如何評估生產環境中的 AI Agent：我們在即時追蹤中使用的三層系統

如何評估生產環境中的 AI Agent：我們在即時追蹤中使用的三層系統

在生產環境中評估 AI Agent，意味著要針對即時流量對 Agent 完整的多步驟軌跡進行評分，而不僅僅是最終答案：檢查每個推理步驟、驗證其是否使用正確的參數呼叫了正確的工具，並在發布後持續監控任務成功率、成本與安全性，因為 Agent 的失敗往往是靜默且非確定性的。

在 2026 年 6 月我們自己的 Techsy 內容管線的一次運行中，Agent 產出了一篇看起來完美的部落格文章，最終輸出的評分也顯示通過。一切看似乾淨無瑕。然而，回溯三個步驟之前，簡報創建者（brief-creator）呼叫了錯誤的內部連結查找工具，導致一半的叢集連結指向空頁面。了解如何在生產環境中評估 AI Agent，意味著要對 Agent 所走的整個路徑進行評分，而不僅僅是它偶然得出的答案。

關鍵重點：

• 對整個軌跡評分，而不僅是最終答案：即使答案正確，若路徑錯誤仍視為失敗。
• 從三個面向驗證工具呼叫：正確的工具、正確的參數、正確的步驟。
• 在即時生產追蹤中，以連續循環的方式在線下和線上運行相同的指標。
• 依據安全漏洞（如越獄、個人識別資訊洩露、工具濫用）來限制部署，而不僅僅是依據低準確率分數。

為什麼在生產環境中評估 AI Agent 與評估 LLM 不同？

在生產環境中評估 AI Agent 比評估模型更困難，因為 Agent 會採取多個步驟、呼叫外部工具並改變真實狀態，而且這一切都是非確定性地進行的。相同的輸入在每次運行時可能會產生不同的工具呼叫序列，因此早期的一個錯誤步驟可能會腐敗後續的所有步驟。

本指南假設您已經了解一般的 LLM 評估。如果您尚未熟悉，請先閱讀我們的 完整 LLM 評估指南，然後再回來了解當模型轉變為 Agent 時有哪些變化。（仍在建構您即將評級的 Agent 嗎？我們的 最佳 AI Agent 框架綜覽 涵蓋了底層架構。）

當您的 LLM 開始自主行動時，有四件事會立即出錯：

• 多步驟。支援 Agent 可能會搜尋知識庫、呼叫訂單 API，然後起草回覆。如果只對回覆評分，您將無法察知決定該回覆的前兩個步驟。
• 非確定性。溫度參數、模型權重更新和工具延遲意味著相同的請求在每次運行時會採取不同的路徑。您的評估必須能夠應對這種移動的目標。
• 有狀態。Agent 會寫入資料庫、發送電子郵件、退款訂單。錯誤的行為不僅僅是一個糟糕的句子，而是無法撤回的副作用。
• 累積效應。在 12 步的運行中，第 2 步的輕微錯誤會毒化下游的一切，而最終答案看起來仍然可能沒問題。

Galileo 在 2026 年 2 月的《評估工程現狀》報告中，調查了 500 多名從業人員，發現 84.9% 的團隊在發布後六個月內遭遇了 AI 事故。Anthropic 的工程團隊在其 關於 Agent 評估的文章 中直白地指出：Agent 的失敗發生在步驟、工具和意圖之間，而不僅僅是最終輸出。

一個透過錯誤軌跡返回正確答案的 Agent 並沒有通過測試。它是靜默失敗，而下一次幸運的恢復未發生時，它將會大聲失敗。

哪些指標對生產環境中的 AI Agent 真正重要？

對生產環境中的 Agent 最重要的指標超越了準確率：任務成功率、每成功任務的成本、延遲百分位數、工具呼叫準確率、忠實度、人工干預率、漂移以及安全閘門通過率。這些 AI Agent 評估指標共同捕捉了單一輸出分數所遺漏的靜默、非確定性失敗。

以下是我們在自身運行中實際關注的八項指標。请注意，其中很少有指標關心最終答案讀起來是否通順：

這些指標大多依賴 LLM-as-a-judge（一個模型對另一個模型的輸出進行評分）。這是標準技巧且具有擴展性，但存在噪聲：評判者往往共享 Agent 的盲點，因此應將其分數視為信號而非真理。我們將在第七節回頭討論如何校準評判者。

有一個指標值得特別提及。每成功任務成本是能在預算審查中存活下來的數字。普通的每任務成本會獎勵廉價的失敗，因為一個快速且錯誤放棄的 Agent 在電子表格上看起來效率很高。

如何對 Agent 的軌跡而非最終答案進行評分？

要對 Agent 的軌跡進行評分，您需要評估追蹤記錄（trace）：即 Agent 產生的每個推理步驟、工具呼叫和中間輸出的有序記錄。區段級別評估（Span-level evaluation）對每個單獨的步驟（span）進行評分，以便您可以精確定位失敗的那一步，而不僅僅是得知整體運行出錯。

將追蹤記錄想像成推理的堆疊追蹤（stack trace）。每個 區段（span） 是一個步驟：檢索、工具呼叫、子代理交接。可觀測性捕捉這些區段；評估則對其進行評分。（還沒有追蹤功能？我們的 AI 可觀測性指南 涵蓋了評分所依賴的監控層，而我們 LangGraph、CrewAI 和 OpenAI Agents SDK 的比較 展示了在各個框架中追蹤記錄的樣子。）

為什麼要對每個區段評分而不是只關注終點？因為錯誤會累積。如果第 2 步檢索了錯誤的文件，第 3 到 12 步都建立在垃圾數據之上，而幸運的最終措辭仍可能逃過僅檢查輸出的檢測。區段級別評分告訴您運行在第 2 步失敗，而不僅僅是某處失敗。

首先是與框架無關的版本（針對追蹤物件的簡單斷言），然後是使用 DeepEval 基於追蹤的 任務完成指標（Task Completion metric） 的快捷方式：

# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

與框架無關的斷言適用於硬性、確定性的檢查。當成功定義比相等檢查更模糊時，您會需要使用任務完成指標：它從追蹤記錄中提取預期任務和達成結果，並評分它們的一致性。

如何驗證 Agent 是否呼叫了正確的工具？

要驗證 Agent 的工具呼叫，需分別檢查三件事：工具選擇（是否挑選了正確的工具）、參數正確性（是否傳遞了正確的參數和值）以及執行路徑有效性（是否在正確的步驟、以正確的順序呼叫該工具）。最終答案正確但工具呼叫錯誤，代表一個尚未浮現的 bug。

這是最具 Agent 特性的評估，也是幾乎沒有人深入涵蓋的部分。多 Agent 工具使用評估分為三個問題：

1. 選擇。在可用的工具中，Agent 是否挑選了正確的工具？呼叫任何工具不等於呼叫正確的工具。
2. 參數。是否傳遞了正確的參數？正確的工具搭配錯誤的 slug 或格式錯誤的日期仍然是失敗。
3. 執行路徑。是否在正確的步驟、以正確的順序呼叫該工具？在驗證訂單之前就退款，是正確的工具但以錯誤的順序執行。

DeepEval 的 工具正確性指標（Tool Correctness metric） 處理所有這三者：它將 tools_called 與 expected_tools 進行比較，可以匹配輸入參數，並且當 should_consider_ordering=True 時也會對序列進行評分。

# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

那個 0.0 正是我們在自身管線中捕捉到的確切失敗：Agent 伸手去抓 sitemap_search，而預期的工具是 internal_link_lookup。完成的文章仍然通過了其輸出分數。工具呼叫指標是唯一標記出錯誤路徑的東西。

如何在即時生產追蹤上進行線上評估？

線上評估即時針對即時生產追蹤運行您的指標，而不僅僅是在部署前針對測試集運行。這是三層系統的第三層：在金標準集上進行離線測試、部署前的 QA 閘門，然後在即時流量上進行線上評估，並將生產追蹤記錄策劃回數據集中，使循環不斷改進。

離線測試在問題發布前捕捉回歸錯誤。但 Agent 在生產環境中遇到的輸入是金標準集未曾預料的，因此相同的指標必須在發布後繼續運行。以下是頂部圖表映射出的完整循環：

1. 離線。在 CI 中的金標準數據集上運行您的指標。若發生回歸則讓構建失敗。
2. 部署前 QA 閘門。由人工負責的检查點：這是否同時通過了準確率基準 和 安全基準（第六節）？
3. 線上。使用相同的指標即時對即時生產追蹤進行評分。
4. 策劃。自動收集真實追蹤記錄（特別是失敗案例）回到您的評估數據集中。
5. 重新運行。您的金標準集從現實中增長，而不是第一天手寫的 20 個範例。

連接線上評估與追蹤具有相同的儀器化過程，加上指標收集。Confident AI 針對即時追蹤運行 來自 DeepEval 的 50+ 評分器，並且兼容 OpenTelemetry，因此 LangGraph、CrewAI、OpenAI 和 Vercel AI SDK 無需定製適配器即可匯出：

# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# The collection's metrics now run on every trace, in real time.

回報在於策劃步驟。每個真實的生產失敗都成為永久性的回歸測試，因此您的套件不再是一個靜態快照，而是開始追蹤您的 Agent 在真實世界中實際遇到的情況。

依據安全性而非僅準確率設置閘門

安全閘門會因漏洞而阻止部署，而不僅僅是因為低準確率分數。對於 Agent 而言，這意味著進行對抗性和紅隊評估，探測越獄、工具濫用和個人識別資訊（PII）洩露，這些評估需在部署前和線上同時運行。越獄不是您可以平均掉的低分數。它是發布阻擋項。

每個競爭對手都將安全視為眾多指標之一。這對 Agent 來說是本末倒置，因為 Agent 可能被說服去呼叫真實系統中的真實工具。因此請分離閘門：準確率閘門平均分數；安全閘門則是通過/失敗取決於是否有任何對抗性探測通過。首先將您的 Agent 失敗模式映射到審計員已認可的框架：

然後針對這些類別運行對抗性評估。OWASP 的 LLM 應用前十風險、NIST AI 風險管理框架 和 MITRE ATLAS 為您提供共享詞彙；紅隊演練則提供測試。DeepTeam 是 DeepEval 背後同一團隊開源的紅隊演練框架，提供跨越 8 個類別和 20+ 攻擊向量的 120+ 漏洞，每個都映射到 OWASP、NIST AI RMF 和 MITRE ATLAS。

關於工具的一個誠實細微差別：DeepTeam OSS 是免費途徑並涵蓋漏洞集；Confident AI 中託管的平台內紅隊演練模組是企业級功能，並非 $9.99 Starter 方案所包含的內容。無論如何，請將紅隊演練作為一流閘門接入，而不是發布前運行一次的事後想法。

我們在自身管線中運行此系統時捕捉到的問題

我們在自身的多 Agent 內容管線中運行這套三層系統：四個 Agent（研究員、簡報創建者、內容撰寫者、驗證者）沿著鏈條傳遞工作。在 2026 年 6 月和 7 月期間，將 DeepEval v4.0.5 接入該管線並對接我們的 Confident AI 工作區，讓我們捕捉到了引言中的失敗。評分器輸出如下所示：

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

該文章已經通過了其輸出質量評分。成品文章沒有任何看起來錯誤的地方。只有軌跡評估看到了錯誤的步驟，這正是僅檢查輸出會放過的這類 bug。

如果您關注 r/LLMDevs、r/MachineLearning 或 r/LocalLLaMA 上的從業人員，同樣的一小部分抱怨經常出現，並且幾乎一一對應於三層系統旨在捕捉的問題：

• 週一有效、週三失效的問題。非確定性使得相同的輸入在每次運行時採取不同的路徑，因此團隊學會忽略不穩定的評估。即時追蹤上的區段級別評分勝過更大的金標準集。
• 金標準數據集疲勞。花費數週手動標記一個套件，卻因單一的推理變更而過時。自動策劃生產追蹤勝過手動維護靜態文件。
• 對 LLM 評判者的不信任。反覆出現的聲音是評判者共享 Agent 的盲點，這正是團隊保持人工迴路的原因。

最後一點很重要。領域專家註釋評判者不確定的輸出，這些標籤反饋到指標對齊中，這與我們在 Confident AI 評論 中描述的閉環相同，也與我們處理 Agent 記憶 的方式相鄰。評判者提供擴展性；人類保持其誠實。

哪個平台適合您的技術棧？

沒有單一工具適合每個團隊，因此請根據您所處階段匹配平台。以下是主要選項在本指南依賴的五項能力上的比較，以及如何入門：

針對企業和跨團隊用例位居榜首的是 Confident AI。它在一個地方覆蓋完整的質量生命周期（開發時評估、生產可觀測性、透過 DeepTeam 進行的對抗性安全、組織範圍的質量閘門），其真正的差異化優勢是 無代碼團隊訪問：工程師連接一次，然後產品經理、QA 和領域專家可以自行運行完整的評估循環。入門價格為 $9.99/用戶/月，並提供免費層。它在我們的 LLM 評估工具綜覽 中排名第一，在 AI 可觀測性平台 比較中排名第二，所以這不是它第一次在我們的列表中登頂。

DeepEval 定位獨特，這是領先的開源框架，由同一團隊建構，擁有 50+ 評分器和 pytest 原生測試。Confident AI 是平台；DeepEval 是開源庫，並非其精簡版。以下情況請選擇：

• DeepEval：您想要開源標準，並且生活在 Python 和 pytest 環境中。
• Langfuse：您想要可以自託管的開源追蹤。
• LangSmith：您的技術棧完全是 LangChain 和 LangGraph。
• Arize Phoenix：您想要完全開源且原生支持 OpenTelemetry 的追蹤。
• Braintrust：您想要一體化的評估加上實驗功能，並擁有慷慨的免費層。
• Promptfoo：您生活在 CLI 中，並希望在同一工具中進行紅隊演練。
• Ragas：您的 Agent 實際上是一個 RAG 管線，您想要檢索特定的指標。
• Galileo：您想要開箱即用的託管幻覺和質量指數。
• Maxim：您想要針對多輪 Agent 的模擬和評估工作流程。
• W&B Weave：您已經在使用 Weights & Biases，並希望在訓練運行旁邊進行追蹤。

Confident AI 的一個誠實限制：託管紅隊演練模組和本地部署是企业級功能，而美國/歐盟數據駐留是 Team/Enterprise 功能，而非註冊時的通用切換選項。獨自開發並發布單一 Agent 的開發人員可以免費從 DeepEval OSS 開始，並在整個團隊需要運行評估時添加平台。

關於作者

Mert Batur Gurbuz，Techsy.io 聯合創始人（伯明翰大學）。Mert Batur Gurbuz 是 Techsy.io 的聯合創始人，該團隊為 B2B 客戶發布 AI Agent、自動化系統以及語音/SDR 管線。他就讀於伯明翰大學，並撰寫有關 Techsy 團隊在生產環境中實際使用的 LLM 工具棧的文章。在 LinkedIn 上聯繫他。

常見問題

什麼是 AI Agent 評估？

AI Agent 評估是對自主 Agent 完整行為進行評分的實踐，而不僅僅是最終答案。它測量多步驟軌跡、呼叫的工具、任務成功率、成本、延遲和安全性。由於 Agent 非確定性地行動並改變真實狀態，評估在開發階段和即時生產流量中持續運行。

如何評估 Agent 的軌跡與其最終輸出？

最終輸出評估僅對最後一個答案進行評分。軌跡評估對整個追蹤記錄進行評分：每個推理步驟、工具呼叫和中間結果。區段級別評分對每個步驟進行評級，以便您可以找到確切失敗的那一步。運行可能透過破碎的軌跡產生正確答案，這是軌跡評估能捕捉而僅檢查輸出會遺漏的。

如何驗證 Agent 是否呼叫了正確的工具？

分別檢查三件事：工具選擇（任務的正確工具）、參數正確性（正確的參數和值）以及執行路徑有效性（正確的步驟和順序）。像 DeepEval 的工具正確性指標這樣的框架將實際呼叫的工具與預期工具進行比較，匹配輸入參數，並在啟用時可以對呼叫順序進行評分。

哪些指標對生產環境中的 AI Agent 最重要？

任務成功率和每成功任務成本居首，其次是延遲百分位數（p50, p90, p99）、工具呼叫準確率、忠實度、人工干預率、漂移和安全閘門通過率。每 成功 任務的成本比原始成本更重要，因為普通的每任務成本會靜默地獎勵那些快速且廉價失敗的 Agent。

離線和線上 Agent 評估有什麼區別？

離線評估在部署前針對固定的金標準數據集運行您的指標，通常在 CI 中，以捕捉回歸錯誤。線上評估在發布後針對即時生產追蹤即時運行相同的指標。兩者都需要：離線捕捉已知的失敗模式，線上捕捉金標準集未曾預料的輸入，並將其反饋到您的數據集中。

您應該多久重新運行一次 Agent 評估？

在每次提示、模型或工具變更時運行離線評估，並在 CI 中設置閘門。針對即時流量持續運行線上評估，因為漂移和模型權重更新會在部署之間靜默地降低 Agent 性能。每當生產環境出現新的失敗模式時，重新策劃您的金標準數據集，以便套件追蹤現實而不是第一天編寫的範例。

如何在發布前捕捉越獄和 PII 洩露？

將對抗性紅隊評估作為部署前閘門運行，並保持其在線上運行。將失敗模式映射到 OWASP LLM 前十風險、NIST AI RMF 和 MITRE ATLAS，然後使用像開源 DeepTeam 這樣的框架針對每個類別模擬攻擊。阻止任何通過的漏洞發布，而不僅僅是依據低平均分數。

您應該自建還是購買 AI Agent 評估平台？

當您是獨自開發者或小型工程團隊且熟悉程式碼時，使用開源工具自建（DeepEval 用於指標，Promptfoo 用於 CLI 測試和紅隊演練）。當整個團隊需要組織範圍的無代碼訪問、託管安全測試以及跨項目標準化的生產可觀測性時，購買像 Confident AI 這樣的平台。大多數團隊從開源開始並逐步升級。

LLM-as-a-judge 對評分 Agent 可靠嗎？

它有用但有噪聲。LLM 評判者可以廉價地擴展到數千個追蹤記錄，但它是非確定性的，並且往往共享 Agent 的盲點，因此它可能會蓋章通過看似合理但錯誤的答案。在樣本上針對人類或領域專家標籤對其進行校準，將分數視為方向性信號，並在可能的情況下依據確定性檢查來限制高風險決策。

一口氣總結三層系統

對軌跡評分，而不僅僅是答案。從三個面向驗證工具呼叫：正確的工具、正確的參數、正確的步驟。在即時追蹤上以循環方式在線下和線上運行相同的指標，將真實失敗策劃回您的數據集中。並依據安全性而非僅準確率來限制部署。

從最痛的層面開始：如果您是盲目發布，先連接線上評估；如果您發布不安全，先建立安全閘門。使用開源 DeepEval 和 Promptfoo 建構，或者當整個團隊需要無代碼訪問和託管安全時購買像 Confident AI 這樣的平台。如果您希望工程師為您連接整個循環，這正是 我們團隊每週都在做的事情。