Dong-skills — 智能體協作工作流
- Codex
- Claude Code
- OpenCode
- Grok CLI
- Agent Workflows
- Code Review
- Verification
一個公開的個人 skills 倉庫，把反覆使用中的多智能體 coding 實踐寫成明確的操作規則。四條已命名工作流覆蓋實際在用的配對 — Claude-Codex 互評、Codex-OpenCode、Codex-Grok 與 Codex-Antigravity — 每條都固定同樣幾個問題：什麼可以委派、什麼保持私有、誰負責 git，以及第二 agent 的意見在成為被採納的改動前必須通過哪些檢查。三條之中有兩條跑在 Codex CLI 裡，編排的是我自己那組六插件矩陣中的插件；第三條跑在 Claude Code 裡，編排的是一個第三方插件。
項目概覽
角色 獨立作者 — 工作流設計、安全邊界、審查協議、文檔，以及實測失敗記錄
場景
多智能體 coding work 如果範圍、隱私、審查權限與驗證責任不明確，很容易失控。第二個 agent 只有在職責範圍受控，且其結論被真實 repo 驗證時才有價值。而真正耗時間的失敗很少是推理出錯，多數是運行時出錯：一個讓第二 agent 啟動即死且沒有有效報錯的配置值、一個只回 id 的長任務、一個被 wrapper 靜默丟掉的參數。
產品策略
我把反覆使用中的協作實踐整理成 skills：限制第二個 agent 能看什麼、做什麼，設置審查關卡，並在交付前逐條對照 repo 驗證 — 對方是被委派方時用任務包，對方是同儕時則用一份被評審過的 spec 與 plan。每個運行時失敗都連同症狀、真正成因與確切恢復步驟一起記下，讓下一次會話認得它，而不是重新踩一遍。
成果與當前階段
公開 skills 倉庫 · 四條已命名工作流，兩種形態 — 一條同儕互評、三條受控委派 · 實測失敗記錄跨 2026-07 與 2026-08 累積 · 三條委派 skill 以已安裝插件的當前 contract 為準，不釘版本號
我的工作
- Claude-Codex 互評，分兩個階段：設計先在 fresh thread 裡被評審到 GO，才允許開始寫程式碼；之後 Codex 按任務實施，Claude 跑 Codex 沙箱跑不了的測試，並且只在測試綠加一輪評審之後才提交。測試綠本身不算完成；而且每次複查都開新 thread，因為被續用的評審 thread 會漂移，並且會憑空造出不存在的 bug。
- Codex-OpenCode 受控委派：可用性不確定時先做能力檢查，每次調用只承擔工具表上的一個角色，完成與否只認該次運行自己的完成標誌，之後在 Codex 側重讀每個被引用的文件、重跑每條相關命令。
- Codex-Grok 受控委派，四個角色 — 受控實施、獨立評審、對抗式評審、救援診斷 — 另加一份 acceptance ledger，把每條 Grok 結論標記為採納、拒絕或收窄。
- Claude-Codex 那條 skill 裡跨 2026-07 與 2026-08 累積的實測失敗記錄 — 九條 operational gotchas，另有六條紅線與五條反模式：讓第二 agent 啟動即死且沒有有效報錯的配置值；只回一個裸 job id 的長任務 — 應該去輪詢，而不是當成失敗；wrapper 不保證轉發、必須從 session 記錄讀回確認的 model 與 effort 參數；以及升級 CLI 卻碰不到已在運行的共享 runtime。
- 把驗收關卡寫成錯誤實作無法通過的樣子 — 起因是連續三輪評審打的都是關卡本身而不是程式碼：要求的文案必須綁定到真正渲染它的那個欄位與語言，因為「關鍵詞在文件裡出現過」不構成關卡。
技術證據
- 三條受控委派工作流共用的硬邊界：不執行破壞性命令、被委派方不 commit / push、不讀私有 runtime paths、一棵工作樹只能有一個寫者，未經驗證的結論一律不當作 finding 採納。
- 為三條受控委派工作流準備的可復用任務包結構：目標、二元驗收、限制在一到五個文件或一個窄目錄的 scope（Grok 那條再放寬到一個明確 diff）、讀寫權限、禁止動作、驗證命令、要求的返回格式與風險。同儕工作流不用這個結構 — 那邊的單位是 spec 與 plan，不是任務包。
- 同樣是那三條工作流的要求 — 每次委派都留一份 handoff record：角色、job 或 session id、確切範圍、終態、該次運行是否真的報告完成、第二 agent 的結論、已做的驗證、被拒絕的結論、實際跑過的命令，以及剩餘風險。
- 在那三條工作流裡，決定工具行為的是已安裝的插件而不是 skill 本身：skill 絕不從自己的正文重建缺失的工具或參數，也不釘死 contract 版本 — 正因如此，同族插件可以持續發版，而一條自 2026-07 起就沒再改過的工作流依然有效。
為什麼做這個倉庫
這個倉庫把反覆使用中的本地實踐整理成操作規則，讓 Claude Code、Codex、OpenCode 與 Grok 之間的協作有清楚範圍、可供檢查，也能用實際結果驗證。這些 skills 定義了什麼能委派、什麼保持私有、誰負責 git，以及第二 agent 的意見在被採納前必須通過哪些檢查。
寫下來的規則能活得比產生它的那次會話久。倉庫在 2026-07 與 2026-08 期間增加的內容，很多不是新理論，而是被記錄下來的失敗 — 症狀、真正的成因、確切的恢復步驟 — 因為這些細節，一個全新的會話沒有辦法用低成本重新發現。
第二 agents 的審查角色
Codex-OpenCode 工作流把 OpenCode 定位為第二 reviewer 或受控 helper。流程在可用性不確定時先做能力檢查，再發送明確任務包，禁止 commit 與破壞性命令，最後要求 Codex 對照真實文件與測試輸出驗證每個發現。
Codex-Grok 工作流把同一規則套到 grok-plugin-codex：在可用性或版本相容性不確定時先做能力檢查，只委派一個受控任務或 review，檢查完整結果，並讓 Codex 繼續負責文件、測試、git 與最終判斷。每條返回的結論隨後被標記為採納、拒絕或收窄 — 一段不完整的日誌或一句肯定的斷言只是線索，不是結論。
Claude-Codex 工作流刻意不是這個形態。它是雙向的：兩側互相評審，直到兩個模型與測試套件都同意；角色被固定住，不允許倒置；而且設計階段在實施開始前就設了關卡。受控委派攔得住一個壞 diff；只有在 fresh thread 裡被評審到 GO 的設計，才攔得住那種根本就不該被實作出來的方案。
工作流跑在什麼之上
工作流之所以區分宿主與供應方，是因為插件本身就是這樣分的。三條 skill 之中，一條跑在 Claude Code 裡；跑在 Codex CLI 裡的那兩條附帶對應的 agent 註冊文件。我自己的六個同族插件把三個第二 agent 接進兩個宿主 — Claude Code 側是 opencode-plugin-cc、grok-plugin-cc 與 agy-plugin-cc；Codex CLI 側是 opencode-plugin-codex、grok-plugin-codex 與 agy-plugin-codex。三條工作流掛到這個矩陣上的方式並不齊整：Codex-Grok 那條直接點名 grok-plugin-codex；Codex-OpenCode 那條是對著 opencode_* 工具面寫的，並未點名某個插件；而 Claude-Codex 那條依賴的是一個第三方插件，根本不在我這組裡。
覆蓋範圍比矩陣窄，也比矩陣看上去的更窄。四條已命名工作流覆蓋的是 Claude-Codex 這一對，加上矩陣裡整個 Codex CLI 側 — OpenCode、Grok 與 Antigravity。Claude Code 那一側 — opencode-plugin-cc、grok-plugin-cc 與 agy-plugin-cc — 目前仍然沒有自己的已命名工作流。一對配對要等我用到它的失敗模式值得記錄，才會被寫成 skill；這個倉庫要當的是「實際壞過什麼」的記錄，而不是「什麼可以接起來」的地圖。