一次答案评测不够用了

模型评测常常关心一次回答是否正确。Agent 评测不能只停在那里。Agent 会计划、调用工具、读取上下文、修改环境、等待反馈，再产出结果。

如果只看最后答案，就看不见中间是否越权、是否浪费成本、是否走了不可复现路径，也看不见失败后能不能恢复。

真实任务链条至少有六个维度

一个像样的 Agent benchmark，至少要记录目标理解、工具选择、步骤执行、状态恢复、人工交互和最终结果。再往生产靠，还要记录成本、时延、安全事件和审计证据。

这些维度会让评测更麻烦，但也更接近真实使用。只测结果，会奖励那些偶尔撞对答案、过程不可控的系统。

事件结构决定能不能复盘

OpenTelemetry GenAI 语义约定的重要性，在于它试图让模型调用和相关事件有共同语言。评测如果没有事件结构，就很难比较不同 Agent 的执行过程。

所以评测平台应该从一开始保存 trace，而不是只保存最终文本。trace 里要有模型、工具、输入摘要、输出、错误、重试和人工介入。

评测最后要服务放行决策

评测不是为了做榜单好看，而是为了决定能不能放进生产。对企业来说，真正的问题是某类任务能不能交给 Agent，交给它需要多少人类监督，失败边界在哪里。

因此 Agent 评测的最终输出不应只是分数，而应该是任务适用范围、风险等级、必要 guardrail 和上线条件。

三类任务不要混在同一个分数里

Agent 评测还需要先分任务类型。信息整理、代码修改、浏览器操作、表格分析和跨系统业务执行，失败代价完全不同。如果把它们压成一个总分，最后得到的只是营销口径，而不是上线依据。

更合理的做法，是每类任务单独写评测表。信息整理重点看引用和事实一致性；代码修改重点看测试、回归和可维护性；浏览器操作重点看状态恢复和页面变化；业务执行重点看权限、审批和可回滚性。不同任务可以共享 trace 格式，但不能共享同一套权重。

评测结果要能变成上线门槛

一套评测如果不能转成上线门槛，就很难服务生产。团队至少要能从评测里得到三类结论：哪些任务可以自动执行，哪些任务必须人工批准，哪些任务当前禁止交给 Agent。

这也是 Agent 评测和普通 benchmark 最大的差异。普通榜单可以只追求排名，生产评测必须给出放行条件。比如成功率达到多少、平均成本低于多少、失败后能否恢复、关键动作是否都有审计记录。没有这些阈值，评测就很难帮团队做决策。