第33章：编排 Agent：从子智能体到终端编排工具
"工作流把计划搬进代码。用 subagent 和 skill 时，编排者是 Claude 自己；工作流脚本自己握住循环、分支和中间结果，Claude 的上下文里只留最终答案。"
—— Anthropic，《Orchestrate subagents at scale with dynamic workflows》
第 32 章讲的是单个 agent 内部的执行编排：计划、任务列表、走查文档。这一章往外走一层：一个上下文窗口装不下的任务，怎么让多个 agent 分头去做。
「多 agent」这个词被用坏过。给 agent 起名「产品经理」「架构师」「测试工程师」，让它们像公司部门一样互相传文档，这条路在实践里成批失败。原因不复杂：角色是人类的分工方式，LLM 没有「职业壁垒」，同一个模型既能写 PRD 又能写代码；信息在角色之间单向交接，传的是结论，丢的是推理过程，每个节点局部正确，整体漂移。
活下来的分工方式不靠角色头衔：任务记录是共享的，谁做了什么随时追加，接手的 agent 读到完整历史。这一章先看三家 CLI（Claude Code、Codex、OpenCode）各自怎么实现子 agent，再看一批跑在终端里的编排工具。
33.1 为什么需要多个 agent
两个动机。
第一个是上下文隔离。主会话的上下文窗口是稀缺资源，OpenAI 在自己的 Harness Engineering 实践（第 10 章）里反复强调这一点。让子 agent 去读三千行代码、跑测试、翻文档，把结论带回来，海量中间产物留在子 agent 自己的窗口里，主会话保持干净。
第二个是并行。互不依赖的工作单元同时开工，比如同时审查五个模块。子 agent 各有各的窗口，互不干扰。
并行带出一个工程问题：两个 agent 同时改同一个工作区，会互相踩。这一章后面所有工具给的答案是同一个：git worktree，每个 agent 一份独立的工作目录和分支。
33.2 Claude Code：subagent、agent teams 和动态工作流
Claude Code 的编排能力分三层，一层比一层重。
Subagent。 在项目的 .claude/agents/ 目录下放一个 markdown 文件，写清楚这个 agent 的职责、思维规则和输出格式，一个子 agent 就定义好了。主 agent 需要时派出去，它在独立的上下文窗口里干活，干完只把结果带回主线程。子 agent 定义是文件，可以进 git，可以团队共享，和 skill 是同一个思路：能力即文件（第 6 章）。社区流传最广的例子之一，是用七个 subagent 文件配上研究员、编辑、项目经理这类角色。
Agent Teams。 2026 年年中上线的多实例协作，早期要开实验开关。一个会话当 team lead，负责拆任务、分配、收尾；几个 teammate 是独立的 Claude Code 实例，各有各的上下文窗口。所有成员共享一个任务列表，谁领了什么、干到哪一步，一目了然；成员之间可以直接通信，不用事事经过 lead。要看大家干活，用 tmux 或 iTerm2 分屏，每个队友的终端摊开一格。有两个控制开关：delegate mode 把主 agent 限制成只做协调，不直接写代码；plan approval 让 lead 在队友动手前先审计划。
它和 subagent 的分工一张表说清：
| Subagent | Agent Teams | |
|---|---|---|
| 上下文 | 独立，结果汇总回主线程 | 独立，不汇总 |
| 通信 | 只向主 agent 报告 | 成员之间可以直接通信 |
| 协调 | 主 agent 集中控制 | 共享任务列表，自组织 |
| 适用 | 单一、独立的子任务 | 多层面、需要讨论的任务 |
Dynamic Workflows。 2026 年 5 月底随 Opus 4.8 发布的研究预览，针对的是前两层的共同瓶颈：编排者始终是 Claude 本身，每个子 agent 的结果都要回到 Claude 的上下文窗口，协调几十上百个并行任务时装不下。动态工作流的解法是让 Claude 把整个编排过程写成一段 JavaScript 脚本，循环、分支、中间结果收集都固化在代码里，交给独立的运行时执行。标志性案例是 Bun 作者 Jarred Sumner 用它在 11 天里把 Bun 运行时从 Zig 迁到 Rust，75 万行代码，99.8% 的原有测试通过。
编排逻辑从提示词搬进定义文件，再搬进可执行代码，这条线在第 第 17 章还会从另一个角度看到。
33.3 Codex：subagent 加 worktree
Codex 的编排能力在 OpenAI 自己的大规模实践中打磨过。他们记录过一次实验：三个工程师，五个月，零行手写代码，做出一个约百万行的生产产品，全程由 Codex 完成，合并了约 1500 个 PR。人只负责描述任务、审 PR、给反馈，单人吞吐量维持在每天 3.5 个 PR，单次任务经常无人值守跑六个小时以上，过夜出结果。
支撑这种玩法的是三个能力：
- Subagents：为并行的子任务派生 child agent，每个有隔离的上下文。
- Worktrees：每个任务一个独立的 git worktree，并行的 agent 互不冲突。这一条后来成了整个行业的标准配置。
- 无头模式：codex exec 在 CI/CD 流水线里跑，不进交互界面。
33.4 OpenCode：把 agent 写进配置文件
OpenCode 的做法最透明：agent 是配置。opencode.json 或 markdown 文件里定义一个 agent，mode 字段三选一：primary（主会话可用）、subagent（只能被 Task 工具调用）、all（两者都行）。
内置的 subagent 覆盖了最常见的场景：general 是通用代理，有完整工具权限，可以并行跑多个实例干多步任务；Explore 是只读探索代理，找文件、搜关键字、答代码库问题，不能改文件；Scout 也是只读，负责外部文档和依赖研究，比如把某个依赖仓库克隆到托管缓存里对照源码。
两个细节值得抄。一是每个 agent 可以单独指定 model，主 agent 用强模型，子 agent 挂便宜快速的模型，成本立刻分化。二是 hidden: true 把子 agent 从 @ 自动补全里藏起来，用户在界面上点不到它，只允许其他 agent 通过 Task 工具程序化调用。权限也是按 agent 单独配的。
33.5 终端里的编排工具
CLI 内置的编排覆盖不到一种场景：你不想只开一个会话，想同时跑三五个、十几个 agent，各领各的任务。这时需要终端编排工具。下面四个，从底座到地图。
tmux：底座。 2007 年诞生的终端复用器，agent 编排的地基。模型很简单：一个 server 托着所有会话，断线随时 detach，回来一条命令 reattach，现场原样；窗口里随便分屏。这一领域的工具几乎都长在它上面：claude-squad 的每个实例是一个 tmux 会话，orchestrators 清单里一串工具的名字里都带着 mux。它只有一个问题：tmux 认识 pane，不认识 agent。哪个 pane 里的 agent 停下来等人了，它没有任何表示。
herdr：会看 agent 的运行时。 herdr（github.com/herdrdev/herdr，40.8k star，Rust）的自我定位一句话：the runtime your coding agents live on。一个后台 server 拥有 agent 的终端：关掉客户端、断掉 SSH，里面的终端照跑；机器重启后恢复布局，受支持的 agent 会话还能接回去。ctrl+b q 离开，敲一下 herdr 回来。每个 pane 标着 working、blocked、idle，agent 停下来要答案，herdr 直接告诉你，不用挨个 pane 找哪个卡住了。它不包装也不替换 Claude Code、Codex、Cursor、OpenCode 这些 agent，只当它们终端的房东。真正的差异在 agent-native：agent 自己通过 CLI 和 socket API 驱动 herdr，自己开 pane，互相发 prompt，等另一个 agent 真的 blocked 才继续。生态已经长出来：手机上的 collie、macOS 控制台 herdrm、审查侧栏 herdr-reviewr。
luvus：任务控制台。 luvus（github.com/RizRiyz/luvus，Rust）2026 年 6 月发布，比 herdr 再进一步。除了终端 pane 管理、agent 状态感知（连 token、成本、上下文占用都显示）和 Git、GitHub 面板，它把编排要用的东西也装了进来：建 worktree，管依赖任务，任务队列和路径租约按项目隔离，给 agent 派活，跑质量门，合并成品。Commander 从底部输入框向指定的几个 agent pane 群发 prompt。Claude、Codex、Grok 的会话可以带着完整上下文 fork 出一份。接口层是 UHP（Universal Harness Protocol），方法注册表带版本号，别人可以在上面造自己的编排器。
awesome-agent-orchestrators：地图。 前三个是工具，这是一个 awesome 清单（github.com/andyrewlee/awesome-agent-orchestrators，2k star），把编排工具分成几大类：终端并行 agent、桌面与 Web、Multi-Agent Swarms、自主循环 Runner、自主任务 Runner、基础设施原语、个人助理，另有一类 Resting 收录停止维护的项目。清单有网站版 agent-orchestrators.com，收录 221 个工具。这个领域月月出新东西，选型前先看这张地图。
33.6 本章小结
- 多个 agent 的两个动机：上下文隔离（中间产物不占主会话）和并行（独立工作单元同时开工）。
- 公司部门式的角色分工在 agent 上成批失败；活下来的方案靠共享任务记录，不靠角色头衔。
- Claude Code 三层编排：subagent（文件定义、独立上下文）、agent teams（多实例、共享任务列表、成员直连）、dynamic workflows（编排写成代码，上下文只留最终答案）。
- Codex 把 worktree 隔离和无头执行做成标配；OpenCode 把 agent 写进配置文件，每个 agent 可以配不同模型、不同权限。
- 终端编排的底座是 tmux 加 git worktree。herdr 让运行时会看 agent 的状态，luvus 把任务队列和质量门管起来，awesome-agent-orchestrators 是选型的地图。
至此编排的话题讲完。下一章回到单个任务的质量环节：代码审查。