1. 这道题到底在考什么“Agent 怎么做规划”——乍一听像是一道八股文面试题但真正面过几十个候选人之后我发现它其实是一道筛子题。80% 的候选人被淘汰不是因为不会写代码而是因为没有真正理解“规划”在 Agent 系统里意味着什么。先把这个概念说清楚。Agent 的规划不是传统软件工程里的“任务调度”也不是简单的 if-else 分支。它指的是给定一个模糊的、多步骤的目标Agent 如何自主决定先做什么、后做什么、遇到问题怎么调整、什么时候停下来。这中间涉及目标拆解、依赖分析、资源分配、失败恢复、动态重规划等一系列决策。为什么这道题能淘汰这么多人因为大部分候选人的回答停留在“调 LLM 生成一个步骤列表然后按顺序执行”这个层面。这个答案在 demo 里能跑通但在真实场景里几乎必然崩溃——因为真实世界的任务有依赖、有并行、有失败、有歧义而一个静态的步骤列表处理不了这些。这道题真正想考察的是三件事第一你知不知道规划问题的本质难点在哪里第二你有没有实际落地过一个能跑的规划模块第三你能不能在不同的方案之间做出有理由的取舍。下面我按这三个维度展开把这道题拆透。2. 规划问题的本质难点拆解2.1 为什么“让 LLM 列个步骤”不够用很多人第一反应是规划嘛不就是让大模型输出一个 to-do list我试过在简单任务上确实能用。比如“帮我查一下明天天气然后决定穿什么”模型输出“1. 查天气 2. 根据温度推荐穿搭”没问题。但一旦任务变复杂问题就暴露了。我拿一个真实场景举例让 Agent 完成“调研三个竞品的功能差异并生成对比报告”。如果直接让 LLM 列步骤它可能输出“1. 搜索竞品A 2. 搜索竞品B 3. 搜索竞品C 4. 对比 5. 写报告”。看起来合理但实际执行时会遇到搜索竞品A返回了20条结果哪几条有用需要二次筛选但步骤列表里没有这一步。竞品B的搜索失败了是重试还是跳过步骤列表没说。对比的时候发现缺少某个维度的信息需要回头补充搜索但步骤列表是线性的回不去。三个竞品的搜索其实可以并行但步骤列表是串行的浪费时间。这些问题的根源在于静态步骤列表无法表达条件分支、循环、并行和动态调整。而真实的规划需要这些能力。2.2 规划的三个核心维度我把 Agent 规划拆成三个维度来理解这样在面试时也能有条理地展开。第一个维度是粒度。规划可以很粗——只定大方向比如“先调研、再分析、最后输出”也可以很细——每一步都指定具体的工具和参数。粒度太粗执行时容易跑偏粒度太细规划本身的开销就很大而且一旦环境变化就得全部重来。实际落地时我通常采用分层规划顶层用粗粒度定阶段每个阶段内部再用细粒度定具体动作。第二个维度是时机。规划可以一次性做完静态规划也可以边做边规划动态规划。静态规划适合环境确定、步骤可预测的任务动态规划适合环境不确定、需要根据中间结果调整的任务。大部分真实场景需要的是混合模式先做一个粗略的静态规划执行过程中根据反馈动态调整。第三个维度是反馈闭环。规划不是做完就完了执行结果要能反馈回来影响后续规划。这个闭环的设计才是真正区分高手和普通人的地方。没有闭环的规划就是“拍脑袋”有闭环的规划才能自我修正。2.3 一个容易被忽略的点规划的终止条件面试时我经常追问一个问题“你的 Agent 怎么知道规划完成了”很多候选人答不上来。这其实是个很关键的设计点。终止条件不能简单设成“所有步骤执行完”因为步骤可能执行了但目标没达成。比如“搜索竞品信息”这一步执行了但搜到的信息不完整目标其实没达成。合理的终止条件应该是目标达成判定用一个独立的判断模块可以是 LLM 也可以是规则来评估当前状态是否满足原始目标。如果不满足且还有可用的调整空间就继续规划如果满足或者资源耗尽就停止。这个设计在面试里是加分项因为它说明你考虑过“规划失败”的情况而不是假设一切顺利。3. 主流规划方案与选型逻辑3.1 从 ReAct 到 Plan-and-Execute如果候选人只知道 ReAct我会觉得他可能没真正落地过复杂 Agent。ReAct 的思路是“想一步做一步”适合短任务但长任务里容易迷失方向因为每一步都只看局部信息。Plan-and-Execute 是更成熟的方案先规划出完整步骤再逐步执行。它的优势是有全局视野但缺点是规划一旦定死就不好改。实际落地时我通常把两者结合用 Plan-and-Execute 做顶层规划用 ReAct 做每个子任务的执行。这样既有全局方向又有局部灵活性。还有一个变体是LLM Compiler的思路它把规划表示成有向无环图DAG节点是任务边是依赖关系。这个方案的好处是能自动识别哪些任务可以并行哪些必须串行。我在一个数据处理项目里用过这个思路把原本串行的 12 个步骤优化成 4 层并行执行整体耗时降了 60%。3.2 方案选型的决策框架面试时如果被问到“你怎么选方案”不要直接说“我用 XX”而是给出决策逻辑。我通常从三个问题出发决策问题选型倾向任务步骤是否可预测可预测选静态规划不可预测选动态规划任务是否有明确的依赖关系有依赖用 DAG 规划无依赖用线性规划执行环境是否稳定稳定用 Plan-and-Execute不稳定用 ReAct 或混合模式对延迟是否敏感敏感则减少规划开销用轻量规划不敏感可以用更重的规划失败成本高不高高则加验证和回滚机制低则可以快速试错这个框架在面试里很实用因为它展示的是工程判断力而不是背答案。3.3 一个实际项目的选型过程我拿之前做过的一个“自动化数据分析 Agent”举例。需求是用户给一个数据集和一句分析目标Agent 自动完成数据清洗、特征分析、可视化、结论生成。一开始我用的是纯 ReAct结果发现 Agent 经常在数据清洗阶段就陷入循环反复尝试不同的清洗方法忘了最终目标是分析。后来改成 Plan-and-Execute先规划出“清洗→分析→可视化→总结”四个阶段每个阶段内部再用 ReAct 执行。这样 Agent 始终知道自己在哪个阶段、下一步该往哪走。但新的问题又来了如果清洗阶段发现数据质量太差根本没法分析怎么办这时候就需要动态重规划检测到异常后回到规划层重新生成步骤比如“先做数据修复再分析”或者“告知用户数据不可用”。这个重规划机制是后来加的加完之后 Agent 的成功率从 55% 提到了 82%。4. 规划模块的实操实现4.1 规划器的核心结构一个可落地的规划器我通常拆成四个部分目标解析器、步骤生成器、依赖分析器、执行调度器。目标解析器负责把用户的模糊输入转成结构化的目标描述。比如用户说“帮我看看这个月销售哪里出了问题”解析后变成“分析销售数据找出异常维度给出可能原因”。这一步用 LLM 做 few-shot 抽取就行关键是定义好输出的 schema。步骤生成器基于目标描述生成初始步骤列表。这里有个技巧不要让 LLM 一次性生成所有细节而是先生成高层步骤再对每个步骤单独展开。这样生成的步骤质量更高因为每次 LLM 只需要关注一个子问题。依赖分析器负责识别步骤之间的依赖关系构建 DAG。简单的依赖可以用规则判断比如“步骤B的输入是步骤A的输出”复杂的依赖需要 LLM 辅助判断。执行调度器按照 DAG 的顺序执行步骤处理并行、失败重试、超时等逻辑。4.2 步骤生成的关键 prompt 设计步骤生成的质量直接决定规划的质量。我试过很多种 prompt 写法最后稳定下来的结构是这样的PLANNING_PROMPT 你是一个任务规划器。给定以下目标请生成执行步骤。 目标{goal} 可用工具{tools} 要求 1. 每个步骤必须明确指定使用哪个工具 2. 步骤之间如果有依赖关系请标注依赖的步骤编号 3. 如果某些步骤可以并行执行请标注 4. 步骤数量控制在 3-8 个太粗或太细都不好 5. 输出格式为 JSON 数组每个元素包含 step_id, description, tool, depends_on, parallel_group 请输出 这个 prompt 的关键在于约束了输出格式和步骤数量。不约束格式LLM 会输出一堆自然语言后续没法程序化处理不约束数量LLM 要么只给两三个大步骤要么给二十个细碎步骤都不好用。4.3 依赖分析与并行执行拿到步骤列表后下一步是构建依赖图。我通常用拓扑排序来确定执行顺序同时识别可以并行的步骤。具体做法是先把所有步骤按 depends_on 关系建成图然后找入度为 0 的节点作为第一批执行。每执行完一个节点就把它从图中移除更新其他节点的入度再把新的入度为 0 的节点加入执行队列。这个过程循环直到所有节点执行完。并行执行的时候要注意资源竞争。比如两个步骤都要调用同一个 API如果 API 有速率限制并行反而会触发限流。我的做法是给每个工具配一个信号量控制并发数。这个细节在面试里提出来能说明你考虑过真实环境的约束。4.4 动态重规划的触发条件重规划不是随时都做那样开销太大。我通常设三个触发条件步骤执行失败且重试无效比如搜索工具连续三次返回空结果说明当前路径走不通。中间结果与预期偏差过大比如预期找到 10 条相关数据实际只找到 1 条说明目标可能需要调整。执行步数超过阈值比如规划了 5 步执行到第 10 步还没结束说明规划有问题。触发重规划后不是从头再来而是保留已完成的步骤结果只重新规划剩余部分。这样能避免重复劳动。5. 常见坑与排查技巧5.1 规划粒度失控最常见的坑是规划粒度要么太粗要么太细。太粗的表现是步骤描述模糊比如“分析数据”——分析什么怎么分析执行器不知道怎么做。太细的表现是步骤数量爆炸比如把“打开文件”和“读取内容”拆成两步规划开销比执行还大。我的经验是一个步骤应该对应一个可独立验证的产出。如果一步做完之后你能明确说“这一步完成了产出是 X”那粒度就合适。如果做完之后说不清产出了什么说明太粗如果产出小到没有独立验证的价值说明太细。5.2 依赖关系识别错误依赖识别错了要么导致执行顺序错误该先做的后做了要么导致并行冲突两个互相依赖的步骤被并行执行。排查方法很简单在 DAG 里找环。如果依赖图里有环说明依赖关系识别错了因为正常的任务依赖不应该有循环。我通常在规划完成后加一个环检测有环就打回重新规划。另一个技巧是让 LLM 自己检查依赖。生成步骤后追加一个 prompt“请检查以下步骤的依赖关系是否合理是否存在循环依赖或遗漏的依赖。”这个自检步骤能过滤掉大部分低级错误。5.3 重规划陷入死循环动态重规划有个风险如果重规划后的步骤还是失败可能反复触发重规划陷入死循环。我的做法是设一个重规划预算最多重规划 3 次超过就终止并返回当前最佳结果。同时记录每次重规划的原因如果连续两次原因相同说明问题不在规划层而在执行层或工具层这时候应该报错而不是继续重规划。5.4 常见问题速查表问题现象可能原因排查方向解决方案步骤执行到一半卡住依赖关系有环或缺失检查 DAG 是否有环加环检测重新规划并行步骤互相干扰资源竞争或数据依赖检查并行组的工具调用加信号量控制并发重规划频繁触发规划粒度太细或工具不稳定统计重规划原因分布调整粒度或加固工具最终结果偏离目标终止条件太宽松检查目标达成判定逻辑加独立的目标验证步骤规划耗时过长步骤生成 prompt 太复杂测量规划阶段耗时简化 prompt 或分层规划5.5 一个真实的排查案例之前有个项目Agent 在执行“生成报告”这一步时经常超时。排查发现报告生成步骤依赖了前面所有步骤的输出但前面的输出格式不统一导致报告生成器要花大量时间做格式适配。解决方案是在规划阶段就约定中间产出的格式。每个步骤的输出 schema 在规划时就定义好执行器按 schema 输出下游按 schema 消费。这样虽然规划阶段多花了一点时间但执行阶段的效率提升了很多。这个经验后来成了我规划模块的标配规划不只是规划步骤还要规划数据契约。6. 面试中如何展示规划能力6.1 回答的结构化框架如果面试被问到“Agent 怎么做规划”我建议按这个结构回答先说规划的本质不是列步骤而是在不确定环境中做决策序列的生成和调整。然后说核心难点粒度控制、依赖管理、动态调整、终止判定。接着说你的方案你用过什么方案为什么选它遇到什么问题怎么解决的。最后说取舍这个方案的局限是什么什么场景下你会换方案。这个结构的好处是展示了你从理解问题到解决问题的完整链路而不是只背了一个方案。6.2 用具体案例支撑光说方案不够要有一个具体案例。案例要包含任务背景、初始方案、遇到的问题、调整过程、最终效果。数字很重要比如“成功率从 55% 提到 82%”“耗时降低 60%”这些数字比形容词有说服力。但注意案例要是你自己真正做过的面试官会追问细节。如果只是看来的案例追问两轮就露馅了。6.3 展示对边界的认知高手和普通人的区别往往在于知道自己方案的边界在哪里。面试时主动说出“这个方案在 XX 场景下不适用”比只夸方案好要加分。比如我会说“Plan-and-Execute 适合步骤可预测的任务但如果任务本身是探索性的比如开放式研究那 ReAct 的灵活性更重要。实际选型要看任务的可预测程度和失败成本。”这种表述展示的是判断力而不是知识量。7. 规划能力的进阶方向7.1 从单 Agent 规划到多 Agent 协作规划单 Agent 规划做熟了之后自然会遇到多 Agent 场景。多个 Agent 各自有规划能力怎么协调这时候规划问题就变成了分布式规划问题。我试过的一种做法是设一个主规划器负责顶层任务分解把子任务分配给子 Agent子 Agent 各自做自己的详细规划。主规划器不关心子 Agent 怎么执行只关心它们是否按时交付了符合契约的产出。这种分层规划的思路和微服务架构里的 API 契约很像。7.2 规划与记忆的结合规划不是孤立的它应该和 Agent 的记忆系统结合。之前规划过的类似任务、执行过的步骤、遇到的失败都应该被记住下次规划时作为参考。我的做法是给规划器加一个经验检索步骤规划前先检索历史相似任务的规划方案作为 few-shot 示例注入 prompt。这样规划器能复用过去的成功经验避免重复踩坑。实测下来有经验检索的规划器首次规划成功率比没有的高出 20 多个百分点。7.3 规划的可解释性在有些场景里规划不仅要能跑还要能解释。比如企业级应用用户需要知道 Agent 为什么这么规划。这时候规划器需要输出决策理由为什么选这个步骤、为什么这个顺序、为什么跳过某个选项。实现方式是在规划 prompt 里要求 LLM 对每个步骤给出理由然后把这些理由和执行日志一起展示给用户。这个功能在 demo 里看不出价值但在真实产品里是刚需。8. 我个人的一些实操体会规划模块最难的不是写代码而是定义什么叫“规划得好”。我一开始没有评估标准改来改去不知道有没有变好。后来定了一个简单的评估框架任务成功率、平均执行步数、重规划次数、端到端耗时。这四个指标一起看才能判断一个改动是优化还是劣化。另一个体会是规划器的 prompt 要迭代但不能频繁大改。我试过一周改三次 prompt结果每次改完都要重新调执行器因为执行器对步骤格式有依赖。后来定了个规矩prompt 改动必须配套执行器的兼容性测试确保不会因为规划格式变化导致执行失败。还有一点不要追求一次规划完美。真实场景里第一次规划能覆盖 70% 的情况就不错了剩下的靠动态调整。把精力花在重规划机制上比花在让首次规划更完美上回报率高得多。最后分享一个小技巧规划器的输出里加一个confidence字段让 LLM 自己评估这个规划的可信度。如果 confidence 低于阈值就直接触发人工确认或者走保守路径。这个字段不花什么成本但在关键场景里能避免很多低级错误。