Agent 规划不是提示词加长，而是任务被重新切开

很多人第一次接触 Agent，会把它理解成“更长的 prompt + 更强的模型”。这个说法不算错，但只够解释演示，不够解释系统。
真正让 Agent 和单轮问答拉开差距的，是它开始把一个目标拆成一串可执行、可检查、可回退的步骤。

为什么规划层单独值得研究

短任务里，模型往往能直接给出像样答案，所以规划看起来像可有可无。
但只要任务变长，问题立刻就出现了：

• 目标会在执行过程中变形
• 上下文会被中间噪声稀释
• 工具调用会把错误放大
• 前一步的偏差会传导到后一步

所以规划层的意义，不是让模型“先想一想”，而是把原本混在一起的工作显式拆开：

• 先定义目标
• 再列出约束
• 再决定执行顺序
• 最后给每一步留出检查点

一个更实用的规划框架

我现在更偏向把 Agent 规划理解成四层结构。

1. 目标重写

用户给出的目标通常是模糊的，甚至是混合型的。
比如“帮我把这个项目整理好”里，可能同时包含代码修复、文档归纳、部署验证和风险排查。

规划器第一步不该急着分步，而是先把目标重写成：

• 最终产物是什么
• 哪些约束不能碰
• 哪些结果可以接受为“暂时完成”

2. 子任务切分

切分不是越细越好。
太粗，执行器会重新临场发挥；太细，又会让系统陷入机械调度，反而失去效率。

一个好用的经验是：每个子任务都应该有清晰的输入、可观察的输出，以及一句能被单独验证的完成定义。

3. 执行顺序编排

很多失败并不是能力不足，而是顺序错误。
例如先改代码再理解测试失败原因，通常会让整个流程越改越乱。

我更看重下面三种排序逻辑：

• 先做高不确定性任务，再做低不确定性任务
• 先做能缩小搜索空间的任务，再做具体实现
• 先确认外部约束，再进行内部优化

4. 检查点与回退

Agent 规划如果没有回退机制，本质上还是一次性生成。
真正稳定的系统，应该允许它在阶段性失败后收缩问题、重写计划、甚至放弃一条已经走偏的路径。

这也是为什么我越来越不相信“完整计划一次生成后严格执行”的方案。
现实任务里，计划更像活文档，而不是施工蓝图。

我现在最关注的三个研究问题

计划能否被持续修正

很多系统会生成计划，但不会更新计划。
一旦环境变化、工具返回异常或者用户追加要求，原计划就立刻失效。

所以更值得研究的不是“如何生成计划”，而是：

• 什么时候应该重规划
• 什么证据足以触发重规划
• 重规划后怎样保留已经完成的部分

规划器和执行器是否应该分离

把所有能力都压进一个模型里当然省事，但代价是行为边界模糊。
规划器适合做抽象、压缩、排序；执行器适合做具体操作、局部判断和工具调用。

二者分离的好处在于：

• 计划更稳定
• 错误更容易归因
• 成本更容易控制

规划是否应该显式考虑成本

这是很容易被忽略的一点。
一个“理论上最好”的计划，未必是“真实系统里最划算”的计划。

未来真正能落地的 Agent 规划，应该把这些约束一起放进去：

• token 成本
• 工具调用次数
• 等待延迟
• 人工确认门槛

结尾

我越来越觉得，Agent 的规划问题和传统意义上的“提示词工程”已经不是同一个层级。
前者关心的是系统如何组织工作，后者更像是局部交互的优化。

如果后面继续往下挖，我最想看的不是谁又做出了更长的链路，而是谁先把“会执行、会修正、会停下来检查”的规划层真正做稳。