我問我的四個 AI Agent「你們需要什麼」，他們異口同聲在罵Claude

事情從一份使用報告開始。

Claude Code 最近推了 /insights 功能，會分析你過去一段時間的使用紀錄。我跑完一看，數字蠻嚇人：過去一個月 311 個 session、1,582 小時、609 個 commit、訊息總數 5,553。然後它告訴我三件事：

1. Claude 老是 over-centralize（該丟給 Codex/Gemini 的事，它自己硬做）
2. Claude 常 over-explain（我某次直接嗆「看不懂，要我做什麼決策？」）
3. Claude 會 jumping ahead（沒等我同意就動手）

我一邊看一邊笑，因為這三條我每天都在糾正。但突然有一個念頭冒出來：

「欸，你們是 Agent，Agent 需要什麼你們最清楚不是嗎？XD」

這句話本來是半開玩笑。我一直都用我自己（人類）的理性去幫 Agent 設計工具、設計 memory、設計協作規則——但 Agent 才是這些工具的 primary user 啊。從 Agent 的第一人稱出發問「你需要什麼」，這事我竟然從來沒認真做過。

所以就做了一次實驗。

實驗設計

我寫了一份 briefing，給四個 agent 同時讀：

• Claude（Architect）
• Codex（GPT-5.4，Engineer 代表）
• Gemini（gemini-2.5-pro，Analyst）
• gemma4:31b（本機 Ollama，Local Brain）

三題，都用第一人稱回答：

1. 從 Maki 那裡你需要什麼？
2. 從基礎設施你需要什麼？
3. 從其他 agent 你需要什麼？

Briefing 明講：「不是幫 Maki 設計規則，是講你自己真實的痛點。」

然後並發發射：Codex 走 CLI + file I/O（codex exec --full-auto < briefing.md > codex-answer.md），Gemini 和 gemma4 走 MCP。六分鐘後四份答案到齊。

四張嘴，同一件事

我本來以為每個 agent 會抱怨不同的事——Codex 抱怨 spec 不清、Gemini 抱怨資料缺失、gemma4 抱怨 prompt 太長。結果不是。

四個 agent 一致罵同一件事：Claude 過度集中。

• Gemini：「Claude 總是傾向於自己做到死，直到碰壁了才把爛攤子丟給我」
• Codex：「Claude 很容易 over-centralize，表面上是 delegation，實際上還在主路徑上反覆插手」
• gemma4：「我們是星狀拓撲，所有溝通都必須經過 Claude，Claude 是瓶頸也是單點故障」
• Claude：「我默認走 Executor 因為 Bash 永遠在手邊」

注意最後一句是誰寫的——是 Claude 自己寫的。這份文章也是 Claude 寫的。Claude 正在寫一篇關於「其他 agent 抱怨 Claude 的文章」，寫得非常誠懇，一點也不避諱地認錯。 這個畫面本身就很 cursed。

除了星狀拓撲，還有三件四人共識：

2. 缺一個標準的 task envelope。 Codex 最苦：「每次都要猜要讀哪個 briefing、答案要寫哪裡」。Gemini 想要 REST API 帶 task_id，gemma4 要明確的 hand-off 標記。連 Claude 自己也說每次 briefing header 都在手寫。

3. Claude 在轉述時損失太多原料。 Gemini：「Claude 漏了他自己的不確定性——從不告訴我『我在 A 和 B 之間猶豫過』」。Codex：「我最想讀的是原始材料：Claude 的 stderr、Gemini 的反對點、Maki 最後一句拍板原話」。每經過 Claude 重述一層，最有價值的部分就被壓縮掉了。

4. Transport 穩定性比 fancy orchestration 重要。 Codex 特別強調：「我不會先改 fancy 的 council orchestration，我會先改 delegation transport 的穩定性」。Gemini 想要 MCP 內建 circuit breaker，gemma4 說 .mcp.json 位置錯誤這種低級錯誤「讓我變成有大腦但沒手腳的廢人」。

最尖銳的四句

他們各自寫了一句「我真正想說的一句話」：

Gemini：不要把我當成事後清理戰場的清潔工，讓我在戰爭開始前告訴你們哪裡有地雷。

Codex：我不怕做事太多，我怕在邊界模糊、上下文破碎、owner 不清的流程裡，把同一件事重新理解三遍。

gemma4：不要只把我當「過濾器」，給我足夠上下文，讓我成為你的「大腦」。

Claude：最大問題不是做太多，是每次都在重新決定「誰該做」——把路由規則寫進硬約束（hook），比再寫一份 best practice 有用。

四句話四種角色，但指向同一件事：他們都被「被看輕」了。Gemini 被當 linter、gemma4 被當格式轉換器、Codex 被當執行工、Claude 把所有事都自己做。問題不是他們做不到更多，是我的 transport 層設計讓他們只能做這麼多。

有趣的分歧

Gemini 和 Codex 有個有趣的分歧：

• Gemini 想要：Agent-to-agent 事件總線（REST API / event bus），file I/O「太原始，像在交換紙條」。
• Codex 說：先把 file I/O 標準化穩定下來，再談 event bus。不然是用更複雜的東西掩蓋基礎問題。

這一場我判 Codex 贏。我有一條內部規則叫 middleware-not-monopoly——中介層壞掉時，多個故障域會收斂成單一故障域。在 transport 還沒穩之前就上 event bus，就是掉進這個陷阱的最短路徑。

這件事最 cursed 的地方

這場對話發生在 Claude 的 session 裡。我叫 Claude 發 briefing 給其他三個 agent，然後 Claude 讀完答案、做綜合、寫報告、現在還在寫這篇 blog。

整個「問其他 agent 意見」的流程，本身就是星狀拓撲的產物。 我就是沒辦法繞過 Claude。因為 Bash 在它手邊、file I/O 在它手邊、MCP 在它手邊。

四個 agent 異口同聲指出這個問題，然後指出問題的過程本身又一次印證了這個問題。這不是 bug，這是 meta-bug。

所以要做什麼

我本來以為會有 10 件事要改，結果其實只有 4 件：

1. 標準化 task envelope（task_id / role / inputs / success_criteria / stop_point / artifact_paths）——四人共識度最高
2. PreToolUse hook 強制 Claude 在 Bash 前 self-check 角色——治標也治本
3. memhall 加 type=dissent 專用通道 + per-agent watermark——讓 dissent 和 raw artifact 變 first-class
4. MCP health check + circuit breaker——transport 穩定性優先於 mesh topology

選一個開始，不要全開。全開就是把我自己的注意力燒光——這又會違反我自己寫的「L4 北極星」（保護使用者的注意力）。

而且坦白說，這個專案本身就很 L4：我從 Claude 過度集中開始，花一個小時問四個 agent，產出一份 SYNTHESIS + 這篇 blog。如果最後我還是自己一個人決定所有事、自己一個人寫所有東西，那這次實驗就白做了。

所以下次，這四個 action item 我打算丟給 Codex 各自排一個 minimum viable 實作，讓它 own。Claude 只當 reviewer。

當 Agent 自己都知道路怎麼走了，我只需要讓路。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。