Agent规划面试淘汰80%？拆解规划系统设计的三层结构与核心能力

最近我在团队面试里加入了这样一道题：Agent 怎么做规划？本来是想当一个基础题热热身，结果一轮面下来，淘汰率居然到了 80% 左右。这个结果让我挺意外的——聊微调、聊 RAG、聊 Prompt 调优，候选人都能说得很热闹，可一落到"规划"两个字，大多数人就露出底了。

有人把规划理解成"让大模型先写个 todo list"，有人背了一堆 ReAct 的术语但对内部机制完全说不清，还有人干脆说"现在的模型够聪明，不需要规划"。这些答案放在面试场上基本都属于直接出局。作为一个实际做过 Agent 系统设计的人，我越来越觉得：这道题不光是一道面试题，它其实把整个 Agent 系统的设计能力给测透了。

这篇文章我会以面试官的口吻，把这道题完整拆开讲一遍，包括规划在三层系统里的位置、主流规划范式的取舍、从零设计规划模块时的关键协议和状态设计，以及一个可以现场推演的完整案例。无论你是正在准备 Agent 方向的候选人，还是已经在做智能体应用的开发者，我都建议把里面的东西当成一套可复用的设计框架来理解。

1. 这道题为什么能淘汰 80% 的候选人

1.1 面试现场最常见的三种“翻车回答”

第一种是复读机型。候选人在简历里写了 ReAct、Plan-and-Execute、Self-Ask 这些关键词，但当面试官问"它们是怎么完成规划的"，答出来的内容跟论文摘要一模一样，没有任何自己的判断。比如会说"ReAct 就是推理和行动交替进行"，但你再追问一句"交替的节奏怎么控制？谁来决定什么时候停止推理？"他就卡住了。这种回答说明他只是看过，没有真正用脑子想过。

第二种是提示词型。这类候选人把规划当成一个 Prompt 技巧来处理，核心观点是"在 system prompt 里加上一句'请先制定计划，再逐步执行'就可以了"。我理解这种思路从哪来，因为这确实是很多 demo 的做法，但实际生产环境里，单靠提示词生成的计划有三大问题：格式不稳定、目标会漂移、失败后没有任何恢复机制。你把这句话写进提示词，得到的只是一段文字，不是一个能驱动系统运行的规划模块。

第三种是技术虚无型。这类候选人会反问我："现在的大模型能力那么强，直接把最终结果推理出来不就行了，为什么还要单独做规划？"这种回答最大的问题是暴露了经验盲区。模型直接生成答案，本质上是在做一个一步到位的概率采样，它不适用于多步骤、多工具、多约束的真实业务场景。你让大模型不经过规划直接调十个 API，它在第五步出错之后是很难自己绕回来的。

1.2 规划是系统问题，不是模型问题

为什么这 80% 的候选人会集体翻车？我观察下来的核心原因是：他们把 Agent 当成"一个更会说的大模型"，而不是"一个需要被设计的系统"。规划恰恰是系统设计最硬核的一部分。

你仔细想想，规划要解决的问题其实都不是模型能力范围内的事。比如：目标怎么分解成子任务？子任务之间有没有依赖关系？哪些步骤可以并行？失败了是重试、换方案还是上报人工？这些全是系统层面的决策，需要有人去设计状态流转、定义异常分支、评估资源消耗。大模型在这里只是规划器的一个"大脑"，而不是规划的全部。

所以这道题本质上考的不是知识储备，而是候选人有没有真正站在系统设计者的角度思考过 Agent。这个门槛天然就刷掉了大量只做过 Demo、只调过 API、只在论文层面看过概念的人。

1.3 能过关的候选人有什么共同特征

我在面试中会给通过的人画一个能力画像，这里分享出来，大家可以对号入座。这些候选人普遍能回答清楚三件事。

第一，能说明白规划的对象是什么。他们会把规划分成不同粒度：有的是目标级规划（决定先做什么后做什么），有的是动作级规划（决定每一步具体调用哪个工具），还有的是参数级规划（决定工具的参数怎么填）。分清了粒度，才谈得上设计。

第二，会主动谈失败恢复。一个完整的规划系统离不开"计划赶不上变化"的应对方案。通过的人几乎不需要我问，就会主动提到：子任务失败之后怎么办、重试几次、是否降级、是否需要重新规划。这说明他踩过真实的坑。

第三，能讲出选型的理由。为什么这个场景用 ReAct，那个场景用 Plan-and-Execute？他能从 Token 开销、任务长度、错误恢复成本这些维度去解释，而不是背概念。这一条基本是最有区分度的。

2. Agent 规划的底层框架：先理清三层结构

2.1 目标层：从模糊指令到可验证里程碑

我跟候选人讲规划的时候，喜欢先让他们把"规划"这个词拆成三个层面来看，第一层是目标层。

目标层要解决的问题是：用户给了一句模糊指令，你怎么把它变成一组可以被验证的目标。比如用户说"帮我安排下周去出差"，这句话直接扔给执行器是没法干的，因为你不知道出差的目的是拜访客户还是参加活动，不知道预算范围，也不知道时间约束。目标层要做的是通过澄清问题、检索背景信息、结合用户历史偏好，把这句话转化为"在下周内完成出发地和目的地之间的往返安排，总预算不超过 X 元，住宿标准为经济型"这样的里程碑式目标。

可验证很重要。一个目标如果不能被检查是否完成，那后面的规划就是空中楼阁。你在设计目标分解结果的时候，一定要给每个子目标配上验收条件。比如"完成机票预订"的验收条件就包括：有具体的航班号、出发时间和出票凭证。这样规划器和执行器才能做到"有据可依"。

2.2 策略层：在行动空间中选路

第二层是策略层。目标层给出了"要去哪"，策略层回答"怎么走"。这一步我常用开车导航来类比：导航要做的事情不是告诉你每一步踩多少油门，而是在整个道路网络里选出一条从起点到终点的路径，并在路程中根据路况调整。

在 Agent 里，策略层面对的是一个行动空间，这个空间的每个节点都可能是"调用一个搜索工具""执行一段代码""运行一个子智能体"或者"向用户确认一个问题"。策略层的核心工作是搜索并选择一条行动序列，同时考虑约束条件，比如时间开销、Token 成本、工具权限、任务优先级。

这里有个很多候选人容易漏掉的关键点：策略层要能回答"为什么选这条路"。也就是说，规划系统最好保留决策依据，哪怕只是一段简短的推理摘要。这不仅是为了可解释性，更重要的是当后续执行失败时，你可以通过回溯决策点找到问题出在哪一个判断上。没有决策依据的规划，一旦出问题就是一笔糊涂账。

2.3 执行层：算子、工具与状态管理

第三层是执行层，也是直接被大部分人当成"规划"的那一层。执行层做的事情是把策略层选定的行动序列翻译成具体的工具调用、代码执行和 API 请求，并管理整个过程中的中间状态。

执行层的核心设计对象是算子（Operator）。一个算子就是一个最小执行单元，比如"读取文件""调用搜索""发送邮件""计算数值"。算子之间要有清晰的输入输出协议，这样它们才能被灵活编排。我看到不少新手团队在做 Agent 时，每个工具函数的签名千奇百怪，参数有的是 JSON 字符串、有的是字典、有的是纯文本，这种系统是没法支撑复杂规划的，因为规划器的输出没有办法稳定地翻译成算子调用。

状态管理更是执行层的命脉。Agent 跑一条任务链，中间会产生大量中间结果，这些结果必须被记录和传递。我见过一个很典型的失败案例：某个会上网搜索资料并汇总报告的 Agent，它的规划器不停地把前面搜到的信息塞回上下文里继续推理，结果上下文越撑越长，模型开始遗忘了最初的指令，最后生成的报告完全跑偏。如果执行层有一个外置的状态存储，把中间结果放在规划模块之外、按需读取，这类问题就可以避免。

3. 从零设计一个规划模块：输入协议、任务分解与动态重规划

3.1 规划器的输入输出协议：拒绝黑盒

如果把规划器当成一个独立模块，它的输入和输出必须被严格定义。输入通常包含四部分：澄清后的目标描述、可用工具的清单及能力说明、当前状态上下文、约束条件（预算、时间、权限）。输出则不应该是一段自然语言，而应该是一个结构化的计划对象。

我习惯用 JSON 来表示计划对象，下面是一个简化的示例：

{ "goal": "收集竞品A、B、C的价格信息并生成对比日报", "subtasks": [ { "id": "task-001", "type": "crawl", "target": "https://example.com/products", "depends_on": [], "success_criteria": "获取商品名称、价格、库存字段", "fallback": "尝试切换爬虫策略或使用缓存数据" }, { "id": "task-002", "type": "parse", "target": "task-001 的输出", "depends_on": ["task-001"], "success_criteria": "解析出结构化表格，无缺失字段", "fallback": "使用 LLM 兜底解析" } ], "parallel_groups": [["task-001", "task-004"]], "estimated_cost": { "max_tokens": 50000, "max_time_seconds": 300 } }

规划器输出这种结构化计划的好处是：执行器可以逐条消费，如果某一步失败可以精确定位到对应节点；调度器可以依据depends_on决定并发策略；监控系统可以统计每个子任务的耗时与成功率。这比"返回一段自然语言计划"要可靠得多。

3.2 任务分解的粒度怎么定

任务分解的粒度是规划器设计里最容易被忽视的问题。拆得太粗，子任务内部仍然是一个复杂问题，单次推理搞不定；拆得太细，子任务数量暴增，调度开销和错误率都会上升。

我提供一个经验法则：每个子任务应该满足三个条件，一是输入输出边界清晰，二是可以在一到两次模型调用内完成核心动作，三是失败后有明确的备选路径。如果一个子任务还需要再进行一大轮逻辑判断才能完成，那说明它拆得还不够细；如果一个子任务只是"调用 get_price 函数获取价格字段"这种纯机械操作，那它就不应该作为规划器的一个节点，而应该作为算子的内部逻辑。

另外，任务分解时要注意广度优先还是深度优先的问题。在大多数业务场景中，我推荐先做一个深度较浅的分解，把主干路径跑通，再在具体节点上做二次细化。这样设计可以保证失败发生时不会导致整个规划推倒重来，你只需要对局部子任务做增量重规划。

3.3 动态重规划：世界模型、触发条件与增量调整

静态规划在真实环境里活不过五分钟，因为外部世界不会按你的计划走。所以规划模块必须支持动态重规划，这需要三个配套组件：状态感知、触发条件和重规划策略。

状态感知的意思是 Agent 要有一套"世界模型"的近似实现。它不需要像科幻电影里那样预测整个世界，只需要对当前任务的执行效果有一个估计。比如"调用搜索接口之后，预期返回十条结果"，实际只返回了两条，这就说明世界状态与预期偏离，需要触发调整。

触发条件要区分轻重级别。轻微偏离（返回结果略少、单次延迟变高）可以继续执行；中等偏离（依赖的工具不可用、数据格式严重不符）需要对当前子任务做局部重规划；严重偏离（目标本身冲突、权限被完全拒绝、用户中途改需求）就必须暂停整条任务链并上报人工。

重规划策略上我强烈建议做增量重规划，而不是全量重规划。全量重规划的代价非常大，它可能把已经完成的前序工作都打乱，产生新的错误。增量重规划是只对失败节点及其下游节点重新计算路径，上游已经完成的结果保留有效。这一设计能让 Agent 在长任务中保持稳定，不会动不动就"从头再来"。

3.4 一个数据采集 Agent 的规划模块设计示例

把上面这些原则串起来，我举一个完整的小案例：设计一个每天自动采集竞品价格数据的 Agent 规划模块。

目标层要做的事情是识别"采集价格并生成日报"的真实意图，它包含的范围有数据源列表、采集频率、价格字段口径、日报的接收人列表。策略层要决定：先采集哪些站点、哪些站点可并行、数据清洗放在什么节点、日报生成放在最后。执行层要维护的关键状态包括：target_urls、max_pages_per_site、retry_count、collected_samples、failed_urls等。

这个 Agent 的规划器中有一个调度队列，按照站点分组做并发采集，每个站点的子任务之间相互隔离。如果一个站点连续三次返回反爬验证码，规划器会将该站点标记为"需人工处理"并跳过，而不是让整个任务失败。最后日报生成时，会在显著位置标注哪些数据源采集失败，方便人工核对。像这样的设计，在面试里说出来的效果远好于"我调用了爬虫工具把数据拿回来生成个报告"这种一句话描述。

4. 面试官真正想听的是：规划与反思、执行、工具的闭环

4.1 ReAct 范式里的规划是隐式的

现在学术界和工业界讨论 Agent 规划时，绕不开 ReAct 范式：Reasoning 和 Acting 交替进行。但很多候选人没有意识到，ReAct 里面其实没有独立规划器，它的规划是隐式的，分散在每一次推理轨迹里。

你可以把 ReAct 理解成一个"边想边做"的过程：模型观察当前状态，生成一个 Thought（推理），然后决定 Action（行动），观察 Observation（结果），再进入下一个 Thought。规划在这里不是一次性生成的完整计划，而是每一步决策的累加。它的优势是灵活，遇到意外情况时可以随时修正方向，不需要预设太多结构；但它的劣势也很明显——任务链长了以后，模型很容易迷失在局部细节里，忘记全局目标。

我在面试里不会直接否定 ReAct，我会看候选人能不能说出它的适用边界。ReAct 适合工具数量少、步骤短、环境动态性强、需要快速应变的任务。如果你让它去执行一个需要五十步才能完成的数据加工流水线，它大概率会中途跑偏。

4.2 Plan-and-Execute：计划与执行解耦

与 ReAct 相对的，是 Plan-and-Execute 架构。这个架构把规划器（Planner）和执行器（Executor）拆成两个独立组件，先由规划器生成完整计划，再由执行器逐步执行，执行过程中可以由反思器（Reflector）或切换器（Switcher）分析执行结果，决定继续原计划还是触发重规划。

这种解耦最大的好处是全局可控。规划器可以基于完整目标做长视野规划，执行器则不需要每次决策都消耗大量推理。你可以单独监控每一步的执行质量，可以在计划层面做优化，也可以把规划器替换成不同的模型而不会影响执行器。代价是它的灵活性不如 ReAct，遇到计划外的情况必须走"执行-反思-重规划"这条更重的链路，响应速度会慢一些。

如果你做一个需要长时间运行、步骤明确、容错要求高的业务 Agent（比如自动化的报表生成、批量数据处理、流程自动化），Plan-and-Execute 几乎是标准选择。面试里说出这一点，再加上"我为什么不用 ReAct"的对比，就会显得非常有架构判断力。

4.3 Tree of Thoughts：把规划当成搜索问题

还有一个值得提的范式是 Tree of Thoughts，也就是树状思考。它在每一步生成多个候选思路，保留多条探索分支，在分支上做评估和回溯。

ToT 的本质是把规划看成一个搜索问题，它假设当前状态有很多种可能的下一步，Agent 需要同时评估它们。它适合那些搜索空间大、有明确打分函数、需要反复权衡的任务，比如数学推理、创意生成、策略博弈。但在实际业务 Agent 里，ToT 用得相对少，因为成本非常高：每条分支都要消耗模型推理，还要设计可靠的评估器，否则分支选择就成了碰运气。

候选人面试时提到 ToT 是加分项，前提是能说清楚它和 ReAct、Plan-and-Execute 的本质区别。我常听到的错误说法是"ToT 就是让模型多想几条路径"，这个表述太表面了。真正的关键在于 ToT 引入了"显式的搜索树 + 分支评估 + 回溯"，这是另外两个范式不具备的。

4.4 三种规划范式怎么选，一个实用的对比表

很多候选人会问：面试时把三种范式的优缺点背下来够不够？我的答案是，光背不够，你得给出选型逻辑。下面是我在项目里常用的选择框架，同样适合在面试中作为论述结构。

我实际做项目时通常不会只用一种范式，而是做混合：粗粒度任务用 Plan-and-Execute 搭骨架，每个执行节点内部再用 ReAct 处理需要应变的小步骤。比如一个市场调研 Agent，整体框架是"拆解调研维度–并行采集–交叉验证–生成报告"，其中"采集"节点内部就会用 ReAct 应对各种反爬、页面改版和无效数据的情况。这种混合式回答在面试官那里的效果，通常比单纯背任何单一范式都好得多。

5. 现场推演：45 分钟把会议纪要 Agent 的规划模块讲透

5.1 拆目标：从一句话到任务图

面试中如果前面聊得顺利，我一般会追加一道设计题。曾经我给出过一个很经典的场景：假设公司要做一个会议纪要 Agent，它每天自动进入各类语音会议室，录制并转写讨论内容，最后输出结构化纪要和待办事项。请你在白板上设计它的规划模块。

这道题大多数候选人的第一反应是往算法细节上跑，讨论用什么语音识别模型、怎么处理说话人日志。但真正的高手会先做目标分解。一个会议纪要 Agent 的完整目标集包括：会议音频获取、音频转写、说话人分离、内容摘要、待办抽取、纪要格式化和分发。这六个子目标之间有明确的依赖关系，比如摘要必须依赖转写完成，待办抽取则需要结合摘要和原文两个输入。

如果你能现场把这些子目标画成一个 DAG（有向无环图），标清楚depends_on关系，那就已经领先大多数候选人了。因为它证明了你能把一个模糊需求工程化，我甚至不需要你再往下细化，就已经在考察清单上给你打了高分。

5.2 定机器：规划器的状态机设计

任务图画完之后，下一步是做模块内部的状态机设计。我会抛出一个引导：如果转写这一步成功了，但摘要生成时模型幻觉严重，你的系统怎么感知、怎么处理？

好的回答会设计一个状态字段，比如meeting_pipeline的枚举状态可以是：pending、transcribing、summarizing、reviewing、done、failed。每个状态都有对应的输入条件和输出校验规则。转写失败的节点会被放入failed队列，并触发重试或降级策略；摘要生成如果通过关键词覆盖率的规则校验，就会被送去人工审核队列。

这部分的要点是让候选人展示系统心智，而不是只盯着模型能力。规划模块不只是"生成一个计划"，它还是一个状态机，负责在整个生命周期内维护任务的推进、暂停、失败和恢复。如果你能把这个状态机在纸上画得明明白白，面试官基本能看到你真正落地过类似系统。

5.3 谈风险：失败类型与处理预案

做设计题时，主动谈风险是加分最多的行为。很多候选人只会设计 happy path，也就是一路顺利直到完成，完全不管中间出问题怎么办。真正的生产系统，happy path 只占用户实际体验的一小部分。

针对会议纪要 Agent，我会建议至少列出四类失败并给出预案。第一类，音频质量太差或转写结果空，预案是标记该会议转写质量不足，纪要中保留音频原文链接供人工参考。第二类，说话人日志无法区分，预案是切换为匿名的角色标签，比如"发言人A""发言人B"。第三类，待办抽取结果信息量过低，预案是回退到摘要原文并人工提取。第四类，分发环节权限校验失败，预案是跳过发送并通知管理员处理。

这些预案不是拍脑袋想出来的，它们来自真实运行中的 Agent 系统的边界条件。你在面试中能主动讲出这些，面试官会默认你有线上经验。这个心理效果比任何自我介绍都有用。

5.4 亮指标：怎么评价规划做得好不好

最后我会追问一句：你怎么评估这个规划模块做得好不好？如果候选人只能说"看任务完成率"，我会觉得比较单薄。我期望的回答是把指标拆成几个维度。

第一个是规划完备度，也就是计划里列出的子任务数量与实际执行所需的子任务数量的比值，越高说明规划器越能提前看全问题。第二个是无效动作率，Agent 执行过程中有多少工具调用是空转的、产出为空的，这个指标直接反映规划器选路的精准度。第三个是重规划次数，单条任务链中触发重规划的平均次数，这个数值不是越低越好，但要能解释每次重规划的原因。第四个是业务指标，比如会议纪要的准确率、待办被用户采纳的比例。只有把技术指标和业务指标放到一起看，才能真实评价一个规划系统的价值。

这些维度一摆出来，面试官立刻能感受到你是有过后期跟踪和调优经验的，不是写完规划功能就交付不管了。

6. 追问环节：三个高频刁难问题怎么接

6.1 追问一：子任务失败怎么办

这个追问几乎百分之百会出现，回答的好坏直接决定最后评价。最基础的回答是"重试几次，还不行就跳过"，这只能拿及格分。

我会建议候选人把失败类型先分类。第一类是瞬时故障，比如网络抖动、接口超时，这种用指数退避的重试策略就可以。第二类是确定性失败，比如工具不存在、参数格式错误，这种重试一万次也没用，应该直接检查算子的输入协议并修正调用链。第三类是业务规则不满足，比如搜索结果为空、用户权限不足，这种应该降级到备选方案，或者主动上报人工。

回答这类问题时，如果能带上一个你真实经历过的失败案例，那说服力会非常强。比如你说"我之前做过一个舆情分析 Agent，遇到过某个数据源改版导致解析全部失败，后来我在规划器里加了一个数据源可用性探针，每次执行前先做一次轻量探测"，这比任何理论论述都更容易让面试官记住你。

6.2 追问二：你的规划能处理多长的任务链

这个问题考的是对现实约束的理解。很多候选人的第一反应是"我的模型上下文有 128K，所以应该没问题"。这其实是一个典型的误区。上下文长不代表模型能在超长任务链里保持稳定的规划质量，而且长任务的错误是累积的，步骤越多，越容易出问题。

合适的回答方向是把任务链从"单次上下文"中解放出来。你可以说：规划器把计划存储为外部结构化数据，每一步执行结果写入外置存储，模型每次只需要读取相关片段，而不是带着完整历史工作。周期性地做全局回顾，比如每完成五个子任务就重新审视一次当前进度与原始目标的偏差，这样既保证长任务的方向感，又不会吃满上下文窗口。

我还会补充一点：长任务链真正要解决的是错误隔离，而不是长度本身。如果一个子任务出错会连锁影响后面二十个子任务，那这个系统本质上是不稳健的。所以你在设计时应尽量让子任务之间的耦合最小化，每个子任务只依赖上游一份明确的输入，出问题就只影响局部。

6.3 追问三：怎么评估一次规划的优劣

最后一个追问往往是想看你有没有一套自己的评估方法论。除了前面提到的规划完备度、无效动作率、重规划次数和业务指标，还有一个更隐蔽的角度：规划决策的可解释性。

我会刻意问候选人：如果两个模型都完成了同一个任务，你怎么知道哪个模型规划的"质量更高"？很多候选人答不上来。实际上你可以引入一个干预测试：把规划器生成的计划拿给一个不参与执行的人看，问他在每一步开始之前，是否理解"为什么 Agent 决定做这件事"。如果一份计划需要事后补充大量背景才能讲通，说明它的决策依据记录得不完整，这样的规划器即使任务完成了，也很难迁移到新场景里。

这个视角在面试里很加分，因为它代表你已经不是从"模型能不能做"的角度思考问题，而是从"系统能不能被理解和维护"的角度思考问题。后者才是高级工程师和普通开发者之间真正的差距。

最后说一点我个人偏好。做了这么多轮面试之后，我发现这道题最终会回到一个很朴素的判断上：候选人有没有把一个模糊的需求变成一套可执行、可观测、可恢复的机器流程的能力。规划的本质就是这件事。如果你正准备去面 Agent 方向的岗位，我给你的实际建议只有一条——不要只看论文和博客，自己找一个任务，从零开始实现一个带规划模块的 Agent，让它每天自动跑一遍，记录失败和重规划的原因。你只要跑过一个月，这道题你自然就会答了。有些经验，是坐而论道学不来的。