CCG Workflow：讓 Claude Code 指揮 Codex、Gemini 與 Grok 的多模型協作引擎

它解決什麼問題：多模型協作的手動切換地獄

一個工程師在一個任務中，往往要來回使用不同模型。Codex 擅長生成程式碼，Gemini 可能對特定領域有不同見解，Claude 則擅長理解整體脈絡。但這些模型各自獨立，你必須手動複製貼上、切換視窗、整理對話。CCG Workflow 試圖把這個過程變成單一指令。你只要在 Claude Code 中輸入 /ccg:go 加上任務描述，引擎就會分析意圖、分類任務、選擇策略，然後把工作分配給 Codex、Gemini、Grok 等模型。這個專案的主要受眾是已經深度使用 Claude Code 的開發者，他們希望在不離開既有介面的前提下，獲得其他模型的專業意見。它不是一個通用 AI 平台，而是一個針對 Claude Code 生態的擴充套件。

核心機制：Go bridge 與 Hook Engine 的狀態注入

CCG 的架構圖顯示，Claude Code 是主編排者，它分析你的意圖、選擇策略、管理整個工作流。關鍵的技術細節在於兩部分。第一是 codeagent-wrapper，這是一個編譯好的 Go 二進位檔案，它作為橋接器，讓 Claude Code 可以呼叫外部模型進行平行分析與審查。第二是 Hook Engine，這個引擎在每一輪對話中注入狀態，讓 Claude 即使經過 context compaction（上下文壓縮）後，也不會失去任務的脈絡。這是一個重要的設計選擇，因為大型語言模型在長對話中經常遺忘早期指令，而 CCG 透過 Hook Engine 把狀態持續寫入，避免這個問題。從 README 的範例流程來看，當你輸入 /ccg:go add JWT authentication to this API，引擎會先讀取專案上下文，包括 git status、技術棧、檔案結構，然後分類任務為 feature、L complexity、backend、high risk，接著選擇 full-collaborate 策略，建立 .ccg/tasks/add-jwt-auth/task.json 檔案，再啟動 Codex 與 Gemini 的雙模型分析。

安裝與啟動：從 npx 到 dsh 子指令

安裝方式非常直接，README 寫明了兩個主要入口。第一個是全域安裝，執行 npx ccg-workflow，它會引導你完成安裝，號稱 60 秒內完成。第二個是針對 DeepSeek Harness 的整合，執行 npx ccg-workflow dsh install，這個指令會安裝所有找到的 profile，你也可以用 --profile <name> 指定單一 profile。要查看已安裝的 profile，則執行 npx ccg-workflow dsh list。值得注意的是，README 提到可以在 npx ccg-workflow 的互動選單中選擇 D. DeepSeek Harness，這代表安裝流程是互動式的。另外，如果你是 Claude Code 的使用者，可以選擇 APIMart 作為 API 提供者，因為它提供 Anthropic-compatible endpoint，你只要在第一步挑選 APIMart 並貼上金鑰即可。這些指令都來自 README，實際執行時可能因為環境差異而需要額外設定，例如 API 金鑰的環境變數，但 README 並未詳細列出。

真正的限制：依賴鏈與 HARD STOP 的設計

任何多模型協作工具都有依賴鏈問題，CCG 尤其明顯。它依賴 Claude Code 作為主編排者，這意味著如果你的 Claude Code 版本不支援 Hook Engine，整個狀態注入機制就會失效。其次，它依賴外部模型的 API，Codex、Gemini、Grok 各有自己的 API 限制與延遲，任何一個服務中斷，都會阻塞整個工作流。從 README 的流程描述中，可以看到一個特別的設計：步驟 6 是 Produces plan → HARD STOP for your approval，也就是說引擎在產生計畫後會強制暫停，等待你的批准。這是一個好的安全措施，但也意味著你無法全自動執行任務，你必須在每個重大決策點介入。對於希望完全放手讓 AI 處理任務的用戶，這可能是一個摩擦點。另外，README 並未提及錯誤處理機制，例如某個模型 API 呼叫失敗時，引擎是否會自動重試或降級，這在實際使用中是關鍵問題，但目前文件沒有提供答案。

dsh-ccg：另一種整合路線的對比

CCG 專案內含一個名為 dsh-ccg 的子模組，它提供了與主引擎不同的整合方式。主引擎透過 codeagent-wrapper（Go binary bridge）讓 Claude Code 呼叫外部模型，而 dsh-ccg 則直接運行在 DeepSeek Harness 內部，不需要外部 CLI、不需要二進位橋接器，每一次 hop 都是 provider API 請求。這個差異很關鍵：主引擎的架構多了一層 Go bridge，這層可能引入冷啟動延遲或相容性問題，而 dsh-ccg 直接以 API 呼叫取代，理論上更輕量。dsh-ccg 提供了七個角色固定的委派工具，每個角色綁定一個模型與專家 persona，並有兩項主引擎無法乾淨做到的功能。第一是 model panels，你可以給一個角色多個模型，它們會獨立回答同一份簡報，並排顯示在對話中，不投票、不平均，分歧就是發現。第二是 live teammates，ccg_team 可以僱用一個角色作為持續存在的同事，它擁有自己的檔案，如果發生衝突的僱用會被拒絕，而不是警告，而且每次僱用都需要你事先批准。對於使用 DeepSeek Harness 的用戶，dsh-ccg 是更直接的選擇，因為它已經打包在 CCG 中，你不需要追蹤第二個版本。

維護成本與授權：MIT 下的雙重依賴

CCG Workflow 採用 MIT 授權，這意味著你可以自由使用、修改、商用，但必須保留原始版權聲明。這對企業用戶是友善的，但要注意專案本身依賴多個外部服務，包括 Claude Code、Codex、Gemini、Grok 等，這些服務各有自己的條款與費用，MIT 授權並不涵蓋這些外部 API 的成本。維護成本方面，專案的最後一次推送是 2026 年 9 月，最近發布了名為 preset 的版本，內容是 codeagent-wrapper 的預編譯二進位。這代表專案仍在活躍開發中，但你必須追蹤上游模型的 API 變更，例如 OpenAI 或 Google 調整 endpoint 格式時，codeagent-wrapper 可能需要更新。另外，專案的主語言是 Go，但同時提供 npm 套件（ccg-workflow），這代表你需要同時理解 Go 與 Node.js 生態，才能除錯。如果你只是單純使用 npx 指令，維護負擔相對小，但若要自行修改 bridge 或 hook 邏輯，就需要掌握兩種語言。

編輯結論

CCG Workflow 適合已經以 Claude Code 為主要開發介面、且需要引入外部模型進行平行分析或審查的工程師。它不適合從零開始、沒有 Claude Code 使用經驗的團隊，因為整個引擎的運作前提是 Claude 作為主編排者。若你主要使用 DeepSeek Harness，則應優先考慮內建的 dsh-ccg 角色矩陣，而非透過 CCG 的 Go bridge 間接呼叫。在採用前，你必須先驗證三件事：你的 Claude Code 版本是否支援 Hook Engine 的狀態注入，Codex、Gemini、Grok 的 API 憑證是否齊備，以及 .ccg/tasks/ 目錄下的 task.json 結構是否符合你的專案需求。CCG 的價值在於它把多模型協作從「手動切換」變成「單一指令觸發」，但這份便利建立在 Claude Code 與外部 API 的雙重依賴上，任何一環不穩，整個流程就會卡住。

官方來源

1. fengshao1227/ccg-workflow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases