# 评估与可观测性 · 测试、Tracing 与质量度量 · Agent 实战 · 从零构建完备智能体 **作者** Aklman · **章节** 10 / 19 · **首发** 2026.07 · **语言** 中文为主, 中英双语 **原文** https://library.aklman.com/books/build-agent/10-evaluation **全书 markdown** https://library.aklman.com/books/build-agent/llms.md **上一章** https://library.aklman.com/books/build-agent/09-safety/llms.md **下一章** https://library.aklman.com/books/build-agent/11-production/llms.md > 本章来自 Aklman · Library, 完整免费阅读。允许 AI 摘读、引用、问答; 转载请保留作者署名与原文链接 (CC BY-NC-ND 4.0, https://library.aklman.com/license)。 --- > 你无法改进你无法度量的东西 —— Agent 的评估不是跑一次 benchmark，而是持续的可观测性。 你无法改进你看不见的东西。研究助手交回一份烂报告时，你看到的是「报告不对」，看不到的是「第三步它把一个标题党网页当成了可信来源」。这一章讲怎么让它的每一步可见、可度量、可回归 —— 评估不是发布前跑一次 benchmark，是持续的可观测性。 ### I · 先能看见，才能改 —— Tracing agent 是个多步黑盒。不给每一步装上 trace，你调的就是黑盒 —— 只能猜。 每一步都要可追溯：模型的决策、调了哪个工具、参数、结果、token、延迟。OpenTelemetry 的 GenAI 语义约定给了这些字段一套标准，[^1]好处是你的 agent trace 能直接接进现有的监控体系，而不是另造一套。落到工具上，Langfuse 这类平台把 trace、评估、回归集放在一起。[^3] 没有 trace 的 agent，在 demo 里很美，在生产里没法维护 —— 因为你修不了你看不见的东西。tracing 不是上线后才加的运维项，是从第一个循环就该埋的线。 --- ### II · 评估不是一次 benchmark，是一套回归集 跑一次 benchmark 漂亮，证明不了什么。能证明的是一套每次改动都重跑的回归集。 建一个 golden set：一组输入，配上每个的期望行为（调对了工具？给对了答案？步数合理？）。每次改 prompt、换模型、加工具，重跑一遍，挡住「修好一个、弄坏三个」。规模大了人工评不过来，就用 LLM-as-judge —— 让一个强模型评判输出，便宜可扩展，但它有偏差，得先用人工标注校准过。[^2] 回归集不用大，要稳。20 个覆盖真实场景和已知坑的用例，比 1000 个随机用例有用 —— 它每次都告诉你「这次改动有没有让 agent 变笨」。 --- ### III · 度量任务成功率，不是「看起来对」 agent 的质量不是「回答流不流畅」，是「任务做没做成」。度量要落在可检验的成功标准上。 给每类任务定义可检验的成功：订单查询 —— 查到的状态对不对；代码任务 —— 跑起来、测试过没过；研究任务 —— 引用真不真实。把这些指标连同 token 成本、步数、延迟一起持续盯着（第一节的 trace 就是数据源）。一个成功率 70% 但你以为 95% 的 agent，比一个老老实实告诉你 70% 的更危险。 量成功率，还得分清你量的是哪一个数。让同一个任务跑 k 次：「至少成功一次」的概率是 **pass@k** —— 它量能力上限，demo 和刷榜看它；「k 次全部成功」的概率是 **pass^k** —— 它量可靠性，生产系统看它。这个记号是 τ-bench 提出来的，动机就是「度量 agent 行为在多次试验下的可靠性」，实测结果扎心：当时最强的 function calling agent（gpt-4o）任务成功率不到 50%，而在 retail 域，连续 8 次全对的 pass^8 掉到 25% 以下。[^6]跑对一次和次次跑对，中间隔着整个生产的距离。两个数用同一批重跑就能算： _pass@k 与 pass^k：同一批重跑，回答两个问题_ ```text ```python from math import comb def pass_at_k(n, c, k): # 能力上限:k 次里至少对一次的概率 return 1.0 if n - c < k else 1 - comb(n - c, k) / comb(n, k) def pass_hat_k(n, c, k): # 可靠性:k 次全对的概率(τ-bench 的 pass^k) return 0.0 if c < k else comb(c, k) / comb(n, k) # 每个任务重跑 n 次、数出成功 c,分别算出后再对任务取平均。 # 两个都报:pass@k 涨而 pass^k 不涨,说明它更会蒙,没更可靠。 ``` ``` 第二件要分清的，是两个数的差什么时候算数。评测是实验，实验自带噪音 —— 二项分布一算就现形：50 道题的集合上，60% 与 70% 的通过率，95% 置信区间各约 ±13–14 个点，两个区间大面积重叠，这个「提升了 10 个点」根本检不出显著；30 道题只会更宽。所以三条规矩，都来自 Anthropic 的《Adding Error Bars to Evals》：报成功率要带标准误；比较改动前后，用「同一批题上的题级配对差」做推断，而不是两个总分相减 —— 同题配对的方差减免是白赚的；动手前先算最小可检测效应（MDE），论文的算例是要在 80% 功效下检出 3 个点的差距，约需 1000 道题。[^7]这不推翻第二节「20 个稳定用例」的建议 —— 小回归集抓得住「修好一个、弄坏三个」的大崩坏；它只是划清一条线：**小样本上的个位数点差不构成结论**。要下「变好了」的结论，扩样本，或对每题重跑多次再配对比。 把成功率和成本合成一个数，就有了 cost-of-pass：成本 ÷ 成功率 —— 一次「成功通过」的期望花费。Efficient Agents 用它在 GAIA 上量各模块值不值，做到保留 96.7% 性能、成本从 $0.398 降到 $0.228。[^4]它给「这一格值不值得加」一个能横向比的数，而不是凭感觉。 这事整个行业都做得不好。MIT 的《2025 AI Agent Index》盘点了 30 个已部署的 agent，发现 25/30 不披露任何内部安全评测、只有 4 个有 agent 专属的 system card —— 能力大家抢着说，评估和安全没人晒。[^5]别成为那 25/30：评估做了，还要留得下记录。 --- ### IV · 评测作为常设能力：门禁、判官校准、别让平均掩盖尾部 在企业里，评测不是发布前的一个动作，是一条常设的产线。三件事把它从「跑一次」升成「一直在跑」：把回归集接进 CI 当门禁、校准你的判官、以及盯住平均分背后的尾部。 第一件：**回归集当 CI 门禁**。第二节那个 golden set，价值只有接进 CI 才兑现 —— 每次改 prompt、换模型、动工具，CI 自动重跑，成功率掉到阈值以下就**挡住合并**，像单元测试挡住会崩的代码一样。这把「评估」从一份季度报告，变成一道每个 PR 都要过的闸。没有这道闸，「修好一个、弄坏三个」迟早会悄悄合进主干。 第二件：**校准判官**。LLM-as-judge 便宜可扩展，但它有系统性偏差 —— 位置偏差（偏爱两个候选里的某个位置）、长度偏差（把更长的当更好）、自我偏好（偏爱同族模型的输出）。[^2]这些不是玄学，是可测的。校准的做法：拿一小批人工标注当「判官的 golden set」，量判官和人的一致率；一致率不够高，判官的分数就不能当真。评分标准（rubric）该由业务持有 —— 什么叫「答对」是产品决定的，不是判官模型自己发挥。judge 是工具，rubric 是业务契约，别把后者外包给前者。 第三件：**别让平均掩盖尾部**。「平均成功率 92%」听着好，但如果那 8% 的失败集中在某一类高价值任务、或某一个租户身上，平均分正好把它藏了起来。企业级评测要看分布：按任务类型、按租户切开的成功率，和最坏情况（p95 延迟、最差那一档的准确率）。再加一层 **guardrail 指标** —— 不是「答得多好」，是「有没有越界」：越权工具调用率、注入命中率、PII 泄露率、人闸触发率。这些和线下评测互补：线下用 golden set 回归，线上盯 guardrail 指标 + 真实成功率。两头都要，缺一头你就是在用一个漂亮的平均分，赌你没看见的那条尾巴。 动手 · 给你的 agent 装上度量： - 给循环每一步打 trace：决策、工具、参数、结果、token、延迟，至少先写进日志。 - 建一个 10 个用例的 golden set，每个配一条可检验的成功标准。 - 改一次 prompt，跑改前改后的回归，量出成功率的变化 —— 别靠感觉判断「变好了」。 > demo 看一次就够， > 回归集要天天跑。 ## 引用与参考 01 · OpenTelemetry · GenAI 语义约定 —— 为 LLM / agent 调用定义标准的 trace / span 字段（模型、token、工具调用等），让可观测性可移植、可对接现有监控。截至 2026-05。 (OpenTelemetry · GenAI semconv) 02 · Zheng et al. · 「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」（2023，arXiv:2306.05685）—— 用一个强模型评判另一个模型输出的方法、效力与偏差，是 agent 自动评估的常用手段。 (arXiv · LLM-as-a-Judge (2306.05685)) 03 · Langfuse —— 开源 LLM / agent 可观测性平台，把 trace、评估、回归集放在一起。作为「把 tracing 落到工具」的一个代表。 (Langfuse · Docs) 04 · Wang et al. · 「Efficient Agents: Building Effective Agents While Reducing Cost」（2025，arXiv:2508.02694）—— 定义并使用 cost-of-pass = 成本 ÷ 成功率（一次成功通过的期望花费）在 GAIA 上度量各模块值不值；其框架保留 96.7% 性能、成本从 $0.398 降到 $0.228。 (arXiv · Efficient Agents (2508.02694)) 05 · Staufer et al. · 「The 2025 AI Agent Index」（MIT 等，2026，arXiv:2602.17753；aiagentindex.mit.edu）—— 按 6 大类、45 字段记录 30 个已部署 agent；发现 25/30 不披露内部安全评测、23/30 无第三方测试、仅 4 个有 agent 专属 system card —— 能力披露多，安全与评估披露极少。 (arXiv · The 2025 AI Agent Index (2602.17753)) 06 · Yao et al. · 「τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains」（2024，arXiv:2406.12045）—— 工具调用 + 模拟用户的 agent 基准；提出 pass^k「度量 agent 行为在多次试验下的可靠性」（k 次全部成功的概率，区别于 pass@k 的至少一次）；实测当时最强的 function calling agent（gpt-4o）任务成功率不到 50%，retail 域 pass^8 低于 25% ——「结论指向需要让 agent 行为更一致、更可靠守规则的方法」。 (arXiv · τ-bench / pass^k (2406.12045)) 07 · Miller · 「Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations」（Anthropic，2024-11，arXiv:2411.00640）—— 把评测当实验对待：报成功率要带标准误（二项情形 SE = √(p(1−p)/n)）、成组题用聚类标准误、比较两个模型要「对题级配对差做统计推断，而非各自的总体汇总统计」、用功效分析 / 最小可检测效应（MDE）先判断评测集测不测得出目标差距；算例：80% 功效下检出 3 个点的差距约需 1000 题。 (arXiv · Adding Error Bars to Evals (2411.00640)) --- *评估与可观测性 · 测试、Tracing 与质量度量 · Agent 实战 · 从零构建完备智能体 · Aklman 著 · CC BY-NC-ND 4.0 · https://library.aklman.com/books/build-agent/10-evaluation*