Agent Team Workflow

這篇在講什麼

更新註記（2026-10）：早期我把它叫做「一個指揮官＋多個執行者」。現在我更習慣直接講模型：Gemini / Luna 處理需求整理、研究與輕量工作，Opus 負責架構、拆單與高判斷密度的 review，DeepSeek 扛大量施工。模型可以替換，但角色、邊界與驗證節點不跟著亂。

一個人不可能分身去當 PM、工程師、QA、客服——但一套 AI 多代理工作流可以。這篇講我怎麼用「一個指揮官 + 一群廉價執行者」的架構，一個人把 Learning Hub、客訴自動化這些系統蓋出來，而且品質有把關。

核心架構：不要談「最強模型」，直接談誰適合站在哪一段

我現在比較少用「貴模型／便宜模型」來描述這套流程，因為真正重要的是工作密度。

目前常見的分工長這樣：

Gemini / Luna
需求整理、研究、讀資料、輕量任務
        │
        ▼
      Opus
架構設計、邊界、拆工單、高風險判斷
        │
        ▼
    DeepSeek
大量施工、CRUD、Runner、CLI、Logging、測試補齊
        │
        ▼
測試 / fresh-context verification
        │
        ▼
      Opus
最終 review、仲裁、必要時打回施工

這不是一張永遠不變的模型名單。哪天有更合適的模型，直接換掉就好。真正不能亂的是交接規則：誰可以做決定、誰負責施工、誰不能驗自己、什麼結果才算可以往下一步。

四種模型，放在不同位置

• Opus：我把它留給架構、核心抽象、拆工單、衝突仲裁與最後 review。這些地方判斷錯一次，後面所有人都會一起做錯。
• DeepSeek：最適合大量施工。CRUD、Runner、CLI、Logging、Persistence、測試補齊這種邊界清楚的工作，讓它持續做比一直叫 Opus 親自下場划算得多。
• Gemini：適合需求整理、長文資料吸收、研究與把混亂上下文整理成可以交接的文件。我會讓它先把需求說清楚，再交到下一棒。
• Luna：放在快速、低成本、需要大量來回的輕量任務，例如整理、檢查、分類與一些不值得佔用高階模型注意力的工作。

這些角色不是身份。今天 DeepSeek 變弱、Luna 變強，我就換位置；流程要穩，模型不需要神聖化。

最關鍵的設計：驗證不自驗

這是我從第一個專案就死守的鐵則，也是整個工作流品質的來源：

自己寫的碼，不能自己驗。

聽起來很違反直覺——「我自己寫的，我不驗誰驗？」但重點是：寫的人會對自己的錯誤免疫。寫的人會不自覺地重跑「他以為在驗」的測試，但測的其實是同一條他早就確定沒問題的路徑。

所以我規定：寫程式的人 永遠不能驗自己寫的那塊。要嘛交給另一個 fresh-context 代理（完全不認識這份程式的人）驗，要嘛實跑測試驗。驗收結果逐筆記錄，留下軌跡。

測驗策略：免費跑量，錯誤摘要 <5 行

測試是整個工作流裡最大的「量」，也是成本最容易失控的地方。我的策略：

1. 全部用免費的 subprocess 跑——pytest 直跑，零 token 消耗；
2. 失敗摘要限制在 5 行以內——失敗訊息太長就截斷，只把重點餵回 context，避免把整個測試輸出倒進對話，浪費 token 又淹沒重點；
3. 重跑前「把失敗當作最有價值的訊息」，先看失敗軌跡再動手。

踩過的坑：代理把「看起來完成」當成「真的完成」

便宜代理最危險的不是錯，是**「看起來很像對」**。

舉例：我派廉價代理「把 X 功能完成」，它跑了一輪測試全綠就回報「完成」。但測試全綠，是因為測試本身寫得太弱——它可能根本沒測到主流程，或者測的是自己剛寫的假資料。

所以「驗證不自驗」不只是鐵則，它是防呆：驗收必須由不寫那份程式的人做，而且驗收要看「這測試到底測了什麼」，不是「綠不綠」。

結果：466 條測試，真的擋住過問題

Learning Hub 最後有 466 條離線測試，而且不是裝飾品——真抓到過 bug，例如「舊題目版本被誤當新題目發布」這種邏輯錯，就是測試先抓到的，而不是使用者。

當一個系統的測試數量能上千、又全部免費跑，品質保證就不再是「靠一個人小心」，而是靠流程。

這套工作流的錢花在哪

到目前為止，整年的 AI 預算控制在兩萬台幣以內：

• Opus：留給架構、仲裁與最後 review
• Gemini / Luna：吸收脈絡、研究、整理與大量輕任務
• DeepSeek：承接大量可驗證施工
• pytest / Vitest / ESLint 等測試：能不用模型就不用模型

關鍵不是「哪個模型最強」，而是「這個節點到底需要多少判斷力」。模型只是可替換資源，流程才是資產。