当 AI 编码遇上多智能体编排：OMO-OPSX 融合方案的设计与实践

如何将 SDD（规范驱动开发）的结构化工作流与多智能体并行编排深度融合，在 AI 辅助编码中同时实现高吞吐与高可靠。

一、引言：AI 编码的效率天花板

2025 年以来，AI 辅助编码已经从”补全一行代码”进化到”端到端实现一个功能”。行业数据令人振奋——Atlassian 在全面采用 AI Agent 后测量到工程师人均 PR 数量提升了 89%；Stripe 的 Agent 系统每周自主合并超过 1000 个 PR；Rakuten 利用 AI Agent 在 7 小时内完成了 1250 万行代码库上的复杂 vLLM 实现。

但随着 AI Agent 承担的任务从单文件修改扩展到跨模块的复杂变更，一个新的瓶颈开始浮现：

单智能体顺序执行的效率天花板。

想象一下这个场景：你要给项目新增一个用户认证模块。这涉及数据模型、API 端点、中间件、前端集成和测试——至少 5-6 个相互关联的子任务。在传统的单 Agent 模式下，即便这些任务中有些彼此独立，AI 也只能一个接一个地串行执行。5 个任务各花 5 分钟，总耗时就是 25 分钟。

更致命的是质量问题。单 Agent 既当运动员又当裁判：自己写的代码自己验证，缺少独立的质量门控。研究表明，多智能体系统中 13.2% 的失败来自推理-动作不匹配，7.4% 来自任务偏离，6.8% 来自错误假设。当 Agent 对某个 API 不确定时，它可能会猜测类型、留下 TODO、甚至抑制类型检查——这些”半成品”在复杂项目中会迅速积累成技术债务。

微软研究院将 “意图形式化”（Intent Formalization） 定义为可靠 AI 编码的核心挑战——如何自动将模糊的人类意图转化为精确、可检查的规范。这恰恰是 SDD（规范驱动开发）试图解决的问题。

这驱使我们思考两个核心问题：

1. 能不能让多个 AI 智能体并行工作，像流水线一样同时处理互不依赖的任务？
2. 能不能在 AI 执行链路中嵌入结构化的质量门控，让”写代码”和”验代码”由不同的角色完成？

OMO-OPSX 正是对这两个问题的回答。它将 OpenSpec 的规范驱动开发（SDD）工作流与 OMO（oh-my-opencode） 的多智能体编排能力深度融合，在保持开发灵活性的前提下，实现并行加速与分层质量保障。这种融合代表了一种正在兴起的工程范式——有人称之为**”复合工程”（Compound Engineering）**：工程师的角色从”代码编写者”转变为”系统编排者”，通过设计约束、编排智能体和验证输出来实现 3-7 倍的生产力提升。

---

二、背景：这些东西原来是什么

在深入融合方案之前，有必要先了解两个核心组件各自的定位。

2.1 OpenSpec：规范先行的变更管理

OpenSpec 是一个开源的 Spec-Driven Development（SDD） 框架，在 GitHub 上拥有超过 3.6 万颗星。它的核心理念用官方的话说：

“AI coding assistants are powerful but unpredictable when requirements live only in chat history. OpenSpec adds a lightweight spec layer so you agree on what to build before any code is written.”

简单来说：在让 AI 写代码之前，先用结构化的规范文档把”要做什么”和”怎么做”对齐。

每个需求变更在 OpenSpec 中是一个独立的文件夹：

openspec/changes/add-user-auth/
├── proposal.md    # 做什么、为什么做
├── design.md      # 怎么做（架构与方法）
├── specs/         # 技术规范（接口契约、数据模型）
└── tasks.md       # 实现任务清单

工作流通过 CLI 命令驱动，分为四个阶段：

命令	阶段	产出
openspec explore	探索	自由思考，无固定产出
openspec propose	提案	四件套：proposal + design + specs + tasks
openspec apply	执行	代码实现
openspec archive	归档	变更移入归档目录，规范同步

OpenSpec 的设计哲学是 “流动而非僵化”（fluid not rigid）——迭代而非瀑布，简单而非复杂，既适用于全新项目也适用于存量项目。探索阶段是完全自由的对话，不强制任何格式；提案阶段才开始结构化。制品之间还支持反向更新——随着实现深入，你可以随时修正 proposal 或 design。

但问题是：原生 OpenSpec 采用单智能体顺序执行。探索是单线程搜索，制品逐个创建，任务一个接一个执行。在小型变更中这没问题，但复杂变更的效率瓶颈非常明显。

2.2 OMO：多智能体编排引擎

OMO（oh-my-opencode，现已更名为 oh-my-openagent） 是一个构建在 OpenCode 之上的多智能体编排系统，GitHub 上拥有超过 4.5 万颗星。用官方的话说：

“It transforms a single AI agent into a coordinated development team that actually ships code.”

它的核心能力是：让多个专业化的 AI 智能体并行工作，各司其职。

OMO 提供了多种类型的智能体：

智能体	角色	成本
explore	代码库搜索，多角度并行发现	免费（本地工具）
librarian	外部文档查找，库/API 最佳实践	低
metis	需求完整性分析，发现隐藏需求和歧义	中
momus	计划可执行性审查，循环直到通过	中
oracle	架构咨询，深度权衡分析，最终验证	高

这些智能体通过统一的 task() API 调度，支持后台并行执行。编排器（Orchestrator）负责分发任务、聚合结果、触发验证，而工作者（Worker）专注于原子任务的确定性执行。

OMO 的优势在于并行能力和质量门控，但它缺少 OpenSpec 那样的结构化变更管理——没有从需求到规范到代码的完整链路。

2.3 为什么要融合

两者的互补关系非常清晰：

能力	OpenSpec	OMO
结构化变更管理	✅ 完整的 SDD 生命周期	❌ 无
并行执行	❌ 单智能体顺序	✅ 多智能体并行
质量门控	❌ 无结构化验证	✅ 三层门控
确定性协议	❌ 无	✅ UltraWork 协议
断点续跑	❌ 中断需从头开始	✅ 检查点机制
探索灵活性	✅ 自由形式	✅ 智能体可选

融合目标：保留 OpenSpec 的 SDD 哲学和变更管理能力，注入 OMO 的并行编排、质量门控和确定性执行，让整个链路既快速又可靠。

---

三、融合方案设计

3.1 整体架构：5 个技能覆盖完整生命周期

OMO-OPSX 设计了 5 个技能（Skills），对应 SDD 的完整生命周期：

想法/问题                                                      交付
  │                                                              │
  ▼                                                              ▼
explore ──> brainstorm ──> propose ──> apply ──> archive
(发散)     (收敛)        (制品化)    (实现)    (归档)

  姿态        流程          流程        流程       流程
  无产出    design-brief   artifacts   code     archived

注意 brainstorm 是融合方案新增的阶段——它是 explore（发散）和 propose（制品化）之间的收敛桥梁，解决了原来探索阶段的上下文在跨阶段时丢失的问题。

3.2 核心设计：Orchestrator-Worker 两层架构

融合方案采用严格的两层架构，这是确保并行安全的关键：

┌─────────────────────────────────────────────────────┐
│               Orchestrator (depth=0)                │
│  • 唯一能调用 task() 的层级                          │
│  • 负责：探索、并行分发、结果聚合、质量门控           │
└────────────────────┬────────────────────────────────┘
                     │ task(...)
         ┌───────────┼───────────┐
         ▼           ▼           ▼
    ┌─────────┐ ┌─────────┐ ┌─────────┐
    │Worker 1 │ │Worker 2 │ │Worker N │
    │(depth=1)│ │(depth=1)│ │(depth=1)│
    │不可调用  │ │执行确定  │ │返回交付  │
    │task()   │ │性工作   │ │物       │
    └─────────┘ └─────────┘ └─────────┘

关键规则：Worker 不得调用 task() 创建子智能体——这防止了递归调用导致的不可控行为。Worker 要么完全完成任务，要么明确报告阻塞原因。

3.3 DAG Wave 并行执行模型

这是融合方案最核心的创新。传统的 tasks.md 是一个扁平列表，融合方案将其升级为带依赖关系的有向无环图（DAG）：

## Dependencies
<!-- deps:
T1: []
T2: []
T3: [T1]
T4: [T1, T2]
T5: [T3, T4]
-->

## Wave 1 (并行)
- [ ] T1: 创建用户认证模型 [critical]
- [ ] T2: 添加 JWT 工具函数

## Wave 2 (并行, after Wave 1)
- [ ] T3: 实现登录端点 (depends: T1)
- [ ] T4: 实现注册端点 (depends: T1, T2)

## Wave 3 (after Wave 2)
- [ ] T5: 添加认证中间件 (depends: T3, T4) [critical]

执行语义：

• Wave 内并行：同一 Wave 中的任务作为独立 Worker 同时执行
• Wave 间顺序：Wave N+1 等待 Wave N 完全完成并验证通过
• 关键路径标记：最长依赖链上的任务标记 [critical]，触发额外验证

效果对比：

顺序执行(原始):            并行执行(融合):
T1→T2→T3→T4→T5              Wave 1: T1, T2 (并行)
5m+5m+5m+5m+5m                    ↓
= 25 分钟                   Wave 2: T3, T4 (并行)
                                   ↓
                            Wave 3: T5
                            = 15 分钟 (~40% 提升)

3.4 三层质量门控

单 Agent 自己验证自己的代码是不够的。融合方案引入了三层递进式质量保障：

第一层：需求完整性（提案阶段）

在创建任何代码之前，Metis 智能体分析变更提案：

• 用户故事是否完整？
• 边缘情况是否覆盖？
• 成功标准是否可测量？
• 是否有隐式假设？

第二层：任务可执行性（提案阶段）

Momus 智能体审查 tasks.md：

• 每个任务是否原子且具体？
• 依赖关系是否正确？
• 能否无歧义地执行？

Momus 会循环审查直到通过（设有上限防止无限循环）：

Round 1: 提交 → REDO（反馈修正）
Round 2: 重新提交 → REDO（继续修正）
Round 3: 重新提交 → OKAY ✓
超过上限 → 降级为人工审查

第三层：最终一致性（执行阶段）

所有任务完成后，Oracle 智能体进行全局验证：

• 实现是否匹配 proposal/design？
• 是否有遗漏？
• 成功标准是否满足？

Oracle 说”VERIFIED”才是真完成。 智能体说 DONE ≠ 已验证。

3.5 UltraWork 确定性协议

每个 Worker 的提示中都注入了强制约束：

确定性协议（强制执行）:

• 100% 确定性规则：只做你绝对确定的修改。
  任何不确定的地方，停止并报告给编排器。
• 零容忍：不留部分实现。要么完全完成，要么回滚所有更改。
• 强制验证：报告完成前在每个修改的文件上运行诊断检查。
• 禁止推测：永远不要猜测 API、类型或行为。阅读实际代码。

场景	无协议（猜测）	有协议（确定性）
API 不确定	猜测类型，留 TODO	停止并报告”需要澄清”
错误处理	跳过，留注释	完整实现或明确报告阻塞
类型错误	抑制类型检查	强制诊断，修复后提交

---

四、关键创新点详解

4.1 Brainstorm 阶段：解决上下文丢失

原来的 OpenSpec 工作流中，explore 阶段的思考和发现只存在于对话上下文中——一旦切换到 propose 阶段，这些上下文全部丢失，Agent 需要重新做一遍探索。

原来: explore 思考 ──(上下文丢失)──> propose 重新探索
融合: explore 思考 ──> brainstorm 收敛 ──(design-brief.md)──> propose 跳过探索

Brainstorm 的工作方式：

1. 收集探索阶段的上下文
2. 生成 2-3 个可选方案，让用户选择
3. 逐项审批设计维度：架构、数据流、错误处理、测试策略
4. 所有维度通过后，输出 design-brief.md 作为结构化的上下文桥梁

HARD-GATE：所有设计维度必须获得用户明确批准后才能进入 propose。这确保了人在环（human-in-the-loop）的设计审批不会被 AI 跳过。

4.2 分级验证：成本与质量的最优平衡

不是所有任务都需要昂贵的深度验证。融合方案采用分级策略：

验证层级:              成本:       适用任务:
┌──────────────────┐
│ 诊断检查 + 测试  │   FREE      所有任务（标准）
└────┬─────────────┘
     ▼ (仅关键任务)
┌──────────────────┐
│ + Momus 审查     │   MEDIUM    标记 [critical] 的任务
└────┬─────────────┘
     ▼ (仅最终)
┌──────────────────┐
│ + Oracle 验证    │   EXPENSIVE  最终 Wave 全局验证
└──────────────────┘

以一个 10 任务、3 个关键任务的变更为例：

• 全部深度验证：10 × EXPENSIVE = 高昂成本
• 无验证：0 成本，但质量风险高
• 分级验证：10 × FREE + 3 × MEDIUM + 1 × EXPENSIVE = 最优平衡

4.3 检查点续跑与 Git 集成

复杂变更可能跨越多个会话。tasks.md 本身就是检查点文件：

## Wave 1
- [x] T1: 创建数据模型       ← 已完成
- [x] T2: 添加 API 端点      ← 已完成

## Wave 2
- [ ] T3: 实现业务逻辑       ← 从这里恢复
- [ ] T4: 添加测试

恢复流程：解析 [x] 标记 → 跳过已完成 Wave → 从第一个未完成 Wave 继续。

更进一步，每个 Wave 验证通过后自动执行 scoped git commit：

git commit -m "feat(add-user-auth): complete Wave 1 (T1, T2)"

这意味着即使后续 Wave 失败，也能精确回滚到最后一个成功 Wave 的状态。

4.4 三级失败熔断

并行执行不可避免地会遇到部分失败。融合方案设计了递进式熔断机制：

级别	范围	处理
Level 1	Worker 级	单个失败 → 其他 Worker 继续 → 重试 1 次 → 仍失败标记 BLOCKED
Level 2	Wave 级	有 BLOCKED 任务 → 检查下游依赖 → 无依赖则继续，有依赖则跳过
Level 3	全局	失败任务 > 3 个 → 暂停执行 → 生成失败报告 → 人工干预

这避免了两个极端：一个任务失败就全部停止（过度保守），或者忽略失败继续执行（过度激进）。

---

五、文件冲突安全与并行上限

多个 Worker 并行修改代码库时，最危险的是两个任务修改同一个文件。融合方案在每个 Wave 分发前增加了运行时冲突检测：

Wave 分发前：
1. 收集本 Wave 所有任务的目标文件列表
2. 检测文件交集：files(Ti) ∩ files(Tj)
3. 如果有交集 → 将冲突任务移入下一 Wave
4. 并行上限：每个 Wave 最多 8 个并行任务

最坏情况是误判冲突导致任务串行化——性能退化但不影响正确性。这是一个安全优先的设计决策。

---

六、Trivial 检测：简单任务的快速通道

并非所有变更都需要完整的 DAG + 多层验证流程。对于简单修改，融合方案提供了快速通道：

任务数	策略
≤ 3 个	跳过 DAG、跳过 Momus/Oracle，串行执行 + 基础诊断检查
4-6 个	简化 Wave，Momus 限制 1 轮
> 6 个	完整 DAG 并行流程

这确保简单变更不被复杂编排拖累，同时复杂变更获得充分的并行加速和质量保障。

---

七、渐进式融合：无运行时依赖

一个重要的架构决策是：融合方案不依赖 OMO 内部运行时。所有增强能力通过提示工程（Prompt Engineering）注入到 SKILL.md 文件中。

┌─────────────────────────────────────────┐
│         SKILL.md (纯文本提示)           │
├─────────────────────────────────────────┤
│  确定性协议 → 注入 Worker 提示          │
│  DAG Wave 执行 → 指令中描述             │
│  质量门控 → task() 调用模式             │
│  并行编排 → run_in_background=true      │
│                                         │
│  无导入，无依赖，纯提示工程              │
└─────────────────────────────────────────┘

这意味着：

• 可移植：SKILL.md 文件即全部，拷贝到任何项目即可使用
• 可维护：更新通过编辑文本文件，无需重新编译
• 可审计：所有行为在提示中透明可见
• 可降级：Legacy tasks.md 自动识别并降级到顺序执行

---

八、架构决策记录

为什么只用 Skills，不用 Commands？

OMO 中 Skills 和 Commands 共享统一命名空间，Skills 自动注册为斜杠命令且优先级更高。经测试发现，Commands 和 Skills 是两个独立注册表——通过 Command 入口调用时，SKILL.md 中的多智能体增强完全不生效。

因此我们做了一个决定：删除所有 Commands，仅保留 Skills 作为唯一入口。单一事实源，零额外跳转，零维护负担。

为什么精简 SKILL.md 中的 task() 代码块？

原方案中 5 个 SKILL.md 包含 22 处 task() 调用示例。当 Worker 通过 load_skills 加载完整 SKILL.md 时，这些编排指令可能误导 depth=1 的 Worker 尝试递归调用。精简后仅保留 1 处（Worker dispatch prompt 中的确定性协议注入），将递归风险和 context 消耗同时降低。

---

九、已知风险与应对

任何方案都不是完美的。以下是我们识别到的主要风险和对应的缓解策略：

风险	描述	缓解
DAG 解析依赖 LLM	拓扑排序由 LLM 理解执行，复杂 DAG 可能出错	限制每变更 ≤ 8-10 任务；Wave 前校验前置任务完成状态
Brainstorm 禁止 TodoWrite	系统级 Hook 可能覆盖 Skill 级约束	强化措辞 + 未来支持 Skill 级 Hook opt-out
Momus 无限循环	反复 REDO 导致成本爆炸	每阶段 max 2 次重试，超限降级为人工审查
Worker 递归调用	加载完整 SKILL.md 可能误导 Worker	已精简 task() 代码块；Worker 建议 load_skills=[]

---

十、效果总结

OMO-OPSX 的融合在保持”流动而非僵化”哲学的前提下，实现了 15 项核心增强：

1. 并行加速：Wave 执行 + 并行探索 + 并行制品生成
2. 质量保障：三层门控（Metis → Momus → Oracle）
3. 确定性执行：UltraWork 协议，100% 确定性，零容忍推测
4. 断点续跑：tasks.md 检查点 + Wave 级 git commit
5. 渐进式融合：无运行时依赖，纯提示工程
6. 保持灵活：探索自由形式，智能体作为可选工具
7. 分级验证：成本与质量的最优平衡
8. 可降级：Legacy 格式自动兼容
9. TDD 纪律：RED-GREEN-REFACTOR 强制协议
10. 设计收敛：brainstorm 阶段产出经审批的 design-brief
11. 两阶段审查：关键任务分规范合规和代码质量
12. 成本可控：重试上限 + Trivial 短路
13. 三级熔断：Worker → Wave → Global 递进式失败处理
14. 并行安全：文件冲突检测 + max 8 并行上限
15. 精简高效：移除冗余代码块，降低 Worker 递归风险

---

写在最后

AI 编码正在从”单兵作战”走向”团队协作”——只不过团队成员是一群专业化的智能体。

OMO-OPSX 的实践给了我们一个重要启示：AI 编码的质量问题，本质上是工程问题，而不是模型能力问题。 同一个模型，在缺乏结构化约束时会产生半成品和猜测；在确定性协议和分层验证的约束下，则能交付高质量的确定性输出。

这让我想到制造业的演进：从手工作坊到流水线，核心突破不是工人更能干了，而是生产流程被重新设计了。SDD + 多智能体编排，也许正是 AI 编码领域的那条”流水线”。

未来的方向可能包括：

• 将 DAG 解析从 LLM 理解移入程序化工具（如 openspec compute-waves --json）
• Skill 级别的 Hook opt-out 机制
• 跨项目的知识复利——让一个项目中沉淀的规范和经验自动迁移到下一个项目

但这些都是后话了。当下最重要的是：先让 AI 不猜测，先让质量有门控，先让并行能安全。 其余的，交给时间。

---

参考资料

1. OpenSpec - Specification-Driven Development Framework
2. Oh-My-OpenAgent (OMO) - Multi-Agent Orchestration
3. Atlassian AI Adoption Metrics - 89% PR/engineer increase
4. Microsoft Research - Intent Formalization
5. Compound Engineering: From Vibe Coding to System Orchestration
6. Multi-Agent Orchestration Practical Guide
7. Agentic Engineering Complete Guide 2026
8. Spec驱动的研发复利：AI 时代的组织级工程体系探索 - 网易KM, 青檀(高民)
9. Building a Multi-Agent Orchestrator

---

本文基于 OMO-OPSX v2.2 方案设计文档撰写，方案已在实际项目中部署并持续优化。