最近我在团队面试里加入了这样一道题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 三种规划范式怎么选一个实用的对比表很多候选人会问面试时把三种范式的优缺点背下来够不够我的答案是光背不够你得给出选型逻辑。下面是我在项目里常用的选择框架同样适合在面试中作为论述结构。维度ReActPlan-and-ExecuteTree of Thoughts规划方式逐步隐式推理显式全局计划显式搜索树任务长度适应性短任务较好长任务更稳中等任务视搜索空间而定失败恢复成本低但容易漂移中等可局部重规划高需要回溯分支上下文开销高全程都在推理中计划单独维护很高多条分支并行可解释性中看轨迹高看计划与执行日志高看搜索树与评估分数典型场景对话助手、即时工具调用数据流水线、报表、自动流程数学推理、路径搜索类任务我实际做项目时通常不会只用一种范式而是做混合粗粒度任务用 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让它每天自动跑一遍记录失败和重规划的原因。你只要跑过一个月这道题你自然就会答了。有些经验是坐而论道学不来的。
