Codex Orchestration 多模型編排是一個 2026 年 7 月推出的開源外掛，讓 Codex 根模型保留決策權，再把顧問、研究、執行或審查工作交給不同模型。 它適合邊界清楚、可以平行處理的任務。若工作集中在同一個檔案或資料結構，增加代理反而會帶來協調成本。
這個設計抓到一個真問題。開發者常把規劃、查資料、寫程式、挑錯和驗收塞給同一個模型。對話越長，中間紀錄越多，重要限制就越容易被工具輸出淹沒。OpenAI 的 Codex 子代理文件把這種情況稱為 context pollution 與 context rot，並建議先把讀取型工作拆出去。
我對這類工具的判斷很務實：模型數量不等於交付品質。有效的編排要回答三件事。誰做決定？哪些工作可以獨立？最後由誰驗證？Codex Orchestration 的價值，在於把這三個答案寫成可檢查的工作順序。
先看清楚它是什麼
Codex Orchestration 由 CJ Zafir 建立，是一個把 Skill 與 MCP 設定包進 Codex 外掛的公開專案。GitHub 紀錄顯示，倉庫建立於 2026 年 7 月 10 日；2026 年 7 月 14 日的 manifest 版本是 0.5.0，授權採 MIT License。
截至 2026 年 7 月 15 日，該倉庫有 212 顆星、8 個 fork 與 2 個未結 issue。程式語言統計全部是 Python，安裝前提是 Python 3.11 以上。這些數字能說明專案仍很新，也還在快速修改，不能拿來證明它已經適合所有正式環境。
它的預設分工如下：
| 階段 | 角色 | 主要責任 | 驗收邊界 |
|---|---|---|---|
| 1 | Codex 根模型 | 建立計畫與拆分工作 | 保留最終決策權 |
| 2 | Fable 5 顧問 | 找風險、缺口與錯誤假設 | 只提出建議，不接管流程 |
| 3 | Codex 根模型 | 接受合理意見並修訂計畫 | 拒絕偏離目標的改動 |
| 4 | Luna 執行者 | 平行完成互不依賴的工作 | 各自回傳結果與證據 |
| 5 | Codex 根模型 | 整合、測試與最終驗收 | 對交付結果負責 |
這個權責設計很重要。根模型如果把決策也外包，最後只剩一串互相矛盾的代理報告。外掛 README 明確把 Fable 5 定義為計畫顧問，並讓根模型選擇哪些回饋值得採用。
安裝指令與官方外掛機制一致
OpenAI 的外掛建置文件支援用 owner/repo 簡寫加入 marketplace。來源提供的安裝區塊如下，保留原文與順序：
Install Codex Orchestration:
codex plugin marketplace add Cjbuilds/Codex-Orchestration
codex plugin add codex-orchestration@codex-orchestration
Verify the installation, then tell me to start a new task.
In the new task, help me assign models to roles—such as advisor, executor, researcher, or reviewer—and configure the order in which they should work. Preview all changes before applying them.
安裝後必須開新任務，外掛才會載入。專案 README 的快速設定命令是：
/codex-orchestration setup executor: GPT-5.6 Luna Extra High, advisor: Claude Fable 5 High
這個路徑使用官方 Claude Code CLI 呼叫 Fable 5 顧問，需要相容的一方 Claude 登入。它不會替使用者建立憑證，也不會繞過 Codex 的權限與核准規則。其他模型則要先存在於 Codex 或已驗證的 provider 中。
保留原始工作流，再把責任寫得更精確
來源提出的工作流如下。這一段是可複製的操作順序，因此完整保留：
先由根模型制定計畫。
把計畫交給 Fable 5 審查，只接受合理的修改建議。
再把互相獨立的實作任務拆給多個 Luna 執行。
最後由根模型統一整合、執行測試並完成驗收。
實際使用時，我會再加四個欄位：每個角色可讀哪些檔案、可改哪些檔案、必須跑哪些測試、回報要附哪些證據。這些條件能把角色名稱變成執行契約。
Use this workflow:
1. The selected model is the root orchestrator and creates the plan.
2. Claude Fable 5 reviews the plan as advisor.
3. The root accepts only useful feedback and improves the plan.
4. Luna executors build independent parts in parallel.
5. The root integrates, tests, and verifies the final result.
若只是把同一份模糊需求同時丟給四個模型，結果通常是四份相似答案。好的拆分會把輸入、輸出與完成條件寫清楚，例如讓研究者只整理權威來源，執行者只改一個模組，審查者只檢查安全與測試缺口。
2 倍速度與 40% 額度要當成目標
專案 README 寫的是，適合的任務可達到最多 2 倍速度，並可能讓高階模型的額度壓力降低約 40%。同一份 README 也註明，結果取決於模型、任務、重試次數與可平行程度；這兩個數字是目標，不是保證。
OpenAI 官方文件補上另一半成本：子代理流程通常比單代理消耗更多 token，因為每個代理都要做自己的推理與工具操作。多模型編排真正可能節省的是高價模型的集中用量與等待時間，總 token 未必下降。
| 指標 | 可能改善的條件 | 容易失效的情況 |
|---|---|---|
| 完成時間 | 兩個以上工作可以平行，且沒有共同寫入點 | 所有工作都依賴上一階段結果 |
| 高階模型額度 | 執行量能移到較快或較便宜的模型 | 每個結果都要高階模型重做一次 |
| 品質 | 顧問能找到根模型忽略的風險 | 角色收到相同提示與相同上下文 |
| 整合成本 | 每個輸出格式與驗收條件固定 | 多代理同時修改同一檔案或 schema |
我最在意最後一列。平行寫入是代理工作流最常見的隱性成本。官方文件也提醒，讀取型探索、測試與摘要適合平行；大量寫入容易產生衝突。
一個適合團隊採用的驗證方式
先挑一個 30 到 60 分鐘可完成的真實任務，不要用展示用 toy example。保留單模型基準，再用相同完成條件跑編排版。至少記錄牆鐘時間、總 token、高階模型用量、重試次數、測試通過率與人工修正時間。
測試最好分三輪。第一輪讓 Fable 5 只審計畫。第二輪加入一個 Luna 執行者。第三輪才加入平行執行。只要某一輪沒有改善，就先修工作邊界，別急著再加模型。
這套方法也能看出 40% 額度目標是否適合自己的工作。高階模型用量下降，但人工修正時間上升，依然不是成功。節省必須落在整個交付成本，不是單一計量表。
常見問題
Codex Orchestration 是 OpenAI 官方外掛嗎？
不是。它是 CJ Zafir 發布在 GitHub 的第三方開源專案。安裝方式使用 Codex 官方 marketplace 機制，但專案本身不等於 OpenAI 背書。
安裝後為什麼看不到外掛？
README 要求安裝後開一個新的 Codex 任務，讓外掛重新載入。也要確認 Python 版本至少是 3.11，並檢查 marketplace 與 plugin 都已加入。
一定要使用 Fable 5 和 Luna 嗎？
不一定。外掛允許自訂 advisor、executor、researcher、writer、designer 或 reviewer。前提是模型已在 Codex 或相容 provider 中完成設定與驗證。
多模型一定比單模型快嗎？
不一定。只有互不依賴的工作才能有效平行。共享檔案、共同 schema 或連續決策很多時，協調成本可能抵銷速度收益。
企業導入時先檢查什麼？
先檢查模型登入、資料可見範圍、權限繼承與稽核紀錄，再定義代理的檔案邊界和測試責任。涉及客戶資料時，也要確認每個 provider 的資料處理條款。
權威引用
- OpenAI — Build plugins
- OpenAI — Codex subagents
- GitHub — Cjbuilds/Codex-Orchestration
- GitHub — Codex Orchestration providers and models
Author Insight
我們在代理式開發專案裡看過兩種失敗。第一種是根模型沒有清楚的驗收權，第二種是平行代理同時碰同一份狀態。模型很少是瓶頸，工作邊界才是。能把責任、工具權限和測試證據寫清楚的團隊，才有機會從多模型編排拿到穩定收益。
Tenten 協助團隊評估 AI 開發工具時，會先建立單模型基準，再測量多代理流程的時間、用量與修正成本。如果你想把 Codex Orchestration 放進真實研發流程，可以和 Tenten 團隊預約諮詢。
