評估AI代理：使用Strands和AgentCore的生產藍圖

本文與Motorway以及AWS原型設計和AI客户工程（PACE）團隊共同撰寫。

Motorway是一家總部位於英國的在線汽車市場，每天運行一場拍賣，多達8,000家經銷商對多達2,500輛汽車進行競價。Motorway與AWS PACE團隊合作構建了一個AI驅動的經銷商庫存搜索代理，該代理改變了經銷商尋找車輛的方式，用自然語言查詢取代了數小時的手動篩選。

挑戰

代理給出自信的回答，但如何證明它在涉及真實資金時可靠運行？工具選擇錯誤導致錯誤的搜索結果，損害經銷商信任。語義搜索誤解返回不相關的結果。像“汽油、混合動力和電動車，車齡不超過5年”這樣的查詢要求代理正確解析多個約束。多輪對話中的上下文漂移丟失經銷商的細化要求。非確定性輸出使得單次測試不可靠。

解決方案

Motorway和AWS共同構建了一個端到端評估管道，將錯誤結果從每8次查詢1次減少到每50次1次，並將問題檢測時間從幾小時縮短到幾分鐘。該管道結合了Strands Agents SDK與Amazon Bedrock AgentCore，這是一項用於大規模部署和運營AI代理的完全託管服務。在本文中，您將學習如何為自己的代理構建此管道：

兩階段評估策略：構建時測試使用strands-agents-evals（Strands Agents的開源評估庫），生產監控使用Amazon Bedrock AgentCore Evaluations。

三層框架評估工具使用、推理和輸出質量。

五階段部署管道，質量門控在指標低於閾值時阻止發佈。

附帶存儲庫提供了一個可部署的藍圖，您可以將其適配到自己的代理。儘管藍圖使用AWS服務，但核心原則是任何生產就緒AI代理所必需的且與系統無關。這些原則包括三層評估框架和使用pass^k指標來確保一致性。

先決條件

要遵循本文，您必須具備以下先決條件：

具有Amazon Bedrock、AWS Lambda、Amazon S3、Amazon DynamoDB、Amazon EventBridge、Amazon CloudWatch和Amazon SNS權限的AWS賬户。

已安裝並引導AWS CDK v2。

Python 3.14+。

通過Amazon Bedrock模型訪問獲得Anthropic Claude模型和Amazon Titan模型的訪問權限。

熟悉Python、AWS CDK和代理概念（工具調用、多輪對話）。

完成時間：初始部署30-45分鐘，為您的域定製2-3小時。

預估成本：運行示例評估套件大約需要5-10美元的Amazon Bedrock推理費用。生產監控成本因採樣率而異。

安全説明：附帶存儲庫實現了最低權限的AWS IAM角色，將API密鑰存儲在AWS Systems Manager Parameter Store中（而不是環境變量），並使用類型化參數幫助防止注入攻擊。詳情請參閲存儲庫README。

工作示例：經銷商庫存搜索代理

Motorway基於Strands Agents SDK和Amazon Bedrock AgentCore構建了經銷商庫存搜索代理。該代理暴露了八個工具，結合了對超過89個車輛屬性的結構化過濾和由LanceDB及Amazon Titan Text Embeddings V2支持的向量相似性搜索。

經銷商通常花費數小時使用CSV和剛性過濾器瀏覽列表。通過引入對話式AI代理，經銷商現在可以與代理對話：“找一下我經銷商附近2.5萬英鎊以下的柴油SUV”或“適合家庭、運動且自動擋的車”。

在高峯時段大約有1,500個併發用户時，代理行為的正確性不是可選的。工具選擇錯誤或語義搜索誤解會直接影響用户信任。圖1顯示了端到端請求流程：經銷商通過Web界面提交自然語言查詢，路由到Amazon Bedrock AgentCore運行時。運行時協調對八個不同工具的調用，同時使用Amazon Bedrock模型（Claude用於推理，Amazon Titan用於嵌入）。工具響應通過運行時返回，生成最終的面向經銷商的結果。

為什麼代理評估不同

LLM評估側重於文本生成質量：連貫性、事實準確性、響應相關性。代理評估評估的是根本不同的東西。可以這樣理解：LLM評估檢查發動機性能。代理評估評估整輛車在交通中、雨天或滿載乘客時的駕駛表現。

傳統的LLM指標無法告訴您Motorway代理是否為“Grade 1 Suzuki車型”調用了正確的搜索工具。它們無法揭示代理是否向LanceDB傳遞了正確的過濾參數。它們還錯過了經銷商從上一輪細化結果時是否得到正確響應。

評估維度 為什麼它對代理很重要

任務完成 代理運行多步驟工作流，部分完成很常見

工具使用正確性 錯誤的工具或錯誤參數可能破壞整個工作流

推理連貫性 有缺陷的推理導致條件變化時不可預測的失敗

可靠性和一致性 非確定性意味着相同輸入可能產生不同輸出

安全性和合規性 自主代理可能採取有現實世界後果的行動

成本和效率 每個任務需要50次API調用的代理可能在經濟上不可行

精確查詢如“大眾高爾夫7-12年車齡”可能完美工作，但口語化變體如“我在找一輛較舊的大眾”可能在語義搜索層未正確評估時失敗。

在部署前使用strands-agents-evals捕獲問題

該藍圖實現了兩個階段的評估，映射到GenAIOps生命週期。構建時評估在部署前捕獲問題，生產評估捕獲合成測試遺漏的問題。以下圖表（圖2）顯示了工具使用、推理和輸出質量層在部署前必須通過。該框架評估三個層：

第1層（工具使用）：驗證正確的工具選擇和參數傳遞，閾值大於95%。

第2層（推理）：評估邏輯決策，閾值大於85%。

第3層（輸出質量）：測量響應幫助性和準確性，閾值大於90%。所有三層必須通過才能繼續部署。

在開發和CI/CD期間，管道使用strands-agents-evals框架在部署前捕獲問題。它提供輸出驗證、軌跡評估、多輪對話模擬和自動實驗生成。每個都旨在與基於Strands Agents SDK構建的代理原生工作。該框架提供三個原語：

實驗：針對代理運行的測試用例集合。

案例：輸入查詢、預期輸出和預期工具軌跡。

評估器：評分邏輯（確定性或基於LLM）。

將測試組織成層。第1層運行確定性基於代碼的評分器，用於工具選擇準確性。第2層和第3層使用LLM作為評判評估器（使用LLM對代理輸出評分）進行推理和輸出質量。

自定義評估器子類處理特定域的問題。對於Motorway代理，這些涵蓋數據新鮮度、經銷商範圍和安全護欄。您的代理會有自己的域約束。

三種類型的評分器

評估框架使用三種評分器類型，每種適用於不同的評估需求。

評分器類型 層 測量內容 權衡

基於代碼的確定性 第1層 工具選擇、參數傳遞、軌跡順序 快速、廉價、可重複

LLM作為評判（Claude Sonnet 4.6） 第2-3層 推理質量、輸出幫助性、目標成功 靈活；非確定性（通過pass^k控制）

人工審查 校準 邊界情況和安全性 昂貴；用於校準LLM評判提示

在實踐中，評估代理產生的內容比評估其路徑能捕獲更多問題。您關心的是用户是否獲得了相關結果，而不是代理先調用了哪個工具。

三層評估框架

構建時評估在三個不同的層上運行，每個層有特定的通過/失敗閾值。

第1層：工具使用（>95%閾值）。代理是否調用了正確的工具並帶有正確的參數？

“柴油車輛，價格從7,000英鎊到20,000英鎊”應使用search_vehicles並帶有類型化過濾器（fuel_type=diesel, min_price=7000, max_price=20000）。

“現代掀背車，低里程”應觸發hybrid_search，結合語義嵌入和結構化過濾器。

您以確定性方式測量：ToolSelectionGrader檢查調用了哪些工具，TrajectoryOrderGrader驗證調用順序。

第2層：推理（>85%閾值）。決策過程是否邏輯？HelpfulnessEvaluator和TrajectoryEvaluator使用LLM作為評判評分來評估代理的推理是否合理。通過不合理推理得到正確響應的代理將在條件變化時不可預測地失敗。

第3層：輸出質量（>90%閾值）。響應是否有幫助、準確且可操作？OutputEvaluator和GoalSuccessRateEvaluator使用LLM作為評判評估來評估用户是否獲得了有用、格式良好的響應。

三層必須在部署前通過。某一層失敗會阻塞管道。

處理非確定性

由於LLM輸出在不同運行之間變化，單次測試結果可能具有誤導性。附帶存儲庫中的run_all_layers()函數接受num_trials參數來解決這個問題。來自代碼生成研究社區的兩個指標有助於衡量可靠性：

pass@k衡量在k次嘗試中至少成功一次的可能性。當找到一個正確解決方案就足夠時，此指標很有用。

pass^k衡量在k次連續試驗中成功的概率。當用户期望每次行為都可靠時，此指標很有用。

對於面向客户的代理，pass^k最重要。一個每次試驗成功率為75%的代理只有42%的機會通過三次連續試驗（0.75³）。用户期望每次交互都有一致的質量。

在附帶代碼中，run_all_layers(task_fn, registry, num_trials=5)運行具有多試驗支持並基於pass^k門控部署的評估層。請參閲完整實現。

測試用例管理

測試用例按類別組織：

快樂路徑：應成功的常見查詢。

邊界情況：模糊查詢、俚語、多輪細化。

安全/護欄：代理應拒絕或重定向的查詢。

當生產監控檢測到問題時，該交互成為新的測試用例。Motorway的測試套件在三個月內從最初的50個案例增長到150個，每個都基於真實用户行為。從20到50個案例開始，讓生產數據增長套件。

包括負面案例，即代理不應調用某些工具的情況。例如，配置文件查詢應調用配置文件工具，而不是搜索工具。結構化查詢應使用結構化搜索，而不是原始SQL回退。單方面評估會導致單方面優化。

多輪對話測試

單輪評估遺漏了一個關鍵維度：對話連貫性。經銷商自然地在多輪中細化搜索：

第1輪：“找一下柴油SUV。”

第2輪：“現在只顯示自動擋的。”

第3輪：“看看旅行版呢？”

（文末因成本控制截斷）