先规划还是边走边适应：一次 GPU 采购的三种摆法

ACTION 201 还在纠结：选 D？找第五家？还是放宽某项要求？到了 ACTION 202，它直接向采购门户提交了申请，此时 context 已从 128k 被压到 14k tokens。L5 p.2 的这条真实轨迹，是贯穿全讲的病例。

讲次页把同一个采购任务摆成三栏：工作流、先规划后执行、适应式，差别在控制权放在哪。哪种摆法什么时候划算，病例会给出答案。

一、病例：一次采购是怎么跑挂的

先看任务。为实验室采购一台 GPU 工作站：跨厂商站点比价查配置、对照内部 wiki 的集群要求查兼容性、提交采购申请。三步都来自 L5 p.2。

任务的难点在结构，L5 p.3 列了四个特征：

• 并行子任务：多家厂商可以同时搜。
• 依赖：比价查配置要先于兼容性结论。
• 迟到信息 late-arriving information：wiki 的机架要求在轨迹后半段才被读到。
• 不可逆步骤 irreversible：采购申请一旦提交就难撤回。

而且这张任务图本身会变：四家全不满足时，必须长出第五次搜索。

这张图本身就是论证：任务图若固定，工作流能一次写死；可一旦四家全不满足这种分支真会发生，图就必须为 replan 留出位置，p3 干脆把这条边直接画进任务图。L5 p.2 的真实轨迹，是这样失败的：

L5 p.2 的页边批注点了三种病。头一条：四次独立搜索挤在同一线程同一个 context，结构图里本可并行的四路子任务被串行压进一个窗口，四份站点观察互相挤占。第二条：挑的四家站点结果都不理想，选站没有先验，却没留调整余地。

第三条最要紧，硬选一家提交申请。ACTION 201 明明在纠结，202 却原样提交：模型「知道」不对劲，却没把犹豫转化为结构的通道，既没触发一次重规划，也没升级给人。

context 从 128k 被压到 14k tokens，则是第 2 讲 compaction 篇的老话题在规划场景的重演：早期搜索的细节被挤掉，晚期决策只能对着残缺的记忆做。

二、三种摆法：伪码、计划、反馈

L5 p.16 把同一任务摆成三种控制权位置。第一栏最朴素：开发者定义工作流（workflow），控制流完全写死在代码里：

# 开发者定义工作流：厂商清单写死（L5 p.16）
for v in VENDORS:                    # [vendor_a, vendor_b, vendor_c, vendor_d]
    specs[v] = read_specs(v)         # 逐家抓配置
ok = [v for v in specs if fits(v)]   # 过滤兼容
requisition(cheapest(ok))            # 提交最便宜的合格者

快、便宜、可预测 —— 也脆。四家全不满足时 ok 为空，这条流水线没有为全军覆没写分支。

本任务偏偏会全军覆没：D 虽满足规格，20 周交期在业务上等于不满足。20 周算不算合格，这个判断本身就需要一次 replan，伪码里没有它的位置。

第二栏是先规划后执行（plan-then-execute）：模型先产出计划，再照单执行。计划里写的是将要尝试的动作或子目标，及其次序与依赖。

第三栏是适应式（adaptive agent）：执行反馈可以驱动模型改写任务图本身，四家失败就去找第五家，L5 p.16 把 RAO、MACU 也归在这一栏。

预先承诺（pre-commitment）的红利有数字为证。ReWOO 把规划与执行解耦，规划阶段完全不看观察，提示成本从随步数二次增长降为线性；HotpotQA 上拿到 5 倍 token 效率，准确率反升 4%。

LLM Compiler 让规划器直接产出可并行派发的函数调用 DAG，相对 ReAct 延迟最高降 3.7×、成本省 6.7×、准确率升约 9%。

两篇都出自 2023 年。先想清楚再动手是老话，token 经济学把这笔账算清楚了。

红利也有边界。ReWOO 的规划期看不见世界，世界变了计划就过时，wiki 信息迟到就是 “规划期全知” 假设的反例。

Anthropic 在 Building effective agents（2024）里给的判据是：预先承诺更快、更便宜、更可预测，重规划让模型在执行揭示新信息时适应；只有当反馈值回额外的成本与复杂度时才加后者。复杂度只在可证明改善时才加。

Anthropic 后来把这页博客标记为过时、指向新版指南 —— 模型更强之后，一部分写死的脚手架可以退役；但课堂提醒：换来的可靠性会掉，新领域里从 workflow 起步仍是更稳的走法（字幕）。

三、计划是什么，Plan Mode 为什么起效

值不值谈完，再看计划是什么。L5 p.5 给了工作定义：计划是对预期未来行为的显式表示（explicit representation），内容是将尝试的动作或子目标，及其次序与依赖。

三条限定把它与邻居分开：

• 属于本任务：对照 skill，即跨任务可复用的指南，第 2 讲 skill 篇的对象就是它。
• 面向未来工作：组织的是将要做的事，不回溯过去。
• 是提案（proposal）不是保证：Mike Tyson 有言，「Everybody has a plan until they get punched in the mouth.」

病例里那一拳，就是 OBSERVE 31 的 wiki 页。

产业侧已把先计划做成了产品，Cursor、Claude Code、Codex 都推出了 Plan Mode。L5 p.4 的流水线分五步：

• 只读调查 read-only investigation
• 澄清问题 clarifying questions
• 书面计划 written plan
• 人工审查 human review
• 执行

起效的道理，slides 在 L5 p.4 给了五条候选解释：更多计算、更好的 context、外部 artifact、分解、人的批准。

Cursor 官方博客（2025-10-07）说得更具体：先计划后施工显著改善生成代码质量；计划是一份含文件路径与代码引用、可内联编辑的 Markdown，Shift+Tab 进入。

把流水线放回病例就看得清。第一步只读调查就去读 wiki 的机架要求，这条信息就不迟到了；书面计划把四家全不满足摆到人面前，人工审查卡在提交之前，ACTION 202 的硬提交就没有发生的位置。

五条解释里，人的批准这一条就是病例缺的那道闸。

这份计划的形态逐条对上工作定义：显式、属本任务、组织未来工作；可内联编辑，承认的也是提案属性。

加规划结构的理由，L5 p.17 列的是 modularity、feedback、long horizons、control 四条。Plan Mode 里最直白的是 control：计划是人与 agent 之间的审批界面。

至于计划终究会废，Fred Brooks 在《人月神话》里早宽慰过你（L5 p.17）：做好扔掉一个的准备，反正你也会扔。原话见拆开 planner 与 executor 篇。

与本讲的连接

本篇回答的是 L5 p.3 四问骨架里的 Value 一问：规划何时有用，预先承诺的红利有数字为证；何时有害，写死的分支盖不住会变的任务图。伴读那句「计划是假说不是承诺」，是贯穿本篇的母题。三种摆法只是在不同的位置回答同一个问题：假说被证伪之后，系统里还有没有活着的东西能接住它。