我们识别出六种不同的多智能体模式：

1. 1.

   单智能体（无多智能体）：Mini-SWE-Agent、Aider——以及 Pi 的核心，它不带派生或任务工具；其子智能体住在扩展空间里（见下）。

2. 2.

   顺序委派：Mistral Vibe（父级经 task 工具派生子智能体并等待完成）。

3. 3.

   并行子会话：OpenHands（task 与 delegate 工具把子级作为独立对话运行，在线程中并发）、OpenCode（task 创建跑同一循环的子会话；一条消息里的多次调用并发执行）。

4. 4.

   带扇出的分层线程树：Codex（专门线程、分叉模式控制的继承、按模型的工具世代、map-reduce 扇出、持久化的父/子拓扑）。

5. 5.

   递归组合：Claude Code（智能体以可组合方式派生子智能体，分叉共享提示词缓存）。

6. 6.

   注册表 + 跨进程协议：Gemini CLI（对称的本地/远程会话协议背后的具名智能体定义，远程智能体走 A2A）、OpenClaw（ACP 会话派生）、Hermes 的看板集群（SQLite 黑板上的子进程）。

表 9 给出详细对比；图 6 让每种模式的形状一目了然。

Claude Code 的多智能体架构是所研究系统中最精巧的。 它支持三个层次的协调：临时子智能体、类型化的智能体定义，以及完整的协调者模式。

Codex 的多智能体架构围绕三个核心抽象构建：

V0 时代的 AgentDelegateAction（顺序、一次一个、共享事件流）已成历史。 V1 SDK 经工具委派：一个形状明显 Claude Code 化的 TaskTool（prompt、subagent_type、description、resume），配一个 TaskManager 为每个任务创建独立对话（自己的事件日志，指标回传）；还有一个带 spawn/delegate 命令的 DelegateTool，把受委派任务在线程中并发运行。 子智能体声明为带 YAML frontmatter 的 Markdown 文件（名称、描述、模型、工具、技能、Hook、MCP 配置、权限模式、凝聚器），位于项目/用户/内建/插件层级——内建包括 code-explorer、bash-runner 与 web-researcher（外加一个 general-purpose 默认）——且显式支持嵌套。 委派层之上还有一个脚手架级的外层循环：/goal 端点在每次运行后让一个 LLM裁判审读转录，要么注入后续提示词，要么带完成状态停止，再配上可插拔的批评家（critic），细化迭代上限可配置。

Mistral Vibe 的多智能体支持刻意简单：父智能体调用 task 工具，后者以请求的智能体档案（如 explore）构造一个全新的 AgentLoop 实例，进程内跑到完成，再把子智能体的 AssistantEvent 输出与 ToolResultEvent 摘要返回给父级。 一个守卫确保只有标注为“subagent”的档案（目前仅 explore）可被委派，防止意外递归升级到可写档案。 每个子智能体拿到全新的 VibeConfig、自己的会话目录和独立的消息历史，隔离程度堪比 Codex 的线程树，代价是没有真并行：父级 await 阻塞到子智能体退出。 架构上的简单（一个工具、顺序、进程内）意味着 Mistral Vibe 停在多智能体光谱的简单端——语料库中最简短的委派（再简就没了），令人想起 OpenHands 已退役的 V0 AgentDelegateAction。

Gemini CLI 的多智能体模型分两层。 本地，一个 AgentRegistry 保存具名智能体定义——带强制 YAML frontmatter 的 Markdown 文件——从用户、项目与扩展作用域加载。 例如内建的 generalist 智能体授予全部已注册工具的访问，运行预算为 10 分钟、20 轮。 调用经 /agent 斜杠命令、@agent-name 提示记法，或——自 v0.39 的子智能体统一以来——一个可被模型调用的 invoke_agent 工具，每次运行拿到一个隔离的工具注册表。 调用路径已被抽象到一个智能体会话协议之后，带对称的本地与远程实现，因此由进程内执行器支撑的注册表条目与由远程 A2A 智能体支撑的注册表条目，走同一个接口驱动。

Gemini CLI 与语料库中所有其他系统的分歧点在 packages/a2a-server 模块——Google 的智能体对智能体（Agent-to-Agent, A2A）协议的实验性实现。 A2A 之于智能体间通信，犹如 MCP 之于工具集成：一个 JSON-RPC 标准，让一个智能体进程去发现另一个、向其认证并交换消息——对方可能在另一台机器上、由另一家厂商构建。 Gemini CLI 的 A2A 服务器让远程编排器像驱动一个已注册的本地智能体那样驱动本地 Gemini CLI 实例——如今还经该协议上报用量元数据以做跨厂商资源核算——为跨厂商的多智能体拓扑打开了大门，没有其他语料库系统原生支持这一点（第 14.4 节的元 Harness 恰好从外部构建这样的拓扑）。

Hermes 是默认扁平的委派，向上留了两个逃生舱。 delegate_task 在线程池上进程内构建子智能体：全新对话、聚焦的系统提示词、只回摘要、工具集与父级求交（“子智能体不得获得父级没有的工具”），外加一个六工具黑名单（不许递归、不许用户交互、不许写记忆、不许调度）。 默认保守——三个并发子级、50 迭代预算、深度 1——但一个 role="orchestrator" 配置加派生深度设置即可解锁嵌套树，编排者提示词块明确“以 OpenClaw 的 buildSubagentSystemPrompt 为原型”。 后台委派返回一个句柄，并经完成队列以全新轮次再进入，而不是在轮次中途拼接——一个保提示词缓存的选择。 再往上是一个进程级层：看板集群把 计划根 $\to$ 并行工作者 $\to$ 验证器 $\to$ 合成者作为独立的 hermes -p <profile> 子进程运行，经一块 SQLite 看板和一块结构化 JSON 评论黑板协调——通过共享数据库而非协议或通道实现的协调者-工作者。 第三层叠加 /moa 扇出多个咨询型参考模型（最多八个并发），其输出为主模型的下一次迭代调味。

核心 Pi 没有派生或任务工具——子智能体是其扩展论点的旗舰示范，以约 $\sim$1,000 行的示例交付。 每次调用派生一个独立的 pi --mode json -p --no-session 操作系统进程，从构造上获得硬性上下文隔离；父级解析子级的 JSONL stdout 做进度与成本汇总。 一个工具提供三种形态：single、parallel（工人池 4，最多 8 个任务）与带 {previous} 替换的 chain。 智能体定义是 Markdown 加 frontmatter，经子级的 --tools 标志过滤工具；没有深度计数器，也没有运行中的父子消息传递。 单进程之上，一个实验性的 orchestrator 包以 RPC 模式监督 Pi 实例舰队，并向一个托管协调者注册在场——多实例管理，而非循环内协调者。 值得注意的是，Pi 真做多智能体时，落在跨进程 JSONL 而非进程内原语上——第 13.3 节会回到这个数据点。

OpenCode 的子智能体是子会话，不是另一个引擎：task 工具创建一个带 parentID 的 Session，跑同一个循环，可经 task_id 恢复，只返回包在 <task_result> XML 里的最终助手文本；后台结果作为合成的用户消息注入。 智能体与模式统一在一个 schema 里（mode: primary|subagent|all）：内建有 build、plan（除计划文件外拒绝编辑）、general、只读的 explore，外加隐藏的 compaction/title/summary 工具智能体——plan 模式是一个权限规则集加一条 <system-reminder> 注入，而不是架构叠加。 工具可用性处处由权限派生（对某工具拒绝 "*" 即把它从 LLM 视野移除），且封禁是不对称的：子级只继承父级的拒绝规则。 递归默认关闭（task 对子级自动拒绝），但可按智能体选择启用且无数字深度上限；自定义智能体来自配置、Markdown 文件，或者——独一份——LLM 生成（对 {identifier, whenToUse, systemPrompt} 跑 generateObject）。

OpenClaw 的多智能体模型根本不同：它经一个 ACP（Agent Client Protocol，Zed/Google 面向编辑器的 JSON-RPC 标准，见 agentclientprotocol.com，不是 IBM 更早的同名 Agent Communication Protocol）转换器运作，把网关线上协议桥接到智能体进程。 子智能体作为子进程派生，绑定 RPC。 每个智能体有自己的会话，JSONL 转录持久化。 通信经 ACP 增量事件（文本、思考、工具调用）而非共享内存。 速率限制器（MAX_PROMPT_BYTES = 2MB）提供 DoS 防护。

观察 7。协调者-工作者在语料库中独立涌现：全部四个厂商原生系统（Claude Code、Codex、Gemini CLI、Mistral Vibe）、OpenHands（会话树上的并行委派）、Hermes（配置门控的编排者角色加 SQLite 黑板上的子进程集群——一个新颖的协调基底）、OpenCode（并发子会话），以及协议层的 OpenClaw。我们在这里宽泛地使用协调者-工作者一词，泛指一切父级派生工作者的委派；第 6 节较窄的规定性叠加层只适用于 Claude Code、Codex 与（门控的）Hermes。如此多独立开发的代码库收敛到同一个分层形态，是趋同演化的有力证据——不过这种趋同应当限定于把多智能体内建进核心的系统：Pi 是一个刻意单智能体交付的生产级 SWE Harness，把子智能体降级到扩展空间。各实现在优化目标上的分歧颇有教益：Claude Code 分叉上下文并在子级间共享提示词缓存（成本）；Codex 构建深度跟踪的线程树，带类型化的智能体间记录、按模型的工具世代与 CSV 扇出（隔离与规模）；Gemini CLI 把调用抽象到对称的本地/远程会话协议之后（可移植性）；Mistral Vibe 进程内顺序跑子智能体（简单性）；Hermes 求交工具集并默认拉黑递归（封禁）。Hadfield 等人 [17] 把编排者-工作者描述为“涉及重度并行、信息超出单个上下文窗口、需要对接大量复杂工具的高价值任务”的自然模式——这恰好也是一段长程编码会话的公允写照。

Claude Code 与 Codex 是两大占主导的商业编码智能体，各自代表其供应商生态的最先进水平。 从用户请求到完成任务的端到端编排管线，两者的设计立场很不相同。 表 18 突出关键分歧。

这张表揭示出两种自洽的哲学，而两者的差距在我们两次快照之间已出现可测量的收窄。 Claude Code 是组合式-规定性的：它强制结构化阶段（研究 $\to$ 综合 $\to$ 实现 $\to$ 验证），经工具白名单限制子智能体能力，递归组合智能体，并围绕提示词缓存经济学激进优化。 Codex 曾经是沙箱式-涌现型——安全在操作系统层保证，工作流组织交给模型——但它长出了自己的规定性结构：带 Plan 预设的面向用户协作模式选择器、声明式子智能体角色、深度跟踪的派生控制，以及一个映照 Claude Code 中间权限层的 Guardian 分类器；与此同时 Claude Code 的 Hook 词汇与插件格式成了 Codex 的接口（第 14.5 节）。 两者在真实基准上都产出强劲结果；残存的哲学分歧在于安全在哪里得到保证（操作系统强制 vs. 分层审查），而不在工作流如何组织。