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

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

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

四层指标

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

评测输入需要固定

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

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

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

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

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

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

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

Agent 评测应包含：

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

效率不能只看工具次数

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

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

从单次实验形成回归集

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

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

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