为什么说你的 Agent 并没有在规划：它只是在填空？

当前AI Agent领域热议的“规划能力”背后，实则隐藏着一个圈内少有人戳破的真相：多数号称具备“规划”模块的Agent，其核心不过是将CoT（思维链）的prompt模板套进一个while-loop循环，再贴上“Planning”的标签。本文将深入剖析这一现象，首先界定“真规划”的内涵，随后揭示当前Agent planner的真实工作机理，最后分析“CoT套壳”为何能大行其道，并展望真正规划能力的发展方向。

一、先立标杆：什么叫"真规划"，它和 CoT 根本不是一件事

CoT（Chain-of-Thought）的原始定义非常明确。根据Wei等人在2022年发表的论文，其本质是在输出答案前让模型使用自然语言展开逐步推理，将原本的input → output变为input → reasoning chain → output。这一方法旨在解决模型容易在中间步骤产生跳跃、偷懒或计算错误的问题，其本质上是单路径、线性且闭卷式的思维展开过程。

相比之下，在Agent语境中，“规划（Planning）”的概念要厚重得多，它至少需要承担以下四个核心职能：

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 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）中，这个分支要么缺失，要么仅仅是将错误信息重新放入上下文，让LLM再次生成，这实质上依然是一种没有状态空间建模的CoT重生成过程。

一个对照表把"CoT 套壳规划"和"真规划"钉死

三、为什么"CoT 套壳"能横行？三个结构性原因

一、Demo 经济学

只需向LLM添加一句“Let's think step by step”，并配合一个包含 Think/Act/Observe模板的few-shot示例，再挂上一个while-loop循环，就可以在半小时内实现“哇，它会自己拆解任务了”的效果。而真正的规划需要维护状态、进行失败恢复（failure recovery）、连接环境反馈闭环，其工程工作量相差一个数量级。95%的Agent产品仅满足于能跑通happy path的demo，很少有人愿意为提高那5%的鲁棒性投入成本。

二、LLM 本身的"规划能力"尚未收敛

当你要求GPT类模型“为两周内上线一个小程序制定计划”时，它能生成一份看似不错的方案——但这属于静态规划，一次性生成结果。真正的Agent规划要求实现：动态调整、由环境反馈驱动下一步行动、以及持续修正目标。这三项能力，目前LLM单靠自己难以做到，因此框架才需要在外部进行补充（ReAct补充观测、MRKL补充工具选择、BabyAGI补充任务队列）。换句话说，并非框架不想实现真规划，而是LLM无法担当真正的规划者角色，只能充当CoT生成器，框架不得不在外部用代码进行辅助。

三、CoT 的幻觉问题被"有工具"掩盖了

aakashshran的剖析非常深刻：在FEVER数据集上，超过56%的CoT轨迹包含虚构事实，而且模型越大，其“hallucinate with greater confidence”（幻觉产生时越自信）——因为它全程在内部进行推理，缺乏外部校正机制。然而，在Agent场景中引入工具调用后，工具返回的结果部分承担了环境接地（grounding）的职责，从而掩盖了CoT的漂移现象，给人一种“规划似乎还行”的错觉。一旦任务跨越到工具无法覆盖的抽象层面（例如“是否需要改变策略”这样的元决策），CoT套壳的缺陷就会立刻暴露。

️ 一个常被忽略的点：OpenAI o1/o3 这条线把推理做成内部化（thinking tokens 不暴露），表面上脱离了"CoT 套壳"，但本质仍是单路径推理增强，不是带状态管理的规划。所以即便 frontier model 往前走，Agent 层的"规划"标签水分还在。

四、真规划该往哪走：几条已经在动的方向

需要明确的是，CoT套壳并非毫无价值——它是重要的基础，但不能替代真正的规划。以下是几个值得关注的发展方向：

1. Plan-and-Execute + Reflexion：规划器生成计划后执行，再由一个轻量级评估模型（甚至小模型即可胜任）判断进展或失败根因，最后反馈给规划器进行改写。LangGraph中的reflect节点正是基于这一思路。
2. CodeAct / 可执行抽象：让规划器输出代码（而非自然语言步骤），执行侧直接运行，通过变量和异常进行状态管理。这比“第一步做A，第二步做B”的自然语言计划更加稳定可靠。
3. LLM + 搜索树：ToT（Tree of Thoughts）使模型能够同时展开多条候选路径，并进行评估和回溯——这是唯一突破CoT线性结构的方法，但其代价是token消耗巨大。
4. LLM + Symbolic 混合：将“步骤顺序约束”、“资源依赖”、“失败阈值”等规则交给symbolic planner（如PDDL类）管理，而LLM仅负责将子目标翻译为具体动作。对于工业界的长周期任务，这一路径很可能是主流方向。

五、一句收得住的话

综上所述，当前多数Agent宣传材料中所谓的“自主规划”，用工程实话翻译过来就是：在系统提示词中嵌入一段Think/Act/Observe模板，外部包裹一个while-loop循环，由LLM负责每轮填充Thought和Action的文本。这种机制使模型“看起来像是在规划”，但模型本身既没有状态机，也不支持回溯，更缺乏对计划的元认知能力——本质上，CoT只是被prompt模板和代码骨架夹了一下，披上了一件名为Planning的外衣。

真正的规划能力，需要等待以下两件事之一取得突破：要么是LLM自身进化出“带状态管理且能重规划”的推理模式（这并非o1那种内部化的CoT，而是真正过程级的规划），要么是Agent框架将symbolic规划、搜索树、reflexion等“非LLM部分”做得足够强大，以至于规划者不再是LLM的独角戏，而是LLM与结构引擎的双人协奏。在此突破发生之前，对于“Agent具备规划能力”这一说法，建议默认将其打上折扣来解读。