A_ made by arjun

2026.09.01 · WRITING

Agent 是怎么做计划的：从任务拆解到搜索与重规划

计划不是越长越好。本文从一个 Go 服务迁移任务出发，拆解 Plan-and-Execute、Replanning、ToT、GoT、Reflexion 与经典规划器各自解决的问题。

给 Agent 一个复杂任务，它很容易在几秒内列出十几步。列表看起来完整，真正执行时却常常从第二步就开始偏离。

问题不一定是模型不会列计划，而是它在还没看过代码、日志和约束时，就把未知信息写成了确定步骤。

假设任务是：

把一个陌生 Go 服务的鉴权逻辑迁到统一身份服务，保持现有 API 兼容，并给出可回滚的上线方案。

在读取仓库之前，Agent 可以猜到要分析接口、修改代码、运行测试和准备发布。但它不知道鉴权逻辑散落在哪些包里，不知道现有测试能覆盖什么，也不知道调用方是否依赖某些未写进文档的行为。

所以，一份有用的计划不能只是步骤清单。它至少要回答四件事：当前要解决什么、步骤之间有什么依赖、怎样判断一步已经完成，以及新证据出现后哪些步骤需要改变。

规划不是 Agent 的“神秘大脑”

Planning 经常被说成 Agent 与 Chatbot 的分水岭，这个说法太绝对。

一个系统可以不生成完整计划，只根据当前状态选择下一次工具调用。ReAct 展示的就是推理轨迹与行动交错推进：行动返回的信息会帮助系统跟踪、更新计划并处理例外。反过来，一个普通 Workflow 也可以先生成任务清单，但后续仍然沿着预先写好的路径执行。

因此，更实用的判断不是“它有没有写计划”，而是：

计划只是 Agent 状态的一部分。真正让它发挥作用的，是计划、行动、Observation 和 Runtime 之间的循环。

Chain-of-Thought 不等于计划

Chain-of-Thought（CoT）首先是一种推理提示方法。Wei 等人在 2022 年的论文中，通过提供带有中间推理步骤的 Few-shot 示例，提升了大模型在算术、常识和符号推理任务上的表现。

常见的 Zero-shot CoT，也就是加入“Let’s think step by step”，来自 Kojima 等人的另一篇 2022 年论文。它不应该和最初的 Few-shot CoT 被混成同一种实验设置。

CoT 可以帮助模型展开一个问题，但一段推理文本还不是工程意义上的执行计划。计划通常需要成为可以保存和更新的结构化状态，例如：

[
  {
    "id": "inspect-auth-boundary",
    "goal": "确认现有鉴权入口和调用关系",
    "depends_on": [],
    "done_when": "入口、依赖方和现有测试均已记录",
    "status": "in_progress"
  }
]

这里最重要的不是让模型公开一大段“内心独白”，而是让 Runtime 能判断：当前在做哪一步、依据是什么、完成条件是什么。

推理文本经过 Runtime 后，成为可保存和更新的结构化 Plan State
推理可以形成候选判断；真正进入执行之前，Runtime 还需要把它提取、校验并保存为可管理的状态。

第一种实用结构：Plan-and-Execute

Plan-and-Execute 把规划和执行分开。Planner 先拆解任务，Executor 再逐项完成。

在前面的迁移任务里，初始计划可能只有四步：

  1. 找到鉴权入口、调用方和数据依赖；
  2. 记录必须保持兼容的行为；
  3. 设计迁移边界、回滚路径和验证方式；
  4. 分批修改并运行对应测试。

这种结构的价值在于，规划器可以先看清依赖，执行器不必在每一步重新理解整个目标。它适合任务可以拆开、依赖关系相对清楚的场景。

但“先计划、再执行”不应该理解成计划一旦生成就不能动。如果第一步发现项目里同时存在 Cookie、JWT 和内部签名三套鉴权方式，后面三步就必须更新。继续照着原计划执行，只是在自动化地走错路。

比完整计划更重要的是重规划

真实任务里，计划通常是一个暂时成立的假设。

检查现场 → 生成当前计划 → 执行一步 → 读取结果
    ↑                                  ↓
    └──── 保留有效部分，修改受影响步骤 ────┘

重规划不等于每次失败都推倒重来。更稳妥的做法是保留已经验证的事实，只替换受到新证据影响的部分。

例如，Agent 已经确认了 API 兼容要求，但测试显示旧客户端依赖一个未记录的错误码。这时需要修改兼容层和测试计划，不需要重新调查所有鉴权入口。

工程上可以把这些情况设成明确的 Replan Trigger：

这样做比让模型凭感觉决定“要不要重新想一遍”更容易控制。

Agent 检查现场、生成计划、执行、观察，并在触发条件出现时局部重规划
重规划不等于推倒重来：已经验证的事实应该保留，只修改被新证据影响的步骤。

Self-Consistency：多采样，不是多步骤计划

Self-Consistency 经常和规划方法放在一起讲，但它原本是一种解码策略。

它会对同一个问题采样多条不同的推理路径，再根据最终答案的一致性进行聚合。论文的表述是对采样出的推理路径进行边缘化，而不是让这些路径在推理过程中互相交换信息。

它适合有相对明确答案、又允许多种推导方式的任务，例如部分数学和常识推理问题。它不直接解决“下一步该调用哪个工具”或“执行失败后怎样改计划”。

代价也很直观：采样次数越多，模型调用和 token 消耗越高。如果任务没有可以可靠聚合的答案，多生成几份意见不一定更接近事实。

Tree of Thoughts：把候选路径变成显式搜索

Tree of Thoughts（ToT）处理的是另一类问题：当前存在多个候选方向，过早选错一条路会影响整个结果。

ToT 把较大的推理单元作为 Thought 节点，生成多个候选状态，对它们进行评估，再选择部分分支继续展开。需要时，搜索过程可以向前看，也可以回退。原论文在 Game of 24、创意写作和迷你填字游戏上进行了实验。

它与普通 CoT 的关键差别不是“文字变成了树形排版”，而是 Runtime 显式管理了候选状态、评估和搜索过程。

ToT 也有明显边界。分支越多，调用成本越高；负责评估候选状态的模型如果判断不准，正确分支可能很早就被剪掉。它适合搜索空间有限、候选状态可以比较的任务，不适合无差别地套在所有 Agent 上。

Graph of Thoughts：允许分支重新汇合

Tree 中的一个节点通常只有一条父路径。Graph of Thoughts（GoT）进一步允许 Thought 之间形成更自由的依赖关系，还可以把多个中间结果聚合成一个新结果，或者通过反馈回路继续改进某个 Thought。

这对“先分后合”的任务很有启发。例如先分别分析多个模块，再把各模块的迁移风险合并成一份全局方案。

但 GoT 是一种更通用的研究框架，不是“比 ToT 高一级，所以工程上应该优先使用”的默认答案。原论文展示的是若干特定任务上的收益。换到新的任务、模型和评估方式，是否值得增加图调度复杂度，仍然需要实测。

Reflexion：保存文字反馈，不是更新模型权重

Reflexion 关注的是跨尝试改进。一次任务失败后，Agent 根据反馈生成文字形式的反思，并把它放进 Episodic Memory，后续尝试再读取这些内容。

论文明确说明，Reflexion 不通过更新模型权重来学习。它改变的是后续推理时可以看到的语言反馈。

因此，它能否工作依赖反馈质量。如果测试结果、环境奖励或评审意见足够可靠，反思可以帮助下一次避开同样的问题。如果反馈本身含糊或错误，记忆只会把错误经验带到下一次尝试。

Reflexion 可以帮助计划改进，但它与任务拆解、搜索策略不是同一层概念。

LLM+P：把严格规划交给经典规划器

有些任务具有明确动作、前置条件和目标状态，例如受控环境中的机器人操作或形式化调度。LLM+P 的思路是让 LLM 把自然语言问题转换成 PDDL，再调用经典规划器求解，最后把结果翻译回自然语言。

这条路线把自然语言理解和符号搜索分开：LLM 负责翻译，规划器负责在形式化模型中寻找可行或最优方案。

需要注意，规划器的正确性建立在形式化描述正确的前提上。如果 LLM 漏掉了一个前置条件，或者把动作效果翻译错了，后面的规划器再严格，也是在解决错误的问题。

CoT、Self-Consistency、ToT、GoT、Reflexion 与 LLM+P 所处的不同系统层次
这些方法解决的是不同层的问题。它们可以组合，但不是一条从低到高的统一升级路线。

不要按“链、树、图”选型

CoT、Self-Consistency、ToT、GoT、Reflexion 和 LLM+P 解决的不是同一个层面的问题，把它们排成一条统一升级路线会误导工程选型。

更合适的判断顺序是：

  1. 下一步是否能由代码预先确定？如果能，优先使用 Workflow。
  2. 任务能否拆开，但执行结果会改变后续步骤？使用 Plan-and-Execute，并加入 Replanning。
  3. 是否存在多个候选路径，而且中间状态可以比较？再考虑 ToT 一类搜索。
  4. 是否需要合并多个分支的中间结果？可以考虑图式编排或 Orchestrator-Worker。
  5. 是否存在严格约束和可形式化的动作模型？外部规划器往往比纯文本推理更合适。
  6. 是否需要利用多次尝试的可靠反馈？再加入 Reflexion 一类记忆机制。

Self-Consistency 更像“为同一个答案多采样几次”，它可以与其中某些结构组合，但不替代执行计划。

根据任务特征选择 Workflow、Plan 加 Replan、ToT、图式编排或外部规划器
先判断任务的路径、反馈、分支、聚合与约束，再决定该用哪一种规划结构。

一份可运行的计划应该保存什么

在生产系统里，我更愿意看到一份短而明确的 Plan State，而不是一篇很长的推理作文。它至少包含：

这些字段可以被保存、检查和恢复。系统崩溃后，Runtime 也能知道已经完成了什么，而不是让模型重新读完整段聊天记录再猜一次。

计划写得长，不代表 Agent 看得远。多数时候，那只是它在信息不足时猜得更多。

真正有用的计划应该短到可以执行，明确到可以验收，也愿意在证据变化时改掉自己。

参考资料