AI Agent 评测：用任务集、轨迹和回归测试替代感觉

Agent 能调用工具、读写系统并执行多步任务后，仅比较最终文本已经不够。它可能答案看似正确，却调用了错误用户的数据、重复创建资源或绕过确认。可靠评测要同时检查最终结果、执行轨迹、安全边界和成本。

从真实任务建立评测集

任务不要只写“创建文章”，而应包含初始状态、用户输入、允许工具、期望状态和禁止行为：

name: create_article_draft
initial_state:
  logged_in: true
input: "帮我起草一篇 Go PGO 文章，但先不要发布"
expected:
  editor_open: true
  title_not_empty: true
  persisted: false
forbidden:
  - submit_review
  - publish_article

从线上失败、客服反馈和人工对话中持续补充任务。简单 Happy Path 只能证明 Demo 可用。

分层评测

结果层

检查数据库、页面状态或生成文件是否达到目标。能用确定性断言就不要只让另一个模型打分。

轨迹层

记录每次模型输入、工具名、参数、返回、确认和重试。检查是否选择了最小权限工具、是否重复调用、是否在写操作前获取必要上下文。

安全层

加入提示注入、越权请求、伪造身份、恶意附件和网页隐藏指令。公共网页内容只能作为数据，不能覆盖系统规则；工具参数还要由服务端做权限和 Schema 校验。

体验层

评估首次响应时间、流式中断、错误说明、确认步骤和用户取消后是否真正停止执行。Agent 最终成功但等待一分钟、期间没有反馈，仍是糟糕体验。

工具测试先脱离模型

每个工具都有普通单元与集成测试：输入校验、权限、幂等、超时、重试和审计。模型只是工具调用方，不能替工具承担正确性。评测 Agent 时使用可重放的 Mock 返回，保证失败能够稳定复现。

不要只用单一总分

建议分别记录：

  • Task Success Rate。
  • 非必要工具调用次数。
  • P50/P95 完成时间。
  • 输入输出 Token 与外部调用成本。
  • 需要人工纠正的比例。
  • 越权、重复写和未确认写操作数量。

关键安全失败应是硬门槛，不能被“平均分较高”抵消。

回归与发布

Prompt、模型、工具 Schema、检索索引和业务接口任一变化都可能影响行为。CI 跑快速确定性集合；每日或发布前跑完整集合；线上先灰度并保留旧版本回退。失败轨迹脱敏后进入回归集。

模型输出存在随机性，重要任务可重复运行多次并看成功率分布。评测环境固定模型版本、温度、工具返回和初始数据，才有可比较结果。

参考资料