如何評估智能體效果呢？LangChain 團隊的經驗總結
去一個月，LangChain 基于 Deep Agents 框架交付了四個應用：
- DeepAgents CLI: 一個編碼 agent
- LangSmith Assist: LangSmith 內置的智能助手
- Personal Email Assistant: 能從用戶交互中學習的郵件助手
- Agent Builder: 無代碼 agent 搭建平臺
在開發和部署這些 agent 的過程中，團隊為每個應用都配置了評估系統，積累了不少實戰經驗。這篇文章會深入探討評估深度 agent 的幾個關鍵模式:
- 深度 agent 需要為每個測試用例定制測試邏輯 —— 每個案例都有自己獨特的成功標準
- 單步運行 特別適合驗證特定場景下的決策(還能省 token)
- 完整輪次運行 適合測試 agent 的"最終狀態"
- 多輪對話測試 能模擬真實用戶交互，但需要保持測試可控
- 環境配置很關鍵 —— 深度 agent 需要干凈、可復現的測試環境
術語說明
先解釋幾個后文會用到的概念。
Agent 的運行方式:
- 單步 (Single step): 限制核心 agent 循環只運行一輪，看它會采取什么行動
- 完整輪次 (Full turn): 讓 agent 完整處理一次輸入，可能包含多次工具調用
- 多輪對話 (Multiple turns): 讓 agent 完整運行多次，模擬用戶和 agent 之間的多次交互
圖片
可以測試的內容:
- 執行軌跡 (Trajectory): agent 調用了哪些工具，傳了什么參數
- 最終響應 (Final response): agent 返回給用戶的最終回復
- 其他狀態 (Other state): agent 運行過程中產生的其他內容(比如文件、制品等)
圖片
智能體評估實戰
1.深度 Agent 的每個測試用例都需要定制化邏輯
傳統的 LLM 評估流程很直接:
- 構建示例數據集
- 寫一個評估器
- 用應用處理數據集生成輸出，然后用評估器打分
每個數據點的處理方式完全一樣 —— 跑同樣的應用邏輯，用同樣的評估器打分。
圖片
深度 Agent 打破了這個假設。除了最終消息，還需要測試更多內容。每個數據點的"成功標準"可能完全不同，需要針對 agent 的軌跡和狀態做特定的斷言。
看個例子:
圖片
有個日歷調度 agent，能記住用戶偏好。用戶說"記住，不要在早上 9 點前安排會議"。需要驗證這個 agent 是否在文件系統中更新了自己的記憶。
為了測試這個場景，可能需要驗證:
- agent 是否對 memories.md 文件調用了 edit_file
- agent 是否在最終消息中告知用戶記憶已更新
- memories.md 文件是否真的包含了不安排早會的信息?？梢?
用正則表達式查找"9am"
或者用 LLM-as-judge 配合特定成功標準，做更全面的文件更新分析
LangSmith 的 Pytest 和 Vitest 集成支持這種定制化測試?？梢葬槍γ總€測試用例，對 agent 的軌跡、最終消息和狀態做不同的斷言。
# 標記為 LangSmith 測試用例
@pytest.mark.langsmith
def test_remember_no_early_meetings() -> None:
user_input = "I don't want any meetings scheduled before 9 AM ET"
# 可以把 agent 的輸入記錄到 LangSmith
t.log_inputs({"question": user_input})
response = run_agent(user_input)
# 可以把 agent 的輸出記錄到 LangSmith
t.log_outputs({"outputs": response})
agent_tool_calls = get_agent_tool_calls(response)
# 斷言 agent 調用了 edit_file 工具來更新記憶
assert any([tc["name"] == "edit_file"and tc["args"]["path"] == "memories.md"for tc in agent_tool_calls])
# 用 LLM-as-judge 記錄反饋: 最終消息是否確認了記憶更新
communicated_to_user = llm_as_judge_A(response)
t.log_feedback(key="communicated_to_user", score=communicated_to_user)
# 用 LLM-as-judge 記錄反饋: 記憶文件是否包含正確信息
memory_updated = llm_as_judge_B(response)
t.log_feedback(key="memory_updated", score=memory_updated)關于如何使用 Pytest 的通用代碼示例，可以查看這份文檔:
這個 LangSmith 集成會自動把所有測試用例記錄到實驗中，這樣就能查看失敗用例的 trace(方便調試)，還能跟蹤結果的變化趨勢。
2.單步評估很實用，效率也高
圖片
在深度 Agent 的評估中，大約一半的測試用例都是單步評估，也就是說，在特定的輸入消息序列之后，LLM 會立即做什么決策?
這對驗證 agent 在特定場景下是否用正確的參數調用了正確的工具特別有用。常見的測試場景包括:
- 是否調用了正確的工具來搜索會議時間?
- 是否檢查了正確的目錄內容?
- 是否更新了記憶?
回歸問題往往出現在單個決策點，而不是整個執行序列。如果用 LangGraph，它的流式能力可以在單次工具調用后中斷 agent 來檢查輸出 —— 這樣能在不跑完整個 agent 序列的情況下及早發現問題。
在下面的代碼中，手動在 tools 節點前設置了一個斷點，這樣就能輕松地讓 agent 只跑一步。然后就可以檢查單步之后的狀態并做斷言。
@pytest.mark.langsmith
def test_single_step() -> None:
state_before_tool_execution = await agent.ainvoke(
inputs,
# interrupt_before 指定要在哪些節點前停止
# 在 tool 節點前中斷，就能檢查工具調用參數
interrupt_before=["tools"]
)
# 可以看到 agent 的消息歷史，包括最新的工具調用
print(state_before_tool_execution["messages"])3.完整輪次運行能看到全貌
把單步評估當作"單元測試"，確保 agent 在特定場景下采取預期行動。而完整輪次運行也很有價值 —— 能看到 agent 端到端執行的完整畫面。
完整輪次運行可以從多個角度測試 agent 行為:
1) 執行軌跡: 評估完整軌跡的一個常見方法是確保某個特定工具在執行過程中的某個時刻被調用了，但不關心具體時機。在日歷調度的例子中，調度器可能需要多次工具調用才能找到適合所有參與者的時間段。
圖片
2) 最終響應: 有時候最終輸出的質量比 agent 走的具體路徑更重要。在編碼和研究這類開放式任務中，這種情況更常見。
圖片
3) 其他狀態: 評估其他狀態和評估 agent 的最終響應很相似。有些 agent 不是以聊天格式回復用戶，而是創建制品。在 LangGraph 中檢查 agent 的狀態，就能輕松查看和測試這些制品。
- 對于編碼 agent → 讀取并測試 agent 寫的文件
- 對于研究 agent → 斷言 agent 找到了正確的鏈接或來源
完整輪次運行能看到 agent 執行的全貌。LangSmith 把完整的 agent 輪次以 trace 的形式展示，既能看到延遲和 token 使用量這些高層指標，也能分析每次模型調用或工具調用的具體步驟。
4.多輪對話測試模擬真實用戶交互
圖片
有些場景需要測試 agent 在多輪對話中的表現，也就是多個連續的用戶輸入。挑戰在于，如果直接硬編碼一系列輸入，一旦 agent 偏離了預期路徑，后續硬編碼的用戶輸入可能就不合理了。
團隊的解決方案是在 Pytest 和 Vitest 測試中加入條件邏輯。比如:
- 運行第一輪，然后檢查 agent 輸出
a.如果輸出符合預期，繼續下一輪
b.如果不符合預期，提前讓測試失敗(因為可以靈活地在每步之后加檢查，這個方案可行)
這種方法可以運行多輪評估，而不用對 agent 的每個可能分支都建模。如果想單獨測試第二輪或第三輪，只需從那個點開始設置測試，配上合適的初始狀態就行。
5.搭建合適的評估環境很重要
深度 Agent 是有狀態的，專門用來處理復雜的長時任務 —— 通常需要更復雜的環境來做評估。
不像簡單的 LLM 評估，環境通常只包含幾個無狀態工具，深度 Agent 需要為每次評估運行提供一個全新、干凈的環境，才能保證結果可復現。
編碼 agent 就是個典型例子。Harbor 為 TerminalBench 提供了一個在專用 Docker 容器或沙箱中運行的評估環境。對于 DeepAgents CLI，團隊用了更輕量的方案: 為每個測試用例創建一個臨時目錄，在里面運行 agent。
總結一下: 深度 Agent 評估需要每個測試都能重置的環境 -- 否則評估會變得不穩定，難以復現。
小技巧: Mock API 請求
LangSmith Assist 需要連接真實的 LangSmith API。對真實服務運行評估既慢又貴。更好的辦法是把 HTTP 請求記錄到文件系統，測試時重放它們。Python 可以用 vcr；JS 的話，可以通過 Hono app 代理 fetch 請求。
Mock 或重放 API 請求能讓深度 Agent 評估更快、更容易調試，特別是當 agent 嚴重依賴外部系統狀態時。 (這個很重要，Mock假接口可以幫我快速打通流程，驗證輸入和輸出有效性，這個也是筆者經常調試的一個手段)
