企业官网建设流程全解析

面试现场，我通常会问一句：“你做过 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( id=1, name="collect_market_data", description="搜索并整理近三年市场规模及增长率数据", dependencies=[], acceptance="包含>=2个来源，且年份覆盖近三年", ), TaskSpec( id=2, name="collect_competitor_info", description="检索头部厂商最新动态和市场份额", dependencies=[], acceptance="明细列出至少3家厂商", ), TaskSpec( id=3, name="write_report", description="基于前两部分素材生成完整报告正文", dependencies=[1, 2], acceptance="报告章节完整且引用数据来源", ), ] return Plan(tasks=subtask_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 规划这道题能刷掉这么多人，恰恰说明行业里大部分人还停留在“能跑就行”的层面，而真正被需要的，是能把“能跑”变成“能稳定地跑完复杂任务”的人。