2025–2026 年，AI 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 语境下的分量要重得多，它至少需要承担以下四件事：

1. 任务拆解：把一个开放目标（比如“分析用户流失原因并生成报告”）拆解成若干子目标，且拆解方式本身可被评价和优化
2. 状态管理：准确记录已经完成到哪一步、哪些子目标已达成、当前上下文是什么
3. 环境 grounding：每一步的假设都能被环境反馈校正（调用工具、获取观测结果、再决定下一步动作）
4. 动态重规划：执行到一半发现原计划走不通，能回溯、能调整路线、能舍弃或替换子目标

一句话区分：CoT 是“脑内推演”，规划是“带地图和探照灯的野外行动”。前者不连接环境、不涉及工具调用、没有显式状态管理、更不会在半路改变主意。有人用同一个“电商用户流失分析”任务跑过三模式对比：CoT 是“想清楚再动手”——问题在于“你以为想清楚了，执行时总有意外”。

所以工程圈内有一个共识分层：CoT ≈ 局部推理增强，ReAct ≈ 在线决策机制，Plan-and-Execute ≈ 才接近真正意义上的任务规划框架。直接把 CoT 称为“规划”，是这一轮 AI 热潮中最普遍的术语通胀现象。

二、拆开看：当前 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-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 套壳”能大行其道？三个结构性原因

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 宣传页上的“自主规划”，翻译成工程大实话就是：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 具备规划能力”这句话，建议默认打个折扣来读。