我把 AI workflow 搞成七位一體，然後放棄了 MCP

大概三個月前我還在想「怎麼把 Claude 用到極致」。

現在我每天實際在做的事已經變了——不是用 AI，而是在設計一個多智能體的工作組織。我的日常 workflow 已經從一個 AI 演化到七個，我自己內部叫它「七位一體」。

這趟路踩過幾個很明確的坑，走到後面我才發現一件事：AI workflow 的真正瓶頸從來不在模型，而在協作協議。

從一個 AI 到七個

最早的版本很簡單：一個 Claude 負責所有事情。寫 code、review code、做決策、整理筆記，全都它。

問題很快就出現：當你讓同一個 agent 既是執行者又是審查者，它會自我合理化。它會說「這個改動沒問題」，因為那是它自己寫的。

所以我開始拆角色：

• 規劃者（拍架構）
• 執行者（寫 code）
• 審查者（挑錯）
• 反對者（故意唱反調、毒舌那種）
• 分析者（做技術比較和 research）
• 本地腦（跑隱私資料、背景批次）
• 人類（也就是我，最終 ratify）

加到第四個角色「反對者」之後，我發現產出的問題變少了——因為衝突被設計進系統裡，不用再靠我一個人去抓問題。

這件事跟「prompt engineering」差很遠。它比較像組織設計：你不是在調整一個員工，而是在安排一個團隊的分工和制衡。

然後我撞到一面牆：複雜度

七位一體聽起來很帥，但很快我就發現三件事：

1. Context 切換成本暴增——每個 agent 都要重新 orient 一次
2. Latency 變長——每一步都要等
3. 每一步都「形式正確但效率下降」——走完流程比問題本身還累

這時候我發現自己花在「管 agent」的時間，開始比「解決問題」的時間還多。這是很明確的警訊。

我原本以為 MCP 會救我

MCP（Model Context Protocol）是現在業界最潮的 agent 溝通協議。理論上它很優雅——統一的 tool binding、session 管理、權限控制，全部包得漂漂亮亮。

我照著做了一陣子，然後放棄了。

原因不是 MCP 本身有 bug，而是它抽象太厚：

• 一壞掉，你要同時懷疑 transport、schema、tool binding、權限、context 五件事
• 中間狀態看不見——理論上有傳，但你不知道實際傳了什麼
• 失敗模式不夠笨——好系統要壞也要壞得很蠢，讓人類能直接修

MCP 壞掉的時候常常是「一團霧」。你看著它，它看著你，大家都不知道為什麼。

我改用了最土的方法：CLI + File I/O

Agent 之間改走檔案溝通。每個 agent 都有自己的 inbox 和 outbox：

~/Documents/agent-council/
  {agent}-briefing.md   ← 我寫給它的任務
  {agent}-answer.md     ← 它的回應

Claude 寫 briefing → 我執行 CLI 或手動貼 → Claude 讀 answer 綜合判斷。

這聽起來很原始。實際跑起來的感受完全相反——它比 MCP 穩很多。

為什麼？因為 file-based 有四個 MCP 很難給你的特質：

可追溯。 每一步都落地成檔案，不是聊天紀錄裡的一坨糨糊。

可重跑。 某個 agent 爆了，直接重跑那一步，不用整段重來。

可插拔。 今天 Claude 做 reviewer，明天換 Gemini，只要吃同一份檔案格式就能接上。

可治理。 approve/reject gate、retry、timeout、風險分級、人工覆核點，全部都能直接加在檔案協議上。

解決了 concurrency 之後，下一關是一致性

剛開始兩三個 agent 同時寫檔案會撞車，我用 atomic rename + lock 檔解掉了。過了那關之後，下一關立刻冒出來：一致性與可恢復性。

具體來說有四個問題你要回答：

1. Immutability——你是 overwrite 還是 append？如果是 overwrite，之後 debug 會是地獄
2. Single Source of Truth——status 只能有一份，其他全部是 artifact
3. 崩潰後復原——如果某個 agent 寫到一半掛掉，誰會接手？怎麼判斷卡住？
4. 冪等性——同一個任務被執行兩次會不會壞掉？

這四件事一寫下來，我忽然理解了：我不是在寫 script，我是在做一個 file-based 的 workflow engine。

檔名變成路由層

後來我又補了一步。一開始檔案只有類型，後來我開始把更多資訊塞進檔名：

[timestamp]__[repo]__[to]__[type]__[task_id].md

• 交付對象放進檔名——誰該接、誰該看一眼就知道
• repo 名放進檔名——多專案並行時不會串線
• 時間戳——新舊順序、重跑痕跡一目了然
• review 和 answer 分開——批判不是交付，審查不是答案

最後一點很關鍵。很多 AI workflow 死掉，就是死在 review 和 answer 混在一起——看起來很忙，其實不可控。

真正的轉折點

走到這裡，我忽然意識到一件事：

我花最多時間的不是「選哪個模型」，也不是「調 prompt」，而是在想：

• 任務怎麼交接？
• 狀態怎麼保存？
• 失敗怎麼恢復？

這三件事定好了，模型換誰都能跑。

這才是硬實力。不是 MCP 那種看起來很潮但一摔就散的東西。

給還在 AI workflow 路上的人

如果你現在也在往多 agent 的方向走，我的建議只有一句：

不要再加 agent 了。去寫一份讓這些 agent 不會互相踩死的憲法。

至少要包含：

• 任務 lifecycle（state machine）
• 檔案結構與命名規則
• schema 定義
• lock / concurrency 規則
• retry / timeout 規則
• human override 點

這份東西寫完，你的系統才會從「能跑」變成「能擴」。

結論

三個月前我覺得自己是 AI 工具的重度使用者。現在我比較像是在設計一個非常小的組織——只是這個組織的成員剛好是一群模型。

我真正學到的事：

MCP 比較像展示架。CLI + File I/O 比較像工地。而真正蓋出東西的，通常不是展示架。

「七位一體」只是我內部的暱稱，重點從來不是「七」。重點是從「會用 AI」跨進「會讓 AI 合作但不失控」這一層。

下一步我會把整套檔案協議正式化成一份 spec 丟出來。如果你在做類似的事，歡迎交換筆記。