怎麼知道 Agent 做得夠好

先看多數人是怎麼驗收的,方法其實很樸素:你交辦一個任務,它做完,你瞄一眼,看起來對,就過了。一次兩次沒問題,靠肉眼很快。但問題來了:當你一天要跑幾十個任務,或是你要把這個 Agent 接進公司正式流程、天天自動跑,你一個人的眼睛,根本看不過來。這時候,樸素的驗收就不夠用了。

我先戳破一個東西。「我覺得它做得不錯」——這句話,不是證據,是一種感覺。你今天測了三題,它都對,你就安心了。但你有沒有想過:同樣的任務,明天再跑一次,它可能就歪掉了。你改了一句 prompt、換了個模型,它可能突然某類問題就答錯。你以為你在掌控它,其實你根本不知道它到底穩不穩定。感覺,是會騙人的。

那正確做法是什麼?核心概念其實很簡單:你準備一組「固定的測試案例」,一次又一次拿去驗它。同樣的輸入,你看它的輸出對不對;而且不只看對不對,還要看它每次跑,是不是一致。這個「用一組固定案例反覆去驗」的動作,就是我們要講的主角,英文叫 eval,評估。它把驗收從「臨場看一眼」,變成「有一把固定的尺」。

那具體怎麼做?我給你一個最小、馬上能動手的版本。第一步,挑幾個「代表性的真實任務」——不是刁鑽的偏門題,是你平常最常交辦、最在意做對的那幾種。第二步,針對每一題,寫下「正確答案長什麼樣子」,或至少寫下「怎樣算對、怎樣算錯」。第三步,把這組題目跟答案存起來。這就是你的考卷,一份固定不變的考題。

有了這份考卷,接下來就好辦了。只要你動了任何東西——改了 prompt、換了模型、調了流程——你就拿這組固定案例,完整跑一遍,對照答案看結果。重點不是「它有沒有全對」,重點是「跟上次比,有沒有變差」。你在做的,其實是每次改動前後,各考一次同一份卷子,然後比分數。這個動作聽起來很笨,但它是你唯一能抓到問題的方法。

這裡要記一個關鍵詞:回歸測試,英文 regression。什麼叫回歸、叫退步?就是你調了某個東西,結果「本來會做對的,現在反而做錯了」。這是最陰險的一種問題,因為你改的時候眼睛盯著新功能,根本不會回頭去看舊的那些案例有沒有被你弄壞。而唯一能抓到這種退步的辦法,就是有一組固定的測試,每次都完整跑過。沒有它,你就是在盲改。

但你真的動手做,馬上會撞到第一個難題,而且這題跟傳統軟體測試完全不同。傳統程式你餵同樣的輸入,輸出永遠一模一樣,所以測試可以拿字串直接比對。但模型是**帶隨機性**的:同一題跑兩次,意思可能一樣,字面幾乎不可能一樣。這代表兩件事。第一,你不能用「跟標準答案一字不差」當判斷標準,那樣會全部誤判成失敗。第二,更重要 —— **跑一次通過,不代表它穩**。所以正確的做法是:同一題跑個五次,記的不是「過或不過」,是「五次裡對幾次」。一題五次全對,跟一題五次只對三次,那是完全不同的可靠度,但你只跑一次的話,這兩種看起來一模一樣。**通過率,才是你要記的那個數字。**

第二個難題是:很多任務的正確答案根本不是一個標準答案。「幫我寫一封回覆客訴的信」,對的寫法有一百種,你要怎麼自動判?這裡的順序很重要,不要一開始就跳到最花俏的做法。**能用程式判的,一律先用程式判。** 有沒有算錯數字、格式對不對、該提到的那三個關鍵事實有沒有出現 —— 這些寫幾行程式就能查,又快又不會騙你。真的判不了的那部分,才用一個現在很流行的做法:**再叫一個模型來當評審**,英文叫 LLM-as-judge。你把題目、Agent 的答案、還有評分標準一起餵給它,讓它打分。關鍵在最後那個「評分標準」:你不能問「這個答案好不好」,那會得到毫無意義的分數。你要問的是具體的、可勾選的:「有沒有回應客戶提到的那個問題?有沒有給出時間點?語氣是不是有禮貌?」**評審問得越具體,分數才越有意義。**

但模型當評審有它自己的毛病,你要先知道,不然你會拿一把歪的尺量得很認真。第一,**它偏愛長的答案**。同樣的內容,寫得比較長、比較華麗的那份,常常拿到比較高的分,哪怕多出來的都是廢話。第二,**順序會影響它**。你把 A 答案跟 B 答案的位置對調再問一次,它給的評價可能就翻過來了。怎麼防?三招。第一,評分標準寫得越死越好,少留模糊空間。第二,要比較兩個答案的時候,**兩種順序各跑一次**,結果一致才算數。第三,也是最重要的:**你自己要抽個二十題,親手看過,對照評審給的分。**如果評審給高分的那些你看了搖頭,那你的尺是壞的,要先修尺,而不是拿它的分數去做決定。**評審本身,也是要被驗收的東西。**

最後講一個很容易掉進去的陷阱,而且掉進去了你還會覺得自己做得很好。你有了那五題之後,會不自覺一直對著那五題調 prompt、調流程,調到五題全過。問題是:**那五題滿分,不代表第六題會對。**你只是把 Agent 調成很會考這五題,這在機器學習裡有個名字,叫過擬合。你要記得:那份考卷是**抽樣**,它代表你關心的那一類任務,它本身不是目標。所以有兩個習慣要養。第一,**考卷要持續長大** —— 每次真實情況坑到你,不管是它做錯還是做歪,當天就把那一題補進考卷,不要拖。第二,**別把考卷的題目直接寫進 prompt 裡**,那等於把答案抄給它,分數就完全失真了。一份會跟著你踩坑一起長大的考卷,才是活的;一份三個月沒動過的考卷,量到的東西已經跟現況無關了。

這件事,個人玩玩也許還好,但只要進到企業就變成必要。為什麼?因為你要把這個 Agent 接進正式流程、給很多同事天天用。這時候一定會有人問你:它到底有多可靠?出錯率多少?這個問題,你不能用「我感覺還行」來回答。你得拿得出實際的數字、實際跑過的案例。在公司裡,沒有證據,就沒有人敢用你的東西。

我把這件事講得更白一點。一個 Agent 在你電腦上 demo 得很漂亮,跟你敢不敢把它放上線、讓它自動處理真實業務,是兩回事。demo 只要成功一次就好看;上線要的,是它每天跑、跑一萬次都穩。而支撐你「敢按下上線」的那份底氣,就是這組評估。它是你和公司之間的信任基礎——你有一組可重複的證據,證明它到底行不行。

講到這,可以收在一個更根本的原則上:真正的完成,是「可驗證」,不是「我覺得對了」。這裡講的 eval,其實就是那句話的規模版。以前你是一個任務、用眼睛驗一次;現在你是把那個「驗一次」的動作,升級成一套「可以自動重複跑」的證據系統。同樣的精神,只是從一次性,長成了可規模化。這就是從 vibe coding 走向 vibe engineering 的差別。

你可能會覺得:這聽起來好工程、好麻煩。別怕,起點可以非常小。你完全不用一開始就去搞什麼高級的評估平台、自動化框架。你就做一件事:把你「最在意、最不能錯」的五個案例寫下來,每一個配上一份正確答案。就這樣。一個文件、五題、五個答案。這是任何人今天下午就能開始做的。

有了那五題,用法就是這麼樸實:每次你要改東西之前,先拿這五題跑一次,把結果記下來;改完之後,再跑一次,兩邊對照。只要發現本來對的變錯了,你就知道這次改動有問題,擋下來、別放行。就這麼簡單的一個對照動作,你就已經比市面上大多數「憑感覺就上線」的人,嚴謹太多了。嚴謹,不等於複雜。

如果今天你只帶走一句話,那就是:別再用「我覺得對了」去決定要不要信任一個 Agent。改成用一組固定的案例,反覆去驗它,把「感覺對」升級成「有證據對」。這一步,就是一個 Agent 能不能真的放進你的工作、放心交給別人用的門檻。跨過它,你的 Agent 才算真的可靠。你可以從三個案例開始:一個典型的、一個邊界的、一個你以前被它坑過的。