一個人寫程式碼容易盲點。所以我們發明了 pair programming——兩個人看同一份程式碼，一個寫、一個審。

現在有人問：如果兩個都換成 AI 呢？

這個概念從哪來

Axel Delafosse 在他的部落格上發了一篇「Agent-to-agent pair programming」，在 HN 拿了 97 分和 34 則討論。核心想法：讓 Claude Code 負責寫程式碼，讓 OpenAI Codex 負責 review，兩個 agent 在同一個 codebase 上來回迭代，直到 review 通過。

不是人 + AI，是 AI + AI。人類退到 supervisor 的角色——設定目標、審核最終結果，中間過程交給兩個 agent 自己跑。

實際怎麼運作

目前有幾種做法在社群裡流通：

手動切換派。 最原始但很多人在用。Claude Code 寫完一個 feature，把 diff 丟給 Codex review。Codex 找到問題，人類把 review 結果貼回 Claude Code。來回幾輪直到通過。HN 上有人提到做了 10-15 輪 fix-and-review 才完成一個大功能。

共享檔案派。 兩個 agent 透過 PLAN.md 或類似的 markdown 檔案溝通。一個寫計畫，另一個執行；一個寫 code，另一個在同一份檔案上留 review comment。簡單但笨拙——本質上是把 Google Docs 的模式搬到 AI agent 上。

直接通訊派。 Axel 的做法更進一步——利用 Codex 的 App Server（開源的）和 Claude Code 的 Channels 功能建立直接連線，agent 之間即時通訊，不需要人類當傳話筒。

為什麼用不同的 AI

HN 討論裡有個很實際的觀察：Claude 擅長生成和創造，Codex 擅長「頑固、準確地挑毛病和稽核」。

這不是偶然。不同模型有不同的訓練偏好和行為傾向。讓同一個模型自己 review 自己的產出，它傾向於確認自己的決策——跟人類的確認偏誤一樣。用另一個模型來審，能打破這個迴圈。

有人用了另一種組合：Codex 寫、Opus review。也有人用 Claude 同時生成和 self-review（問它「你確定嗎？」），通常它會承認自己遺漏了什麼。但跨模型 review 的效果普遍被認為更好。

一位 HN 使用者的說法很精準：「Claude 完成一個任務後，讓 Codex review，幾乎每次都能找到問題。每次。」

社群裡的分歧

肯定的聲音：

有人把這套流程接進了 GitHub Actions——Sentry 偵測到錯誤 → 自動建 issue → Claude Code 修 bug → Codex review → 開 PR。全自動。對重複性的 bug fix 來說，效果不錯。

有開發者用 self-review（同一個模型，不同的 system prompt 和 temperature）也看到明顯改善。「即使是同一個模型，第一次產出的品質和 review 後的品質差很多。」

質疑的聲音：

「需要更多科學。」目前所有 multi-agent 的證據都是 anecdotal。沒有 controlled study 比較 single-agent vs multi-agent 在相同任務上的表現差異。

「更多改動不一定是好事。」兩個 agent 互相 loop 可能產出超出原始 scope 的修改。對人類開發者來說，scope creep 已經夠頭痛了——現在 AI 也會。

「生命週期管理是真正的難題。」Agent A 叫 Agent B 做事，B 做到一半 crash 了，A 等到天荒地老。有人花了三週解決 happy path 之外的 lifecycle 問題，最後搞出了一套類似 saga pattern 的 agent 協調協議。

最犀利的一句話：「The circle of slop.」（垃圾的循環。）直接了當，但也反映了一部分人對 AI 生成程式碼品質的根本懷疑。

這對你的開發流程有什麼啟發

我認為 agent-to-agent pair programming 的核心洞見不在於技術實作，而在於一個觀念：AI 的第一次產出幾乎永遠不是最好的。

你不需要兩個 agent 的花式架構來獲得這個好處。最簡單的做法：

1
2
3
4
5
1. 讓 AI 寫完程式碼
2. 換一個 context（新的 session、不同的 system prompt）
3. 讓 AI review 自己的產出
4. 根據 review 修改
5. 重複直到 review 沒有重大問題

這比單次生成的品質好很多，成本只是多幾輪 API 呼叫。

如果你想更進一步，跨模型 review 確實有價值。不同模型有不同的盲點分布。Claude 可能在某些 edge case 處理上有慣性，Codex 可能在另一些地方有偏見。交叉 review 能覆蓋更大的錯誤空間。

但要注意幾件事：

成本會翻倍甚至更多。 每一輪 review 都是一次完整的 LLM 呼叫。10 輪 fix-and-review 就是 20 次呼叫。對於按量付費的 API，這個成本不能忽略。

scope creep 需要控制。 給 review agent 明確的指令：「只檢查正確性和安全性，不要建議重構。」否則兩個 agent 會互相激勵，把一個簡單的 bug fix 變成大規模重寫。

人類仍然是 supervisor。 兩個 AI 達成共識不代表結果是對的。它們可能在同一個方向上犯同一個錯——尤其是涉及業務邏輯或架構決策時。最終的 approve 必須是人類。

展望

Agent-to-agent 開發還在非常早期的階段。通訊協議不統一、lifecycle 管理粗糙、缺乏系統性的效果評估。

但方向是對的。人類 pair programming 的價值早已被證實——兩雙眼睛比一雙好。AI 的版本也遵循同樣的邏輯，只是把「眼睛」換成了不同的模型視角。

如果你現在就想試，不需要等工具成熟。打開兩個終端機，一個跑 Claude Code，一個跑 Codex CLI。手動把一邊的產出餵給另一邊。笨，但有效。等生態系統成熟了，再考慮自動化。

相關資源：HN 討論、Swival self-review、AxmeAI agent lifecycle