第 8 章：规划不是写给人看的漂亮计划
本章目标：讲清 Agent 里的规划到底是什么，它为什么不是装饰，也不是一份好看的文档，而是系统减少盲动、组织动作和处理分支的核心机制。
本章对应总纲：docs/ebook-outline.md中“第 8 章正文写作提纲（2026-03-31 归档）”。
8.1 为什么很多人一说“规划”就理解错方向
一提到 planning，很多人脑子里立刻出现的是：
- 先写一个计划书
- 把步骤列出来
- 看上去很完整
- 好像很有条理
然后就觉得系统已经会规划了。
这不对。
因为在 Agent 系统里，规划真正解决的问题不是“写得像不像计划”，而是：
系统在行动之前，能不能先组织动作；在行动之后，能不能根据反馈调整路径。
如果没有这两点，再漂亮的计划也只是展示，不是执行机制。
8.2 规划到底在解决什么问题
一个真实 Agent 在运行时，通常都要面对三类困难：
- 目标不是一步能完成的
- 动作之间存在依赖关系
- 中途反馈会改变原路径
规划层存在的意义，就是为了处理这三件事。
8.2.1 把模糊目标拆成可执行步骤
用户说：
帮我给这个项目加一个导出功能。
这不是一步动作，而是一串潜在动作：
- 找现有数据结构
- 找导出入口
- 确认格式要求
- 修改代码
- 运行验证
- 检查副作用
如果系统没有规划能力，它很容易一上来就乱改。
8.2.2 识别先后依赖
很多任务不是“想做什么就先做什么”。
例如：
- 不先读定义，就不该直接改实现
- 不先确认接口边界，就不该动调用链
- 不先验证问题复现，就不该自信修复
规划层要做的，就是把依赖关系提前看出来。
8.2.3 在路径分叉时选更合理的一条
同一个任务往往有不止一种路径：
- 先搜索还是先读文件？
- 先改局部还是先查根因？
- 先问用户还是先补足上下文？
规划的价值，不是保证永远选对，而是减少盲撞。
8.3 规划不是一次性的，决策发生在每一轮
8.3.1 前置规划只是一半
很多人对规划的理解停在任务开头：
- 先列步骤
- 然后开始执行
这最多只完成了一半。
因为真实 Agent 不是按静态剧本跑，而是边跑边接反馈。于是规划实际上至少分成两层：
- 前置规划：先大致设计路径
- 过程决策：每轮根据反馈继续调整
8.3.2 为什么过程决策比计划书更重要
计划书可以写得很漂亮，但真正决定系统质量的，往往是执行中的这些判断：
- 当前是不是该继续当前路径？
- 这个错误说明方向错了，还是只差补一步？
- 现在该继续搜，还是该停下来问人？
- 当前目标是否已经满足，可以停机？
所以从工程角度看，规划不是文档，而是一种持续决策能力。
8.4 好规划的标准，不是完整，而是有用
很多人做规划，最容易滑向一个坏习惯：
- 把所有能想到的步骤都列出来
- 把所有可能性都写进去
- 结果看起来很全
但执行时根本用不上。
8.4.1 过度规划的典型味道
最常见的症状是：
- 步骤太细，稍微环境一变就废了
- 分支太多，主线反而看不清
- 计划长度很长，但关键依赖没说清
- 计划里混进大量“也许以后会需要”的假想步骤
这不是严谨，这是噪音。
8.4.2 好规划应该保留什么
一个对 Agent 真正有用的规划，通常至少要包含：
- 当前目标
- 关键步骤
- 主要依赖
- 关键风险点
- 何时验证
- 何时停止或求助
这已经足够驱动系统了。再往上堆，往往收益很小。
8.5 规划和工作流不是一回事
这里也必须切一刀。
工作流更像：
- 预定义好的执行顺序
- 固定步骤之间的机械衔接
- 已知路径问题的自动化
规划更像：
- 在当前任务和当前环境下组织路径
- 识别依赖和风险
- 在变化中重选下一步
所以：
- 工作流偏固定
- 规划偏动态
可以直接用这张判断表来区分：
| 问题特征 | 更适合 Workflow | 更适合 Planning |
|---|---|---|
| 步骤是否稳定 | 是 | 否 |
| 分支是否很少 | 是 | 否 |
| 中途是否常改路 | 否 | 是 |
| 是否依赖实时反馈 | 弱 | 强 |
| 是否需要临场判断 | 弱 | 强 |
这也是为什么不是所有自动化都需要 Agent。
如果一个任务路径稳定、分支少、失败处理也固定，那 workflow 往往更便宜、更可靠。
只有当任务需要动态决策时，规划层才真正变得不可替代。
8.6 规划和执行之间，最重要的是验证点
很多系统看起来会规划，实际仍然很蠢。原因是它们少了一样东西：验证点。
8.6.1 为什么没有验证点的计划很危险
如果系统只是：
- 列步骤
- 机械执行
- 直到全部做完才回头看
那它很容易在错误路径上跑很远。
8.6.2 验证点本质上是在问：现在还走对吗？
在好的规划里，关键步骤之间通常要插入验证点，例如：
- 读完关键文件后，先确认问题定位是否成立
- 改完代码后，先跑检查
- 用户边界不清时，先停下来确认
- 路径分叉明显时，先判断是否继续当前思路
这说明规划不是单向推进，而是推进 + 校验。
没有校验，规划就只是更有条理的盲跑。
8.7 回退能力：规划成熟不成熟，看它会不会承认原路错了
一个真实系统几乎不可能永远第一次就选对路径。
所以判断规划层成熟不成熟，一个很硬的标准就是：
它有没有回退能力。
8.7.1 什么叫回退
回退不是简单地“失败了重来”，而是：
- 承认当前假设被证伪
- 放弃旧路径的后续动作
- 把已获得的负面信息保留下来
- 换一条更合理的路径继续推进
8.7.2 为什么很多系统不会回退
因为它们的规划只是静态步骤表。
一旦进入执行，就会出现两个极端：
- 要么死撑到底
- 要么彻底崩掉
这两种都不成熟。
成熟的 Agent 应该能做到：
- 错了就回
- 但不是全盘失忆
- 而是带着已知失败信息重新决策
8.8 用 Claude Code 看一个现实中的规划样本
Claude Code 这类系统很适合用来理解规划层，因为它并不是一收到任务就无脑开干。
从当前项目能直接看见几条很明显的规划线索：
plugins/README.md:19的feature-dev不是一个“直接写代码”的单步命令，而是明确写成 structured 7-phase approach- 同一个插件又拆出
code-explorer、code-architect、code-reviewer三种角色，说明规划不是一团话术，而是先探索、再定结构、再做质量回看 plugins/README.md:16和plugins/README.md:24里的多 Agent 审查插件也在说明：复杂任务先拆视角，再收敛，不要一上来把所有判断压成一个动作examples/settings/settings-strict.json:1又提醒你，规划从来不只是“怎么做”，还包括“哪些路当前根本不该走”
所以现实系统里的规划，不是“写一个计划文件”这么浅，而是把几类判断压进执行结构里：
- 先探索还是先实现
- 先拆角色还是自己完成
- 关键验证点插在哪
- 哪些路径因权限或风险直接排除
- 当前失败后是补一步还是回退换路
这背后其实对应几条很硬的设计规则：
- 规划先解决动作组织，再解决文档表达
- 复杂任务先拆阶段，别一把梭
- 验证点必须进规划，不然计划只是更整齐的盲跑
- 风险边界本身也是规划输入，不是执行到一半才补想起来
这才是现实里的 planning：不是写得像项目计划，而是能稳定改变后续执行质量。
如果把话再说死一点：规划解决的是单条执行链里的路径组织、验证插点和回退时机；一旦执行单元不止一个，这个问题就会进一步升级成后面要讲的编排问题。
8.9 为什么“先规划一下”也可能变成表演
这里也得说一句难听的话。
不是所有“先规划一下”都真的有价值。很多时候它只是另一种形式的拖延和表演。
典型表现是：
- 计划写得很长
- 但没有关键依赖
- 没有验证点
- 没有停机条件
- 没有回退策略
- 最后执行时还是临场瞎猜
这种规划只是把混乱提前写出来，并没有减少混乱。
所以判断规划有没有用，不看它写了多少，而看它是否真正改变了执行质量。
8.10 本章小结
这一章真正想讲清的是：规划不是写给人看的漂亮计划，而是 Agent 减少盲动、组织动作和处理变化的核心机制。
你现在应该记住六件事：
- 规划解决的是多步目标、动作依赖和路径分叉问题。
- 真正的规划不只是任务开始前列步骤，而是每一轮都在持续决策。
- 好规划的标准不是更完整，而是更能驱动执行。
- 规划和工作流不是一回事，前者偏动态，后者偏固定。
- 验证点和回退能力，是判断规划层是否成熟的硬指标。
- 没有验证和回退的“规划”，大多只是更有条理的盲跑。
下一章我们继续往下走，看一个 Agent 系统到底该在什么时候停下、什么时候问人、什么时候必须把控制权交还给用户。