多 Agent 编排——四 Lane 架构

学习目标

• 理解四 Lane 架构如何将 19 个专业 Agent 组织为可预测的协作模式
• 掌握 Build/Analysis、Review、Domain、Coordination 四个 Lane 的职责边界
• 能够设计自己的多 Agent Lane 系统
• 识别 Agent 过多导致的上下文爆炸问题

前置知识

多 Agent 编排的核心模式（Supervisor/Worker、Sequential 等）已在通用知识中介绍：

• 多 Agent 路由模式

下文假设你已理解 Supervisor、Sequential、Handoff 等基础模式，直接聚焦 OMC 的 Lane 架构——一种将 Agent 按生命周期阶段分组的组织方式。

项目实践

什么是 Lane 架构

OMC 的 19 个专业 Agent 不是平铺的列表，而是按职责分为四个 Lane（车道），每个 Lane 覆盖软件开发生命周期的不同阶段：

四个 Lane 的职责

Lane	Agent 数量	职责	模型倾向
Build/Analysis	8	完整的开发生命周期——从探索到验证	Haiku→Opus，覆盖三级
Review	2	质量门控——正确性与安全	以 Opus 为主
Domain	8	领域专家——测试、设计、文档	以 Sonnet 为主
Coordination	1	挑战者——审查计划和设计	Opus

典型流水线

OMC 中的典型流水线穿越多个 Lane：

Build: explore → analyst → planner → critic(review plan)
     → architect → executor → verifier
     ↓
Review: code-reviewer → security-reviewer
     ↓
Domain: test-engineer → qa-tester → writer(documentation)

Agent 的模型选择与 Lane 的关系

Lane 架构的另一个特点是模型分层：

• Build Lane 中的 Agent 覆盖了 Haiku→Sonnet→Opus 全部三级——从轻量探索到深度设计
• Review Lane 以 Opus 为主——需要最高质量的判断力
• Domain Lane 以 Sonnet 为主——中等推理能力即可胜任

问题与规避

问题 1：上下文爆炸

19 个 Agent 的描述如果全部加载到上下文窗口，会消耗大量 Token。OMC 的解决方案是：

• 按需加载：通过 getAgentDefinitions() 动态生成注册表，而非静态注入所有 Agent 描述
• Agent 类型声明：每个 Agent 有明确的 description 字段，用于路由决策

问题 2：Lane 间信息丢失

Build Lane 的产出传递给 Review Lane 时，如果信息传递不完整，Review Agent 可能做出错误判断。OMC 通过以下方式缓解：

• 明确的产出格式：.omc/plans/、.omc/autopilot/spec.md 等标准化产出
• 验证协议：Verifier Agent 在产出交接时检查完整性

问题 3：Lane 边界模糊

某些任务（如 tracer）同时涉及 Build 和 Review。OMC 的处理方式是明确归属——tracer 属于 Build Lane，其产出供后续 Lane 使用。

设计取舍

为什么选择 Lane 而非平铺？

维度	Lane 架构	平铺架构
可理解性	高——职责分组明确	低——19 个 Agent 难以理解
可扩展性	高——新 Agent 归入现有 Lane	低——每个新 Agent 都需要新的路由规则
调试性	高——问题定位到具体 Lane	低——19 个 Agent 中排查
灵活性	中——Lane 间通信有固定模式	高——任意 Agent 间可直接通信

OMC 的选择：Lane 架构牺牲了少量灵活性（Agent 间不能随意直接通信），换取了可理解性和可扩展性。

为什么不设独立的 Memory Lane？

OMC 将记忆管理集成到 Hook 系统中（Notepad、Project Memory），而非作为独立的 Lane。原因是记忆操作不是独立的”任务”，而是贯穿所有 Lane 的横切关注点。

参考来源

• OMC Architecture 文档 — 四 Lane 架构的官方描述
• Claude Code Agent SDK 文档 — Agent 编排基础