Agent 怎么做规划这道题最近在很多团队的技术面里出现频率高得离谱而且一轮面下来能筛掉大部分候选人。我一开始觉得奇怪规划这个名字听着不算难CoT、ReAct、Plan-and-Execute 这些方案网上到处都是随便说两句也能应付一下。但实际面了几个之后我明白了绝大多数人挂在同一个地方他们能把概念名词背得滚瓜烂熟却说不清楚规划到底在系统里怎么落地、挂了怎么办、反馈怎么接。这篇文章我就把这件事掰开揉碎讲一遍。会先拆面试官真正在看什么然后从原理层面讲 Agent 规划的本质再给几种工程实现路径最后用一个数据处理的实操案例把整个闭环跑给你看告诉你实测里会撞上哪些坑。准备面 Agent 相关岗位的人或者在落地 Agent 时总觉得规划这块使不上劲的人都值得看完。1. 面试官拿这道题到底在测什么三个隐性考察点1.1 他首先在确认你是真跑过 Agent还是只在背稿子简历上写熟悉 Agent 开发做过智能体应用的人不少但一问到实际操作就露馅。比如我经常追问你做的任务分解粒度是怎么定的每个子任务大概多少 token如果某一步执行返回的结果和规划假设完全不一致代码怎么处理这些细节光靠看文档是答不出来的只有真实跑过循环、被日志折磨过的人才能接住。这道题之所以能筛掉那么多人恰恰因为它不是考概念记忆而是考你有没有被坑过。一个只背过 ReAct 流程的候选人会流畅地讲出思考-行动-观察的循环但当我问他某个动作连续失败两次你会让模型重试还是换策略时他的回答会变得特别虚。真正落地过 Agent 的人都知道答案是分情况而且每种情况都有对应策略。这一层没有实操经验撑腰编不出来。1.2 他想看你能不能从提示词思维跳进系统思维另一个常见问题是候选人把规划等同于一段精心设计的提示词。每次听到我在 system prompt 里让它先列计划再执行我心里都会咯噔一下。提示词确实是载体但规划在工程上是一个独立模块有明确的输入输出接口有状态管理有异常处理路径。我更希望看到的是类似这样的表达规划器的输入是用户目标加工具清单输出是一组结构化的执行步骤执行器拿到步骤后去调工具把结果反馈给一个校验器校验器决定继续、回退还是重规划。这句话听起来朴素但它把规划器从 prompt 里抽出来了把它当成系统里的一个组件。谁说出这种话我基本能判断这个人写过的 Agent 代码超过一千行。来我画一张不是图而是文字的对比你感受一下差别认知层级候选人常说的话这类回答暴露的问题提示词层我在 prompt 里让它先输出一个计划把模型输出当成规划本身框架层我用了某某框架的 Plan-and-Execute 组件知道有轮子但不清楚内部结构系统层规划器是决策模块要管理状态、接口和反馈回路能把规划当工程问题来设计有意思的是大多数候选人连第二层都站不稳更别提第三层。1.3 他还想确认你知道规划能力的上限在哪里懂规划的人一定同时知道规划什么时候会失效。Agent 规划不是万能的它的上限受三样东西约束模型上下文长度、工具集合的表达能力、任务本身的模糊度。上下文撑不住完整计划的记忆工具太少计划再完美也没法执行任务目标本身就含混不清时规划器只会一本正经地做错误决策。面试官如果把这个追问抛出来他要的是边界感。回答最大化模型能力让它规划得更准是减分项回答我会给规划器加预检机制、加回退策略、加人机确认点才是加分项。说白了考察的是你有没有把 Agent 当成一个会出错的系统来设计而不是当成一个无所不能的魔法盒子。2. Agent 规划的本质把我要什么翻译成我做什么2.1 规划的最小闭环从目标到收敛的六步循环先聊点抽象的。你可以把 Agent 规划想成装修房子没人会在拿到毛坯房的第一天就开始贴瓷砖。你要先拆出水电改造、泥木工、油漆、软装这些大块再排它们之间的先后顺序——水电没做完就刷墙那就是灾难。Agent 规划做的事情一模一样只不过决策者从工长变成了大模型。一个完整的规划闭环包含六个环节目标理解、任务分解、依赖排序、执行、校验、收敛。目标理解搞清楚用户到底要什么结果任务分解把大目标切成分步动作依赖排序决定哪些能并行、哪些必须串行执行就是让 Agent 调用工具去落实校验判断上一步结果是否达到预期收敛则是在任务完成或确定无法完成时把状态收束成一个明确的产物。绝大多数候选人只说到任务分解就停了好像规划等于拆任务。但真正重要的是后面那三步。拆解是计划的第一步而执行后的校验与收敛才是让规划从一张纸变成真实产出的关键。没有反馈机制的规划叫猜测不叫规划。2.2 任务分解的粒度拆太粗跑不动拆太细爆上下文任务分解是规划的核心动作但很少有人讲清楚粒度怎么控制。我见过一个 Agent 规划整理会议室预订记录模型拆出来的步骤是读取数据-找到冲突-生成新时间表-写入备份这粒度合理。但换一个任务让模型拆清理日志文件它有时候会拆出删除超过30天的日志-删除超过60天的日志-压缩剩余文件-更新索引这个粒度就有问题了——如果工具层只有一个clean_logs()接口这些步骤往哪执行粒度的决定因素有三个。第一工具的能力边界每个工具能一次性完成多大事拆解就不能比工具更细。第二单步执行的 token 消耗步骤拆得太细会造成大量冗余的工具往返上下文很快被观测结果塞满。第三任务的可逆性天然风险高的操作比如删除、覆盖、对外发送消息需要拆得更细方便在关键节点插入确认而那些不可逆性弱的只读操作可以合并成大步。命名一个我能反复强化的原则分解的下一层必须对应一个真实存在的工具调用。如果你拆出来的某个子步骤在当前工具列表里找不到落点要么说明工具列表需要扩展要么说明拆解粒度出了偏差需要让规划器重新对齐。2.3 规划成功的关键前提状态同步与工具能力对齐还有一件特别容易被忽略的事——规划器对当前世界状态的认知必须和执行真实发生的环境一致。什么意思Agent 做规划的时候脑子里会有一个关于现状的模型比如数据文件在桌面上服务还没部署数据库连接正常。这些假设如果和实际环境不一致计划再漂亮也是空中楼阁。这就像导航软件。你设置目的地之后导航不是一次性给你一条路就再也不管它每隔几秒接收一次当前位置发现前方拥堵立刻重算。Agent 也应该这样在执行每一步之前通过工具返回值、环境观测把真实状态同步进来然后决定是继续原计划还是必须修改路线。我踩过一个大跟头。某次部署类任务规划器把启动服务排到最后一步但它预设配置文件已经存在于服务器实际上那个文件刚被清理工具删掉了结果整个流程跑到最后一步才报错。从那以后我养成了一个习惯所有 Agent 在正式规划前必须加一节环境预检把关键前提条件一次性验证完。别小看这一步它在真实项目里能省掉大量无意义的返工。3. 规划的实现方案从朴素提示词到分层反射框架3.1 方案一先输出完整计划再逐条执行最朴素的做法是先让模型根据目标输出一整套步骤然后 Agent 逐个执行。这个方案实现起来很快就是把计划输出的步骤解析成结构化列表再放进一个循环里跑。优点显而易见可控、可解释、执行路径透明。但它的短板也很致命整个计划是一次成型的模型在第一步做决策时看不到后续执行的反馈。如果中途某个工具返回了意外结果或者用户临时改了需求原先的计划就全部作废只能从头再规划。所以我把这个方案定义为适合确定性流水线。适合的场景长这样步骤固定、顺序明确、环境基本不变比如拉取数据-格式转换-生成报告-上传到指定目录。如果你的任务有较强动态性单靠这个方案很快会翻车。3.2 方案二ReAct 式边想边做把规划内联进执行循环ReAct 的核心思想其实很简单不要先规划完再执行而是让模型在每个 step 里交替输出思考、行动、观测用想想-做做-看看结果-再想想的循环把任务推完。规划不再是独立于执行的一张大清单而是被掰碎了揉进每一步的决策里。这个方案的优势在于灵活性和即时反应能力。模型能在观测到异常反馈的下一秒就修正方向不需要把整个计划推倒重来。尤其适合以工具调用为核心的中短任务比如查一下某公司的人均产出然后和行业基准对比这一类。代价也不是没有。边想边做的模式缺乏全局视野模型容易被当前这一步的局部信息牵着走忘记了最初的终点目标。常见表现是一开始目标是把数据整理成周报跑着跑着开始纠结某个指标的异常值陷入局部探索最后交出来的东西根本不是最初要的报告。3.3 方案三分层规划加反射最贴近工程实践的方案我最近在工程里用得最多的是第三个方案顶层规划器先把任务拆成若干里程碑每个里程碑内部再套一个 ReAct 式的细粒度循环同时在整个过程中定期插入反射Reflection环节让 Agent 回头检查自己有没有偏离主线。顶层规划负责方向比如先定位数据源、再清洗、再做分析、最后写报告底层执行只负责当前里程碑的若干动作比如检查文件格式、调用清洗函数、输出前十条预览。反射环节每完成一个里程碑触发一次拿当前产出和总目标做比对一旦发现偏移就重设下一段计划。代价是工程复杂度明显上升你要维护计划列表、里程碑状态、反射结果等多份数据。但换来的是可观测性和可恢复性的大幅提升。日志里能看清模型本来想做什么、实际做了什么、回退后改成了什么这对于线上问题排查来说是救命级别的价值。三个方案最直观的对比放在这张表里维度一次性计划ReAct 内联规划分层规划加反射动态响应能力低计划成型后难调整高每步可调整中高里程碑粒度调整全局目标保持好计划里写清楚了差容易局部迷失好反射定期校准上下文开销低高每步都有完整痕迹中可裁剪局部细节工程复杂度最低中最高适合场景确定性流水线交互式工具调用长链路、高容错需求任务4. 实操案例让一个 Agent 完成多步骤数据处理任务4.1 任务设定一个干净但能暴露问题的小场景我设计了一个教学用的实验场景给 Agent 一张销售流水表要求它完成四件事——读取数据、清洗异常值、算每个月的销售额环比、生成一份 markdown 格式的总结报告。工具层面就三样一个读取文件的函数一个调用 pandas 做清洗和聚合的函数一个把结果写入文件的函数。选这个任务的原因很简单足够经典能看到规划器的完整行为又足够简单出问题时能一眼定位。你可以把它理解成一个最小可复现的 Agent 沙盘任何多步骤任务的长链路问题在这个小场景里都会以缩小版的形式出现。4.2 核心代码骨架规划循环到底长什么样这个实验的 Agent 核心循环大概长这样我用简化代码展示结构def run_agent(task: str, tools: dict): state { task: task, history: [], # 执行历史 plan: [], # 当前计划 step_index: 0, done: False, } # 1. 规划阶段根据任务和工具生成初始计划 state[plan] planner.generate_plan(task, list(tools.keys())) # 2. 执行循环 while not state[done] and state[step_index] MAX_STEPS: step state[plan][state[step_index]] # 执行一个步骤调用工具并收集观测 observation execute_step(step, tools, state) state[history].append({step: step, obs: observation}) # 3. 反射阶段判断当前步骤是否达到预期 check reflect(state[task], state[history], state[plan]) if check[status] success: state[step_index] 1 elif check[status] replan: # 4. 重规划根据新观测修订后续计划 state[plan] planner.replan(state[task], state[history], check[reason]) else: # 彻底失败收束状态给用户 state[done] True return {status: failed, reason: check[reason]} return finalize(state)这段代码里的 planner 和 reflect 都是接 LLM API 的调用点。你可以理解成planner.generate_plan 是让模型根据任务和工具列表输出结构化步骤reflect 是让模型基于执行历史和目标判断下一步方向。这个骨架虽然只有二十行左右但它已经把前面讲的最小组件都包括了规划器、执行器、反射器。真实工程里你还会在每一步前后加上 token 统计、耗时记录、日志输出思路是一样的。4.3 实测中撞上的三类典型失败把骨架搭好之后我拿真实数据跑了好几轮记录下了最有代表性的三个坑。第一个坑拆解粒度与工具不匹配。模型把清洗数据这个工具一步能完成的事拆成了删除空行、去重、格式统一三个子步骤而工具列表里根本没有对应的三个函数。规划器写出了一批无法落地的计划。解决的思路是执行前加一步归一化把计划里的每个子步骤映射到真实工具找不到映射就启动一次轻量级的重新规划要求模型压缩粒度。第二个坑执行循环里打转不推进。某个版本里模型在一个步骤上反复调用读取函数每调用一次都重新读取一遍数据观测结果近乎相同但 step_index 一直没变。代码层面必须加两个保险一是每个 step 允许的重试次数上限到达上限强制执行 replan二是给观测结果做一个简单哈希如果连续多次观测完全相同判定为无效循环强制跳转。第三个坑环境前提没有预检。计划排得很漂亮但一开始就没检查销售流水表是否已经上传等到执行到第三步计算月度环比时才报错。这验证了我前面反复强调的那条经验规划器需要预检环节把环境前提条件作为任务的隐式依赖写进计划里或者直接在正式执行前跑一个专用的环境检查动作。这三个坑每一个都很稳定地复现几乎每轮跑都能撞上至少一个。面试时如果能讲出这一段真实经历比你说十个论文术语都管用。5. 没有反馈闭环的规划都是空中楼阁失败模式与工程应对5.1 计划永远赶不上变化环境反馈驱动的重规划很多 Agent 系统死在计划定得太死。理由很朴素——现实世界的反馈永远不可能和你预想的一模一样。工具返回了一个意外格式、某步执行超过预期耗时、用户中途补了一嘴顺便把去年的数据也加进来这些都意味着原计划的一部分不再成立。工程上要把重规划当成一等公民来设计。我的经验是设三个重规划触发条件执行步骤返回值校验失败、观测结果与规划预期不符、任务目标在运行中被修改。每一类触发都要保留下当时的完整上下文——历史步骤、观测结果、当前计划、原始目标——然后把它们组装成重规划的输入让模型产出新的后续计划。注意重规划不是把整个计划都推翻。多数情况下问题只影响后面两步前面已完成的动作是有价值的资产全盘推倒重来既费 token 又丢进度。让重规划器从第 N 步开始修改而不重新生成第 1 到 N-1 步这个约束能在稳定性和灵活性之间取得一个不错的平衡。5.2 无限重试是最贵的错误终止条件怎么定跑 Agent 最容易被忽略也是最伤钱的问题模型宁可死磕也不认输。没有上限的情况下一个失效步骤可以被重试十几次token 烧了一大堆任务还是卡在原地。我在开发初期被这个问题坑过日志里满屏重复的工具调用看了都想关机。现在我在所有 Agent 系统里都强制三套终止策略。第一套是成功即终止反射器明确判定目标达成立即收束。第二套是步数上限终止整个任务的执行步数超过预设值强制停止并给出已产出结果。第三套是低置信终止反射器连续判断无法推进返回一个信号把控制权交还给用户——这一步特别重要它代表 Agent 知道自己不知道。终止的原因必须记录在日志里。不要只记任务失败四个字要记为什么失败是重试超限还是置信度过低还是用户中途撤销。这些终止原因是后续调优的核心依据比任何玄学调 prompt 都靠谱。5.3 长任务中最隐蔽的敌人局部完美与全局迷失跑长链路任务时我见过一种特别讽刺的失败模式每个子步骤都完成得非常漂亮但最终产物跟最初目标七扭八歪。模型沉浸在某一个子问题里把那个局部的细节抠到极致却忘了自己本来要做的是另一件事。比如总结一份行业报告并提取三个投资建议这个任务模型会在总结报告一步上花掉大半上下文把每一页的内容都写进 summary等到要生成建议时才发现已没有输出空间。这就是典型的局部与全局失衡。对策也很直接在里程碑边界强行插入全局复核。每个大阶段结束时单独调用一次反射把已完成的产出与原始目标做一次显式比对输出一段当前进度与目标的关系描述。这一步等于让 Agent 定期抬头看路能非常有效地抑制局部迷失。上下文管理上还要有意识地裁剪历史步骤的细节观测别让早期步骤的冗长输出挤占后面步骤的注意力。6. 面试答案的骨架怎么回答才能让面试官觉得这个人是真会的6.1 不要一上来背框架先用一句话定位问题很多候选人听到Agent 怎么做规划就开始倒背 ReAct、CoT、Plan-and-Execute这是最典型的减分操作。面试官问的是开放题不是填空题他要的是你有自己的理解框架。我建议第一句话就把问题定义一个高度比如规划本质上是个决策问题而不是一个提示词问题。这句话的价值在于它瞬间把讨论从 prompt 技巧拉到系统工程层面。接下来你再展开面试官会下意识用系统设计的标准来听你只要别掉回概念背诵的模式整个回答的层次就立起来了。6.2 一个能撑住五分钟的回答结构我推荐一个分层展开的回答骨架它既完整又好记把规划拆成架构层、策略层、执行层三层来讲。架构层讲模块划分规划器、执行器、反射器各自负责什么它们怎么连接状态怎么流转。这里体现的是系统设计能力。策略层讲粒度与触发条件任务怎么分解粒度怎么对齐工具能力什么情况下重规划终止条件怎么设。这里体现的是权衡能力。执行层讲真实反馈拿一个自己做过的例子讲计划怎么生成、执行中怎么观测、失败怎么兜底。这里体现的是实操经验。三层讲完基本五分钟就过去了而且每一层都踩在面试官的考察点上。还有一个技巧讲执行层时优先讲失败案例。失败案例比成功案例更能证明你真正做过——成功可以编失败编不了。6.3 最减分的回答长什么样以及几个加分动作我把这件事放在最后是因为它的价值被大多数人低估了。减分回答有一个共同特点只讲应该怎么做绝口不提做砸过什么。还有两类也很减分一是把模型能力当方案张嘴就是用更强的模型就能规划得更好二是不谈成本和边界好像 Agent 烧 token 不用钱、失败不用收尾一样。加分动作则刚好反过来。第一能说清回滚逻辑某步失败了我会保留此前的观测结果从失败点之前的最近一个可用检查点重试而不是重头执行。第二能说出实测数据这个任务跑一遍大概消耗多少 token平均几步收敛失败率多少。第三能画清系统流程图——不是让你现场画而是你的表达里要有一个清晰的状态流转路径。我在实际面试里看到过不少简历非常好看的人就在这些细节点上栽跟头。反过来那些看起来没那么花哨、但能把这几个动作做扎实的候选人往往反而是最合适干 Agent 方向的。最后说句掏心窝的话这道面试题真正想筛选的不是谁记住的方案多而是谁真的把 Agent 当成一套会出错、可调试、能兜底的工程系统在理解。能想明白这一层面试过不过反倒是小事了。