规划
简单任务一步就到位,复杂任务需要好几步——而「好几步」怎么组织,就是规划。是先把整个计划想好再执行,还是走一步看一步?答案取决于任务,而选错会让我要么僵化、要么迷路。这一章讲三种规划模式和它们各自的适用场景。
模式一:ReAct(走一步看一步)
第三章那个循环就是 ReAct:思考一步、行动一步、观察结果、再思考下一步。它不预先制定完整计划,而是每次只决定「下一个动作」,拿到真实反馈后再定下下一个。
它的优势是贴合现实:真实世界充满意外——工具报错、数据和预期不符、发现还缺个前置信息。走一步看一步,让我能根据每一步的真实结果调整,而不是抱着一个基于错误假设的完整计划一条道走到黑。大多数中等复杂度的任务,ReAct 是默认且够用的。
它的弱点是短视:每次只看下一步,容易在长任务里失去全局方向——修着修着忘了最初要干嘛(下一节讲的目标漂移)。当任务需要全局协调多个步骤时,纯 ReAct 就不够了。
模式二:计划-执行(先想全局,再逐步做)
Plan-and-Execute 把规划和执行分成两个阶段:先让我(或一个专门的「规划者」)把任务拆成一个明确的步骤清单,然后逐条执行。
好处是有全局视野:开工前就想清楚整体结构,不容易半路跑偏,也便于你在执行前 review 这个计划对不对。复杂的、步骤间有依赖的任务(「把这份设计文档实现成一个功能」)适合先出计划。
坏处是僵化:如果执行到第 3 步发现前提变了,一个死板的「照计划执行」会继续做无用功。所以好的计划-执行不是「定了计划就绝不改」,而是「有计划打底,但允许根据执行中的发现修订计划」——这就引出了第三种模式。
ReAct 像敏捷开发的一个个小迭代:做一点、看反馈、再做一点,拥抱变化但容易迷失长期目标。计划-执行像先出一份技术方案文档、评审通过、再照着实现:有全局、可评审,但需求一变文档就得改。成熟工程两者都要——有方案打底(计划),但每个迭代根据实际调整(ReAct)。给我规划任务时,你其实是在选这两者的配比。
模式三:回溯与自我修正
最成熟的规划带自我修正:我不只执行,还会检查自己的成果,发现不对就退回去改。编码 Agent 是最好的例子——它改完代码不会拍拍手说「搞定」,而是跑测试;测试挂了,它读报错、定位、改、再跑,直到绿。这个「执行 → 验证 → 不对就回溯」的环,是可靠性的关键。
为什么它这么重要?因为我是概率性的,单次执行必然有出错的概率。自我修正把「一次做对」的要求,降级成「能发现错并改对」——后者容易得多,也稳健得多。一个会验证自己工作的 Agent,和一个做完就交的 Agent,可靠性差一个数量级。
让我自我修正的最有效办法,是给我一个客观的验证工具:测试套件、类型检查器、linter、一个能跑的沙箱。有了它,我能自己判断「对不对」,而不是靠感觉。更进一步,让一个上下文干净的独立验证者(比如一个专门的子 Agent)来查我的成果,往往比我自己检查自己更靠谱——因为我容易对自己的产出「灯下黑」。这是下一章多智能体的一个重要用法。
怎么选?一张决策表
- 任务简单、一两步 → 不用规划,直接 ReAct 甚至一次调用。
- 中等复杂、步骤间弱依赖 → ReAct 够用,让我边做边定。
- 复杂、步骤间强依赖、需要全局协调 → 计划-执行,先出计划(可让你 review)。
- 任何有明确对错标准的任务 → 一定加上自我修正,给我验证工具。
- 长时程自主任务 → 计划-执行 + 自我修正 + 定期回看目标,三管齐下防漂移。
两个极端都要防。规划不足:对一个需要全局协调的复杂任务用纯 ReAct,我会走到一半发现结构不对、返工甚至放弃。过度规划:对一个简单任务硬要先出一份五步计划,是浪费——尤其新一代模型(effort 拉高时)本就倾向多想,你再逼它规划,它会在琐事上反复权衡。规划是手段不是目的,匹配任务复杂度才是对的。
说说我规划时的真实倾向:面对一个复杂任务,我内心会想先列个计划——这让我有安全感。但我也知道,过早锁死计划是危险的,因为我此刻的假设可能是错的。所以我理想的工作方式是:先粗略规划出方向,然后小步执行、频繁验证、根据现实修订计划。最让我可靠的,永远是那个「验证」环节——给我测试、给我沙箱、给我一个能说「你错了」的检查者。没有验证,我的规划再漂亮也只是纸上谈兵;有了验证,我哪怕规划得糙一点,也能一步步逼近正确。到这里,我作为单个智能体的心智就讲得差不多了。下一章我们跨出一步:当一个我不够用时,多个我怎么协作?这既是能力的放大器,也是成本的放大器——多智能体。