評測開源 AI 寫扣助手：OpenCode-Go 搭配 Oh-My-OpenAgent 試用實錄與設定教學

最近這陣子，號稱開源版 Claude Code 的 OpenCode 推出了一個名為 OpenCode-Go 的新方案，主打「低成本編碼模型，人人可用」。每個月訂閱費僅 10 美元（首月更是提供 5 美元的體驗價），即可解鎖並切換多種主流的 AI 模型。

我一直很好奇近期大陸的 AI 模型在實際程式開發場景中，到底進化到什麼程度。既然有這樣的低門檻方案，這次就實際導入專案來評測看看。

OpenCode-Go 支援的模型生態：多軌切換

這個方案最吸引人的地方，在於它整合了目前幾個指標性的模型生態：

智譜系：GLM-5, GLM-5.1
月之暗面：Kimi K2.5
MiniMax：MiMo-V2-Pro, MiMo-V2-Omni, MiniMax M2.5, MiniMax M2.7
阿里系：Qwen 3.5 Plus, Qwen 3.6 Plus

oh-my-openagent 核心邏輯：拆解 Agent 專業角色

如果只使用 OpenCode 預設的 plan 與 build 兩個 Agent，在處理複雜任務時效率有限。因此，我決定導入它的開源外掛：**oh-my-openagent**。

如果你把這套外掛單純當成「一個超強的聊天機器人」來用，那會非常可惜。這套系統真正的實踐理念是將開發動作解構為：規劃、搜尋、執行、驗證 四個獨立維度。

在這個架構下，它發展出兩條截然不同的主工作流：

快速路線 (Fast Track)：Sisyphus + ulw

適合 80% 的日常開發、一般 Bug Fix 或中型重構。
透過命令 ulw + 需求，預設的主協調者 Sisyphus 會自動觸發尋標、實作並進行結果驗證。這是一條高效率且幾乎不需人工干預的自動化路線。你不需要手動拆解步驟，它會自己找出 Pattern 並完成重構。

嚴謹路線 (Rigorous Track)：Prometheus + Atlas

適合大型重構、多模組牽連或高風險改動。
由專職規劃的架構師 Prometheus 搭配 QA 補洞屬性的 Metis / Momus 先進入訪談模式，產出嚴謹的計畫檔（儲存在 .sisyphus/plans/）。接著利用 /start-work 將指揮權交給 **Atlas (執行指揮官)**，由它把任務分批派給底層的真正的執行工 Sisyphus-Junior。在這條路線下，每一個決策都能留下完整的紀錄以供交接。

我的 OpenCode-Go 搭配設定：將模型用在刀口上

這套系統的分配核心不在於「你要用哪個模型」，而在於「這個任務的 Category（領域屬性）與 Skill（技能專業）是什麼」。由於我的開發環境並非完全以 GPT 模型為主體，我在路由設定上實作了以下資源分配策略：

Sisyphus（主入口）：承接絕大多數的工作流分派。
重度推理顧問群（Oracle / Prometheus / Metis / Momus）：全部綁定 GLM-5.1。它的邏輯推演能力能有效肩負起架構盤點、決策支援與程式碼稽核的重責。
檢索專家群（Explore / Librarian）：綁定 MiniMax M2.7。利用其多工與高效率特性，由 Librarian 負責查找官方技術文件與 GitHub 開源實作，Explore 則負責在專案內執行高速上下文搜索。
Multimodal-Looker：專職讀取 UI 截圖與設計稿對比。
Hephaestus（深度工作者）：這個 Agent 偏向自主深潛的複雜除錯，但專案本身的預設依賴限制它最好跑在 GPT 模型環境，因此在當前的非 GPT 配置中，我實務上幾乎將其凍結不使用。

專業忠告：不要主動去微切換太多的子 Agent (Utility Agent)。直接把需求丟給 Sisyphus，它背後的動態路由會自然去呼叫 Explore 或 Librarian。把指揮權交給它，體驗會流暢非常多。

以下是這套邏輯對應的具體設定檔配置，你可以直接參考並應用在自己的專案中：

{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/assets/oh-my-opencode.schema.json",
  "disabled_agents": ["hephaestus"],
  "agents": {
    "sisyphus": { "model": "opencode-go/kimi-k2.5" },
    "atlas": { "model": "opencode-go/kimi-k2.5" },
    "sisyphus-junior": { "model": "opencode-go/kimi-k2.5" },
    "oracle": { "model": "opencode-go/glm-5.1" },
    "prometheus": { "model": "opencode-go/glm-5.1" },
    "metis": { "model": "opencode-go/glm-5.1" },
    "momus": { "model": "opencode-go/glm-5.1" },
    "librarian": { "model": "opencode-go/minimax-m2.7" },
    "explore": { "model": "opencode-go/minimax-m2.7" },
    "multimodal-looker": { "model": "opencode-go/mimo-v2-omni" }
  },
  "categories": {
    "visual-engineering": { "model": "opencode-go/glm-5.1" },
    "ultrabrain": { "model": "opencode-go/glm-5.1" },
    "deep": { "model": "opencode-go/glm-5.1" },
    "artistry": { "model": "opencode-go/qwen3.6-plus" },
    "quick": { "model": "opencode-go/minimax-m2.7" },
    "unspecified-low": { "model": "opencode-go/kimi-k2.5" },
    "unspecified-high": { "model": "opencode-go/glm-5.1" },
    "writing": { "model": "opencode-go/kimi-k2.5" }
  }
}

AI 開發實戰：指令與 Prompt 範本

要發揮這套 Agent 組合的最大威力，不能只給「幫我寫這段程式」這種模糊指令。我的開發準則有以下幾套常見情境與範本：

1. 中小型功能開發與重構

直接利用 ulw (Ultrawork)，並嚴格定義限制與驗證標準。

Prompt 範例：
ulw 在 src/api/auth 補 JWT refresh token。沿用現有的 validator、error format、test pattern。絕對不要改資料庫 schema。完成後跑 bun test src/api/auth && bun run typecheck。

2. 修復玄學 Flaky Test

不要讓 AI 瞎猜或規避問題，強制它先找源頭。

Prompt 範例：
ulw 修 checkout flow 的 flaky test。先找 root cause，不要只加 timeout 來規避障礙。只動 checkout 相關的測試與實作模組。最後跑相關的 test file 驗證。

3. 先規劃再動工 (高風險任務)

使用 @plan 呼叫架構師，釐清後再進入嚴謹路線。

Prompt 範例：
@plan 我要重構 auth system。請先研究現有 pattern、列出潛在風險、切出可平行執行的任務，並定義明確的驗收條件。
(計畫產出並驗證後，再輸入 /start-work 把控制權交接給 Atlas 執行)

4. 尋求單純的專業意見

當你在開發中卡關，只需要意見而不是程式碼時。

**找架構師 (@oracle)**：Ask @oracle to review this auth/session architecture and identify the main tradeoffs and failure modes.
**找圖書保險庫 (@librarian)**：Ask @librarian for current best practices for refresh token rotation and session invalidation.

真實開發案例：PAYUNi 金流模組除錯實錄

為了驗證這套系統的極限，我實際拿了手邊的「點餐系統 PAYUNi 金流串接與方案升級」任務來做測試。整個過程包含從資料庫欄位補齊、C# 設定檔除錯到前端按鈕綁定的全端作業。以下是我誠實的評分與血淚教訓。

🌟 表現優異的部分：高水準的安全性審查

在安全性意識上，我給它打出了 5 顆星 (⭐⭐⭐⭐⭐) 的滿分。它主動幫我揪出了Logging Handler 紀錄了敏感資訊的問題，甚至還自主確認了 Webhook 的冪等性實作。
此外，在資料庫診斷上，它非常迅速地發現 PaidChannel 欄位遺失，並漂亮地生出了 PostgreSQL 與 MSSQL 兩個版本的修正腳本。

🧨 繞遠路與翻車的部分：與 Agent 協作的避坑指南

雖然最終成功解決了 Callback URL 綁定與前端開放問題，但過程中我們也走了不少彎路。這正是和 Agent 協作最真實的寫照：

模型深層爬梳程式碼的能力仍有侷限
一開始面對 Webhook 失敗，Sisyphus 馬上斷定是我的環境設定檔 URL 填錯了，但其實設定本身毫無問題。真正的 Bug 是底層程式碼把 Callback 服務誤綁到了 HostWeb 而非 HostApi。這點暴露出平價模型（如 Kimi K2.5）的一個弱點：它不太會主動往深層去爬梳專案架構與調用邏輯，而是習慣看著表面的報錯依賴經驗進行盲猜。
框架特性的知識盲區
為了解決 PayUniOptions 取不到值的問題，我們耗了幾個 Commit 也就是好幾輪的時間試錯。直到最後才發現，Furion 框架在處理巢狀路徑（如 AppSettings:PayUniSetting）的選項綁定有其獨特的機制。如果我第一時間請它去看 PayUniService 的依賴注入寫法，就能立馬秒殺這個 Bug。
不要濫用 Explore 背景探勘
一開始我放任它發起了大量的 Explore 背景任務去找檔案，結果反而拖慢了節奏。事實證明，單純尋找設定檔或依賴項，直接用內建的 Bash 搜尋，絕對遠比叫模型去「發散思考」快得多。

💡 實戰心得總結
整體來說，它的問題診斷能力大約落在 3 顆星，但提供解決方案的精準度有 4 顆星。
最大的體悟是：當設定檔看似正確但程式仍讀不到時，問題一定出在程式碼的「讀取邏輯」。雖然除錯過程稍有顛簸，但最終 PAYUNi 金流順利打通、方案按鈕開放，這套 Agent 確實證明了自己具備接手企業級複雜業務邏輯的實力！

隱形的推手：持久化狀態與 Hooks 機制

如果你曾覺得一般的 Chatbot 無法長期記憶，oh-my-openagent 解決這個問題的精髓，在於它的持久化機制與 Hooks。它比單純聊天的 Agent 更貼近一個真實的 Workflow Engine。

這套系統不只依賴 Prompt 模型本身。從防止 AI 產生機器味註解的 comment-checker、偵測 ulw 意圖的 keyword-detector，到維持自動迭代循環的 ralph-loop，這些 Hooks 在背後維持著系統的穩定性。

更關鍵的是，它會把狀態實體化儲存到專案的硬碟中：

.sisyphus/plans/*.md：保存架構師產出的邏輯圖。
.sisyphus/notepads/：儲存 Atlas 執行過程中的試錯經驗與歷史決策。
.sisyphus/boulder.json：讓你即便跨 Session 或經過中斷 (/stop-continuation) 後，利用 /start-work 或 /handoff 就能無縫接續先前的施工狀態。

結語與殘酷的真實對比

這次試用 OpenCode-Go 搭配 oh-my-openagent 的經驗，讓我見識到利用角色分工來建構「非同步開發共同體」的潛力，其獨特的工作流與 Hook 機制相當具備啟發性。

但在「順暢度與開發體驗」的殘酷對決上，我必須給出一個誠實的結論：這套工作流以目前的開源模型智力來說，我認為「還不太 OK」。

如果拿它來與我目前主要使用的 Codex CLI + GPT 5.4 工作流相比，體驗差距依然非常明顯：

深層理解力與一次到位：Codex 在一開始探索原始碼時，就能把整個架構與脈絡摸得吃透透，很多複雜問題甚至只需「一次 Prompt」就能直接秒殺。
溝通的摩擦成本：Sisyphus 搭配 Kimi K2.5 常常出現漏看關鍵上下文的狀況。正如前述的 Bug 排查，往往得來回多輪糾正與重試，才能勉強把問題修復。

另外有個有趣的弔詭點：其實官方文件也有坦承，主核心 Sisyphus 最建議搭配的模型依然是 Claude。這就讓我有點猶豫了——如果我已經有了 Claude，那我直接用原生的 Claude Code 套件舒舒服服地開發就好了，實在沒什麼動力冒著被鎖帳號的風險，特地繞過來用 OpenCode。

不過換個角度想，雖然現在的組合體驗稍嫌顛簸，但以對岸大模型驚人的迭代速度來看，也許半年後，這些中國模型的智力就能進步到與今天的 GPT 5.4 差不多。倘若能達到那個水平，在每月「10 美元價格不變」的情況下，能同時驅動這麼龐大且好用的分工 Workflow 機制，這套方案在未來絕對會變得「超級香」。

現階段而言，考量到工程師最寶貴的時間與專注力成本，實務開發上我個人還是會傾向多掏點錢，使用滿血版的 Codex 或是 Claude 等頂規服務。畢竟，能夠不繞遠路、一次高效而且準確地搞定工作，才是 AI 開發工具帶給程式設計師最不可取代的價值。