1.3.2. Agent 評(píng)判的主題和內(nèi)容

知道要評(píng)估什么：軌跡(trajectory) 已經(jīng)成功了一半。另一半則是如何進(jìn)行評(píng)估。對(duì)于質(zhì)量、安全性和可解釋性等細(xì)微方面，這種判斷需要一種復(fù)雜的混合方法。自動(dòng)化系統(tǒng)能提供效率，但人類的判斷仍是質(zhì)量的關(guān)鍵。

1.3.2.1. 自動(dòng)化評(píng)估指標(biāo)

自動(dòng)化指標(biāo)具有速度快和可重復(fù)性高的特點(diǎn)。它們在回歸測試和輸出基準(zhǔn)測試中很有用。例如：

• 基于字符串的相似度（ROUGE、BLEU），用于比較生成文本與參考文本。
• 基于嵌入的相似度（BERTScore、余弦相似度），用于衡量語義貼近度。
• 特定任務(wù)基準(zhǔn)，例如 TruthfulQA2

自動(dòng)化指標(biāo)雖高效卻流于表面：它們只能捕捉表面的相似性，無法體現(xiàn)更深層次的推理或用戶價(jià)值。

1.3.2.2. LLM 作為評(píng)判者

我們該如何自動(dòng)化評(píng)估 “這個(gè)總結(jié)是否優(yōu)質(zhì)？” 或 “這個(gè)方案是否合理？” 這類定性輸出呢？答案：LLM-as-a-Judge 方式，即采用另一款強(qiáng)大的模型來評(píng)估當(dāng)前 Agent 的輸出。
向作為 “評(píng)估者” 的模型提供以下信息：Agent 的輸出結(jié)果、原始提示詞、“標(biāo)準(zhǔn)答案” 或參考依據(jù)（若存在），以及一份詳細(xì)的評(píng)估標(biāo)準(zhǔn)（例如，“從實(shí)用性、準(zhǔn)確性和安全性三個(gè)維度，按 1-5 分給該響應(yīng)打分，并說明評(píng)分理由”）。這種方法能提供可規(guī)?；⒏咝揖润@人的反饋，尤其適用于 Agent “思考過程” 質(zhì)量、工具響應(yīng)解讀等中間環(huán)節(jié)的評(píng)估。盡管它無法取代人類判斷，但能幫助我們在數(shù)千種場景中快速評(píng)估 Agent 性能，讓迭代式評(píng)估流程具備可行性。(最好進(jìn)行對(duì)比性評(píng)估AB兩個(gè)結(jié)果對(duì)比)

1.3.2.3. Agent 作為評(píng)判者

LLM 雖能對(duì)最終響應(yīng)打分，但對(duì) Agent的評(píng)估需要更深入 —— 不僅看結(jié)果，更要審視其背后的推理邏輯與執(zhí)行行為。為此，Agent-as-a-Judge 這一新興范式應(yīng)運(yùn)而生：它讓一個(gè) Agent 完整評(píng)估另一個(gè) Agent 的執(zhí)行軌跡，核心是聚焦 “過程” 而非僅評(píng)判 “輸出”。其關(guān)鍵評(píng)估維度包含三大方面：

• 計(jì)劃質(zhì)量：Agent 制定的方案邏輯是否清晰、是否具備可落地性？
• 工具使用：所選工具是否契合任務(wù)需求，且應(yīng)用過程是否正確？
• 上下文處理：Agent 能否有效利用前期獲取的信息輔助決策？

這種方法在過程評(píng)估中特別有價(jià)值，因?yàn)槭⊥从谟腥毕莸闹虚g步驟，而非最終輸出。
要落地 “智能體作為評(píng)估者”，可按以下步驟操作：

1. 配置 Agent 框架，使其記錄并導(dǎo)出完整的執(zhí)行軌跡，軌跡中需包含 Agent 的內(nèi)部計(jì)劃、所選工具列表，以及傳遞給工具的精確參數(shù)；
2. 再創(chuàng)建一個(gè)專用的評(píng)估 Agent，并為其配置包含評(píng)估標(biāo)準(zhǔn)的 Prompt，讓它直接對(duì)軌跡數(shù)據(jù)進(jìn)行評(píng)估。Prompt 需聚焦過程性問題，例如：“1. 從軌跡來看，初始計(jì)劃是否符合邏輯？2. 工具 A 是否是合適的首選工具，還是應(yīng)選用其他工具？3. 傳遞的參數(shù)是否正確且格式規(guī)范？” 如此一來，即便 Agent 最終輸出看似正確，也能自動(dòng)檢測出過程中的問題（如計(jì)劃效率低等）。

1.3.2.4. HITL 評(píng)判

自動(dòng)化雖能實(shí)現(xiàn)規(guī)?；u(píng)估，卻在深度主觀性任務(wù)（如創(chuàng)意質(zhì)量評(píng)估、語氣微妙性判斷）和復(fù)雜領(lǐng)域知識(shí)應(yīng)用上存在局限。而 Human-in-the-Loop(HITL) ，正是彌補(bǔ)這一短板的核心手段 —— 它能捕捉自動(dòng)化系統(tǒng)遺漏的關(guān)鍵定性信號(hào)與細(xì)微判斷，為 Agent 質(zhì)量校準(zhǔn)提供 “人類視角”。
不過需明確的是，人工評(píng)分并非絕對(duì)的 “客觀真相”：面對(duì)高度主觀的評(píng)估維度，標(biāo)注者間很難達(dá)成完全一致。因此，HITL 的核心價(jià)值在于建立 “經(jīng)人類校準(zhǔn)的基準(zhǔn)”，確保 Agent 行為符合復(fù)雜的人類價(jià)值觀、場景化需求，以及醫(yī)療、法律、金融等專業(yè)領(lǐng)域的精準(zhǔn)性要求。具體而言，HITL 流程通過三大關(guān)鍵功能落地：

1. 領(lǐng)域?qū)I(yè)支持：針對(duì)醫(yī)療、法律等專業(yè) Agent，需依靠領(lǐng)域?qū)＜以u(píng)估其輸出的事實(shí)準(zhǔn)確性與行業(yè)標(biāo)準(zhǔn)符合性；
2. 細(xì)微差異解讀：人類能精準(zhǔn)判斷 Agent 互動(dòng)中的微妙特質(zhì)，比如溝通語氣是否恰當(dāng)、是否契合用戶潛在意圖、倫理層面是否合規(guī)；
3. 構(gòu)建 “黃金集合”：在自動(dòng)化評(píng)估啟動(dòng)前，由人類打造包含典型、邊緣及對(duì)抗性場景的測試基準(zhǔn)，明確 Agent 成功的核心目標(biāo)，為后續(xù)評(píng)估提供參照。

1.3.2.5. 用戶反饋和 Reviewer 界面

評(píng)估還必須收集 Agent 真實(shí)的用戶反饋。每一次互動(dòng)都是反映其 “實(shí)用性”“清晰度” 與 “可信度” 的重要信號(hào)。這類反饋既包含 “點(diǎn)贊 / 踩” 這類直觀的定性信息，也涵蓋可量化的產(chǎn)品內(nèi)成功指標(biāo)，比如代碼類 Agent 的拉取請求（PR）通過率、旅行類 Agent 的預(yù)訂完成率。
要讓用戶反饋真正助力 Agent 優(yōu)化，需遵循四大最佳實(shí)踐：

1. 低門檻反饋設(shè)計(jì)：用 “點(diǎn)贊 / 點(diǎn)踩”、快捷滑塊或簡短評(píng)論等輕量化方式，降低用戶反饋的操作成本，提升參與意愿；
2. 場景化反饋關(guān)聯(lián)：將用戶反饋與完整對(duì)話記錄、Agent 的推理軌跡綁定，讓后續(xù)問題定位有跡可循，避免 “反饋孤立無援”；
3. 專業(yè)化評(píng)審界面（Reviewer UI）：采用雙面板布局，左側(cè)展示對(duì)話流程，右側(cè)呈現(xiàn) Agent 的推理步驟，支持直接標(biāo)注 “計(jì)劃不合理”“工具誤用” 等問題，讓評(píng)審更精準(zhǔn)；
4. 反饋聚合看板：通過儀表盤匯總所有反饋數(shù)據(jù)，自動(dòng)凸顯高頻問題與潛在風(fēng)險(xiǎn)，為 Agent 迭代指明方向。

好用的界面是評(píng)估框架落地的關(guān)鍵 —— 一套優(yōu)秀的 Reviewer UI 能讓用戶反饋和評(píng)審意見更直觀、傳遞更高效，最終轉(zhuǎn)化為可落地的優(yōu)化動(dòng)作，避免評(píng)估流于形式。

1.3.3. AI 歸責(zé) & 安全評(píng)估

對(duì)生產(chǎn)級(jí) Agent 而言，評(píng)估絕不止 “能否完成任務(wù)” 這一項(xiàng) —— 負(fù)責(zé)任 AI（RAI）與安全性，是必須跨越的 “硬性門檻”。哪怕一個(gè) Agent 的任務(wù)完成度達(dá) 100%，若存在安全隱患、可能造成傷害，它仍是徹底的失敗品。
安全性評(píng)估并非孤立環(huán)節(jié)，而是需貫穿 Agent 全開發(fā)生命周期的專業(yè)工作，核心落地路徑包含三大方向：

1. 破壞性測試：主動(dòng)用對(duì)抗性場景 “挑戰(zhàn)” Agent，比如嘗試誘導(dǎo)其生成仇恨言論、泄露用戶隱私信息、傳播有害刻板印象，或是觸發(fā)惡意操作，以此暴露潛在安全漏洞；
2. 自動(dòng)過濾 + 人工審核雙保障：先用技術(shù)過濾器初步攔截違反政策的內(nèi)容，但因自動(dòng)化工具難以識(shí)別細(xì)微的偏見或隱性不良信息，必須搭配人工審核進(jìn)一步把關(guān)，形成 “技術(shù)篩查 + 人類判斷” 的雙重防線；
3. 嚴(yán)格對(duì)標(biāo)倫理準(zhǔn)則：將 Agent 的輸出與預(yù)先制定的倫理規(guī)范、核心原則逐一比對(duì)，確保其行為符合道德標(biāo)準(zhǔn)，避免因設(shè)計(jì)漏洞導(dǎo)致意外后果。

1.4. 可觀測性：洞悉 Agent 的思維

1.4.1. 從監(jiān)控到可觀測性

在上一章中，我們確定 AI Agent 是一種新型軟件。它們不只是遵循指令，還能做出決策。這種根本差異要求我們采用新的質(zhì)量保證方法，將我們從傳統(tǒng)的軟件監(jiān)控帶入更深層次的可觀測性領(lǐng)域。

1.4.1.1. 可觀測性三大支柱

我們無法直接讀取 LLM 的想法，但可以分析它留下的痕跡。這是通過將我們的可觀測性實(shí)踐建立在三個(gè)基礎(chǔ)支柱上來實(shí)現(xiàn)的：(LOG)日志、(Traces)追蹤 和 (Metrics)指標(biāo)。

Agent 可觀測性的三大基礎(chǔ)支柱

1.4.2. 支柱一：Logging

什么是 Logs ？日志是可觀測性的原子單位。可以把它們看作是 agent's 日記中帶有時(shí)間戳的記錄。每條記錄都是關(guān)于某個(gè)離散事件的原始、不可變的事實(shí)：“在10:01:32，我被問到一個(gè)問題。在10:01:33，我決定使用 get_weather 工具?！?它們告訴我們發(fā)生了什么。

1. 不僅是 print()：什么讓 Log 變得有效？
   需要具備大規(guī)模存儲(chǔ)、搜索和分析日志數(shù)據(jù)的能力，可以自動(dòng)從服務(wù)收集日志，允許進(jìn)行標(biāo)準(zhǔn)化查詢(SQL)，以發(fā)現(xiàn) Agent 行為中的趨勢。

2. 關(guān)鍵日志條目解析
   要重建 Agent 的“思考過程”，日志必須包含豐富的上下文。結(jié)構(gòu)化的JSON格式是黃金標(biāo)準(zhǔn)。

   • 核心信息：一份優(yōu)質(zhì)的日志應(yīng)包含完整的上下文：提示詞/輸入輸出、中間推理步驟（智能體的“思維鏈”，）、結(jié)構(gòu)化工具調(diào)用（輸入、輸出、錯(cuò)誤）以及 Agent 內(nèi)部狀態(tài)的任何變化。
   • 權(quán)衡：冗長與性能：高度詳細(xì)的DEBUG日志是開發(fā)人員排查問題的得力助手，但在生產(chǎn)環(huán)境中可能過于“嘈雜”，并造成性能開銷。這就是結(jié)構(gòu)化日志如此強(qiáng)大的原因：它允許你收集詳細(xì)數(shù)據(jù)，同時(shí)高效地對(duì)其進(jìn)行過濾。

   以下是一個(gè)展示結(jié)構(gòu)化日志強(qiáng)大功能的實(shí)際示例，改編自ADK的DEBUG輸出：

   // 一條記錄單次 LLM 請求的結(jié)構(gòu)化日志
   ...
   2025-07-10 15:26:13,778 - DEBUG - google_adk.google.adk.models.google_llm - Sending out request, model: gemini-2.0-flash, backend: GoogleLLMVariant.GEMINI_API, stream: False 
   2025-07-10 15:26:13,778 - DEBUG - google_adk.google.adk.models.google_llm - 
   
   LLM Request:
   System Instruction: 關(guān)于你的行為描述是："可擲 8 面骰子并判斷結(jié)果數(shù)值的 Hello World agent"。你需執(zhí)行擲骰子操作，并回答與骰子結(jié)果相關(guān)的問題.....
   
   Contents:
   {"parts":[{"text":"擲一個(gè) 6 面骰子"}],"role":"user"} 
   {"parts":[{"function_response":{"name":"roll_die","response":{"result":2}}}],"role":"user"} {"parts":[{"function_call":{"args":{"sides":6},"name":"roll_die"}}],"role":"model"} 
   
   Functions:
   roll_die: {'sides': {'type': <Type.INTEGER: 'INTEGER'>}} 
   check_prime: {'nums': {'items': {'type': <Type.INTEGER: 'INTEGER'>}, 'type': <Type.ARRAY: 
   'ARRAY'>}} 
   
   2025-07-10 15:26:13,779 - INFO - google_genai.models - AFC is enabled with max remote 
   calls: 10.
   2025-07-10 15:26:14,309 - INFO - google_adk.google.adk.models.google_llm - 
   
   LLM Response:
   Text: 我已擲出一個(gè) 6 面骰子，結(jié)果為 2.
   

一種有效的日志記錄模式是在行動(dòng)前記錄 Agent 的意圖，在行動(dòng)后記錄結(jié)果。這能立即明確失敗的嘗試與故意決定不采取行動(dòng)之間的區(qū)別。

1.4.3. 支柱二：Tracing

什么是Tracing? 如果說 logs 是日記條目，那么traces就是將它們串聯(lián)成一個(gè)連貫故事的敘事線索。追蹤會(huì)從最初的用戶查詢到最終的答案，全程跟進(jìn)單個(gè)任務(wù)，將各個(gè)日志（稱為spans）拼接成一個(gè)完整的端到端視圖。追蹤通過展示事件之間的因果關(guān)系揭示出關(guān)鍵的“原因”。

1.4.3.1. 為什么追蹤至關(guān)重要

考慮一種復(fù)雜的 Agent 故障：用戶提出問題，卻得到了毫無意義的答案。

• 孤立日志可能顯示：錯(cuò)誤：RAG搜索失敗 以及 錯(cuò)誤：LLM響應(yīng)驗(yàn)證失敗。你能看到這些錯(cuò)誤，但根本原因尚不明確。
• Trace記錄揭示了完整的因果鏈：用戶查詢 → RAG 搜索（失?。?錯(cuò)誤的工具調(diào)用（收到空輸入）→ LLM 錯(cuò)誤（被錯(cuò)誤的工具輸出弄混淆）→ 不正確的最終答案

這條 Trace 能讓根本原因立即顯現(xiàn)，這使其在調(diào)試復(fù)雜、多步驟的智能體行為時(shí)不可或缺。

1.4.3.2. 智能體 Trace 的關(guān)鍵要素

現(xiàn)代追蹤基于 OpenTelemetry 等開放標(biāo)準(zhǔn)構(gòu)建。其核心組件包括：

• Spans：trace 中各個(gè)已命名的操作（例如，llm_call span、tool_execution span）。
• Attributes：每個(gè) Span 附帶的豐富元數(shù)據(jù)——prompt_id、latency_ms、token_count、user_id等。
• 上下文傳播：通過唯一的 trace_id 將 Spans 鏈接在一起的“魔法”。整合完整圖景，將 Agent 調(diào)用與所有后續(xù)的模型和工具調(diào)用關(guān)聯(lián)起來。
  
  OpenTelemetry 視圖允許您查看屬性、日志、事件和其他詳細(xì)信息

1.4.4. 支柱三：Metrics

什么是Metrics？ Metrics 就是評(píng)論家發(fā)布的最終評(píng)分卡。它們是定量的、匯總的健康分?jǐn)?shù)，能讓你立即、一目了然地了解 Agent 的整體表現(xiàn)。
評(píng)論家并非僅憑對(duì)最終結(jié)果評(píng)判就隨意給出評(píng)分。他們的判斷是基于所觀察到的一切得出的。Metrics 也是如此：它們并非新的數(shù)據(jù)來源，而是通過長期匯總日志和追蹤數(shù)據(jù)得出的。它們要回答的問題是：“平均而言，性能表現(xiàn)有多好？”
對(duì)于AI Agents 而言，將 Metrics 分為兩個(gè)不同的類別是很有用的：可直接測量的系統(tǒng)指標(biāo)和更復(fù)雜、更具評(píng)估性的質(zhì)量指標(biāo)。

1.4.4.1. 系統(tǒng)指標(biāo)：生命體征

系統(tǒng)指標(biāo)是衡量運(yùn)營健康狀況的基本量化指標(biāo)。它們通過聚合函數(shù)（如平均值、總和或百分位數(shù)）直接從日志和追蹤的屬性中計(jì)算得出?？梢詫⑦@些指標(biāo)視為 Agent 的生命體征：脈搏、體溫和血壓。
需要跟蹤的關(guān)鍵系統(tǒng)指標(biāo)包括：

• 性能：延遲(P99)和錯(cuò)誤率
• 成本：tokens 和 API Cost
• 有效性：任務(wù)完成率和工具使用頻率

1.4.4.2. 質(zhì)量指標(biāo)：評(píng)判決策過程

質(zhì)量指標(biāo)是在原始可觀測性數(shù)據(jù)基礎(chǔ)上，超越了效率層面的進(jìn)一步評(píng)估，用于評(píng)估 Agent 的推理過程及最終輸出質(zhì)量本身。 這些并非簡單的計(jì)數(shù)器或平均值，而是通過在原始可觀測性數(shù)據(jù)之上應(yīng)用一個(gè)判斷層而得出的二階指標(biāo)，包括：

• 正確性與準(zhǔn)確性：Agent 提供的答案是否符合事實(shí)？如果它對(duì)文檔進(jìn)行了總結(jié)，該總結(jié)是否忠實(shí)于原文？
• 軌跡遵循度：Agent 是否遵循了給定任務(wù)的預(yù)期路徑或“理想方案”？它是否按正確順序調(diào)用了正確的工具？
• 安全性與責(zé)任性：Agent 的響應(yīng)是否避免了有害、有偏見或不適當(dāng)?shù)膬?nèi)容？
• 有用性與相關(guān)性：Agent 的最終回復(fù)對(duì)用戶是否真的有幫助，且與他們的查詢相關(guān)?

生成這些指標(biāo)不僅需要簡單的數(shù)據(jù)庫查詢。這通常涉及將Agent的輸出與“黃金”標(biāo)準(zhǔn)數(shù)據(jù)集進(jìn)行比較，或者使用 LLM-as-a-Judge，根據(jù)評(píng)分標(biāo)準(zhǔn)對(duì)響應(yīng)進(jìn)行打分。

1.4.5. 整合：原始數(shù)據(jù)到可執(zhí)行

擁有 logs、traces 和 metrics 之后，你需要將它們整合并轉(zhuǎn)化為實(shí)際行動(dòng)和可落地的業(yè)務(wù)洞見。這涉及三個(gè)關(guān)鍵的操作實(shí)踐：

1. 儀表盤與告警
   單一儀表盤無法滿足智能體多維度的管理需求，必須按 “系統(tǒng)健康” 和 “模型質(zhì)量” 拆分視圖，讓不同角色精準(zhǔn)獲取所需信息：
   • 運(yùn)營儀表盤（面向 SRE/DevOps 團(tuán)隊(duì)）
     • 核心定位：監(jiān)控智能體 “基礎(chǔ)生命體征”，確保系統(tǒng)穩(wěn)定運(yùn)行
     • 追蹤指標(biāo)：P99 延遲（反映極端情況下的用戶等待時(shí)間）、錯(cuò)誤率（工具調(diào)用 / API 請求失敗比例）、API 成本（外部服務(wù)調(diào)用開銷）、令牌消耗（LLM 使用成本）
     • 核心價(jià)值：實(shí)時(shí)捕捉 “硬故障”，比如當(dāng) P99 延遲連續(xù) 5 分鐘超過 3 秒時(shí)，立即觸發(fā)告警，提示工程團(tuán)隊(duì)排查系統(tǒng)瓶頸（如服務(wù)器負(fù)載過高、工具響應(yīng)超時(shí)），避免影響用戶體驗(yàn)
   • 質(zhì)量儀表盤（面向產(chǎn)品 / 數(shù)據(jù)科學(xué) / AgentOps 團(tuán)隊(duì)）
     • 核心定位：洞察智能體 “決策與輸出質(zhì)量”，發(fā)現(xiàn)細(xì)微的性能漂移
     • 追蹤指標(biāo)：事實(shí)準(zhǔn)確率（輸出內(nèi)容與真實(shí)信息的匹配度）、軌跡合規(guī)性（智能體推理步驟是否符合預(yù)設(shè)流程）、實(shí)用性評(píng)分（用戶對(duì)輸出的滿意度）、幻覺率（生成虛假信息的比例）
     • 核心價(jià)值：捕捉 “軟問題”，例如當(dāng) “實(shí)用性評(píng)分” 24 小時(shí)內(nèi)下降 10% 時(shí)，即便系統(tǒng)指標(biāo)（如延遲、錯(cuò)誤率）正常，也能及時(shí)預(yù)警 —— 提示團(tuán)隊(duì)排查是否是新模型部署后推理邏輯變化、或訓(xùn)練數(shù)據(jù)偏差導(dǎo)致質(zhì)量退化
2. 安全與隱私保護(hù)
   在生產(chǎn)環(huán)境中，日志和軌跡會(huì)不可避免地記錄用戶輸入，其中可能包含身份證號(hào)、手機(jī)號(hào)等個(gè)人身份信息（PII）。因此，數(shù)據(jù)脫敏機(jī)制必須成為日志流水線的 “標(biāo)配環(huán)節(jié)”：在數(shù)據(jù)長期存儲(chǔ)前，需通過技術(shù)手段自動(dòng)過濾或加密 PII 信息，既符合《個(gè)人信息保護(hù)法》等隱私法規(guī)，也能避免用戶數(shù)據(jù)泄露風(fēng)險(xiǎn)。這不是 “可選項(xiàng)”，而是智能體合規(guī)運(yùn)營的底線。
3. 平衡數(shù)據(jù)粒度與系統(tǒng)開銷
   若對(duì)生產(chǎn)環(huán)境中每一次請求都記錄高細(xì)節(jié)日志（如 DEBUG 級(jí)別），會(huì)導(dǎo)致兩大問題：一是存儲(chǔ)與計(jì)算成本飆升，二是系統(tǒng) latency（延遲）增加。解決之道在于 “動(dòng)態(tài)采樣” 這一最佳實(shí)踐：
   • 開發(fā)環(huán)境：使用高粒度日志（DEBUG 級(jí)別），方便工程師調(diào)試代碼、驗(yàn)證邏輯；
   • 生產(chǎn)環(huán)境：默認(rèn)采用低粒度日志（INFO 級(jí)別），同時(shí)按場景靈活采樣 —— 例如僅追蹤 10% 的成功請求，用于統(tǒng)計(jì)整體性能；但對(duì) 100% 的錯(cuò)誤請求完整記錄軌跡，確保每個(gè)故障都有詳細(xì)診斷數(shù)據(jù)。
     這種方式既能為指標(biāo)計(jì)算提供足夠的性能樣本，又不會(huì)讓系統(tǒng)過載，實(shí)現(xiàn) “成本可控” 與 “故障可查” 的雙贏。

1.5. 總結(jié)

在 AI 智能體（Agent）技術(shù)飛速發(fā)展的今天，如何讓具備自主性與非確定性的智能體突破傳統(tǒng)軟件質(zhì)量模型的局限，成為企業(yè)可信賴的工具？本文將整合白皮書核心內(nèi)容，拆解智能體質(zhì)量保障的 “飛輪體系” 與三大核心原則，為落地企業(yè)級(jí)智能體提供行動(dòng)藍(lán)圖。

1.5.1. 從 “能做事” 到 “可信任” 的跨越

AI 智能體的特殊性在于其 “自主決策” 能力 —— 它不像傳統(tǒng)軟件那樣遵循固定邏輯，而是會(huì)基于模型推理、工具調(diào)用、環(huán)境交互動(dòng)態(tài)調(diào)整行為。這種特性讓評(píng)估標(biāo)準(zhǔn)從 “任務(wù)是否完成” 升級(jí)為 “任務(wù)如何完成”：效率是否最優(yōu)？操作是否安全？用戶體驗(yàn)是否良好？畢竟，當(dāng)智能體的失誤可能引發(fā)業(yè)務(wù)風(fēng)險(xiǎn)（如金融領(lǐng)域的決策偏差、醫(yī)療場景的建議錯(cuò)誤）時(shí)，“盲目部署” 絕不可行。
為應(yīng)對(duì)這一挑戰(zhàn)，白皮書首先確立了智能體質(zhì)量的四大支柱，作為所有評(píng)估與優(yōu)化的核心目標(biāo)：

• 有效性：是否精準(zhǔn)達(dá)成用戶真實(shí)意圖（如零售智能體不僅要找到商品，更要推動(dòng)轉(zhuǎn)化）；
• 成本效益：完成任務(wù)的資源消耗是否合理（如避免過多工具調(diào)用、冗余推理步驟）；
• 安全性：是否符合倫理邊界與合規(guī)要求（如規(guī)避偏見、防止數(shù)據(jù)泄露）；
• 用戶信任：是否能持續(xù)提供可靠、可解釋的服務(wù)，建立長期信任關(guān)系。

1.5.2. 智能體質(zhì)量飛輪：讓系統(tǒng) “自我進(jìn)化”

優(yōu)秀的智能體不僅能穩(wěn)定執(zhí)行任務(wù)，更能通過持續(xù)評(píng)估不斷優(yōu)化。白皮書提出的 “智能體質(zhì)量飛輪”，正是將 “定義質(zhì)量 - 觀測行為 - 評(píng)估過程 - 反饋迭代” 整合為閉環(huán)的運(yùn)營體系，像推動(dòng)一個(gè)重型飛輪般，從初始的 “費(fèi)力啟動(dòng)” 到后續(xù)的 “慣性加速”，形成質(zhì)量與信任的良性循環(huán)。其四大核心步驟如下：

智能體質(zhì)量飛輪

步驟 1：定義質(zhì)量（明確方向）

飛輪的第一步是鎖定目標(biāo) —— 以 “四大質(zhì)量支柱” 為具體標(biāo)準(zhǔn)，而非抽象的 “好與壞”。例如，為客服智能體設(shè)定 “有效性” 指標(biāo)為 “用戶問題解決率≥90%”，“安全性” 指標(biāo)為 “敏感信息泄露率 = 0”，讓后續(xù)評(píng)估有明確依據(jù)。

步驟 2：構(gòu)建可見性（筑牢基礎(chǔ)）

“看不見的過程無法管理”。通過可觀測性實(shí)踐（對(duì)應(yīng)白皮書第 3 章），讓智能體生成兩類關(guān)鍵數(shù)據(jù)：

• 結(jié)構(gòu)化日志：像 “智能體日記”，記錄每一步操作（如 “15:30 調(diào)用天氣 API，參數(shù)為北京”）；
• 端到端軌跡：像 “敘事線索”，串聯(lián)零散日志，呈現(xiàn)完整決策鏈（如 “用戶請求→LLM 規(guī)劃→工具調(diào)用→結(jié)果生成”）。
  這些數(shù)據(jù)是衡量 “四大支柱” 的 “證據(jù)庫”，也是飛輪轉(zhuǎn)動(dòng)的核心燃料。

步驟 3：評(píng)估過程（驅(qū)動(dòng)運(yùn)轉(zhuǎn)）

有了可見性數(shù)據(jù)，下一步就是用 “由外而內(nèi)” 的評(píng)估框架（對(duì)應(yīng)白皮書第 2 章）判斷性能：

• 外部評(píng)估（黑盒視角）：看最終輸出是否達(dá)標(biāo)（如任務(wù)成功率、用戶滿意度）；
• 內(nèi)部評(píng)估（玻璃盒視角）：拆解決策軌跡，定位問題根源（如 “推理邏輯混亂”“工具調(diào)用參數(shù)錯(cuò)誤”）。
  評(píng)估時(shí)需結(jié)合 “自動(dòng)化工具” 與 “人類判斷”：用 LLM-as-a-Judge 實(shí)現(xiàn)規(guī)?；u(píng)分（如批量檢測輸出準(zhǔn)確性），用人機(jī)協(xié)同（HITL）處理復(fù)雜場景（如醫(yī)療、法律領(lǐng)域的專業(yè)驗(yàn)證），兼顧效率與精準(zhǔn)度。

步驟 4：構(gòu)建反饋循環(huán)（加速慣性）

飛輪的關(guān)鍵在于 “失敗即資產(chǎn)”—— 將生產(chǎn)環(huán)境中捕獲的每一次失誤（如智能體生成錯(cuò)誤金融建議、未識(shí)別 API 異常），通過標(biāo)注轉(zhuǎn)化為 “黃金評(píng)估集” 中的回歸測試用例。這樣一來，系統(tǒng)會(huì)從錯(cuò)誤中學(xué)習(xí)：下次遇到類似場景時(shí)，自動(dòng)規(guī)避風(fēng)險(xiǎn)，實(shí)現(xiàn) “越用越聰明” 的自我進(jìn)化。

1.5.3. 三大核心原則：落地可信智能體的 “底層思維”

若只能記住白皮書的一個(gè)知識(shí)點(diǎn)，那一定是這三條原則 —— 它們是所有技術(shù)實(shí)踐與運(yùn)營策略的 “指南針”：

原則 1：評(píng)估是 “架構(gòu)級(jí)設(shè)計(jì)”，而非 “最后一步測試”

就像一級(jí)方程式賽車從設(shè)計(jì)之初就嵌入遙測傳感器，而非賽后加裝一樣，智能體的 “可評(píng)估性” 必須從第一行代碼開始規(guī)劃。例如，在開發(fā)初期就定義日志格式、軌跡采集規(guī)則，讓后續(xù)的質(zhì)量分析無需 “返工補(bǔ)課”。質(zhì)量不是 “測試出來的”，而是 “設(shè)計(jì)出來的”。

原則 2：軌跡即真相，過程比結(jié)果更重要

智能體的最終輸出只是 “故事的最后一句話”，真正決定質(zhì)量的是其 “思考過程”。比如，兩個(gè)客服智能體都回答了用戶的物流問題，但一個(gè)是通過精準(zhǔn)調(diào)用物流 API 獲取實(shí)時(shí)數(shù)據(jù)，另一個(gè)是靠模型 “ hallucination（幻覺）” 生成虛假信息 —— 僅看結(jié)果無法區(qū)分優(yōu)劣，只有分析完整軌跡才能判斷可靠性。而這一切，都依賴于步驟 2 中構(gòu)建的深度可觀測性。

原則 3：人類是最終仲裁者，自動(dòng)化是輔助工具

自動(dòng)化（如 LLM 評(píng)估、安全過濾器）能解決 “規(guī)?；?問題，但 “好” 的定義、微妙場景的判斷（如客服語氣是否親切、法律建議是否合規(guī)）必須錨定人類價(jià)值觀。就像 AI 可以幫老師批改試卷，但評(píng)分標(biāo)準(zhǔn)（什么是 “A+”）、作文的創(chuàng)意與邏輯判斷，最終仍需人類決定。

1.5.4. 未來：可靠的 Agentic

當(dāng)前正處于智能體時(shí)代初期，打造具備推理、規(guī)劃與行動(dòng)能力的 AI 是極具變革性的技術(shù)突破，但能力提升伴隨構(gòu)建可信系統(tǒng)的重大責(zé)任。

掌握 “評(píng)估工程”（即白皮書所闡述的智能體評(píng)估理念與方法）是下一波 AI 競爭的核心差異點(diǎn)。若仍將智能體質(zhì)量視為事后補(bǔ)充，會(huì)陷入 “演示前景好、落地卻失敗” 的循環(huán)；而投入資源建立嚴(yán)謹(jǐn)且與架構(gòu)深度融合的評(píng)估體系，才能突破概念炒作，落地真正具備變革力的企業(yè)級(jí) AI 系統(tǒng)。

智能體研發(fā)的終極目標(biāo)不只是 “能運(yùn)行”，更是 “被信任”。這種信任并非偶然，而是通過持續(xù)、全面且架構(gòu)層面可靠的評(píng)估體系逐步構(gòu)建而成。

2. 代碼實(shí)驗(yàn)室

2.1. Log in Develop

• 通過 Web 界面運(yùn)行 Agent 然后觀察 lm_call 和 tool_call 的具體細(xì)節(jié)內(nèi)容
• 通過本地 debug 級(jí)別日志查看LLM 請求和回復(fù)的具體細(xì)節(jié)

2.2. Log in Production

通過 Callbacks 回調(diào)函數(shù)添加日志到代碼中

不同時(shí)間的回調(diào)函數(shù)

from google.adk.runners import InMemoryRunner
from google.adk.plugins.logging_plugin import (
    LoggingPlugin,
)  # <---- 1. Import the Plugin
from google.genai import types
import asyncio

runner = InMemoryRunner(
    agent=research_agent_with_plugin,
    plugins=[
        LoggingPlugin()
    ],  # <---- 2. Add the plugin. Handles standard Observability logging across ALL agents
)

print("? Runner configured")

LangGraph 內(nèi)部有 BaseCallbackHandler 同樣可以實(shí)現(xiàn)回調(diào)函數(shù)；LangSmith 可以實(shí)現(xiàn) Web 頁面觀察 Trace Timeline；使用開源的 LangFuse 也可以實(shí)現(xiàn)觀測和分析。

2.3. Evaluation

• Web界面運(yùn)行保存成功的用例用于后續(xù)在運(yùn)行時(shí)評(píng)估對(duì)比使用
• 用 JSON 文件記錄多個(gè)場景運(yùn)行成功用例+評(píng)估標(biāo)準(zhǔn)，Agent批量執(zhí)行這些場景并和JSON記錄結(jié)果進(jìn)行自動(dòng)化型評(píng)估

LangGraph 原生沒有 Evaluation 模塊，不過實(shí)現(xiàn)起來很簡單。

參考文獻(xiàn)：
5-Day AI Agents Intensive Course with Google
Agent Quality
Day 4a - Agent Observability
Day 4b - Agent Evaluation