模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第10章 — Oh-My-OpenCode的创新
Token用量: 约 4,200 input + 1,150 output

10.1 三层编排架构

Oh-My-OpenCode 最核心的创新，不是某一个 agent，也不是某一个 hook，而是它把编码工作组织成了一套三层编排架构。换句话说，它不把“写代码”理解为一个模型在长上下文里完成的单线程独白，而是把它理解为一个小型工程组织中的分层协作：先规划，再调度，再执行。

graph TB
    subgraph "第1层：规划层"
        P["Prometheus<br/>📝 计划生成器"] 
        Met["Metis<br/>🔍 预分析器"]
        Mom["Momus<br/>✅ 计划审查者"]
        Met -->|"隐藏意图"| P
        P -->|"计划草案"| Mom
        Mom -->|"批准后的计划"| Atlas
    end
    
    subgraph "第2层：执行层"
        Atlas["Atlas<br/>🎯 调度者"]
    end
    
    subgraph "第3层：工作层"
        Atlas -->|"视觉任务"| SJ["Sisyphus-Junior<br/>⚡ 任务执行者"]
        Atlas -->|"深度问题"| Hep["Hephaestus<br/>🔨 深度工作者"]
        Atlas -->|"需要建议"| Ora["Oracle<br/>👁️ 只读顾问"]
        Atlas -->|"搜索外部"| Lib["Librarian<br/>📚 外部检索"]
        Atlas -->|"搜索代码库"| Exp["Explore<br/>🔎 快速搜索"]
    end
    
    Atlas -.->|"📓 经验沉淀"| NB["笔记本系统<br/>经验 / 决策 / 问题"]
    NB -.->|"注入给所有人"| SJ
    NB -.->|"注入给所有人"| Hep
    
    style Atlas fill:#ff6b6b,color:#fff
    style P fill:#4a9eff,color:#fff
    style Ora fill:#ffd43b,color:#000

第一层是规划层，核心角色是 Prometheus、Metis、Momus。Prometheus 的作用不是简单生成一个 markdown 计划，而是先像顾问一样“访谈用户”。它通过提问、澄清目标、锁定边界，把含糊请求整理成更清晰的任务定义。这个设计非常重要，因为大量 agent 失败并不是代码能力不够，而是在一开始就误解了真实需求。Prometheus 要解决的正是“问题定义错误”这一前置失败点。

但 OMO 并不完全相信单一规划器。Prometheus 在落计划之前，Metis 会先做一轮预分析。Metis 的职责是找隐藏意图、未说出口的约束、缺失的验收标准、模糊边界，以及 AI 容易忽略的前提假设。用更标准的 CS 语言说，它相当于在“提交计划之前”插入了一个专门的风险分析阶段。也就是说，系统不是假设“第一次想到的计划就够好”，而是先问一句：这个计划漏了什么？

接着是 Momus，即计划批评者。在高准确模式下，Prometheus 不是把计划写完就算，而是必须反复提交给 Momus 审核，直到 Momus 返回通过信号，通常就是字面量的 “OKAY”。这一点非常关键。很多 agent 系统也会在 prompt 里说“请自我检查”，但 OMO 让批评者真正成为一道关卡。只要 Momus 不通过，计划就不能被视为完成。这意味着计划质量不再只是软约束，而是一个带重试闭环的硬约束。

第二层是执行层，核心角色是 Atlas。如果说规划层负责回答“做什么”，那么 Atlas 负责回答“怎么做、谁来做、做到什么程度才算完成”。Atlas 会把计划拆解成可执行单元，识别哪些任务可以并行，把子任务分发给合适的专业 agent，回收结果，做验证，并通过 notepad 机制维护阶段性知识。若用分布式系统的比喻，Atlas 很像调度器加验证器；若用团队组织的比喻，它更像项目经理兼技术负责人。

Atlas 的价值在于弥合“计划”与“落地执行”之间的断层。计划写得好，并不意味着执行一定好。任务是否切得合理，是否分配给正确的人，是否存在并发机会，是否真正验证过结果，这些都不是计划文件本身能自动保证的。Atlas 正是在做这件事：把一张静态计划，变成一个动态执行流程。

第三层是工作者层。这里是实际干活的专业 agent 集合。用户在任务里特别点名的几个角色恰好最能体现 OMO 的设计思想。Sisyphus-Junior 通常绑定 Sonnet 4.5 一类模型，定位是“聚焦执行者”，负责清晰、边界明确的子任务，不承担复杂调度。Oracle 常映射到 GPT-5.2 这类高推理模型，但被严格限定为只读顾问，用于架构评审、调试分析、复杂判断。Librarian 偏外部知识和资料检索，常走 GLM-4.7 路线。Explore 是代码库搜索专员，强调快速 repo 勘探。Hephaestus 则偏向 GPT-5.3 Codex 一类深度工作模型，负责高复杂度、强自主的工程任务。

实际上，OMO 的 roster 不止这些。更完整地看，它包含 Sisyphus、Prometheus、Metis、Momus、Atlas、Oracle、Librarian、Explore、Hephaestus、Multimodal-Looker，以及按 category 生成的 Sisyphus-Junior 变体，整体可以视作一个约 11 个专业角色组成的 agent 体系。这里真正值得注意的不是“数量”，而是角色隔离：规划者负责规划，批评者负责挑错，调度者负责编排，工作者负责执行。

这使得 OMO 与多数单智能体系统有了本质差异。传统系统更像一个“全能型个人”，在同一上下文里交替做需求理解、代码搜索、实现、总结。OMO 则更像一个“有分工的组织”。这样做至少有四个好处。

第一，减少角色冲突。保守的规划行为不必和激进的执行行为挤在同一个 prompt 身份里。第二，支持模型专门化。不同角色可以走不同 fallback chain、不同推理强度。第三，支持并行性。Atlas 可以同时派出多个 worker，而不必把所有步骤塞进一条顺序推理链。第四，增强可归因性。如果任务失败，可以分析是理解错、规划错、执行错，还是验证错。

从方法论上看，这套三层结构其实把经典软件工程中的若干阶段压缩进了 agent runtime：需求澄清、方案评审、执行拆解、实现、QA。也正因为如此，它不是“多几个 agent”这么简单，而是在回答一个更大的问题：复杂编码任务应该如何组织？

OMO 给出的答案是：不要让一个模型扮演所有人，而要让系统像一个组织一样运作。这就是三层编排架构真正的创新性所在。