8.1 什麼是 Oh My OpenAgent?

Oh My OpenAgent(簡稱 OmO,套件名稱 oh-my-opencode)是一個強大的 OpenCode 外掛程式,將原本的單一 AI 代理轉變為多模型多代理協同引擎。

可以這樣理解:如果 OpenCode 原本是一個全能工程師,OmO 就是將他升級為一整間公司的開發團隊 — 有專案經理、架構師、研究員、品管工程師⋯⋯各司其職,協同完成任務。

🌟 OmO 的核心能力
  • 多模型支援:同時使用 Claude、GPT、Gemini 等多個模型
  • 專業代理團隊:10 個各具專長的子代理協同工作
  • 智能分類路由:根據任務性質自動選擇最合適的代理組合
  • 背景並行:多個代理可同時在背景執行,大幅縮短等待時間
  • 深度工作模式:Ultrawork 模式實現長時間、高品質的自主開發

8.2 安裝指南

OmO 提供兩種安裝方式,你可以根據偏好選擇:

方法 A:AI 輔助安裝(推薦)

在 OpenCode 中直接貼上以下指令,讓 AI 代理幫你完成安裝:

$
> 安裝並設定 oh-my-opencode,請按照以下指示操作:
> https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md
🔍 正在讀取安裝指南...
📦 偵測到 Bun,使用 bun 進行安裝
✅ 安裝中...
◉ 正在安裝 oh-my-opencode...
◉ 正在下載代理設定檔...
◉ 正在設定分類路由...
✅ Oh My OpenAgent 安裝完成!
▶ 執行 'omo doctor' 驗證安裝狀態

方法 B:手動安裝

在終端機中直接執行以下指令:

# 使用 bun(建議)
bunx oh-my-opencode install

# 或使用 npx
npx oh-my-opencode install

進階:自訂訂閱選項

安裝時可以指定要啟用的 AI 服務:

# 啟用 Claude(最多 20 個 API key)
bunx oh-my-opencode install --claude=max20

# 啟用 Claude + OpenAI
bunx oh-my-opencode install --claude=yes --openai=yes

# 啟用所有支援的服務
bunx oh-my-opencode install --claude=yes --openai=yes --gemini=yes --copilot=yes
選項 值 說明
--claude yes / no / max20 啟用 Anthropic Claude(max20 = 最多 20 個 API key)
--openai yes / no 啟用 OpenAI GPT 系列模型
--gemini yes / no 啟用 Google Gemini 模型
--copilot yes / no 啟用 GitHub Copilot 模型

驗證安裝

安裝完成後,執行診斷指令確認一切正常:

$ bunx oh-my-opencode doctor
🔍 Oh My OpenAgent 診斷報告
────────────────────────
✅ OpenCode 狀態:已安裝
✅ oh-my-opencode 版本:v1.2.0
✅ 代理設定:已載入(10 個代理)
◉ Claude API:已設定(3 個金鑰)
◉ OpenAI API:已設定
◉ Gemini API:已設定
◉ 分類路由:已啟用
────────────────────────
✅ 所有系統正常運作!

8.3 設定檔結構

OmO 的設定分散在兩個層級的設定檔中:

層級 路徑 說明
使用者全域 ~/.config/opencode/oh-my-openagent.jsonc 跨專案的全域設定,如 API 金鑰、預設模型
專案層級 .opencode/oh-my-openagent.jsonc 專案特定的代理設定與路由規則

設定檔使用 JSONC 格式(支援註解的 JSON),讓設定更具可讀性:

// .opencode/oh-my-openagent.jsonc
{
  // 預設模型設定
  "defaultModel": "gpt-4o",

  // 代理團隊設定
  "agents": {
    "sisyphus": {
      "model": "gpt-4o",
      "temperature": 0.3
    },
    "oracle": {
      "model": "claude-opus-4",
      "temperature": 0.2
    }
  },

  // 分類路由
  "routing": {
    "visual-engineering": ["sisyphus", "hephaestus"],
    "ultrabrain": ["oracle", "metis"],
    "quick": ["explore", "librarian"]
  }
}

8.4 代理團隊(The Agent Team)

OmO 最引人注目的特色就是它的代理團隊。每個代理都有明確的角色定位與專長領域,共同構成一個完整的 AI 開發組織:

代理 角色 核心職責 適合任務 對應真實團隊角色
Sisyphus 主編排器 解析使用者意圖、分派任務給合適代理、獨立驗證結果、全流程生命週期管理 複雜多步驟任務、需要跨代理協作的場景 Tech Lead / 專案經理
Prometheus 規劃師 面試式需求收集、結構化規劃、產生可執行的執行計畫、提供多種實作方案 新功能開發、大型重構的預先規劃 產品經理 / 解決方案架構師
Hephaestus 深度執行者 啟動並行探索、深度架構推理、高品質實作、處理依賴鏈與邊界情況 需深度技術判斷的實作任務 資深工程師
Oracle 架構顧問 高難度技術決策、跨領域知識綜合(唯讀)、提供權威技術建議 架構審查、技術方案評估、疑難排解 首席架構師 / 技術顧問
Librarian 文獻研究員 搜尋 GitHub 範例、查閱官方文件、整理技術參考、比對不同實作方式 需要外部參考資料的任務 技術研究員
Explore 程式碼偵察兵 超高速 grep 搜尋、常駐背景分析、程式碼庫導覽、檔案結構梳理 大型程式碼庫中的搜尋與分析 程式碼審計員
Metis 計畫顧問 辨識模糊意圖、揭露隱藏假設、提供中立建議、引導需求釐清 需求不明確時的探索性對話 業務分析師
Momus 計畫審查官 嚴苛驗證、零妥協審查、只有在無懈可擊時才批准、產出詳細審查報告 程式碼審查、合併前的最後把關 QA 主管 / 程式碼審查者
Athena 知識管理員 跨 session 知識累積與檢索、自動摘要學習成果、最佳實踐歸檔 長期專案的知識延續、團隊 onboarding 知識庫管理員 / 技術作家
Themis 合規審查員 安全漏洞掃描、OWASP 威脅模型檢核、授權與密碼學審查、OWASP Top 10 驗證 安全審計、合規檢查、生產環境部署前檢查 安全工程師 / 合規專員

代理的「唯讀」與「讀寫」模式

代理團隊中,部分代理(如 Oracle)預設為唯讀模式 — 他們可以閱讀程式碼、分析架構、提出建議,但不會直接修改檔案。這確保了顧問型代理不會意外變更程式碼,而執行型代理(如 Hephaestus)則擁有完整的讀寫權限。這種設計讓每個代理的權責範圍清晰明確。

代理團隊的協作模式

這些代理並非各自為政,而是以Sisyphus 為核心的編排體系。Sisyphus 像一個 Tech Lead,負責接收任務、拆解成子任務、指派給最合適的代理、追蹤進度,最後合併結果。這種「中心化編排、去中心化執行」的模式,既保持了協作的靈活性,也確保了輸出一致性。

團隊協作流程

當你提出一個需求時,OmO 的代理團隊會這樣協作:

▶ 使用者:為這個專案加入使用者認證功能
────────────────────────
[Sisyphus] 收到請求。正在解析需求...
[Sisyphus] 這是一個中等複雜度的功能,需要規劃與實作。
[Sisyphus] 指派 Prometheus 進行需求收集。
────────────────────────
[Prometheus] 我需要了解幾個關鍵問題:
1. 你偏好哪種認證方式?(JWT / Session / OAuth)
2. 是否需要第三方登入?(Google / GitHub / Line)
3. 使用者資料的儲存方案?(PostgreSQL / MongoDB)
────────────────────────
[Sisyphus] 收集到完整需求,產生執行計畫。
[Sisyphus] 指派 Hephaestus 進行實作。
[Hephaestus] 開始實作。先探索現有程式碼結構...
[Librarian] 背景任務:查閱 JWT 套件最新文件
[Explore] 背景任務:搜尋現有認證相關程式碼
...
[Momus] 開始審查實作結果...
✅ 審查通過。實作品質符合標準。
[Sisyphus] 所有任務完成!

8.5 分類路由(Category Routing)

OmO 的另一個核心特性是分類路由 — 根據任務性質自動選擇最合適的代理組合。這確保了每個任務都由最適合的團隊成員處理。

路由類別 適用場景 主要代理
visual-engineering 前端 UI、視覺設計、互動原型 Sisyphus, Hephaestus
ultrabrain 深度推理、複雜架構決策 Oracle, Metis
deep 需要長時間執行的深度任務 Hephaestus, Sisyphus
quick 快速查詢、簡單修改 Explore, Librarian
artistry 創意寫作、內容創作 Prometheus, Metis
writing 技術文件、API 文件 Prometheus, Librarian

路由通常是自動的,但你也可以手動指定:

# 自動路由(OmO 會根據任務內容判斷)
你:為這個 API 加入完整的錯誤處理

# 手動指定路由
你:使用 ultrabrain 模式分析這個架構設計

# 在 task() 中指定
task(category="visual-engineering", ...)

8.6 內建技能系統

OmO 也整合了 OpenCode 的技能系統,提供一系列開箱即用的專業技能:

🎭

playwright

瀏覽器自動化技能,用於端到端測試、網頁爬蟲、自動化截圖與表單填寫。支援 Chromium、Firefox 與 WebKit。

🔧

git-master

Git 操作專家技能,確保每次 commit 都是原子性的、提供 rebase/squash 策略、支援 blame/bisect/log -S 等進階除錯。

✨

frontend-ui-ux

即使沒有設計稿也能產出精美的前端介面。包含豐富的色板、字型搭配與互動模式,讓 AI 生成的 UI 擺脫模板感。

這些技能安裝後即可使用,會在對話中根據觸發詞自動載入。

8.7 你的第一個 OmO 指令

安裝完成後,你第一個應該嘗試的指令就是 Ultrawork(縮寫 ulw):

$
> /ulw 為這個 React 專案加入完整的錯誤邊界系統
────────────────────────
[Sisyphus] 🚀 啟動 Ultrawork 模式
[Sisyphus] 正在分析任務、制訂策略...
[Prometheus] 開始需求收集...
[Sisyphus] 任務已規劃完成。開始執行...
[Hephaestus] 正在實作 ErrorBoundary 元件...
[Explore] 搜尋現有錯誤處理模式...
[Librarian] 查閱 React 官方 Error Boundary 最佳實踐...
...
[Momus] 審查完成。通過。
✅ Ultrawork 完成!
已建立:
• src/components/ErrorBoundary.tsx
• src/components/ErrorFallback.tsx
• src/hooks/useErrorHandler.ts
• src/utils/errorLogger.ts
• src/__tests__/ErrorBoundary.test.tsx
💡 為什麼是 Ultrawork?

Ultrawork 模式會啟動完整的代理團隊協作流程:Prometheus 先規劃,Sisyphus 編排,Hephaestus 執行,Explore 與 Librarian 背景支援,最後 Momus 審查。這確保了高品質且一致的輸出結果。

8.8 Oh My OpenAgent 架構深度解析

OmO 不是一個單純的外掛,而是一套完整的任務編排系統。它改造了 OpenCode 從使用者輸入到任務完成的每一條執行鏈。理解 OmO 的架構,能幫助你更有效地使用它的各項功能,並在遇到問題時快速定位。

核心觀點

OmO 不是在 OpenCode 上套了一層殼,而是改造了整條任務執行鏈 — 從使用者發出訊息開始,到上下文注入、任務分類、模型路由、後台代理並行執行、工具呼叫前後攔截,再到 session 空閒時自動續跑。每一環都由專屬的代理與機制負責。

8.8.1 四層架構總覽

OmO 的架構可以分為四個層級,由底層到上層分別負責不同粒度的任務處理:

層級 名稱 負責代理 核心功能
第 1 層 上下文注入層 Explore, Librarian 在使用者訊息送達模型前,自動注入相關的專案上下文、程式碼參考與技術文件
第 2 層 任務分類層 Sisyphus, Metis 分析使用者意圖,判斷任務的類別(實作 / 研究 / 審查 / 規劃),決定適用的路由
第 3 層 模型路由層 Sisyphus, Prometheus 根據任務類別選擇最佳的 AI 模型組合(Claude / GPT / Gemini),配置溫度與參數
第 4 層 背景執行層 Hephaestus, Athena, Momus 啟動背景代理並行執行子任務,監控進度、彙整結果、執行品質審查

8.8.2 從使用者訊息到任務執行:完整流程

當你在 OpenCode 中輸入一條訊息,OmO 的執行鏈如下所示:

$
> 為這個專案加入使用者認證功能
──────────────────────────────────
[上下文注入層] 正在收集專案上下文...
├─ Explore:掃描專案目錄結構與現有檔案
├─ Librarian:查閱 JWT 與 OAuth 最新文件
└─ 上下文注入完成(3 個參考檔案)
──────────────────────────────────
[任務分類層] 正在分析使用者意圖...
├─ Sisyphus:辨識為「功能開發」任務
├─ Metis:確認需求明確,無需額外釐清
└─ 分類結果:visual-engineering 路由
──────────────────────────────────
[模型路由層] 正在配置模型組合...
├─ 主模型:GPT-4o(適合實作任務)
├─ 顧問模型:Claude Opus(架構審查)
└─ 路由完成,準備執行
──────────────────────────────────
[背景執行層] 啟動多代理協作...
├─ Hephaestus:開始實作認證模組
├─ Athena:記錄實作過程的技術決策
├─ Momus:背景監控實作品質
└─ Sisyphus:追蹤整體進度
✅ 任務完成!

8.8.3 工具呼叫前後攔截機制

OmO 的一個關鍵設計是工具呼叫攔截(Tool Call Interception)。每當代理要執行一個工具操作(如讀取檔案、搜尋程式碼、執行指令),OmO 的攔截層會介入:

階段 攔截動作 目的
呼叫前 驗證工具參數合法性、檢查檔案路徑範圍、評估操作風險等級 防止代理誤操作或存取不應觸及的資源
執行中 監控工具執行時間、設定逾時保護、記錄呼叫次數 避免代理陷入無窮迴圈或過度消耗資源
呼叫後 過濾敏感輸出、擷取關鍵結果摘要、將結果回饋給上下文 確保代理僅取得必要的資訊,保護敏感資料

這種攔截機制讓 OmO 可以在不修改各代理內部邏輯的情況下,統一實施安全策略與資源管理。這也是 OmO 被稱為「編排層」而非「外掛」的原因之一 — 它不是在原有系統旁邊加功能,而是嵌入到每一筆工具呼叫的生命週期中。

8.8.4 Session 空閒時自動續跑機制

當你長時間未操作時,OpenCode 的 session 可能會逾時中斷。OmO 的自動續跑(Auto-Resume)機制解決了這個問題:

  • 心跳監控:背景執行緒定期檢測 session 活性
  • 狀態保存:每當代理完成一個子任務,OmO 自動保存當前進度與中間結果
  • 自動重連:偵測到 session 中斷時,自動發起新的 session 並載入已保存的狀態
  • 斷點續跑:從最後一個完成的子任務繼續執行,不須從頭開始
實際應用場景

假設你啟動了一個大型重構任務,預計需要 2 小時完成。中途你去開會或休息,session 因逾時中斷。當你回來時,OmO 已自動恢復 session 並從中斷處繼續執行 — 你不會遺失任何進度,也無需重新下達指令。

8.8.5 代理跨層協作圖譜

不同代理並非固定在某一層,而是根據任務需要在多層之間協作:

代理 主要活躍層級 跨層協作對象 協作模式
Sisyphus 第 2、3 層 所有代理 主編排者,串接分類、路由與執行
Prometheus 第 3 層 Sisyphus, Hephaestus 規劃產出後移交給執行層
Hephaestus 第 4 層 Sisyphus, Explore, Librarian 執行中呼叫資料收集代理取得參考
Oracle 跨 2-4 層 Sisyphus, Momus 以唯讀顧問身份提供架構建議
Explore 第 1、4 層 Hephaestus, Sisyphus 上下文注入與執行中程式碼搜尋
Librarian 第 1、4 層 Hephaestus, Prometheus 規劃階段與執行階段的外部資料查閱

8.8.6 架構設計哲學

OmO 的架構設計遵循幾個核心原則,這些原則也體現在代理團隊的每一個設計決策中:

  • 編排重於自動化:與其讓代理完全自主決策,OmO 採用 Sisyphus 集中編排的模式。這確保了複雜任務的執行一致性
  • 層級分離:四層架構讓每一層可以獨立演化。例如,你可以在不改動代理行為的情況下,替換底層的模型路由策略
  • 攔截而非修改:工具呼叫前後攔截機制讓 OmO 可以在不侵入各代理內部邏輯的前提下,統一實施安全、監控與資源管理
  • 背景透明化:使用者不需要知道哪個代理正在處理,甚至不需要知道 OmO 的存在 — 只需輸入需求,系統自動完成其餘工作

8.9 常見問題

Oh My OpenAgent 和 OpenCode 是什麼關係?▼
Oh My OpenAgent 是 OpenCode 的外掛,不是替代品。它建立在 OpenCode 的基礎功能之上,提供更高層次的多代理協作能力。你可以先熟悉 OpenCode 的基本使用,再安裝 OmO 來獲得進階功能。OmO 的主要價值在於代理團隊協作、多模型支援與智慧路由。
安裝 OmO 後,原來的 OpenCode 功能會受影響嗎?▼
不會。OmO 是附加在 OpenCode 之上的增強層,所有原有的 OpenCode 功能(內建指令、代理系統、技能等)都可繼續正常使用。OmO 新增了 Ultrawork 模式、分類路由、代理團隊等高階功能,但不會取代或破壞任何原有功能。如果你希望暫時不使用 OmO,只需不觸發 Ultrawork 模式即可。
我需要為每個 AI 服務都準備 API 金鑰嗎?▼
不一定。OmO 可以只使用一個 AI 服務(如僅 Claude 或僅 GPT)就能運作。多模型的主要優勢在於:不同的 AI 模型在不同類型的任務上各有擅長。例如,Claude 在程式碼理解與安全審查方面表現優異,而 GPT 在創意發想與文件撰寫方面更為出色。你可以根據需求與預算,逐步增加支援的 AI 服務。
OmO 的四層架構各自負責什麼?▼
第 1 層(上下文注入層)由 Explore 和 Librarian 負責,在使用者訊息送達模型前注入專案上下文;第 2 層(任務分類層)由 Sisyphus 和 Metis 分析意圖並決定路由;第 3 層(模型路由層)由 Sisyphus 和 Prometheus 選擇最佳 AI 模型組合;第 4 層(背景執行層)由 Hephaestus、Athena 和 Momus 啟動背景代理並行執行並監控品質。
工具呼叫前後攔截機制會影響效能嗎?▼
攔截機制的開銷極小(微秒級別),因為攔截邏輯是輕量的驗證與過濾操作,不會引入額外的 AI 模型呼叫。相反地,攔截機制透過防止錯誤操作與過早逾時,反而提升了整體任務成功率與執行效率。
Session 自動續跑機制如何確保狀態一致性?▼
OmO 在每次子任務完成時,會將當前完成的任務結果、未完成的任務佇列、已收集的上下文資料序列化為 JSON 狀態快照。當 session 恢復時,OmO 從快照重建執行環境,並從斷點處繼續。這種設計確保了即使 session 中斷多次,任務最終的結果與從頭執行到底完全一致。

小試身手

在 OmO 代理團隊中,哪個代理的角色是「主編排器」,負責解析意圖與分派任務?
下列哪個分類路由適合用來處理「需要深度推理的複雜架構決策」?
在 OmO 安裝完成後,可以用哪個指令來驗證所有服務正常運作?