先列清单,再一条条执行 — 一份漂亮计划是怎么跑砸的
这一章讲三件事: 为什么要换一种分工;换完之后一趟真实的任务长什么样; 以及那份看起来很漂亮的计划为什么救不了它。
它在全书链条里的位置: 第 03 到 05 章那一圈是「走一步看一步」。 这一章是这本书给出的第二种转法:先把步骤全想好,再照着走。 第 11 章那个「自己给自己派活」是它的更激进版本。
1. 一圈圈转下去,提示词会越写越长
这一节讲换分工的动机。它是第 08 章那笔账的直接后果。
书自己把上一种转法的问题写得很清楚。原文的推导有三步1:
- 为了让程序既盯着最终目标、又记得住之前的步骤,提示词里要纳入越来越多的历史信息;
- 为了提高工具调用的可靠性,提示词里又要塞进更多「这个工具怎么用」的说明;
- 于是模型往往不堪重负,在几个轮次之后会出现各种各样的问题。
请 把这三步和第 08 章第 5 节那笔账对上: 那一节算过, 一趟鲜花定价里,光是搜索返回的十条摘要就有六七百字,而且每轮都要重发。 第 1 条说的就是这件事。
书还给了一个背景:随着越来越多的人准备把这类程序放到真实业务里, 对「能处理更复杂请求」和「更可靠」的要求同时变高1。 这两件事一起变高,就把上一种转法逼到了墙角。
2. 换个分工:先列清单,再一条条执行
这一节讲这本书给出的第二种转法,它的名字和它的做法一样朴素。
书引的那篇论文提出的做法只有一句话:为了解决多步推理任务, 应该首先规划要采取的步骤,然后逐步执行这些步骤2。
书里学生把它总结成五个字:计划和执行的解耦3。作者的回应是「大道至简」。
为什么「先想好」会比「走一步看一步」好? 书给了一个非常具体的对照4:
题目: 一个有 20 名学生的舞蹈班,20% 的学生选现代舞, 剩下的学生中有 25% 选爵士舞,其余选嘻哈舞。整个班级中有多少百分比的学生选嘻哈舞?
只让它一步步想: 答案给成 55%——错的。
让它先列步骤再执行: 步骤 1,20 人的 20% 是 4 人选现代舞;剩下 16 人的 25% 是 4 人选爵士舞,共 8 人; 步骤 2,剩下 12 人选嘻哈舞; 步骤 3,12 ÷ 20 = 60%——对的。
给这两个数配参照:55% 和 60% 只差 5 个百分点,可一个对一个错。 而差别只在于:后者先把「要算哪三步」写了出来。
3. 计划者是一个模型,执行者也是一个模型
这一节讲这套东西的零件,其中第二个零件很容易被看漏。
书给的结构只有两块5:
计划者是一个大模型。 它用推理能力规划要做的事,以及可能遇到的边缘情况; 产出的原始文字再经过一次解析,变成一个清晰的步骤列表,每个字符串代表一步。
执行者也是一个大模型——而且执行者本身就是一个转圈的 agent。
第二块请读两遍。 书的原话是: 在这个框架的实现中,执行者本身就是一个 ReAct Agent; 这允许它接受一个高级目标(单个步骤)并使用工具去实现它, 可以一步完成,也可以两步完成5。
你的一句话
│
▼
┌──────────┐ 一次模型调用
│ 计划者 │ ──────────────▶ ["第1步…", "第2步…", …, "第8步…"]
└──────────┘
│
▼ for 每一步:
┌──────────┐
│ 执行者 │ ← 这里面是第 03 到 05 章那一整圈,能自己转好 几轮
└──────────┘
│
▼
把这一步的产出接在后面,进入下一步
图说:外层是一条直线(照单执行),内层每一格里还藏着一个圈。
**所以「几步」和「几次模型调用」完全不是一个数** —— 第 4 节会算这笔账。
书还点了一句这么分的好处:可以用较强的模型完成思考要求高的计划任务, 而用较小、较快、更便宜的模型来执行6。
最后一件事必须说在前面: 书自己写明,这套东西当时被放在框架的 实验模块里,理由是相关理论和实践仍在发展中7。 「实验」这两个字在第 13 章第 3 节会变成一个很具体的后果。
4. 主走查:一份 8 条的漂亮计划
这一节起是本章的主走查。作者自己把这一趟叫「不可能完成的任务」, 因为需求根本不清晰——他想看看它是坦白承认能力不足,还是自信地胡说八道8。
输入: 一句话——「查查玫瑰的库存然后给出出货方案!」9 **手上两件工具:**一个查库存的函数(内部写死,任何花都返回 100), 一个按基础价和加价比例算最终价的函数10。
第 1 步 · 计划者产出。 它一口气列了 8 条11:
1. 检查玫瑰花库存
2. 分析对玫瑰花的需求
3. 再次确定 玫瑰花库存
4. 计算玫瑰花的需求数量
5. 比较可用数量与需求数量
6. 如果可用数量足够,基于需求制订发货计划
7. 如果可用数量不足,考虑替代方案
8. 回应用户的原始问题,给出最终解决方案
作者的评价是:这个计划挺不错。 老实说,它确实像一份人写的工作清单—— 有主线、有分支(第 6、7 条)、有收尾。
第 2 步 · 执行第 1 条。 执行者点了查库存工具,Observation: 100,
然后给出最终回答「玫瑰库存是 100」12。一切正常。
第 3 步 · 执行第 2 条(分析需求)。 这一条根本不需要查库存。 可它又点了一次查库存工具,又拿回 100,然后说: 要分析需求,可以考虑市场需求、季节趋势、顾客偏好,还可以看历史销售数据13。 ——一句正确的废话,而且白查了一次库存。
第 4 步 · 执行第 3 条(再次确定库存)。 第三次点查库存,第三次拿回 100。 这一次它的回答里带了一句自知之明:我已经查过玫瑰的库存了,数量是 10014。
第 5 步 · 执行第 4 条(计算需求数量)。 这一步它没有点工具, 直接给出最终回答:要算需求数量,需要更多关于需求的信息15。这一步是干净的。
第 6 步 · 执行第 5 条(比较)。 第四次点查库存,第四次拿回 100。 然后它说了这一趟最清醒的一句话: 很抱歉,不知道玫瑰的需求量,我无法把可用数量和需求数量做比较; 请提供更多关于需求的信息16。
作者在这里给了一句好评: 它已经意识到,仅凭手上的工具没法做这个比较; 在需求不清晰时它没有胡乱猜测17。
第 7 步 · 执行第 6 条。 第五次点查库存,第五次拿回 100。 回答是:库存是 100,现在我们可以拿它和需求数量比一比,看够不够18。 ——第 5 条刚说过没法比,第 6 条又说「现在可以比一比了」。
第 8 步 · 执行第 7 条。 第六次点查库存,第六次拿回 100。 回答和 上一步几乎一字不差19。
第 9 步 · 执行第 8 条。 没有点工具。回答是: 看起来用户的原始问题没有提供,请让用户提供他的原始问题20。 ——用户的原始问题当然提供了,就是那句「查查玫瑰的库存然后给出出货方案」。
这一趟的账:
第几条 查了库存吗 拿回什么
1 ✅ 100
2 ✅ 100 ← 这一条是「分析需求」,不需要查
3 ✅ 100 ← 「再次确定库存」,计划里就写重了
4 ❌ —
5 ✅ 100 ← 查完之 后说「我没法比较」
6 ✅ 100 ← 上一条刚说没法比
7 ✅ 100 ← 和上一条几乎一字不差
8 ❌ —
─────────────────────────────
8 步里 6 步在查同一个库存,6 次都拿回 100。
给个参照:这一趟真正需要查库存的只有 1 次。
也就是说,**多余的查询是必要查询的 5 倍。**
图说:每一次查询在真实系统里都是一次数据库往返;
而这里它们全部返回同一个数,连缓存都省不掉 —— 因为程序自己不知道自己在重复。
5. 清单一旦列好,就改不动了
这一节讲这一趟真正的病根,它不在模型笨,在结构。
回看第 6 步:执行者在第 5 条上已经明确说了「没有需求数据,我无法比较」。 一个人看到这句话会怎么做? 会停下来问一句,或者把后面两条划掉。
可这套结构做不到。 计划是在最开头一次性产出的,列完就是一份定死的清单; 执行者只负责一条一条往下走,它没有「回头改计划」这个动作。
于是第 6、7 两条照样跑,而且跑出了自相矛盾的回答:
| 第几条 | 它说了什么 |
|---|---|
| 第 5 条 | 我无法比较,请提供更多信息 |
| 第 6 条 | 库存是 100,现在我们可以拿它和需求比一比 |
| 第 7 条 | 库存是 100,现在我们可以拿它和需求比一比 |
这三行放在一起,就是这套结构的全部代价。
再看第 9 步那个更离谱的: 它说「用户的原始问题没有提供」。 为什么? 因为计划里第 8 条写的是「回应用户的原始问题」, 而执行者手里只有这一条步骤文字,原始那句话没有跟着传下来。
对比第 05 章那一圈: 那里每一轮的输入都带着完整的记事本, 所以模型永远看得到最初的问题。而这里,计划一列完,原始问题就掉队了。
判断(我们的,不是书里的): 这一趟暴露的不是模型的问题,是「一次性规划」这个结构的问题。 计划是在信息最少的时刻(第一步之前)做出来的,而执行过程中获得的所有信息 ——「库存是 100」「需求数据没有」—— 都无法回头改变它。 走一步看一步那一圈虽然啰唆,但它每一步都在用最新的信息重新决定。 如果错,会错在: 如果框架其实提供了「执行到一半重新规划」的开关而书没用, 那么这就不是结构问题,只是书里这个例子没配好。
6. 另起一处:需求补全之后,它编了一个价格
这一节走第二趟。作者把需求写清楚之后,这一趟确实跑通了——但产出是错的。
输入: 「查查玫瑰花的库存然后给出 50 朵玫瑰花的价格和当天的配送方案!」21
计划这次只有 5 条:查库存 → 判断够不够(不够就告知并结束)→ 取 50 朵的价格 → 查当天的配送选项 → 把价格和配送选项告诉用户22。 比上一趟短了 3 条,而且没有重复项。
第 1、2 条正常: 查库存拿回 100,判断 100 ≥ 50,够,继续23。
第 3 条出事了。 它要算 50 朵玫瑰的价格,于是想用那个算价格的工具。 可那个工具要两个参数:基础价和加价比例——而这两个数从头到尾没人给过。
它自己在思考里也说了这件事:我们还没有基础价和加价比例, 需要看看我们有没有这个信息,或者要不要问用户24。
然后它没有问用户。 它先又查了一次库存(拿回 100),接着直接调用了算价格的工具:
{
"action": "calculate_price",
"action_input": {
"base_price": 10.0, ← 这个数是它自己编的
"markup": 0.2 ← 这个数也是它自己编的
}
}
Observation: 12.0
Thought: The price of 50 roses is 12.0.
这一步至少错了两层:
第一层:两个输入是编的。 书里从没给过任何价格,那个工具的说明里也没有默认值25。
第二层:算出来的数根本不是「50 朵的价格」。 10.0 × (1 + 0.2) = 12.0, 这是一朵花的价格,不是五十朵的。 50 朵应该是 600。 可它写下的是「The price of 50 roses is 12.0.」,而且这句话一路传到了最终答案里26。
给这个 12.0 配个参照:按它自己编的那两个数,正确结果是 600,差了 50 倍。
书对这一趟的评价是正面的: 说它「展示了结构化和逻辑清晰的任务执行方式」, 「因为我们提供了足够的信息,可以确保任务按照既定流程顺利完成并给出答案」27。 书没有指出 12.0 这个数是错的。
判断(我们的,不是书里的): 这一趟比上一趟危险得多。 上一趟至少「看起来没完成」,你一眼就知道有问题; 这一趟从头到尾流程顺畅、格式完整、语气自信,而答案是错的。 需求不清晰时它老实承认,需求清晰时它反而编了两个数—— 这说明「承认不知道」这件事本身也是不稳定的。 如果错,会错在: 如果换个模型或者把工具说明写得更严(比如把两个参数标成必填、 并在说明里写「 没有就问用户」),这个编造可能不会发生。第 04 章第 8 节那条 「它只保证是合法 JSON,不保证符合你要的结构」说的就是这里。
7. 书里的空白:一条护栏都没有
这一节把这本书在这一格的缺口一次列清。
第 4 节那趟白查了 5 次库存,第 6 节那趟编了两个数。 这两件事都可以被拦住,而书里一条拦法都没有:
| 本来可以有的护栏 | 它能拦住什么 | 书里有吗 |
|---|---|---|
| 轮数上限 | 第 4 节那趟跑飞时及时叫停 | 没有 |
| 连续出错就熔断 | 同一个工具连着几次白跑就停 | 没有 |
| 打转检测 | 「同一个工具、同样的参数、同样的结果」重复了 6 次 | 没有 |
| 必填参数校验 | 第 6 节那两个编出来的数 | 没有 |
| 计划中途可改 | 第 5 节那三行自相矛盾 | 没有 |
五格全空。 这一整章从头到尾没有出现过任何一条上面这些东西。
有意思的是,第一条其实一直都在,只是书从没提过。 第 05 章第 9 节引过:那个执行器有一个默认 15 的轮数上限。 而这一趟的外层是 8 条计划,每条里面还嵌着一个能自己转好几轮的圈—— 所以真实的模型调用次数远不止 8 次。
打转检测那一条最值得单说。 第 4 节那张表里, 第 1、2、3、5、6、7 条点的是同一个工具、同样的参数、拿回同样的结果。
这是一个纯机械的判断,不需要任何智能: 「上一次点这个工具、参数一样、结果一样,那这一次就别点了。」 书里连提都没提。
8. 今天的待办清单长成什么样
这一节补上今天的做法,并且给出一个有点反直觉的现状。
第 4 节那份 8 条的清单,今天有个通用名字:待办清单。 你大概会以为它已经成了这类程序的标配。事实相反:
补充(不在书里,依据我们的前沿框架书架): 在一个专门做「长任务」的框架里,待办清单已经从默认里被拿掉了。 依据: shelf=ai-frontier-reference/deepagents#01-assembly-and-profiles.md @25aa2735dabbca6a8c82afae2c7c9f35830d151c 事实=那个负责待办清单的组件已从默认装配里移除(0.7.x 起改为按需打开); 想用「写待办」这件工具,得靠针对某个模型的配置把它额外挂回来 ——内置的一份配置就是这么做的。28
这条现状说明了什么? 它说明「先列清单」不是一个越用越好的东西。 当模型本身已经能一边做一边调整时,一份定死的清单反而是负担—— 正是第 5 节那个判断块说的那件事。
所以这一章的结 论不是「计划这条路错了」,而是:
- 计划的价值在于「把要算的步骤写出来」(第 2 节那道舞蹈班的题就是证据);
- 计划的代价在于「它定死了」(第 5 节那三行自相矛盾就是代价);
- 两者的取舍,取决于任务中途会不会冒出新信息。 舞蹈班那道题不会——所有数字一开始就都在题面上; 而查库存这趟会——「需求数据没有」是执行到第 5 条才知道的。
书的第 7.5 节其实也给了类似的结论,只是说得更温和: 在处理需要多步骤推理的复杂问题时,这一套可能更强, 而走一步看一步那一套可能更适合需要和环境交互的任务29。
9. 可带走的
- 换分工的动机是提示词越写越长: 既要盯目标又要记步骤,还要塞工具说明,模型开始不堪重负——这是书自己承认的;
- 做法只有一句话:先规划要采取的步骤,然后逐步执行; 书里学生把它总结成「计划和执行的解耦」;
- **舞蹈班那道题是它的最好证据:**只让它一步步想给出 55%(错),先列步骤再执行给出 60%(对);
- 执行者本身就是一个转圈的 agent——所以「几步计划」和「几次模型调用」完全不是一个数;
- 8 步里 6 步在查同一个库存,6 次都拿回 100;而这一趟真正需要查的只有 1 次,多余的是必要的 5 倍;
- 清单一旦列好就改不动了: 第 5 条已经说了「没法比较」,第 6、7 条照样往下跑并且说「现在可以比了」;
- 原始问题会掉队: 第 8 条要「回应用户的原始问题」,而执行者手里只有那一句步骤文字,所以它说「用户没有提供问题」;
- **需求补全那一趟更危险:**流程顺畅、格式完整、语气自信,而它自己编了基础价 10.0 和加价 0.2,得出「50 朵玫瑰的价格是 12.0」——按它自己编的数算也应该是 600;
- **书里一条护栏都没有:**轮数上限、连错熔断、打转检测、必填参数校验、计划中途可改,五格全空;
- **今天的现状有点反直觉:**在一个专做长任务的框架里,待办清单已经从默认里被拿掉、改成按需打开——因为清单的代价是它定死了。
10. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 提示词越写越大、模型不堪重负 | 7.1 Plan-and-Solve策略的提出 | text/49-ch07-01-7-1-plan-and-solve.txt:62(搜「增加提示词的规模」) · text/49-ch07-01-7-1-plan-and-solve.txt:60(搜「越来越多的开发者和组织准备将Agent应用于生产环境」) |
| 论文的核心主张 | 7.1 Plan-and-Solve策略的提出 | text/49-ch07-01-7-1-plan-and-solve.txt:70(搜「首先规划要采取的步骤」) |
| 计划和执行的解耦 | 7.1 Plan-and-Solve策略的提出 | text/49-ch07-01-7-1-plan-and-solve.txt:137(搜「计划和执行的」) |
| 舞蹈班那道题、55% 与 60% | 7.1 Plan-and-Solve策略的提出 | text/49-ch07-01-7-1-plan-and-solve.txt:86(搜「舞蹈班」) · text/49-ch07-01-7-1-plan-and-solve.txt:90(搜「55%」) · text/49-ch07-01-7-1-plan-and-solve.txt:106(搜「12/20 = 60%」) |
| 计划者与执行者、执行者本身是个 agent | 7.2 LangChain中的Plan-and-Execute Agent | text/50-ch07-02-7-2-langchain-plan-and-execute-agent.txt:22(搜「计划者是一个大模型」) · text/50-ch07-02-7-2-langchain-plan-and-execute-agent.txt:28(搜「执行者本身就是一个ReAct Agent」) |
| 用不同模型分别做计划和执行 | 7.4 从单Agent到多Agent | text/52-ch07-04-7-4-agent-agent.txt:9(搜「较小、较快、更便宜」) |
| 被放进实验模块 | 7.2 LangChain中的Plan-and-Execute Agent | text/50-ch07-02-7-2-langchain-plan-and-execute-agent.txt:7(搜「Experimental」) |
| 不可能完成的任务、两件工具 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:71(搜「不可能完成的任务」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:27(搜「假设每种花都有100个单位」) |
| 第一趟:输入与 8 条计划 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:87(搜「查查玫瑰的库存然后给出出货方案」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:99(搜「检查玫瑰花库存」) |
| 六次查库存 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:135(搜「Observation: 100」) · :167 · :190 · :232 · :261 · :283 |
| 第 5 条那句清醒话与作者的好评 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:238(搜「cannot compare the available quantity」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:218(搜「已经意识到」) |
| 第 8 条说用户没提供问题 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:307(搜「original question was not provided」) |
| 第二趟:输入、5 条计划、编出来的两个数、12.0 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:324(搜「50朵玫瑰花的价格和当天的配送方案」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:327(搜「Check the inventory of roses」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:400(搜「we don't have the base price and markup percentage yet」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:418(搜「base_price」) · text/51-ch07-03-7-3-plan-and-execute-agent.txt:424(搜「The price of 50 roses is 12.0」) |
| 书对第二趟的正面评价 | 7.3 通过Plan-and-Execute Agent实现物流管理 | text/51-ch07-03-7-3-plan-and-execute-agent.txt:474(搜「顺利完成并给出答案」) |
| 两套转法各适合什么 | 7.5 小结 | text/53-ch07-05-7-5.txt:21(搜「两种框架各有所长」) |