2025--2026 年 Agent 圈一层不太愿意被挑破的窗户纸------市面上号称"具备规划能力"的 Agent，十之八九的 planner 模块，本质是把 CoT 的 prompt 模板套进了一个 while-loop，再贴个"Planning"的标签。下面把这件事拆开讲透：先界定什么叫"真规划"，再看当前 Agent 的 planner 实际在干什么，最后说清为什么这种"CoT 套壳"能横行，以及真规划该往哪走。
一、先立标杆：什么叫"真规划"，它和 CoT 根本不是一件事
CoT（Chain-of-Thought）的原始定义很清楚------Wei 等人 2022 年的论文里，它就是在输出答案前让模型用自然语言展开一步步推理 ，把 input → output变成 input → reasoning chain → output。它解决的是"模型容易在中间步骤跳步、偷懒、算错"这个问题，本质是单路径、线性、闭卷式的思维展开。
而"规划（Planning）"在 Agent 语境下要重得多，它至少得扛住这四件事：
- 任务拆解：把一个开放目标（"分析用户流失原因出报告"）拆成若干子目标，且拆法本身可被评价
- 状态管理：记得已经做到了哪、哪些子目标完成了、当前上下文是什么
- 环境 grounding：每一步的假设能被环境反馈校正（调工具、拿观测、再决定下一步）
- 动态重规划：执行到一半发现原计划走不通，能回溯、能改路线、能弃子目标
💡 一句话分界：CoT 是"脑内演算"，规划是"带地图和探照灯的野外行动" 。前者不连环境、不涉及工具、没有显式状态、更不会在半路改主意。 里作者用同一个"电商用户流失分析"任务跑过三模式对照：CoT 是"想清楚再动手"------问题是"你以为想清楚了，执行总有意外"。
所以工程圈里有个共识分层：CoT ≈ 局部推理增强，ReAct ≈ 在线决策机制，Plan-and-Execute ≈ 才接近真正意义上的任务规划框架（ 的同作者表述）。把 CoT 直接叫"规划"，是这一轮最普遍的术语通胀。
二、拆开看：当前 Agent 的"规划"到底长什么样
拿几个被反复引用的"标杆 Agent"开刀：
AutoGPT / BabyAGI 的规划器
表面看是"自主拆解任务、维护待办列表、循环执行"。但拆开 prompt 看，核心就是一段被写死的模板：
vbnet
You are an AI assistant. To complete tasks, always think step by step,
consider tools you have, and reason before acting.
Use this format:
Think → Decide → Act → Observe模型每一步的"规划"不过是在这个模板里填空 。程序层面强制了一个 任务 → 拆解 → 执行 → 记录 → 复盘 → 继续的 while-loop，LLM 只负责生成每一步的文字描述。你看到的"自动规划"，其实是 prompt + 代码骨架合谋演的一出戏，LLM 本人并没有"悟出"规划。
ReAct 的规划
ReAct 论文（Yao et al., ICLR 2023）的本职是把"推理"和"行动"拧成 Thought → Action → Observation → Thought的闭环，解决的是 CoT 无 grounding、Act-only 无策略这两个单边缺陷。但注意------ReAct 的"规划"仍是单路径、线性、一次生成的：它不能并行探索多条方案，也不能在推理链死胡同时回溯。所以严格说，ReAct 是"带环境反馈的 CoT"，不是规划器。
Plan-and-Execute 框架（LangGraph 等）
这套把"规划 Agent"和"执行 Agent"分开，看起来最接近真规划。但实际落地时，"规划 Agent"干的事通常还是：一次性让 LLM 吐一份步骤清单，然后交给执行侧逐条消费。如果执行侧某步挂了，有没有重规划（re-plan）取决于你代码里有没有写"失败 → 回到 planner 再生成一份"这个分支------而多数 demo 里这个分支是缺的，或者只是简单地"把 error msg 塞回上下文让 LLM 再吐一次"，依然是没有状态空间建模的 CoT 重生成。
一个对照表把"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-loop，半小时能跑出"哇它会自己拆解任务了"的效果。真规划要维护状态、要做 failure recovery、要接环境反馈闭环------工程量差一个数量级。95% 的 Agent 产品停在"能跑通 happy path 的 demo"就够了，没人愿意为那 5% 的鲁棒性付钱。
2. LLM 本身的"规划能力"还没收敛
你让 GPT 类模型"给设计一个两周上线的小程序计划"，它能吐一份看着不错的东西------但那是静态规划 ，一口气生成的。真 Agent 规划要的是：动态调整、环境反馈驱动下一步、持续修正目标。这三件事目前 LLM 单靠自己做不到，所以框架才得在外面"帮它补脑"（ReAct 补观测、MRKL 补工具选择、BabyAGI 补任务队列）。换句话说，不是框架不想做真规划，是 LLM 当不了真 planner，只能当 CoT 生成器，框架只好在外部用代码补。
3. CoT 的幻觉问题被"有工具"掩盖了
aakashshran 那篇拆得狠：FEVER 数据集上 超过 56% 的 CoT 轨迹包含虚构事实 ，而且模型越大会"hallucinate with greater confidence"------因为它全程在脑子里推，没有外部校正机制。但 Agent 场景里塞了工具调用后，工具的返回结果部分承担了 grounding 的职责，于是 CoT 的漂移被掩盖成了"哦看起来规划还行"。一旦任务跨到工具覆盖不到的抽象层（比如"要不要换一种打法"这种 meta 决策），CoT 套壳立刻露馅。
⚠️ 一个常被忽略的点：OpenAI o1/o3 这条线把推理做成内部化 （thinking tokens 不暴露），表面上脱离了"CoT 套壳"，但本质仍是单路径推理增强，不是带状态管理的规划。所以即便 frontier model 往前走，Agent 层的"规划"标签水分还在。
四、真规划该往哪走：几条已经在动的方向
不是说 CoT 套壳没用------它是地基，但不能顶替规划。几条值得跟踪的演进：
- Plan-and-Execute + Reflexion ：规划器生成计划 → 执行 → 轻量评估模型（甚至小模型就行）判断进展/失败根因 → 回到规划器改写。LangGraph 的
reflect节点就是这个思路。 - CodeAct / 可执行抽象：让 planner 输出代码（而非自然语言步骤），执行侧直接跑，状态由变量和异常接管。比"第一步做 A，第二步做 B"的 NL plan 稳得多。
- LLM + 搜索树：ToT（Tree of Thoughts）让模型同时展开多条候选、评估、回溯------这是 CoT 线性结构唯一被打破的地方，代价是 token 爆炸。
- LLM + Symbolic 混合：把"步骤顺序约束""资源依赖""失败阈值"这些用 symbolic planner（PDDL 类）管，LLM 只负责子目标到具体动作的翻译。工业界长 Horizon 任务大概率走这条。
五、一句收得住的话
当前多数 Agent 宣传页上的"自主规划"，翻译成 engineering 实话是：system prompt 里塞了一段 Think/Act/Observe 模板 + 外层一个 while-loop + LLM 负责每轮填 Thought 和 Action 的文本 。它让模型"看起来在规划"，但模型既没有状态机、也没有回溯、也没有对计划的元认知------本质上是 CoT 被 prompt 模板和代码骨架夹了一下，穿上了一件叫 Planning 的风衣。
真规划要等两件事之一发生：要么 LLM 本身长出"带状态、能重规划"的推理模式（不是 o1 这种内部化 CoT，而是真正的过程级规划）；要么 Agent 框架把 symbolic / search-tree / reflexion 这些"非 LLM 部分"做得足够重，重到 planner 不再是 LLM 独奏，而是 LLM + 结构引擎的双人舞。在此之前，"Agent 具备规划能力"这句话，建议默认打个折扣读。