取证 Agent 的一次正确回答，可能来自完整的分析，也可能只是碰巧选中了正确值。评测需要同时检查任务选择、执行过程和最终结论，并保留能够解释成败的运行记录。本文给出一套适用于小规模开发的评测方法；其中的测试矩阵、字段和计分方式均为教学设计，不代表已有系统的实测效果。
评测对象与判定依据
选择层检查 Agent 是否识别了任务范围，以及是否加载了适合该任务的 Skill。某个 Skill 在描述中包含“数据库”，不意味着所有带有“数据库”字样的问题都应触发它。查询已有取证材料中的应用记录，与设计一个业务数据库，虽然共享术语，所需方法和工具并不相同。选择层需要同时安排应当触发和不应当触发的请求。
过程层检查实际操作。以统计账号当前关注数为例，答案为 2 仍不足以判定通过：Agent 可能没有限定账号，恰好在另一张表中也查到了 2。评测应核对查询对象、筛选条件、统计对象、工具返回状态和结果覆盖范围。判据只约束会影响结论的操作，不要求所有正确实现使用相同的 SQL 排版、工具调用顺序或解释句式。
结果层检查答案是否回答了题目，并有足够证据支持。工具成功返回不代表业务问题已经解决；文件存在也不能单独证明某个用户访问过它。对材料不足的案例，正确结果可以是指出缺少的记录及其影响，而不是给出一个数值。预期结果需要提前写明这种处理是否属于通过，避免评分时临时改变要求。
每条必需判据采用通过、未通过、待人工复核三种记录值，并附上判定依据。字段类型、行数和计算值可以自动检查；对象关联是否充分、解释是否超出证据范围，往往需要审查原始记录。由模型辅助评分时，也应要求它指出对应输出和证据位置。评分模型写出一段肯定评价，不能替代实际核对。
测试集与运行条件
开发集用于发现问题和修改 Skill；留出集用于观察修改后的方法能否处理未参与调试的案例。两者需要按材料及分析任务分开。同一数据库的副本即使换了文件名，仍可能泄漏答案、字段含义和解题路径。若开发过程中已经查看留出集答案并据此改写步骤，该案例应转入开发集，另行补充未使用的材料。
一个测试案例至少要保存请求原文、输入材料标识、前置状态、预期行为和判据。材料可以使用自编数据，但必须说明字段含义；故障注入应当可重复，例如固定让某次查询返回权限错误，或在指定步骤中断任务。没有可核对的预期结果时，先完成样例的人工分析，不能直接把另一次模型回答当作标准答案。
每轮评测建立一份运行配置记录。下表中的内容用于判断
