企业官网建设流程全解析

1. Agent规划的核心思路：把目标拆成可执行步骤

1.1 为什么规划是Agent的命门？

面试官问Agent怎么做规划，绝对不是闲聊技术流行词。Agent这个名词这两年被聊得火热，但落到真实系统里，一个Agent最核心的能力不是“会聊天”，而是“能靠谱地完成任务链条”。规划就是把一个模糊的目标翻译成一套可执行的动作序列，这个过程本质上考验的是工程系统思维，而不是单纯把提示词写得花哨。

我面试时见过太多候选人，能流畅背诵大模型的参数规模、能罗列一堆工具框架的名称，但被问到“你手里的Agent接到一个‘帮我订好去上海的行程’这种指令时，内部到底发生了什么”，立刻就露怯。原因很简单，课本和框架文档里不会教你怎么拆解不确定性、怎么设计回退机制、怎么在有限步数内收敛到可用的结果。规划就是Agent的命门，因为规划决定了Agent的上限。同样一个底层模型，规划做得好，Agent能把复杂任务拆得清清楚楚，每一步都有产出、有验证；规划做得差，Agent就成了一个会生成花样废话的随机数发生器。

还有一个容易被忽略的点：规划能力直接决定了Agent的可调试性。如果一个Agent没有显式的规划层，所有的逻辑全凭模型自由生成，那出了问题你根本不知道是模型判断错了、工具执行错了，还是任务拆解本身不合理。有了成熟的规划结构，你就能像看图纸一样定位问题出在哪一环。这也是为什么很多实际项目里，看起来“笨”一点但规划清晰的Agent，反而比花里胡哨的纯大模型表现更稳。

1.2 三种主流规划方案：ReAct、Plan-and-Execute、任务分解

我先把目前工业界和学术界最常出现在工程项目里的三种规划方案讲清楚，每一种都有各自的适用范围，不是哪个新潮选哪个。

第一种是ReAct（Reasoning + Acting），本质是“边想边做”。Agent每走一步，都让大模型根据当前已有的信息做一次推理，决定是调用工具还是直接回答，然后把工具返回的结果又塞回给大模型做下一轮决策。这种方式的强项在于灵活性，特别适合那些路径不确定、需要根据中间结果动态调整的任务。比如“你知道今天的天气吗？如果适合户外，帮我推荐一条跑步路线”，这个任务只有在拿到天气数据之后才能决定下一步怎么走，非常适合ReAct。

第二种是Plan-and-Execute，也就是“先规划再执行”。Agent接收用户请求后，不急着动工具，而是先让大模型生成整个步骤清单，然后按步骤一步步执行。这个过程很像我们做菜前先看一遍菜谱，把所有准备工作列好再动手。它的优势是流程可控、每一步可预测、方便插入人工审核节点，特别适合业务相对固定、操作流程早就定死的场景，比如“每天定时抓取某个网站数据，清洗后写入数据库并生成报表”。

第三种是任务分解（Task Decomposition），严格来说它更像一种规划的组织方式，经常和前两种方案嵌套使用。核心是把一个大目标递归拆成树状的子任务，直到每个子任务都原子到可以直接调用某个工具或API的程度。比如“做一个行业竞品分析报告”，可以拆成收集竞品列表、抓取官网信息、抓取社交媒体评论、汇总分析、排版输出这几个二级任务，然后每个二级任务再往下拆。

这三种方式放到一起对比，看得更清楚：

不夸张地说，能把这三者的区别和选型理由讲清楚，面试已经赢了一半。最怕的就是候选人只知道“有个东西叫ReAct”，却说不出为什么不用另外两种，这不仅暴露了知识的碎片化，更说明根本没有完整落地的经验。

1.3 选型逻辑：不要盲目跟风，需求和场景决定方案

我见过不止一个团队，上来就冲着最火的ReAct方案去搭Agent，结果在一个极其稳定的数据处理流程里频繁“抽风”：模型偶尔会凭空调用不相关的工具，偶尔会陷入反复查询同一条信息的死循环。看起来“生动”，用起来“灾难”。

选规划方案的核心是判断任务确定性。怎么判断？我一般用三个角度：步骤按预设顺序走就能成吗？中间需要参考即时反馈来调整走向吗？子任务之间是严格的先后依赖还是可以并行？如果步骤本身是固定的线性流程，Plan-and-Execute 就是最省心的选择；如果任务需要根据阶段性结果决定下一步，比如爬取了一堆数据后发现缺了关键字段、还需要补查另一个维度，那就果断选 ReAct；如果任务是“把一堆杂事整合成一个完整交付物”，那任务分解是主框架，内部细节再配合 ReAct 或 Plan-and-Execute。

还有一点，很多候选人忽略了对“不确定性的边界”的思考。一个成熟的规划方案，必须预先定义清楚“什么情况下Agent可以自主决定”、“什么情况下必须停下来向用户确认”。比如让Agent订机票，如果模型自动选择了某个不符合公司差旅标准的航班，这种自作主张不仅不聪明，还会给用户带来麻烦。规划层应该内置规则边界，超出边界就终止或询问，而不是让模型自由发挥。

所以面试中，你讲选型逻辑时应该带出真实场景。我说一个我自己的复现经验：做一个内部知识库问答Agent，早期用纯Plan-and-Execute，把“理解问题-查知识库-生成答案”作为三个固定步骤。看起来合理，但实际跑起来发现，有些问题需要先查知识库才能搞清楚用户到底在问什么，再回头修正最初的理解。后来我改成ReAct，每个回合都重新评估当前信息是否足够回答，效果立刻好了很多。这种实际对比，讲出来比任何理论都更有说服力。

2. 实操中的关键细节：从目标到动作的翻译

2.1 目标拆解：把大目标具象化成可执行的小任务

规划的第一步，也是最容易被小看的一步，是把“用户的一句大白话”变成“可执行的任务树”。很多候选人会说“拆任务嘛，谁不会”，但他们不知道拆任务拆得不好，后面整个规划过程都会塌掉。

先举个典型差拆解：用户说“帮我安排好这周的健身计划”。一个差的拆法是把“健身计划”直接理解成“生成一份文字计划”，然后让模型输出一段漂亮话。这不是Agent，这是文档生成器。好的拆解会这么走：第一步，询问或推断用户当前的身体状态、可训练时间、器械条件；第二步，根据信息确定本周训练目标（增肌/减脂/保持）；第三步，按训练日、动作类型、组间休息、强度把计划拆到每天的清单；第四步，检查计划是否和用户日程冲突，不冲突才输出。只有拆到这种粒度，每个子任务背后才有明确的工具或者数据可以支撑。

关于拆解粒度，我习惯用一个朴素标准：一个子任务里应该只有一个“必须决策点”。比如“确定训练目标”是一个决策点，“选择动作列表”是另一个决策点，如果把它们揉在一起，Agent容易在单个步骤里胡猜一气，也不方便单独插入人工确认。拆完任务以后，还有一个经常被漏掉的环节——给任务排序。有些任务天然有先后依赖，比如“先决定训练目标，再选择动作”，有些任务可以并行，比如“查天气”和“查用户日程”互不相关。排序做得好，整个执行时间能缩短一大截。

在我实操过的Agent项目里，经验是拆解时不要把用户想得太理性。用户很少一次性给足所有信息，很多情况下只有一个不完整甚至带歧义的诉求。所以任务树的顶部通常会额外加一个信息收集任务，用来补齐缺失的字段。有人觉得这样显得“啰嗦”，但实际是保证规划不跑偏的核心动作。

2.2 工具调用：Agent如何决定用哪个工具

规划拆出了步骤，接下来每步都得落实到一个具体的工具上。工具调用的过程，本质上是大模型在做“动作选择”。

实现层最常见的做法是函数调用（Function Calling）。先用JSON Schema把每个工具的名称、参数、返回值类型描述清楚，然后在每次规划循环里把这些描述连同历史对话一起发给大模型。大模型输出一个结构化结果，例如{"name": "search_web", "arguments": {"query": "上海三日游攻略"}}，然后外部代码解析这个结果并真正执行搜索。

这里有个容易犯的错：工具描述写得又短又模糊。我做过实验，工具名叫“process”之外什么都不写，大模型根本不知道该在什么时候用它。后来我把描述改成了“process_payment（处理订单支付，参数: order_id），该工具会扣款并返回支付状态”，调用准确率立刻提升了非常明显的一截。所以写工具描述时要做到“名称动词开头，描述包含功能、输入、输出、边界条件”四件套。这些功夫不花在视觉上，但直接决定了工具选择是否靠谱。

工具调用的另一个重点是如何处理并发和并行。规划中各个子任务如果互不依赖，理论上可以用并行发起多个工具调用，节省时间。OpenAI的函数调用接口已经支持在单个响应里返回多个tool_calls，很多开源框架也都支持。但并行调用会引入资源竞争和依赖判断的复杂度，比如两个工具都修改同一个用户的配置文件，就会出现潜在冲突。项目里的做法通常是：能并行则并行，但写“只读类工具”优先并行，“写操作类工具”保持串行并逐次确认结果。

2.3 状态跟踪：防止规划跑偏的核心机制

规划执行过程里，如果Agent没有一份显式的状态记录，执行到第三步的时候，它很可能已经忘了第一步得到的关键信息。这不是开玩笑，是真实发生过的坑。大模型上下文窗口再大，也不适合用来充当“数据库”，它只适合做短程推理。全局状态需要由系统端维护。

我自己的做法是维护一个JSON结构，里面包含三个字段：已完成步骤列表、当前待处理步骤、关键中间结果缓存。每执行完一个工具调用，就把工具的返回值填充进“关键中间结果缓存”，并把该步骤从待处理列表移到已完成列表。下一次规划循环开始前，把这份状态序列化后拼进提示词上下文，让模型基于最新的事实做决策，而不是凭着对话残影去猜。

给个直观例子。用户让Agent“给某公司写一份周报，然后发给主管”。Agent必须先拿到项目数据，然后写周报，再找到主管的邮箱，最后发送。如果没有状态跟踪，模型很可能在生成周报正文之前就去翻通讯录，甚至重复抓取多遍项目数据。而状态跟踪做得好，就能看到“数据获取：完成”、“周报生成：待执行”、“收件人查找：待执行”、“邮件发送：待执行”，每一步都是明确的，任何人来看当前进行到哪都一目了然。

状态跟踪还有一个隐藏价值：失败恢复。如果某个步骤执行失败了，比如邮件服务暂时不可用，有了状态表你就能知道应该回滚到哪一步，而不是让Agent从零再来一遍。很多复杂的生产级Agent，比如电商客服、运维巡检工具，本质上全靠这套状态管理在撑着。

3. 亲手实现一个Agent规划：一个简单Demo

3.1 环境准备：创建一个可运行的Demo项目

光讲概念不过瘾，我直接用一个“日程助手Agent”来演示规划到底在代码里长什么样。这个Demo的核心功能是：用户用自然语言描述日程安排需求，Agent自行决定是先查时间还是直接建日程，最后给出确认信息。这个例子虽小，却完整包含了规划、工具调用、状态跟踪和终止判断。

先说环境。我用的Python版本是3.10以上，只需要装一个最核心的依赖包：

pip install openai

我假设你已经有一个可用的模型服务接口，并且配置好了环境变量。为了演示方便，下面代码里把模型调用统一封装在一个叫client.chat.completions.create的地方，和主流SDK的用法保持一致。

整个项目的文件结构可以保持极简，两个文件足够：一个是tools.py，用来定义工具函数；一个是agent.py，用来写规划循环主逻辑。别小看这个极简结构，后面扩展成复杂项目时，把工具定义和规划逻辑分开写是避免代码腐化的好习惯。

3.2 核心实现：规划循环怎么写

先定义工具。这个Demo只需要两个工具，一个是获取当前时间，一个是创建日程事件。每个工具都写成普通Python函数，然后额外定义一个工具Schema列表，供大模型做函数调用参考。

from datetime import datetime import json def get_current_time(): """获取当前时间（ISO格式）""" return datetime.now().isoformat() def create_calendar_event(title: str, time: str, location: str = ""): """创建一条日程记录，返回确认文本""" return f"日程已创建: {title} 在 {time} 地点: {location or '未指定'}" tools = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取当前时间，ISO格式，用于判断当前日期和具体时刻。", "parameters": { "type": "object", "properties": {}, "required": [] } } }, { "type": "function", "function": { "name": "create_calendar_event", "description": "创建日程事件，必须提供日程标题和事件时间，可选提供地点。", "parameters": { "type": "object", "properties": { "title": {"type": "string", "description": "日程标题，例如“团队周会”"}, "time": {"type": "string", "description": "事件时间，ISO格式，例如2025-06-01T09:00:00"}, "location": {"type": "string", "description": "事件地点，例如“会议室A”"} }, "required": ["title", "time"] } } } ]

接下来是核心的规划循环。我声明一个run_agent函数，参数是用户输入的字符串。循环里每一轮做四件事：把历史消息发给模型；模型返回工具调用请求或文本答复；如果有工具调用就执行工具并把结果追加进消息；直到模型不再请求工具调用为止。

from openai import OpenAI client = OpenAI() def execute_tool(name: str, arguments: dict): if name == "get_current_time": return get_current_time() elif name == "create_calendar_event": return create_calendar_event(**arguments) return "未知工具" def run_agent(user_request: str, max_steps: int = 5): messages = [{"role": "user", "content": user_request}] for step in range(max_steps): response = client.chat.completions.create( model="gpt-4o", # 换成实际可用的模型标识 messages=messages, tools=tools, tool_choice="auto" ) msg = response.choices[0].message # 模型没有要求调用工具，说明规划已经收敛到最终答案 if not msg.tool_calls: return msg.content # 把模型提出的工具请求追加进上下文 messages.append(msg) # 依次执行模型请求的每个工具调用 for tool_call in msg.tool_calls: tool_name = tool_call.function.name tool_args = json.loads(tool_call.function.arguments) result = execute_tool(tool_name, tool_args) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) return "已达到最大步数上限，未能完成规划，需要更多信息或调整方案。"

这段代码虽然短，浓缩了一个Agent规划循环的所有要素。注意看几个关键点：每次工具执行后的结果都用role: "tool"的消息传回给模型；消息列表是不断累积的，因此模型能看到完整的执行轨迹；max_steps限制了循环次数，防止模型陷入死循环。

3.3 测试和验证：从运行结果看规划行为

我用这段代码跑了几条真实请求，把实际行为拆开讲一讲。

请求一：“现在几点了？”模型直接就调用了get_current_time，拿到时间后没有再调用其他工具，很快给出回答。这说明规划很简单，一步到位。

请求二：“帮我安排明天上午10点开一场项目复盘会，地点在3楼会议室。”这次模型做了两次工具调用：一次是获取当前时间（因为“明天上午10点”需要从当前时间推算具体日期），一次是创建日程事件。第二个工具的参数里自动填上了计算好的具体日期。整个过程没有多余动作，非常干净。

请求三：“帮我安排个会议。”这条就出问题了。模型直接调用了create_calendar_event，参数里的title随便填了个“会议”，time填了一个看似合理的未来时间。这看起来好像“完成了任务”，实际上完全是瞎猜。与会人员是谁？会议主题是什么？时长多久？全都没有和用户确认。

这个失败案例非常有价值，因为它暴露出规划层一个典型缺陷：大模型倾向于“臆造缺失信息”来迎合请求。解决办法不是在工具层加参数，而是在系统提示词里明确约束：“如果用户指令中缺少必要信息（如日程主题、具体日期、参会人员），必须先向用户提问，不得自行猜测或填充默认值。”我在项目里加了这个提示后，无脑乱猜的行为大幅减少。

3.4 辅助函数：让Agent具备信息补齐意识

既然上面说到信息缺失的问题，我干脆扩展一下这个Demo，让它具备“追问缺失信息”的能力。做法很简单，给Agent加一个ask_user工具，模型发现信息不够时调用这个工具反过来向用户提问。

def ask_user(question: str): return f"需要用户回答: {question}" # 在tools列表里增加一项 # { # "type": "function", # "function": { # "name": "ask_user", # "description": "当用户请求中缺少必要信息时，使用该工具向用户提问，获取缺失的字段。", # "parameters": { # "type": "object", # "properties": { # "question": {"type": "string", "description": "需要用户回答的具体问题"} # }, # "required": ["question"] # } # } # }

加了ask_user之后，面对“帮我安排个会议”这种情况，模型就会主动调用它来追问“会议主题是什么？会议时间是什么？参会人员有哪些？”。这个交互流程已经是很多成熟语音助手和办公Agent的常见引擎形态了。

但注意一个度的问题：不要把所有信息都推给用户去填。如果一个字段可以通过已有工具推断出来，那就应该让Agent先尝试自主解决，只有实在无法推断时才发起询问。好的Agent设计是“能自己搞定的绝不麻烦用户，搞不定的才问人”，这个分寸感就是在规划层反复调优出来的。

4. 常见问题与排查技巧实录

4.1 为什么Agent总在规划层死循环？

“死循环”是我在项目里和面试中被提起频率最高的问题。症状是Agent反复调用工具，来回做相同或相似的操作，迟迟不给出一个最终答案。最典型的案例是：模型每隔一轮就重新查一次当前时间，或者反复搜索同一个关键词。

排查技巧第一条，先看步数上限是否设置得太高。如果上限是二十步，模型会在上下文中积累大量消息，有时会因为提示词过长而“晕头转向”，不断重复之前做过的操作。把上限适度调小，迫使模型在有限步数内收敛，往往立竿见影。

第二条，检查工具结果是否真正被模型理解。有时候工具返回的数据格式太复杂，比如给了一整段HTML文本，模型根本没有从里面提取出关键信息，于是只能假装“还在研究中”，继续提出调用同一个工具。这种情况需要做“精简工具返回结果”：要么后端只返回关键字段，要么加一步数据预处理把结果提炼成摘要后再塞给模型。

第三条，非常重要但也容易被忽略的，是在系统提示词里加上“停止条件”。比如写明“当你已经获取所有必要信息并生成最终答案后，直接回复用户，不要再提议调用其他工具”。没有这个显式约束，模型很容易停在某种“我这个答案还不够完整”的自我怀疑中，不断加步数反而给胡来制造空间。

4.2 工具选错的根本原因和解法

工具选错是Agent规划里最常见的“低级错误”，但根因往往不在模型，而在工具设计。我见过最离谱的例子是，模型把“发送邮件”的工具当成“获取邮件”来调用，结果把用户指令理解成去执行一个不存在的操作。

排查这类问题，第一步看工具名称是否有歧义。名称不要用抽象缩写，更不要用模棱两可的动词。举两个例子，“save_data”太模糊，是保存数据库还是保存文件？都不说清楚。“save_attachment_to_cloud_storage”就明确得多了。工具名称是给模型看的，模型不会像人一样根据上下文脑补工具含义，它的判断基准完全建立在名称和描述文字上。

第二步看描述里是否包含“使用时机”。比如一个“get_stock_price”工具，不能只写“获取股票价格”，还要写“当用户询问特定股票实时价格，或需要计算股票收益时调用”。补充清楚使用场景，模型的工具选择准确率会有非常显著的提升。我把这条经验叫作“像给实习生写交接文档一样写工具描述”。

第三步，给工具设计容错。如果模型调用了不合理的参数，工具端不要直接报错，而是返回一个结构化的错误码和错误原因，比如{"error": "invalid_stock_code", "message": "股票代码不存在，请检查后重试"}。这样Agent就能根据错误信息继续规划，是重新解析用户意图还是换另一个工具。

4.3 规划失败时的降级策略

没有哪个Agent敢说自己永远完美，所以规划层的容错设计一定要提前做好。我给自己的Agent设计过一条“三级降级链”，在项目里很管用，也在面试里讲过多遍。

第一级：当前方案（比如ReAct）正常运行时，遇到单个工具调用失败，Agent会基于失败信息尝试修正命令再试一次。比如调起API超时，模型会换用备用API或增加重试间隔。

第二级：如果同一类型的错误连续发生，比如模型反复用同一个错误参数调同一个接口，这时候需要显式终止当前规划路径，回退到更早期的步骤，重新梳理任务拆解逻辑。这不太像是模型主动做出来的，更多是我在系统层写的规则：超过N次同类失败就自动触发重新规划，而不是让模型在废墟上不停打转。

第三级：当重计划也无法解决问题，Agent必须学会“承认失败”。它应该返回一条清晰的消息，说明自己尝试了什么、在哪一步受阻、需要用户提供什么帮助。这一步看起来简单，实际是很多Agent翻车的重灾区。一个硬撑着“完成”任务、其实是给出了一个错误结论的Agent，比直接说“我不知道”的Agent危害大得多。

在面试里讨论这个降级链条，会让面试官觉得你是从生产环境里走过一遭的。绝大多数候选人只会讲一个理想化的流程，如果你能主动提“我的规划经常挂在哪儿，我后来怎么做的”，那已经远超平均水平。

4.4 面试官真正想考察的底层能力

说到底，一个“Agent怎么做规划”的问题，面试官在意的根本不是你能背出多少种方案，而是三件事。第一，你愿不愿意把一个模糊概念落到具体环节上。App的候选人会直接说“用提示词让模型一步步想”，但真正有经验的人会告诉你，这还不够，你还要定义工具、定义循环终止条件、定义失败恢复路径。第二，你有没有面对过真实的不确定性。各种公开方案里都写着“让Agent自主决策”，但“自主决策”在真实环境中意味着要处理信息不全、步骤错乱、外部接口异常一堆糟心事，你没有趟过这些泥潭，是讲不出那种细节的。第三，你有没有权衡取舍的能力。一个方案不可能适配所有场景，你能不能根据任务确定性做选型决策，这比掌握方案本身更值钱。

我也听过一种回答，候选人说“我觉得规划其实不需要单独做，让大模型全部搞定就行”，这种话我一般会在心里打个问号。再智能的模型也仍然是概率系统，面向用户交付的Agent工程，恰恰需要更多确定性，而确定性就是规划层提供的。模型负责发散，规划负责收敛，两者配合，才能把一个“可能做对的系统”变成一个“大概率稳定做对的系统”。

我自己在早期做Agent项目时，也沉迷过“大模型无所不能”的幻想，后来碰了几次墙壁才明白，规划不是限制模型的自由，而是给模型搭一条有护栏的跑道。跑得快不算本事，跑得快还不翻车才算。这篇文章里所有的代码和流程，我都在真实Demo里验证过，并非纸面推演。如果你的Agent正卡在规划层，或者你正在准备一道类似的面试题，实际去跑一遍这个十几行的小例子，感触会比读十篇教程都深。