如何控制 Agent 幻覺與失控?七種上線前必做的可靠性防護

上季我們接手一個做法遵循的金融後台 Agent。它負責讀合約、比對法規、生成一份合規摘要。Demo 那天沒人挑得出毛病。上線第九天,它在一份併購文件裡「引用」了一條根本不存在的金管會函釋——條號、日期、內容,全是它自己編的,而且語氣篤定到承辦人差點就送簽了。

問題不在模型笨。問題在於,沒有人在它和真實世界之間放任何一道閘門。

Agent 的失控通常不是單一大爆炸,而是一連串沒被攔下的小偏差:一次無中生有的引用、一次多打的參數、一個進入死循環的工具呼叫。要做 agent 幻覺失控控制,靠的不是換更強的模型,而是在上線前把下面七道防護一層層疊上去。我們把它整理成一張可以直接拿去對照的清單。

agent 幻覺失控控制的七道防線

#	防護	攔什麼	對應的真實失控
1	接地檢核	沒有來源的斷言	上面那條被憑空捏造的函釋
2	工具強制	該查卻用猜的	該呼叫查價 API 卻自己報了個假價
3	輸出驗證	格式與範圍越界	退款金額算出負數仍照送
4	停損機制	死循環與失速	同一步驟重試 40 次燒掉 API 額度
5	權限最小化	越權執行	客服 Agent 誤觸「刪除訂單」
6	人在迴路	高風險動作	自動發出一封措辭失當的道歉信給大客戶
7	監控回放	事後查不到原因	出事三天後才發現,還原不了現場

接地檢核（grounding）。 要求每一句事實性陳述都掛上可回溯的來源片段,查不到來源就不准輸出,直接回「我不確定」。這一招專治捏造。我們給那個金融 Agent 加上強制引用後,凡是找不到對應法條原文的段落一律標紅退回,捏造率從肉眼可見降到近乎為零。

工具強制（tool forcing）。 模型最愛的偷懶方式,是把「該去查」的事情用「我記得大概是」帶過。凡是涉及即時數據——庫存、報價、餘額——就在系統層強制它必須先呼叫工具,拿到結果才能作答,不給它用參數記憶硬掰的空間。

輸出驗證（output validation）。 別相信自然語言,相信 schema。金額、日期、狀態碼一律用結構化格式輸出,再過一層規則:退款不能為負、日期不能早於今天、狀態只能落在白名單裡。一個算出負數的退款,在這關就會被擋下,而不是流到財務。

停損機制（stop-loss）。 給每個 Agent 設硬上限:單一任務最多幾次工具呼叫、最多幾輪反覆、最高花多少 token。超過就中斷、告警、轉人工。那個重試 40 次的死循環,如果一開始設了「同一步驟最多 3 次」的斷路器,根本燒不到第五次。

前面四招管「說錯」,後面三招管「做錯」和「查不到」。

權限最小化。 Agent 能呼叫的工具,只給它這個任務真正需要的那幾個。客服 Agent 不該有刪除訂單的權限,能查、能改狀態就夠了。破壞性動作要嘛不給,要嘛獨立收在需要二次確認的通道裡。

人在迴路。 不是每件事都要人審,但高風險、不可逆、對外的動作——發信給客戶、動帳、對外公告——一定要留一個人按下確認鍵。關鍵是把「該攔的」和「可放行的」切乾淨,否則審核疲勞會讓人變成無腦點同意的橡皮圖章,等於沒審。

監控與回放。 每一次工具呼叫、每一段 prompt、每一個中間輸出,都要留下可回放的 trace,並且配上線上評測,持續盯著接地率、工具正確率、越界攔截數。出事的價值不在當下,而在你三分鐘內能還原現場、找到是哪一步歪掉——而不是三天後靠客訴倒推。

這七道防護沒有一道是模型本身給的,全都得在系統層自己搭。我們在客戶現場做 Agentic 導入時,通常上線前就把這張清單逐項打勾:接地、工具、驗證、停損、權限、人審、監控,一項都不放過。Demo 漂亮從來不是我們驗收的標準——這套 Agent 上線後有人敢真的按下確認、而且沒出事,才算數。