Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead 章节: 第11章 — Claude Code的商业设计 Model: openai/gpt-5.4 Generated: 2026-04-01 Token Usage: 当前API环境不可见
11.6 Bridge与Coordinator模式
如果说安全、成本、压缩体现的是 Claude Code 的商业工程底盘，那么 Bridge、Coordinator mode 与 assistant mode（KAIROS） 体现的，则是它在工作模式上的扩张。它不再把代理限定为“本地命令行里的单一会话”，而是开始把代理设计成一种可远程、可持续、可多代理协调的工作系统。
先看 Bridge。用户入口是 claude remote-control，而实现分布在 src/bridge/ 下的大量文件中，如 bridgeMain.ts、initReplBridge.ts、replBridge.ts、bridgeApi.ts 等。Bridge 的本质，是把本地 CLI 会话变成可被远端访问和继续的会话端点。也就是说，终端不再是唯一前端，Web 或移动端也可以接管、继续或接入这个工作流。
这件事意义很大。第一，它提供了 远程会话支持。会话不必随着当前 shell 退出而消失，而可以被继续、恢复、迁移。第二，它让 Claude Code 融入更大的产品生态：CLI、网页、移动端不再是分裂体验，而是同一会话拓扑上的不同入口。bridgeMain.ts 中关于环境注册、心跳、session spawn、token refresh、继续参数 --continue / --session-id 的实现，说明这不是简单的转发层，而是一套会话基础设施。
再看 Coordinator mode。它要解决的不是“远程接入”，而是 多代理编排。在 coordinatorMode.ts 中，Claude Code 明确把主代理定义为协调者：负责分派 worker、汇总研究结果、制定实现方案、组织验证，并管理 worker 的生命周期。文件里甚至写了完整的并行策略、通知格式、停止 worker 的规则、以及如何继续已有 worker 的流程。这已经不是“能开子代理”这么简单，而是正式的 orchestration protocol。
从产品角度说，这非常关键。很多开源代理用户会手工构造“主代理 + 若干子代理”的工作流，但那往往停留在提示词技巧或外部脚本层面。Claude Code 则把这种模式内建进产品行为中。协调者知道何时并行、何时综合、何时验证、何时中止，这意味着多代理不再只是实验性玩法，而变成了受支持的工作模式。
接着是 assistant mode（KAIROS）。代码中大量 KAIROS gate 表明，它与长运行、持续交互、会话续接、brief view、定时检查等能力有关。直观上可以把它理解为：Claude Code 不再只响应当前这一轮请求，而是在逐步向“长期陪伴式代理”演化。也就是说，代理从一次性应答者，转向长期会话参与者。
这三者结合起来，就形成了一种比传统 CLI agent 更强的会话拓扑：本地与远程可以打通，单代理与多代理可以切换，短会话与长会话可以延续。商业上，这类能力尤其适合高级用户与企业用户，因为他们真正关心的往往不是某一轮问答质量，而是复杂任务能否跨设备、跨时间、跨多个 worker 稳定推进。
与 OpenCode 和 Oh-My-OpenCode 相比，Claude Code 在开放可编排程度上未必最自由，但在 把远程控制、持续会话、多代理编排做成正式产品模式 这一点上，显然更成熟。这种成熟度来自它把会话当成基础设施来设计，而不只是把消息当成输入输出。
因此，本节最重要的启示是：未来编码代理的竞争，未必只发生在模型推理层，也会发生在 会话拓扑设计 上。Bridge、Coordinator 与 KAIROS 展示的，正是 Claude Code 对这一趋势的提前布局。
深度解析：Claude Code 的子智能体架构
Model: openai/gpt-5.4
Token Usage: 当前API环境不可见
前面我们把 Bridge 和 Coordinator mode 视为产品层能力，但如果继续往下看，会发现 Claude Code 真正更值得分析的部分，是它把“子智能体系统（sub-agent system）”做成了运行时架构，而不是只靠提示词模拟出来的工作流。很多系统也会说自己支持 sub-agent，但本质上只是主智能体在同一个大上下文里多做几次调用，或者手工伪装出“委派”语气。Claude Code 更进一步：它有明确的 AgentTool、Task Tools、SendMessageTool、Coordinator mode，以及可声明的自定义 agents。这些组件合起来，才构成了一个相对完整的多智能体执行平面。
这个执行平面的核心，不只是“能不能多开几个 agent”，而是 上下文如何隔离、任务如何异步推进、结果如何压缩回流、角色如何被制度化。如果把它放到更大的 Agent Engineering 语境里看，Claude Code 的子智能体系统，最接近的是一种以 Context Firewall 为中心原则的架构。
这里需要解释一下 Context Firewall。它不是传统 CS 教科书里的标准术语，而是近年 agent 工程里很有代表性的衍生概念。类比网络里的 firewall：防火墙的作用，是控制不同网络域之间的信息流动；而 Context Firewall 的作用，是控制不同 agent 上下文之间的信息流动。它不是简单地“不给看历史”，而是有意识地限制哪些信息可以跨上下文传播，避免一个 agent 的错误路径、噪音历史、无关细节，把另一个 agent 也拖进同样的混乱里。
graph TB
Main["🧠 主智能体<br/>(父上下文)"]
Main -->|"AgentTool"| SA1["🤖 子智能体 1<br/>隔离上下文"]
Main -->|"AgentTool"| SA2["🤖 子智能体 2<br/>隔离上下文"]
Main -->|"TaskCreate"| BG1["⏳ 背景任务<br/>(DreamTask)"]
SA1 -->|"压缩结果"| Main
SA2 -->|"压缩结果"| Main
BG1 -->|"TaskOutput"| Main
SA1 -.->|"SendMessage"| SA2
subgraph "上下文防火墙"
SA1
SA2
BG1
end
CA[".claude/agents/<br/>自定义智能体定义"] -.->|"定义"| SA1
CA -.->|"定义"| SA2
style Main fill:#4a9eff,color:#fff
style SA1 fill:#51cf66,color:#fff
style SA2 fill:#51cf66,color:#fff
style BG1 fill:#ffd43b,color:#000
1. AgentTool：真正的子智能体生成机制
Claude Code 子智能体架构的第一核心组件，就是 AgentTool。从功能上看，它负责创建一个新的 agent，并由父 agent 把某个任务委派给它；但从架构角度看，AgentTool 最关键的意义不在“spawn”，而在“spawn 之后给什么上下文”。
如果一个父 agent 把自己的全部历史、全部推理残留、全部上下文噪音都原样塞给子 agent，那么这个子 agent 并不是真正独立的执行单元，它只是主线程的延长。Claude Code 显然不想走这条路。它更强调：子 agent 应该拿到一个干净的、为当前任务裁剪过的上下文窗口。这就是 Context Firewall 的直接体现。
这种设计有几个明显好处。
第一，降低认知污染。认知污染可以理解为：与当前子任务无关、甚至误导性的历史信息，持续占据上下文资源，影响后续判断。这也不是经典教材术语，但很适合描述 agent 场景下的一个常见问题。
第二，强化角色纯度。所谓角色纯度，意思是一个 agent 更像在执行自己被赋予的职责，而不是一边工作一边重演主 agent 的全部犹豫、转向和未完成推理。
第三，提高稳定性。如果父 agent 在前文里有错误假设、错误方向、错误心理预期，子 agent 不必全部继承。
第四，节省 token 预算。少带无关历史，意味着更多窗口可以留给真正的任务本身。
当然，这种做法也有代价。一个完全干净的子上下文，有可能丢掉父智能体在前面回合中积累的一些隐性经验，比如哪些方案试过了、哪些路径已经失败、哪些约束虽然没显式写出来但其实非常关键。Claude Code 的选择是：宁可容忍部分重复探索，也优先保证上下文隔离的可靠性。这是一种很典型的商业系统取舍。
2. 子智能体返回的是压缩结果，不是完整思维残留
AgentTool 的第二个关键点，是 返回路径设计。子智能体不是把一整段原始对话、原始搜索轨迹、原始中间废话全部倒回给父智能体。更合理的方式是：子智能体把结果压缩成摘要、发现、建议、结论，再回传给父智能体。
这件事非常重要，因为多智能体系统最容易失控的地方，不是“开太多 worker”，而是 结果回流带宽失控。这里的“带宽（bandwidth）”也是借用分布式系统的概念。在网络里，带宽是节点之间可传输的数据量；在 agent 系统里，也存在类似问题：一个 agent 的内部工作产物，到底应该有多少传给另一个 agent？
如果传得太少，父智能体可能拿不到足够信息，导致子任务价值被浪费；如果传得太多，父智能体上下文就会迅速膨胀，最后所有子智能体产生的噪音又重新汇入中心，等于 Firewall 白做了。Claude Code 的选择是明显偏向 摘要化回流：保留有效结论，压缩中间噪音。
这意味着 Claude Code 的父智能体，更像一个阅读各类“工作报告”的 coordinator，而不是一个吞噬所有原始过程日志的上下文黑洞。这种设计非常成熟，因为它抓住了编排系统的本质：不是让所有人共享一个超长 transcript，而是让每个角色在有限带宽下交换高价值信息。
3. .claude/agents/：声明式定义的 Custom Agents
Claude Code 的第三个关键点，是 Custom Agents。这些 agents 可以在 .claude/agents/ 目录中以 Markdown 文件 + YAML frontmatter 的形式定义。这个设计看起来朴素，实际上非常有战略意义。
它意味着 agent specialization 不一定非要写死在程序逻辑里，也可以被表达成一种 声明式配置对象。所谓“声明式（declarative）”，也是需要解释的衍生术语。它与“命令式（imperative）”相对。命令式更强调“怎么做”；声明式更强调“我要什么性质、什么约束、什么角色”，由运行时去解释执行。
在 Claude Code 里，一个 custom agent 通常可以描述：
- 名称与用途说明；
- system prompt 或角色设定；
- 工具白名单 / 允许工具范围；
- model preference；
- 被
/agents命令或 AgentTool 调用时的元信息。
这很像 OMO 里的 Oracle、Explore、Librarian 这些专用 agents，但两者底层哲学不同。OMO 的 specialized agents 更偏程序化定义：它们常常跟 category routing、fallback chain、prompt builder、tool discipline、hook enforcement 紧密耦合。Claude Code 的 custom agents 更偏声明式定义：角色被写进 markdown，运行时负责装配和执行。
这两种方式各有优劣。声明式定义的优点，是可读、可审查、可版本化、易共享；程序化定义的优点，是能写出更复杂的动态逻辑、更细的路由规则、更强的回退链。前者更适合团队治理和产品化；后者更适合高强度 orchestration engineering。
4. Task Tools：让子智能体异步运行，而不是阻塞父智能体
如果说 AgentTool 解决的是“如何生成一个子 agent”，那么 Task Tools 解决的就是“这些子任务如何在时间维度上被管理”。
关键组件包括：
- TaskCreateTool：创建后台任务；
- TaskGetTool：查询任务状态；
- TaskListTool：列出已有任务；
- TaskOutputTool：获取任务产出；
- DreamTask：支持更长时间、更持续的后台处理。
这里最核心的思想，是 异步（asynchronous）。异步是教材里有的标准概念，但放到 agent 里需要具体化：父 agent 在把工作交给子任务后，不必卡住原地等待，而是可以继续推进别的事情，之后再回来查看状态、读取结果、决定下一步。这一点和 OMO 的 background agent 很像，但 Claude Code 把它包装成了更清晰的工具层接口。
为什么异步这么重要？因为复杂工程任务天然存在不同时间尺度。有的搜索几秒完成，有的静态分析更久，有的跨目录综合、远端持续任务、或者更复杂的整理工作则可能明显更长。如果所有事情都塞在一个同步回合里，系统会变得两头不讨好：要么一直等，交互迟钝；要么把大量中间状态塞进当前上下文，导致窗口被撑爆。Task Tools 等于把“任务启动”和“任务回收”分离开，形成一个更接近操作系统作业管理的模式。
5. SendMessageTool：没有共享大脑，但有消息传递
Claude Code 还有一个非常值得注意的部件：SendMessageTool。它允许一个运行中的 agent 给另一个运行中的 agent 发送消息。这听起来像个小功能，但它意味着 Claude Code 的多智能体系统，不只是单向“父派子、子回父”，而是出现了最基本的 agent-to-agent communication。
要理解这一点，可以借用分布式系统中的两种经典协作方式：shared memory（共享内存） 与 message passing（消息传递）。共享内存的做法，是所有参与者访问同一块状态空间；消息传递的做法，是各自保持边界，只通过明确消息来交换信息。
Claude Code 明显更偏后者。它并没有把所有 agent 融成一个共享大脑，而是让它们通过显式消息互相协调。这种方式虽然原始，但有两个优势：
第一，边界清晰。你可以知道是谁在什么时候给谁发了什么。
第二，更有利于隔离。不会因为某个 agent 修改了一块共享状态，就让整个系统一起被污染。
当然，SendMessageTool 目前看还不是一个高度复杂的 agent bus，也不是完整的 actor system，但它至少说明 Claude Code 已经超越了“单向子任务回传”的最简单模型。
6. Coordinator mode：从能力集合上升为编排协议
如果只有 AgentTool、Task Tools 和 SendMessageTool，那么 Claude Code 已经具备不错的多智能体基础设施；但 Coordinator mode 更进一步，它把这些分散能力上升成一种更清晰的工作协议。
最适合描述 Claude Code Coordinator mode 的结构，是 Hub-and-Spoke。这个词也不是传统算法教材的核心术语，但在系统设计里很常用。Hub 是中心枢纽，Spoke 是从中心向外辐射的支点。用到 agent 上，就是：一个中央协调者负责拆解任务、派发工作、收回结果、做最终综合；多个 worker 分别处理不同子问题。
Claude Code 的 Coordinator mode 本质上就是这种枢纽-辐射式结构。Coordinator 是 hub，sub-agents 是 spokes。每个 spoke 都有自己的上下文窗口和工作边界，主 agent 负责监控、整合、校验、收束。
这和 OMO 的 Atlas 很像，但又不完全一样。OMO 更像一种 层级更强的三层结构：Planning → Execution → Workers。也就是说，除了中心协调者和底层 worker，还会显式区分更高层的规划职责与中层执行职责。Claude Code 则更平一些：中心很强，worker 很清楚，但层之间没有 OMO 那样被制度化得那么深。这种“更平”的结构更易产品化、更易理解、更易控，但在超大任务中，表达能力也可能略逊于更厚重的层级系统。
7. Context Isolation 与 OMO Wisdom Transfer 的根本分歧
从更高层看，Claude Code 和 OMO 的差异，并不只是工具多少，而是 记忆哲学 不同。
Claude Code 的默认倾向，是 Context Isolation。每个子 agent 尽可能在干净上下文里工作，结果以摘要形式回传，跨上下文的信息传播被严格控制。
OMO 的默认倾向，则是 Wisdom Transfer。前面完成的任务可以沉淀出“智慧”或任务知识，后续子智能体能够继承这些结果。这样做的好处是：整个任务链条有更强的连续性，后来的 agent 不必从零开始重复理解。
这两种路线，本质上是在回答同一个问题：一个 agent 学到的东西，是否应该被后续 agent 自动继承？
Claude Code 的答案偏向：可以继承，但必须是受控的、压缩过的、边界清晰的继承。
OMO 的答案偏向：应该尽量继承，因为复杂任务真正有价值的是累积出来的 mission intelligence。
Claude Code 这一路线的优势，是可靠、可控、边界明确；OMO 这一路线的优势，是连续性强、重复劳动少、整体任务更像一个持续学习过程。问题在于，Wisdom Transfer 一旦做不好，就会出现前面提到的 context pollution：早期错误、过时判断、局部假设，被当作“智慧”一路传下去。反过来，Context Isolation 做得太绝，也会导致后续 agent 重复踩坑。
所以更准确的说法不是谁对谁错，而是两者分别押注了不同的最优点。Claude Code 押注 局部可靠性，OMO 押注 全局连续性。
8. 对 Agent 设计的更普遍启示
Claude Code 的子智能体架构之所以值得在书里补一大节，不只是因为它“功能挺多”，而是因为它代表了一种非常清晰的多智能体设计思路：
- 明确生成子 agent；
- 默认隔离上下文；
- 用任务系统管理异步生命周期；
- 用摘要而不是原始残留来回流结果；
- 在必要时允许 message passing，而不是完全共享上下文。
这套组合的价值，在于它试图解决现代 coding agent 的一个核心难题：怎样扩大工作规模，而不把整个系统变成一个巨大的脏上下文池？
如果从“理想系统”的角度看，未来最值得追求的，也许不是简单站队 Claude Code 或 OMO，而是做一种混合方案：默认使用 Claude Code 式的 Context Firewall 保持 worker 干净；同时借鉴 OMO 的 Wisdom Transfer，但只传递经过验证、结构化、可审计的知识对象，而不是传递原始对话残留。
那样的系统，既能保留局部可靠性，也能获得长期任务中的累积智能。换句话说，Claude Code 的子智能体架构真正提出的，不只是一个实现方案，而是一种更普遍的设计命题：多智能体扩展，不应该依赖无限膨胀的单一上下文，而应该依赖边界清晰、职责分明、信息流受控的“受约束智能体社会”。