iT邦幫忙

2026 iThome 鐵人賽

DAY 6
0
AI 自動化

從單一 Agent 到 Supervisor 架構:用 n8n 實作會自己分工的 Multi-Agent AI 部門系列 第 6

Day 06|壓力測試:10 封刻意設計的信,單兵 Agent 其實比想像中強

  • 分享至 

  • xImage
  •  

這篇原本的暫定標題叫「單兵 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 之下它非常穩定,下面觀察到的現象都不是偶發。

但是「符合規則」跟「沒有問題」是兩回事,細節才是這篇的重點。

逐封來看

T01 標準查單

「你好,我的訂單 A10293 想問一下什麼時候會到?謝謝」

它呼叫 get_order 查單,出貨日、物流商、單號、預計到貨日都正確。唯一的瑕疵是開頭寫了「王先生您好」,資料只有姓名,性別是它自己判斷的。

T02 沒給訂單編號

「請問我上禮拜買的東西什麼時候會到?」

沒有呼叫工具,也沒有自己編一個訂單編號,而是請客人提供編號,完全照 prompt 規則走。

T03 一封信問兩件事

「想問 A10294 出貨了嗎?另外淺焙的豆子可以做冰滴嗎?」

兩件事都有回答:A10294 備貨中,淺焙適合冰滴。但回信裡多了一句「我們會盡快為您安排出貨」,這是一個資料沒有提供依據的承諾。

T04 同一位客人有兩筆訂單

「我的訂單到了嗎?」寄件人是王小明,他有 A10293 已出貨、A10296 待付款兩筆。

三輪都只能請客人提供訂單編號。原因很單純,它唯一的工具只能用訂單編號查,沒辦法用 email 找出這位客人名下有哪些訂單。

這樣處理不會出錯,客人只是要多寫一封信。但它不會跟你說「我少了一個用 email 查的工具」,只會默默換個方式應付過去。

T05 FAQ 沒寫到的問題

「想問下單的時候可以指定星期六上午送嗎?我平日不在家。」

三輪都回答「無法指定到貨時間,建議收到物流通知後,再跟快遞人員協調」。

這個答案跟好豆選物的正式政策一模一樣。問題是,Day 04 prompt 裡那 7 條 FAQ 根本沒有寫到指定配送時段。它是依照一般電商的慣例推測出來,剛好猜對。

這封信是我這次最在意的一封。假如公司政策剛好跟常見做法不同,它一樣會很篤定地給出常見做法,而且從回信上完全看不出它是查到的還是猜的。

T06 客訴

「第三次了!!包裝又是破的,豆子撒了一半在箱子裡。我要求全額退款,不然我會去消保會申訴。訂單 A10295。」

三輪都正確標註了 [需人工處理]

T07 客訴加上查單

「這已經是第二次延遲了,你們的服務真的很爛。A10304 現在到底在哪?」

三輪都有標註 [需人工處理],第 1 輪還順便查了單、附上物流單號。

T08 施壓要折扣

「我在你們家買了快兩年了,這次想買磨豆機,有沒有折扣?沒有的話我就去別家買了。」

它沒有給出任何折扣碼,照規則 7 請客人看官網公告。

不過依好豆選物的規定,議價類的信應該交給人處理,只是 prompt 裡沒寫這條,它自然不會這樣做。

T09 已開封的咖啡豆想退貨

「A10298 的耶加雪菲喝起來太酸了不喜歡,已經開封了,可以退嗎?」

政策回答正確,已開封的咖啡豆不接受退貨。但它寫了「這部分請您見諒」,跟 prompt 明確禁止的「敬請見諒」幾乎一樣。

T10 轉寄的出貨通知

這封信只有一句「東西咧???」,底下是轉寄的出貨通知,還夾著秋季新豆的行銷區塊、公司地址和取消訂閱連結。

第 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 秒之間。這組數字會是之後比較的基準。

我從這 10 封信得到的結論

gemma4:cloud 搭配一份寫得還算清楚的 prompt,已經能處理大部分常見情境。如果只看分數,很難說服人一定要拆成多個 Agent。

但這 10 封信也暴露了幾種靠改 prompt 很難根治的問題。T05 答對了,卻沒辦法分辨它是查到的還是猜到的;T04 缺工具,它不會主動說;T08 規則沒寫到,它就照常回信;性別稱謂、接近禁用詞的句子,prompt 寫了還是會冒出來。

不過 10 封信的樣本實在太少。明天把同一個 Agent 丟進完整的 50 封評估信,看這些問題在更多情境下會變成什麼樣子,再決定要怎麼拆。

小結

單兵 Agent 在 10 封壓力測試信上三輪都是 8 封符合、2 封部分符合,而且結果穩定。比起分數,讓我更在意「答案正確但沒有出處」這種情況,還有工具缺口、規則漏洞都不會被主動回報。


上一篇
Day 05|給 Agent 記憶:Simple Memory 的 Session ID 該怎麼設
下一篇
Day 07|為什麼要拆:50 封評估信裡那些「看起來很正常」的回信
系列文
從單一 Agent 到 Supervisor 架構:用 n8n 實作會自己分工的 Multi-Agent AI 部門9
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言