Agent Harness 源码拆解（八）：多 Agent——什么时候拆子代理，凭什么信它不越权

Posted on In , Views:

多 Agent 是 harness 里最容易被”神话”也最容易被”搞砸”的模块。被神话，因为大家都幻想”拆一堆子代理并行干活”；被搞砸，因为真拆起来会发现两个要命的问题：子代理的 transcript 会撑爆父上下文，子代理可能拿到父没有的权限。

先把这个权衡用真实数据摆出来。Anthropic 的多 agent 研究系统比单 agent 强 90.2%，但代价是多 agent 系统消耗的 token 约为普通聊天的 15 倍——作为参照，单 agent 约为普通聊天的 4 倍。也就是说，多 Agent 是用 15 倍的算力成本，换 breadth-first（广度优先）任务上的大幅性能提升——值不值，取决于你的任务是否足够高价值、足够可并行。而多数 coding 任务的可并行度其实不高（任务间依赖多、还要共享同一份代码上下文），所以”拆一堆子代理”绝不是免费的午餐。

这一章看三家怎么拆。它们答案不同，但共享一个判断，放最后讲。

CodeWhale：高扇出不卡，靠的不是进程边界

CodeWhale 的第一条纪律是：子代理不是第二执行基底。历史上它漂移出过两套并行 worker 系统，修法是让一个 headless Runtime worker 成为唯一的 detached 执行原语——“Everything else is a way to select, launch, or observe that one Runtime”。

分工措辞很精确：fleet 回答”谁”有资格被选中，Runtime 回答”如何与何处”执行，sub-agent 只是嵌套指派的角色/UX 词汇。

它还有一个直接推翻直觉的结论，是调查 Claude Code/Codex/Kimi 后写进文档的：高扇出不卡的真相不是进程边界——那三家全都让子代理跑在进程内。真正起作用的是”隔离 + 紧凑事件流”三条：

  • 子代理的 transcript 永不回灌进父上下文——父拿到的是结果摘要 + 一小段生命周期事件流；
  • UI 渲染的是计数（2 running / 3 done），不是每个 worker 一个子会话；
  • 每个 worker 的工具面直接从角色/能力 profile 构建，而不是”全建出来再过滤”。

权限上它的核心是 ChildGrant 单对象 + 与父求交（clamp 交集）、deny 并集、恢复时再次求交，配守护测试钉住”绝不放大”。一句话：委托转移工作，不转移权力。多代理系统的权限泄漏点，几乎都在”子代理获得了父没有的能力”。

grok-build：子代理是完整子会话，共享父的执行底座

grok-build 的答案是：子代理是独立子会话，隔离的是上下文窗口，共享的是执行底座。

隔离的：每个子代理有自己的上下文窗口，主 agent 委托工作不消耗自己的上下文。共享的：hunk tracker（编辑去重）、文件系统、终端、环境变量全部复用父的——子代理的编辑和父的编辑走同一条 diff/冲突追踪管线，不是各写各的。

还有两个细节值得记。一是 spawn 协议有收据语义：发出 → 收据（确认子代理开始处理）→ 结果，不是 fire-and-forget。二是验证者也要被验证：goal verifier 运行前，先检查候选角色是否具备最小能力集（Skeptic 至少要能 read + grep），不满足就 fail-open——多 Agent 系统里，验证者的资格是二阶问题。

Maka：子 Session 是操作员容器，Graph 是排程不是第二运行时

Maka 有四种多 Agent 机制（Swarm / agent_spawn / Agent Graph / Rive），但最关键的判断是一句：Graph 是 Runtime 事实之上的 durable 排程，不是第二个执行宇宙。

它的 agent_spawn 有个反直觉的设计：子代理不是子进程或子线程，而是一个链接的子 Session。这样做的收益和前面的持久化一脉相承——子 Session 的每一步都落进 Runtime 事实日志，可重放、可恢复、可审计，而不是一个脱离事实体系的孤立进程。

它们共同的判断

三家共享的那个判断是：子代理的工作必须回灌成摘要，而不是 transcript。Anthropic 的说法更本质：“搜索的本质是压缩”——子代理并行探索不同方向，最后把最重要的 token 压缩回主 agent。不管是 CodeWhale 的”transcript 永不回灌”、grok 的”报告 summary”、还是 Maka 的”子 Session 是操作员容器”，本质是同一件事——上下文是稀缺资源，子代理的完整过程是内部实现细节，父只需要结果。谁把子代理 transcript 原样塞回父上下文，谁就是在用一个子代理的预算，换两次上下文爆炸。

如果你要拆多 Agent

  • 要高扇出、要多模型适配：学 CodeWhale，一个执行基底 + 紧凑事件流 + 子代理 transcript 永不回灌。
  • 要编辑语义一致：学 grok，共享 hunk tracker / 文件系统，隔离上下文窗口。
  • 要可审计、可恢复：学 Maka，子代理是链接子 Session，每一步落事实日志。

四个最容易踩的翻车点：

一是子代理拿到父没有的能力。权限必须与父求交，绝不放大。

二是transcript 回灌。子代理的完整过程塞回父上下文，二次爆炸。

三是长出第二套执行基底。新场景来了复制一套 worker，语义分叉从此开始。

四是验证者没资格。让一个连文件都不会读的角色当审查者，fail-open 都比它靠谱。

下一篇是收尾的 Memory 与扩展：记忆怎么存才不越权、扩展怎么留口才不失控——以及 AGENTS.md 为什么被 CodeWhale 当成”受管理的资产”。

本篇术语

  • fleet：子代理的”身份·成员·选择”层，回答”谁有资格被选中”
  • 执行基底（execution substrate）：唯一的 detached 执行原语（headless Runtime worker）
  • transcript 回灌：把子代理完整对话塞回父上下文（应避免，只回摘要）
  • ChildGrant + clamp：子代理授权单对象，与父权限求交，保证不放大
  • fail-open / fail-closed：验证者能力不足时放行（fail-open）还是拒绝（fail-closed）
  • 子 Session：子代理作为链接的子会话，而非子进程/子线程

参考资料

参照系仓库（结论基于 2026-09 下旬至 10 月上旬各仓库 HEAD）：

  1. earendil-works/pi
  2. anomalyco/opencode
  3. xai-org/grok-build —— subagent/mod.rs 子代理机器
  4. zai-org/ZCode
  5. apache/maka —— agent-graph-stream-scheduling-draft.md 四种机制
  6. Hmbown/CodeWhale —— AGENT_RUNTIME.md 一个执行基底、fleet/exact.rs

Harness 设计方法论文献：

  1. Anthropic，《How we built our multi-agent research system》(2025-06)——多 agent 比单 agent 强 90.2%、15× token 成本、”搜索的本质是压缩”的官方复盘
  2. Anthropic，《Agent Harness Design: 3 Patterns for Harnessing Claude’s Intelligence》
  3. Simon Willison，《Anthropic: How we built our multi-agent research system》——该系统的第三方精读