AI Agent 評估正在變成一個產品類別：Strands Evals、Agent-EvalKit、Langfuse 怎麼分工

摘要：一週內 AWS 連發兩個 AI agent 評估工具 — Strands Evals 專門診斷 agent 為什麼失敗，Agent-EvalKit 系統化評估整條執行路徑 — 加上持續走紅的開源觀測工具 Langfuse，「評估 agent」正在從附屬功能變成一個獨立的工具品類。當 agent 多到需要專門工具抓它何時失敗、為何失敗，這三個怎麼分工、怎麼選？

• AWS 在 2026 年 6 月 11 日推出開源的 Agent-EvalKit、6 月 15 日推出 Strands Evals，剛好補上「系統化評估」與「故障根因診斷」兩端。
• Strands Evals 把執行軌跡比對九大故障分類，並用兩階段流程分出根因與下游症狀，宣稱把診斷時間從數小時壓到數分鐘。
• Agent-EvalKit 評估的是整條執行路徑而非只看最後輸出，檢查 agent 是否真的根據工具回傳資料作答。

【核心洞察】agent 一多，問題從「會不會做」變成「為什麼做錯」

agent 上 production 之後最痛的，通常不是跑不起來，而是跑錯了卻不知道錯在哪一步。AWS 這一週的兩個發布正好對著這個痛點：6 月 11 日的 Agent-EvalKit 做系統化評估，6 月 15 日的 Strands Evals 做故障診斷。配上一直在開源圈走紅的 Langfuse，可以看出「評估與觀測 agent」正在長成一個獨立品類。

【深度拆解】

Strands Evals：把「為什麼失敗」自動化

Strands Evals 是一個做故障偵測（failure detection）與根因分析（root cause analysis）的 SDK。它把 agent 的執行軌跡比對一套九大類故障分類：幻覺、錯誤動作、編排錯誤、未遵守任務指令、執行錯誤、context 處理錯誤、重複行為、LLM 輸出問題、設定不符。

它的偵測流程分兩階段，都由 LLM 驅動：第一階段標出故障、給信心分數與佐證；第二階段判斷因果關係（分 PRIMARY／SECONDARY／TERTIARY），把根因和下游症狀分開，並產出修正建議 — 例如歸類成「該改 system prompt」或「該改 tool description」。它相容 OpenTelemetry tracing、可接 CloudWatch Logs，也吃得下 Langchain 等框架產生的軌跡。AWS 的說法是，這能把原本靠人工逐筆看 trace 的診斷時間，從數小時壓到數分鐘。

Agent-EvalKit：評估整條路徑，不只看最後答案

Agent-EvalKit 是一個開源（Apache 2.0）工具，核心主張是「評估 agent 不能只看最終輸出」。它要查的是：agent 有沒有真的根據工具回傳的資料作答、有沒有正確選擇與帶入工具參數，而不是答得漂亮卻其實跳過了驗證、甚至在幻覺。

用法很特別 — 它透過現有的 coding assistant（Claude Code、Kiro CLI、Kilo Code）以 slash command 操作，由助手跑完六個依序階段：Plan、Data、Trace、Run agent、Eval、Report，每個階段產出的成果餵給下一階段。它支援 Strands Agents、LangGraph、CrewAI 等框架，用 Amazon Bedrock 做推論，計算的指標包含 Faithfulness（忠實度）、Tool Parameter Accuracy（工具參數準確度）、Response Quality（回應品質），最後給出對應到具體程式碼位置的優先修正建議。

Langfuse 補的是「持續觀測」那一塊

<

p>Langfuse 是開源的 LLM 可觀測性平台，做 trace、評估、prompt 管理，GitHub 上約有 29.2k 顆星。如果說前兩個工具偏「開發與測試期」的評估和診斷，Langfuse 偏的是「上線後的長期追蹤」。三者拼起來會是一條線：Agent-EvalKit 系統化評估、Strands Evals 深挖故障根因、Langfuse 持續觀測線上行為。

【我的觀點】

我認為「agent 評估」變成一個獨立工具品類，本身就是 agentic AI 從 demo 走向 production 的明確訊號。會做 demo 的人很多，能說清楚「我的 agent 為什麼失敗、失敗在哪一步」的人少得多 — 而後者才是真正能上 production 的門檻。工具開始往這個方向長，代表市場的痛點已經從「做得出來」移到「靠不靠得住」。

工具怎麼選，我的判斷是別一次全上。先用 Langfuse 之類的工具把 trace 接起來，沒有 trace，後面所有診斷都是瞎子摸象；需要系統化跑評估時再加 Agent-EvalKit；等故障多到人工查不動，再上 Strands Evals 做根因分析。要留意的是，Strands Evals 和 Agent-EvalKit 都深度綁 AWS／Bedrock 生態，非 AWS 用戶導入前要先想清楚鎖定問題。

對台灣團隊，我的務實建議是：把「agent 評估」當成跟單元測試同級的工程紀律來建，工具其次。沒有評估流程，換哪個工具都救不了；有了流程，工具只是把它自動化而已。

【常見問題 FAQ】

Strands Evals 跟 Agent-EvalKit 有什麼不同

Strands Evals 專做故障偵測與根因分析，回答「agent 為什麼失敗、根因在哪」；Agent-EvalKit 做整條執行路徑的系統化評估，回答「agent 有沒有忠實依據工具資料作答」。兩者可搭配使用，Agent-EvalKit 本身就支援呼叫 Strands Evals 做指標評估。

評估 AI agent 為什麼不能只看最後輸出

agent 可能答得漂亮，卻跳過了驗證步驟、選錯工具或產生幻覺。只看最終結果會漏掉過程中的錯誤，等於不知道這次成功是真的可靠還是運氣好。所以要評估整條工具呼叫路徑，而不只是終點。

這些工具一定要用 AWS 嗎

Strands Evals 與 Agent-EvalKit 都深度整合 Amazon Bedrock，但相容 OpenTelemetry 與 Langchain 等開放標準；Langfuse 為開源、可獨立部署。非 AWS 用戶仍可使用，但前兩者在 AWS 生態內整合最順。

---

原文出處：AI Agent Failure Detection and Root Cause Analysis with Strands Evals（AWS）、Evaluate AI agents systematically with Agent-EvalKit（AWS）、langfuse/langfuse（GitHub）