摘要： LangChain 在 2026 年 10 月 15 日發表一篇整理 agent evals 常見問題的文章，由 LangSmith 團隊的 Divya Santhanam 撰寫。核心訊息很具體：挑一個行為、從真實 trace 建十到二十個例子、跑一次基線，然後讓線上評估抓到的新失敗不斷餵回離線資料集。對正在把 agent 推上線的 builder 來說，這是把「感覺不太對」變成可衡量問題的第一張地圖。
為什麼 agent 不能照傳統軟體那樣寫單元測試
LangChain 在文章裡指出三個讓 agent 難以測試的原因：同樣的請求每次輸出可能不同；不止一個答案可以是對的，精確比對不管用；而且 agent 會自己決定步驟，正確的輸出可能來自「不該走的路」，例如呼叫了不需要的工具，或未經用戶同意就行動。
所以 evals 的角色不是驗證單一正確答案，而是給每次 run 打分，容許這些變異。這也意味著沒有萬用套件，最好的評估組合取決於你的團隊、產品和想優化的目標。
起手式：一個行為、一個小資料集、一次基線
文章給的起手流程刻意做小。先讀一批 trace，看 agent 實際怎麼處理請求、在哪裡出錯，然後挑一個你在乎的行為——以旅遊助理為例，可以是有沒有照用戶指定的日期和價格區間訂票。接著從 trace 建一個十到二十個例子的資料集，跑基線並存成 experiment，之後每個版本的 agent 都跟它比。生產環境還沒上線的話，就先靠團隊或設計夥伴測試的 trace 來源。
改進循環就是：找到失敗、加進資料集、改 agent、重跑。文章舉的例子很傳神——價格對了，但 agent 搜的是錯的日期，這條 trace 就該變成新例子。
離線、線上與四種評分器
Offline evals 在上線前跑資料集，適合測新 prompt、新模型或新工具，也在改動出事前抓 regression。Online evals 則是對真實生產流量即時打分，通常沒有參考輸出可比，所以靠 code 檢查和 LLM judge 自行評分。兩者要並用，線上抓到的失敗會變成離線資料集的新例子。
評分的邏輯有四種，多數團隊從一到兩種開始：
- Code evaluators：確定性地檢查，例如訂票價格有沒有超出預算，快、便宜、一致。
- LLM-as-a-judge：處理 code 查不了的事，例如回覆有沒有清楚確認航班細節。
- Human review：慢，但對主觀品質是最好的訊號，也用來校正其他評估器。
- Pairwise evaluators：兩個輸出並排比誰好，適合在兩個 prompt 或模型之間做選擇。
評估對象也不只最終回覆。可以針對單一步驟（例如搜尋工具的日期參數對不對）、整段對話，甚至是環境的最終狀態——benchmark 常用後者，在容器裡跑完後檢查訂票紀錄這類實際留下的狀態。
LLM judge 能不能信
LLM judge 有彈性，但會不一致，也可能慢慢偏離團隊的判斷。LangChain 給了幾個習慣性的做法：拿人類評分和 judge 對照，找出分歧後調整 judge 的 prompt 或例子；問窄問題——「回覆有沒有提到每一段轉機」比「這個回覆好不好」好判得多；用二元 pass/fail 或小組分類取代 1 到 10 分制，因為 judge 很難區分 6 分和 7 分。
這一段和我之前寫過的觀測性話題是一體兩面：先把 Claude API 的呼叫變成可查的 trace，evals 才有材料可以下手（見把 Claude API 的每一次呼叫變成可查的 trace）。
Benchmark 是什麼、Harbor 又是什麼
文章把 benchmark 定位成一種離線 eval：一組任務，每個任務帶自己的容器環境和一個檢查結果的測試腳本。任務通常步驟更多——安裝套件、改檔案、跨數十次工具呼叫——而分數來自 agent 留下的環境狀態，例如測試有沒有通過。
Harbor 是驅動 Terminal-Bench 的開源 eval harness，跑完的結果會記到 LangSmith experiment。LangChain 自己就用這套流程改進 Deep Agents 在 Terminal-Bench 2.0 的表現，也用它造出給 LangSmith Engine 用的 IssueBench。想給自己的 agent 建 benchmark，路徑和一般 evals 相同：從 trace 收集任務、定義「好」的標準、用分數反覆 A/B 測改動。
對 builder 的實際啟示是：別等一套完美評估架構。今天就能讀十條 trace、挑一個行為、建二十個例子跑基線，這個循環跑起來，eval suite 會自己長出形狀。