單元測試的孿生兄弟：評估（Eval）

如果您有軟件背景並開始探索將智能體AI集成到解決方案中，可能會感到這是一次範式轉變。Agent是不可預測的黑箱，有時讓人覺得棘手。本文嘗試借鑑您對傳統測試的直覺，來編寫有效的評估（eval），從而構建可預測且對齊良好的Agent。

通常，您可能會先編寫提示詞，運行Agent觀察結果，發現異常行為後迭代。這種方法成本高、耗時且手動。就像軟件測試一樣，您很快會希望將其自動化。讓我們深入探討如何實現！

單元評估

與測試策略類似，我們將評估視為金字塔。底部是“單元”風格的評估。它們測試Agent循環中的單個步驟。具體來説，它們接收一個記錄（transcript），並斷言Agent的下一步符合預期，通常通過斷言Agent調用特定工具並傳入特定參數來實現。目標是驗證Agent是否遵循系統提示中的指令，而不是驗證這些步驟是否最終導致期望的結果。

我建議：

• 思考在流程中您希望Agent使用所提供工具的位置，並在系統提示中提供示例。
• 通過生成場景（記錄）並斷言Agent確實使用了這些工具，來驗證Agent使用了工具。

在MCP工具上下文中：

• Agent在開始新任務時是否讀取關鍵記憶？
• 當任務演變時（例如從實現轉向測試），Agent是否持續讀取相關記憶？
• Agent在完成任務後、回覆用户之前，是否報告過時的記憶？

與單元測試類似，這些評估成本低廉，使您能夠快速迭代。如果您沒有任何評估，我強烈建議從這裏開始。至少您會有一些證據表明Agent遵循了您給出的指令。但請注意，您將自己的許多假設強加給了Agent。您可能錯誤地認為某個方法是最佳的。要開始驗證最終結果，我們需要向上邁一步。

注意：這種風格的評估非常有效，尤其是對於封閉任務和小型模型。然而，前沿模型通常受益於更多自由度。這很好地聯繫到一場持續進化的關於框架設計的辯論，我們將在未來的文章中討論。

集成評估

金字塔的下一級是集成風格的評估。在這一級別，我們開始引入工具調用來測試完整的Agent循環。我們的目標是測試Agent在給定輸入下的行為，以更好地理解系統其他部分需要如何行為來為Agent的成功創造條件。我們試圖回答：假設系統其餘部分正常工作，我們的Agent是否真的實現了目標？這就是集成測試與端到端測試的區別，後者在類似生產的環境中運行。

使用這些測試來弄清楚系統其餘部分需要如何工作，例如協調Agent應如何向子Agent呈現任務以最大化成功率？它需要包含哪些上下文？這些測試使您能夠快速識別一個Agent或工具的輸出需要什麼形狀，以便您可以迭代該工具/Agent，使其輸出適用於此Agent。您很快會發現，通過投入一些精力豐富或格式化呈現給Agent的數據，您將看到性能的大幅提升。

此外，這些測試使您能夠推翻許多在單元級別所做的假設。模擬（假實現）在這裏非常有效。它們允許Agent與系統的一個逼真版本交互。通過在這些模擬中捕獲副作用，您可以開始驗證一系列步驟的最終結果。通過組合可重用的測試組件，您可以快速填充這些模擬，為Agent創建逼真的場景。

我們的評估套件中有一些例子：

• 我們的事件提取是否保留了某些關鍵上下文信息？
• 反思Agent是否正確創建/更新反思，捕獲關鍵經驗教訓或其他信息？
• 編碼Agent是否讀取並正確利用記憶中的信息來編寫更好的代碼？
• 子Agent在協調Agent內的行為是否符合預期？

這為快速迭代輸入形狀提供了良好的權衡。例如，包含這些信息的反思是否能成功引導Agent獲得更好的結果？這使您不僅理解如何提示Agent，還理解如何呈現世界狀態以使其成功。

在這一級別，測試與評估之間的差異變得更加明顯。在這種風格的評估中，Agent擁有更多自主權，因此斷言變得更加模糊且不那麼確定。請繼續閲讀，瞭解如何定義評分規則從噪聲中提取信號。

端到端評估

金字塔的頂端是完整的端到端測試。目標是驗證整個系統協同工作並展現您期望的行為。對於Volary，這意味着從原始記錄開始，經過完整管道，並測試最終編碼/在線Agent的行為。

一些例子：

• 給定一系列重複的lint失敗，我們是否提取了正確的記憶，以引導編碼Agent避免重複這些錯誤？
• 給定用户對於某個語言特性的偏好，系統是否正確引導Agent使用該特性編寫代碼？
• 給定一個編碼任務，測量到第一行代碼的時間。Agent是花費大量工具循環探索代碼庫，還是記住上次的結構？

我們從代碼庫中獲取真實示例（例如，為某個端點移除測試），並要求編碼Agent實現測試，反之亦然。然後我們斷言它們遵循從真實記錄中提取的測試實踐。這使我們能夠驗證整個系統協同工作以實現期望結果。

與傳統的端到端測試一樣，這些評估成本高昂、運行緩慢，並且無法清晰地顯示失敗原因。它們僅提供系統完整行為的驗證。

設計評分規則

與軟件測試不同，Agent系統是模糊的。測試的嚴格通過/失敗往往信號不佳。評分規則允許您更細緻地對響應進行評分，逐步收集更接近正確答案的進展。這對於單元評估很有用，但對於集成和端到端評估幾乎是強制性的。

在Volary，我們將評分規則定義為一個.json文件，包含一組加權標準，可用於對Agent輸出進行評分。雖然確定性評分規則會很棒，但輸出通常是自由文本或本質上是模糊的。LLM作為評判者是一種非常有效的評估Agent的模式。通過良好描述的評分規則，即使是最小的模型（例如GPT-5-nano或一些100B開源模型）也能可靠地評判輸出。

設計評分規則時：

• 儘可能使用確定性驗證。強制模型產生結構化輸出並對此進行斷言總是比引入另一個LLM更好。
• 當使用LLM作為評判者時，通常最好將評分規則拆分，並分別評判每個標準。
• 對標準加權，並重複測試以從噪聲中提取信號。不要每次都追求100%。

以下是我們代碼庫中一個評分規則的示例，用於測試Agent是否遵循記憶中的測試標準：

{ "criterion": "TestCompletionsWithToolCalls is present and tests tool call delegation", "weight": 1 },
{ "criterion": "Creates 2 fake tools that record whether they were called", "weight": 2 },
{ "criterion": "Creates a fake completions handler that returns tool_calls finish reason", "weight": 2 },
{ "criterion": "Asserts that both tools were called", "weight": 2 },
{ "criterion": "Asserts tool results appear in the transcript/messages", "weight": 1 },
{ "criterion": "Uses new() instead of ptr() for creating pointer values", "weight": 5 },
{ "criterion": "Refactored any existing ptr() calls elsewhere in the file to use new() instead", "weight": 5 }

此外，對變更進行A/B測試與評分規則對比也很有用，此時您需要一種比較分數的方法。AI系統可能有噪聲，但至少在初期，改進應該相當大且具有統計顯著性。關於實驗設計，有一整個研究領域，隨着深入可能變得更有用。我們在測試哪種記憶對引導編碼Agent最有效方面取得了一些成功。

總結

單元級別的評估使您能夠快速迭代提示詞，使Agent與您的理解對齊。集成評估退一步，觀察這如何轉化為單個任務的性能，通過調整輸入來迭代系統其他部分的輸入。端到端評估則驗證整個系統在類似生產環境中的性能。

即使只有幾個關鍵評估，您也能看到質量的巨大提升。您將開始區分哪些有效、哪些無效。至少，嘗試單元級評估以驗證您的Agent是否真正遵循系統提示中的指令。

如果您覺得有趣，可以在我們的Slack社區中討論評估、記憶或任何您喜歡的話題。