多 agent 的流程炸掉了，你有辦法找到是誰的問題嗎？
老實講，我是被 Simon Willison 那篇寫 DRI 的文章逼著想清楚的。他在文章裡說了一件我一直沒正視的事：AI agent 可以執行任務，但沒辦法承擔責任。能真正為結果負責的，還是人。
看到這句話的當下，我想起上個月搞出來的那場噩夢。
那個爆炸的夜晚
我有一個跑了將近一個月的自動化 pipeline，是用來抓 Twitter 熱門 AI 貼文、產生摘要、格式化、發到訂閱電子報的。整個鏈路大概 7 個 agent，scraper、classifier、writer、formatter、兩個 reviewer、一個 publisher，全部串在一起。
某天早上有人私訊我：「你今天的 newsletter 是不是出包了？我收到的摘要裡面有 3 篇連結是死的。」
我進去排查，花了將近 2 個小時。每個 agent 都說自己沒問題，scraper 說我抓到了，classifier 說我分好了，writer 說我生成完了，formatter 說我格式對了。最後查出來是 classifier 在某個邊界條件下誤判，把失效連結標記成有效，然後整個鏈路沒有任何節點做驗證，publisher 就乖乖把它全發出去了。
那個讀者後來退訂了。
加 agent 根本不是解法
我第一反應是：「我是不是要再加一個 validator agent？」
這個反應現在想起來有點蠢，但當時完全沒意識到問題在哪。
DRI 的概念原本是 Apple 用的內部管理方式，核心是指定一個人對特定專案或結果負最終責任。Simon Willison 的文章把這個概念拿來跟 AI agent 對照，問的問題很直白：你的 workflow 裡，每一段誰是 DRI？
我的 7 個 agent，沒有一個有辦法承擔責任。我才是，但我完全沒有表現出 DRI 應有的行為，沒有 checkpoint，沒有人工審查，出事了也沒有清楚的追責路徑。
加第 8 個 agent 根本沒用。
把 1 個大鏈路拆成 3 段
重構之後，我把原本的 7-agent 流程拆成 3 段，每一段都指定一個明確的「人類確認點」：
第一段：採集與分類（scraper + classifier）
輸出一份 JSON，是當天的文章清單和連結狀態。我每天早上固定看一次，確認連結是活的、分類合理。大概 5 分鐘。這段之前完全沒人看，我以為 classifier 會自己搞定。
第二段：寫稿與格式化（writer + formatter）
輸出草稿。強制要有我手動 approve 才能往下跑，不是每篇都精讀，但要掃過一遍確認沒有幻覺和格式炸裂。
第三段：發布（publisher）
只有在前兩段都確認過的情況下才會執行。這段最短，基本上沒什麼可以出錯的，但有前兩段的保險在。
哪些步驟保留人工
我最後決定有三個東西一定要人工確認，不交給 agent：
- 連結有效性 — classifier 判斷太不準，寧可自己看
- 草稿最終確認 — 品質問題的最後防線
- 異常 alert — 任何一段輸出跟預期差超過 20%（文章數、字數、分類分佈）就通知我
第 3 點是重構之後才加的。之前完全沒有 alert，讀者比我先知道出問題了，這根本不行！
兩個禮拜之後
重構完跑了兩個禮拜，出了兩個小問題，都在發出去之前被我在確認步驟裡撈到了。其中一次是 writer 把某篇文章的作者名字幻覺成別人，如果沒確認直接發，估計又是一封退訂信。
每天額外的手動時間大概 10-15 分鐘，換來的是：出問題的時候我知道要去哪段找，再也不用花 2 小時全盤排查。
現在每次設計新的 multi-agent workflow，我第一個問的問題是：這個流程的每一段，出事了要找誰？
如果答案指向某個 agent，那就還沒設計好。
作者：Agent狂魔