不是派活，是武装——从 Task Delegation 到 Capability Empowerment

上一章我们解决了一个基本问题：如何约束单个 agent，让它的产出可靠。Mechanical gate、independent review、tamper detection——这些是驾驭单个执行引擎的缰绳。但当你的手里不只有一匹马，而是一支骑兵队时，问题从”如何约束”变成了”如何武装”。约束是底线，武装是战斗力。

大多数人对”用 AI 组建团队”的理解是这样的：你是老板，AI 是员工，你把任务拆好，一个个分下去，它们各干各的，最后你汇总。

这个理解不是错的，但它止步于 task delegation——你在分配任务。

Task delegation 的问题在于它假设你能把任务拆得足够细、足够清楚。但真实的工程工作不是流水线。一个”实现用户认证模块”的任务，在执行过程中会遇到”数据库 schema 要不要改”、“和现有 session 机制怎么兼容”、“错误码体系要不要统一”这些决策。每一个决策都需要上下文、需要判断力、需要对系统全局的理解。

如果你的 agent 只是一个”接受任务、执行任务”的执行者，它在每个决策点都会卡住或者瞎猜。你要么不停地介入（那你就是实际干活的人），要么放任它自行决策（那你就等着返工）。

真正 scale 的方式是 capability empowerment——你不是给 agent 一个任务，你是给它一套完整的能力装备，让它有能力在执行过程中自主做出合理的决策。

这套装备包括：

• 完整的工具集：不是”只给它需要的工具”，而是给它足够多的工具让它能自主解决执行过程中遇到的问题。
• 足够的上下文：不只是 “做什么”，还有 “为什么这样做”、“系统的整体架构是什么”、“哪些约束不能违反”。
• 显式的决策框架：当遇到需要判断的场景时，应该优先考虑什么？哪些情况需要上报？哪些可以自行决定？
• 协作协议：如何和其他 agent 交互？如何处理冲突？如何共享发现？

这就是”武装”的含义——你不是在雇佣临时工，你是在培训特种兵。

Agent 的两种执行模型：Spawn vs Delegate

当你的 main agent 需要另一个 agent 帮忙时，有两种根本不同的模型。这不是行业标准术语——这是我基于实践总结的分类框架。不同的 agent framework 可能用不同的名字，但底层的取舍是一样的。

Spawn 模型

Main agent 启动一个全新的 agent session，给它一个任务描述和必要的上下文，然后各干各的。Spawned agent 独立运行，有自己的 context window、自己的工具集、自己的执行节奏。任务完成后返回结果给 main agent。

Spawn 的核心特征是 session 隔离。两个 agent 不共享 context window，通过消息传递通信。注意这里说的不是 OS 进程隔离——多个 agent 完全可能运行在同一个进程内，关键是它们持有独立的 conversation state。这带来几个直接后果：

• 并行性好：多个 spawned agent 可以同时运行，互不阻塞。
• 故障隔离：一个 agent 崩了不影响其他 agent。
• 上下文独立：每个 agent 从一个干净的 context 开始，不会被其他 agent 的思路污染。这对 independent review 至关重要。
• 通信成本高：每次交互都是一次完整的”打包-传输-解包”。你不能假设对方”应该知道”什么，你必须显式传递所有必要信息。

Delegate 模型

Main agent 通过 tool call 将一个子任务交给一个 sub-routine 执行。执行完成后控制流回到 main agent，结果直接可用。

Delegate 更像是函数调用。它的特征是 控制流集中：main agent 始终掌握控制权，sub-routine 是它的延伸而非独立实体。

• 低延迟：没有进程启动开销，结果即刻可用。
• 上下文共享：delegate 可以访问 main agent 的部分或全部 context。
• 串行执行：delegate 在 main agent 的执行流中是阻塞的。
• 耦合度高：delegate 的行为依赖 main agent 的 context，不适合需要独立判断的任务。

什么时候用什么

经过大量实践，这个选择可以形式化：

用 Spawn 的场景：

• 任务需要独立判断（review、second opinion）
• 任务可以并行执行
• 任务可能长时间运行
• 需要故障隔离

用 Delegate 的场景：

• 任务是当前思路的自然延伸
• 任务需要 main agent 的完整上下文
• 任务很轻量，spawn 的开销不值得
• 结果需要立即用于下一步决策

一个常犯的错误是把应该 spawn 的任务做成 delegate。最典型的例子是 code review——你让 builder agent 在自己的 context 里调用一个 review tool。这个 tool 形式上是”另一个 agent”，但它继承了 builder 的 context，看过 builder 的推理过程，本质上还是 self-review。第二章讲过为什么这不行。

另一个方向的错误也存在：把应该 delegate 的任务 spawn 出去。比如”读取一个配置文件并返回某个字段”——你 spawn 了一个 agent 来做这件事，等它初始化、执行、返回，花了 30 秒。而一个 tool call 能在 1 秒内搞定。

还有一些关键的 orchestration 机制：

通知系统：spawned agent 完成任务后，main agent 需要被通知。一种常见的做法是通过 message bus——agent 完成后发一条消息到 bus，main agent 订阅感兴趣的 topic。这比轮询高效得多。

Tracker：当你同时有多个 spawned agent 在运行时，你需要一个地方追踪它们的状态——谁在运行、谁完成了、谁卡住了、谁失败了。这个 tracker 是 coordinator 的眼睛。

Abort Cascade：当一个任务被取消时，所有为这个任务 spawn 的子 agent 也应该被取消。听起来显而易见，但如果你不显式实现这个 cascade，你会经常遇到”主任务已经取消了，子 agent 还在吭哧吭哧跑”的场景——浪费资源是小事，它可能还在修改文件，制造幽灵变更。

Multi-Agent 系统的失败分类学

在讨论具体的路由和编排设计之前，值得先建立一个失败模型。大多数人在 multi-agent 系统出问题时，本能反应是”修那个出 bug 的 agent”。但 multi-agent 系统的失败往往不在单个 agent 身上——它在 agent 之间的缝隙里。

我把 multi-agent 系统的失败分为三层：

Agent 层失败：单个 agent 的能力问题。幻觉、工具使用失败、超出 context window 导致遗忘。这是最容易诊断的一层——你能明确指出”是这个 agent 搞砸了”。第二章的 harness 体系主要对付的就是这层。

协调层失败：agent 之间的协作问题。信息在传递过程中丢失或变形、两个 agent 等待彼此的输出形成死锁、多个 agent 对同一个问题做出了矛盾的决策但没人发现。这层失败的特征是：每个 agent 单独看都没有错，但合在一起就出问题。下文讨论的显式路由和冲突管理，核心就是在对抗协调层失败。

系统层失败：整体架构的韧性问题。没有 fallback 机制导致单个 agent 挂掉整条 pipeline 停摆、错误在 agent 链条中传播和放大（agent A 输出一个小偏差，agent B 基于它做了一个更大的偏差决策，agent C 把偏差当成事实写进了最终产出）、缺乏全局的超时和熔断导致系统进入不可恢复状态。

这个三层模型的意义在于：它告诉你不同层级的失败需要不同层级的应对。战术性地修补单个 agent 的 prompt 不能解决协调层和系统层的问题。你需要的是系统性策略——显式的通信协议、结构化的状态管理、以及贯穿全链路的 fallback 设计。后面几节的具体设计，都是在回应这三层失败模型。

路由必须显式：三个系统的教训

这可能是本章最重要的一个教训：agent 之间的状态传递必须是显式的。

让我用三个项目的对比来说明。

Agent Store 的 Routing Bug

我见过一个 agent 平台的真实案例：它的 agent store 允许用户创建自定义 agent，每个 agent 有自己的工具集和行为配置。早期设计中，agent 之间的路由依赖一个隐式的 context 传递机制——当 agent A 调用 agent B 时，系统会自动把 A 的”当前状态”注入 B 的上下文。

听起来很方便。实际上是噩梦。

Bug 的表现是：agent B 偶尔会做出莫名其妙的决策，像是在回应一个没人问过的问题。排查后发现，A 的 context 里残留着前一轮对话的状态，这些状态被隐式传递给了 B，B 把它们当成了当前任务的上下文。

这不是一个普通的 bug。这是一个 架构层面的设计缺陷：隐式状态传递让你无法推理数据流。你不知道一个 agent 拿到了什么信息、信息从哪来、是否还有效。

三个系统的对比

那个 agent 平台：修复后改为显式消息传递。agent A 调用 agent B 时，必须在 message payload 中声明所有传递的信息。没有”自动继承上下文”——你传了什么，B 就有什么；你没传的，B 就没有。这增加了调用方的工作量，但让每一次交互都是可审计的。

OpenClaw（一个开源的 config-driven agent 路由系统）：采用了 8-tier priority cascade 的路由设计。这是一个纯 config-driven 的 binding 系统——每个请求经过 8 层优先级匹配，按规则路由到目标 agent。所有的路由规则都写在配置文件里，没有运行时的动态推断。你打开配置文件就能回答”这个请求会被路由到哪个 agent”这个问题，不需要跑代码。

OpenClaw 的 8-tier cascade 是这样的：从最高优先级到最低，依次是用户显式指定 > 场景特化绑定 > 用户偏好 > 主题绑定 > 能力匹配 > 负载均衡 > 默认路由 > fallback。每一层都是确定性规则，不涉及 LLM 判断。任何一层命中就停止，不继续往下匹配。

这个设计的优雅之处在于：它把所有的路由决策都外化成了配置。添加新的路由规则不需要改代码，只需要在对应层级加一条配置。调试路由问题不需要打断点，只需要看配置文件和请求参数。

Claude Code（我自己的使用方式）：最简单的模型——一个 main agent 直接调用 subagent tool，参数里带上所有必要信息。没有中间层，没有 message bus，没有配置级联。适合小规模场景，但路由逻辑散落在 prompt 和 tool call 中，scale 不了。

三个系统的共同教训：不管你的路由多简单或多复杂，状态必须是显式的。隐式状态传递是 agent 系统的根本性缺陷。人类可以依赖共享的工作记忆和文化背景来补全未说出口的信息，LLM 不行——它只处理你给它的 token。你以为”它应该知道”的东西，它不知道。

协议优于框架：Agent 基础设施的被低估维度

在 agent 编排这个领域，有一个被系统性高估的东西和一个被系统性低估的东西。被高估的是框架（framework），被低估的是协议（protocol）。

选了 LangChain 就绑定了它的执行模型、记忆方案、prompt 模板、tool calling 约定。选了 CrewAI 就绑定了它的 role-based 抽象和任务编排方式。框架的问题不在于它们不好用——它们在 demo 阶段确实好用。问题在于 耦合。当你需要换一个 LLM provider、换一种记忆策略、或者对接一个框架没预想到的 tool 时，你发现自己在和框架的抽象层搏斗，而不是在解决业务问题。

MCP（Model Context Protocol）的成功恰好印证了协议思维的价值。MCP 不是一个框架——它不管你用什么语言实现 server，不管你的 agent 内部怎么编排，它只定义了 agent 和 tool 之间的通信契约。这跟 HTTP 之于 Web 框架是同一个关系：HTTP 定义了客户端和服务器怎么对话，但你用 Django 还是 Express 还是手写 socket，HTTP 不管。正是这种松耦合，让 MCP 能在短时间内获得广泛采用——任何框架都能接入，不需要放弃已有的技术选型。

对 multi-agent 系统来说，这个洞察的实践含义是：把你的编排逻辑建立在协议之上，而不是框架之上。 定义清楚 agent 之间怎么传递消息、状态格式是什么、错误怎么上报、能力怎么声明。至于每个 agent 内部用什么框架实现，那是它自己的事。前面讲的显式消息传递、结构化的 review report、三级 blocking/warning/info 分类——这些都是协议层面的设计，不依赖任何特定框架。

Companion 设计：全能 vs 受限

当你有多个 agent 时，面临一个设计选择：前端用户直接交互的那个 agent（companion），应该是什么样的？

有两种流派：

Router 流派：companion 是一个路由器。它接收用户的请求，分析意图，然后转发给合适的专业 agent 处理。companion 本身不做任何实际工作，只做分发。这个设计看起来很”架构正确”——关注点分离、单一职责。

Full-capability 流派：companion 是一个全能 agent。它自己就能处理大部分请求，只在必要时调用专业 agent。用户感知到的始终是同一个实体。

我在实践中一致选择了 full-capability。

OpenClaw 和 Claude Code——两个产品的 main agent 都是全能模式。 在我接触过的其他 agent 平台中，趋势也是如此。

为什么？

因为 router 模式有一个致命的延迟问题。用户说了一句话，router 先要理解意图（一次 LLM call），然后路由到专业 agent（一次 spawn 或 delegate），专业 agent 开始处理。整个链条的延迟是累加的。而 full-capability agent 直接处理，延迟少一个环节。

更深层的原因是 上下文完整性。Router 模式下，专业 agent 只拿到 router 传过来的信息。如果 router 遗漏了重要上下文（比如用户三轮前提到的一个约束），专业 agent 就会做出不符合预期的决策。Full-capability agent 从头到尾都在对话中，它拥有完整的上下文。

当然，full-capability 不意味着什么都自己做。它意味着 有能力自己做，但可以选择调用专业 agent。这个”选择权”在 companion 手里，而不是被架构强制。

实际操作中，companion 的 tool policy 是按 theme 组织的，不是按 tool 组织的。

Tool Policy by Theme, Not by Tool

传统的权限设计是：列出所有 tool，逐个标注 agent 是否有权使用。这导致了一个巨大的权限矩阵——N 个 agent × M 个 tool，维护成本极高。

更好的方式是按 theme 组织 policy。一个 theme 是一组相关的能力，比如”文件系统操作”、“代码执行”、“网络请求”、“用户交互”。每个 agent 被赋予若干 theme，theme 内的所有 tool 自动可用。

这样做的好处：

1. 添加新 tool 不需要更新每个 agent 的权限。新 tool 归属于某个 theme，所有拥有该 theme 的 agent 自动获得权限。
2. 权限语义清晰。“这个 agent 可以操作文件系统”比”这个 agent 可以使用 read_file、write_file、delete_file、list_directory、move_file、copy_file”更易于理解和推理。
3. 减少配置错误。单个 tool 粒度的权限很容易遗漏——你加了 write_file 但忘了加 create_directory，agent 能写文件但创建不了目录。按 theme 授权就没有这个问题。

并行 Agent 的冲突管理

当多个 agent 并行工作时，你必然会遇到一个问题：它们会同时编辑同一个文件。

这不是 edge case，这是常态。想想一个真实的开发场景：agent A 在实现一个新 API endpoint，agent B 在重构错误处理逻辑。两个 agent 都需要修改 app/middleware.py。如果它们不知道彼此的存在，各自基于同一版本做了不同的修改，你就得手动 merge conflict。

而且这比人类的 git conflict 更棘手。人类开发者有心智模型——他看到 conflict marker 时，他理解两边的意图，能做出合理的 merge 决策。Agent 没有这个能力。它看到 conflict marker，最可能的反应是把其中一边删掉。

我在实践中总结了几种应对策略：

策略一：文件级别的悲观锁

最简单粗暴的方案。在 task 分配阶段就识别出每个 task 会涉及的文件，确保没有两个并行 task 会碰同一个文件。如果有冲突，把其中一个改为串行。

优点：完全避免 conflict。 缺点：过于保守。两个 agent 可能都需要修改 config.py，但一个改第 10 行，另一个改第 200 行，完全不冲突。悲观锁会强制它们串行。

策略二：分支 + 自动 Merge

每个 agent 工作在自己的 git branch 上。完成后，由 coordinator 负责 merge。如果 git 能自动 merge（不同区域的修改），直接 merge。如果有 conflict，coordinator 调用一个 merge resolution agent 来处理。

优点：最大化并行度。 缺点：merge resolution agent 的质量不稳定。对于简单的 conflict（比如两边各加了一行 import），它处理得不错。对于语义级别的 conflict（两边修改了同一个函数的不同方面，各自一致但合在一起矛盾），它经常出错。

策略三：架构级隔离

最根本的方案。如果你的代码架构足够模块化，每个 agent 工作在自己的模块内，跨模块的交互通过明确定义的接口进行。这样并行 agent 天然不会编辑同一个文件。

优点：从根本上解决问题。 缺点：需要前期的架构投入。不是所有代码库都有这个条件。

实际操作中，我通常混合使用这三种策略：先做架构级隔离（尽可能减少 conflict 的可能），在架构无法完全隔离的地方用分支 + 自动 merge，对于已知的高争用文件（比如全局配置、数据库 migration、路由表）用悲观锁。

还有一个至关重要但容易被忽略的点：分阶段委派时，验证的不只是 components，还有 wiring。

当你把一个大任务分成多个阶段，每个阶段由不同的 agent 完成时，每个 agent 交付的 component 可能都是正确的，但它们之间的连接可能是错的。Agent A 暴露了一个函数叫 get_user，agent B 调用的是 fetch_user。各自的单元测试都通过了，但集成起来就挂了。

你必须在每个阶段切换之间验证 wiring，而不只是验证 component。 这意味着 integration test 是阶段切换的 gate，不是最终交付时才跑的东西。

Multi-Agent 场景下的 Review 实操

第二章论证了 independent review 的必要性。在 multi-agent 场景下，问题不再是”要不要 review”，而是”怎么在多个 agent 并行工作时高效地做 review”。

Spawn 而非 Delegate

Review agent 必须被 spawn，不能被 delegate——这一点在第二章的 gate 层级中已经确立。但在 multi-agent 场景中，spawn 的方式有讲究：

• Reviewer 不共享 builder 的 context window。 它拿到的是纯粹的产出物：代码 + 需求文档。builder 的 prompt、推理链、放弃的方案——reviewer 一概不知。
• Reviewer 的 prompt 是标准化的。 不是”请 review 这段代码”，而是一套结构化的 checklist：功能正确性、边界条件、错误处理、与现有系统的一致性。
• 一个 builder 对应一个 reviewer。 不要让一个 reviewer 同时审多个 builder 的产出——context pollution 会在同一个 session 内跨任务传播。

Review 结果驱动 Iteration

Review 不是终点，是 feedback loop 的一环。Review agent 的输出是一份结构化的 report，明确区分三个级别：

• Blocking：必须修复才能继续。Builder 拿到后重新进入 build-review cycle。
• Warning：应该修复但不阻塞。Builder 在当前轮修复，或标记为 known issue 留到下一轮。
• Info：建议性意见。Builder 可选择采纳。

这个三级分类不是让 reviewer 表演”我很认真”，而是给 coordinator 提供可操作的信号——coordinator 只需要检查 blocking list 是否为空就能决定是否放行。

量化数据：方向性参考

在一次版本迭代中，我对 20 个任务做了 self-review vs independent review 的对比。样本量不大，统计显著性有限，但方向性结论是清晰的：

实验条件：同一个 Claude 模型，同一批任务（涵盖新功能开发、bug 修复、重构三种类型）。Self-review 是同一个 session 内的 delegate，independent review 是 spawn 出来的独立 session，只看代码和需求文档。

几个值得注意的模式：

• Self-review 几乎无法发现设计层面的问题。 Builder 选择了某个设计方案，self-review 时它会为这个方案辩护，而不是质疑。
• Independent review 在边界条件发现上大幅领先。 Builder 在实现时没想到的边界条件，self-review 时同样不会想到——同一个 context window 里的认知盲区是共享的。
• Self-review 的误报率极高。 它在无关紧要的 style 问题上挑刺（“命名不够好”、“注释可以更详细”），在真正的问题上放行。

成本方面：以当前 LLM 定价（截至 2025 年中），一次 review 的 token 成本大约在几美分到几角之间。即使只有 10% 的 review 发现了关键 bug，对比漏网 bug 在生产环境中的修复成本（定位、修复、测试、部署、善后），ROI 依然轻松达到 50x 以上。

本章小结

这一章的主题是从”一个人用一个 AI”到”一个人用一支 AI 团队”的跃迁。核心不是技术上多复杂，而是思维模型的转变。

几个关键原则：

1. 武装而非派活。 给 agent 完整的能力装备，让它能自主应对执行中的不确定性。Full-capability companion 优于 router。

2. Spawn vs Delegate 的选择是架构决策。 需要独立性的任务 spawn，需要上下文共享的任务 delegate。错误的选择会带来系统性的质量问题（delegate 做 review）或性能问题（spawn 做简单查询）。

3. 路由必须显式。 隐式状态传递是 agent 系统的原罪。OpenClaw 的 8-tier cascade 是一个范本：所有路由逻辑外化为配置，可审计、可理解、可修改。

4. 并行 agent 的冲突是架构问题，不是运气问题。 架构级隔离 > 分支 + 自动 merge > 悲观锁。同时，分阶段委派必须验证 wiring，不只验证 components。

5. Independent review 是 multi-agent 系统的纠错机制。 它不只是质量保障——在并行 agent 各自为战的架构里，independent review 是唯一能发现跨 agent 盲区的环节。Spawn 它、标准化它、让它驱动 iteration loop。

从第二章的约束体系到第三章的团队架构，一条主线始终贯穿：你不是在和 AI 合作，你是在设计一个以 AI 为执行层的工程系统。 合作的隐喻暗示 AI 有自主判断和质量标准，会让你放松警惕。系统的隐喻则提醒你：每一个行为都需要被设计、被约束、被验证。

下一章，我们把视角从”怎么协调 agent”转向”怎么让整个系统自主运转”。当你有了一支装备精良的 AI 团队，自然的下一步是：你能不能从 operator 退到 architect，让 pipeline 自己跑起来？Autonomous operation 不是放手不管——它是一门精确到 tick 级别的工程。