发布时间2026-07-12标签AI AgentLLMBenchmark质量评测工程实践系列导航上一篇AI Agent 工程实践17Agent 为什么需要可观测性Observability下一篇 AI Agent 工程实践19从 Demo 到生产环境——AI Agent 的工程 Checklist本文是 [AI Agent 工程实践] 系列的第 18 篇第二季 · 工程实现。上周我改了一行 Prompt——把请详细回答改成了请简洁回答。感觉上Agent 回答变快了。优化成功我在 commit message 里写道。三天后我发现这行改动让代码审查任务的漏检率从 12% 涨到了 28%——Agent 变简洁了但也跳过了关键检查项。感觉好了和真的好了差了一个 Benchmark。我说的是 Benchmark Agent不是 Benchmark 模型。前者回答改完之后 Agent 变好了吗后者回答哪个模型分高。你改了一行 PromptAgent 变好了还是变差了——没有 Benchmark你永远不知道。本文你将学到✓ Benchmark Agent 和 Benchmark 模型的本质区别——前者是持续交付后者是选型✓ Agent Benchmark 的核心链路Task → Expected → Result → Score✓ 四个关键指标Success Rate / Cost / Time / Tool Calls✓ 如何把 Benchmark 做成 CI/CD——每次改动自动跑、自动对比适合阅读✓ 经常调 Prompt / Rule / Tool、但靠感觉判断效果的人✓ 想让 Agent 的质量像代码一样可回归测试的人✓ 不知道Agent 改完是变好还是变坏的人问题背景99% 的 Benchmark 文章在讲同一件事哪个模型更好。MMLU 几分、HumanEval 几分、这个榜那个榜。但 Agent 开发者真正需要的不是选模型时的决策依据——模型选完之后问题才刚开始。你每天在做的操作是改了core/00-must.md的一条规则加了一个新的 heavy 文件调整了 Router 的 priority 配置换了一个 Tool 的实现每次改动后Agent 是变好了还是变坏了这个问题MMLU 回答不了HumanEval 也回答不了。因为它们在测裸模型不是在测你的 Agent 这个具体系统。Benchmark Agent 不是做一次是每次改动后都做——这才是真正的 CI/CD for Agent。它回答的不是GPT-5 比 GPT-4 好多少而是你今天的 commit 让 Agent 的质量涨了还是跌了。错误尝试第一次靠感觉判断质量改完 Prompt自己跑几个 case觉得好像不错就上线。结果很多退化是统计意义上才可见的——成功率从 92% 降到 88%跑 5 个 case 根本看不出来跑 50 个才能发现。感觉是 Benchmark 的敌人——感觉好的时候往往指标在变差。第二次只测最终输出对错搭了一套自动评测给 Agent 一个任务比对输出是否和预期一致。对就是对错就是错。结果Agent 的输出对了但多了 3 次不必要的 Tool 调用延迟从 5 秒变成了 18 秒token 消耗翻了一倍。用户不会告诉你答案对了但太慢了——他们直接不用了。只看 Success Rate 的 Benchmark和只看血压的心脏检查一样——漏了一半的指标。两次尝试指向同一个教训Benchmark 需要多维度 回归对比 统计显著。不是跑 5 个 case 看看而是每次改动后对同一组标准任务跑分、和历史版本对比、多维指标综合判断。关键观察我把Agent 上线后退化的 case做了根因追溯退化类型改动操作单看 Success Rate 能发现吗占比成功率下降改了一条 Rule✅ 能30%延迟暴涨加了一个 Tool 调用❌ 不能Success 反升25%成本翻倍改了 Router 配置❌ 不能25%Tool 调用冗余改了 Planner❌ 不能20%pie title Agent 退化的可检测性只看 Success Rate Success Rate 能发现 : 30 延迟暴涨Success Rate 看不出 : 25 成本翻倍Success Rate 看不出 : 25 Tool 冗余Success Rate 看不出 : 20你改了一行 PromptAgent 变好了还是变差了——没有 Benchmark你永远不知道。70% 的质量退化Success Rate 看不出来。你需要四维指标同时跑——少一维就有一个盲区。最终方案Agent Benchmark 四维体系核心链路Task → Expected → Result → ScoreBenchmark 的本质就是标准任务 预期输出 多维评分 回归对比。少任何一环就是盲测。四个指标的全部含义指标测什么为什么不能只看它怎么算Success Rate输出是否正确覆盖不了效率和成本退化正确数 / 总任务数CostToken 消耗单独看没意义——便宜的废品还是废品input_tokens × 单价 output_tokens × 单价Time端到端延迟快没用的答案也是没用从 Task 进入到 Result 输出的总耗时Tool Calls调用效率答案对了但调了 10 次 Tool是浪费任务完成用的 Tool 调用次数四维不是四个独立的分数是综合评判。我的产出公式是综合分 Success Rate × 0.5 (1 - Cost/预算) × 0.2 (1 - Time/阈值) × 0.2 (1 - ToolCalls/上限) × 0.1Success Rate 占 50% 权重答案对不对最重要但 Cost / Time / Tool Calls 各占其余 50%——一个慢到不可接受的 Agent和答错的 Agent 一样不能用。Benchmark 作为 CI/CD真正的价值不在测一次在每次改动都测、每次和历史对比def benchmark_regression(agent_v2, test_suite, baseline): 每次 commit 后自动跑和历史版本对比 v2_scores run_benchmark(agent_v2, test_suite) report { success_rate: (v2_scores.sr, baseline.sr, v2_scores.sr - baseline.sr), cost: (v2_scores.cost, baseline.cost, v2_scores.cost - baseline.cost), time: (v2_scores.time, baseline.time, v2_scores.time - baseline.time), tool_calls: (v2_scores.tc, baseline.tc, v2_scores.tc - baseline.tc), } # 如果任一指标退化超过阈值CI 报红 degraded any(delta -THRESHOLD for _, _, delta in report.values()) return FAIL if degraded else PASSAgent 的 CI/CD 不是代码能跑就行是质量没跌就行。架构图 / 流程图Benchmark 驱动的 Agent 迭代闭环关键不是上线前手动测一下——是每次 commit 自动跑、自动对比、退化自动阻止。这和第 04 篇 Review 闭环、第 15 篇 RAG Evaluate 闭环是同一种思想反馈系统必须自动化靠人做不了。代码或配置示例标准 Benchmark 任务集定义# benchmark/suite.yaml tasks: - id: code_review_01 task: 审查这段 Python 代码的安全性 expected: must_contain: [SQL 注入风险, 建议使用参数化查询] must_not_contain: [看起来不错, 没有明显问题] - id: db_query_01 task: 查询 user_id42 的订单状态 expected: must_return: shipped max_tool_calls: 2 - id: report_gen_01 task: 根据过去 10 条订单生成周报 expected: must_contain: [总订单数, 完成率] max_time_ms: 8000Benchmark 执行引擎def run_benchmark(agent, suite: list) - BenchmarkScore: results [] for test in suite: start now() result agent.run(test.task) # Trace 自动记录17 篇 elapsed (now() - start).ms # 四维评分 sr 1.0 if evaluate(result, test.expected) else 0.0 cost result.total_tokens * TOKEN_PRICE tc result.tool_calls_count results.append({sr: sr, cost: cost, time: elapsed, tc: tc}) # 汇总所有任务的各维度取平均值 return BenchmarkScore( srnp.mean([r[sr] for r in results]), costnp.mean([r[cost] for r in results]), timenp.mean([r[time] for r in results]), tcnp.mean([r[tc] for r in results]), )和 17 篇的 Trace 无缝衔接每跑一次 Benchmark 都是一次完整的 Trace 记录。Benchmark 不只产出一个分数还产出了每次运行的完整调用链——分数跌了Trace 告诉你哪个 Span 出了变化。设计权衡候选方案优点缺点为什么不选靠感觉评测零成本完全不可靠感觉骗人只看 Success Rate简单直观漏 70% 的退化效率/成本退化看不见人工评测每次手测最准不可持续规模一大人就崩自动 Benchmark CI 回归持续可对比、多维覆盖需维护标准任务集选择理由唯一把质量变成可量化、可自动化的工程实践的方案Benchmark 的任务集需要持续维护。标准任务集不是写完一次永远不变——新功能上线要加新 case过时的 case 要淘汰。这本身也是一个治理问题和第 15 篇 RAG 知识治理同源测试集本身也有生命周期。总结✅ Benchmark Agent ≠ Benchmark 模型——前者是持续交付的 CI/CD后者是选型依据。✅ 核心链路Task → Expected → Result → Score → 和历史 baseline 回归对比。✅ 四维指标缺一不可——Success Rate / Cost / Time / Tool Calls。只看 SR 会漏掉 70% 的退化。✅ Benchmark 必须做成 CI/CD——每次 commit 自动跑、自动对比、退化自动阻止合并。✅ 测试集本身也需要治理——新 case 持续加、旧 case 淘汰更新。参考资料第 17 篇Agent Observability→ Trace 是 Benchmark 的数据源每次 Run 生成完整 Trace第 15 篇RAG 知识治理→ 测试集的治理与知识治理同构第 04 篇Review 闭环→ Benchmark 是 Review 的量化工具RAGAS / LangSmith Evaluation→ Agent 自动评测的工程参考实现ML CI/CD (MLOps)→ 模型回归测试的最佳实践Agent Benchmark CI 的思想来源系列导航上一篇AI Agent 工程实践17Agent 为什么需要可观测性Observability下一篇 AI Agent 工程实践19从 Demo 到生产环境——AI Agent 的工程 Checklist本文是 [AI Agent 工程实践] 系列的第 18 篇第二季 · 工程实现。
