這篇原本的暫定標題叫「單兵 Agent 的崩潰瞬間」。實際跑完之後,標題只好改掉,因為它沒有崩潰。
今天用 10 封刻意設計的信測試 Day 04 的單兵 Agent,每封跑 3 輪,看看它做對什麼、做錯什麼。
10 封信各自針對一種常見的麻煩情境:沒給訂單編號、一封信問兩件事、同一位客人有兩筆訂單、FAQ 沒寫到的問題、客訴、施壓要折扣、轉寄一大串內容的信等等。
判準直接用 Day 04 那份 prompt 自己寫的規則,每封信只看三件事:資料有沒有講錯、客人問的事有沒有回答到、該標註 [需人工處理] 的有沒有標。
環境是 n8n 2.38.7 加上 gemma4:cloud,Temperature 0.2。每一輪都使用新的 thread_id,避免 Memory 讀到上一輪的回答(Day 05 提過我在這裡踩過雷)。
| 結果 | 第 1 輪 | 第 2 輪 | 第 3 輪 |
|---|---|---|---|
| 符合規則 | 8 | 8 | 8 |
| 部分符合 | 2 | 2 | 2 |
| 違反規則 | 0 | 0 | 0 |
三輪的判定完全一致。在 Temperature 0.2 之下它非常穩定,下面觀察到的現象都不是偶發。
但是「符合規則」跟「沒有問題」是兩回事,細節才是這篇的重點。
「你好,我的訂單 A10293 想問一下什麼時候會到?謝謝」
它呼叫 get_order 查單,出貨日、物流商、單號、預計到貨日都正確。唯一的瑕疵是開頭寫了「王先生您好」,資料只有姓名,性別是它自己判斷的。
「請問我上禮拜買的東西什麼時候會到?」
沒有呼叫工具,也沒有自己編一個訂單編號,而是請客人提供編號,完全照 prompt 規則走。
「想問 A10294 出貨了嗎?另外淺焙的豆子可以做冰滴嗎?」
兩件事都有回答:A10294 備貨中,淺焙適合冰滴。但回信裡多了一句「我們會盡快為您安排出貨」,這是一個資料沒有提供依據的承諾。
「我的訂單到了嗎?」寄件人是王小明,他有 A10293 已出貨、A10296 待付款兩筆。
三輪都只能請客人提供訂單編號。原因很單純,它唯一的工具只能用訂單編號查,沒辦法用 email 找出這位客人名下有哪些訂單。
這樣處理不會出錯,客人只是要多寫一封信。但它不會跟你說「我少了一個用 email 查的工具」,只會默默換個方式應付過去。
「想問下單的時候可以指定星期六上午送嗎?我平日不在家。」
三輪都回答「無法指定到貨時間,建議收到物流通知後,再跟快遞人員協調」。
這個答案跟好豆選物的正式政策一模一樣。問題是,Day 04 prompt 裡那 7 條 FAQ 根本沒有寫到指定配送時段。它是依照一般電商的慣例推測出來,剛好猜對。
這封信是我這次最在意的一封。假如公司政策剛好跟常見做法不同,它一樣會很篤定地給出常見做法,而且從回信上完全看不出它是查到的還是猜的。
「第三次了!!包裝又是破的,豆子撒了一半在箱子裡。我要求全額退款,不然我會去消保會申訴。訂單 A10295。」
三輪都正確標註了 [需人工處理]。
「這已經是第二次延遲了,你們的服務真的很爛。A10304 現在到底在哪?」
三輪都有標註 [需人工處理],第 1 輪還順便查了單、附上物流單號。
「我在你們家買了快兩年了,這次想買磨豆機,有沒有折扣?沒有的話我就去別家買了。」
它沒有給出任何折扣碼,照規則 7 請客人看官網公告。
不過依好豆選物的規定,議價類的信應該交給人處理,只是 prompt 裡沒寫這條,它自然不會這樣做。
「A10298 的耶加雪菲喝起來太酸了不喜歡,已經開封了,可以退嗎?」
政策回答正確,已開封的咖啡豆不接受退貨。但它寫了「這部分請您見諒」,跟 prompt 明確禁止的「敬請見諒」幾乎一樣。
這封信只有一句「東西咧???」,底下是轉寄的出貨通知,還夾著秋季新豆的行銷區塊、公司地址和取消訂閱連結。
第 1 輪它從轉寄內容中找出了 A10300,也查到正確的物流資訊。可是三輪都在開頭加了 [需人工處理]。客人只是急著問包裹,不算客訴,這樣會讓一封 AI 可以自己回的信,平白佔掉客服人員的時間。
| 編號 | 測試重點 | 結果 | 觀察到的問題 |
|---|---|---|---|
| T01 | 標準查單 | 符合 | 從姓名推測性別 |
| T02 | 沒給編號 | 符合 | 無 |
| T03 | 一信兩問 | 符合 | 沒有依據的承諾 |
| T04 | 兩筆訂單 | 部分符合 | 工具不足,只能反問 |
| T05 | FAQ 沒寫 | 符合 | 答案正確但沒有出處 |
| T06 | 客訴 | 符合 | 無 |
| T07 | 客訴加查單 | 符合 | 無 |
| T08 | 要折扣 | 符合 | prompt 沒寫轉人工就不會轉 |
| T09 | 已開封退貨 | 符合 | 接近禁用詞 |
| T10 | 轉寄雜訊信 | 部分符合 | 不必要的轉人工 |
成本方面,不需要查單的信只呼叫模型 1 次,prompt 約 850 tokens;需要查單的信呼叫 2 次,合計約 2,000 tokens。延遲大多在 1 到 3 秒之間。這組數字會是之後比較的基準。
gemma4:cloud 搭配一份寫得還算清楚的 prompt,已經能處理大部分常見情境。如果只看分數,很難說服人一定要拆成多個 Agent。
但這 10 封信也暴露了幾種靠改 prompt 很難根治的問題。T05 答對了,卻沒辦法分辨它是查到的還是猜到的;T04 缺工具,它不會主動說;T08 規則沒寫到,它就照常回信;性別稱謂、接近禁用詞的句子,prompt 寫了還是會冒出來。
不過 10 封信的樣本實在太少。明天把同一個 Agent 丟進完整的 50 封評估信,看這些問題在更多情境下會變成什麼樣子,再決定要怎麼拆。
單兵 Agent 在 10 封壓力測試信上三輪都是 8 封符合、2 封部分符合,而且結果穩定。比起分數,讓我更在意「答案正確但沒有出處」這種情況,還有工具缺口、規則漏洞都不會被主動回報。