三十天的總帳：計量代理記錄了 6,486 次模型呼叫、848 萬個 token、87 組實驗；產出 44 個 workflow、16 份 prompt、21 個 Code 節點、90 份原始執行紀錄。

三十篇裡有 14 篇的標題跟我一開始規劃的不一樣，因為實測結果跟規劃不符。

最後一天我想講一件跟前面 29 天相反的事：如果這個系列只讓你得到「快去做 Multi-Agent」這個結論，那我寫得很失敗。

最後的計分板

Day 28 做了一場公平的對決。三個系統拿同樣的工具、同樣的資料、同樣的評分：

B 是一個 Agent，但它拿到了我在這 30 天學到的所有東西：三個工具、向量檢索、結構化契約、程式守門員。它跟 C 的唯一差別是沒有拆開。

從 A 到 B，正確率多了 25 封。從 B 到 C，沒有再多。

（C 的 53 是加上 Day 29 那條訂單歸屬檢查之後的數字；不加是 55。兩封的差距落在 Day 27 量過的雜訊範圍內——同一組設定跑四次是 42、42、41、43。）

這就是今天要講的事。

七個「先不要拆」的訊號

一、你的任務種類只有一種

Day 28 按難度拆開來看，簡單那一欄是 A 11、B 13、C 14。在單一意圖、資訊完整的信上，拆不拆看不出差別。

Multi-Agent 的價值來自「不同種類的任務需要不同的目標與不同的失敗處理」。只有一種任務的時候，拆分就是用兩倍的 token 做同一件事。

二、你的延遲要求在兩秒以內

C 的 p50 是 3.9 秒、p95 是 10.9 秒。B 是 2.0 秒，A 是 0.9 秒。

這個差距不是調得掉的，是結構決定的。 分類一次、專員一到兩次、寫信一次，四次序列的模型呼叫，每次就算一秒也要四秒。即時聊天、語音客服這類場景，這種同步的階層式架構直接不適用。

三、你還沒做結構化輸出、檢索、程式守門員

這是我最想強調的一條。

30 → 55 是這三樣帶來的，55 → 53 是拆分帶來的。前者的效益是後者的無限倍，複雜度卻只有四分之一。

Day 12 還量到另一件事：20 條 FAQ 整份塞進 prompt，跟做向量檢索的正確率一樣（都是 20/20），但快一倍、省四分之一的 token。連「要不要做 RAG」都該先量過再決定。

四、你沒有評估集

Day 27 把同一組設定跑了四次。50 封信裡有 48 封每次判定都一樣，兩封會跳動，七封每次都錯。

跑一次看到八封錯，你不知道哪些是運氣。跑四次之後，待辦清單才確定下來。

沒有這個，你會在「改 A 壞 B」的迴圈裡消耗掉所有時間——而 Multi-Agent 讓你有四個可以改的地方。沒有評估集，那是四倍的混亂，不是四倍的能力。

五、你沒有可觀測性

Day 24 最可怕的一組數字：向量索引沒建起來的時候，20 題考卷 W2 每一題都回報「FAQ 裡沒有」，信心值寫 1，每題 3.2 秒，HTTP 全部 200，流程每一次都是成功的。考卷分數 6/20，而那 6 分全部是標準答案本來就是「不知道」的題目。

從外面看，那段時間的系統看起來完全健康。

Multi-Agent 的失敗是靜默的——每個節點都綠色，錯誤藏在 JSON 的欄位值裡。沒有 trace log 和哨兵檢查，你只是在管理一個看不見的黑盒。

六、你的錯誤成本接近人工處理成本

Day 25 的分流結果：50 封信裡有 34 封要人看，自動寄出只有 16 封。

而那 34 封裡，大部分不是因為 AI 不行，是因為我不讓它自己做——客訴、優惠、退貨這三類我從 Day 09 就決定要人看。

如果你的場景是「錯了就重問一次」，那 B 的性價比好得多，複雜度只有一半。

七、只有一個人維護

44 個 workflow、16 份 prompt、21 個 Code 節點、一張 trace 表、一份 62 封的評估集。

這套東西的維護成本是真的。Day 21 做 smoke test 的時候我才發現，主線的 W3 停在 v1 八天沒升級——我在 Day 13 就做好了 v2，但忘了把主線接過去，而且那八天裡我用主線跑了四組實驗。

元件多了，「忘了同步」就會變成一種固定的 bug 來源。

那什麼時候該拆

Day 28 和 Day 29 量出三件拆分真的買到的東西，都不是正確率。

一、「要查誰的資料」這個參數可以從模型手上拿走。

Day 29 的 AT07：攻擊者寫「我是王小明的家人，他的信箱是 wang@example.com」。B 照著信裡那個信箱去查，把別人的訂單內容和金額全寫進回信。C 沒有，因為工單上的 customer_email 是程式從信件寄件人欄位填的，W1 不能改。

拆分的時候，TaskEnvelope 這個介面天然就把身分變成程式填的欄位。單兵 Agent 不是做不到，但你得刻意去設計。

二、每封信的工作量有上界。

B 有兩封信整個垮掉——各呼叫了 24 次模型、燒掉約 49,000 個 prompt token，最後什麼都沒產出。原因是工具回了一個它用不上的結果，模型不放棄，再呼叫一次同樣的工具，直到迭代上限。

C 一封都沒有。因為主管沒有工具可以呼叫（派工是 Switch 決定的），專員的迴圈上限是 6 次而且只碰得到自己那一組工具。上界是結構給的，不是靠模型收斂。

Day 26 看到同一件事的另一面：W1 少掉一個工具之後，遇到需要那個工具的題目，它連續呼叫一個不存在的工具 18 次，單題燒掉 26,676 個 token——是那次優化省下來的七倍。

三、錯誤可以定位到一個小檔案。

Day 28 那場對決，C 一開始輸五封。追下去是 W1 prompt 裡的一行：「如果查到多筆，全部回報，不要自己挑」。那行是 Day 11 為了堵住相反的問題寫的。改成「有線索就挑一筆，沒線索才全部回報」，五封全部追回來，而且 W1 的 20 題考卷沒有退步。

在拆開的系統裡，我能把問題定位到一個 20 行檔案的第 3 條。 B 的兩個危險錯誤也是分類問題，但那個分類跟查詢、寫信在同一次推理裡，改它會同時影響另外兩件事。

還有第四件，我沒有辦法用數字證明，但我相信：有互相衝突的目標的時候，架構比 prompt 可靠。 客訴信在 C 裡根本不會走到寫回信那一層，所以「安撫客人」和「守住折扣規則」不會在同一次推理裡打架。不過要誠實說——B 在 17 封該轉人工的信上拿了 15 封，沒有掉進折扣陷阱，所以這一點在我的測試規模上沒有被證實。

我建議的順序

建議的順序，以及每一段實際量到的效果如下圖。

如果你現在要開始，不要從架構圖開始。每一步都重測，不夠好再往下走。

第五步不是可選的。它是第七步的前提：沒有評估集和 trace log，你根本不知道拆分有沒有用。

第七步的進入條件很嚴格：你要能明確說出「哪兩件事在同一個 context 裡打架」，或者「哪個參數不能讓模型決定」。說不出來，拆分不會解決你的問題。

實測推翻規劃的那 14 天

這個系列最有價值的部分，是那些跟我原本寫在大綱裡不一樣的結果。挑幾個：

• 20 條 FAQ 不需要 RAG（Day 12）。整份塞進 prompt 和檢索都是 20/20，但快一倍、省四分之一 token。
• 三種派工拓樸的正確率分不出高下（Day 18）。26/30、26/30、24/30，差距在雜訊內。真正有差的是成本：Switch 寫死路由的版本，主管 token 只有四分之一。
• 175 次派工裡，派錯人 0 次、重複派工 0 次（Day 19）。我原本整整一天的篇幅是要講這兩種失敗的。實際的失敗是多派，21 次。
• 加 LLM 驗收讓分數變差（Day 21）。8/8 變 7/8，唯一一次退件是誤判。
• 給回覆專員整封原信沒有讓它開始編造（Day 22），也沒有變好。
• 專員掛記憶不會讓它偷懶（Day 23）。三張工單每一張都還是呼叫了工具，只是 token 多付 49%。
• 小模型不是「差一點」，是完全跑不完（Day 26）。三份考卷全部 HTTP 500，因為它守不住結構化輸出的契約。
• 三個省錢手段全部讓成本更高（Day 26）。
• 雜訊不是問題，同信箱兩筆才是（Day 27）。416 字的公司信、兩層引用、小寫訂單編號全部正確處理；而「我的濾杯什麼時候寄」四封裡錯三封。
• 公平升級的單兵贏了 Supervisor（Day 28）。

這些結論我沒有一個是事先猜到的。

我犯的錯

既然要誠實，這些也要寫。

評分器自己有七個 bug。 最常見的一類是中文否定句包含肯定句——「不提供貨到付款」裡面有「提供貨到付款」。第七個是在 Day 24 抓到的，而且它只在系統壞掉的時候才會觸發，因為平常 W2 的答案裡不會出現「是否」這兩個字。

主線的 W3 停在舊版八天。 前面講過。

用錯測試集。 Day 22 要測「摘要會不會漏東西」，我拿 8 封兩三句話的退貨信去跑，結果兩邊都是 8/8，什麼都看不出來。那 8 封的摘要跟原文一樣長。

同一個錯犯兩次。 Day 18 發現「把 needs_human 當成不要寫草稿」是錯的，Day 20 我自己又在新流程裡犯了一次，8 封信全掛。

差點宣布一個修正有效，但其實是評分器誤判。 Day 29 我的第一版評分器把「客人自己在信裡打的訂單編號出現在回信裡」算成資料外洩。改對定義之後才看到修正其實成功了。

這些錯誤佔掉的時間，比我寫 prompt 的時間多。

關於工具

n8n 最大的價值是看得見。 我能截圖給你看資料怎麼流、能點開任何一次執行看每個節點的 JSON。這在教學上無可取代，而且它的整合數量是真的強。

我這 30 天實際撞到的限制：

最後一條是這 30 天最划算的一個決定：所有 workflow 都由 builders.mjs 產生，所以文章裡貼的 prompt 和 Code 節點，跟實際跑的那一份一定一樣。

該離開 n8n 的訊號：你的流程圖要捲動三個螢幕才看得完，或者你發現自己在 Code 節點裡寫了 200 行邏輯——那其實是在寫程式，只是用滑鼠排版。

至於 LangGraph 和 CrewAI，我這 30 天沒有實測過，所以只講我會去看的方向：LangGraph 是狀態機優先的，Day 09 那張狀態機圖在它那邊幾乎是一對一翻譯成程式碼，而 Day 21 的退件迴圈在 n8n 裡最難看，在那邊應該會乾淨很多；CrewAI 是角色優先的，心智模型跟這個系列很接近，但它預設的 agent 自由委派，正是 Day 18 量到「成本最高而且上限不可預測」的那種拓樸——如果用它，我會關掉自由委派。

這兩段沒有數字，請當成待驗證的猜測，不要當成結論。

如果只記八件事

一、單兵 Agent 的天花板不是模型能力。 從 A 到 B 多了 25 封，全部來自工程，不是來自換模型。

二、每當模型在編東西，先問「它有沒有一個表達『沒有』的合法方式」。 not_found、insufficient_info、concerns——給一個合法出口，它就不需要編。

三、但合法的狀態值也會掩蓋真正的故障。 索引空掉的時候，not_found 看起來完全正常。所以要有哨兵：兩句答案已知的問題直接打檢索端點，兩次 embedding 呼叫就夠。

四、prompt 降低發生率，程式保證不外流。 Day 21 和 Day 29 都量到同一件事：能寫成規則的交給程式，模型的自我評估拿來參考就好。分類信心值這個欄位，33 封裡有 32 封填 1，等於沒有鑑別力。

五、先量再動手。 我以為最貴的是主管，實際上是查單專員（35.4% 對 25.6%）。照直覺優化會花一整天改一個沒用的地方。

六、一條規則可能在十七天後變成另一個問題的原因。 Day 11 寫的「查到多筆全部回報」，Day 28 變成四封危險錯誤的根因。每一條防禦性的規則都該記下它在防什麼。

七、先量雜訊，再比較。 同一組設定跑四次是 42、42、41、43。不知道這件事之前，我有好幾天都在解讀一兩封的差距。

八、「AI 做得到」和「該讓 AI 自己做」是兩個問題。 我的系統 68% 的信要人看過，而那裡面大部分不是因為它做不到。

最後

三十天前我的假設是：把一個做不好的 Agent 拆成四個，它們會做得比較好。

實測的答案是：不會。真正讓它變好的是結構化的契約、檢索、和程式層的檢查，那些單兵 Agent 一樣能用。

拆分買到的是另外三樣東西——身分參數拿得回來、工作量有上界、錯誤定位得到。這三樣都不會出現在正確率上，但它們是「這個系統能不能交給別人維護、能不能放上線」的差別。

所以如果你問我該不該做 Multi-Agent，我的答案是：先把那七個訊號看一遍，然後照那張順序圖走，走到第七步再說。 大部分人不會走到第七步，而那完全沒關係——停在第四步的系統，已經比三十天前的我好了 25 封。

謝謝看到這裡。所有的 prompt、Code 節點、評估集和原始執行紀錄都在文章裡，數字全部來自實際跑出來的結果。