智能體評估在結合快速變化的在線信號與穩定的離線基線時最為強大。要了解智能體是否真正隨時間改進，除了不斷變化的真實世界流量，還需要一個固定的基準。
在Amazon Bedrock AgentCore中將測試用例作為數據集管理評估基線，為智能體評估帶來了版本化測試固定組件的紀律。您可以編寫包含輸入、預期輸出、斷言和工具序列的場景，然後將其發佈為不可變的編號版本，這些版本不會在運行中發生變化。您可以自由地迭代可變草案，直到準備好鎖定檢查點。當生產環境出現故障時，該故障將成為永久測試用例，未來每次更改都將對其進行評估。
在本文中，我們通過一個金融市場情報智能體演示完整的工作流程。我們從生產跟蹤中捕獲故障，構建版本化數據集，運行評估，修復智能體，並針對相同的鎖定輸入確認改進。
為什麼數據集很重要
智能體本質上是非確定性的。相同的輸入在不同運行中可能產生不同輸出，這使得單個評估結果幾乎毫無意義。您無法判斷得分變化是因為智能體改變了還是因為模型採樣不同。只有在穩定輸入上進行一致測量，才能知道更改是否真正有效。
但僅靠穩定輸入是不夠的。大型語言模型（LLM）評判器可以判斷回覆是否聽起來有幫助，但它無法判斷股票價格是否準確、經紀人工作流是否按正確順序運行、或者會話之間是否泄露了個人身份信息（PII）。對於這些檢查，您需要真實情況：預期響應、所需工具序列以及無論回覆如何措辭都必須成立的斷言。真實情況將主觀分數轉變為可驗證的測量。沒有它，您測量的是正確性的表象，而非正確性本身。
版本化數據集同時提供這兩者。它們固定輸入以便分數跨運行可比，並攜帶使分數有意義的真實情況。這在智能體評估實際發生的兩個地方最為重要。
內循環是開發者桌面。您調用智能體、讀取分數、調整工具描述、再次調用。週期只有幾分鐘。在這個階段，問題不在於運行評估，而在於測試用例往往是附近已有的內容：某人上週寫的問題或偶然保存的會話。當分數提高時，您希望相信修復有效。但如果沒有下面的穩定輸入，您無法知道智能體是變好了還是問題變容易了。
外循環是CI/CD管道。在更改上線前，需要有人確認它沒有破壞任何東西。大多數團隊都有這個門控。但他們往往缺少的是帶有明確斷言的穩定、版本化輸入集。這意味着門控測試的是某人最後指向的內容，沒有真實情況可對照。一個因為問題改變而通過構建的管道不是在捕捉迴歸，而是在遺漏迴歸。
版本化數據集彌補了這一差距。開發者在內循環中將故障整理到草案中。在外循環中，該草案的已發佈版本成為門控。它是不可變的，真實情況完好無損，並且測試與上個迭代及更早迭代相同的場景。告知開發者修復有效的相同分數，也是管道用於決定是否上線的分數。
兩種類型的測試場景
Amazon Bedrock AgentCore中的數據集支持兩種模式類型，分別為這兩個循環服務。
預定義場景是向後看的。您已定義了用户將發送給智能體的確切查詢，並且知道正確結果的樣子：預期響應、工具序列和必須成立的斷言。將其寫下來，評估器檢查智能體是否滿足。一旦故障被形式化為預定義場景，它就會保留在未來的每次評估運行中。它們屬於外循環門控，因為通過和失敗標準是明確、可重複且不依賴於對話過程的。
用户模擬場景是向前看的。您不是編寫對話輪次，而是描述一個角色：參與者是誰、他們想要實現什麼以及如何溝通。LLM驅動的角色與您的智能體進行真實的多輪對話，直到目標達成或達到輪次限制。您不編寫角色的發言內容。覆蓋範圍從交互中自然產生。更多信息，請參閲AgentCore用户指南中的用户模擬。
這與標準評估工具包中的任何內容都不同。預定義場景測試您的智能體是否正確處理特定輸入。模擬場景測試您的智能體是否能夠滿足某類用户的需求，無論該用户採取何種路徑。
在本文中，我們以市場趨勢智能體為例。該智能體為金融機構的投資經紀人服務。經紀人向智能體發送類似“我是來自摩根士丹利的Sarah Chen，專注於科技和清潔能源——今天NVDA有什麼情況？”的消息。智能體識別經紀人，在AgentCore Memory中存儲其偏好，檢索當前NVIDIA股票價格，並搜索Bloomberg和Reuters的相關新聞。然後提供個性化簡報，將數據與Sarah的投資重點聯繫起來。當Sarah第二天回來時，智能體會記住她的檔案並相應調整響應。
對於預定義場景，您可能有用户與智能體交互的生產跟蹤，您可以將其整理到評估數據集中。市場趨勢智能體的示例如下：
PreDefinedScenario{ "scenario_id": "broker_profile_onboarding", "turns": [ { "input": ( "嗨，我是來自摩根士丹利的Sarah Chen。" "我專注於科技和清潔能源。" "風險承受能力：中高。" "客户羣：機構和高淨值。" ) } ], "expected_trajectory": {"toolNames": ["identify_broker", "update_broker_financial_interests"]}, "assertions": [ "智能體按姓名和公司識別經紀人。", "智能體存儲經紀人的行業偏好和風險承受能力。", "智能體確認收到檔案並提供幫助。" ], "metadata": {"category": "onboarding", "priority": "high"}, }
模擬的高級科技分析師可能會以關於NVIDIA Corporation普通股的廣泛問題開始。當回覆顯得單薄時她會追問，要求與AMD比較，並且只有在獲得可供客户電話引用的內容時才完成。沒有人編寫這些輪次。角色從檔案中生成了它們。您可以定義如下場景：
SimulatedScenario( scenario_id="sim-tech-analyst-nvda-amd-deep-dive", scenario_description=( "一位高級科技研究分析師在客户電話前深入比較NVDA和AMD。" ), actor_profile=ActorProfile( traits={ "expertise": "高級", "focus": "半導體", "style": "懷疑且數據驅動" }, context=( "為高價值客户電話準備要點的賣方高級科技分析師。期待多層次分析，而非表面摘要，並在答案顯得通用或單薄時追問。" ), goal=( "通過詢問NVIDIA、要求更豐富細節、請求與AMD的結構化比較，只有在獲得可供客户對話引用的要點時才結束，從而壓力測試智能體的半導體領域深度。" ) ), input=( "我正在準備客户電話，需要關於NVIDIA的快速但紮實的簡報。從NVDA的近期表現和半導體定位開始。" ), max_turns=8, assertions=[ "智能體提供初始NVDA摘要，包括近期表現和定位", "智能體針對NVDA回應更深入的基本面、產品/路線圖或護城河細節", "智能體產生結構化的NVDA vs AMD比較（例如估值、增長、細分市場）", "智能體包含適合客户電話的特定、可引用數據點或指標" ] )
用户模擬在內循環中特別有用，當您不確定尚未發現的故障模式時。出現的故障成為下一個數據集版本中預定義場景的候選，直接反饋到外循環門控。
關於模擬底層工作原理，有幾點值得了解。角色運行在您在SimulationConfig中指定的Bedrock模型上。在每個輪次，角色接收智能體的響應併產生三件事：關於目標是否達成的內部推理、要發送的下一條消息以及停止信號。對話在角色指示完成、達到max_turns或角色未產生下一條消息時結束。由於對話路徑是動態的，模擬場景不支持expected_trajectory或逐輪expected_response。改用斷言作為真實情況，並描述無論對話如何到達那裏您期望的結果。
對於市場趨勢智能體，預定義場景覆蓋已經給經紀人帶來損失的股價漂移錯誤。模擬場景覆蓋尚未出現故障但代表智能體需要妥善處理的真實用户類型的ESG專家。
AgentCore中數據集的工作方式
數據集作為具有ARN、IAM授權和標籤的一級資源內置於AgentCore中。無需配置Amazon S3存儲桶或外部服務。
草案和發佈。每個數據集都有一個可變草案，您可以在其中自由添加和刪除場景。當您想要穩定檢查點時，發佈它。草案變為不可變的編號版本。將評估運行固定到版本3，它將使用版本3中的確切場景，無論您此後在草案中添加了什麼。
寫入時模式驗證。創建數據集時聲明模式類型，每個場景在接收前都根據該模式進行驗證。格式錯誤的示例在攝取時被拒絕，而不是在30分鐘評估運行中途作為錯誤出現。
一個數據集，多個運行器。使用DatasetManagementServiceProvider加載數據集，並將其傳遞給按需運行器以獲得每個場景的快速反饋，或傳遞給批處理運行器以獲得跨多個會話的聚合評分。無論您是在桌面迭代還是門控部署，相同的場景、斷言和數據集ID均適用。
智能體：市場趨勢助手
我們使用市場趨勢智能體，一個部署在AgentCore Runtime上的LangGraph應用程序，作為運行示例。完整源代碼在AgentCore示例存儲庫的02-use-cases/market-trends-agent目錄下。該智能體具有以下工具，幫助其處理金融經紀人的查詢：
工具 功能
get_stock_data 獲取股票代碼的當前價格、日變化、成交量。 search_news 多源金融新聞搜索（Bloomberg、Reuters、CNBC、WSJ、FT）。 identify_broker 從消息中提取經紀人身份以進行內存查找。 get_broker_financial_profile 讀取存儲的偏好、風險承受能力、行業焦點。 update_broker_financial_interests 將新偏好寫入長期記憶。
三種故障模式經常出現，值得永久測試用例：
陳舊價格——智能體引用一個與實時值漂移超過2%的數字，通常是因為重新使用了緩存的工具響應而不是進行新調用。
跳躍身份檢查——智能體在未先調用identify_broker的情況下直接跳至get_broker_financial_profile，這可能導致提取錯誤的經紀人偏好。
[為控制AI成本截斷]