Agent Evals 是对代理任务结果、执行过程和失败情况进行系统评估的方法。ReviewBench 则是面向 AI 代码审查的专项基准。企业验收代理时，应先定义本业务中的成功结果，再使用对应的测试与评审方法，不能只凭回答流畅或通用榜单判断可用性。
代理评估为什么比检查一次回答更复杂？
一次问答主要看生成内容是否正确，代理任务还会读写数据、调用工具并改变外部状态。最后的文字总结可能很完整，但文件没有生成、记录没有更新，或者中间步骤已经选错业务对象，这些都属于任务失败。
Anthropic 在 2026 年 1 月的评估文章中，将任务、一次执行尝试、评分逻辑与完整轨迹区分开。这个框架的实用价值在于让团队说明：测的是什么任务、重复了几次、依据什么判定，以及出现问题后能否找到执行记录。
先把成功写成可以核对的结果
假设代理负责把合同中的交付日期整理到清单。验收不能只要求“提取准确”，而应明确每个日期对应哪项义务、是否保留原文位置、日期缺失时如何标注，以及有没有把签订日期误当成交付日期。
业务人员可以先准备合格输出与典型错误。若连人工评审者都无法根据同一规则判断结果，自动评分通常也不会稳定。定义成功标准本身就是需求澄清，而不是功能做好之后才补的测试文档。
怎样组织第一批评估任务？
从实际出现过的失败和高频工作开始，覆盖正常输入、材料缺失、表述冲突和工具异常。每个测试保留输入材料版本与预期规则，避免测试文件被修改后，前后结果失去可比性。
任务数量应服从业务覆盖需要，不用为了数字好看大量复制相似案例。先让每个案例都能解释一种独立风险，再逐步增加。还要保留一些未参与调试的案例，检查系统是否只记住了测试写法。
规则检查、模型评分和人工复核怎样分工？
文件是否存在、必填字段是否齐全、金额加总是否一致，适合确定性规则。语气是否符合品牌要求、摘要是否突出重点等主观问题，可以让模型给出评分依据，再用人工样本校准。
模型评分也可能受到表达风格和长度影响，不能天然视为客观裁判。对于重要事实，优先检查原始证据和业务规则。人工复核应关注争议和边界样本，逐步把反复出现的问题整理成更明确的判定标准。
ReviewBench 能提供什么参考？
GitHub 在 2026 年 10 月 5 日公布 ReviewBench，介绍面向代码审查代理的评测方式，包括真实风格的拉取请求、多来源参考依据和贴近生产的指标。它回应的是审查工具能发现什么、会漏掉什么、会产生多少噪声。
因此比较代码审查能力，不能只数评论条数。发现关键缺陷、把建议落在正确位置，以及减少没有价值的意见，都影响实际使用。本文没有运行 ReviewBench，也不提供任何未经验证的产品排名或分数。
通用基准为什么不能替代企业验收？
外部基准可以帮助理解能力维度，但业务环境中的代码结构、数据、权限和工具链可能不同。某个模型在榜单中表现良好，并不意味着它已理解企业内部约定，也不能证明其能够安全处理本系统的状态变更。
可以把外部方法用于完善内部测试。例如借鉴代码审查基准对误报的关注，在合同审查或客户线索审核中也记录无效提醒。迁移的是评估思路，而不是直接复制一个分数作为采购或上线结论。
如何用评估推动后续迭代？
每次调整提示词、工具、检索或模型，都运行同一组测试，查看哪些任务变好、哪些退步。结合执行时间、单次成功成本与人工修正量，才能判断改动是否值得保留。
发布之后仍需观察真实任务。生产中的新输入可能超出测试范围，应将确认的问题补入案例集，保留修复前后的证据。这样评估会逐步成为业务知识与工程维护的共同语言，而不是上线前临时勾选的一份检查表。
一份可复核的评估报告应该写什么？
报告应说明任务输入、执行环境、判定规则、每次尝试结果与失败分类。以文档提取为例，分别记录字段值是否正确、来源位置是否正确以及缺失项有没有被编造。不能把几个维度平均成一个漂亮分数之后，就隐藏了关键字段错误。
还应说明哪些验证没有执行。只检查生成文件存在，不等于检查文件内容正确；在测试环境通过，不等于生产连接器已可用。若使用模型评分，保存评分依据和人工校准样本，便于发现评分偏差。团队可以先用简单表格管理这些结果，重点是让产品负责人和工程人员能够依据同一份证据决定保留、修复或回退改动。
官方资料与核验范围
本文资料核验日期为 2026 年 10 月 17 日。下列日期指对应公告或工程文章的发布日期，不代表概念首次出现；产品可用范围、版本与接入条件请以官方当前说明为准。文中业务案例为帮助理解而设计的假设示例，不是实测成绩或客户交付承诺。