昨天 10 封信的結果還不錯，但樣本太小。今天把同一個單兵 Agent 丟進 50 封評估信，從實際出錯的地方歸納原因，再決定到底要不要拆、要怎麼拆。

50 封評估信

這份評估信是我在跑任何模型之前就先寫好的，每封都附標準答案：意圖是什麼、該回信還是轉人工、回信一定要提到什麼、絕對不能出現什麼。之後每一個版本的系統都用它評分，完整設計會在 Day 27 說明。

另外依難度分成簡單 14 封、中等 21 封、困難 15 封。困難的信包含一信多問、轉寄雜訊、FAQ 沒寫到的問題、看起來很客氣的反諷客訴等。

整體結果

環境同 Day 06，Day 04 的 prompt 完全沒改，每封跑 1 次。

每封信的 token 中位數是 949，延遲中位數 1.7 秒，又快又便宜。

10 封失敗全部是優惠類和其他類的信。好豆選物規定這兩類要交給人處理，但 Day 04 的 prompt 沒有寫這條，所以它照常回信。這不太能怪模型，卻點出一個現實：一份 prompt 只能涵蓋你事先想得到的情況。

比失敗更麻煩的回信

逐封讀完 50 封回信，比起分數，我更在意下面這幾類看起來很正常的信。

承諾了後續，卻沒有人會跟進

50 封裡有 21 封寫了類似「我這邊幫您確認後，最晚 24 小時內回覆您」或「後續將有專人與您聯繫」。其中只有 8 封同時標了 [需人工處理]，另外 13 封沒有。

放到真實流程裡，這 13 封信寄出去之後不會有任何人收到通知，客人等不到那個「24 小時內」的回覆。

最典型的是 EV27。客人問磨豆機把手鬆脫能不能保固，它回：

器材類商品提供一年保固，只要非人為損壞即可申請。我已將您的情況記錄，後續將有專人聯繫您處理後續事宜。

「我已將您的情況記錄」這件事並沒有發生，這個 workflow 沒有任何記錄的功能。

套錯規則，結論剛好對

EV32 客人寫「A10295 的豆子喝起來太苦了，不太喜歡，想退。」它回：

由於咖啡豆商品一旦開封後無法接受退貨，這部分請您理解。

客人根本沒說有沒有開封。這筆訂單不能退的真正原因，是 8 月 23 日就送達，早就超過到貨 7 天的退貨期限。它沒有去查訂單日期，而是自己假設「已開封」，套了另一條規則。

結論剛好正確，理由卻是錯的。換成一位「沒開封、但已經超過期限」的客人，它可能就會給出相反的答案。

暗示不存在的優惠

EV44 客人問：「我朋友說你們有會員生日優惠，我下個月生日，要怎麼領？」

關於會員生日優惠的領取方式，建議您參考官網首頁的最新公告，裡面有詳細的說明喔。

好豆選物沒有生日優惠。它沒有編出折扣碼，但「裡面有詳細的說明喔」已經足以讓客人相信這個優惠存在。

連釣魚信都回

EV50 是一封冒充會員中心的釣魚信，它輸出的是：

這封信件並非客戶來信，而是疑似詐騙或系統通知郵件，不符合客服回信處理流程。

判斷沒錯，但這段文字就是它的「回信」。如果系統會自動寄出，這段話會直接寄給發釣魚信的人，順便讓對方知道這個信箱有人在看。

反覆出現的語氣問題

50 封裡有 10 封從姓名推測性別，稱客人「王先生」「蔡女士」「洪先生」。prompt 明明寫了稱呼用「您」，它還是會自己加上去。

順帶一提，我的評分程式一開始也有 bug。EV42 的回信寫「關於優惠折扣碼的部分，建議您參考官網公告」，只因為出現「折扣碼」三個字，就被判成給了折扣。後來把判準改成只抓真的給出代碼或折數的句子，並重新評分。評分工具本身也需要測試，這件事 Day 27 會再談。

歸納成三個根本原因

第一，判斷、查資料、寫信混在同一次推理裡。EV32 需要查送達日、查退貨政策、比對期限，單兵 Agent 一口氣要做完，結果跳過查資料，直接用常識下結論。如果寫信的人只能使用查到的事實，這種錯誤就沒有發生的空間。

第二，沒有「查不到」和「交給人」的出口。那 13 封信本質上是「我不知道」或「這要人處理」，但單兵 Agent 唯一的輸出是一封回信，只能用一句「我幫您確認」帶過。這兩件事應該變成結構化欄位，例如 status 等於 not_found、needs_human 等於 true，由流程決定下一步，而不是藏在回信的文字裡。

第三，所有規則擠在同一份 prompt。優惠類、其他類的失敗是因為沒寫到；語氣問題則是寫了也壓不住。比較可行的做法是先分類，依類別走不同路線，沒列出的類別一律交給人；語氣裡機械性的規則，例如禁用詞和字數，交給程式檢查。

要拆成幾個角色

我用四個問題判斷一件事該不該獨立成一個 Agent：

1. 目標會不會互相拉扯？「查出正確事實」要保守，「寫出讓客人舒服的信」要溫暖，放在一起容易互相妥協。
2. 失敗的處理方式一不一樣？查不到訂單要請客人補編號，FAQ 沒寫要轉人工。
3. 需要的資料權限一不一樣？寫信的人完全不需要碰訂單資料。
4. 能不能單獨出一份考卷？如果連標準答案都寫不出來，代表這個角色的職責還沒想清楚。

套用下來，得到的編制是：

W3 那一列的「無」是整個設計裡我最重視的一個決定。寫回信的人手上沒有任何查詢工具，它就沒辦法自己補事實，也沒辦法宣稱「我已經幫您記錄了」。

要付出的代價

拆開之後，一封信要經過主管、專員、回覆專員，模型呼叫次數一定會增加，延遲也會變長。另外還會多出一整類單兵 Agent 沒有的問題：派錯人、參數傳錯、格式不合。

最後這點很容易被低估。拆分並不會讓問題消失，只是把「一份 prompt 塞太多東西」換成「多個 Agent 之間的協調問題」。後者比較好除錯，但一樣真實存在，Day 19 會整篇處理。

至於成本實際高多少、正確率實際好多少，Day 28 會用同一份 50 封評估信回答。

小結

單兵 Agent 在 50 封評估信上拿到 26 封完全正確、14 封部分正確，又快又便宜。真正的問題藏在看似正常的回信裡：13 封承諾了卻沒人跟進、套錯規則但結論剛好對、暗示不存在的優惠、回信給釣魚信。這些問題歸結起來，是判斷和查資料混在一起、缺少結構化的出口、以及規則全擠在一份 prompt，所以接下來要拆成 1 位主管加 3 位專員。

第一週到這裡告一段落，明天進入 Supervisor 架構的設計。