原文：Mastering Agentic Techniques: AI Agent Evaluation · NVIDIA Technical Blog · 2026-05-19 作者：Edward Li、Vanessa Bellotti、Nicola Sessions、Rebecca Kao
一句话导读：模型基准告诉你「这台引擎在标准跑道上有多快」，Agent 评估告诉你「这台车在你家门口的烂路上能不能反复跑通」。这两件事，长得像，但根本不是同一个问题。
引言：一个 MMLU 90 分的 Agent，为什么在产线上反复掉链子
设想一个真实场景。你的「订单查询 Agent」上线第一周：
- 用户问：“帮我看下昨晚那笔订单到哪儿了？”
- Agent 调用
search_order(user_id, time_range)，参数 schema 多写了一个字段，API 返回 400。 - Agent 没有兜底，重试 12 次，每次都用同一个错误 schema，最终对用户说：“抱歉，系统繁忙。”
底模是哪家？业内顶配。MMLU、HumanEval 分数都在排行榜前列。但用户的任务一次没成。
这就是 NVIDIA 这篇文章想点破的窗户纸：
你在排行榜上读到的，是模型的能力上限。你在生产环境里付出的，是系统的轨迹质量。
中间隔着一整条链路：规划、工具调用、Schema 合规、失败重试、环境观察、多步推理。任何一个环节翻车，最终答案就是零分——而模型基准压根不会告诉你这件事。
一、范式分野：评模型 vs 评 Agent，到底在评什么
先把两件事彻底分开。这是后面所有评估动作的认知底座。
| 对比项 | AI 模型评估 | AI Agent 评估 |
|---|---|---|
| 评估对象 | 孤立的基础模型 | 端到端运行的系统 |
| 环境 | 静态、预定义 | 动态、非确定性 |
| 典型基准 | MMLU、GSM8K、HumanEval | GAIA、SWE-bench、WebArena |
| 核心指标 | 知识、推理、编码准确率 | TSR、Tool Call Accuracy、Trajectory Efficiency |
| 核心问题 | 引擎够不够强？ | 系统能不能反复跑通？ |
| 关注焦点 | 最终输出 | 完整轨迹（规划 + 工具 + 观测 + 结果） |
一个反常识的事实：模型基准分越高，越容易让你忽略 Agent 评估。因为顶级模型的能力盖住了大部分推理失败，剩下露出来的全是工具调用、Schema、规划与重试问题——而这些恰恰是模型基准压根不测的部分。
一句话总结：模型基准是「考卷」，Agent 评估是「跟车记录仪」。考卷打 90 分的人，未必能把车开到目的地。
二、五维评估清单：Agent 该被怎么打分
NVIDIA 这篇文章给出的不是「指标罗列」，而是一张能贴在工位上的检查表。我把它整理成五个维度——任意一项缺位，评估就有盲区。
维度 1 · 任务成功率（TSR），而不是「最终答案对不对」
把任务定义为 意图 + 约束 的组合，而不是只看输出字符串：
- ❌ 旧式：判 Agent 回答和参考答案的字符相似度
- ✅ 新式：「在 ≤ 2 次工具调用内、通过
update_orderAPI 完成订单状态修改」——意图 + 硬约束都满足才算 1，否则算 0
关键动作：分场景跟踪 TSR——正常场景、降级工具场景（API 限流/超时）、模糊指令场景。只看总体 TSR 会掩盖脆弱性，分场景拆开才能看见 Agent 在哪类情况下崩。
维度 2 · 完整轨迹，不只是终点
两个 Agent 给同样的答案，一个 3 步搞定，一个 17 步乱试——这两件事的可靠性、成本、可维护性，完全不在一个量级。
轨迹日志最少要记：
- 计划与子目标
- 每次工具调用的参数、响应、耗时
- 中间推理步骤（能记则记）
- 最终答案与副作用（写入、更新）
维度 3 · 工具使用是一等信号
生产级 Agent 的成败 80% 取决于工具用得对不对，而不是语言表达。
为每个评估任务声明 工具契约：
- 哪些工具允许 / 必须使用
- 每个工具的最大调用次数
- 每次调用预期的 Schema
衡量两件事：
- Tool selection precision / recall：选对了吗？避开错的了吗？
- Schema compliance：参数一次性通过吗，还是反复重试？
Schema 重试是个常被忽略的成本黑洞——模型在「幻觉一个看起来合理但不存在的字段」上能反复尝试十几次，不限次就能把账单刷穿。
维度 4 · 推理质量 & 效率
正确答案 + 错乱推理 = 高账单，且不可维护。
- 抽样标注推理轨迹：正确 / 部分有缺陷 / 错误
- 跟踪每次成功任务的 tokens / 工具调用次数 / 端到端延迟
- 用显式预算做约束：「95% 任务在 N tokens、M 次工具调用内完成」——这条预算线一旦写下来，就是优化 prompt、路由、重试策略的指南针
维度 5 · 自定义指标对齐业务
通用指标之上，叠加用例特定 KPI：
- 客服 Agent：语气合规率、是否触发安全词
- 研究 Agent：引用覆盖率、是否给出来源
- 风控 Agent：误判率、漏判成本
通用指标保你不至于不可靠，自定义指标决定你能不能上线——前者是地基，后者是验收单。
三、贯穿案例：同样的最终答案，两条天差地别的轨迹
把「订单查询 Agent」拿出来当示范。用户问：“昨晚那笔订单到哪儿了？”
两个 Agent 最终都答对了「正在派送，预计今晚 8 点送达」。但打开轨迹看：
Agent A · 精确轨迹（3 步）
get_user_recent_orders(user_id, limit=1)→ 返回订单 IDtrack_shipment(order_id)→ 返回物流状态- 综合答复用户
Agent B · 乱试轨迹（17 步）
search_orders()—— 参数 Schema 错误 → 重试 4 次query_database("SELECT * FROM orders")—— 工具选错，没权限web_search("订单 昨晚")—— 工具选错，无关结果- ……再瞎试 10 步，最终撞对
track_shipment拿到答案
| 指标 | Agent A | Agent B |
|---|---|---|
| 最终答案 | ✅ 正确 | ✅ 正确 |
| TSR（限 ≤ 5 步内完成） | 1 | 0 |
| Tool Call Accuracy | 100% | 12% |
| Trajectory Efficiency（步数） | 3 | 17 |
| Schema Compliance（一次过） | 100% | 38% |
| 单次成本（tokens 估算） | ~1.2k | ~14k |
| 端到端延迟 | ~2s | ~28s |
如果你只看「最终答案准确率」，这两个 Agent 在排行榜上是并列冠军。只有打开轨迹看，你才会发现 Agent B 是一个等着被熔断的定时炸弹。
这就是为什么 NVIDIA 反复强调：Outcomes + Tool Usage + Reasoning + Cost 四类信号必须同步追踪。少看一类，就有一类坑你来背。
四、把评估前置：评估驱动开发（EDD）循环
第 5 条 Tip 是这篇文章里最容易被一带而过、但最值钱的一条：不要事后补可观测性，从原型那一天起就把评估织进开发循环。
落地姿势分三层：
Layer 1 · 写代码时就埋观测点
- 每个 plan、tool call、关键推理步骤都打稳定 ID
- 轨迹结构化落盘（JSON Lines / OpenTelemetry span），不要只打 print
- 失败模式打标签：plan_failure / tool_failure / env_failure / schema_failure
Layer 2 · 建一个「日常跑」的评测集
- 不要只有大规模 benchmark，要有每次 PR 都能跑的小集合（30–100 case）
- 覆盖正常 + 降级 + 模糊 + 对抗四类场景
- 跑完自动产出 TSR、Trajectory Efficiency、Tool Call Accuracy 三件套报告
Layer 3 · 把评估指标接进 CI/CD
- 关键指标设 SLO：例如「TSR ≥ 92%、p95 步数 ≤ 8、Schema 一次通过率 ≥ 95%」
- 不达标的 PR 不准合入；上线后线上指标退化触发回滚
这条循环跑顺了之后，「这版 prompt 是不是变好了」这种主观争论会消失——剩下的全是可量化的对比。
五、Agent 评估的最小可行栈（MVS）
如果你今天刚要给一个 Agent 项目搭评估体系，最少最少需要这五块：
- 轨迹采集层：OpenTelemetry / LangSmith / NVIDIA NeMo Agent Toolkit — 任选一个，关键是落结构化日志，不是 print
- 评测集仓库：用 Git 管，case 是代码资产；至少 4 类场景分桶
- 指标计算器：跑一遍评测集，输出 TSR / Tool Call Accuracy / Trajectory Efficiency / Schema Compliance 四张表
- 可视化看板：Grafana / Streamlit / 自建 — 让 PM 和工程师看同一张图，省下一半口水
- CI 守门员：把指标 SLO 写进 GitHub Actions，不达标不让合
工具选谁都行，但这五块缺一块，你的 Agent 就是黑盒上线。
NVIDIA 自家方案是 NeMo Agent Toolkit——它的卖点是「可插入现有 Agent 框架，不重写就能加评估」。如果你已经在用 LangGraph / AutoGen / CrewAI，这是个值得评估的选项；如果是自建框架，至少要按这五块的形状自己拼一套。
收束：从「跑得通」到「反复跑得通」
回到开头那个 MMLU 90 分却在产线上掉链子的 Agent。它的问题不在模型，而在没人给它建立轨迹层面的反馈回路。
这篇文章可以浓缩成三句话：
- 评模型 ≠ 评 Agent：前者评能力上限，后者评系统下限。
- 核心三件套：TSR、Tool Call Accuracy、Trajectory Efficiency——任意一个缺位都看不出 Agent B 那种「答对但有病」的情况。
- 评估必须前置：从第一天就把它织进开发循环，否则就是事后救火。
Agent 不会因为底模升级而自动变可靠。反复跑得通这件事，永远要靠评估闭环亲手织出来——这是 NVIDIA 这篇文章给这个浮躁行业最朴素也最重要的一句提醒。
延伸阅读：
- GAIA: A Benchmark for General AI Assistants
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
- WebArena: A Realistic Web Environment for Building Autonomous Agents
- NVIDIA NeMo Agent Toolkit
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
