主题
第六章 OmO Agent 体系
← 返回目录 | 上一章：OmO 插件架构 | 下一章：OmO 后台任务系统 →
6.1 设计哲学：从"一人干所有"到"专人专事"
Opencode 原生的 Agent 模型是通才型——build Agent 什么都做，general 子 Agent 也什么都做。这种设计在简单任务上足够好，但在复杂项目中有明显缺陷：
- 一个 Agent 既要规划又要执行，容易在执行中偏离计划
- 没有"第二双眼睛"来审查决策
- 所有任务使用同一个模型，不能按需选择性价比最优的模型
OmO 的解决方案是构建一个分工明确的 Agent 团队，每个 Agent 有：
- 明确的职责边界
- 专属的 LLM 模型（按任务特性选择最优模型）
- 受限的工具权限（最小权限原则）
- 定制的系统提示词（领域专家级指令）
6.2 完整 Agent 清单
第一梯队：主编排层
| Agent | 模型 | 模式 | 角色定位 |
|---|---|---|---|
| Sisyphus | claude-opus-4-6 (max reasoning) | all | 主编排器——接收用户请求，分析意图，分派任务，验证结果 |
| Atlas | claude-sonnet-4-6 | primary | Todo 编排器——在 Sisyphus 不可用时管理任务续航 |
Sisyphus（西西弗斯）是整个系统的"大脑"。它的名字来源于希腊神话——每天推石上山的人。寓意是：AI Agent 每天也在重复执行任务，但和人类一样，这并不使工作没有价值。
Sisyphus 的核心行为模式：
- 意图识别：收到用户请求后，先分类（研究/实现/调查/评估/修复/开放式）
- 路由决策：根据意图类型选择直接执行、委派子 Agent、还是先探索
- 并行调度：将独立的探索任务同时发给多个子 Agent
- 结果验证：子 Agent 完成后，检查结果是否符合预期
- 质量保证：运行 LSP 诊断、构建命令、测试来验证代码变更
第二梯队：执行层
| Agent | 模型 | 模式 | 角色定位 |
|---|---|---|---|
| Sisyphus-Junior | claude-sonnet-4-6 | all | 分类执行器——根据 category 承接具体开发任务 |
| Hephaestus | gpt-5.4 (medium reasoning) | all | 深度自主工作者——处理需要深入研究后实现的复杂任务 |
Sisyphus-Junior 是 Category 系统的执行者。当 Sisyphus 委派一个带有 category 的任务时，Junior 作为后台子 Agent 使用该 category 对应的模型和 Skill 来执行。
Hephaestus（赫菲斯托斯，希腊锻造之神）专门处理需要自主研究+端到端实现的"硬活"。它的特点是：先充分理解问题，再动手实现。
第三梯队：顾问层（只读）
| Agent | 模型 | 模式 | 角色定位 |
|---|---|---|---|
| Oracle | gpt-5.4 (high reasoning) | subagent | 架构顾问——只读、高成本、高质量的推理模型，用于复杂架构决策和深度调试 |
| Metis | claude-opus-4-6 (max reasoning) | subagent | 预规划顾问——分析任务需求，识别隐藏意图、歧义和 AI 失败点 |
| Momus | gpt-5.4 (xhigh reasoning) | subagent | 计划审查员——以严格标准评估工作计划的清晰度、可验证性和完整性 |
Oracle 是系统中最"贵"的 Agent，使用最高推理能力的模型。它只在以下场景被调用：
- 复杂架构设计需要权衡多系统的 tradeoff
- 修 Bug 失败两次以上
- 安全/性能方面的关键决策
Metis 和 Momus 形成了一个"计划审查流水线"：
用户需求 → Metis（分析需求、找漏洞）→ Prometheus（制定计划）→ Momus（审查计划质量）→ 执行第四梯队：侦察层
| Agent | 模型 | 模式 | 角色定位 |
|---|---|---|---|
| Explore | grok-code-fast-1 | subagent | 代码库搜索——快速、廉价的内部代码搜索 |
| Librarian | minimax-m2.7 | subagent | 外部文档搜索——查询官方文档、OSS 实现、最佳实践 |
| Multimodal-Looker | gpt-5.3-codex | subagent | 多模态分析——PDF/图片/截图内容提取 |
Explore 和 Librarian 是 Sisyphus 最常用的"侦察兵"。它们的设计理念是"grep 而非顾问"——快速搜索、返回原始结果，不做过多解读。Sisyphus 在分析用户请求时，通常会同时发射 2-5 个 Explore/Librarian 后台任务，并行搜索不同维度的信息。
第五梯队：内部特殊用途
| Agent | 模型 | 用途 |
|---|---|---|
| Prometheus | claude-opus-4-6 (max) | 战略规划器——生成详细的工作计划文件 |
Prometheus（普罗米修斯）不直接与用户交互，而是一个内部规划引擎。它生成的计划文件保存到 .sisyphus/plans/ 目录，然后由 Momus 审查，最终由 Sisyphus 或 Junior 执行。
6.3 模型选择策略
OmO 的模型分配体现了成本-质量平衡：
高成本 / 高质量 低成本 / 高速度
◄─────────────────────────────────►
Oracle (gpt-5.4 xhigh)
Momus (gpt-5.4 xhigh)
Sisyphus (opus max)
Prometheus (opus max)
Metis (opus max)
Hephaestus (gpt-5.4 medium)
Junior (sonnet-4-6)
Atlas (sonnet-4-6)
Multimodal-Looker (gpt-5.3-codex)
Librarian (minimax-m2.7)
Explore (grok-code-fast-1) ← 最便宜、最快这个分配逻辑是：
- 搜索类任务（Explore、Librarian）使用最便宜的模型，因为它们本质上是"智能 grep"
- 执行类任务（Junior、Hephaestus）使用中等模型，需要足够的代码生成能力
- 决策类任务（Oracle、Momus、Metis）使用最贵的模型，因为决策错误的代价远高于执行错误