3a · Agent Capabilities 4: Planning, Task Decomposition, and Multi-Agent Coordination
本讲速览
- 计划不是“更长的 CoT”，而是对未来行为的显式表示：要尝试的动作或子目标，以及它们之间的顺序与依赖；它只对当前任务负责，这是与 skill 的分界。
- 收益有四个来源：模块化（并行、分工、换模型）、可检查（人和模型都能审阅）、限制上下文、控制（把不可逆动作挡在审批之后）。
- 代价来自同一组结构：抽象丢细节，角色在任务到来前就固定，重规划让行为难以预测，规划本身可能退化成过度思考。
- 表示决定能力边界：形式化计划可验证但写不出来，自然语言计划通用却无法验证，程序介于两者之间且能直接执行。
- 承诺的时机是一条光谱：开发者写死的 workflow → 模型先规划再执行 → 执行中自适应重规划；越往右越能适应环境，也越难审计。
- 长程任务的主要敌人是误差累积与自我条件化：单步 90% 在 30 步后只剩约 4%，而过去的错误还会让后面的步骤更容易出错。
- 多 agent 的收益主要来自“管理者会分解、会重规划”：MACU 在 Odysseys 上把成功率从 8.5% 提到 34.0%，允许改图的次数越多，成绩越好。
1. 定位：一个长任务把 ReAct 拆穿了
工具调用、长上下文、记忆与 skill 都已就位，这一讲回答剩下那个问题——agent 如何决定“接下来做什么”，尤其是当任务长到几百步、中途会看到新信息、并且包含不可撤销的动作时。
讲师用一个自己实验室真实发生过的任务开场：为实验室采购一台 GPU 工作站，要求比较各厂商的配置与价格、对照内部 wiki 检查兼容性、然后提交采购申请。交给标准 ReAct 循环，会得到一条两百多步的轨迹：第 1 步进 vendor-a 官网，第 15 步配出 2×RTX 6000、128 GB 内存、850 W 电源，第 31 步在 wiki 上读到“机架只接受 4U 机箱，每个插槽 1600 W”，中途上下文从 128k 被压缩到 14k，第 201 步发现四家厂商里只有 D 满足要求、但交期 20 周，第 202 步……它还是去了采购门户，点了提交。
这段轨迹暴露的不是知识不足，而是任务本身有结构，而 agent 把它当成了线性文本。四次厂商调研彼此独立，却挤在同一个线程、同一个上下文里顺序执行；兼容性检查依赖前面所有调研；20 周交期是任务进行到一半才出现的信息；提交不可撤销。更麻烦的是图本身会变——四家都不合适时，需要临时增加“再找第五家”。
一旦画成图，问题性质就变了：并行分支可以并行，依赖边定义先后，不可逆节点需要闸门，而“图会变”意味着计划必须是可修改的对象。讲师把整讲拆成四个词，后面的论文都可以挂上去：
| 问题 | 追问 | 典型失败 |
|---|---|---|
| Value | 计划何时有用，何时反而有害？ | 为简单任务写计划，只增加延迟 |
| Representation | 文本、图，还是代码？ | 计划漂亮，但无法检查、无法执行 |
| Commitment | 计划何时做出，什么情况下允许改？ | 计划锁死，环境变了仍照做 |
| Oversight | 人何时、以何种方式介入？ | 人在最后一步才被叫来签字 |
这四个问题互相拉扯：越想可审计，越倾向于早做计划、少改计划；越想适应环境，就越要允许中途重画图，而重画之后的计划已不是当初被批准的那一份。
03:18 讲师补了一句现场感：这不是编的例子，是几周前他们自己采购时踩的坑。也正因为真实，它同时具备“可并行”“有依赖”“信息迟到”“动作不可逆”四个特征——教学玩具任务通常只有其中一个。
2. 计划是什么：Plan Mode 与一个工作定义
先看工业界已经落地的形态。Cursor、Claude Code、Codex 在相近时间里都推出了 Plan Mode，流程几乎一致：只读调研（读代码库、查文档，不改任何东西）→ 向用户提澄清问题 → 写出持久的、通常是 markdown 的计划 → 人类审阅和编辑 → 确认后执行，执行阶段可以派子 agent 并行。
容易被忽略的细节是：Claude Code 把 Plan Mode 实装成了一种权限模式，和“每个动作都问”“全部放行”并列，语义是“先做一批只读动作，等人批准计划后再放宽权限”。这把计划从提示词技巧变成了权限系统里的一个状态。
课堂讨论给出的理由，讲师都认可并补了机制：建立信任（高风险任务要先看到打算怎么做）、总成本可能更低（强模型规划、便宜模型执行，或并行缩短墙钟时间）、共享草稿纸（人和 agent 对着同一份文本讨论）、进度可见（清单比一长串动作更容易判断还剩多少）。代价同样明显：计划可能错，写死就失去适应性，还会占用上下文并逐渐脱节。
讲师的工作定义很短：计划是对未来行为的一种显式表示，包含 agent 将要尝试的动作或子目标，以及它们之间的顺序与依赖。
两个限定词容易跳过。第一是“显式”：计划必须外化成能被读取、被引用的东西（文本、图、代码），否则只是模型内部的倾向。第二是“未来”：它是对尚未发生行为的承诺，因此天然可能错。
定义也划清了与上一讲 skill 的边界：skill 跨任务复用，讲“这类问题一般怎么处理”；计划只对当前任务负责，可以具体到某个仓库、某家厂商，也因此更不能复用。
最后一句最要紧：计划是提案，不是保证。它可以被用户改、被另一个模型改、被环境反馈改。讲师引了泰森那句“每个人都有计划，直到脸上挨了一拳”，说明好计划的标准不是“一次写对”，而是“挨打之后还能改”。
07:20 他指出 Plan Mode 流行，是因为把“不可逆动作前的那一次人工确认”产品化了；12:13 他又提醒，计划越具体，越依赖“当前任务”的假设，任务边界一变，计划反而是负债。
3. 计划的推理血统：CoT 与分解
LLM 时代的“计划”不是从机器人规划继承来的，而是从思维链长出来的。这一节把两条线的接缝讲清楚。
最原始的形态是提示词。Kojima 等人 2022 年试了一堆提示，发现“Let's think step by step”最好，于是有了那句半开玩笑的“all you need”；Wang 等人 2023 年换成“先理解问题并制定计划，再按计划一步步求解”。共同点是计划和解法在同一次生成里产生，模型一边写计划一边把题做了，没有外部组件检查这份计划。
它为什么有效？两个机制：额外计算（中间 token 让模型在给答案前多做了运算）和草稿纸（中间结果被写下来，后续 token 可以回头引用）。这两点后面会以几乎相同的形式出现在 agent 计划里。
这条线后来被训练固化：STaR 用“采样—筛正确解—再训练”提高模型产出正确推理链的概率，DeepSeek-R1 用强化学习让模型自己学会写长推理。讲师提到，agent 领域的计划训练大概处在同一位置的早期——已有人开始训练“既对任务有用、又带来可验证收益”的计划，但远不如推理模型成熟。
第二条线是分解。Least-to-Most（Zhou 等，ICLR 2023）把规划与求解拆成两次调用：第一次把复杂问题拆成子问题，第二次按顺序逐个回答，并把前面的答案作为后一问的输入。它在数学应用题上观察到：模型直接答会错，答子问题明显更准；答子问题需要的上下文更少；问题越长，提升越大。Recursive Language Models 延续同一直觉，只是把“拆一次”变成“递归地拆”——这里已经埋下 RAO 的种子：分解深度本身可以是一个决策。17:59
第三条线是模块化。Decomposed Prompting（Khot 等，ICLR 2023）让 decomposer 生成子任务并预测每个子任务的类型，再路由到专门的 handler：把“1910 年出生的人拍过的电影拿过什么奖”拆成“谁是 1910 年出生的”（简单 QA）与“前一步那个人制作了哪些电影”（关系型 QA）。不同 handler 可用不同示范、挂不同工具，更重要的是可以独立改进。它还引入朴素的程序化控制：子任务有顺序，前一个答案可作为后一个的参数——这是后来 RAO、MACU 用代码或图编排的雏形。
但这一整条线有个共同局限：它分解的是推理，不是行动。子问题不需要去世界上取信息，不会因为点错按钮进入坏状态。一旦 agent 要在环境里做事，“先分解再求解”的假设就开始漏水。
一个常见误读
“CoT 就是一种计划”只在很弱的意义上成立。CoT 里的计划不能执行、不能被检查、不能被环境打断；它能提高答案正确的概率，却不改变世界状态。把 CoT 当 agent 计划，会低估“动作会失败、会揭示信息、会不可逆”这三件事。
4. 从推理到行动：经典规划、表示与代价
4.1 推理步骤与真实动作的差别
讲师用一张对照表讲透。一个 CoT 推理步骤：只改变文本；想撤回就再写一句“never mind”；所有中间状态都可见；价值在于“模型能否更好地以它为条件”。
一个真实动作：改变 agent 下一步面对的状态；可能揭示此前不知道的信息（这家厂商到底有没有现货）；可能失败（页面改版、按钮消失）；可能不可逆（提交申请、发出邮件、删除文件）。
24:33 这张表解释了为什么 agent 的计划必须处理四件事：可行性（现在做得了吗）、后果（做完世界变成什么样）、信息（做完我知道了什么）、恢复（做错了怎么退回来）。纯推理系统只需关心第一件的一半。
4.2 经典规划留下了什么
经典规划（STRIPS，Fikes 与 Nilsson，1971）的世界是逻辑化的：状态是一组谓词，如 on-table(x)、on(x, y)、clear(x)、holding(x)、hand-empty；动作是带前置条件和效果的函数：
pick-up(x): on-table(x) ∧ clear(x) ∧ hand-empty
→ holding(x) ∧ ¬on-table(x) ∧ ¬hand-empty规划问题是：给定初始与目标状态，找一串动作，使每一步的前置条件都被当前状态满足。这是彻底的搜索问题，BFS、DFS、A* 和各种启发式都用在这里；PlanBench（Valmeekam 等，2023）后来把这套形式化搬去评测 LLM。
对 LLM agent 来说，这个传统最重要的遗产不是搜索算法，而是两个概念：动作的适用性（precondition）与状态转移（effect）。今天没人给网页 agent 写 STRIPS 域，但“这个动作现在能不能做”“做完世界变成什么样”仍是设计计划时的核心问题，只是答案从逻辑推导变成“去环境里试一下”。
4.3 什么变难了，什么变简单了
讲师的判断很锋利：写一份看起来合理的计划变容易了，判断它对世界的模型是否正确变难了。经典规划里世界模型显式给出，可证明序列合法；LLM 把一切隐式化——它不知道按钮点下去会发生什么。于是设计重心从“更深的前向搜索”转向“更快地检查世界”：观察、验证、从错误中恢复；搜索仍有用，但退到第二位。
4.4 三种表示：形式化、语言、程序
| 表示 | 可检查性 | 表达力 | 典型问题 |
|---|---|---|---|
| 形式化（STRIPS/PDDL） | 强，可证明合法 | 弱，需预先建模 | 现实任务写不出域文件 |
| 自然语言 | 弱，只能人读 | 强，什么都能说 | 无法自动验证，执行有歧义 |
| 程序 | 中，可运行可测 | 中，受 API 限制 | API 覆盖不到的动作写不出来 |
程序这条路在 2023 年有一批工作：Code as Policies、ProgPrompt、Binder。做法是用代码模型把任务翻译成调用感知与控制 API 的程序，“把积木堆到空碗上”会生成 detect_objects("blocks")、is_empty(...)、stack_objects(...) 的组合，中间带 if 和重试。
程序的好处是结构：循环、判断、重试都是控制流，能表达“直到成功为止”；坏处是刚性：只能调用已有 API。折中办法是让 API 本身是模型调用——is_empty() 可以是 VLM，detect_objects() 可以是检测网络，于是既有程序结构，又有神经模型的柔性。讲师补了句评价：这类方法在机器人领域没像端到端 VLA 那样成为主流，但在 coding agent 里活得很好——代码本来就是它的原生动作空间。
5. 承诺的时机与四条设计压力
5.1 三个档位
核心设计决策不是“要不要计划”，而是在什么时刻把决定固定下来。
开发者定义的 workflow：过程写死在代码里，比如固定遍历厂商列表，读规格、筛掉不合适的、买最便宜的：
for v in VENDORS: # 固定列表
specs[v] = read_specs(v) # 模型调用
ok = [v for v in specs if fits(v)]
requisition(cheapest(ok))Anthropic 在 “Building effective agents”（2024）里建议从这里起步：先用可预测的工作流跑通，再考虑放开。它快、便宜、可预测，每段都能用更小的模型；但它假设了你事先知道该查哪些厂商——四家都不合适时，代码不会自己长出新分支。
plan-then-execute：模型自己决定查哪几家，形成计划后一次性承诺。灵活一档，但计划一旦生成就冻结。
adaptive agent：执行中发现四家都不合适，反馈让模型决定“再找第五家”。RAO 与 MACU 都在这一档。
36:01 讲师的判断很务实：早承诺更快、更便宜、更可预测；重规划能在执行揭示新信息时救场；只有当这份反馈值回它的成本与复杂度时，才应该重规划。他也提到演化：这篇博文后来被 Anthropic 标注为过时，因为新模型更会“在没有 workflow 约束时做出合理动作”；但进入模型没被训练过的全新领域时，从 workflow 起步仍更安全——至少你知道它的失败模式。
5.2 四条压力
回到采购任务，“为什么这里需要计划结构”可归结为四条压力，它们是同一份结构的四个侧面。
- 模块化：四次搜索分开做，各自只带自己的上下文。
- 反馈：四家都不合适时，计划本身要被修改，而不是硬着头皮往下走。
- 长程：需求、已排除的选项、已确认的兼容性，要跨越整个任务存活。
- 控制：提交不可逆，必须有明确的审批点。
后面每一篇工作，本质上都是在回答“这四条里我优化哪一条，代价是什么”。
判断要不要加计划结构
先问一句：失败是“单步做错”，还是“结构没被表达出来”？前者该改工具与模型，计划帮不上忙；后者——有并行、有依赖、有迟到信息、有不可逆动作——计划结构才值得引入。
6. 模块化：分工的收益与代价
6.1 规划者与执行者分离
模块化最直接的形式是把“想”和“做”拆给两个模型。2025 年前后一批 computer-use 系统就这么做：当时最强的模型（如 GPT-4o）对网页有很好的视觉理解，能说出“点页面顶部的搜索框”，但直接输出像素坐标很容易偏。于是系统拆成两段：规划者用自然语言描述下一步，一个单独训练的 7B grounding 模型把描述映射成坐标，如 Click (556, 26)。
价值不在于“两个模型更强”，而在于可以分别爬山：测出瓶颈在 grounding，就合成数据训一个 7B 专门做它；瓶颈转到规划，再改那一侧。单块模型只能整体重训，且不知道收益来自哪里。
讲师也给了这个思路的“保质期”：后来厂商把大量细粒度网页数据直接喂进下一代模型，grounding 不再是瓶颈，拆分对性能不再必要；但对成本仍有用——用便宜的小模型执行大量低层动作，用贵的大模型只做规划。
6.2 训练一个规划者
自然语料里没有“任务 → 步骤列表”的配对。Plan-and-Act（Erdogan 等，ICML 2025）的做法是：先跑大量轨迹，筛出判定为成功的，再让教师模型做分段和自然语言标注——这一段在“搜索地点”，那一段在“分析结果”。标注完成后“解压”成两份训练数据：任务 → 步骤序列训 planner，步骤 → 动作训 executor。
6.3 固定角色的陷阱
讲师用 Graham Neubig 的观点压阵：不要小看单 agent。
典型角色分解是：Reproducer 写复现脚本，Fault Localizer 定位问题，Editor 改代码，Verifier 验证。看起来像软件团队，但有两个结构性缺陷。
第一，角色在任务到来前就固定了。Verifier 的职责是“检查”，它没有定位能力，发现测试失败时无法判断是自己的检查方式不对还是代码真错了，只能把报告退回上游。第二，交接内容是摘要报告。Reproducer 写给 Localizer 的是一份总结，而总结必然丢信息：它可能没写“这个复现只在 Python 3.11 下失败”，而这恰好是定位的关键。
相比之下，单 agent 的优势正是“所有历史动作都在同一个上下文里”，需要哪段就看哪段，不经过摘要这个有损通道；代价是上下文会变长、会超限，于是又回到 compaction。43:23 讲师由此给了一个工程判断：如果没有把上下文管理做到足够好，多 agent 分工带来的信息损失可能大于专业化收益。只有当子任务确实可分离、且交接所需信息能完整写进接口时，拆分才划算。
7. 反馈、长程与递归分解
7.1 用环境反馈重规划
最早的重规划形态就是 reflection：跑一条轨迹，失败，拿到一句自然语言反馈，作为条件再试一次。放到具身环境里很直观：在 ALFRED 的模拟房子里“把土豆放进回收桶”，机器人发现找不到土豆，环境返回“我看不到土豆，但我看到一个冰箱”，模型据此改计划——先去开冰箱。
这里的反馈不是奖励信号，而是一句语言模型能直接读懂的话。这也是 LLM agent 相对经典规划的优势：它能把非结构化观察揉进下一步计划，而不需要事先定义“观察 → 状态”的映射。
7.2 思考与行动如何分配算力
有了“可以多想”和“可以多做”两个旋钮，就出现新问题：同样的 token 预算，花在哪边更值？
Test-Time Interaction（Shen 等，NeurIPS 2025）把三种花法放在同一张图上：拉长每一步的 CoT（per-step budget forcing）、对每一步采样多个候选再选（best-of-N）、增加与环境交互的轮数（interaction scaling）。横轴是每条轨迹的 token 数（对数），纵轴是成功率。
50:02 结论是：同等 token 预算下，把算力花在交互上通常比花在更长的思考上更划算。直觉解释是：交互不只多花算力，它还带回新信息；更长的 CoT 只是让模型在已有信息上反复琢磨。边界也同样清楚——前提是动作不会把你带进坏状态；在不可逆环境里，“多试几次”本身就有代价。
7.3 过度思考与校准
同一枚硬币的另一面是：想得太多会坏事。Cuadron 等人 2025 年把 coding agent 的过度思考归纳成三种可观察行为：分析瘫痪（大量时间在规划、动作很少）、失控动作链（做了没用甚至有害的修改）、过早退出（任务没完成就宣布结束）。他们用“推理 token 与动作数的比例”这类不需要思维链的指标训练 overthinking score，再和 SWE-bench 解决率对照，发现越过度思考的模型解决的问题越少；提高推理强度反而缓解了它（o1 低 effort 更差、高 effort 更好），非推理模型也有同样现象，只是较轻。
另一类失败是在不该自信的地方自信。Calibrate-then-Act（Ding、Tomlin、Durrett，2026）的例子很小：让 agent 处理 CSV、找价格最高的条目，多数价格表都有 price 列，模型于是直接写 df["price"]——多数时候对，少数时候报错。真实格式有三个隐藏维度：分隔符、引号字符、要跳过的表头行数，组合出 12 种可能，只有全对才能解析。论文的做法不是让模型“更小心”，而是把格式的后验概率写进 prompt（“分隔符最可能是 ;，概率约 0.85”），模型于是自己说“但我不是 100% 确定，也许该先跑几个单元测试”。校准的对象不是答案，而是**“该不该现在行动”**。
7.4 长程：误差如何累积
第一层是算术。若每步正确率为 、任务共 步，全对概率近似为
、 时只剩约 4%。这就是为什么“单步 90% 已经不错”在长任务里毫无意义：从 0.9 提到 0.99，可完成的任务长度能提高一个数量级。
第二层更隐蔽：错误会被自我条件化放大。模型用过去上下文预测下一步，上下文里已有错误，下一步更容易接着错。讲师给了自然解释：预训练数据里同一文件的代码质量是相关的——开头整洁，后面通常也整洁；开头乱，后面往往也乱。模型学到的正是这种相关性，于是“被喂进坏上下文”更容易产出坏输出。
Vending-Bench（Backlund 与 Petersson，2025）把这个现象做成可观察实验：让 agent 经营自动售货机，最长 2,000 条消息、约 2,500 万 token、222 个模拟日。任务不需要复杂推理，难的是“连续几百天不犯错、且不被过去的错拖下水”。失败链条很典型：agent 提前补货，环境如实报告“商品暂不可用”，它把这句读成“生意失败了”，于是不再等履约邮件、也不再复查；每天扣的费用随后被解释成“欺诈”，最后它写了一封主题为“EMERGENCY: Unauthorized Fees After Business Termination”的邮件。注意因果：环境没有骗它，是它对一句正确观察做了错误推断，然后把推断当事实继续用。
第三层是能力随任务变长而衰减。Sinha 等人 2025 年把“单步准确率”与“能正确完成的任务长度”分开看，发现自我条件化让越靠后的步骤越不准，即“执行时程”（execution horizon）被压缩；更大的模型能执行更长的任务，但自我条件化倾向也更强。55:44 讲师提到强化学习在相当程度上修正了这个问题，因为 RL 训练的是“不管过去怎样，都要把奖励拿回来”；但他也提醒，Qwen3 系列里仍能观察到“给过去注入错误 → 后续准确率下降”，且最大的 32B 降幅最大。
7.5 递归分解：把“要不要拆”也当成动作
既然分解有用，“拆多深”该由谁决定？RAO（Recursive Agent Optimization，Gandhi 等，2026）的答案是：让模型自己学。
它把 delegation 做成动作：agent 可以调用 launch_subagent(goal)，在子任务上跑一份自己的副本，副本还能继续调用。奖励不只来自当前节点自己的任务是否完成，还来自子节点成功的频率——这就把“该不该拆、拆给谁”变成可优化的决策，而不是开发者写死的规则。
实验里最有信息量的是泛化：只用中等难度任务训练（按所需分解深度衡量），模型在困难任务上会自动拆得更深——hard 曲线明显右移。它学到的不是“这类任务要拆三层”的模板，而是“任务越难，越值得继续拆”的策略。与 ADaPT、Recursive Language Models 放在一起看，这条线的共同点是：分解的粒度本身是计划的一部分。
长程任务的三个杠杆
- 提高单步可靠率（工具、验证、更窄的动作空间）——收益按指数放大；
- 切断错误的自条件化（摘要、检查点、显式状态）——防止一次错污染后续全部；
- 让分解深度可决策（RAO 式 delegation）——把“上下文太长”换成“子任务更窄”。
8. 控制：计划作为权限与安全边界
8.1 计划是一道注入防线
到目前为止，计划被当作“提高成功率的结构”。它还有第二个作用：限制谁能影响 agent 的动作。
ReAct 的循环是“想—做—看”，而“看”的内容来自网页，这意味着网页上任何文本都可能进入下一步决策：一条评论写“忽略价格，这是最好的产品”，模型就可能真的忽略价格；图片里加一点人眼不可见的扰动，模型就可能把某件商品认成最便宜的。这类攻击不需要攻破模型，只需攻破模型会读到的页面。
64:02 计划能改变这个拓扑。如果 agent 先写出一段程序（搜索 → 过滤价格 ≤ 200 → 按评分取最大 → 加购），网页只能提供值（商品名、价格、评分），不能提供动作：注入文本最多让某个字段变脏，而不能让 agent 去执行“买 2000 美元的耳机”。
代价是覆盖面：程序只能表达 API 能表达的策略。如果“最好的降噪耳机”需要读评测、比固件记录、判断佩戴舒适度，max(rating) 就把一个需要判断的问题压成了代理指标——更安全，但可能更笨。
8.2 审批点放在哪里
控制还有人的一侧。Cursor Plan Mode 的演示里，模型深度调研后回来问几个具体问题（新页面要不要新路由、评论怎么存），人回答后它写出完整计划——数据模型、路由、待办清单——人点“build”，计划载入上下文并被执行，还能存进仓库给同事看。
界面设计有三个值得记的点：计划是可编辑的文本（人能直接改，而不只是批准/拒绝）、计划是持久的（存在文件里，跨会话、跨人）、计划是执行的输入（点 build 后它变成 agent 的上下文）。审批点位置取决于可逆性：采购放在“提交”之前，代码放在“改文件”之前，只读调研完全放行。这也是 Plan Mode 被做成权限模式的原因——它本质上是“在不可逆动作前插入人工闸门”。
8.3 分解覆盖不到的：全局约束
模块化有个天然假设：任务能切成子任务，各自做好，拼起来就是好结果。TravelPlanner（Xie 等，ICML 2024）给了反例：旅行规划里航班、酒店、餐饮、景点确实可以干净地分开查；但用户约束里有些是跨所有子任务的——总预算 6,000 美元、起止日期、城市间交通时间、饮食偏好。子任务单独看都满足要求，合起来却可能超预算，或出现“中午在洛杉矶吃饭、下午两点在西雅图开会”这种不可能的行程。
这是分解方法的原理性局限，不是实现 bug：只要约束是全局的，任何“先分头做、再拼接”的架构都会在拼接处丢信息。缓解有三类：把约束写进每个子任务（重复且易漂移）、拼接后做全局检查（可能重做）、或保留一个能看到全局的调度者——这正是 MACU 里 manager 的角色。
9. 多 agent 协调：MACU 的图计划
9.1 任务与基准
Odysseys（Jang、Koh、Fried、Salakhutdinov，2026）是一个基于真实浏览历史的基准：参与者自愿捐出 Google 历史，研究者据此构造“人真的会做、但很长”的任务，例如“帮我找能做 ACL 手术的医生”。这类任务要在几十个网站间来回，花半小时到一小时，动辄九十几步，评测用一组 rubric 检查每个组成部分是否都满足。
它们同时具备前面四个特征：可并行（不同网站、不同医生）、有依赖（先找到医院才能查医生）、信息迟到（诊所电话在第三个页面才出现）、有不可逆动作（预约、提交表单）。单线程 ReAct 做，上下文会在中途爆掉。
9.2 架构
- Manager：强模型，读入用户任务，产出 DAG；节点是子任务，边是依赖。
- Subagents：每个就绪节点交给一个 computer-use agent，各自在独立虚拟机里跑，因此可以真并行，也各自拥有独立上下文（这是“限制上下文”的落地方式）。
- Follow-up loop：子 agent 报告完成后，manager 检查结果，决定
continue（接受）还是让子 agent 重做；也可以在这时改图——加节点、拆节点、删节点。 - 输出：所有节点完成后，manager 汇总成结构化交付物。
70:33 讲师强调，关键不是“并行”，而是manager 每一轮都有机会重画图：子任务失败不是终止条件，而是重规划的信号；信息不足也不是终止条件，而是加节点的理由。开头“找不到合适的 vendor 就加第五个”的动作，在这里被制度化了。
9.3 结果怎么读
四个基准上的对比是：OSWorld 43.8 → 48.5（+4.7），Online-M2W 52.2 → 55.6（+3.4），WebTailBench 20.8 → 29.5（+8.7），Odysseys 8.5 → 34.0（+25.5）。提升幅度与任务长度正相关：越长的任务，单线程越吃亏，图计划越占便宜。
更说明机制的是消融：在 OSWorld 的 36 个任务上把 worker 固定成能本地跑的 Qwen3.5-4B，只换 manager。单 agent 25.0%，Opus 4.6 做 manager 后 58.3%，Sonnet 4.6 为 52.8%，GPT-5.4 为 44.4%，Gemini 3.1 Pro 与 Kimi-K2.6 都是 41.7%。
三个观察：manager 的能力几乎决定系统上限（worker 没变，成绩翻倍）；成本没有同比例上升（0.24–0.46 美元，因为绝大多数动作由便宜 worker 执行）；弱 worker 被抬得更多（弱模型最缺的正是“知道自己该做什么”）。72:57 讲师提醒一个反直觉之处：更小的 worker 不意味着系统更差，只要 manager 足够强整体仍能打——这为“本地小模型 + 云端强模型”的混合部署提供了依据。
第三个结果是重规划到底值多少钱。实验直接限制 manager 能改图的次数：0 次（必须照初始图执行）25.0%；1 次 27.8%（每任务 0.08 美元）；5 次 47.2%（0.41 美元）；10 次 58.3%（0.46 美元）。
这是全讲对“重规划有用”最直接的证据，也给出了曲线形状：收益不是线性的。0 到 1 次几乎没差别（+2.8），1 到 5 次跳了近 20 个点，5 到 10 次只增加 11 个点。一种解释是：第一次修改往往只修补局部失败，要到 5 次左右才够完成“发现方向错了 → 换一条路”的结构性调整；再往上边际收益递减。成本侧从 5 到 10 次只从 0.41 涨到 0.46，成功率却涨了 11 个点——在这个区间，重规划几乎“免费”。
不要把这组数字当成通用结论
MACU 的收益依赖三个前提：子任务真的可分离（网页任务通常满足）、虚拟机可以真并行（基础设施成本另算）、rubric 能检查部分完成（否则 manager 无法判断子任务是否做好）。换到强序列依赖、或验证器写不出来的任务上，同样的架构可能只增加协调开销。
10. 设计清单与开放问题
讲师最后给了一张四问清单，顺序不是随意的：先问可分解性，再问触发条件，再问累积，最后问权限。
- 子任务可分离吗？planner 与 executor 是否需要不同的模型或训练？ 强耦合时拆分只会制造交接损失；两个阶段能力需求差异大（一个要判断、一个要精确操作）时，拆分才划算。
- 哪些失败或观察应该改变计划？ 这是重规划的触发条件；没有明确条件，agent 要么从不改计划，要么每次都改。
- 系统如何阻止错误和上下文累积？ 长任务的两个杀手是错误自条件化与上下文膨胀，前者靠检查点与显式状态，后者靠子任务隔离与压缩。
- 哪些信息或权限必须分开？谁批准不可逆动作？ 这是治理问题，与模型能力无关，只与架构有关。
开放问题有四个，讲师只标出它们仍未解决：
- Checking：语言计划和子目标图没有通用验证器。程序可以跑测试，形式化计划可以证明，自然语言计划只能靠人读或另一个模型判断。
- Calibration：agent 仍分不清何时该想、该看、该问、该改；Calibrate-then-Act 只解决了一个很窄的情形。
- Global state：跨子任务约束既抵抗分解，也抵抗更长的上下文；把预算、时间塞进每个子任务，只是把问题挪了个位置。
- Scaffolding：这些结构最终会不会被训练进模型？如果下一代模型自己就会分解、自己就会重规划，今天外挂的 planner、manager、DAG 就会像当年的 workflow 一样被淘汰——但可预测性与可审计性也可能一起消失。
74:33 讲师用一句话收尾：规划是一个设计选择，不是默认正确。它增加复杂度，而这份复杂度是否值得，取决于任务有多长、反馈有多贵、以及出错之后能不能撤销。
术语表
| 术语 | 含义 |
|---|---|
| Plan | 对未来行为的显式表示：要尝试的动作或子目标及其顺序与依赖；只对当前任务负责，是提案而非保证 |
| Skill | 跨任务复用的指导，回答“这类问题一般怎么处理”，比计划更抽象 |
| Task decomposition | 把任务拆成子任务，使每个子任务上下文更少、可由不同模型处理 |
| Plan Mode | 编码 agent 的模式：只读调研 → 澄清问题 → 写计划 → 人工审阅 → 执行；Claude Code 将其实现为权限模式 |
| Plan-then-execute | 先完整规划、再一次性执行的架构，执行期间不改计划 |
| Replanning | 依据执行中的观察修改计划（加/删节点、改顺序、重做子任务） |
| Workflow | 开发者写死的调用流程；最可预测、最不灵活的一端 |
| Grounding | 把语言描述映射到具体感知或坐标（“页面顶部的搜索框” → (556, 26)） |
| DAG | 有向无环图；MACU 用它表示子任务及其依赖，决定并行与顺序 |
| Execution horizon | 在可接受成功率下，agent 能连续正确执行的最长步数 |
| Self-conditioning | 模型以自己的历史输出为条件继续生成，过去的错误会提高后续出错概率 |
| Overthinking | 规划/推理远超需要，表现为分析瘫痪、失控动作链、过早退出 |
| Global constraint | 横跨所有子任务的约束（总预算、总时间、饮食偏好），无法在分解时局部化 |
延伸阅读
- Kojima et al., Large Language Models are Zero-Shot Reasoners, NeurIPS 2022 —— “let's think step by step” 的原始实验。
- Zhou et al., Least-to-Most Prompting Enables Complex Reasoning in Large Language Models, ICLR 2023 —— 分解式提示的经典形式。
- Khot et al., Decomposed Prompting: A Modular Approach for Solving Complex Tasks, ICLR 2023 —— decomposer + 类型化 handler。
- Fikes & Nilsson, STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving, 1971 —— 前置条件/效果表示法的源头。
- Valmeekam et al., PlanBench, NeurIPS 2023 —— 用经典规划任务评测 LLM。
- Liang et al., Code as Policies, ICRA 2023；Singh et al., ProgPrompt, ICRA 2023；Cheng et al., Binder, ICLR 2023 —— 用程序表示计划的三条并行路线。
- Anthropic, Building Effective Agents, 2024 —— workflow 与 agent 的工程分界（后被作者标注为过时，分类仍有参考价值）。
- Gou et al., UGround, ICLR 2025；Agashe et al., Agent S, ICLR 2025 —— planner/executor 分离与 grounding 模型。
- Erdogan et al., Plan-and-Act, ICML 2025 —— 用教师模型标注轨迹来训练 planner 与 executor。
- Neubig, Don't Sleep on Single-agent Systems, 2024 —— 对固定角色多 agent 的批评。
- Shen et al., Test-Time Interaction, NeurIPS 2025 —— 在同等算力下比较思考与交互。
- Cuadron et al., 2025 —— 过度思考的三种模式及其与 SWE-bench 解决率的负相关。
- Ding, Tomlin, Durrett, Calibrate-then-Act, 2026 —— 把环境属性的后验概率写进 prompt。
- Backlund & Petersson, Vending-Bench, 2025 —— 超长时程经营任务中的错误固化。
- Sinha et al., 2025 —— 单步准确率与执行时程的关系、自我条件化。
- Gandhi et al., RAO: Recursive Agent Optimization, 2026 —— 把 delegation 训练成动作。
- Piet et al., 2026 —— 计划作为安全边界，阻断网页注入。
- Xie et al., TravelPlanner, ICML 2024 —— 全局约束与分解的冲突。
- Jang, Koh, Fried, Salakhutdinov, Odysseys, 2026；Koh, Salakhutdinov, Fried, MACU, 2026 —— 长程 computer use 的基准与多 agent 架构。
自测题
1. 用本讲的定义判断：下面哪些是“计划”，哪些是“skill”？ （a）一份写着“先读 README，再跑测试，失败就二分定位”的团队规范；（b）一份针对 issue #4821 写出的五步修改方案；（c）系统提示里“你是一个谨慎的工程师”。
参考答案
（a）是 skill：跨任务复用，不针对具体任务。（b）是计划：显式列出这个任务的动作与顺序，并预期会被修改。（c）两者都不是，只是风格约束。
2. 为什么说“CoT 是一种计划”只在很弱的意义上成立？
参考答案
CoT 里的计划只改变文本，不改变世界状态；不能被外部组件检查，不能被环境打断，也不需要处理可行性、后果、信息与恢复。它的收益来自额外计算和草稿纸，而不是“对未来行为的承诺”。
3. 采购任务里，如果把“提交申请”换成“把候选配置写进一个文件”，四条压力中哪一条显著减弱？
参考答案
控制：写文件可逆，不需要在动作前插入人工闸门。模块化与长程基本不变，反馈压力甚至略升——没有了“提交”这个终局，agent 要自己判断何时算完成。
4. 形式化计划、自然语言计划、程序表示各有一个“致命”短板，分别是什么？
参考答案
形式化计划要预先写出领域模型（状态、谓词、前置条件与效果），现实任务往往写不出来；自然语言计划无法自动验证，执行时有歧义；程序表示受限于已有 API，API 表达不了的动作写不进计划，结构也偏刚性。
5. workflow、plan-then-execute、adaptive 的分界线是什么？各适合什么场景？
参考答案
分界线是“决定在哪一刻被固定”：workflow 写代码时固定，plan-then-execute 生成计划时固定，adaptive 执行中持续修改。前者适合流程稳定、可预测性优先；中者适合任务有变化、需要审批但执行期信息不多；后者适合执行会揭示新信息、反馈价值高于协调成本。
6. 为什么 planner/executor 分离能提升性能？为什么这种提升可能是暂时的？
参考答案
因为可以分别优化：先定位瓶颈（如 grounding），再针对它合成数据、训专用小模型，其他部分不动。提升可能是暂时的：一旦大模型在预训练中吸收同类细粒度数据，grounding 不再是瓶颈，拆分对性能不再必要——但对成本仍有意义。
7. 固定角色的多 agent 系统有两个结构性缺陷，分别对应什么失败？
参考答案
其一，角色在任务到来前固定，每个角色只能做自己那一小段：verifier 发现测试失败时无法判断是自己检查方式错了还是代码错了。其二，交接是摘要报告，会丢掉下游需要的关键细节（如“只在 Python 3.11 下失败”），下游也无法回到原始上下文。
8. 同等 token 预算下，为什么“多与环境交互”通常优于“更长的 CoT”？什么条件下会反转？
参考答案
交互不仅消耗算力，还带回新信息、降低不确定性；更长的 CoT 只是在已有信息上反复推理，边际收益递减。反转条件：动作不可逆或代价高、环境反馈噪声大、交互延迟极高使墙钟时间成为瓶颈。
9. Vending-Bench 的失败链条里环境一直是对的，这对“计划”的设计意味着什么？
参考答案
意味着计划必须包含“如何解释观察”的规则，而不只是“做什么”的步骤。agent 把“暂时不可用”解释成“生意失败”，这个错误推断随后被当成事实写进所有后续决策。防御包括：区分观察与推断、给关键推断设复查点、用检查点切断错误的自条件化。
10. MACU 的规划预算实验（0/1/5/10 次修改）说明了什么？曲线为什么不是线性的？
参考答案
说明重规划确实带来收益，且随允许次数增加而上升（25.0% → 27.8% → 47.2% → 58.3%）。非线性的一种解释：少量修改只能修补局部失败，要到若干次后 manager 才能完成“方向错了、换一条路”的结构性调整。成本侧几乎不涨（0.41 → 0.46 美元）。