技术知识库 · 技术指南 · · 国科智飞 Gavin

Agent Eval：怎么证明一个 Agent 能上线

Agent 最危险的不是报错，而是做错了还显示已完成。一套最小可用评测框架：先定发布决策，结果与轨迹双评，三层评分，门禁把关。

Agent 最危险的状态不是报错，而是做错了还在界面上显示「已完成」。报错至少会让人停下来查；而一个编造了引用、越权调用了工具，或者外部系统根本没写入却回复「已完成」的 Agent，会把错误一路带进业务结果里。

本文的方法来自 X 用户 Cloris（@ClorisSignal）的一篇实操文章，原文用一个「资料研究 Agent」做案例，从零搭出一套最小可用 Eval。我们把它整理成可以直接落地的版本。原文链接：https://x.com/clorissignal/status/2095703810392150211

先写发布决策，再谈评测框架

多数团队一上来就搜「Agent Eval 用什么框架」。工具很快装好，真正要做的决定却没写下来。同一套 Agent，不同的发布决策需要完全不同的评测：

评测开始前先写一份 eval charter：评什么系统、评什么粒度（一轮对话、一段会话还是一次完整任务）、和什么比。system under test 要写完整——模型、Prompt、检索、工具、工作流、权限、环境都算系统的一部分，只记「用了哪个模型」，过几周就无法复现。

把「做完」写成可检查的条件

Agent 很容易制造完成的错觉：搜索 10 次不等于找到正确资料；成功调用保存工具不等于报告内容正确；回复「已完成」不等于外部系统真的变了。

因此，完成条件（Outcome）和硬失败（Hard Failure）都要提前写清楚。硬失败一旦发生，整个任务直接判死，例如：编造不存在的来源、把不支持结论的材料当证据、访问任务范围外的数据、未经允许向外部系统写入、工具已经失败仍宣称完成。

关键原则：硬失败不能混进平均分。报告完整度 95 分、语言 90 分，但编造了关键来源，平均分依然好看，业务却无法接受。正确做法是——安全、权限、关键事实做门禁，成本、延迟、语言做优化指标。

同时要有一份 Failure Taxonomy（失败分类），粒度要细到能指导修复：不是「v2 失败了」，而是「v2 的检索失败率从 8% 升到 17%，集中在跨两个来源的问题」，这样才知道去查什么。

结果与轨迹分开评

传统 LLM 评测是输入 → 模型 → 输出 → 打分。Agent 在中间多了一条会变化的路径：目标 → 计划 → 工具调用 → 观察 → 重规划 → 环境变化 → 最终输出。

没有 Outcome，只能判断「答案看起来对不对」；没有 Trajectory，失败后不知道该改模型、工具还是流程。对会改状态的 Agent，环境终态比最后那段回复更可信。

数据集：30 条起步，100–300 条过门禁

第一版 30 条真实任务就够跑通闭环，但要按类型配比：常见任务 12 条、边界或信息缺失 6 条、来源冲突 4 条、工具失败或空结果 4 条、已经发生过的事故 2 条、权限与对抗 2 条。发布门禁则建议用 100–300 条。

数据集最忌讳全是简单题——真实用户会省略条件、把两个要求写在一起、问没有答案的问题。没有线上数据时，可以让领域专家写案例，再让模型生成边界题和对抗题；但模型生成的题不能直接当金标准，否则出题和答题共享同一偏差。

每条 case 建议记录：必须覆盖的（must_cover）、允许的（allowed）、禁止动作（forbidden_actions）、期望终态（expected_outcome）、严重级别（severity）、切片（slices）和评分器。数据集分成 dev / holdout / regression / challenge 四份分别报告。数据也会过期，给每条 case 标注版本、负责人和刷新日期，比不断追加更重要；每次线上事故都要变成新的回归 case。

三层评分：Rules + Judge + Human

LLM Judge 本身也是测量工具，上线前需要 100–500 条专家确认的校准集，比较它与人工标签的一致度、对严重错误的召回、各切片表现，以及证据不足时是否愿意弃权。平均一致率高不代表安全：如果它判文风很准却放走伪造引用，就不适合做发布门禁。

一次成功不等于可靠

Agent 的输出有随机性。单次成功率 80%，连续 5 次全部成功的概率是 0.8⁵，约 32.8%。这就是 pass@k 与 pass^k 的区别：前者是 k 次里有一次成功即通过，适合代码探索这类允许试错的场景；后者要求连续 k 次全成功，适合日报、订单、改系统状态这类要稳定性的场景。重要 case 至少重复 3–5 次，比较 v1/v2 时用同一批 case、同一初始状态做配对评测。

Release Gate 与上线节奏

发布门禁要在看到结果之前就定好，至少覆盖几类指标：主指标（配对任务成功率有真实提升且置信区间支持）、安全项（越权操作与编造来源为零）、可靠性（关键 case 的 pass^k 达标）、效率（单次成功成本、p95 延迟不超阈值）、切片（来源冲突、证据不足、工具失败等高风险切片无重大回归）。

报告不要只给一个「综合质量 87.4 分」。总平均最容易藏问题：常见任务涨了 8 个点、来源冲突任务跌了 15 个点，混在一起只剩一个略升的数字。应至少包含整体成功率、关键 case 的 pass^k、各类失败率、风险切片、单次成功成本、延迟分位和置信区间。样本不足时，诚实的结论是「没发现重大回归」，而不是「显著更优」。

门禁通过也不等于立刻全量切流。先 shadow（收真实请求但不影响用户），再 canary（低风险流量、保留回滚），稳定后逐步扩大。

闭环：线上失败回到评测集

线上不必每条都送最贵的 Judge：先用便宜检查过滤（工具错误、空输出、循环次数、成本异常、缺引用、用户重试、人工接管），再抽三类样本精查——明确失败或告警的、Judge 不确定的、正常流量的随机样本。

每次改 Prompt、模型、RAG、Skill 或工具，都在同一套 case 上重跑，一次只改一个主变量，结果变了才知道是谁带来的。系统复杂后可以测组件增量（Component Lift）：固定任务、模型、环境和评分器，只切换一个组件。多 Agent 方案则必须和最强的单 Agent 基线比较——加 Planner、Researcher、Critic 会同时增加成本、延迟、交接损失和故障点，质量收益要覆盖这些代价。

检查清单

第一版不需要企业级评测平台：一个明确任务、30 条真实 case、几个检查脚本，再加一份人工 Rubric，就能跑通发布决策的闭环。

参考来源