買現成、自己造，還是等官方？
跨模型協作的執行層，我評估過現成方案、自己造了一套一千六百行的，最後被官方 plugin 整批做掉。而我居然很開心。
git 裡看不到的部分#
我不想再當 AI 之間的人肉路由器的結尾說到，repo 的第一個 commit 不是故事的開頭。這一篇講開頭：「讓 AI 之間直接協作」這個目標定下來之後，執行層要怎麼搭？我走過三代答案，而前兩代在 git 裡連屍體都沒留下。
第一代：買現成的#
最先考慮的是社群熱門的 PAL，一個現成的多模型協作工具箱（技術上是一個 MCP server：MCP 是把外部工具接上 AI 的標準插座，裝了它，AI 就多一批可以呼叫的工具）。它提供 consensus（多模型表決）、codereview（跨模型審查）這類工具，聽起來每一個都命中需求。
但我淘汰它的理由有三條：
- 維護者對安全疑慮的回應，不能讓人放心；
- 隔著一層黑盒子，出問題難以 debug；
- 最實際的一條：五千多行 Python，對「跨模型 review」這個簡單需求來說太重了。
我要的是一條水管，它給我的是一整套自來水廠，而且水廠的圖紙不在我手上。
所以「買現成」的帳不能只算功能覆蓋率，還要算出事的時候你能不能自己修。答案是不能，那就不買。
第二代：自己造#
那就自己來。清單如下：一個約 150 行的迷你版工具插座（自寫的 MCP server）、兩支轉接殼腳本（wrapper，把別家 AI 的指令包成自家 AI 叫得動的形狀），配上三個自訂的子代理（subagent，主 AI 派出去幹活的分身，各自有乾淨的工作記憶）：codex-coder 負責寫、codex-reviewer 負責審、gemini-reviewer 出第二意見。再加幾個串流程的腳本，整套長到 1600 多行。
它能動，但代價陸續浮現。先是三個環境問題輪流咬人：trusted-directory 的信任設定、stdin 的處理、權限提示的互動。每一個都不是「功能寫錯」，而是自製管線跟宿主環境的邊界摩擦，而這種摩擦只有維護管線的人要負責磨平。然後是總量：1600 行的自製件，每一行都是自己的責任。依賴會升級、介面會變動，它們不會通知你，只會在某天默默壞掉。
不過自己造換到的東西也要誠實記帳：完全的透明。哪裡卡住，翻自己的 code 就知道；想加什麼，當天就能加。第一代缺的正是這個。此刻的帳面是「透明 vs 維護成本」，看起來還打平。
最貴的一筆學費先記在這裡，下一篇會展開：codex-coder 加 codex-reviewer 這個組合，看起來是兩個代理在互相制衡，其實是同一個模型呼叫兩次。這件事的殺傷力比它聽起來大得多。
第三代：官方來了#
2026 年 3 月底，OpenAI 發布了官方的 codex plugin，把 Codex 直接整合進 Claude Code。「整合」在使用端只剩這樣（README 安裝段原文節錄，整台機器做一次）：
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex裝完，/codex:review、/codex:adversarial-review、/codex:rescue 開箱即用。我 debug 過三個環境問題才換來的東西，人家兩行指令。
於是我自製的那些元件，一夕之間全部有了官方對應物。設計文件裡留著一張退役對照表（原文），一個蘿蔔一個坑：
| v2 元件 | v3 取代 |
|---|---|
.claude/scripts/codex_exec.sh | Codex Plugin 內建 |
codex-reviewer subagent | /codex:review |
codex-coder subagent | /codex:rescue |
gemini-reviewer subagent | 不再需要（codex 取而代之） |
handoff-context-format skill | Plugin 自己處理 context 傳遞 |
cross-model-review skill | /codex:review 直接 invoke |
plan-with-review skill | superpowers writing-plans + auto /codex:review |
七列，每一列都是我寫過、debug 過、最後親手劃掉的東西。文件給這件事的措辭是「完成歷史任務、可以光榮退役」。1600 多行縮到約 900 行，這就是「少即是多」在這個專案第一次登場。
注意用詞：是「光榮退役」，不是「白做了」。這個差別是本篇真正想講的東西。
該一開始就等嗎？#
被官方做掉之後，最自然的檢討是：「如果一開始就等等看，會省很多事。」這句話對了一半。
對的那一半，後來成為文件裡的關鍵教訓：自製方案要警惕官方化的可能性。如果你在解的問題夠通用，官方或生態遲早會解它，而他們的版本有你拿不到的整合深度。
但錯的那一半更重要：「總是等」不是對的策略。第二代的價值不在那 1600 行程式碼，在它逼我真實理解了問題：什麼是隔離、哪裡會踩環境雷、context 該怎麼傳。
所以官方解法一出現，我能在第一時間判斷它好在哪、哪些自製件該退役、哪些概念要留下。沒有第二代的踩坑，第三代不會這麼乾淨。若不自己造過一次，你分不清官方給的是水管，還是又一座水廠。
造的目的不一定是用，有時是為了看懂。 造過一次的人才有資格快速地買。
這段歷史不在版本控制裡#
寫這篇時我做了一次考古，結果值得單獨記一段。repo 的第一個 commit（4 月 25 日）裡，研究員已經定位成搜尋角色、review 已經走官方 plugin，那已經是第三代的落地。第一代的評估、第二代的 1600 行、被官方做掉的整個過程，全部發生在 repo 誕生之前，git 裡一個 commit 都沒有。
前兩代沒有屍體，只有設計文件裡的訃聞。如果當初沒有把「為什麼淘汰 PAL」「自己造的那套踩了什麼」寫進文件，這段最有教育意義的歷史就蒸發了。開發史的精華常常不在版本控制裡——版本控制只記得你做了什麼，不記得你放棄了什麼。
下一篇#
這一篇回答了「執行層該買、該造、還是該等」：買，輸在出事時修不了黑盒；造，換到了對問題的真實理解；等到官方出手，就讓自製件光榮退役。另外還撈回一條差點蒸發的教訓——開發史的精華常常不在版本控制裡。
而第二代最貴的那筆學費，值得整整一篇：兩個輪流上場的代理，看起來在互相制衡，其實是同一個人分飾兩角。下一篇講這套 kit 最重要的智識框架，看起來 multi-agent，不等於有隔離，以及隔離到底有幾種。