2026年被業(yè)界公認(rèn)為"AI Agent爆發(fā)元年"。從年初Manus驚艷亮相到各大廠商密集發(fā)布Agent產(chǎn)品，AI智能體正以前所未有的速度從實(shí)驗(yàn)室走進(jìn)生產(chǎn)環(huán)境。

據(jù)IDC最新預(yù)測(cè)，全球AI Agent市場(chǎng)規(guī)模將在2026年突破1.2萬(wàn)億元人民幣。但熱鬧之下，一個(gè)幽靈般的難題正在困擾每一位Agent開(kāi)發(fā)者——

"我的Agent到底行不行？"

你可能也有過(guò)這樣的經(jīng)歷：你的AI Agent在Demo里表現(xiàn)完美、驚艷四座，領(lǐng)導(dǎo)看了直呼"就按這個(gè)上"。然后你興沖沖地部署上線，結(jié)果真實(shí)用戶一用——工具調(diào)錯(cuò)了、回答跑偏了、各種你沒(méi)想過(guò)的翻車場(chǎng)景層出不窮。

這不是你的錯(cuò)。傳統(tǒng)軟件測(cè)試的方法論，放在AI Agent身上，就像用體溫計(jì)去測(cè)地震——工具不對(duì)，結(jié)果自然不靠譜。

國(guó)際云計(jì)算巨頭AWS顯然也意識(shí)到了這個(gè)痛點(diǎn)。近日，亞馬遜云科技正式發(fā)布了Amazon Bedrock AgentCore Evaluations，一個(gè)專門為AI Agent"體檢"的全托管評(píng)估服務(wù)。簡(jiǎn)單來(lái)說(shuō)，它就像給你的AI Agent配了一個(gè)"質(zhì)檢部門"——不只是告訴你"行"或"不行"，而是給你一份詳細(xì)的診斷報(bào)告。

（報(bào)告?zhèn)魉烷T：https://aws.amazon.com/cn/blogs/machine-learning/build-reliable-ai-agents-with-amazon-bedrock-agentcore-evaluations/）

為什么傳統(tǒng)測(cè)試對(duì)AI Agent"水土不服"？

要理解這個(gè)問(wèn)題，首先得明白AI Agent和傳統(tǒng)軟件的根本區(qū)別。

傳統(tǒng)軟件測(cè)試，本質(zhì)上是一種確定性驗(yàn)證：同樣的輸入，期望得到同樣的輸出。測(cè)試用例是固定的，判斷標(biāo)準(zhǔn)也是固定的。單元測(cè)試、集成測(cè)試、端到端測(cè)試——這套方法論運(yùn)行了幾十年，可以說(shuō)是相當(dāng)成熟了。

但AI Agent不一樣。它的底層是大語(yǔ)言模型（LLM），而LLM天生就是非確定性的。同一個(gè)用戶問(wèn)題，你問(wèn)三次，Agent可能給出三種不同的回答——選了不同的工具、走了不同的推理路徑、產(chǎn)出了不同的最終答案。

這意味著什么？意味著一次測(cè)試的結(jié)果，只能告訴你"可能發(fā)生什么"，而不是"通常發(fā)生什么"。

更要命的是，當(dāng)用戶和Agent交互時(shí)，整個(gè)決策鏈路是這樣的：

1.工具選擇——Agent決定要不要調(diào)用工具、調(diào)用哪個(gè)工具；

2.參數(shù)構(gòu)造——Agent構(gòu)造傳給工具的參數(shù)是否正確；

3.結(jié)果合成——Agent把工具返回的結(jié)果整合成最終回答是否準(zhǔn)確。

每一個(gè)環(huán)節(jié)都可能出問(wèn)題，而傳統(tǒng)測(cè)試只關(guān)注最終輸出是否正確。就好比考試，你只看總分，不看各科成績(jī)——就算總分及格了，你可能都不知道數(shù)學(xué)其實(shí)掛了。

AWS在這篇博文中點(diǎn)出了一個(gè)殘酷的現(xiàn)實(shí)：很多團(tuán)隊(duì)陷入了"手動(dòng)測(cè)試 → 發(fā)現(xiàn)問(wèn)題 → 修提示詞 → 再手動(dòng)測(cè)試"的死循環(huán)，燒了大量的API費(fèi)用，卻始終說(shuō)不清一件事——

"這個(gè)Agent現(xiàn)在到底比上次好了沒(méi)有？"

這個(gè)問(wèn)題答不上來(lái)，每一次改動(dòng)就都是一場(chǎng)賭博。

AgentCore Evaluations：給Agent裝上"行車記錄儀+體檢系統(tǒng)"

Amazon Bedrock AgentCore Evaluations 的核心思路可以概括為一句話：把"感覺(jué)不錯(cuò)"變成"數(shù)據(jù)說(shuō)話"。

這個(gè)服務(wù)最初在2025年12月的AWS re:Invent大會(huì)上以公開(kāi)預(yù)覽版發(fā)布，現(xiàn)在已經(jīng)正式可用（GA）。它背后有三個(gè)基本原則：

原則一：證據(jù)驅(qū)動(dòng)開(kāi)發(fā)——用量化指標(biāo)替代直覺(jué)判斷。修改提示詞之后，"感覺(jué)好了"不算數(shù)，數(shù)據(jù)提升了才算數(shù)。

原則二：多維度評(píng)估——不是籠統(tǒng)地打一個(gè)總分，而是獨(dú)立評(píng)估工具選擇、參數(shù)精度、回答質(zhì)量等各個(gè)維度，精確定位問(wèn)題。

原則三：持續(xù)度量——從開(kāi)發(fā)測(cè)試到生產(chǎn)監(jiān)控，用同一套評(píng)估標(biāo)準(zhǔn)貫穿Agent的整個(gè)生命周期。

在技術(shù)實(shí)現(xiàn)上，這個(gè)服務(wù)有一個(gè)亮點(diǎn)：它基于OpenTelemetry（OTEL）標(biāo)準(zhǔn)。OpenTelemetry是一個(gè)開(kāi)源的可觀測(cè)性標(biāo)準(zhǔn)，而AgentCore Evaluations在此基礎(chǔ)上加入了生成式AI的語(yǔ)義約定（包括提示詞、補(bǔ)全結(jié)果、工具調(diào)用、模型參數(shù)等），這意味著——無(wú)論你的Agent是用Strands Agents還是LangGraph構(gòu)建的，只要接入了OpenTelemetry或OpenInference，就能直接用這套評(píng)估體系。

翻譯成人話就是：它是框架無(wú)關(guān)的。你不被鎖定在AWS的生態(tài)里。

三種評(píng)估方式：總有一款適合你

AgentCore Evaluations支持三種評(píng)估方式，靈活度相當(dāng)高：

1. LLM-as-a-Judge（LLM當(dāng)裁判）

這是最核心的方式。簡(jiǎn)單說(shuō)，就是用一個(gè)大模型來(lái)評(píng)判另一個(gè)大模型的輸出。裁判模型會(huì)審視整個(gè)交互上下文——包括對(duì)話歷史、可用工具、實(shí)際調(diào)用的工具和參數(shù)、系統(tǒng)指令等——然后給出評(píng)分和詳細(xì)的推理過(guò)程。

值得一提的是，每個(gè)分?jǐn)?shù)都附帶解釋。不是冷冰冰的一個(gè)數(shù)字，而是告訴你"為什么給這個(gè)分"和"哪里可以改進(jìn)"。這比單純的人工審查效率高得多。

2. Ground Truth（對(duì)標(biāo)標(biāo)準(zhǔn)答案）

如果你有領(lǐng)域知識(shí)，知道"正確答案"應(yīng)該是什么，可以用這種方式。比如你可以預(yù)先定義期望的工具調(diào)用序列、期望的回答內(nèi)容、或者期望達(dá)成的目標(biāo)狀態(tài)，然后讓系統(tǒng)比較Agent的實(shí)際行為和你的標(biāo)準(zhǔn)答案之間有多大的差距。

3. 自定義代碼評(píng)估器

有些時(shí)候，你需要的是確定性檢查，比如：Agent有沒(méi)有返回精確的賬戶余額$8,333.33？生成的請(qǐng)求ID是否符合PTO-2026-NNN的格式？這類問(wèn)題LLM裁判不一定靠譜，但一段代碼就能搞定。AgentCore Evaluations允許你接入AWS Lambda函數(shù)，用自定義代碼來(lái)做精確校驗(yàn)。而且Lambda調(diào)用的成本只有LLM推理的一小部分，適合大規(guī)模生產(chǎn)環(huán)境下的高頻評(píng)估。

在線評(píng)估 vs 按需評(píng)估：雙管齊下

AgentCore Evaluations最巧妙的設(shè)計(jì)之一，是它把評(píng)估分成了兩種模式，分別覆蓋Agent生命周期的不同階段：

在線評(píng)估的邏輯很直觀：系統(tǒng)會(huì)從生產(chǎn)流量中持續(xù)采樣一定比例的Agent交互（采樣率可配置），自動(dòng)評(píng)分并展示在AgentCore Observability儀表板上。一個(gè)很關(guān)鍵的洞察是：很多時(shí)候，傳統(tǒng)的運(yùn)維監(jiān)控（延遲、錯(cuò)誤率）都是綠的，但用戶體驗(yàn)已經(jīng)在悄悄惡化——因?yàn)锳gent可能開(kāi)始選錯(cuò)工具了、回答沒(méi)那么有幫助了，但系統(tǒng)層面并沒(méi)有報(bào)錯(cuò)。在線質(zhì)量評(píng)分能抓住這種"無(wú)聲的退化"。

按需評(píng)估則更像是開(kāi)發(fā)者的"實(shí)驗(yàn)室"。你選擇特定的交互（通過(guò)trace ID或span ID），指定評(píng)估器，系統(tǒng)會(huì)給出詳細(xì)的評(píng)分和解釋。最適合的場(chǎng)景包括：驗(yàn)證提示詞修改的效果、對(duì)比不同模型的性能、在CI/CD流水線里做回歸測(cè)試。

兩種模式使用同一套評(píng)估器，這意味著你在開(kāi)發(fā)階段測(cè)試的標(biāo)準(zhǔn)，和生產(chǎn)環(huán)境監(jiān)控的標(biāo)準(zhǔn)是完全一致的。不會(huì)出現(xiàn)"開(kāi)發(fā)環(huán)境一切正常，上線就翻車"的尷尬。

13個(gè)內(nèi)置評(píng)估器：從"工具選對(duì)了嗎"到"用戶滿意了嗎"

這是整篇文章最"干貨"的部分。AgentCore Evaluations把Agent交互組織成三層結(jié)構(gòu)，對(duì)應(yīng)不同粒度的評(píng)估需求：

這三層分開(kāi)評(píng)估的價(jià)值在于精確定位問(wèn)題。比如你的Agent可能工具選對(duì)了、參數(shù)也傳對(duì)了，但最終生成的回答質(zhì)量很差——這種情況只有在獨(dú)立評(píng)估各層之后才能發(fā)現(xiàn)。

但更有意思的是評(píng)估器之間的關(guān)系和權(quán)衡。AWS在這篇文中分享了一些非常實(shí)用的洞察：

依賴關(guān)系：

• "工具參數(shù)準(zhǔn)確率"只有在"工具選擇準(zhǔn)確率"高的前提下才有意義——先確保選對(duì)工具，再優(yōu)化參數(shù)
• "正確性"往往依賴于"上下文相關(guān)性"——沒(méi)有正確的信息輸入，就不可能生成正確的回答

矛盾關(guān)系：

• "簡(jiǎn)潔性"和"有幫助性"經(jīng)常沖突——過(guò)于簡(jiǎn)潔的回答可能省略了用戶需要的上下文信息

這些洞察對(duì)于實(shí)際調(diào)優(yōu)Agent非常有價(jià)值。比如你發(fā)現(xiàn)"正確性"分?jǐn)?shù)低，別急著改回答生成邏輯——先去查查"上下文相關(guān)性"是不是也不高，也許問(wèn)題出在信息檢索環(huán)節(jié)。

實(shí)戰(zhàn)建議：從"盲人摸象"到"精準(zhǔn)診斷"

AWS在文中還分享了一些實(shí)用的最佳實(shí)踐和常見(jiàn)問(wèn)題排查模式：

• 診斷模式一：所有評(píng)估器分?jǐn)?shù)都很低

通常說(shuō)明是基礎(chǔ)性問(wèn)題。優(yōu)先檢查：上下文相關(guān)性（Agent有沒(méi)有獲取到正確信息？）、系統(tǒng)提示詞（是否有模糊或矛盾的指令？）、工具描述（是否準(zhǔn)確解釋了工具的用途和使用方式？）。

• 診斷模式二：相似交互分?jǐn)?shù)不一致

大概率是評(píng)估器配置問(wèn)題，而非Agent本身的問(wèn)題。檢查自定義評(píng)估器的指令是否足夠具體、每個(gè)評(píng)分等級(jí)是否有清晰可區(qū)分的定義。也可以考慮降低評(píng)估模型的溫度參數(shù)，讓評(píng)分更穩(wěn)定。

• 診斷模式三：工具選擇準(zhǔn)確但目標(biāo)完成率低

說(shuō)明Agent選對(duì)了工具，但沒(méi)能完成用戶的目標(biāo)?？赡茉颍喝鄙倌承┍匾墓ぞ?、或者Agent難以處理需要多步順序調(diào)用的任務(wù)。建議同時(shí)查看"有幫助性"分?jǐn)?shù)。

在整體策略上，AWS建議：

從3-4個(gè)評(píng)估器開(kāi)始，根據(jù)你的Agent類型選擇最關(guān)鍵的那些。比如客服型Agent優(yōu)先關(guān)注"有幫助性"和"目標(biāo)完成率"；RAG型Agent重點(diǎn)看"正確性"和"忠實(shí)性"；工具密集型Agent盯緊"工具選擇準(zhǔn)確率"和"工具參數(shù)準(zhǔn)確率"。

每個(gè)問(wèn)題至少測(cè)10遍，按類別分組統(tǒng)計(jì)方差，看看你的Agent在哪些方面穩(wěn)定、哪些方面還需要打磨。

每次改動(dòng)前后都做對(duì)照實(shí)驗(yàn)，讓數(shù)據(jù)來(lái)說(shuō)話，而不是憑感覺(jué)說(shuō)"好像好了點(diǎn)"。

行業(yè)的"房間里的大象"

跳出AWS的產(chǎn)品視角，我們來(lái)看看這個(gè)行業(yè)趨勢(shì)。AgentCore Evaluations的發(fā)布，折射出的是整個(gè)AI Agent行業(yè)正面臨的一個(gè)共性挑戰(zhàn)：從"能不能用"到"用得好不好"的范式轉(zhuǎn)變。

Gartner在2025年的報(bào)告中就指出，到2028年，33%的企業(yè)軟件將內(nèi)嵌Agent能力，而到2026年，AI Agent的商業(yè)化落地將從探索期進(jìn)入規(guī)?；渴鹌凇＿@意味著，Agent的可靠性和可衡量性將成為企業(yè)選型的關(guān)鍵決策因素。

事實(shí)上，"LLM-as-a-Judge"這個(gè)概念早在2023年就被學(xué)術(shù)界提出（參考論文《LLM-as-a-Judge: Scaling Evaluation for LLM-at-Work》），但將其工程化、產(chǎn)品化并整合進(jìn)Agent全生命周期管理平臺(tái)，AWS這次可以說(shuō)是走在了前面。

這給行業(yè)的信號(hào)很明確：AI Agent的質(zhì)量評(píng)估不能再是"玄學(xué)"，必須變成"科學(xué)"。未來(lái)，一個(gè)成熟的Agent產(chǎn)品，不僅要能"做事"，還要能"證明自己做得好"。

回到開(kāi)頭那個(gè)問(wèn)題——"我的Agent到底行不行？"

Amazon Bedrock AgentCore Evaluations給出的答案是：不要猜，去測(cè)。不是隨便測(cè)測(cè)，而是用系統(tǒng)化的、多維度的、貫穿全生命周期的評(píng)估體系來(lái)持續(xù)測(cè)量和改進(jìn)。

對(duì)于行業(yè)外的讀者來(lái)說(shuō)，這件事的意義在于：AI Agent正在從"實(shí)驗(yàn)室玩具"進(jìn)化為"生產(chǎn)級(jí)工具"，而這個(gè)進(jìn)化的關(guān)鍵一步，就是建立可靠的"質(zhì)量體檢體系"。就像汽車工業(yè)的發(fā)展——不是發(fā)動(dòng)機(jī)技術(shù)最關(guān)鍵，而是碰撞測(cè)試、耐久測(cè)試、排放檢測(cè)等一整套質(zhì)檢標(biāo)準(zhǔn)，讓普通消費(fèi)者敢放心上路。

對(duì)于業(yè)內(nèi)人士來(lái)說(shuō)，AgentCore Evaluations提供了一個(gè)值得參考的評(píng)估框架，尤其是三層評(píng)估體系（會(huì)話/追蹤/工具）、評(píng)估器間的依賴與權(quán)衡關(guān)系、以及在線評(píng)估+按需評(píng)估的雙模式設(shè)計(jì)，都具有較高的借鑒價(jià)值。

當(dāng)然，這套體系也不是萬(wàn)能藥。它評(píng)估的是"質(zhì)量"維度，而Agent的商業(yè)成功還需要綜合考慮延遲、成本、用戶體驗(yàn)等多個(gè)因素。但至少，當(dāng)我們討論"這個(gè)Agent行不行"的時(shí)候，終于可以有數(shù)據(jù)支撐了——

告別"盲人摸象"，擁抱"精準(zhǔn)診斷"。

（本文首發(fā)鈦媒體APP，作者 | 硅谷Tech_news，編輯 | 焦燕）