拆解 Oh-My-OpenCode 與上下文工程的未來

OpenCode 正在開發者圈引起廣泛關注。免費的高效能模型加上強大的外掛生態系統，正在加速開發者從封閉式 AI 編碼工具轉移的趨勢。

其中一個外掛特別值得注意 - 由韓國開發者金延奎（YeonGyu Kim）打造的 Oh My OpenCode，它作為多代理協作的實際實作，將不同的 AI 模型當作一個協調運作的團隊來使用，已經獲得了高度的關注。

在通讀整份程式碼之後，我發現這不僅僅是聰明的提示詞技巧。在上下文工程的層次上，正在發生真正的結構性創新。

單一代理編碼工具的結構性瓶頸

大多數 AI 編碼工具都是用單一代理來扮演所有角色 - 規劃者、開發者、除錯者、研究者 - 以串行方式執行。這會造成不斷累積的問題：

• 上下文窗口消耗飛快。 每次角色切換都會分散代理的注意力，把原本可以用在實際工作上的 token 浪費在上下文切換上。
• 上下文過載引發幻覺。 當太多不同的關注點堆疊在同一個上下文中，模型就會開始捏造資訊或直接放棄任務。
• 單一模型的弱點會主導整體表現。 如果你唯一的模型擅長 UI 但架構設計不行，架構工作的品質就是會受到拖累。

核心創新：基於編排器的團隊架構

Oh My OpenCode 真正的突破在於 Sisyphus - 一個管理者代理，透過平行執行將工作分派給專業化的子代理。

• Frontend Engineer 負責 UI 元件、Librarian 執行文件研究、Oracle 設計架構 - 全部同時進行。
• 每個代理的上下文在程式碼層級就是隔離的。這對防止上下文腐化至關重要 - 所謂上下文腐化，就是累積的無關資訊隨時間逐漸降低輸出品質。
• 不同模型服務不同角色。 架構設計交給 GPT-5（Oracle）、需要引用佐證的研究交給 Claude Sonnet 4.5（Librarian）、創意性的 UI 生成交給 Gemini 3 Pro（Frontend Engineer）、文件撰寫交給 Gemini 3 Flash（Document Writer）。每項任務都分配到最適合它的模型。

Sisyphus 編排器：設計哲學

Sisyphus 不只是做角色分配 - 它透過程式碼來強制執行工作流。

• createSisyphusAgent 函式從 Phase 0（意圖閘門） 到 Phase 3（完成） 動態組裝提示詞，定義了一個結構化的執行管線。
• 平行執行是強制性的。 程式碼中包含類似 // CORRECT: Always background, always parallel 的註解，搭配注入的 background_task 呼叫模式，強制所有任務同時執行。
• 串行執行在結構上被封鎖。 架構設計使子任務不可能依序執行 - 一切都在設計上就是平行分派的。

Librarian 代理：基於證據的研究實踐

對抗幻覺最精密的防線存在於 Librarian 代理中。

• 每個論述都必須附上 GitHub 永久連結。 回覆必須引用可驗證的來源 - 「官方文件第 3 行、GitHub issue #1234、原始碼第 47 行。」
• 回答前必須先完成分析區塊。 代理會區分「字面請求」（使用者輸入了什麼）和「實際需求」（使用者真正需要什麼），並將兩者明確分開。
• Type A/B/C/D 分類系統會平行搜尋 GitHub Issues、官方文件和原始碼，以收集佐證資料。
• 2024 年以前的資訊會自動被排除。 代理強制優先搜尋 2025 年之後的文件。

用程式碼而非祈禱來確保任務完成

最令人印象深刻的部分在於，行為規範是透過程式碼而非單純的提示詞來強制執行的。

• Todo 接續強制器（Todo Continuation Enforcer）：當代理過早認為自己已經完成時，系統會偵測 session.idle 事件，並注入一則系統訊息：「還有剩餘任務，繼續執行。」這防止了代理過早宣告完成這個常見的失敗模式。
• Ralph 迴圈（Ralph Loop）：代理被強制在迴圈中持續運行，直到它明確輸出 <promise>DONE</promise> 標籤為止。完成與否由具體的證明來判斷，而非模型的自我評估。

LSP 整合：用 IDE 的方式理解程式碼

不同於典型的基於 grep 的程式碼搜尋，Oh My OpenCode 實作了真正的 Language Server Protocol 客戶端。

• LSPClient 類別直接與語言伺服器（如 typescript-language-server）通訊。
• 它處理 Content-Length 標頭和 JSON-RPC 訊息 - 這和 VSCode、IntelliJ 用來理解程式碼的協定完全一致。
• 診斷（Diagnostics）、定義（Definitions）和參考（References） 直接暴露為代理工具，讓 AI 擁有和人類開發者在編輯器中依賴的相同程式碼智慧。

階層式上下文注入

開發者不應該每次都得向代理解釋專案背景。Oh My OpenCode 將這件事自動化了。

• findAgentsMdUp 函式從目前檔案所在目錄開始，向上遍歷整個目錄樹。
• 舉例來說，編輯 src/components/auth/LoginForm.tsx 時，系統會自動收集 src/AGENTS.md、src/components/AGENTS.md 和 src/components/auth/AGENTS.md。
• 架構規則、UI 模式、安全準則在任何程式碼被撰寫之前就被注入代理的上下文中 - 自動擷取專案的隱性知識。

為什麼這很重要

與 Cursor 或 Claude Code 相比，Oh My OpenCode 展示了一種工程優先的方法：同時結合多個模型的優勢、用結構化方式管理上下文而非碰運氣、透過程式碼而非仰賴提示詞的遵從性來強制正確行為。

隨著這種社群驅動的方法快速擴散，值得關注的是這個模式 - 帶有程式化防護機制的多模型協作團隊 - 是否會成為 AI 輔助開發的產業標準。