Agent规划面试题深度拆解：从原理到工程落地的系统指南

最近我帮团队做技术面试连着面了一批候选人简历上清一色写着大模型应用开发、Agent 相关项目经验。但当我把Agent 怎么做规划这道题抛出去十个人里有八个让现场气氛陷入沉默。有的人背了一串名词把 ReAct、Plan-and-Execute、AutoGPT 说了一遍再往下追问一句那你的系统里重规划是怎么触发的就接不上话了。这其实是一个非常典型的现象大家看了很多 Agent 的科普文章也调过几个大模型的接口但真正把规划当成一个系统工程问题想清楚的人很少。这道题之所以淘汰率高是因为它表面问的是你知不知道 Agent 会规划实际考察的是你有没有亲手设计过一个能稳定工作的规划模块。面试官的潜台词是给我讲讲你如何在代码层面把 LLM 的一次次推理变成一条可靠的任务执行链路。这篇文章我就把这道题拆开讲清楚包括规划的本质、两条主流技术路线、任务拆解的方法论、真实的模块设计细节以及面试现场可以直接拿来用的回答框架。1. 面试官问Agent 怎么做规划到底想听什么先别急着背概念。我作为面试官看到候选人简历上写了 Agent 项目又抛出一道规划题我的真实目的只有一个区分调包工程师和系统设计师。你是否有能力理解自己在做什么而不只是知道在用什么。1.1 表面在问名词实际在问系统这道题最常见的错误答法是Agent 的规划就是让大模型自己拆解任务比如用户说要订机票它就把任务拆成查航班、比价格、填订单、付款。这种回答我只能给出一个礼貌的微笑。因为它描述的是规划的效果不是规划的机制。面试官想知道的是拆解任务之后你打算怎么执行步骤之间如果有依赖关系怎么办某一步执行失败了你的 Agent 是直接停下来还是带着错误信息重新规划你设计的规划模块是一次性生成一个完整计划还是允许在执行过程中边做边调整这些都不是名词解释能覆盖的问题而是一个完整的系统设计问题。我经常用一个比喻来提醒候选人Agent 的规划模块就像现实中的项目经理。项目经理拿到一个模糊目标之后要做的是把它拆成排期、分配资源、设定里程碑、处理风险。面试官想听的不是项目经理很会拆任务而是你如何设计一套流程让项目即便有人请假、需求变更、工期延误也能把活干完。1.2 三个递进层次大部分人只答到第一层按照我的观察面试回答的深度通常分成三层。第一层是概念层能说出 ReAct 是推理加行动、Agent 会自主规划这一层大概能拿到 30 分。第二层是系统层能讲清楚规划器的状态流转、重试机制、工具调用的参数生成这一层能拿到 60 到 70 分。第三层是工程层能说出你实测中遇到的失败模式以及你为什么在某个场景下没选某种方案这一层才是区分度所在。80% 的候选人倒在了系统层。原因很简单他们只在 Demo 里见过 Agent 跑通一顿操作没见过生产环境里 Agent 是怎么在二三十次工具调用后依然不失控的。所以这篇文章真正想帮你补的是第二层和第三层。1.3 隐藏考点对 LLM 能力边界的理解再往深处说这道题其实在考察你对大模型能力边界的认知。如果一个人认为 LLM 是万能的觉得把任务扔给它就能自己规划自己执行那他一上来就输了。真实的 LLM 在规划上能力是很不稳定的它可能把订酒店拆成打开浏览器输入网址点击搜索拆得过于琐碎也可能把两个本应串行的任务设计成并行完全忽略了现实约束。所以一个成熟的规划模块设计核心思路是别让 LLM 自由发挥太多要把它的不可靠性通过工程手段兜住。比如限制规划输出的格式、对计划做规则校验、引入人工确认环节、对执行失败做重规划。你把这些边界设计讲清楚了面试官就知道你是真的跟 Agent 打过交道而不是只看过几篇热门文章。2. Agent 规划的两条主流技术路线先排期还是边干边想聊到具体方案目前业界广泛使用的规划路线主要有两条一条是管线式规划业内叫 Plan-and-Execute另一条是循环式规划以 ReAct 为代表。面试的时候把这两条路讲透比列十个名词有用得多。2.1 管线式规划像做项目排期表管线式规划的思路非常直观启动任务时先让 LLM 生成一份完整的多步骤计划然后按计划逐步执行。这份计划可以是一个列表每一项包含步骤描述、输入输出、依赖的工具。执行器拿到这个列表后逐项推进执行完当前步骤再进入下一步。这种方式的好处是稳定。整个执行路径在开始阶段就清晰可见你可以提前做步骤合法性校验可以给用户展示完整规划让用户确认也可以很方便地把每个步骤的输出记录下来用于审计。在那些任务边界清晰、步骤顺序基本固定的场景里这种方法非常舒服。但它也有明显的短板一旦中间某一步的结果和预设不一致后面整条计划都可能失效。我做过一个实际项目任务是自动收集某个流程的数据并生成报告。前几步执行得都很顺利但到第三步需要的某个接口突然换了返回格式后续的所有步骤全部失去了意义。碰到这种情况Plan-and-Execute 就非常僵硬要么把这一步的结果喂给 LLM 重新编一份新计划要么就得设计复杂的回溯机构。2.2 循环式规划像开车时随时调整方向ReAct 走的是完全不同的路线它不先预设完整计划而是一次只走一步。整个循环是Thought当前状态分析→ Action调用工具或进行推理→ Observation观察工具返回结果→ 再 Thought基于新观察重新分析→ …… 直到最终给出答案。这个模式的本质是让规划和执行深度融合。你不需要提前预测后面十步会发生什么只需要根据当前掌握的信息决定下一步怎么走。这在那些探索性极强、路径不固定的任务里优势巨大比如让 Agent 从一个结构化网页里找出一条满足多个条件的信息或者做一轮需要反复试错的数据清洗。代价是稳定性和成本控制变差。Agent 可能绕半天圈子找不到出路整个循环陷入死循环也可能调用十几步工具却什么都分析不出来Token 消耗和接口调用费用都非常可观。所以真实项目里一般会给 ReAct 循环加最大步数限制超过上限强制退出再让 LLM 基于已有信息重新规划。2.3 两种路线怎么选三个维度做决策面试时如果能给出清晰的选型逻辑会显得你非常有经验。根据我的实践可以从三个维度来权衡。维度Plan-and-Execute管线式ReAct循环式任务路径确定性高路径可预先推演低需要边做边探索环境变化频率低外部依赖相对稳定高中间结果不可预测Token 与费用控制好计划阶段消耗集中在一次差循环过程消耗难预估可解释性好计划可提前展示给用户中过程需要逐步骤解释失败恢复僵硬需要整段重规划灵活观察后即可调整下一步我的经验是如果一个任务你在拿到需求时就能写出大致的操作手册哪怕写得不精确优先用 Plan-and-Execute如果一个任务你在开始前根本不知道要查几次才能查到结果那就用 ReAct。很多成熟系统实际上是把两者混用主路线用 Plan-and-Execute单个复杂步骤内部再嵌套一个 ReAct 循环这也算现在业内比较主流的设计。3. 规划的真正难点把目标拆成任务、动作和工具调用明确路线之后接下来就是具体的拆解设计了。很多候选人喜欢说让 Agent 自己拆任务但这句话等于没说。你要能讲清楚目标是怎么变成任务列表的任务列表里的每一项粒度多大每一项对应哪个工具调用如果工具参数生成出错了怎么办3.1 一个贯穿全文的例子三天两夜旅行规划为了把这些问题说透我用一个在面试里经常出现的场景来举例给 Agent 安排一个任务帮用户规划一次三天两夜的旅行预算五千块钱重点是美食和轻松体验不要赶景点。如果让一个不做规划的裸 LLM 直接回答它会给你一篇文章式的建议完全没法执行。但 Agent 的规划模块需要把它变成类似下面的计划第一阶段任务分解根据用户偏好将规划旅行拆解为目的地选择、交通规划、住宿预订、美食路线规划、日程安排五个子任务。第二阶段动作编排为每个子任务绑定工具比如机票比价工具酒店搜索工具本地美食推荐接口地图路线计算工具。第三阶段依赖分析明确先后关系只有确定了目的地之后交通和住宿才能并行搜索只有确定了住宿位置之后美食路线才方便规划。第四阶段边界确认检查预算是否与行程冲突如果酒店费用太高送回重规划触发预算调整。这一步真正的价值在于把规划拆成了四个动作任务分解、动作编排、依赖分析、边界确认。面试官想听的就是这四个动作在你脑海里要有一个清晰的顺序而不是笼统的一句拆成五步。3.2 任务拆解时最容易犯的三个错我见过很多 Agent 项目在任务拆解环节栽跟头犯错的方式几乎一样。第一个错是粒度不均有些步骤拆到点击按钮这种原子操作有些步骤却是一个需要十次工具调用的大任务。粒度不均会让执行器和后续的失败重试都很难设计因为你没法为每种粒度分别定义成功率。第二个错是忽略依赖关系。旅行规划中根据住宿地点规划美食路线和先预订住宿之间有严格的先后关系但 LLM 在生成计划时经常把这种依赖当作并列关系。所以我一般在设计规划 Prompt 时会强制要求 LLM 输出每个任务的依赖条件字段再用代码做一次校验如果发现某个任务依赖的前置任务还没出现在计划里直接让 LLM 重新生成。第三个错是缺少可验证的完成标准。任务清单里只写搜索酒店是不够的你还得定义什么叫搜索完成。是返回搜索结果给用户就算完成还是完成比价后直接推荐一个最优选项没有这个定义执行器在循环里很容易卡在生成结果和判断结果是好是坏这两个环节之间打转。3.3 工具层规划LLM 如何把任务变成参数任务拆解完之后还需要有一个阶段把任务翻译成具体的工具调用。这里最核心的技术细节就是函数调用Function Calling机制。比如搜索符合预算的酒店这个任务LLM 在规划阶段就要把它转成类似这样的调用意图调用 search_hotel 工具参数是 city, date_range, budget_low, budget_high, preference_keywords。这里最容易出问题的是参数幻觉。LLM 可能会编造一个城市名或者把预算单位算错甚至把目的地写成一次旅行中的某家餐厅名。我的常用做法是三层防护第一层在工具定义里写清楚每个参数的类型、范围和示例值减少模型自由发挥空间第二层在调用前用 pydantic 这类库做 schema 校验参数类型不对直接拦截第三层对调用结果做一个语义校验比如判断返回结果是否真的与查询意图匹配。这三层用完工具调用这一环才真正可靠。4. 一个真实规划模块的设计状态、重试与重规划如果面试进行到这里你已经把两条路线和拆解逻辑说清楚了接下来的加分项就是讲一个真实模块的设计细节。我拿之前做过的一个跨平台智能助手项目来举例这个项目的核心功能是帮用户完成多步骤事务办理规划模块是整个系统最关键的组件也是踩坑最多的地方。4.1 规划器的核心状态从 IDLE 到 DONE我们一开始把规划器当成一个简单的LLM 调用循环来实现结果很快就发现了问题执行次数一多整个服务就没法控制了。后来我们重新设计把规划器当成一个状态机来管理。核心状态大概有这么几个IDLE等待新任务系统空闲PLANNINGLLM 正在生成整体计划WAITING_CONFIRM计划已生成等待用户确认或修改EXECUTING正在按计划执行当前步骤WAITING_TOOL等待外部工具返回结果REPLANNING发生失败或计划偏差LLM 正在重新生成计划FAILED到达最大重试次数任务终止DONE所有步骤执行完成产出最终结果这个状态机的好处是你可以在任何状态下对系统做干预。比如用户在中途说取消、改预算、换目的地你不会在一个深度的循环里手足无措而是可以通过状态切换安全地回到 PLANNING 或 WAITING_CONFIRM。面试的时候能把这段讲出来面试官就知道你处理过真实场景。4.2 重规划机制什么时候触发、怎么触发重规划是这个模块的心脏。为了讲清楚它的必要性我举一个特别典型的案例有个任务需要调用某政务类查询接口正常流程是查完 A 再查 BB 依赖 A 返回的编号。有一次 A 返回的数据里没有编号字段整个后续链条就断了。当时我们设计的处理办法是这样的。第一EXECUTING 阶段一旦捕获到工具报错或者关键字段缺失不直接让整个任务失败而是把错误信息原封不动地整理成文本连同当前任务步骤的历史上下文一起送到 LLM 那里。提示词大概是当前计划第 3 步执行失败失败原因是……目前已经做到第 3 步已获得的信息有……请重新规划后续步骤。第二给重规划加一个最大次数限制。我们当时设置的是两次。加上第一次原始规划一个任务最多经历三次规划。超过这个次数说明这个问题可能真的超出了模型的规划能力再让它尝试只会烧钱不如直接进入 FAILED 状态并通知用户。第三重规划之后必须做计划差异校验。我见过太多次 LLM 重规划之后把已经执行完的步骤又重新来一遍比如用户已经确认了预算重规划之后又生成了一个超预算的方案。所以重规划之后要把新计划和旧计划做对比检查是否违背了用户已经确认的关键条件。4.3 状态持久化中断恢复与用户修改最后一个值得讲的细节是状态持久化。Agent 任务一般都比较长中途可能遇到服务重启、用户关闭页面、切换设备。我们当时把所有状态序列化成了 JSON每完成一个步骤就写入存储。这样做有一个很实际的收益用户可以在第二天重新打开应用Agent 能接着昨天的进度继续执行而不是把所有任务从头再来一遍。这个功能对真实用户非常友好。毕竟让用户看着 Agent 白白重复已经做过的操作是很糟糕的体验。持久化设计还有另一个作用就是支持用户修改需求。比如用户看了一眼生成的计划说第二天的行程我不想安排太满。你把当前计划的第 5、6 步标记为待重排这两个步骤的内容和约束条件一并喂给 LLM重新生成一小段计划插入原来的位置。这个操作比整体重规划省得多也明显更可控。5. 面试中三个翻车回答以及怎么把它们变成加分项说完了方案设计我们回到面试现场本身。我在面试时收集了不少真实的翻车回答这里拿出三个最常见的讲讲为什么会翻车以及怎么从一个被动回答变成加分项。5.1 翻车一ReAct 就是让模型推理加行动这个回答没有错但也没有信息量。如果候选人只答这一句我一追问你的循环终止条件是什么如果工具一直返回空结果怎么办他就答不出来了。正确的答法要把它展开成一个完整的循环控制逻辑。你可以这样说ReAct 本质上是一个 while 循环循环体是根据当前观察进行推理→选择动作→调用工具终止条件一般是两个要么模型自己输出了 Final Answer要么执行步数到达了系统预设的上限。如果到达上限还没得出结论我们会把已收集的信息作为上下文让模型尝试生成一个尽量完整的答案或者进入人工处理流程。这一套讲下来同一个名词的含金量完全不同。5.2 翻车二我们项目直接用开源框架的 Agent 就行很多候选人一听到规划问题就想到自己常用的那套开源 Agent 框架然后开始背框架文档。面试官问的是你的设计思路不是框架说明书。而且开源框架默认的规划行为在真实业务里几乎都需要大量定制因为框架根本不知道你的工具会返回什么格式的数据。如果你确实用了某个框架正确的答法是讲清楚你做了什么定制。比如说框架默认的 AgentExecutor 执行完一步就直接进入下一步但我们的业务里某几个工具会返回临时性的失败码需要重试三次。因此我改造了执行器加入了针对特定工具错误码的重试逻辑又比如说框架默认的 Agent 不会提前给用户展示计划我在外层套了一个 Plan 确认节点把计划发给用户用户确认后再进入执行循环。讲到这里框架只是一个载体你本人的设计能力才是核心。5.3 翻车三规划就是让 LLM 输出一个 JSON 计划这个说法让我哭笑不得。它把规划的落地点说对了但把规划的复杂度严重低估了。LLM 输出 JSON 只是整个规划流程里非常靠前的一小步真正的挑战在于这个 JSON 生成之后。我一般会继续追问这个 JSON 里可能包含一个不存在的工具名你怎么校验某个步骤的依赖字段指向了一个后面才出现的步骤你怎么处理这些都要答出具体的解法。比方说我们会拉一份工具清单做本地匹配会校验依赖关系的拓扑排序是否合法会把计划里的步骤数量和预计工具调用次数加起来做成本估算超过预算就退回让人工确认。这一层补上之后这个回答才配得上规划两个字。6. 这道题的满分回答框架拆开给你看讲了这么多最后我总结一个可以直接在面试里用的回答框架。只要准备时间允许我会建议候选人用这个框架来组织思路不管面试官从哪个角度切入你都能稳稳地把话术落下来。6.1 三层答题法定义、选型、落地第一层是定义问题用一句话讲清楚你会把 Agent 规划理解成什么。这是为后面所有内容定的基调。我比较推荐的说法是我认为 Agent 的规划本质上是把用户模糊的目标转化为一组有依赖关系、可执行、可验证的子任务并为每个子任务匹配相应的工具和退出条件。第二层是选型逻辑说明在你的场景里你会选哪条技术路线以及为什么。这里最好带上对比权衡突出我没有无脑选择某个方案而是基于我的任务特点做的判断。第三层是落地细节这是区分度最高的部分也是你前面讲的所有内容能否立住的关键。讲一两个你踩过的坑配上你当时的解法面试官就会由心底认可你。6.2 一个两分钟的话术范本假设面试官直接问Agent 怎么做规划你可以这样回答我一般把 Agent 的规划拆成三件事。第一件事是把用户目标结构化也就是任务拆解。拿规划一次旅行举例我会让它生成一个包含子任务、依赖关系、工具绑定、完成标准的计划结构。第二件事是设计执行控制我会根据任务特性选择一次性生成完整计划还是边执行边规划。如果路径比较确定我偏向 Plan-and-Execute如果探索性强我会用 ReAct 循环但会严格控制最大步数。第三件事是安排失败恢复。我的系统里有一个重规划机制某一步执行失败时会把错误信息连同历史上下文交给模型重新生成计划同时限制最多重规划两次防止无限循环烧钱。同时每一步状态都会持久化方便用户中途修改需求或跨设备继续执行。这个回答大概不到两分钟却把定义、选型、落地三层全部覆盖了。面试官后续无论往哪个方向深挖你都有内容可以接住。6.3 面试前值得做的三个小演练最后分享三个我在准备这类面试题时觉得特别有效的演练方式。演练一拿不同复杂度的任务考自己。从帮我查明天的天气到帮我规划一次 7 天的出境自由行逐一走一遍这个任务适合哪种路线需要哪些工具哪些步骤可能失败你怎么恢复这样能把方法论真正内化成自己的思路。演练二手动模拟一遍 ReAct 循环。拿一张纸把自己当成模型写下一步 Thought、下一步 Action、下一步 Observation然后再写下一步 Thought。不要用代码纯粹手动走三轮。你很快就能体会到模型在规划时的纠结感也更理解为什么循环要加终止条件。演练三读一个开源 Agent 项目的规划器源码注意不是看文档是看代码。重点找三个东西它在循环内部是怎么处理异常的它在哪里插入重规划逻辑它的计划数据结构里有哪些字段这三种细节比任何面试题汇总都有价值。我把这道题的回答逻辑完全拆给你了。最近面试下来能把这些内容组织成一套连贯思路的候选人一个巴掌数得过来。绝大多数人缺的其实不是技术而是在项目里没有真正把规划当成一个系统问题去思考也没有花时间去沉淀那些失败经验。面试官一眼就能看出你是背出来的还是做出来的。希望你去刷这道题之前先自己动手把一个规划模块从头到尾设计一遍甚至实现一遍。到那时候你会发现自己再也不会怕面试官问规划的问题了。