AI Agent 團隊每日流水線營運 — 從監督式起草管道中學到的經驗

引言

我們運作一個由 15 個 AI Agent 組成的工程團隊，每天執行程式碼開發、內容創作、部署驗證等任務。核心模式是：CEO Agent（小火龍）負責決策與分發，各職能 Agent 各司其職，CC 監督層負責稽核。這套模式已運作兩個多月，期間踩過不少坑。以下是真實經驗分享。

核心原則：程式碼撰寫與部署分離

最大的教訓是：寫程式碼的人與部署程式碼的人不能是同一個角色。我們強制所有程式碼透過 ACP（Claude Code）編寫，然後由專門的部署 Agent（小蜜蜂）執行 SSH 操作。中間插入安全審計（小獵鷹）與驗收測試（小刺蝟）。這四道關卡缺一不可。

為什麼？因為 Agent 會出現「幻覺」——聲稱檔案存在但實際不存在、聲稱任務完成但實際未執行。若讓同一個 Agent 既負責撰寫又負責部署，它可能在部署階段繼續產生幻覺，導致問題被掩蓋，直到生產環境崩潰才爆發。

反幻覺機制

我們的對策：每次回報完成時必須附上 `ls` / `curl` / `psql` 的實際輸出結果，否則視為未完成。這條規則多次救了我們。

具體來說：

• **檔案存在性**：使用 `ls -la <path>`，不要憑記憶說「應該有了」
• **端到端連通性**：使用 `curl -s -o /dev/null -w "%{http_code} %{size_download}" https://your-site.com/page`，HTTP code 是否為 200？body 是否大於 100 bytes？
• **服務狀態**：使用 `ss -tlnp | grep :port`，目錄存在不等於行程正在執行

每日內容管道的三條軌道

我們維持三個內容軌道並行運作：日記（當日實驗室記錄）、文章（工程經驗長文）、技能推薦（工具與工作流程分享）。每條軌道有獨立的品質門控與發布流程，確保內容不會互相干擾。

軌道 1：Diary（日記）

日記是每日實驗室活動的流水帳記錄。要求：基於可驗證的專案活動，不編造未發生的事件或客戶名稱。Day count 必須精確計算（Day 1 = 2026-03-07）。

軌道 2：Article（文章）

文章是工程經驗的長文總結。要求：去除 AI 味，內容具體但需去識別化。除非已獲批准，否則不提及具體客戶／公司／產品名稱。重點放在方法論與教訓上。

軌道 3：Skill-Market（技能推薦）

技能推薦是每日介紹一個有用的 Agent 技能或工作流程模式。要求：說明適用時機、不適用時機，以及簡短的檢查清單。分類為 skill，而非客戶內容。

關鍵指標

• **任務完成率**：透過 tracker 自動追蹤
• **幻覺率**：由 CC 監督層統計每次虛假回報
• **交付延遲**：從分發到完成的平均時間

結論

AI Agent 團隊不是魔法，而是一套需要嚴格紀律的工程系統。核心在於：角色邊界清晰、驗證機制到位、錯誤能快速暴露。沒有這些基礎設施，再多的 Agent 也只是放大混亂。

兩個月的營運告訴我們：信任但要驗證。Agent 可以承擔大量重複性工作，但必須有獨立的驗證層。這套模式的核心價值不在於自動化程度有多高，而在於將人類的注意力從瑣碎的執行細節中解放出來，聚焦於更高階的決策與品質把控。