Oh My OpenCode实战指南：打造你的AgentTeam

关注公众号【寒江瞭望】获取更多内容。资深架构师，AI赛道的躬身入局者，研究AI生产力工具，同时也追踪产业趋势和景气度。这个公众号记录我的双重观察:作为从业者，关注AI如何真正提高了生产力；作为投资者，关注哪些产业趋势正在形成。

[!tip] 核心理念
Oh My OpenCode 是一个多模型智能体编排系统，将单一AI助手转变为真正的协作开发团队。不锁定Claude，不锁定OpenAI，只追求更好的结果、更低的成本、真正的编排。

📋 目录

• 架构概览
• 智能体角色与模型匹配
• 编排系统详解
• 工作模式实战
• 配置与最佳实践

🏗️ 架构概览

核心哲学：打破锁定

Oh My OpenCode 不是"Claude Code增强版"，而是要打破单一模型、单一供应商的桎梏：

Anthropic想锁定你，OpenAI想锁定你。Oh My OpenCode不玩这个游戏。

核心优势：

• 多模型编排 - Claude做编排，GPT做深度推理，Gemini做前端，Haiku做快速任务
• 并行执行 - 同时启动5+个智能体，研究、实现、验证同步进行
• 意图门控 - 先理解你真正想要什么，再路由到合适的智能体
• 哈希锚定编辑 - LINE#ID内容哈希验证，Grok Code Fast 1成功率从6.7%提升到68.3%
• 技能嵌入MCP - 每个技能自带MCP服务器，上下文窗口保持清爽

数字化开发团队三层架构

┌─────────────────────────────────────────────────────────┐
│  Planning Layer (规划层)                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │Prometheus│  │  Metis   │  │  Momus   │              │
│  │  战略规划 │  │  顾问    │  │  审查者  │              │
│  └──────────┘  └──────────┘  └──────────┘              │
└─────────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────────┐
│  Execution Layer (执行层)                                │
│  ┌──────────┐                                            │
│  │  Atlas   │  ← 指挥官，不写代码，只做协调               │
│  │  指挥官  │                                            │
│  └──────────┘                                            │
└─────────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────────┐
│  Worker Layer (工作者层)                                 │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│  │Sisyphus  │ │  Oracle  │ │ Explore  │ │Librarian │  │
│  │ -Junior  │ │ 架构师   │ │ 代码搜索 │ │ 文档搜索 │  │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘  │
│  ┌──────────┐ ┌──────────┐                            │
│  │ Frontend │ │Hephaestus│                            │
│  │ UI专家   │ │ 深度工匠 │                            │
│  └──────────┘ └──────────┘                            │
└─────────────────────────────────────────────────────────┘

工作流程

用户请求
   ↓
[意图门控] — 分类你真正想要什么
   ↓
[Sisyphus] — 主编排器，规划和委派
   ↓
   ├─→ [Prometheus] — 战略规划（面试模式）
   ├─→ [Atlas] — Todo编排和执行
   ├─→ [Oracle] — 架构咨询
   ├─→ [Librarian] — 文档/代码搜索
   ├─→ [Explore] — 快速代码库grep
   └─→ [基于类别的智能体] — 按任务类型专业化

🤖 智能体角色与模型匹配

模型家族分类

[!important] 理解模型行为差异
不同模型有不同的"性格"和指令遵循方式。了解哪些模型"相似"有助于做出安全替换。

Claude类模型（指令遵循、结构化输出）

这些模型响应类似Claude，与oh-my-opencode的Claude优化提示词配合良好：

GPT模型（显式推理、原则驱动）

GPT模型需要不同结构的提示词。某些智能体会自动检测GPT并切换提示：

不同行为模型

这些模型有独特特性 — 不要假设它们表现得像Claude或GPT：

智能体体系介绍

Sisyphus：纪律之使

以西西弗斯命名。每天推石头上山。从不停止。从不放弃。

角色定位：主编排器。规划、委派给专家、通过激进并行执行推动任务完成。不会中途停下。不会分心。完成任务。

推荐模型：

Sisyphus:
  - Claude Opus 4.6      # 最佳
  - Kimi K2.5            # Claude类替代
  - GLM 5                # 可选项

[!warning] 关键限制
Sisyphus是Claude优化智能体。没有GPT提示词存在。不要用GPT替换，性能会严重下降。

Prometheus：战略规划师

像真正的工程师一样面试你。提出澄清问题。识别范围和歧义。在写一行代码之前构建详细计划。

触发方式：

1. 按Tab进入Prometheus模式
2. 从Sisyphus输入@plan "你的任务"

面试流程：

描述工作 → 采访研究 → 启动explore/librarian → 收集上下文
   ↓
要求检查
   ↓
核心目标定义？ → 否 → 回到采访
范围边界确立？ → 是
关键技术决策？
测试策略确认？
   ↓
计划生成 → Metis咨询（必须） → 写计划 → 用户确认
   ↓
用户想要高准确度？ → 是 → Momus循环验证
                      → 否 → 完成

意图特定策略：

Atlas：指挥官

执行Prometheus计划。将任务分发给专业子智能体。跨任务积累学习。独立验证完成。

指挥官心态：Atlas不演奏乐器，它确保完美和声。

能做的事：

• 读取文件理解上下文
• 运行命令验证结果
• 使用lsp_diagnostics检查错误
• 用grep/glob/ast-grep搜索模式

必须委派的事：

• 写或编辑代码文件
• 修复bug
• 创建测试
• Git提交

智慧积累机制：

.sisyphus/notepads/{plan-name}/
├── learnings.md      # 模式、约定、成功方法
├── decisions.md      # 架构选择和理由
├── issues.md         # 问题、阻塞、坑
├── verification.md   # 测试结果、验证结果
└── problems.md       # 未解决问题、技术债

每个任务后提取学习，分类传递给所有后续子智能体。防止重复错误。

Hephaestus：合法工匠

有意反讽的命名。Anthropic因为这个项目阻止OpenCode使用他们的API。团队反而构建了一个自主GPT原生智能体。

运行模型：GPT-5.3 Codex (medium)

使用场景：

1. 需要深度架构推理

   • "设计新插件系统"
   • "将单体重构为微服务"

2. 需要复杂调试的推理链

   • "为什么这个竞态只在周二发生？"
   • "通过15个文件追踪内存泄漏"

3. 跨领域知识综合

   • "将Rust核心与TypeScript前端集成"
   • "零停机MongoDB到PostgreSQL迁移"

4. 你特别想要GPT-5.3 Codex推理

Oracle：顾问

只读高智商顾问，用于架构决策和复杂调试。咨询Oracle当面对不熟悉模式、安全关注或多系统权衡。

辅助角色

类别+技能系统

为什么类别是革命性的

问题：模型名称创造分布偏差

// 旧方式：模型名称
task(agent="gpt-5.2", prompt="...")  // 模型知道自己的局限
task(agent="claude-opus-4.6", prompt="...")  // 不同自我认知

解决方案：语义类别

// 新方式：类别描述意图，非实现
task(category="ultrabrain", prompt="...")     // "战略思考"
task(category="visual-engineering", prompt="...")  // "设计美丽"
task(category="quick", prompt="...")          // "快速完成"

内置类别

安全vs危险覆盖

[!danger] 警告

某些覆盖会严重破坏智能体性能

安全的覆盖（同家族）：

• Sisyphus: Opus → Sonnet, Kimi K2.5, GLM 5
• Prometheus: Opus → GPT-5.2 (自动切换提示词)
• Atlas: Kimi K2.5 → Sonnet, GPT-5.2 (自动切换)

危险的覆盖（无提示词支持）：

• ❌ Sisyphus → GPT: 无GPT提示词，性能严重下降
• ❌ Hephaestus → Claude: 为Codex构建，Claude无法复制
• ❌ Explore → Opus: 巨大成本浪费。Explore需要速度，不需要智能
• ❌ Librarian → Opus: 同样。文档搜索不需要Opus级推理

🎼 编排系统详解

何时使用什么

决策流程：

是快速修复或简单任务？
  └─ 是 → 正常提示
  └─ 否 → 解释完整上下文很烦？
              └─ 是 → 输入"ulw"让智能体搞定
              └─ 否 → 需要精确可验证的执行？
                         └─ 是 → 用@plan给Prometheus规划，然后/start-work
                         └─ 否 → 就用"ulw"

规划层：Prometheus + Metis + Momus

Metis：缺口分析员

Prometheus写计划前，Metis抓住Prometheus漏掉的：

• 用户请求中的隐藏意图
• 可能破坏实施的歧义
• AI-slop模式（过度工程、范围蔓延）
• 缺失的验收标准
• 未处理的边界情况

为什么Metis存在：
计划作者（Prometheus）有"ADHD工作记忆" - 它建立连接但从未写下来。Metis强制外化隐含知识。

Momus：无情审查员

对于高准确度模式，Momus根据四个核心标准验证计划：

1. 清晰度：每个任务是否指定在哪里找到实现细节？
2. 验证：验收标准是否具体可测量？
3. 上下文：是否有足够上下文继续进行而无需>10%猜测？
4. 大局：目的、背景和工作流程是否清晰？

Momus循环：
Momus只在以下时说"OKAY"：

• 100%文件引用已验证
• ≥80%任务有明确参考来源
• ≥90%任务有具体验收标准
• 零任务需要假设业务逻辑
• 零关键危险信号

如果REJECTED，Prometheus修复问题并重新提交。无最大重试限制。

执行层：Atlas指挥官

工作流程

1. 读取计划
   ↓
2. 分析任务
   ↓
3. 积累智慧
   ↓
4. 委派任务 → 工作者
   ↓          ↘ 结果+学习
5. 验证结果 ←────────┘
   ↓
6. 最终报告

工作者层：Sisyphus-Junior和专家

Sisyphus-Junior：任务执行器

Junior是真正写代码的主力。关键特性：

• 专注：不能委派（blocked from task tool）
• 纪律：强迫性todo跟踪
• 验证：完成前必须通过lsp_diagnostics
• 约束：不能修改计划文件（READ-ONLY）

为什么Sonnet足够：
Junior不需要最聪明 - 需要可靠。有：

1. Atlas的详细提示（50-200行）
2. 传递的积累智慧
3. 清晰的必须做/绝不做约束
4. 验证要求

即使中等模型也能精确执行。智能在系统中，不在单个智能体中。

系统提醒机制

钩子系统确保Junior从不会中途停止：

[SYSTEM REMINDER - TODO CONTINUATION]

你有未完成的todo！完成所有后再响应：
- [ ] 实现用户服务 ← 进行中
- [ ] 添加验证
- [ ] 编写测试

在所有todo标记完成前不要响应。

这个"推石头"机制是系统以Sisyphus命名的原因。

🚀 工作模式实战

Ultrawork模式：懒惰模式

输入ultrawork或就ulw。就这样。

智能体自己搞定一切 - 探索代码库、研究模式、实现功能、用诊断验证。持续工作直到完成。

这是"就去做"模式。全自动。你不需要深度思考，因为智能体替你深度思考。

使用场景：

1. 你想让智能体自己搞清楚

   • ulw 修复失败的测试
   • ulw 给API添加输入验证

2. 复杂但范围明确的任务

   • ulw 按照我们的模式实现JWT认证
   • ulw 创建新的部署CLI命令

3. 你感到懒惰（官方支持的使用案例）

   • 不想写详细需求
   • 信任智能体探索和决策

4. 你想利用现有计划

   • 如果存在Prometheus计划，ulw模式可以使用
   • 没有计划则回退到自主探索

Prometheus模式：精确模式

按Tab进入Prometheus模式。

Prometheus像真正的工程师一样面试你。提出澄清问题。识别范围和歧义。在写一行代码之前构建详细计划。

然后运行/start-work，Atlas接管。任务分发到专业子智能体。每个完成独立验证。学习跨任务积累。进度跨会话跟踪。

使用场景：

• 多天项目
• 关键生产更改
• 复杂重构
• 想要文档化的决策轨迹

Hephaestus vs Sisyphus + ultrawork

推荐：

• 大多数用户：在Sisyphus中使用ulw关键词。这是默认路径，对90%复杂任务效果出色。
• 高级用户：特别需要GPT-5.3 Codex推理风格或想要完全自主探索和执行的"AmpCode深度模式"体验时切换到Hephaestus。

/start-work行为与会话连续性

运行/start-work时发生什么：

User: /start-work
    ↓
[start-work hook激活]
    ↓
检查：.sisyphus/boulder.json存在吗？
    ↓
    ├─ 是（现有工作）→ 恢复模式
    │   - 读取现有boulder状态
    │   - 计算进度（已检查 vs 未检查复选框）
    │   - 注入剩余任务的继续提示
    │   - Atlas从你离开的地方继续
    │
    └─ 否（全新开始）→ 初始化模式
        - 找.sisyphus/plans/中最新的计划
        - 创建新boulder.json跟踪此计划
        - 切换会话智能体到Atlas
        - 从任务1开始执行

会话连续性示例：

周一上午9:00
  └─ @plan "构建用户认证"
  └─ Prometheus采访并创建计划
  └─ User: /start-work
  └─ Atlas开始执行，创建boulder.json
  └─ 任务1完成，任务2进行中...
  └─ [会话结束 - 电脑崩溃，用户登出等]

周一下午2:00（新会话）
  └─ 用户打开新会话（默认智能体=Sisyphus）
  └─ User: /start-work
  └─ [start-work hook读取boulder.json]
  └─ "恢复'构建用户认证' - 8个任务中完成3个"
  └─ Atlas从任务3继续（无上下文丢失）

运行/start-work时自动激活Atlas。你不需要手动切换到Atlas。

boulder.json跟踪：

• active_plan: 当前计划文件路径
• session_ids: 所有在此计划上工作的会话
• started_at: 工作何时开始
• plan_name: 人类可读的计划标识符

⚙️ 配置与最佳实践

提供商优先级

Native (anthropic/, openai/, google/) > Kimi for Coding > GitHub Copilot > Venice > OpenCode Zen > Z.ai Coding Plan

自定义配置

在oh-my-opencode.json中覆盖：

{
  "agents": {
    "sisyphus": {
      "model": "claude-opus-4.6",
      "provider": "anthropic",
      "temperature": 0.1,
      "fallback_chain": [
        {"model": "kimi-k2-5", "provider": "kimi-for-coding"},
        {"model": "glm-5", "provider": "zai-coding-plan"}
      ]
    }
  },
  "categories": {
    "visual-engineering": {
      "model": "gemini-3-pro",
      "provider": "google"
    },
    "ultrabrain": {
      "model": "gpt-5.3-codex",
      "provider": "openai"
    }
  }
}

选择优先级

Claude优化智能体选择模型时：

Claude (Opus/Sonnet) > GPT (如果智能体有双重提示) > Claude类 (Kimi K2.5, GLM 5)

GPT原生智能体选择模型时：

GPT (5.3-codex, 5.2) > Claude Opus (不错回退) > Gemini (可接受)

最佳实践总结

1. 简单任务：直接提示，不使用智能体
2. 复杂但懒：ulw让Sisyphus自主处理
3. 复杂且精确：@plan → Prometheus规划 → /start-work → Atlas执行
4. 深度架构：切换到Hephaestus
5. 前端/视觉：使用visual-engineering类别自动路由到Gemini
6. 快速搜索：Explore和Librarian自动使用快速模型

故障排除

"我切换到Prometheus但什么都没发生"

Prometheus默认进入面试模式。它会问你关于需求的问题。回答它们，准备好时说"make it a plan"。

"/start-work说'找不到活动计划'"

要么：

• .sisyphus/plans/中不存在计划 → 先用Prometheus创建一个
• 计划存在但boulder.json指向别处 → 删除.sisyphus/boulder.json并重试

"我在Atlas但想切换回正常模式"

输入exit或开始新会话。Atlas主要通过/start-work进入 - 你通常不手动"切换到Atlas"。

"@plan和直接切换到Prometheus有什么区别？"

功能上没有区别。 都调用Prometheus。@plan是便利命令，切换智能体是显式控制。用哪个感觉自然就用哪个。

"应该用Hephaestus还是输入ulw？"

大多数任务：在Sisyphus中输入ulw。

用Hephaestus当：你特别需要GPT-5.3 Codex推理风格进行深度架构工作或复杂调试。

💡 核心要点

[!success] 记住这些

1. 智能体专业化 - 不同智能体做不同的事，协作而非单打独斗
2. 类别优先于模型名 - 描述意图，让系统路由到最佳模型
3. 规划与执行分离 - Prometheus规划，Atlas执行，工作者写代码
4. 智慧积累 - 学习传递，错误不重复
5. 会话连续 - boulder.json跟踪进度，随时恢复
6. 多模型协作 - Claude、GPT、Gemini各司其职

准备好开始了吗？ 试试看看指挥一个强大的AI Agent团队可以为你做什么？