一個跨三個 microservice 的 bug，花了我三小時才定位——不是因為技術特別難，而是因為一個 AI 對話窗裝不下所有脈絡，這就像一個偵探推開門，走進一團混亂的案發現場
Log 散落一地像血跡噴濺，error message 互相矛盾，三個 microservice 同時出問題，每條線索都指向不同的嫌犯，這不是小偷竊案，這是一樁精心佈局的連環命案
偵探只有一個人，他得搜集證據、審問嫌犯、做鑑識分析、寫結案報告——全部自己來
這就是我去年用一個 Claude 對話窗做所有事的感覺
獨行偵探的困局
一開始效率很高，讀需求、寫程式、跑測試、review 自己的 code、回應客戶問題——全部在同一個對話窗裡搞定
但隨著案件越來越複雜，問題開始浮現
想像一個偵探把所有證據堆在同一張桌上，現場照片、指紋報告、證人筆錄、監視器影片、通聯記錄，桌子越來越滿，他翻找早期的關鍵證據時，不小心把它壓到最底層，然後忘了它的存在
AI 對話窗也是這樣，上下文有容量限制，當你把需求分析、程式碼、錯誤訊息、review 意見全部塞進去，AI 開始「遺忘」早期的脈絡，回應品質逐漸劣化，就像偵探在第七十二小時不眠不休後開始產生幻覺
但最致命的問題不是記憶力，而是盲點
自己寫的供詞，自己看不出破綻
偵探界有一條鐵律：不能讓同一個人既搜證又做結論，因為人會傾向確認自己的假設，你認定是 A 幹的，所有模糊的證據在你眼裡都長得像 A
AI 也一樣，同一個 AI 寫了 code，再讓它 review 自己的 code——它傾向確認自己的判斷，看不見自己的盲點
這不是 AI 的缺陷，這是任何思考系統的本質限制，自我審查的效果永遠比不上外部審查
你自己的 code 自己看不出問題，同事一眼就看到了，偵探自己寫的報告自己覺得無懈可擊，檢察官一翻就翻出三個漏洞
案件之所以被偵破，從來不是因為某個人特別天才，而是因為不同角色的目標互相制衡，搜證人員只管蒐集，不管有罪無罪，鑑識人員只管分析，不管誰是嫌犯，檢察官的目標和辯護律師對立，這種張力，讓真相更容易浮出水面
軟體公司的 PM、工程師、QA、設計師也是這個邏輯——每個角色的「成功定義」都不一樣，這種制衡反而讓產出更健全
多 Agent AI 工作流，就是把這套辦案邏輯搬進 AI 世界
組建偵探小隊
我把 AI agent 分成三種角色，對應辦案的三個階段：
偵察組（Scout Agent）
他們是最先抵達現場的人，任務：讀 codebase、分析 git 歷史、整理 issue 狀態、回報哪裡有風險，他們只勘查，不碰證據，不做推論，就像鑑識小組在現場拉封鎖線、拍照、採集指紋——只觀察，不行動
行動組（Executor Agent）
根據偵察報告出手，寫程式、修 bug、建立測試，關鍵是：行動組收到的情報是被精簡過的——他只知道這次任務相關的資訊，不需要知道案件的全部歷史，上下文小，動作反而更精準，就像拆彈小組只需要知道炸彈的位置和類型，不需要知道嫌犯的童年
督察組（Reviewer Agent）
他們的目標是「找問題」，他們不在乎 code 怎麼來的，不知道行動組做了什麼決定，他們只看最終結果，挑漏洞、抓邏輯錯誤、確認安全性，督察組和行動組的目標是對立的——一個要結案交差，一個要雞蛋裡挑骨頭
這種對立是刻意設計的，就像警局的內務督察，存在的意義就是不信任
三種辦案模式
有了小隊，接下來是指揮調度
直接出手（1-3 步的小案）
停車罰單不需要出動專案小組，改一個 CSS 顏色、更新一行設定、回答一個問題——直接做就好，把它拆成三個 agent 來處理，就像派十個偵探去調查一起腳踏車失竊案，純粹浪費資源
平行出擊（獨立的並行任務）
十個專案需要同步狀態，這十個任務互不相干，可以同時派出十個偵察組各自去查，最後把線報匯整回來，這不是讓偵探更聰明，而是讓他們同時出動
組隊協作（牽一髮動全身的任務）
後端改了資料庫結構，前端會受影響，這種案件不能各查各的——後端偵察組發現的線索，前端行動組必須知道，才能做出正確判斷，這就像跨轄區的聯合辦案：不只是分工，而是真正的情報共享，A 組的發現會改變 B 組的行動方向
破案實錄
一個具體的案件：生產環境的功能 bug
舊的辦案方式（獨行偵探）：
我在一個對話窗裡描述 bug，貼上 log，請 AI 分析，AI 給了一個推論，我照著試，不對，再貼新的 log，AI 修正推論，來來回回之間，對話越來越長，早期的關鍵線索被埋到最底層，偵探在自己的筆記本裡迷路了
新的辦案方式（偵探小隊）：
偵察組先去讀 log 和相關程式碼，提交一份偵察報告：根本原因、影響範圍、建議方向，行動組根據這份報告寫修法——他的上下文只有這份報告和相關檔案，乾淨俐落，督察組獨立審查修法，他不知道前兩組說了什麼，只看 code 本身
三層把關，每一層都有乾淨的現場，不受其他階段的干擾，案件從受理到結案，每一步都有獨立的視角
陷阱：十個偵探搶一條線索
我見過一種迷思：既然三個 agent 比一個好，那十個一定更好
不，十個偵探擠在同一個案發現場，互相踩腳印、污染證據、搶著審問嫌犯，成本爆炸，速度反而變慢，而 agent 之間的協調本身就是新的複雜度來源，每多一個 agent，你就多了一個需要管理的「腦袋」，多了一個可能出錯的環節
不要為了一張停車罰單出動十個偵探
實際原則：用最少的 agent，完成最多的工作
判斷要不要組隊，問自己兩個問題：這個任務真的需要不同目標的角色嗎？這些任務真的需要平行或互相協作嗎？如果答案是否，直接出手，別組隊
2026：偵探之間開始說同一種語言
一件事正在悄悄發生：AI agent 之間的通訊協定正在標準化
過去，不同的 AI 工具是各自為政的孤島，每個工具有自己的證據格式、報告模板、溝通方式，要讓它們協作，得寫大量的翻譯程式碼
現在有些標準開始出現——例如 Anthropic 的 MCP（Model Context Protocol）——讓 agent 能更容易地呼叫工具、讀取資源、互相傳遞任務，就像國際刑警組織建立了統一的情報交換格式——以前跨國辦案要靠人工翻譯，現在有共同語言
這是基礎設施層面的變化，就像 HTTP 讓不同的網頁伺服器可以用同一種語言溝通，MCP 這類 agent 通訊協定的標準化讓多 agent 系統從「高手的獨門技術」變成「人人都能用的辦案工具」
結案陳詞
多 Agent AI 工作流不是什麼花俏的技術展示，它解決的是一個很具體的問題：一個偵探忙到失去判斷力，而且永遠看不見自己的盲點
分工的邏輯我們其實都懂，警察局裡的偵查、鑑識、督察本來就是這樣運作的，公司裡的 PM、工程師、QA 本來就是這樣制衡的，把這個邏輯搬到 AI 世界，你得到的是一個更可靠、品質更穩定的辦案流程
不需要記住任何設定，先記住這個概念：
一個偵探寫報告，另一個偵探審查，第三個偵探驗證，三層把關，各司其職
這是 2026 年 AI 輔助開發的基本辦案守則
Young Tsai 是一個 AI 接案開發者，同時管理 15 個不同客戶專案，寫這些文章是為了把實際踩過的坑和發現的東西記下來