CoT + Plan-Execute：把复杂任务拆成 Function Call 能接住的步骤

单步任务上你的 Agent 很稳：查天气、查订单，一调一个准。直到第一个多步任务进来——「统计上季度各渠道退款率，做成表格发我」——模型查完数据开始编列名，或者给第三步猜了一个参数。你反复检查每一步的 Function Call，单看都对不上哪里坏了。

腾讯、美团、百度都考过同一道题：

「Planner-Executor 架构在什么情况下优于单 Agent ReAct？」 —— AgentAlpha 面试题库 · 腾讯篇 / 美团篇 / 百度篇

这道题的潜台词是：多步任务的稳定性和单步准确率是两回事，需要不同的架构。

先说结论

CoT + Plan-Execute 提升稳定性的机制是「缩小错误半径」：CoT 让模型动手前把思路写清，每次调用有依据；Plan-Execute 把长任务切成短的、可验证的小步骤，观察回填、冲突重规划——错误最多污染一步，不再一路错到底。但它不是默认架构：步骤少、路径直的任务，多一层规划就是多一层开销和新的出错点。

图：小蓝图解——Plan → Execute → 修正 的三级台阶。

多步任务上，单步 FC 怎么输的

三种失败模式，层层递进。

错误累积。假设单步 95% 正确，十步连乘只剩约六成——这是算术，不是玄学。长任务的稳定性只能靠「每步可验证、可修正」撑住，指望每步都靠运气不现实。

依赖断裂。第三步的参数依赖第一步的工具返回。中间结果把上下文撑长之后，模型取不到或取错字段，就开始编——多步场景里的参数幻觉，大多从这里来。

目标漂移。步骤一多，最初的约束（时间范围、统计口径、输出格式）在长上下文里被稀释，最后一步的产出和需求对不上。

字节篇有一道题默认了这些前提：

「Planner 生成的计划不可执行时，Executor 应该怎样反馈并触发 Replan？」 —— AgentAlpha 面试题库 · 字节篇

题目默认两件事：长任务需要计划；计划本身会错。这两条正是 Plan-Execute 的出发点。

CoT：把「想」从「做」里拆出来

CoT用带中间推理步骤的示例，让模型回答前先把推理写出来，在数学、逻辑类任务上的收益随模型规模显现。

放进 Agent 语境，它的价值是给每次调用装一个「申请理由」：调用工具前先写清要解决什么、选哪个工具、参数从哪里来。有依据的调用比直出的调用更可检查，也更少幻觉——检查一段推理，比审查一个凭空出现的参数列表容易得多。

但 CoT 是单次生成，想完就做完，错了没人告诉它。所以它只解决「出手前想清楚」，解决不了「出手后修正」——后者要把推理接进执行循环。ReAct验证的正是这件事：推理与行动交替，工具观察回填上下文，错误被环境当场纠正。

Plan、Execute、Observe、修正

Plan-Execute 把「先想」升格成显式阶段：

• Plan：Planner 产出结构化计划——每步做什么、依赖哪些前序结果、怎么算完成；
• Execute：Executor 逐步执行，每步就是一次具体的 Function Call；
• Observe：每步的工具返回回填上下文；
• 修正：执行结果与计划假设冲突时，触发 Replan，而不是硬着头皮往下走。

三种范式放在一起看：

和 ReAct 的分工可以这样记：ReAct 是边想边做，适合探索性短任务；Plan-Execute 是想好再做，步骤多、依赖清晰时，全局计划避免了走一步看一步的绕路。字节篇有一道横向对比题：「ReAct、Plan-and-Execute、ReWOO 与状态机分别适合什么任务？」（AgentAlpha 面试题库 · 字节篇）——答题框架就是按任务结构选范式，不背「谁更先进」。

阿里篇则把「修正」单拎出来考：

「工具执行结果与计划假设冲突时，Agent 应该如何修正后续步骤？」 —— AgentAlpha 面试题库 · 阿里篇

修正的前提藏在计划里：每步写清假设和验证标准，冲突才可被发现。「查完数据后，应得到按渠道分组的退款率」是个可验证的假设；「查一下数据」不是。

什么时候是过度设计

三个判断，按顺序过：

1. 步数不超过三步、路径固定：直接 Function Call 或 ReAct，加 Planner 纯属开销；
2. 流程完全确定：写成工作流或状态机，模型只在需要的节点出现——确定性流程用概率组件跑，稳定性反而下降；
3. 目标清楚但路径要探索、步骤多、有依赖：这才是 Plan-Execute 的主场。

还有一笔账要算在前面：Planner 多一次调用，也多一种失败——计划本身会错。所以上 Plan-Execute 必须配套两样东西：Replan 机制和步数预算。缺了它们，只是把失败从执行层挪到计划层，稳定性并没有变好。

一条经验顺序：先让 ReAct 跑通，用日志证明多步错误率确实是瓶颈，再上 Plan-Execute。顺序反了，就是用架构复杂度掩盖工程问题——很多「不稳」其实是 Schema 含糊和没有校验层，加 Planner 救不了它们。

面试迁移

追问预测：

1. 「Planner 和 Executor 用同一个模型吗？」——按成本权衡：规划要全局视野，可以用更强模型；执行步内聚简单，用小模型降本；
2. 「计划粒度多细合适？」——太粗执行时还是靠猜，太细等于把推理挪进计划、环境一变全废；粒度以「每步可验证」为准；
3. 「和 ReAct 什么关系？」——不是二选一，Plan-Execute 的每个执行步内部可以就是一轮 ReAct。

容易扣分的说法：「Plan-Execute 永远优于 ReAct」——没有前提的优劣判断都会被追问打穿；「加个 Planner 就稳了」——忽略 Replan 和步数预算的配套。

要点复盘

• 多步任务的三种失败：错误累积、依赖断裂、目标漂移，单步准确率救不了；
• CoT 的贡献是出手前有依据，ReAct 的贡献是出手后能修正；
• Plan-Execute 四拍：Plan、Execute、Observe、修正，假设要写成可验证的形式；
• 三个判断决定用不用：步数少不加层，流程确定用工作流，探索型长任务才上 Plan-Execute；
• Replan 和步数预算是配套件，缺了它们，稳定性只是换了层失败。