多 agent 工作流存在的理由，從來不是能力問題，而是經濟問題。
恆春有九家民宿需要直訂網站。問題不是正式品質的軟體是否做得出來，而是在民宿這個規模的成本結構裡，做得出來是否划算。一個配齊 PM、架構師、設計師、資深工程師、QA 的開發團隊，每月燒錢的速度遠超過一個直訂網站頭一年多帶回來的收入。這就是 OTA 還在主導市場的原因——不只是因為它們有龐大的廣告預算和多年累積的品牌信任，也因為 OTA 旗下每一個掛牌物件背後，都有專業的數位行銷團隊全職運營。直訂端沒有等值的東西。
Multi-agent pipeline 是我讓一個人跑完 PM、架構、工程、QA 四個角色的方法。每個角色是不同的 agent，有不同的立場，配對一個持相反觀點的對手。輸出的品質是真實的。成本是 Wayne 加上 Claude。這在 AI 出現之前，對這個規模的客戶來說根本不存在——現在它存在了。
五個階段，六個強制停頓
流程分五個階段：PM、Architect、Designer、Engineer、QA。大多數階段跑配對 agent——alpha 和 beta 各自獨立產出，再辯論、收斂。每個階段結束我就停下來讀輸出。這不是儀式，而是整條 pipeline 唯一的錯誤修正機制。
PM 階段。 pm-alpha 和 pm-beta 各自寫一份 PRD。它們幾乎必定意見不合——不是在解法上，而是在問題定義本身：哪些用戶最重要、優先考慮哪種失敗模式、哪些限制是真實的而不是假設。讓它們互相辯護，最後合出的版本比任何一份草稿都精確。那些藏在字裡行間的假設被迫說清楚，邊緣情境在任何人碰 schema 之前就被逼出來。
Architect 階段。 architect-alpha 優先考慮架構正確性與 clean architecture；architect-beta 優先考慮簡單與可交付性。兩者在同一份輸入上對峙，這種張力是有生產力的——被迫為每一個抽象辯護，它們一起把原本不會說出口的取捨逼到台面上。
Engineer 階段。 Engineering 不是配對，是分層：alpha 做 domain types 和 Zod schemas，beta 做 infra 和 queries，gamma 做 presentation。但在所有人動工之前，alpha 先跑依賴分析，列出每個工程師實際需要的檔案和型別定義，建立正確的執行順序。
engineer-alpha: 依賴分析 → domain 層（types、entities、schemas）
engineer-beta: infra + queries（依賴 alpha 的 domain types）
engineer-gamma: pages + components（依賴 beta 的 query 回傳型別）沒有依賴分析這個步驟，我一再看到 gamma 引用 alpha 還沒寫出來的型別。不是 agent 行為的問題，是沒有人維護「現在到底存在什麼」這個共享視圖。
QA 階段。 qa-alpha 跑使用者旅程：像真實的人一樣在介面上移動，切換語系，走遍內容列表頁。qa-beta 做架構合規性與邏輯分析——確認實作與規格相符，確認明顯的邊緣情境沒有被遺漏。兩者在出最終報告前互相 review。
關卡是唯一重要的事
Agent 不會懷疑輸入的正確性。它們忠實地執行輸入。
PM 錯了 10%，Architect 把錯誤放大進架構設計。到了 Engineering，正在建的東西已經偏了，但沒有任何 agent 知道。它們在認真處理拿到的輸入；問題不是執行層面的失誤，而是一個沒被攔截的規格錯誤一路走到這裡。這個偏差唯一會現形的時機，是有人帶著「我真正想要什麼」的知識去讀輸出。在這個 pipeline 裡那個人是我，而唯一能動用這個知識的時間點是關卡。
我用代價學到這件事。有一次為了加速，我跳過了 PM 到 Architect 的審查關卡。兩個 architect agent 拿到同一份 PRD，裡面有一句話說得不清楚——session 怎麼識別。alpha 做了一個假設，beta 做了另一個假設。兩者各自建了一套完整、內部邏輯自洽的架構，然後信心十足地收斂——收斂在根本合不起來的 schema 上。等我讀到輸出，context budget 已經燒完了。
動工前讀那份 PRD 三十秒就能抓到。那句話是可見的，我只是選擇不看。
跳過一個關卡，不只是省了時間。而是移除了那個階段唯一的錯誤攔截機制，讓問題帶著後續每個階段的成本往前走。
收斂不等於正確
配對 agent 意見不合、必須互相辯護的時候，輸出品質明顯更高。用不同的框架詮釋同一個問題，逼出了本來會是暗數的假設。
危險在反面：兩個 agent 在錯的方向上收斂。兩條獨立的推理鏈走到同一個結論，會產生強烈的「這件事解決了」的感覺。而收斂帶來的那種信心，正是危險所在。兩個 agent 都很有把握的時候，那正是應該再讀一遍的時候，不是繼續往前的時候。
Build 過了是個很低的門檻
npm run build 過了。npm run test 過了。我 commit 了。
然後 qa-alpha 用真實使用者的方式走過 zh-TW 路由，發現頁面標題還是英文。qa-beta 發現精選文章卡根據語系顯示錯誤的日期格式。這兩個問題都不會讓 build 失敗，型別系統也看不到。它們只在有人真的在網站上移動時才會現形——大約三十秒的操作就能發現。
這是型別系統、build assertions、單元測試在結構上就觸及不到的那種缺陷。只有整個系統運轉起來、有真實資料、被一個知道正確長什麼樣子的人實際操作，問題才會出現。
慢三到四倍，但慢在對的地方
跑一輪完整流程——PM 到 QA——大概是直接叫單一 agent 實作的三到四倍時間。這幾乎全集中在 PM、Architecture 兩個階段和關卡停頓上。Engineering 本身的速度差不多。
這個比例是結構在運作，不是副作用。Engineering 在一份被兩輪辯論挑戰過、被我讀過的 spec 上動工。一個 agent 寫完 PRD 直接寫 code，輸入沒有被壓力測試，出來的東西普普通通。兩個 agent 辯論 PRD、我讀、兩個 agent 在此基礎上辯論架構、我讀、Engineering 在驗證過的地基上動工——品質在每個階段複利，光靠把更多 agent 加進同一個平行流程做不到這件事。
讓每個階段為它交給下游的東西負責，才是重點。
被保留下來的東西
整套設定後來抽成可重用模板（my_ai-coding-template）——agent 定義、workflow 規則、流程文件、分支政策，以及一組全域安裝的 Claude Code skills。新專案一個指令就能 bootstrap。第一個之後的下一個專案馬上省回幾小時，再之後的更多。
這個模板現在已實際用於三個生產環境的民宿網站。Agent 定義是一等公民的程式碼——它們定義了編輯聲音、架構哲學、QA 標準。Pipeline 出錯的時候，修復寫進 agent 定義，不只是修輸出。
Pipeline 唯一做不到的，是告訴你做的是不是正確的東西。那個判斷仍然完全是人的工作。