如何判斷你的 AI 代理到底行不行：用 Phoenix 與 Claude 做評估——Arize AI 的 Laurie Voss

Arize AI 的開發者關係負責人 Laurie Voss 主張，若要讓 AI 代理真正可靠，唯一的方法是追蹤它踏出的每一步，並用多層評估為這些追蹤紀錄打分——程式碼檢查、LLM 評審、人工標註——且必須在任何提示詞或模型變更上線之前完成。這 116 分鐘的節目大部分為實作工作坊：Voss 以 Claude Agent SDK 打造一個兩輪的財務分析師代理，在開源平臺 Phoenix 上追蹤它，寫一個股票代號檢查與一個自訂的「可執行性」評審，用自己的人工標註驗證此評審，並進行從 Claude Haiku 4.5 升級至 Haiku 5.5 的模型實驗。標題提出的問題在節目中直接得到回答，毫不拖延；整集內容主要聚焦於實作細節、失敗模式判讀與評估方法論，而非 AI 代理市場概況調查。

Voss 以實務工作者的身分說明：他曾在 npm Inc. 擔任 JavaScript 開發，現在在 Arize 負責 AI 應用，而 Phoenix 正是 Arize 所維護的專案。以下整理並重現整條脈絡——心智模型、代理實際出現的失敗（包含一份報告稱有 116% 的分析師同意）、三種評估型別及其適用時機、五段式評分準則、信任評審時的 precision/recall 取捨，以及如何以 LLM 的判斷把關 CI。對於打造或交付 LLM 功能的人而言，具體數字（修正前 16 份報告中僅 5 份可執行，修正後 48 份全數可執行；faithfulness 從 16 份中的 2 份提升至 48 份中的 3 份）遠比抽象論述更有用。

追蹤是日誌，評估是測試，而「我看起來沒問題」不是測試套件

Voss 的核心心智模型刻意保持樸素：追蹤即日誌，評估即測試，且評估即對追蹤紀錄進行測試。與單元測試的差別在於，LLM 的輸出從未兩次完全相同，因而無法斷言預期字串——「一千個不同答案都可能完全正確，只是正確方式不同。」一筆追蹤由多個 span 組成，每一步一個（代理輪次、工具呼叫、LLM 呼叫），各自記錄輸入、輸出、延遲、Token 數，有時甚至還有成本。追蹤告訴你發生了什麼；評估告訴你那到底好不好。

這套做法要取代的失敗模式，他稱之為「憑感覺上線」：先做出來、試三次、再上線。典型症狀是打地鼠——你在系統提示詞中已修正語氣，機器人卻開始捏造產品功能，而且往往是客戶先發現，而非 CI。評估將此事轉化為可追蹤、可比較、可行動的數字。隨著每次模型發布，風險只會更高；若無測試套件，你根本無法分辨新模型改善了哪些任務、又使哪些任務退步。

代理使此事比單次 LLM 呼叫更難，難點在於兩個具體面向。第一，連鎖失敗：早期一個錯誤步驟會向外擴散，之後每一步都偏離得更遠。第二，自信地答錯，他認為這比明顯答錯更糟——當財務代理被問及 Tesla 時，若檢索到的是 18 世紀的發明家而非汽車公司，它會產出一份格式漂亮、文法正確、語氣完美的報告，主題卻完全錯誤，任何格式檢查都無法發現。Voss 亦引用 Anthropic 的 Tau2Bench 客服基準測試：代理被要求將經濟艙座位換掉，結果先把乘客升到頭等艙、換了座位，再降回經濟艙——技術上滿足了要求，但卻是測試未預料到的方式。教訓是：代理有時比你寫的規則更聰明，故評估必須具備彈性。

示範代理的失敗，只有追蹤紀錄才看得出來

工作坊中的代理接收一個股票代號與一個關注焦點（「Tesla」、「成長展望」），先進行一次含網路搜尋的研究，再進行一次寫作，接續在同一個 session 起草報告。它執行於 Claude Haiku 4.5 上——選擇它是因為速度快、成本低，且「笨得有用」，會犯下可預測的錯誤；而前沿模型則僅在更複雜的任務中才會犯相同錯誤。追蹤大約五行：從 Phoenix 套件呼叫 register，它會啟動框架原本就附帶的 OpenTelemetry/OpenInference instrumentation，指向 localhost:6006。一個 TypeScript 的坑：由於 Claude Agent SDK 是匯出唯讀的 ES module，你必須使用 manuallyInstrument 回傳的那份 instrumenter 副本，並從你的 instrumentation 檔案匯入 SDK，絕不能直接從套件匯入——否則它會默默什麼都不記錄。

第一次實際執行就暴露了真實的失敗。寫作提示詞只說「寫一份報告」，沒說寫到哪裡，於是代理試圖把檔案存到磁碟，撞上 permissionMode: "don't ask" 的設定（無人值守、沒有人可以核准），回傳了一則令人困惑的訊息。追蹤直接顯示出失敗的那個工具呼叫；光看主控臺輸出只會一頭霧水。Voss 接著跑了一批 15 個查詢（一次五個，在會議 Wi‑Fi 上要三到四分鐘），把明顯的名字（Apple、Nvidia、Amazon）刻意混入邊界案例：Apple 對 Microsoft 的比較、Rivian（未上市、資料稀薄）、Coca‑Cola（非科技業）、假代號「ZZZQ」，以及「yo is Tesla a buy right now」這種口語問法。

讀追蹤紀錄後，浮現出幾類截然不同的失敗。ZZZQ 處理正確——代理說這個代號不存在。Coca‑Cola 產出的報告稱 KO 是「絕佳的長期收益型標的」，卻沒有買進／持有／賣出的結論。Rivian 的報告塞滿表情符號，還問使用者「要不要幫你建立報告檔案？」，儘管它已被告知不能提問。最有教育意義的是 Tesla「該不該買」那一輪，報告寫著「50% 說買進、52.6% 說持有、13.1% 說賣出」——加起來 116% 的分析師——因為它把兩次不相關的網路搜尋併成同一份資料集，卻沒發現這個算術根本不可能。每一筆搜尋結果都沒問題；出錯的是推理。Voss 之所以區分各種成因，是因為每種成因的修法不同：檢索品質差、推理錯誤、幻覺，或範圍錯誤（回答了跟提問不同的問題）。

他建議先做開放編碼、再做主軸編碼——先為每筆追蹤寫下白話註記（「這很糟，因為它做了 X」），再把註記歸類成群。事先憑空猜類別，只會得到太窄、太寬或根本錯誤的類別。他指出 Anthropic 團隊會定期人工閱讀評估逐字稿，還為此打造了內部工具；而 coding agent 非常擅長大規模閱讀追蹤紀錄——但針對未知的未知，人工抽樣仍然不可或缺。優先順序是頻率乘以嚴重度：40% 的幻覺率是個問題，但 1% 的機率教使用者怎麼做炸彈，必須立刻修掉。

三種評估像瑞士起司一樣層層疊加，問對問題勝過把評分準則調到完美

Voss 提出三種互補的評估型別，並強調它們不是彼此競爭的做法。

| 評估型別 | 檢查什麼 | 成本／速度 | 盲點 |
|---|---|---|---|
| 程式碼評估 | 確定性屬性：能解析為 JSON、少於 500 字、提到股票代號、資料庫狀態、即時 API 交叉核對 | 毫秒級、免費 | 無法判斷語意 |
| LLM 評審 | 依評分準則判斷準確性、faithfulness、語氣、有據可循 | 要花錢、數秒到數分鐘、非確定性 | 可能自信地判錯；需要驗證 |
| 人工評估 | 專家判斷、新型失敗模式、為評審的作業打分數 | 慢、貴、會疲勞 | 無法擴充套件到每一筆追蹤 |

組織這一切的比喻是資安領域的瑞士起司模型：每一層都有洞，但只要洞沒有對齊，錯誤就很難穿過所有層。因此要用很多個小評估，而不是一個「萬能評審」同時檢查準確性、語氣、完整性、格式與政策——它一旦失敗，你分不清是哪個面向失敗，而硬掛上 15 個輸出標籤只會更難追蹤。他也區分護欄（必須擋下發布，例如捏造股價）與北極星指標（可有可無，例如建議其他值得一看的股票）。

第一個程式碼評估是最簡單也有用的檢查：報告有沒有提到被問到的那個股票代號？它幾乎瞬間跑完，抓到兩個失敗——一份 Tesla 報告沒提到 Tesla，一份 Amazon 報告死盯著 AWS 的獲利，完全沒談到購物業務。他強調，程式碼評估不是玩具：它們可以查資料庫、驗證工具造成的副作用，或呼叫 API 確認代理引用的股價。但要評結果，不要評路徑——Anthropic 建議不要斷言代理必須先呼叫搜尋、再呼叫第二個工具，因為代理會找到意想不到的路徑。

接著是內建評審。Voss 用 Claude Sonnet 5.5 當評審跑 Phoenix 的 correctness 評估器（比 Haiku 代理更強的模型，最好還是不同供應商，以避免同模型偏誤），結果 16 份報告全部掛零。原因很有啟發性：correctness 是拿模型自身的知識來判斷，而 Claude 的知識截止點大約在一月，所以十月的股價看起來就像幻覺。16 份說明中有 7 份抱怨評審無法驗證最新資料；其餘則指出數字兜不攏這類真實問題。結論：選對評估比把評估調好更重要。faithfulness 問的是更好的問題——就你手上有的資料而言，這份報告站得住腳嗎？——它需要輸入、輸出與上下文（原始搜尋結果加上研究輪次的筆記）。他的第一版只傳了筆記，評審就把真實數字標成捏造；正式版傳入完整上下文。Faithfulness 判定 16 份中有 14 份不忠實，說明也很有用：Microsoft 那份報告加了沒有依據的說法（Azure 是第二大雲端供應商、三年 backlog 能見度、暗示 FY2027 目標），Nvidia 那份則把兩個資料點混為一談。

工具層級的評審（tool_selection、tool_invocation、tool_response_handling）在讀報告之前就先評代理的選擇。工具選擇需要任務、可用工具清單（追蹤不會記錄這個，得由你提供），以及實際呼叫的工具。它標出六個寫作輪次多做了不必要的第二次 bash 呼叫，另外七個只試一次的則有六個過關——但關鍵在於，只有一則說明提到使用者從未要求產出檔案。評審站在代理這邊，因為提示詞本身就真的有歧義。Voss 的重點是：你告訴代理什麼、以及你告訴評估什麼，兩者會互相影響，所以工具呼叫評估的「錯誤」，有時其實是提示詞的缺陷。

自訂評分準則有五個部分，措辭的小改動就能翻轉判定

因為沒有內建評估會檢查買進／持有／賣出的建議，Voss 自己寫了一個。他說，凡是有效的評分準則都有五個部分：

1. 角色與上下文——「你是一位專家……」有一點幫助，但上下文（這是一份財務報告，我們在意的是它能不能據以行動）更重要。
2. 明確的判準——不是「有幫助且準確」，而是「提出具體建議、點名具體風險、向前看而不只是回顧」。判準來自錯誤分析；「只彙整資料而沒有解讀」之所以寫進評分準則，就是因為在追蹤紀錄裡看到過。
3. 清楚標記的資料——把每個輸入、輸出與範例各自包在自己的 XML 標籤裡。Claude 在大量 XML 上訓練過，處理得很好；標籤也能削弱提示注入（prompt injection），並避免評審把範例和資料搞混。
4. 附標籤的範例——這點有爭議。Voss 做了有範例與無範例的對照：有範例時，評審三次中有 15/16 與他的人工標註一致；沒有範例時，兩次 16/16、一次 15/16。不一致來自一份 Microsoft 報告，它給了買進建議與時間範圍，卻沒有風險段落——他的評分準則把風險列為判準，他的範例也強化了這點，而他當初卻仍把它標為可執行。他承認評審可能比他更嚴格、也更正確。
5. 受限的輸出——現代評估器用工具呼叫搭配列舉選項（可執行 = 1、不可執行 = 0），而不是要求輸出精確字串，可靠得多。

他把評估提示詞當程式碼看待：要版控、要檢查、要測試。一個具體例子——他的範例一開始是純文字，評審回傳了一連串「不可執行」的判定；把同樣的範例包進 XML 標籤後，全部翻轉為可執行，其他什麼都沒改。可執行性評審把他的 16 份報告分成 5 份可執行、11 份不可執行——這是個值得爬的山丘，不像那種全部通過或全部失敗的評估。失敗的模式很一致：Rivian 從頭到尾沒給買進／持有／賣出的結論，Nvidia 的「風險程度為中等」模糊到無法據以行動，Meta 的結論只有「這個部位很穩」。

用人工標註驗證評審，然後接受人類彼此也會不一致

評審就是一個分類器，所以你要拿 ground truth 來衡量它——在這裡就是 Voss 自己對全部 16 份報告的標註，透過 Phoenix 的標註鉛筆圖示輸入成「human actionable」欄位。他建立了一個帶分割的黃金資料集：每一份人工標註的報告都成為一個範例（輸入 = 報告，預期 = 人工標籤），依 span ID 排序，讓每份報告永遠落在同一個分割，每第四個範例進 test，其餘進 dev。這個後設評估在 dev 分割上跑評審，再用一個極小的程式碼評估計算一致率。在他的 12 份 dev 報告上，評審每次都跟他一致——「目前還看不出問題」，但這只有 12 份報告。

最有價值的地方，正是兩個最難的案例。Coca-Cola 對他來說是邊界案例（稱 KO「適合保守型收益導向投資組合」聽起來像建議；他判定不算），對評審也是邊界。Microsoft 則相反：有理由、有時間範圍的買進建議，但沒有風險；評審說它「勉強達到可執行的門檻，但幅度不大」。評審精準重現了他的模糊地帶。當他試圖加上「一份報告只有在符合全部四項判準時才算可執行」來修正，這個更嚴格的評分準則卻讓 test 分割裡的 Apple 報告失分——證明評分準則的改動可能讓評估變得更糟。

他介紹 precision（評審說不可執行時，有多常是對的）與 recall（在所有不可執行的報告中，它抓到了多少），並建議優先顧 recall：誤報的代價是一分鐘的複核，漏掉的失敗則會直接送到客戶面前。他也點名評審的偏誤——位置偏誤（偏好第一個或最後一個選項，所以要交換順序）、長度偏誤（偏好長答案）、自信偏誤（偏好流暢的答案），以及自我偏好（模型給自己的輸出較高分，所以要用 Sonnet 評 Haiku，最好用 OpenAI 的模型來評）。真正該校準的基準是：人類專家拿到同樣的輸出與評分準則，一致度往往只有 Cohen's kappa 0.2–0.3，僅略高於隨機，所以評審的標準是人類的表現，不是完美。而當某個失敗看起來不公平——「其實我看起來沒問題」——問題很可能出在評估本身。他引用 Anthropic 的 CoreBench 那一集：Claude Opus 4.5 起初只拿 42%，一位研究員發現代理其實是用另一種方式答對了（要求六位有效數字，它給了四位；任務描述有歧義；有些任務無法重現），修正測試後，分數一舉跳到 95%。

實驗證明提示詞修正奏效——也暴露它沒修好的部分

沒量測過的提示詞改動，就只是感覺。實驗的模式是：把追蹤紀錄篩選到失敗的那些，加進 Phoenix 資料集，然後對這組資料跑任務（代理）加評估器——每次只測失敗案例，而不是整套重跑。Voss 改進後的提示詞與發現一一對應：評審說沒有建議，提示詞就要求明確的買進／持有／賣出；評審說風險缺乏佐證，提示詞就要求風險須附支援資料；faithfulness 抓到捏造數字，提示詞就說只能用研究中的數字；追蹤顯示它在存檔案，提示詞就說直接回覆報告內容。

因為代理是非確定性的，他把實驗跑了三次，並區分 pass@k（k 次中至少成功一次——對 coding assistant 來說夠了）與 pass^k（每次都成功——對五次錯一次的客服機器人，或給出不準確建議的財務分析師，這是必要條件）。結果：可執行性從 5/16 提升到 48/48；股票代號檢查從 15/16 到 48/48；faithfulness 儘管有明確指示，仍只從 2/16 提升到 3/48。先前通過的報告全都還是通過，所以沒有任何退步——但代理依然會捏造資料，這是下一個要修的東西。他也排出改進的操作順序：先顧資料品質（資料爛，其他調整都白費），再改提示詞，再換模型（槓桿大，但一次改動很多東西，而且通常更貴），超引數放最後——後者用處小到現代 Claude 模型已不再接受 temperature。

模型升級是壓軸。演講前約一週發布的 Haiku 5.5，用同一套實驗跑三次（13 分鐘）。Faithfulness 進步超過三倍，但仍然很糟；一致性提升了——原因是 Haiku 5.5 幾乎總是說「持有」，45 次呼叫中有 41 次。所以它是靠變得更保守來變得更一致，成本大約是四倍。這正是評估—迭代迴圈發揮作用：它告訴他有些東西變了，並點名了新的問題。

用 CI 鎖住成果，週一就從單純追蹤開始

最後一步是把評估放進 Vitest 測試套件（agent.eval.ts）：一個 describe 區塊，每個回歸查詢（Coca‑Cola、Apple 對 Microsoft、Rivian、ZZZQ）一個測試，各自跑代理、把報告記錄為輸出，並套用股票代號檢查與可執行性評審。建置以驗收標準把關——提到股票代號是必須通過的護欄，可執行性則以平均值維持在 0.8 以上為門檻，因為單一評審的判定雜訊太大。建置失敗時會印出計分卡：在他的例子裡四個測試全跑了，每份報告都提到股票代號，但 Rivian 的報告不可執行，平均值因此是 0.75。同一套測試也能在 GitHub Actions 上跑，把 Phoenix 當成服務容器。他提醒不要每次 commit 都跑整個代理——又慢又貴——並建議對真實流量抽樣做生產環境監控，分數下滑且持續低迷時才告警，而不是單次失敗就告警。

他最後的建議是從小處開始：週一就只做一件事，替代理加上 instrumentation，然後讀十幾筆追蹤紀錄。『讀 12 筆追蹤紀錄能得到的資訊，是你光看輸出得不到的。』他也指出，任何知道什麼叫做好的人——PM、客服、聽到同一個抱怨的業務——現在都能靠描述一個好答案來寫評估，或把這段描述交給 coding agent 去寫 TypeScript。這個 repo（Phoenix 101，內含一個「golden」種子專案，收錄他的 16 次執行與人工標註，給會議 Wi‑Fi 斷線的人用）就是成果物；Phoenix 本身是開源的。

值得持續關注的未解張力是 faithfulness：兩輪提示詞迭代加一次模型升級之後，代理大多數時候仍在捏造數字，這暗示剩下的修法屬於架構層面（檢索限制、強制引用、工具層級檢查），而不是提示詞措辭。第二個是 Haiku 5.5 的保守化——靠永遠說「持有」換來的一致性，其實是品質退步，而天真的「一致性指標」會把它算成進步；這提醒我們：你選了什麼評估，就決定了你會得到什麼樣的代理。Voss 自己的說法——「選對評估勝過把評估調好」——正是把 correctness 的失敗、工具選擇的歧義，以及 Haiku 5.5 的結果串在一起的那條線。