★ FEATURED ARTICLE 面试现场我通常会问一句“你做过 Agent对吧那你说说Agent 是怎么做规划的”就这么一个问题在过往那么多场面试里大概能刷掉八成候选人。你以为我在考你概念还真不是。概念背得熟的人照样翻车翻在最基础、最容易被忽视的环节上。这篇我把这道题背后的考点、常见回答的坑、以及一个能体现水平的完整思路拆给你看无论你是准备面试还是真要做 Agent都值得照着过一遍。1. 面试官问 Agent 规划到底在考什么1.1 表面在问机制实际在考系统设计很多人听到“Agent 怎么做规划”第一反应是连锁反应模板、思维链提示、循环调用工具这几件套然后就开始背。但面试官问这个问题根本不是想听名词解释。他想知道你面对一个开放目标时怎么把它拆成结构化的执行方案怎么决定规划的粒度怎么处理不确定因素怎么验证规划结果。Agent 规划和传统程序流程最大的差异在于传统逻辑是开发时写死调用顺序Agent 规划则是运行时动态决策。它涉及“感知-规划-行动-观察”的闭环。在这条闭环里规划承担的是“把模糊意向变成可执行的子任务序列”的职责。考察点实际上有四个维度目标拆解能力面对一个宏大目标你能不能分解成边界清晰的子任务并识别依赖关系。资源约束意识上下文窗口有限、工具调用有成本、模型有延迟规划时是否把这些纳入考量。鲁棒性设计子任务失败怎么办观察结果和预期不符怎么办计划是否需要动态调整效果度量你怎么定义“规划得好”成功率还是步数还是成本如果候选人只盯着第一点后面三个一个都答不上来那么被淘汰一点不冤。1.2 淘汰者的三个典型画像观察这些年来的面试表现答砸的基本集中在三类人。第一类是“只会背链路”的。上来就“链式循环、反思、多智能体协同”听得出来全是文档语言但一旦追问“你这里为什么要用这个模式换成别的行不行”立刻沉默。说明他只是用过框架没有真正理解规划的本质。第二类是“只会调接口”的。做过一两个演示项目每天就在调框架的 API比如调用某个规划器参数。问他如果这个规划模块失效了他能自己写一个吗不知道。问他 Agent 在复杂环境里怎么取舍还是不知道。第三类是“只会做演示”的。项目做得不错但场景很窄。比如只是做一个单轮问答工具没有真正处理过连续决策。问他“你让 Agent 写一篇长文写到一半素材不够了怎么办”他回答“换个提示词再生成一次”。这种答案本质上把规划完全交给了模型随机性没有任何工程设计。这三类人都有一个共同问题没有建立起规划的系统框架。他们知道有这个名词不知道它是个系统。2. Agent 规划的完整认知框架从目标到执行的两条主线2.1 规划的本质把“做什么”翻译成“怎么做”规划一词在 AI Agent 语境里核心任务是把目标状态和当前状态之间的差距转化为一组有序的动作。这里面有两个关键动词“差距识别”和“动作映射”。差距识别要求 Agent 先明确现状。比如目标是“写一份行业报告”现状是手里只有用户一句简短要求那么差距就包括资料缺失、结构未定、篇幅未知。动作映射则针对这些差距拟定解决方案比如补数据、定大纲、逐节撰写。这段和传统“任务清单”的区别在于任务清单是静态的规划是动态的。一个合格的规划器会在执行中不断把新的观察重新纳入考虑。如果某一步收集到的资料和预期差异很大后续步骤就应该立即修正。很多人把“写 Prompt 要求模型一步步思考”等同于规划这是常见的误解。提示词让模型逐步思考确实有助于模型推理但它本质上是引导模型的内部注意力和推理方向输出更多的推理路径并没有生成真正可被追踪、验证、修正的执行计划。Agent 规划应该是有状态的对象每一步都能被监控和管理。2.2 主流规划范式各自适合什么场景我倾向于把规划范式按“规划与执行是否分离”来划分这比罗列名词更有指导性。先看“推理-行动循环式”动作决策、执行、观察结果在一个循环内交替进行。这种模式适合探索性强、没有既定步骤的任务。比如让 Agent 查资料回答一个开放问题它要边搜边判断下一步查什么。优点是灵活缺点是容易跑偏尤其在长任务里会丢失全局方向。另一种是“规划-执行分离式”先让规划器一次性生成完整方案再由执行器逐步执行。这种模式适合结构化程度较高的任务比如批量处理数据、生成固定模板的文档。优点是思路清晰、成本可控缺点是无法应对突发变化如果规划有误后面全盘皆输。还有一类介于两者之间采用“分阶段规划”先做粗粒度规划再对当前阶段做细粒度规划执行完再动态生成后续步骤。这种设计在复杂任务里最稳因为它兼顾全局方向感和局部灵活性。选择哪种范式取决于任务的确定性和风险性。确定性越高越应该偏向一次性规划不确定性越高越需要动态重规划。这也是回答面试追问时能体现深度的地方。2.3 规划粒度的三层抽象规划器产出的结果应该在什么颗粒度上表达是很值得展开的部分。我习惯将规划产物分成三个层级任务级描述“要完成哪些大块工作”偏语义化。比如“收集资料”“编写大纲”“撰写正文”。操作级描述“每一步具体做什么”偏动作化。比如“调用网页搜索工具查询过去三年的市场规模数据”。原子动作级描述“调哪个工具、传什么参数、拿到结果后如何处理”偏 API 化。粗粒度的好处是调用次数少、上下文占用低、对模型推理能力要求低坏处是控制精度不够。细粒度的好处是每步确认、便于回滚坏处是 token 消耗大、延迟高、容易过度拆解。面试中我常问“拆到多细合适”候选人如果说“越细越好”那说明没有成本意识。我自己的经验是执行容错率越低、工具副作用越大越应该细反之探索型任务保持粗粒度让执行器自行发挥。颗粒度的选择本质上是一种资源管理策略。3. 面试高分回答用一个可落地案例展示规划闭环3.1 场景怎么选才讨巧与其空谈原理我建议候选人在现场拿一个真实任务走一遍流程。如果平时有准备可以用自己做过的东西如果临时问就用一个大家都能理解的场景比如“生成一份新能源汽车市场分析报告”。这个场景好在哪第一足够复杂能体现拆解能力第二涉及外部工具和数据获取能展示工具调度第三天然需要验证和控制篇幅能体现验证与约束设计。面试官一听就能脑补出 Agent 执行的全貌。完整的规划闭环至少包含三块规划器、执行器、验证器。规划器负责生成方案执行器负责调用工具和模型生成内容验证器负责检查每一步的产出是否符合要求。三者循环协作。面试中你可以画一张物理结构图有一条主线从目标到规划器再到任务队列执行器从队列取出任务执行结果交给验证器打分评分不达标则重规划。3.2 规划器到底在生成什么规划器输出的不是一句计划描述而是一个结构化对象。我的做法是这样将计划定义为一个层级列表其中每一项包含四部分——任务名称、任务描述、依赖任务列表、验收标准。依赖列表特别关键它决定了任务是否能并发、是否能提前执行。举例来说“写市场现状章节”依赖“查询行业数据”“写竞争格局章节”也依赖“查询行业数据”这两章通过整理同一份素材完成可以在数据准备完毕之后并行执行。面试中能提到这一层说明你真的调度过。验收标准则是为了防止“看起来执行了其实没达到目标”。比如查询数据的验收标准是返回结果里至少包含近三年的市场规模数字且数据来源不少于两个来源。标准前置执行器才知道自己干到何时算合格。伪代码可以写成这样class Planner: def build_plan(self, goal: str, context: dict): subtask_specs [ TaskSpec( id1, namecollect_market_data, description搜索并整理近三年市场规模及增长率数据, dependencies[], acceptance包含2个来源且年份覆盖近三年, ), TaskSpec( id2, namecollect_competitor_info, description检索头部厂商最新动态和市场份额, dependencies[], acceptance明细列出至少3家厂商, ), TaskSpec( id3, namewrite_report, description基于前两部分素材生成完整报告正文, dependencies[1, 2], acceptance报告章节完整且引用数据来源, ), ] return Plan(taskssubtask_specs)这个代码很短但足以体现你对规划器职责的理解它不是“下一步提示词”它是任务分发中心。3.3 动态反馈与重规划是区分水平的分水岭静态规划只能算半个答案。面试官大概率会追问一句“如果某个子任务执行失败了你怎么办”这里我建议分两种情况回答。第一种是局部可重试比如搜索接口超时执行器直接重试两次换一个搜索源继续不需要惊动规划器。第二种是全局需要调整方向比如原本计划通过公开网站获取数据结果发现数据严重不足再搜也是浪费 token这时就应该回到规划器新增一个“购买第三方数据源或改用抽样分析”的替代方案。这种两层错误处理逻辑是实践沉淀出来的。本地重试成本低、响应快规划重规划代价高、但能救全局。如果你能把这条处理链讲出来面试状态就不一样了。另外一个容易被忽略的点是资源预算。Agent 执行长任务时上下文窗口非常容易被中间产物占满。规划器在生成计划时就应该包含清理机制把已经消费完、往下游不需要再回看的原始搜索结果摘要化合并到最终素材文件里释放上下文空间。面试中提到这个细节几乎能让面试官确认你确实做过复杂的 Agent 项目。3.4 执行阶段也要有规划思维真正的执行器也不是“无脑跑任务”。它接收一个任务描述先判断工具选择再考虑并行机会。比如“收集市场规模数据”这个任务完全可以并行发起多个搜索请求而不是一个搜完再搜下一个。这一步对时间效率影响非常大。执行还有一个关键原则对于不可逆或高成本的操作需要设置人工确认环节。像“发送邮件”“删除文件”“下单付款”这类动作无论规划得多好都应该在最后一步前暂停并让用户确认。能在面试中主动提出这种“安全护栏”的设计说明你已经有工程责任感这是一种写作与表达上的隐性加分项。4. 那些让面试官皱眉的操作典型翻车现场与避坑指南4.1 把“规划”等同于“写提示词”很多候选人答这道题张口就是“我先写一个 Prompt 告诉模型要一步步行动”。这类回答大致能确认他在项目里几乎不做系统设计是典型的高层封装使用者。提示词当然可以作为规则约束的一部分但它承担不了完整规划器的职责。规划器应当是代码和数据结构控制的流程而不是字符串里的“请你分步执行”的文本。4.2 流程一走到底失败没有逃生通道另一个常见硬伤是规划做成了单线的“流水账”。规划完一遍就照着流程走不论执行结果如何都不会回到规划层重新思考。这种方案只要中间一个环节数据异常后面输出基本全废。我面试时如果听到这种一般会追一个场景“你让 Agent 去搜索最新数据和政策搜回来的内容和你的知识库预判不一致它下一步怎么办”候选人卡壳的很多。正确的思路应该是观察值进到执行器之后先校验是否满足该任务的验收标准不满足则触发新的查询同时把异常信息传给规划器规划器决定后续路径。4.3 不考虑成本、延迟和执行风险技术能力强的人偶尔也栽在这里。他们能把规划模块做得很复杂动辄多轮反思、多次重规划却忘了 Agent 是要上线被真实用户使用的。多一轮重规划就多一倍模型调用成本多增加一个子任务检查点就多几百毫秒延迟。没有在面试中主动估算这些开销会被判定为实践意识不足。有一个小技巧在讨论方案时顺嘴提一句“这里每轮重规划大约增加多少 token 成本所以只有当损失超过阈值时才重规划”这就把纯粹的技术问题拉到了工程师决策的高度。4.4 避坑检查清单规划结果是否被结构化存储而不是保存在上下文文本里每个子任务是否具备可判定是否通过的验收标准执行器是否有临时自救能力还是所有错误都要上报规划器是否有动态修正接口还是只会一次性生成工具调用的副作用是否被评估高危操作是否加人工确认是否有步骤数和 token 的预算控制避免跑到一半超支这不是一个封闭的 checklist而是一套自检思维。面试前对着自己的项目过一遍比背十篇技术博客都管用。5. 面试追问实战这五个追问能秒懂候选人真实水平5.1 追问一如果中途发现目标本身不合理怎么办这里考验的是更顶层的评判能力。规划器和图灵测试的核心逻辑不同它在执行前会判断目标是否可实现。比如目标要求同时实现“成本最低”和“响应最快”这就是典型的矛盾目标。高质量的回答是规划器应先将目标拆成约束条件识别冲突后向用户澄清优先级而不是硬着头皮把方案生成出来。一个真正做过复杂 Agent 的人对“澄清需求”这个动作一定不陌生。5.2 追问二你怎么评估规划这件事本身的好坏很多候选人没考虑过这个问题。评估规划质量至少要看三个维度成功率、效率、可解释性。成功率衡量任务最终是否能完成效率衡量完成同样目标的步数和成本可解释性衡量规划过程的决策是否清晰、能否追溯。如果一个规划器的成功率很高但步数是别人的三倍那它只是“能工作”但绝对谈不上“好用”。实际项目中还需要把这三者的权重动态调整。对成本敏感的产品效率优先对研究型任务成功率优先。面试时能结合项目的实际情况谈权重比单背指标体系高级得多。5.3 追问三如果模型被替换规划方案还能用吗这个追问主要看候选人把规划逻辑和模型能力绑定到什么程度。好的规划器设计会考虑到模型能力差异在较强模型上多依赖即时判断在较弱模型上多依赖预设模板和分支条件。这种设计思路说明候选人很早就理解“ Agent 的质量上限不由模型单独决定而由规划器对模型能力的适配程度决定”。5.4 追问四长上下文任务你怎么处理这条主要看候选人有没有在现实中处理过超长任务。我会期待听到“内容压缩”“摘要收敛”“外部记忆”“分而治之”这些策略。比如让 Agent 写读一本书的摘要它完全可以先按章节分段阅读并生成章节摘要再聚合章节摘要生成全文摘要避免一次塞进太多内容。这样的 Agent 是“有脑子里装不下的时候会做笔记的人”而不是“拼命硬记的人”。5.5 追问五你的规划器有没有优化空间这个问题没有标准答案但面试官想听你有没有持续迭代的意识。有一些常见方向引入更合理的任务依赖分析用更细的 token 统计机制控制成本在规划层叠加对用户偏好的记忆。凡是能说出具体优化点且能在自己的代码里指出对应位置的候选人基本就是这一轮要等的人了。6. 这道题在真实项目里的另一种打开方式面试之外希望你意识到Agent 规划不是一个“炫技”模块它直接决定产品体验的质量线。如果一个 Agent 总是做无用功来回搜索用户会觉得它蠢如果它面对变化条件毫无应变能力用户会觉得它笨。规划器就是给这套随机性极强的系统装上“结构化方向盘”。我在面试中最终选的候选人往往不是那个对框架 API 背得最熟的人而是那个能用手画画自己的规划模块、能指出哪里可能出错、能给出动态修正方案的人。所以如果你正在准备这类面试与其反复看文档不如动手把一个简单的规划器代码写一遍或者找一个开源 Demo 的规划链路改造一遍。你会发现很多细节比如依赖排序、验收判断、上下文释放只有亲手处理过才说得出口。最后再说一点个人体会面试题淘汰的 80%淘汰的从来不是不懂算法的人而是没有工程视角的人。Agent 规划这道题能刷掉这么多人恰恰说明行业里大部分人还停留在“能跑就行”的层面而真正被需要的是能把“能跑”变成“能稳定地跑完复杂任务”的人。
阅读完成 · 觉得有帮助？
