目录一、Agent 时代评测对象已经发生了根本变化一传统“输入—输出—打分”为什么不够了1、从静态文本生成转向持续改变世界状态2、“模型能力”与“产品能力”必须分开二真正的 ground truth 往往在 outcome而不在 transcript1、最终状态应该优先于“看起来像成功”2. 结果负责定输赢轨迹负责解释原因二、把一个 Agent eval 拆开你真正需要设计的是什么一Task、Trial、Grader、Trace、Outcome 是五个不同问题1、Task不是一道“题”而是一份可执行契约2、Trial一次运行不能代表一个随机系统3、Grader评分器本身也是一个需要被验证的软件系统4、Trace不是为了监控每一步而是为了定位失效机制5、Outcome最好能被独立验证二Evaluation harness测量系统也要有“测量学纪律”1、环境漂移会把假问题伪装成模型问题2. 推荐记录的最小运行元数据三、从“能力”走向“可靠交付”为什么一次成功远远不够一passk 与 pass^k 讲的是两种完全不同的产品故事1、passk多给几次机会至少成功一次2、pass^k连续 k 次都成功二长链路任务的真正敌人是可靠性乘法1、单步看起来很高的成功率串起来可能非常脆弱2. 需要把“恢复能力”也纳入评测三评测结果不应该只有一个总分四维评分比单一排行榜更接近生产决策四、评分器设计最重要的不是“智能”而是“可验证”一能用确定性检查就不要先上 LLM Judge1、硬事实交给代码2、主观质量再交给模型评分器二一个大而全的 Judge通常不如多个窄 Judge1、把评价维度拆开2. 给 Judge “不知道”的出口三结果评分与过程评分要有不同权重1、核心业务状态通常是硬约束2、路径约束只用于真正必要的流程五、评测数据集设计真正困难的是定义“什么叫成功”一最好的第一批测试通常来自真实失败1、不需要一开始就有几百条2、把线上失败变成永不丢失的回归资产二每道题都必须先证明“它真的可解”1、两名领域专家能否独立达成相同判断2、Reference solution 是评测基础设施的单元测试三平衡“应该做”和“不应该做”的案例单侧数据集会制造过度行为四能力集与回归集必须分开维护1、Capability eval 要故意难2、Regression eval 要接近全通过六、从“一套 benchmark”升级成“评测资产组合”一生产级 Agent 至少需要四类 suite1、能力前沿集告诉你下一座山在哪里2、回归保护集告诉你有没有把旧东西弄坏3、生产回放集告诉你离真实用户还有多远4、对抗与策略集告诉你系统会不会“聪明地做错事”二为什么“一个总榜”容易误导团队1、不同 suite 的目标函数本来就不同2、发布决策应该基于门禁与权衡而不是单一均值七、EvalOps把评测从研究脚本变成产品基础设施一评测必须进入版本控制和 CI/CD1、Eval 应与 prompt、tool schema、agent code 一起变更2、每次变更都要保留可比较的实验记录二失败分析是 eval 中最不能自动化掉的一环1、定期阅读 trace 是团队理解系统的高带宽渠道2、建立固定的失败分类法三防止评测饱和和“考试教学化”1、100% 通过的能力集已经失去研究信号2、不能只优化榜单必须持续验证分布外行为八、Agent 评测正在进入第二阶段长任务、动态世界与人机协同一长任务不只是更多 token而是更多隐藏状态OSWorld 2.0 体现了新的难点二用户不再只是出题者而会成为环境的一部分τ²-bench 的双控制视角非常重要三时间跨度会成为重要的能力坐标“能完成多长的人类任务”比单题正确率更有解释力四多 Agent 系统会让评测更像分布式系统测试新问题是协调、通信和共享记忆九、一个更实用的工程框架把 Eval 当成“可执行产品契约”一产品需求必须能被翻译成机器可检查的承诺1、每个关键能力都应对应至少一个可执行测试2、每个关键风险也应对应一个反例测试二可以引入一个“评测债务”概念评测债务会随着系统变化速度复利三最终目标不是追求最高分而是缩短“安全改进循环”好 eval 的本质是提高研发反馈带宽十、落地路线从零开始建立可用的 Agent Eval一第 1 周定义成功而不是先选工具1、建立 20–50 个高价值任务2、给任务分层二第 2 周先做 outcome verifier再做复杂 Judge1、建立稳定环境2、保存完整 trace 与元数据三第 3 周加入模型评分器并完成人工校准1、只把主观问题交给 LLM Judge2、同时测能力与可靠性四第 4 周接入 CI/CD建立长期维护制度1、每次关键变更自动跑回归2、每周固定审查失败轨迹3、每月检查评测健康度十一、结语真正成熟的 Agent 团队先建设“可验证性”可参考文章与论文干货分享感谢您的阅读当大模型从“回答问题”走向“调用工具、修改状态、持续规划并与用户协作”传统以单轮答案为中心的评测方法开始失效。真正需要被验证的不再只是模型能否生成一个看起来正确的结果而是“模型 Agent 脚手架 工具 环境 多轮轨迹 最终状态”组成的完整系统能否在真实约束下稳定地完成任务。我们在系统吸收 Anthropic 2026 年关于 Agent eval 的工程经验基础上进一步提出一套面向生产系统的评测框架以最终状态为主判据、以轨迹为诊断证据把能力、可靠性、安全性与效率拆成独立维度用能力前沿、回归保护、生产回放与对抗策略四类评测组合成“评测资产组合”再通过 EvalOps 把线上失败持续转化为离线测试。同时讨论passk、pass^k、长链路可靠性、LLM-as-a-Judge 校准、环境隔离、任务可解性、评测饱和、动态世界与双控制交互等关键问题并给出一套可直接落地的实施路线。一、Agent 时代评测对象已经发生了根本变化一传统“输入—输出—打分”为什么不够了1、从静态文本生成转向持续改变世界状态过去的语言模型评测通常可以被压缩成三个元素给定一个问题得到一个回答再判断回答是否正确。这个范式非常适合翻译、分类、数学题、知识问答等“输出即结果”的任务。Agent 则不同。一个真正有行动能力的 Agent 往往要读取文件、调用 API、搜索网页、修改数据库、执行代码、与用户来回确认并依据中间结果动态调整后续动作。最终用户在意的并不是它“说了什么”而是它究竟“做成了什么”。因此一个客服 Agent 即使最后回复“退款已完成”如果数据库里没有退款记录它仍然失败一个代码 Agent 即使解释得非常合理如果测试没有通过它也没有完成任务。这意味着 Agent 的评测对象必须从“语言输出”扩展为“状态转换系统”。Anthropic 将 task、trial、grader、transcript、outcome、evaluation harness、agent harness 和 evaluation suite 分开定义本质上是在提醒开发者评测 Agent 时需要先把“任务”“一次尝试”“执行轨迹”“最终状态”“评分逻辑”和“运行基础设施”解耦否则很容易把不同层次的问题混成一个分数。[1]微小错误会在长链路中被放大单轮模型犯一次小错往往只影响一次回答Agent 在长链路里犯一次小错则可能改变后续所有观察。比如一个研究 Agent 在第一轮检索中把公司名称识别错了后续引用、数据匹配、结论和建议都可能建立在错误实体之上。换句话说Agent 不是简单地“多回答几次”而是在一个可变环境里持续执行状态转移。因此评测必须回答至少四个问题任务定义是否清楚环境是否可信行为轨迹是否合理最终状态是否满足目标只看最后一段文本无法区分这些问题。2、“模型能力”与“产品能力”必须分开同一个模型装进不同 Agent harness表现可能显著不同。工具描述是否清晰、上下文裁剪是否合理、错误重试策略是否健壮、是否允许并行、是否设置了停止条件、是否保留了正确的环境反馈都会影响最终成功率。Anthropic 在更早的 Agent 工程文章中也强调Agent 的工具接口和脚手架设计本身会显著影响效果因此不能把一个 Agent 产品的结果简单归因于底层模型。[2]这带来一个重要工程结论模型 benchmark 不是产品验收测试。模型 benchmark 可以告诉你底层能力的上限和趋势但真正用于发布决策的 eval必须尽量复现生产环境中的工具、提示词、状态、权限、预算和交互方式。二真正的 ground truth 往往在 outcome而不在 transcript1、最终状态应该优先于“看起来像成功”Agent 有一种非常危险的失败语言层面给人以“已经完成”的错觉但真实世界状态没有发生对应变化。对这类系统最可信的评分方式通常是检查执行后的环境数据库有没有新记录文件有没有被正确修改订单是否存在测试是否通过权限是否满足页面状态是否达到要求。这也是 τ-bench、SWE-bench、WebArena、OSWorld 等 Agent benchmark 共同体现的趋势尽量使用可执行环境和状态验证而不是只让另一个模型阅读最终答案后判断。[3][5][8]2. 结果负责定输赢轨迹负责解释原因“结果优先”并不意味着轨迹不重要。恰恰相反transcript/trace 是诊断 Agent 的关键证据。一个任务失败后团队需要知道失败究竟来自哪里需求理解错、工具选择错、参数填错、环境超时、检索质量差、规划中断还是评分器本身写错。更稳健的原则是outcome-first, trace-diagnostic。即尽可能用最终状态判定是否完成核心目标再用轨迹检查政策遵循、工具使用质量、沟通质量、效率和失败原因而不是把某一条固定执行路径强行写成“唯一正确答案”。核心结果用状态验证过程轨迹用于诊断、合规和质量判断。这样既减少对“唯一正确路径”的过拟合又保留足够的可解释性。二、把一个 Agent eval 拆开你真正需要设计的是什么一Task、Trial、Grader、Trace、Outcome 是五个不同问题1、Task不是一道“题”而是一份可执行契约一个高质量 task 至少要明确初始状态、用户目标、允许使用的工具、约束条件、结束条件和成功标准。对于开放式任务还应该说明哪些约束是硬约束哪些是质量偏好。很多评测的噪声并不来自模型而来自任务本身不完整。例如要求 Agent 生成脚本却没有指定保存路径但评分脚本默认只在固定目录查找或者题目要求达到某个阈值评分器却要求明显高于阈值。这类“任务—评分器不一致”会把评测变成测量基础设施缺陷而不是测量 Agent 能力。[1]2、Trial一次运行不能代表一个随机系统生成式模型和 Agent 都具有随机性。同一个任务运行两次可能走完全不同的路径。因此“这个任务通过/失败”往往只是一次样本不是稳定事实。对关键任务至少要运行多个独立 trial并保留模型版本、温度、工具版本、环境快照、随机种子、时间预算和 token 预算等元数据。否则团队很难判断一个分数变化究竟是系统升级带来的真实提升还是抽样噪声。3、Grader评分器本身也是一个需要被验证的软件系统Agent 的 grader 大致可分为三类确定性评分器、模型评分器和人工评分器。确定性评分器便宜、快、可复现适合状态、测试、格式、安全策略和数值约束模型评分器适合开放文本、沟通质量、完整性和细粒度语义判断人工评分器成本最高但仍然是校准主观标准和处理高风险场景的重要参考。[1]真正成熟的 eval 不是“选择一种 grader”而是把不同 grader 放在合适的位置。4、Trace不是为了监控每一步而是为了定位失效机制很多团队初次做 Agent eval 时会本能地检查“工具 A 必须先于工具 B”“必须按照某个固定顺序操作”。这种做法很容易变得脆弱因为强模型往往能找到设计者没预料到但仍然正确的路径。更合理的 trace 评分应该关注是否调用了不允许的工具是否泄露敏感信息是否反复无意义尝试是否忽略关键用户信息是否违反费用或时间预算以及失败前发生了什么。路径约束只应在业务流程确实要求固定顺序时使用例如强制身份验证必须先于退款。5、Outcome最好能被独立验证如果一个任务可以通过数据库查询、单元测试、文件哈希、接口状态、页面 DOM、业务流水或日志来确认完成结果就不要只依赖模型自报成功。越接近真实环境状态ground truth 越强。二Evaluation harness测量系统也要有“测量学纪律”1、环境漂移会把假问题伪装成模型问题Agent eval 常常包含容器、浏览器、数据库、网络请求、外部依赖和并发任务因此环境比普通 NLP benchmark 更容易产生噪声。共享缓存、残留文件、API 限流、时间戳变化、依赖升级、CPU/内存争用都可能导致任务之间相关失败。一旦多个 trial 因同一个基础设施问题同时失败就不能把这些样本当作独立证据。成熟的 harness 应该把“Agent failure”和“environment failure”分开记录必要时自动重跑环境异常而不是直接计入模型失败。2. 推荐记录的最小运行元数据至少包括模型与版本、系统提示词版本、Agent harness 版本、工具 schema 版本、评测数据版本、环境镜像版本、开始与结束时间、随机参数、token/时间/费用预算、异常类型、最终状态摘要、grader 版本和原始 trace 地址。这些信息看似繁琐却决定了你的评测是否能被复现。三、从“能力”走向“可靠交付”为什么一次成功远远不够一passk 与 pass^k 讲的是两种完全不同的产品故事1、passk多给几次机会至少成功一次在代码生成等场景中如果系统可以一次生成多个候选然后通过测试选出可用答案那么“k 次尝试里至少有一次成功”非常有价值。Codex 相关工作系统化使用了 passk 思路反映重复采样可以显著提高“找到一个可行解”的概率。[6]在独立同分布的简化近似下如果单次成功率为 p那么至少一次成功的概率可写成passk ≈ 1 - (1 - p)^k它适合回答给系统多几次机会能不能找到一个正确解2、pass^k连续 k 次都成功面向客服、财务操作、企业流程等用户场景用户不会接受“同样的请求有时成功、有时失败”。τ-bench 因此引入pass^k来强调行为一致性。[3]在相同的独立近似下pass^k ≈ p^k它适合回答如果用户重复遇到同类任务系统能不能稳定地都做对假设某任务单次成功率为 75%三次尝试中“至少成功一次”的概率约为 98.4%看起来非常优秀但“连续三次全部成功”的概率只有约 42.2%。同一套 Agent在两个指标下会呈现出几乎相反的产品印象。以单次成功率 75% 为例随着尝试次数增加passk 快速接近 100%而 pass^k 持续下降。两者分别描述“找到一次成功”与“保持一致成功”。二长链路任务的真正敌人是可靠性乘法1、单步看起来很高的成功率串起来可能非常脆弱一个 Agent 完成复杂任务通常需要多个关键环节。如果把每个环节近似看成独立事件整条链路全部成功的概率约等于各环节成功率的乘积。例如20 个关键步骤每一步都有 97% 的成功率整条链全部成功的近似概率只有约 54%。即使每一步提高到 99%50 个关键步骤全部成功的概率也只有约 60%。现实中步骤之间并不独立但这个简单模型已经足以说明为什么“长任务”不是“短任务多做几次”那么简单。2. 需要把“恢复能力”也纳入评测优秀 Agent 不应该要求每一步永不出错而应该具备检测错误、回滚、重试、询问用户、重新规划和最终验证的能力。长链路 eval 应设计出可恢复的中间故障检查系统是否能回到正确状态而不是只测试一路顺风的“happy path”。METR 以人类完成任务所需时间来刻画 AI Agent 的“任务完成时间跨度”本质上也在研究任务长度与成功概率之间的关系其公开方法强调多次独立运行、任务难度和成功率曲线而不是只看一次是否通过。[10]三评测结果不应该只有一个总分四维评分比单一排行榜更接近生产决策对生产 Agent更建议把评测拆成四个独立维度Capability能力能否处理更难、更长、更开放的任务Reliability可靠性在重复运行、输入扰动和环境变化下是否稳定Safety/Policy安全与策略是否遵守权限、流程、合规与风险边界Efficiency效率成本、延迟、token、工具调用次数和人工介入率。这四个维度不应简单相加。安全和关键业务状态通常应采用“硬门槛”质量、成本和延迟更适合作为软优化目标。一个在质量总分上高一点、但偶发越权的版本不应该因为均值更高而被发布。四、评分器设计最重要的不是“智能”而是“可验证”一能用确定性检查就不要先上 LLM Judge1、硬事实交给代码文件是否存在、数据库状态是否改变、金额是否在阈值内、测试是否通过、是否调用了禁止工具、是否在规定轮数内结束这类问题应该优先使用代码评分器。原因不是 LLM Judge 不够强而是这些条件本来就可以被更便宜、更稳定、更可审计地验证。2、主观质量再交给模型评分器沟通是否清楚、报告是否全面、解释是否专业、是否覆盖关键事实、语气是否适合特定用户这类开放问题才是模型评分器的优势区间。但是LLM-as-a-Judge 并不是“自动真理机器”。MT-Bench/Chatbot Arena 的研究显示强模型作为评审可以与人类偏好达到较高一致性但也存在位置偏差、冗长偏差、自我偏好等系统性问题。[7] 因此模型评分器必须像任何检测器一样做校准拿一批人类专家已标注样本持续计算一致率、误报、漏报和边界案例。二一个大而全的 Judge通常不如多个窄 Judge1、把评价维度拆开如果让一个 LLM 同时判断事实正确性、完整性、语气、政策遵循、引用质量和效率它容易在不同维度之间互相补偿。更稳妥的方式是把维度拆开每个 Judge 只负责一个清晰 rubric然后再由程序做聚合。例如研究 Agent 可以拆成事实是否有来源支撑、是否覆盖指定主题、来源是否具备权威性、结论是否与证据一致、是否出现未经支持的推断。这样既方便定位问题也更容易与人工校准。2. 给 Judge “不知道”的出口评分器被迫在信息不足时给出明确结论会产生新的幻觉。对需要上下文才能判定的维度应允许返回Unknown / Insufficient evidence再由规则决定是否触发人工复核。一个好的 grader 不只是会打分还应该知道自己什么时候没有足够证据。三结果评分与过程评分要有不同权重1、核心业务状态通常是硬约束对于退款、下单、代码修复、配置修改、权限变更等任务最终状态应该拥有最高优先级。过程中的“表达很好”不能补偿结果没有完成。2、路径约束只用于真正必要的流程如果业务要求“必须先验证身份再退款”就应该检查顺序如果只是要求“找到正确文件并修复 bug”则不应该规定 Agent 必须先 grep 再打开文件。好的 eval 应允许创造性解法但不能允许违反不可协商的规则。五、评测数据集设计真正困难的是定义“什么叫成功”一最好的第一批测试通常来自真实失败1、不需要一开始就有几百条Anthropic 的实践建议非常务实早期从 20–50 个真实任务启动就足够有价值尤其是直接来自手工测试、bug tracker、客服反馈和用户失败案例的任务。[1]在系统还处于高速变化阶段时大改动往往带来大效应小而高质量的数据集比大而模糊的数据集更有用。2、把线上失败变成永不丢失的回归资产每一个严重线上问题都应该经历一条固定路径复现 - 去敏 - 归因 - 写成 eval task - 修复 - 加入回归套件。否则团队会不断“修同一种问题的不同实例”。二每道题都必须先证明“它真的可解”1、两名领域专家能否独立达成相同判断如果两个专家读完任务后都无法一致判断什么算通过那么这个任务还不够清楚。模糊任务会让评分噪声直接进入模型指标。2、Reference solution 是评测基础设施的单元测试每个确定性任务最好保留一个已知可通过的参考解用它验证题目、环境和 grader 的组合确实能工作。一个看似“模型 0% 通过”的难题可能只是任务定义、环境、脚手架或评分器出了问题。[1]三平衡“应该做”和“不应该做”的案例单侧数据集会制造过度行为如果只测试“什么时候应该搜索”系统可能学会对任何问题都搜索如果只测试“什么时候应该拒绝”系统可能越来越保守如果只测试“应该升级人工的情形”系统可能开始过度升级。因此每个关键行为都应设计正例、反例和边界例。真实产品通常不是在“会不会做”上失败而是在“该做时没做、不该做时乱做”的阈值问题上失败。四能力集与回归集必须分开维护1、Capability eval 要故意难能力集的目的不是证明系统已经很好而是持续暴露“还不会的东西”。它应该保留相当比例的失败让团队有清晰的爬坡空间。2、Regression eval 要接近全通过回归集则用于守住已经获得的能力。它的理想状态是长期接近 100%一旦下降就意味着新版本可能破坏了既有行为。当能力集逐渐被攻克时其中成熟任务可以“毕业”为回归用例。这样评测体系本身会随产品进化而不是一年不变的静态 benchmark。[1]六、从“一套 benchmark”升级成“评测资产组合”一生产级 Agent 至少需要四类 suite1、能力前沿集告诉你下一座山在哪里放入长任务、难任务、新工具、新领域、复杂决策和仍有明显失败率的案例。它主要服务模型选择、提示词研发、工具设计和新能力探索。2、回归保护集告诉你有没有把旧东西弄坏放入已经稳定解决、但业务价值高的关键任务。它适合每次代码、提示词、模型、工具 schema 和路由规则变更时运行。3、生产回放集告诉你离真实用户还有多远从匿名化真实流量中按场景、风险和失败类型抽样定期离线重放。它比人工编写案例更能反映用户分布和语言多样性也能发现离线 benchmark 没覆盖的漂移。4、对抗与策略集告诉你系统会不会“聪明地做错事”Agent 越强越可能找到评测设计者没有预料的路径。对权限、合规、费用、隐私、数据写入、危险工具和业务规则需要专门设计诱导绕过、模糊指令、冲突目标和 loophole 场景。二为什么“一个总榜”容易误导团队1、不同 suite 的目标函数本来就不同能力前沿希望分数不要太高否则没有改进空间回归保护希望接近全通过生产回放追求代表性对抗集追求高风险缺陷的发现率。把四者压成一个总分会让团队不知道“到底是哪里变好了”。2、发布决策应该基于门禁与权衡而不是单一均值更实用的发布标准是关键硬约束不得退步高价值回归必须全部通过能力集有显著提升且置信区间可接受生产回放中的严重错误率不升高成本和延迟在预算内。这样一个版本是否可发布是一组条件而不是一个漂亮分数。七、EvalOps把评测从研究脚本变成产品基础设施EvalOps 的核心是把生产失败持续转化为测试资产并让测试结果反过来约束模型、提示词、工具和产品发布。一评测必须进入版本控制和 CI/CD1、Eval 应与 prompt、tool schema、agent code 一起变更当开发者修改系统提示词、工具描述、重试策略、路由模型、上下文管理或安全规则时应该能在同一个变更中看到对应 eval 结果。否则评测只是“发布前偶尔跑一次”的仪式而不是工程反馈机制。2、每次变更都要保留可比较的实验记录至少记录基线版本、候选版本、每个 suite 的分数、trial 数、统计区间、严重失败样例、成本、延迟和 token 变化。对于大模型系统纯平均分尤其危险因为少量高风险失败可能被大量普通成功稀释。二失败分析是 eval 中最不能自动化掉的一环1、定期阅读 trace 是团队理解系统的高带宽渠道Anthropic 特别强调阅读 transcript因为只有看完整轨迹才能判断失败是否公平、grader 是否拒绝了合理方案、Agent 是否受 harness 限制、还是环境本身异常。[1]这项工作不能完全被“再加一个 LLM Judge”取代。模型可以帮助聚类和初步归因但负责 eval 的工程师与产品专家仍然需要周期性抽查真实轨迹建立对系统行为的直觉。2、建立固定的失败分类法建议至少区分任务定义问题、环境问题、工具问题、规划问题、知识/检索问题、执行问题、沟通问题、政策问题、grader 问题、资源预算问题。长期统计各类占比比只追踪总成功率更能指导研发投入。三防止评测饱和和“考试教学化”1、100% 通过的能力集已经失去研究信号一套 eval 一旦长期接近满分它就更适合做回归而不再适合衡量前沿能力。此时应该增加更长、更开放、更组合化、更接近真实工作的任务而不是继续在已饱和数据上追逐小数点变化。[1]2、不能只优化榜单必须持续验证分布外行为如果团队每天只看固定测试集提示词和策略会逐渐针对那批题优化形成新的“过拟合”。生产回放、动态生成边界案例、专家红队和新任务扩充都是保持 eval 有效性的必要机制。八、Agent 评测正在进入第二阶段长任务、动态世界与人机协同一长任务不只是更多 token而是更多隐藏状态OSWorld 2.0 体现了新的难点早期电脑使用 benchmark 已经证明仅凭截图和 GUI 操作完成跨应用任务非常困难。到 2026 年的 OSWorld 2.0任务进一步转向长链路真实工作流强调动态环境、跨来源推理、隐含状态恢复、视觉空间精度和持续验证等现象。[9]这说明未来 Agent eval 的重点会从“能不能点击对按钮”转向“能不能在一小时级工作流里持续记住约束、发现状态变化、主动确认并验证结果”。二用户不再只是出题者而会成为环境的一部分τ²-bench 的双控制视角非常重要真实客服、IT 支持和协作式 Agent 往往无法独自完成所有动作。Agent 需要指导用户重启设备、修改设置、提供验证码或完成某个现实世界操作。τ²-bench 因此把用户也建模为可以操作共享环境的一方测试 Agent 的推理、沟通和协同能力。[4]这类任务提醒我们未来的 Agent 成功标准不仅是“自己会做”还包括“能否让另一个人正确地做”。三时间跨度会成为重要的能力坐标“能完成多长的人类任务”比单题正确率更有解释力METR 提出的 task-completion time horizon把任务按人类专家完成所需时间映射到 Agent 成功概率为“长任务能力”提供了一个直观坐标。[10] 这种方法并不能替代领域 eval但它带来一个有价值的思路当 Agent 的目标从十分钟任务扩展到数小时、数天甚至更长流程时单纯统计“通过多少道题”可能不再足够。四多 Agent 系统会让评测更像分布式系统测试新问题是协调、通信和共享记忆当一个 orchestrator 调度多个 worker错误可能来自任务拆分、职责冲突、重复工作、信息丢失、上下文不同步和结果合并。此时评测需要同时观察单体能力和系统级组织效率。未来成熟的多 Agent eval 很可能要引入类似分布式系统测试的概念故障注入、部分失效、消息延迟、重复消息、共享状态冲突和恢复策略。它测量的将不是“几个模型加起来有多聪明”而是“一个协作系统在不完美条件下是否仍能完成目标”。九、一个更实用的工程框架把 Eval 当成“可执行产品契约”一产品需求必须能被翻译成机器可检查的承诺1、每个关键能力都应对应至少一个可执行测试例如“能够安全处理退款”不是可执行需求更可执行的表达是身份验证通过后100 美元以内退款可自动处理超过阈值必须升级退款成功后数据库状态、工单状态和确认消息同时更新禁止绕过身份验证。Eval 的价值就在于迫使团队把“感觉应该这样”变成“可以验证的行为契约”。2、每个关键风险也应对应一个反例测试如果产品担心过度搜索、过度升级、过度拒绝、越权写入、误删文件或无依据行动就应该把这些风险转成 explicit negative tests而不是等线上事故证明它们存在。二可以引入一个“评测债务”概念评测债务会随着系统变化速度复利当 Agent 快速迭代但 eval 没有同步增长时团队对“哪些行为仍然有效”越来越没有把握。每次升级模型或提示词都需要更大规模的手工验证研发速度反而下降。可以用一个非严格但实用的启发式来理解评测债务未覆盖的关键行为越多、系统变化越频繁、单次失败成本越高评测债务越大。它与技术债务类似早期看起来省下了测试时间后期却用更高的回归风险和人工验证成本偿还。三最终目标不是追求最高分而是缩短“安全改进循环”好 eval 的本质是提高研发反馈带宽一个团队如果能在几小时内知道新模型在哪些场景提升、哪些场景退步、为什么退步就比只能靠用户投诉发现问题的团队拥有更快的学习速度。因此评测体系的终极 KPI 不应只是“benchmark 分数”还应包括发现回归需要多久、定位失败需要多久、新问题变成回归测试需要多久、新模型完成验收需要多久以及严重线上问题有多少能被离线提前捕获。自动 eval、生产监控、用户反馈、人工 trace 审查和系统性人工研究各自覆盖不同盲区。可信度来自多层证据而不是单一分数。十、落地路线从零开始建立可用的 Agent Eval一第 1 周定义成功而不是先选工具1、建立 20–50 个高价值任务从现有手工测试、线上失败、客服工单、典型用户路径和高风险流程中选取第一批案例。为每个 task 写清初始状态、目标、约束和成功标准。2、给任务分层标记哪些属于能力前沿、哪些必须进入回归、哪些是高风险政策场景。不要一开始就追求覆盖所有情况先确保每个测试都高信号。二第 2 周先做 outcome verifier再做复杂 Judge1、建立稳定环境容器化或快照化测试环境确保每次 trial 从干净状态开始。对数据库、文件、API 和 GUI 状态写确定性验证器。2、保存完整 trace 与元数据保证任何失败都可以被回放和定位。此时甚至可以暂时用人工查看开放式质量问题避免过早把复杂度放在 LLM Judge 上。三第 3 周加入模型评分器并完成人工校准1、只把主观问题交给 LLM Judge为每个维度写窄 rubric准备 50–100 条人工标注样本对 Judge 做一致性检查。对争议样本保留人工复核机制。2、同时测能力与可靠性对关键任务运行多 trial至少同时报告单次成功率和一致性指标避免“平均看起来不错、重复使用却不稳定”。四第 4 周接入 CI/CD建立长期维护制度1、每次关键变更自动跑回归模型升级、提示词修改、工具 schema 变化和 Agent harness 变化都触发相应 suite。高成本能力集可以定时运行关键回归集则尽量高频。2、每周固定审查失败轨迹由工程、产品和领域专家共同选取失败样本判断是 Agent 问题、grader 问题还是任务问题。新发现的高价值案例直接进入数据集。3、每月检查评测健康度关注任务是否过时、是否饱和、是否存在重复、真实流量是否发生漂移、Judge 是否与人工标准偏离、基础设施是否增加了噪声。十一、结语真正成熟的 Agent 团队先建设“可验证性”Agent 的价值来自自主性而自主性也让它更难被测量。越是强大的 Agent越可能使用设计者没有预料的路径越是长链路任务越容易出现错误传播越是开放式输出越难靠单一 ground truth 判断。正因为如此Agent 评测不能只是一个发布前 benchmark而应该成为产品架构的一部分。一套成熟的 Agent eval 应该做到四件事第一把最终状态和业务目标绑定让“看起来成功”无法冒充真正成功第二把随机系统当作随机系统用多 trial 和可靠性指标而不是单次分数做判断第三把确定性评分、模型评分与人工判断放到各自最擅长的位置第四把每一次真实失败持续沉淀为可复用的测试资产。如果把 Agent 看成未来的软件执行主体那么 eval 就是它的可执行产品契约。它不仅回答“这个模型有多聪明”更重要的是回答这个系统在我的业务、我的工具、我的约束和我的风险边界里能不能持续、稳定、可解释地把事情做成。可参考文章与论文Anthropic — Demystifying evals for AI agents (2026)本文的主要启发来源系统讨论 Agent eval 的组成、grader 类型、能力/回归评测、多 trial、评测维护与生产闭环。Anthropic — Building Effective AI Agents (2024)讨论 Agent、workflow、工具接口与 harness 设计为理解“评测对象是模型与脚手架的组合”提供工程背景。Yao et al. — τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains提出面向工具调用与用户交互的 benchmark并使用pass^k强调 Agent 行为一致性。Barres et al. — τ²-bench: Evaluating Conversational Agents in a Dual-Control Environment将用户也建模为共享环境中的行动者扩展了协作式 Agent 的评测边界。Jimenez et al. — SWE-bench: Can Language Models Resolve Real-World GitHub Issues?通过真实 GitHub issue、可执行代码环境和测试套件评估软件工程 Agent。Chen et al. — Evaluating Large Language Models Trained on Code经典代码生成评测工作系统使用 passk 衡量多次采样找到可行解的能力。Zheng et al. — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena讨论 LLM-as-a-Judge 与人类偏好的相关性同时分析位置、冗长度与自我偏好等评审偏差。Xie et al. — OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments在真实计算机环境中评估开放式 GUI Agent强调可执行环境和结果验证。Yuan et al. — OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks将电脑使用评测推进到更长、更真实的工作流并强调动态环境、隐含状态和持续约束跟踪。METR — Task-Completion Time Horizons of Frontier AI Models以人类专家任务时长与 Agent 成功概率之间的关系描述长任务能力并公开多次运行与统计建模方法。