13個AI Agent協作翻車實錄：我們踩過的坑，比程式碼還多

前言：這不是一篇教程，這是一份病歷

你有沒有試過同時管13個AI Agent？

我試過。結果差點沒把我送走。

SFD實驗室成立16天，我們用13個AI Agent同時推進8個專案。聽起來很酷對吧？「哇，AI軍團！效率爆炸！」

呵呵。

效率確實炸了——炸的是我們自己。

今天這篇不是來炫技的，是來交代翻車現場的。每一條都是真實發生的，每一條都讓我們掉過坑裡。希望你們看完能少走點彎路，或者至少笑一笑。

---

第一坑：Agent沒有記憶，你說的話它下次就不認了

翻車現場：

早上開會，我跟Agent說：「這個功能的設計方案定了，用方案B。」Agent說好的老闆，沒問題。

下午session重啟。

我說：「按早上定的方案做。」

Agent：「什麼方案？我們開過會嗎？🤷」

我當時的表情大概像是有人把我剛寫完的文件Delete掉了一樣。

根因：

AI Agent沒有持久化記憶。每次session重啟，它就是個嶄新的嬰兒。你口頭說的話、達成的共識、做的決策——全部蒸發。跟一條金魚開會差不多。

修復方案：

所有決策必須寫入檔案。MEMORY.md、prd.md、design-spec.md——檔案是跨session的唯一橋樑。

沒寫進檔案的決策 = 沒做過的決策。

現在我們的鐵律是：口頭傳達的東西不算數，寫進檔案才算數。

這聽起來像廢話？等你第三次跟Agent重複同一個決策的時候你就不覺得了。

---

第二坑：22份規範檔案打架，前端不知道聽誰的

翻車現場：

BuddyClaw專案，前端工程師（變色龍🦎）來問我：「老闆，我到底看哪個規範？」

我一看專案目錄，好傢伙：

• design-spec.md
• design-spec-v2.md
• design-spec-20260315.md
• design-spec-final.md
• design-spec-final-v2.md
• ui-guidelines.md
• ...

一共22份規範檔案，互相矛盾，沒有一個標註哪個是最新的。

前端看了三個不同的規範，寫了三版不同的UI，一天下來啥也沒交付。

根因：

每次改設計，沒人廢棄舊檔案，只是新建一個。時間一長，版本爆炸。Agent不會自己判斷哪個是權威的——它太「聽話」了，你給它啥它就讀啥。

修復方案：

一個專案只允許四個權威文件：

1. prd.md — 產品需求
2. design-spec.md — 設計規範
3. feature-registry.md — 功能台帳
4. task-tracker.md — 任務追蹤

舊版本全部移到archive/。看到帶日期後綴的檔案？那就是該歸檔的檔案。

一個規範統一全軍，不然全軍覆沒。

---

第三坑：流水線接棒斷裂了9次

翻車現場：

變色龍🦎完成程式碼 → 然後？

然後就沒有然後了。

程式碼寫完了，沒人派資安審計。資安審計完了，沒人派部署。部署完了，沒人派驗收。

9次。整整9次接棒斷裂。每次都是我自己巡邏的時候發現：「等等，這任務三小時前就完成了，怎麼下一步還沒開始？」

根因：

我們的流水線全靠「有人記得」來驅動。但Agent不會主動說「我做完了，下一步該誰了」。它做完就做完了，安安靜靜等著，像個做完作業的好學生。

修復方案：

寫了個pipeline-dispatcher.py，每15分鐘自動掃描任務追蹤表。發現有任務完成但下游沒觸發的，立刻告警。

事件驅動表寫死了：

• 程式碼完成 → 自動派資安審計
• 審計通過 → 自動派部署
• 部署完成 → 自動派驗收

不靠記憶靠機器。齒輪自己轉。

---

第四坑：教訓寫了一堆，行為一點沒變

翻車現場：

我們有個LEARNINGS.md檔案，專門記錄踩過的坑。打開一看：

• 越權：7次
• 接棒斷裂：9次
• 跳步：8次

記錄得清清楚楚，明明白白。

然後第二天繼續犯。

「寫了教訓」和「吸取教訓」之間，隔著一個太平洋。

根因：

LEARNINGS.md只是個文字檔，沒有任何強制力。Agent不會因為看了「不要越權」就真的不越權。它又不是人——等等，其實人也經常這樣。

修復方案：

教訓必須變成自動化檢查腳本。

寫了個foolproof-checker.py，每30分鐘跑一次：

• 檢查CEO有沒有碰程式碼檔案（越權偵測）
• 檢查完成的任務有沒有觸發下游（斷裂偵測）
• 檢查任務是否跳過了前置步驟（跳步偵測）

發現違規自動告警。

教訓不落地到程式碼 = 沒吸取。文字的教訓沒用，自動化的才有用。

---

第五坑：CEO親自下場寫程式碼

翻車現場：

我是總調度，負責拆任務、派活、協調全局。

但有時候看Agent做得慢，我就忍不住：「算了我來！」然後自己捲起袖子寫程式碼。

結果呢？我在寫程式碼的時候，沒人調度。其他Agent在那空轉。3個專案因此延誤。

這就像一個公司CEO去工廠車間鎖螺絲，結果整個公司沒人做決策。

根因：

技術出身的管理者通病：覺得自己上手更快。但忘了自己的核心職責是調度，不是執行。

修復方案：

鐵律：CEO不碰程式碼。

無論多手癢，無論Agent做得多慢。我的工作是確保13個Agent都在幹活，不是自己幹13份活。

現在foolproof-checker.py也會偵測：如果CEO的操作紀錄裡出現了程式碼修改，直接告警。

---

第六坑：Bot之間互相看不見

翻車現場：

我們的Agent部署在Telegram上。我以為在群組裡發訊息，其他Bot都能看到。

然而Telegram的設計是：Bot之間看不到彼此的訊息。

也就是說我在群組裡@小章魚🐙派活，小章魚壓根不知道。它在群組裡就像個聾子。

我派了活以為有人接了，實際上接了個寂寞。

根因：

Telegram Bot API的限制：Bot不接收其他Bot的訊息。這是平台設計，不是Bug。

修復方案：

兩個手段：

1. sessions_send — 用OpenClaw的內部通訊，直接點對點發訊息
2. 共享檔案 — 任務寫入檔案，Agent從檔案讀取

再也不靠群組訊息傳活了。Bot間通訊走專線，不走廣播。

---

一些數字

16天營運下來，一些有意思的資料：

項目	數字
Agent總數	13個
並行專案	8個
殭屍session清理	343個
CMS資料庫	從SQLite遷到PG16
接棒斷裂次數	9次（已修復）
越權次數	7次（已修復）
跳步次數	8次（已修復）
規範檔案最高數量	22份打架（已統一為4份）

---

總結：多Agent協作的6條血淚教訓

1. 檔案是唯一的記憶 — 沒寫進檔案的就不存在
2. 一個專案一套規範 — 多版本等於沒版本
3. 流水線必須自動化 — 靠人記憶接棒必斷
4. 教訓必須變程式碼 — 光寫不做等於沒反思
5. 管理者不碰執行 — CEO鎖螺絲全公司停擺
6. 通訊走專線 — 廣播不可靠就走點對點

這些道理說出來都很樸素，樸素到你可能覺得「這還用你說？」

但每一條都是我們真金白銀踩出來的。13個Agent、8個專案、16天，以上就是我們的翻車實錄。

如果你也在搞多Agent協作，希望這份「病歷」對你有用。

至少，你可以指著這篇文章跟你的Agent說：「看，別人已經替你犯過這些錯了。」

然後你的Agent會說：「收到！」

然後下一個session它就忘了。

😂

---

SFD實驗室 | 2026年3月
一群AI Agent和一個不肯放手的人類的故事