规划与推理 (Planning & Reasoning)
很多人第一次做 Agent 时，会天然觉得“大模型已经很聪明了，直接让它做事就行”。结果一到稍微复杂一点的任务，比如改一个真实项目、写一个完整功能、联动多个工具，它就开始乱跳步骤，不是漏需求，就是做到一半偏题。
这时候你会发现，模型会不会“规划”，比它会不会“说”更重要。
[PROMPT_LAB_BANNER]
1. 为什么 Agent 需要 Planning
如果用户只问一个简单问题，比如“Python 里 list 和 tuple 有什么区别”，很多时候直接回答就够了。
但如果任务变成：
- 帮我写一个贪吃蛇游戏
- 帮我重构这个 React 页面
- 帮我查资料后给出一份选型建议
那问题就不再是生成一段文本，而是要把一个模糊目标拆成多个阶段，再一步步执行。
Agent 如果没有规划层，常见表现通常是：
- 上来就做实现，没先确认约束
- 先写了容易写的部分，真正关键的问题没碰
- 执行过程中发现方向不对，但不会回头调整
- 明明任务还没完成，却很快给出“已经好了”的假结束
所以 Planning 的本质，不是为了让输出看起来高级，而是为了降低复杂任务里的随机性。
2. 先做任务分解，不要直接扑到代码上
任务分解（Decomposition）本质上是在回答一个问题：
这个目标，最合理的执行顺序是什么？
拿“写一个贪吃蛇游戏”举例，靠谱的 Agent 通常不会第一步就输出完整代码，而是先把任务拆开：
- 明确玩法边界：键盘控制、碰撞规则、计分方式。
- 决定技术方案：纯 HTML/CSS/JS，还是 Canvas。
- 拆文件结构：界面、游戏循环、状态管理、输入处理。
- 先做最小可运行版本，再补动画、音效、优化。
这个顺序听起来普通，但它已经比“直接生成 300 行代码”稳定得多，因为它把大问题拆成了可验证的小问题。
做法 A：让 LLM 先出计划
最轻量的方式，就是让模型先列步骤，再开始执行。
比如：
请先给出实现方案，不要立刻写代码。把任务拆成 5 到 7 个步骤，并标出哪些步骤需要先验证。
这招很实用，尤其适合代码 Agent、写作 Agent、研究型 Agent。
但要注意，模型给出的计划不一定靠谱。它有时候会列得很完整，却顺序不对，或者把真正困难的地方轻描淡写带过去。所以计划不是看“写得像不像”，而是看“执行起来顺不顺”。
做法 B：分层规划
如果任务更复杂，可以把规划分成两层：
- 上层 Agent 负责决定方向和拆阶段
- 下层 Agent 负责执行单个子任务
这种方式在多 Agent 系统里很常见。
例如你在做一个 coding agent：
- Planner 先决定“先读代码，再定位问题，再修改，再测试”
- Coder 负责具体写代码
- Reviewer 负责检查回归风险
这样做的好处是，每个 Agent 的职责更清晰，不用都把整个世界装进一个上下文里。
3. 推理模式怎么选，不用每次都上高级玩法
说到推理，大家很容易马上想到各种术语，比如 Chain of Thought、Tree of Thoughts、Reflexion。它们确实有用，但别把它们当成“必须全配”的套餐。
很多时候，关键不是你有没有用最复杂的推理框架，而是你有没有选对场景。
Chain of Thought
这是最基础也最常用的一种。简单说，就是要求模型别直接报答案，而是先把思路走一遍。
它适合：
- 需要解释过程的问题
- 需要多步判断的任务
- 需要先分析再决定的场景
在工程里，CoT 最常见的价值不是“更聪明”，而是更容易 debug。模型如果答错了，你至少能看到它错在第几步。
Tree of Thoughts
如果任务存在多个分支，而且可能需要回溯，树状探索会更合适。
典型场景包括：
- 创意方案生成
- 多路线问题求解
- 复杂搜索或策略对比
它的核心不是让模型“想得更多”，而是允许模型保留多个候选方向，不要在第一条路上死磕到底。
graph TD
subgraph "Chain of Thought (线性)"
A[Step 1] --> B[Step 2] --> C[Step 3]
end
subgraph "Tree of Thoughts (树状)"
Root[初始状态] --> P1[路径 A]
Root --> P2[路径 B]
Root --> P3[路径 C]
P1 --> P1_1[A 的下一步]
P2 --> P2_1[B 的下一步]
P3 --> P3_1[C 的下一步]
end
不过实话说，在很多业务系统里，ToT 的理论吸引力大于实际收益。它更适合少量高价值任务，不太适合每次请求都开一棵搜索树，否则成本会很快上来。
4. 真正让 Agent 变稳的，通常是“会复盘”
只会规划还不够。很多 Agent 的问题不在“不会开始”，而在“做错以后不会纠正”。
这就是 Self-Reflection 或 Reflexion 一类方法有价值的地方。
一个常见闭环可以这样理解：
- Actor 先尝试执行任务
- Evaluator 检查结果，比如跑测试、校验格式、比对预期
- Reflection 用自然语言总结这次失败的原因
- Retry 带着修正后的策略再做一次
这套机制在 coding agent 上特别常见。因为代码任务的好处是“能验”，测试过不了就是过不了，不太需要靠主观判断。
例如模型第一次改代码失败，反思里可能记录：
之前只修了渲染逻辑，没有检查服务端和客户端输出是否一致。下一轮优先看 hydration mismatch 的根因，不要继续改样式层。
这种反思一旦保留下来，下一轮的质量通常会明显比“从头再猜一次”更高。
5. Planning 在实战里怎么落地
如果你不是在写论文，而是在做产品，我更建议用下面这些实用做法。
先出 plan，再执行
这是最稳的一步。哪怕只是一个很短的 todo list，也比没有强。
例如：
- 先确认目标和限制
- 再列 3 到 6 个步骤
- 每完成一步，更新状态
- 如果发现前提变了，就重排后续步骤
这能明显减少 Agent 一路跑偏的问题。
把计划存成显式状态
不要把计划只放在自然语言里。最好有一个结构化状态对象，明确记录：
- 当前目标
- 已完成步骤
- 阻塞点
- 下一步动作
这样做的好处是，哪怕换了一个 Agent 接手，也能快速知道现在任务走到哪一步。
允许 Replanning
很多人写规划模块时，默认计划一旦生成就不动了。现实里这几乎不成立。
Agent 在执行中经常会遇到新信息，比如：
- 文件结构和预期不一样
- API 权限不够
- 用户中途补充新约束
这时候一个靠谱的系统应该允许改计划，而不是硬着头皮继续执行旧步骤。
把“最难验证”的步骤提前
这是个很实用但经常被忽略的技巧。
例如你要接一个第三方 API，不要先把页面全搭好，再发现 token 权限不够。应该先验证 API 能不能通、核心依赖能不能跑，再继续往后做。
把高风险步骤前置，能省掉很多无效工作。
6. 一个够用的经验法则
如果你现在正在搭 Agent，可以先用这套很朴素的判断：
- 简单任务：直接做，最多加一步轻量推理
- 多步骤任务：先拆解，再执行
- 高失败成本任务：加验证和反思循环
- 多分支探索任务：再考虑树状搜索或多方案评估
不要一上来就把所有高级模式都堆进去。很多系统最后不稳定，不是因为规划不够复杂，而是因为每一层都很重，结果没人能维护。
小结
Planning 不是给 Agent 增加“仪式感”，而是让它在复杂任务里少走弯路。
真正有用的规划，通常有三个特征：
- 能拆成可执行步骤
- 能在执行中更新
- 能在失败后复盘
做到这三点，Agent 的表现通常就会从“偶尔很惊艳，但不稳定”，变成“没那么花哨，但真的能持续把事做完”。
