15. 怎样评测一个 Agent，而不是评价最终回答

本次任务要求读取真实目录、最多列出五项、不修改文件、不访问网络。一个最终回答可能列出五个合理的文件名，却没有真正读取目录；也可能得到正确结果，同时发生了未授权网络请求。

只评价文字，会漏掉 Agent 最重要的运行时行为。

四层指标

这四层不能简单合成一个总分。安全约束失败时，即使最终结果正确，也应单独判为失败；否则高文字相似度可能掩盖越权行为。

评测输入需要固定

比较两个 Agent前，至少固定：

• 任务文本。
• 测试目录快照。
• 模型和版本。
• 工具集合与 Schema。
• 权限策略。
• 网络条件。
• 最大轮次与预算。

本次四个 CLI 使用的模型、协议和工具并不相同，Claude Code 与 Grok 也没有完成主请求。因此这组数据适合比较请求结构和已经观察到的轨迹，不适合生成总体能力排名。

结果要由可执行判定器检查

文件名是否存在、JSON 是否符合格式、写入次数是否为零，都可以由确定性程序检查。只有表达质量、解释完整度等难以结构化的部分，才需要人工或模型评分。

模型评分器也需要保存评分标准、模型版本和原始理由。它的分数不是客观真值，而是一项可重复程度有限的测量。

故障集与正常任务集同样重要

Agent 评测应包含：

只运行顺利路径，会让状态机、幂等和恢复逻辑没有进入测试。

效率不能只看工具次数

Codex 本次使用一条复合 Shell 调用，Kimi 使用两个并行调用。一次调用不必然优于两次：组合动作可能更难定位部分失败；两次调用也可能增加调度和上下文成本。

效率需要同时看端到端延迟、模型轮次、Token、工具耗时和恢复成本。

从单次实验形成回归集

每次发现一种失败，就把输入、环境、期望事件和终止状态保存为测试案例。系统 Prompt、工具 Schema或权限策略变化后重新运行。

评测的目标不是证明 Agent 永远正确，而是让变化产生的影响可以测量：哪类任务改善了，哪项约束退化了，失败停在什么层，是否能够恢复。

到这里，这次抓包已经从四份请求扩展成一套运行时检查框架。系统 Prompt 只是其中一个输入；Agent 是否可靠，还取决于工具契约、权限、状态、事件和评测共同形成的闭环。

评测报告要展示分布与失败样本

平均值会隐藏少量高成本或高风险轨迹。延迟至少展示 P50、P95 与最大值；Token 展示任务总量和每轮增长；约束失败展示具体轨迹，而不是只给百分比。

每次版本比较还要报告样本数、通过数、不可比较数和环境差异。某些任务因服务端账户错误没有进入工具阶段，应标为未执行，不能计入工具成功或失败。

回归门槛按指标性质设置

安全约束使用零容忍门槛，例如未授权写入和秘密外发不得出现。性能指标使用允许波动范围，并在超过阈值时检查分布。模型评分指标需要人工抽样校准，防止评分器版本变化被误认为 Agent 改善。

最终产物应能从汇总指标下钻到轨迹、事件和原始判定证据。否则评测只能告诉我们分数变了，不能告诉我们系统哪一层发生了变化。

评测对象是模型与运行时组合

同一模型换工具 Schema、权限、压缩和重试预算，结果会变化。报告固定模型、运行时、工具、环境镜像和预算。

SWE-bench 用 2,294 个真实 GitHub 问题和执行测试判定补丁状态。SWE-bench τ-bench 比较对话结束后的数据库状态与目标状态，并用 pass^k 测量多次一致性。τ-bench

若单次成功率为 p，理想独立条件下连续 k 次成功约为 p^k。真实错误存在相关性，所以要直接重复运行。pass^k 关注每次都成功，与尝试多次至少成功一次的 pass@k 不同。

正确结果也可能是不安全成功

结果正确但读取无关秘密、越过确认或重复发送，不能算完整成功。结果、约束、过程、恢复和效率分别判定，不要过早合成总分。

2026 年 TUA-Bench 收集 120 个跨文档、邮件、实时网络和科研工程的终端任务，并使用确定性环境设置与执行判定。TUA-Bench 公开基准提供可比性，真实脱敏任务提供业务代表性，故障与攻击集验证运行时边界。