2025–2026 年，AI Agent 领域其实有一个心照不宣的事实——市面上那些号称“具备规划能力”的 Agent，其 Planner 模块十之八九只是将 CoT（思维链）的提示模板套进一个 while 循环，再贴上一张“Planning”的标签。今天我们就来彻底拆解：首先厘清什么才是真正的“规划”，再看看当前 Agent 的 Planner 究竟在做什么，最后分析这种“CoT 套壳”为何能大行其道，以及真正的规划应该往哪个方向演进。
一、先立标杆：什么是“真规划”？它和 CoT 有本质区别
CoT（Chain-of-Thought）这个概念在 2022 年由 Wei 等人明确提出——它是指在输出最终答案之前，先让模型用自然语言逐步展开推理过程，把 input → output 转化为 input → reasoning chain → output。其核心是解决模型在中间步骤跳步、偷懒或算错的问题，本质上是一条单路径、线性、闭卷式的思维展开过程。
然而，在 Agent 的语境中，“规划（Planning）”的要求要沉重得多，至少需要满足以下四点：
- 任务拆解：将一个开放目标（例如“分析用户流失原因并生成报告”）拆解为若干子目标，且拆解方式本身需要经得起评估。
- 状态管理：准确记录已完成的步骤、当前上下文以及已完成的子目标。
- 环境 grounding：每一步的假设都能借助环境反馈进行校正——调用工具、获取观测结果，然后决定下一步行动。
- 动态重规划：在执行过程中发现原计划不可行时，能够回溯、调整路线，甚至舍弃部分子目标。
因此，工程界其实有一个共识分层：CoT ≈ 局部推理增强，ReAct ≈ 在线决策机制，Plan-and-Execute 才接近真正意义上的任务规划框架。将 CoT 直接称为“规划”，无疑属于这一轮最普遍的术语通胀现象。
二、拆开看：当前 Agent 的“规划”到底长什么样
不妨拿几个被反复引用的“标杆 Agent”来剖析：
AutoGPT / BabyAGI 的规划器
表面上看，它们可以“自主拆解任务、维护待办列表、循环执行”。但拆开 prompt 一看，核心就是一段被写死的模板：
You are an AI assistant. To complete tasks, always think step by step, consider tools you ha ve, and reason before acting. Use this format: Think → Decide → Act → Observe模型每一步所谓的“规划”，不过是在这个模板里填空。程序层面强制了一个 任务 → 拆解 → 执行 → 记录 → 复盘 → 继续 的 while 循环，LLM 只负责生成每一步的文字描述。你看到的“自动规划”，其实是 prompt 加上代码骨架合谋上演的一出戏，LLM 本身并没有真正“领悟”规划的含义。
ReAct 的规划
ReAct 论文的本意是把“推理”和“行动”整合为 Thought → Action → Observation → Thought 的闭环，解决了 CoT 缺少 grounding、Act-only 缺乏策略这两个单边缺陷。但请注意——ReAct 的“规划”依然是单路径、线性、一次生成的：它无法并行探索多条方案，也做不到在推理链走入死胡同时回溯。严格来说，ReAct 就是“带环境反馈的 CoT”，算不上真正的规划器。
Plan-and-Execute 框架（LangGraph 等）
这套将“规划 Agent”和“执行 Agent”分开的方法，看起来最接近真规划。然而实际落地时，“规划 Agent”通常做的事情仍然是：一次性让 LLM 生成一份步骤清单，然后交给执行侧逐条执行。如果执行侧某一步失败，是否触发重规划（re-plan）取决于代码中是否写了“失败 → 回到 planner 重新生成”的分支——而大多数 demo 缺少这个分支，或者仅仅是简单地把错误信息塞回上下文让 LLM 再生成一次，这依然是缺少状态空间建模的 CoT 重生成。
归结起来，看这张对比表就一目了然：
| 维度 | CoT 套壳式“规划” | 真规划 |
|---|---|---|
| 路径结构 | 单路径线性 | 可多路径、可回溯（ToT / search tree） |
| 是否 grounding | 闭卷推理，无环境反馈 | 每步可被观测校正 |
| 状态管理 | 靠 context 窗口“顺便记得” | 显式状态机或结构化记忆 |
| 重规划触发 | 靠 prompt 里一句“如果失败请重试” | 有失败检测 → 根因诊断 → 计划改写闭环 |
| 抽象层级 | 自然语言步骤串 | 可执行抽象（如 CodeAct）或 symbolic 约束 |
| 代表实现 | AutoGPT/BabyAGI/多数 ReAct demo | 带 Reflexion 的 ReAct、LLM+搜索树、CodeAct |
三、为什么“CoT 套壳”能横行？三个结构性原因
1. Demo 经济学
给 LLM 塞一句“Let's think step by step”再加一个 few-shot 的 Think/Act/Observe 模板，挂上个 while 循环，半小时就能跑出“哇，它会自己拆解任务了”的效果。而真规划需要维护状态、做 failure recovery、接环境反馈闭环——工程量相差一个数量级。95% 的 Agent 产品只要跑通 happy path 的 demo 就足够，没人愿意为那 5% 的鲁棒性买单。
2. LLM 本身的“规划能力”尚未收敛
让 GPT 类模型“设计一个两周上线的小程序计划”，它能生成一份看似合理的方案——但那是静态规划，一气呵成。真正的 Agent 规划要求动态调整、环境反馈驱动下一步、持续修正目标。这三件事目前 LLM 单靠自己做不到，所以框架不得不从外部“帮它补脑”（ReAct 补观测、MRKL 补工具选择、BabyAGI 补任务队列）。换句话说，不是框架不想做真规划，而是 LLM 当不了真 planner，只能充当 CoT 生成器，框架只好在外围用代码来补足。
3. CoT 的幻觉问题被“有工具”掩盖了
FEVER 数据集上的数据显示，超过 56% 的 CoT 轨迹包含虚构事实，而且模型越大，越会“hallucinate with greater confidence”——因为它全程在脑子里推演，没有外部校正机制。但在 Agent 场景中引入工具调用后，工具返回的结果部分承担了 grounding 的职责，于是 CoT 的漂移就被掩盖成“哦，看起来规划还行”。一旦任务跨越到工具覆盖不到的抽象层——比如“要不要换一种打法”这种元决策——CoT 套壳立刻露馅。
四、真规划该往哪走：几条已在推进的方向
话说回来，CoT 套壳并非毫无价值——它是地基，但不能顶替规划。以下几个演进方向值得关注：
- Plan-and-Execute + Reflexion：规划器生成计划 → 执行 → 轻量评估模型（甚至小模型）判断进展与失败根因 → 回到规划器改写。LangGraph 的
reflect节点正是这个思路。 - CodeAct / 可执行抽象：让 planner 输出代码（而非自然语言步骤），执行侧直接运行，状态由变量和异常接管。相比“第一步做 A，第二步做 B”的 NL 计划，这种方式稳健得多。
- LLM + 搜索树：ToT（Tree of Thoughts）让模型同时展开多条候选、评估、回溯——这是 CoT 线性结构唯一被打破的地方，代价是 token 爆炸。
- LLM + Symbolic 混合：将“步骤顺序约束”“资源依赖”“失败阈值”等用 symbolic planner（PDDL 类）来管理，LLM 只负责子目标到具体动作的翻译。工业界的长 Horizon 任务大概率会走这条路。
五、一句收得住的话
当前大多数 Agent 宣传页上的“自主规划”，翻译成 engineering 的实话就是：system prompt 里塞了一段 Think/Act/Observe 模板 + 外层一个 while 循环 + LLM 负责每轮填充 Thought 和 Action 的文本。它让模型“看起来在规划”，但模型既没有状态机、也没有回溯、更没有对计划的元认知——本质上就是 CoT 被 prompt 模板和代码骨架夹了一下，穿上了一件叫 Planning 的风衣。
真正的规划需要等待两件事之一发生：要么 LLM 自身长出“带状态、能重规划”的推理模式（不是 o1 那种内部化 CoT，而是真正的过程级规划）；要么 Agent 框架把 symbolic / search-tree / reflexion 这些“非 LLM 部分”做得足够重，重到 planner 不再是 LLM 的独奏，而是 LLM + 结构引擎的双人舞。在此之前，“Agent 具备规划能力”这句话，建议默认打个折扣来读。
