企业官网建设流程全解析

Agent 怎么做规划？这道面试题淘汰了 80% 的候选人。最近我参与了几轮算法岗的招聘，发现一个很有意思的现象：简历上写着“熟悉 Agent 开发”的候选人，超过八成在问到具体规划机制时卡壳。不是他们不会调接口，而是对“规划”这件事缺乏系统性的认知框架。今天把这道题彻底拆开聊透，从面试官视角看我到底在问什么，从候选人视角讲清楚怎么答才能过关。

1. 面试官为什么要问这道题

1.1 本题考察的三层能力

先说说我的出题动机。Agent 这个词近两年被用滥了，很多人做过几个基于大模型的自动化任务，就敢在简历上写“精通 Agent 开发”。但 Agent 系统的核心难点从来不在调用某个模型接口，而在于如何让模型在复杂、不确定的环境中持续做出正确决策——这就是规划。

我在面试中会先让候选人介绍自己做过的 Agent 项目，然后轻描淡写地追问一句：“你这个 Agent 拿到用户指令之后，是怎么做规划的？”这一句话就能筛掉一大半人。为什么？因为这道题背后考察的是三层递进的能力：

第一层，概念层面的理解。候选人能不能清晰说出规划在 Agent 系统里的定位，是独立模块还是模型能力的一部分，规划的输出产物是什么。第二层，机制层面的认知。知道规划不只是“让模型生成一段步骤列表”，而是要考虑环境反馈、状态跟踪、目标分解、失败重试等完整链路。第三层，工程层面的落地。面对一个实际任务，应该如何选择规划粒度、如何设计规划上下文、如何与其他模块协同。

只答出第一层的，是调用过 API 的普通开发者；能答到第二层的，说明真正做过 Agent 系统；能到第三层的，基本就是我们要的人。所以如果你现在准备面试，一定要把这三层都覆盖到。

1.2 规划在 Agent 架构中的真实位置

很多人对 Agent 的理解停留在“大模型 + 工具调用”的层面，这其实只是最基础的一环。真正生产级的 Agent 系统，一般包含以下几个相互协作的模块：

• 规划模块（Planner）：把用户目标拆解为可执行的子任务序列，决定下一步做什么
• 记忆模块（Memory）：保存历史对话、中间结果、执行失败的教训，供规划模块参考
• 工具层（Tools）：模型可以调用的外部能力，如搜索、计算、代码执行等
• 执行模块（Executor）：真正去调用工具、运行代码、完成某一步具体操作
• 反馈模块（Critic / Evaluator）：观察执行结果，判断当前状态是否达到预期

规划模块在这里充当“大脑皮层”的角色。它不负责具体执行某一步，而是负责持续回答一个问题：“现在我处在什么状态，下一个应该做什么才能接近最终目标？”

我在面试中见过不少候选人有个误区，认为规划就是把用户指令拆分一下就结束。这种理解在单步任务里勉强够用，比如“帮我查一下明天上海到北京的航班”，模型直接调用搜索工具就完成了。但真实场景往往是多步协同的，比如“帮我策划一场为期三天的北京亲子游，包含交通、住宿和每日行程”。这种任务需要在多个维度做决策，规划就不是一句话提示词能搞定的了。面试官真正想听的是：你如何设计一套机制，让模型在这个复杂任务上持续保持方向感。

2. 先厘清一个前提：规划到底解决什么问题

2.1 规划的本质是路径选择，不是步骤罗列

规划这个词听起来抽象，换个角度理解就简单多了：给定一个目标，以及当前的初始状态，找到一条从初始状态到目标状态的行动路径。

这个过程包含三个关键要素：状态空间（系统可能处于的多种情况的集合）、行动空间（每一步可以做的操作的集合）、目标函数（判断一个状态是否满足用户需求的指标）。模型规划，本质上是在这三个要素构成的问题空间中搜索一条合理路径。

举个例子，用户说“帮我调研一下开源 RAG 框架的选型，并输出对比报告”。翻译成规划语言就是：初始状态是“只有用户需求文本”，目标状态是“产出包含框架对比的分析报告”。中间的路径可能包含：搜索相关框架 → 阅读官方文档 → 对比各项指标 → 整理报告框架 → 逐部分填充内容 → 校验引用来源。每一步行动都会改变系统的状态，比如“阅读官方文档”之后，状态就从“只有搜索摘要”变成了“掌握了部分框架的详细特性”。

面试中我经常追问一个问题：“如果模型在第一步搜索时发现没有找到任何相关资料，你的规划应该怎么办？”能答出“根据反馈重新调整后续步骤”的候选人，说明理解了规划是动态的过程——这个点我后面第 3 小节会详细展开。

2.2 为什么不能简单让模型“生成步骤清单”

有候选人会反问：“规划不就是写一段提示词，让模型‘请一步一步思考’吗？”这个说法不算错，但放在面试语境里，显得对系统的理解过于浅层。只依赖模型内隐能力生成一次性步骤清单，会面临几个很现实的问题：

一是步骤与步骤之间没有状态传递机制。模型生成完清单就结束了，中间某一步的产出没有结构化地存储下来，后面的步骤看不到前面的成果，整体执行就像断线木偶。二是缺乏失败恢复能力。清单是预先定死的，如果某一步执行结果与预期不符，模型不会自主修正路径，整个任务就可能卡死。三是无法验证规划质量。没有与真实环境交互的规划，只是模型一厢情愿的推演，一旦用户的真实意图隐藏在需求之中（比如“性价比高的框架”到底怎么定义），规划就可能跑偏。

所以面试官提到“规划”时，隐含的意思是：你如何构建一套机制，让模型在行动中持续规划、修正规划、收敛目标。单纯依靠模型生成一段 Markdown 列表，距离这个要求差了至少一个层次。

2.3 规划与记忆、工具、反思的分工边界

要回答“Agent 怎么做规划”，还有一步关键功课：搞清楚规划模块与其相邻模块的分工。很多候选人把所有逻辑都塞进“规划”这个词里，结果讲起来一团浆糊。我习惯用一个比喻帮助理解：规划是大脑里负责定方向的部分，工具是手，记忆是便签纸，反思是复盘的人。

• 记忆模块负责“记住”：已经完成了哪些步骤、上一步的产出是什么、用户之前提过什么特殊要求
• 工具层负责“行动”：真正去调用外部搜索、执行代码、操作数据库
• 反思模块负责“检查”：这一步的结果是否符合预期，如果不符合，问题出在哪里
• 规划模块负责“决策”：基于记忆提供的上下文、环境返回的反馈，决定下一步调用哪个工具、执行什么操作

面试时如果能把分工讲清楚，会立刻给面试官一种“这个人是真做过系统”的感觉。比如你可以在回答里说：“我的 Agent 里有一个独立的 planner 模块，它会先读取 memory 中保存的历史状态，再根据当前环境反馈生成下一步的操作指令，交给 executor 执行。执行完的结果会写回 memory，并且触发一次反思判断是否需要调整原计划。”这段话听起来就比“让大模型自己规划”扎实得多。

3. 面试必知：四种主流规划实现的模式与取舍

3.1 一次性规划：从 CoT 到结构化任务分解

先讲最基础的方案，面试时可以作为话题起点。一次性规划的思路是：接收用户请求后，让模型基于自身能力直接输出完整的执行计划，之后按计划逐步执行，整个过程中不修改计划内容。

这种方案的典型实现方式是 CoT（Chain-of-Thought）提示，也就是在系统提示词中要求模型“一步步列出行动步骤”。进阶一点的实现是结构化任务分解，让模型输出一个 JSON 数组，每个元素包含步骤描述、依赖的上一步、预期产出、需要调用的工具等字段。这种结构化的输出可以方便后续模块解析和执行。

一次性规划的优点很明显：实现简单、Token 可控、响应速度快，适合目标明确、步骤有限的简单任务。比如“帮我整理这个文件夹里所有 Python 文件的函数清单”，计划基本可以一次成型，中途很少需要调整。

但它也有致命短板：没有任何反馈机制。如果真实执行结果偏离预期，模型不会根据新的信息做出调整。好比导航软件只给你一条路线，不根据实时路况改变推荐——在小城市够用，遇到交通管制就傻了。面试中你可以主动指出这个局限，并顺势引出下一种方案，展示你的知识层次。

3.2 循环式规划：ReAct 模式与动态调整

ReAct（Reason + Act）是目前 Agent 框架里使用最广泛的规划模式，核心思想是“边想边做”：模型在每一轮循环中交替执行两个动作——推理（Reason）当前状态并决定下一步行动，行动（Act）调用工具或执行步骤，然后观察结果，带着新的信息进入下一轮循环。

ReAct 的关键价值在于把规划从一次性行为变成了持续行为。每一步执行后的结果都可能改变模型对后续路径的判断，从而动态调整计划。比如让 Agent“调研 RAG 框架并选型”，第一轮搜索可能返回几个框架的名字，模型据此规划下一步去查阅某个框架的文档；如果文档内容显示该框架已经停止维护，模型可以立即调整计划，不再深入调研它。

循环式规划的落地一般要设计一套结构化提示词。系统提示词中定义好“当前目标”“历史记录”“上一步结果”“下一步行动”四个区域，每一轮循环都更新这些区域。模型在每一步必须输出“推理 + 行动”的 JSON，便于程序解析。

面试时提到 ReAct，一定要说出它的关键缺陷：长期任务中，模型容易在循环里“迷路”。原因很简单，模型没有把已完成步骤和最终目标持续关联起来，越长的任务越容易偏离。这个缺陷是引出反思机制和分层规划的天然跳板。

3.3 分层规划：Plan-and-Execute 如何避免顾此失彼

Plan-and-Execute 模式的灵感来自人类做项目的思路：先做总体规划，再逐步执行。具体到 Agent 里，模型会先根据用户目标生成一个高层计划（比如“第一步调研框架；第二步深入评估候选；第三步输出对比报告”），然后进入逐步执行阶段，每一步执行时再生成细粒度的操作指令。

这种“两层规划”的好处十分突出：高层计划保证了大方向不偏，细粒度规划保证了每步具体可执行。当某一步的执行出现问题时，只需要重新规划当前这一步，而不必推翻整个高层计划。好比建房子，先有建筑蓝图，再针对每一层做详细的施工方案；某一层施工遇到问题，只需要调整该层的方案，不必重新设计整栋楼。

面试时你可以进一步谈 Plan-and-Execute 的变体，比如分层 ReAct：高层使用 ReAct 模式监控目标达成情况，低层使用 ReAct 模式执行单步任务，两层之间通过共享记忆模块同步状态。这种混合架构在复杂任务中表现更好，是当前工业级 Agent 系统的常见选型。

这个方案也有代价：多一层规划意味着更多的模型调用，Token 成本和延迟都会上升。面试中可以主动提这段取舍——比如“对于简单任务，我会退化为单层 ReAct；只有任务复杂度超过阈值时，才启用分层规划”，这句话会显得你很懂工程权衡。

3.4 失败驱动的规划：反思机制如何闭环

前面三种模式都隐含一个假设：模型规划的路径基本合理，只是在执行过程中需要微调。但真实世界里，模型规划的方案很有可能整体方向就是错的，这时候需要有机制让模型发现自己错了，并能主动重规划。这就是反思机制（Reflexion / Self-Refine）要解决的问题。

反思机制的工作流程是：执行一轮规划后，引入一个独立的评估步骤，判断当前状态与目标的差距；如果状态偏离预期，则将原因总结成一条经验记录到记忆模块中；下一次规划之前，模型会读取这些历史经验，避免重蹈覆辙。简而言之，就是给 Agent 装上“复盘一票否决权”。

举个例子，用户让 Agent“总结这篇论文的创新点”，Agent 第一轮规划是“先下载 PDF，再读取全文，最后生成摘要”。如果论文下载失败，一个没有反思机制的 Agent 会反复重试下载，陷入死循环。而带反思机制的 Agent 会将失败原因记录为“下载 PDF 失败可能是因为无法直接访问，应该尝试搜索论文的 HTML 版本或作者主页的公开版本”，然后带着这条经验重新规划路径，成功概率显著提升。

面试时能够主动讲出反思机制，基本就达到资深候选人的门槛了。因为这说明你不是在用一个大模型硬扛所有任务，而是在构建一套可持续改进的系统。

4. 把规划讲透：状态管理、上下文工程与工具协同

4.1 规划上下文的设计与 Token 预算

很多候选人面试时避重就轻，讲概念头头是道，可一旦问到“系统提示词里到底写了什么”“上下文爆掉怎么办”，就开始含糊其辞。这里我明确说，规划上下文的设计是面试加分项，也是实操中最容易踩坑的地方。

一个完整的规划上下文通常包含五个部分：

1. 系统指令区：定义 Agent 的身份、可用的工具列表、输出格式要求
2. 用户目标区：将用户原始请求改写成一个结构化目标描述，包含目标定义、约束条件、成功标准
3. 记忆回放区：压缩保存历史步骤的关键信息，比如已完成的操作、上一步的结果摘要、用户补充的偏好
4. 候选行动区：根据当前状态，由模型生成或由程序筛选出的候选下一步行动列表
5. 决策输出区：模型输出决策结果，包括选择的行动、工具调用参数、预测的预期结果

Token 预算是另一个叙事重点。规划上下文太长会挤占模型生成空间，太短又可能导致信息缺失。我的经验做法是为每个区域设置动态阈值：用户目标区不超过 500 Token，记忆回放区按最近优先原则截取不超过 800 Token 的关键条目，候选行动区最多保留 3~5 个选项。如果历史信息太多，先对记忆做摘要压缩，再用摘要参与构造上下文。

4.2 规划粒度怎么定：粗粒度与细粒度的取舍

面试追问到规划粒度时，大多数候选人答不太清楚。粒度选择确实需要工程判断，这里给你一套可复用的决策逻辑。

规划粒度指的是每一步操作的抽象程度。粗粒度的步骤比如“调研市场竞品”，细粒度的步骤比如“用搜索工具查询某公司某产品的定价并整理成表格”。两者各有利弊：

实操里常见的策略是**“粗粒度规划 + 细粒度执行”**：第一轮先生成不超过 5 个大步骤的计划，进入具体步骤后，再根据当前状态生成细粒度操作序列。这样结合了两者的优点。面试中可以提一句你实际项目里的粒度选择经验，比如“我最初用细粒度规划，结果发现长任务经常中途 Token 溢出，后来改成两层规划，稳定性明显提升”。有真实数据支撑的表述，说服力远高于空谈理论。

4.3 环境反馈回灌：让规划看见真实世界

考察完上下文设计和粒度选择，面试官大概率还会追问一个关键问题：“规划模块怎么感知环境反馈？”这个问题的本质是：模型生成计划时闭门造车，但执行在真实世界中进行，两者之间如何打通。

我常用的一种设计方案是状态向量回灌。环境反馈的结构化字段（比如“月度开销预算已用 90%”“搜索返回结果为空”“代码执行报错类型为权限不足”）会被转译成自然语言文本，并作为一个必需的上下文项注入下一轮规划。模型在生成下一步行动时，必须显式说明“根据上一步反馈，我调整计划如下”，这样既强制模型关注反馈，也给审查人员提供了追踪解释的依据。

另一种更工程化的方式是维护一个动态待办列表（To-do List）。每完成一步，就把这步从待办中划掉，并在列表里补充新的下一步。如果某一步执行失败，该步不会被简单移除，而会被标记为 blocked，同时写入失败原因。下一轮规划时，模型看到 blocked 状态的步骤，就会明白需要绕行或使用替代方案。这种方式可追溯性强，调试 Agent 行为时非常有用。

4.4 工具能力与规划决策的双向绑定

最后再讲一个面试里容易被忽视但含金量很高的点：规划模块和工具层的关系。有些候选人把工具选型描述为“规划时一起输出工具调用参数”，这其实只做对了三分之一。

合理的设计是先定义工具的能力接口，再让规划基于接口做决策。举例说明，搜索工具返回的不只是原始文本，还会附带“结果置信度”“来源时效性”等元信息。规划模块看到低置信度的搜索结果时，会更倾向于规划“打开原始链接阅读全文”而不是直接引用搜索结果。如果搜索工具支持“按时间过滤”，规划模块在调研“最新技术趋势”类任务时就会优先使用时间过滤参数。工具接口设计得越结构化，规划模块的决策质量就越高。

我在项目里养成的习惯是给每个工具写一份机器可读的说明文档，包含功能描述、输入参数、输出字段、典型使用场景和禁忌。这份文档通过系统提示词注入规划上下文，模型在生成规划方案时就会主动匹配工具能力。这个细节被很多开发者忽视，但面试时一旦讲出来，会显得你的设计思路非常系统和完整。

5. 过来人的踩坑实录：典型错误与标准回答话术

5.1 四种典型的失分回答

面试中我记录了许多典型的失分回答，总结成四类：

失分回答一：“让大模型自己拆解任务就行。”这个问题错在把规划完全交给了模型自身能力，没有体现任何机制设计。面试官接下来追问“拆错了怎么办”，候选人往往就答不上来了。

失分回答二：“我用过 LangChain 的 Agent 模块。”报框架名字不是错，错的是只报名字而不讲内部原理：“你改过它默认的 ReAct 提示词吗？”“如果新增一个工具，底层规划上下文要怎么改？”几乎每次都能问倒一片。

失分回答三：“规划就是生成 Prompt 模板。”这类候选人可能做过一点工程，但理解仍然停留在提示词层面。他们没有区分“提示词驱动的模型能力”和“系统架构驱动的规划能力”——前者是模型可能怎么想，后者是系统如何约束模型去进行规范化的规划、执行和反思。

失分回答四：“我们的 Agent 用了一个很大的模型，不需要规划。”这句话最让面试官无语。大模型能力再强，也不可能在一个上下文里承载无限长的复杂任务和不断变化的环境状态。工业级系统需要的是确定性、可控性和可调试性，这些都只能靠显式的规划机制来提供。

5.2 面试官想听的回答结构

帮你整理一套稳妥的答题逻辑，覆盖前文提到的三个考察层次。首先从概念切入：规划是 Agent 根据目标、环境和记忆选择行动路径的过程，输出物是一系列可执行的行动序列。

然后上升到机制：根据任务复杂度选择不同实现模式。简单任务用结构化的一次性规划；中等复杂度任务用 ReAct 循环，让计划在执行中动态调整；复杂长程任务用 Plan-and-Execute 两层架构，高层定方向、低层定操作；再叠加反思机制，让 Agent 能够从失败中学习并重规划。

最后落到工程细节：规划上下文包含目标定义、历史摘要、环境反馈、候选行动、工具接口说明；每一步的规划输出用结构化 JSON 表示，包含行动类型、调用参数、预期结果、依赖关系；执行反馈通过状态回灌更新上下文；还要注意 Token 预算和规划粒度控制。

这样一套回答下来，逻辑层层递进，既有全局高度又有落地细节，面试官基本可以判断你对规划的理解是系统的，不是背出来的。

5.3 被追问怎么接招：模拟场景实录

面试追问环节能进一步拉开差距。这里列出几个高频追问和参考作答方向：

面试官问：“如果规划完成后，工具执行结果和预期不一致，你的系统接下来会做什么？”

参考应答要点：先判断不一致的类型。如果是局部偏差，比如搜索结果比预期少，当前步骤改参数重跑即可；如果是全局偏差，比如目标理解错误，则需要触发反思机制，重读用户意图并重新生成计划。这里的区分逻辑是“偏差的影响范围决定重规划的层级”。

面试官问：“长任务中怎么防止模型忘记最终目标？比如让 Agent 做 20 步以上的事情。”

参考应答要点：一种方案是把最终目标摘要放在规划上下文的固定区域，每轮循环都要重新读一遍；另一种方案是使用子目标校验节点，每隔几步就要求模型输出“当前完成度与最终目标的差距”，如果偏离超过阈值，强制触发重规划。

面试官问：“一个 Agent 系统支持上百种工具，规划时怎么保证模型选对工具？”

参考应答要点：一次性把所有工具描述塞进上下文是行不通的，需要用工具召回机制。第一步，根据当前任务目标用向量检索或规则匹配，从上百种工具里筛选出 5~10 个候选工具；第二步，只将候选工具的详细说明注入规划上下文。这样既控制 Token，又提高选型准确率。

5.4 候选人应该如何准备这道题

准备这道题时，网上的教程和文档多如牛毛，但光看不练很难形成系统认知。我给你三个亲测有效的准备路径：

路径一：亲手搭一个最小 ReAct Agent，不要用现成框架，自己写提示词、自己解析模型输出、自己管理历史状态。完整跑通一轮“规划-执行-反馈-再规划”的循环，你会对状态传递和上下文更新的理解上升好几个台阶。

路径二：阅读两个主流框架中 ReAct 或 Plan-and-Execute 的实现源码，重点看默认提示词模板长什么样、规划输出的数据结构长什么样、哪几个类负责更新上下文。带着“如果让我重新写，我会改哪里”的问题去读，收获完全不一样。

路径三：用文档把“我的 Agent 系统”完整写一遍。从架构图到规划模块的代码片段，再到一次执行过程的日志记录，写的过程就是查漏补缺的过程。这套材料既是面试准备，也是你未来的项目展示资料，一举两得。

6. 从面试透析到真实场景：一个规划模块的最小实现骨架

6.1 用伪代码还原规划循环

光讲理论不给代码，总感觉少了点什么。这里我用一段简化的 Python 伪代码，展示了一个带反馈回路的规划循环长什么样：

class PlanningAgent: def __init__(self, llm, tools, memory): self.llm = llm # 基础模型 self.tools = tools # 可用工具集合 self.memory = memory # 记忆模块 def plan_and_execute(self, user_goal): # 初始化目标上下文 context = self.build_context(user_goal, history=[]) while not self.goal_reached(context): # 1. 规划：生成下一步决策 action = self.llm.generate_action(context) # 2. 执行：调用外部工具 result = self.tools.call(action["tool"], action["params"]) # 3. 反馈：评估结果与目标差距 feedback = self.evaluate(action, result, context["goal"]) # 4. 反思：判断是否需要重规划 if feedback["need_replan"]: context = self.replan(context, feedback["reason"]) # 5. 记忆：写入历史 self.memory.append(action, result, feedback) # 6. 更新上下文 context = self.update_context(context, action, result, feedback) return context["final_output"]

这段代码的主干已经覆盖了规划的完整生命周期。面试或实际设计时，可以把它当成一个可运行的提纲，每个环节再往工程级方向展开。

6.2 设计规划上下文的具体做法

如果你想照着实现，下面的上下文构造模板可以直接抄走：

planning_prompt = """ 你是具备任务规划能力的智能体。请基于以下信息，决定下一步行动。 【最终目标】 {goal_description} 【成功标准】 {success_criteria} 【已完成步骤】 {completed_steps_summary} 【上一步执行结果】 {last_step_feedback} 【可用工具】 {tool_descriptions} 【候选下一步动作】 1. 调用工具：{tool_name}, 参数：{params} 2. 直接生成回复内容 3. 向用户澄清需求 请严格按JSON格式输出你的决策，包含： - thought: 你的推理过程 - action: 动作类型 - action_input: 动作参数 - expected_result: 你预期的结果 """

实际跑过几次你就会发现，“向用户澄清需求”这个选项极其重要。很多 Agent 任务失败，根源在于初始需求含糊不清。在规划上下文中留出澄清入口，等于给系统增加了一条安全通路。

6.3 规划模块冷启动参数与调优方向

最后给一组经过实际项目验证的冷启动参数建议，可以直接作为第一版设计的参考基线：

这些参数没有标准答案，全靠实验数据驱动调整。我在项目中养成的习惯是每次改动只调一个参数，记录前后效果对比，避免参数联动导致无法定位优化来源。

7. 面试之外：这道题背后的行业思考

7.1 为什么“规划能力”越来越被看重

近年来，Agent 的能力边界不断被重新定义，单纯“能调用工具”已经不足以应对复杂的实际任务。行业里有一个逐渐形成的共识：模型本身的智力水平固然重要，但把智力组织成有效行动的“规划中枢”，才是 Agent 能否从玩具走向生产力的分水岭。

一个能稳定完成多阶段任务的 Agent，背后几乎都有一套设计严谨的规划机制。无论是任务分解、动态调整，还是失败反思，这些机制共同决定了系统的稳定性、可控性和可调试性。面试题背后暴露出来的深层行业信号是：市场不再需要“会写提示词的人”，而是需要“能设计决策系统的人”。

7.2 规划机制是门槛，也是护城河

不少产品团队早期发现，使用同样的模型底座，甚至同样的一套提示词，不同人搭出来的 Agent 表现却天差地别。差异恰恰出在规划机制这样的隐形工程细节上：上下文怎么组织、反馈怎么捕捉、错误怎么恢复、经验怎么沉淀。这些设计常识不会直接出现在模型 API 文档里，却决定了产品面对真实复杂任务时的成败。

因此这道面试题淘汰 80% 候选人，既不冤枉也不意外。它淘汰的不是“没背过这个概念”的人，而是“没有真正构建过复杂系统”的人。反过来看，只要你有过亲手实现规划模块的经验，这道题反而会成为你的展示舞台——讲清楚每一步设计背后的取舍，就是最好的证明。

我个人在实际带队做 Agent 项目时体会最深的一点是：规划模块的价值不体现在完美执行路线的时候，而体现在某一步出错时系统还能稳住我发现方向偏差、自动修正并继续朝着目标前进的时候。那正是 Agent 系统真正具备“自主性”的时刻。