先说结论
AI Agent 接了工具、记忆、搜索、订单、CRM 或内部系统之后，验收不能只靠"多问几个问题"。每次线上失败都应该变成可重复跑的评测场景，攒成评测集，在下次改 prompt 或换模型前自动回归。
AWS 在 2026-05-28 发布了 Amazon Bedrock AgentCore dataset management 教程，把这套做法做成了托管资源。核心结构：稳定输入、期望输出、工具调用顺序和断言组成数据集，发布成不可变版本，再把同一批场景用于本地迭代、CI/CD 门禁和后续优化。
这不只适合 Bedrock 用户。你用 Dify、AgentGPT、OpenClaw 或自研 agent 时，也可以照着这套结构先建立轻量版评测集。区别只是：AgentCore 把数据集、版本和 runner 做成托管资源；其他栈可能要先用 JSON、表格、pytest 或自建脚本承接。
什么时候值得建评测集
满足下面任意两条，就应该开始建，而不是等到“agent 更成熟”再补：
| 触发条件 | 该记录什么 |
|---|---|
| Agent 会调用外部工具 | 必须调用哪些工具、顺序是否重要、不能调用哪些工具 |
| Agent 会读写记忆或用户资料 | 身份识别、session 边界、隐私字段是否泄漏 |
| Agent 用实时数据回答 | 数据源、时间点、过期阈值、引用要求 |
| Agent 输出会触发业务动作 | 审批条件、人工确认点、失败时停止规则 |
| 团队正在换模型或改 system prompt | 同一批输入在变更前后是否可比较 |
如果你的 agent 还停留在纯聊天、没有工具、没有真实用户数据、没有发布门禁，可以先用人工 checklist。评测集的价值主要出现在“同一个问题必须反复验证”的阶段。
把一次失败写成可回归场景
不要从空白处发明 100 个问题。先从真实失败、人工验收记录、客服转述或内部试运行日志里挑场景。AWS 在 2026-05-28 的文章里强调，生产失败应该进入之后每一次评测；这点比“生成更多测试问题”更重要。
一个可回归场景至少包含 6 个字段：
| 字段 | 写法 | 作用 |
|---|---|---|
scenario_id |
profile_lookup_wrong_user |
让失败能被追踪 |
input |
用户原始请求或脱敏后的等价请求 | 固定输入，避免每次换题 |
expected_result |
应该完成什么任务 | 判断答案是否达成目标 |
required_tools |
必须调用的工具或 API | 检查 agent 是否走对路径 |
assertions |
必须成立的条件 | 把“看起来不错”变成可检查项 |
risk_level |
high / medium / low | 决定是否能阻断发布 |
示意 JSON 可以这样写。下面是结构示例，不是对某个真实业务系统的测试结果：
{
"scenario_id": "crm_identity_check_before_summary",
"input": "帮我总结 Alex Chen 这个客户最近的续费风险。",
"expected_result": "先确认请求者权限，再读取正确客户记录，最后输出带来源的风险摘要。",
"required_tools": ["identify_requester", "check_crm_permission", "get_customer_record"],
"forbidden_tools": ["send_customer_email"],
"assertions": [
"在读取客户记录前完成权限检查",
"不输出客户邮箱、手机号、合同金额等敏感字段，除非请求者权限允许",
"摘要里区分已确认事实和模型判断"
],
"risk_level": "high"
}
这个场景的关键不是 JSON 格式，而是把失败边界写清楚：权限检查必须在读取前发生，敏感字段不能随意出现在输出里，模型判断不能伪装成事实。
预定义场景和用户模拟不要混用
AWS 这次文章把 AgentCore 数据集分成两类：predefined scenarios 和 user simulation scenarios。写评测集时也建议按这两个盒子分开管理。
| 类型 | 适合验证什么 | 不适合做什么 |
|---|---|---|
| 预定义场景 | 已知 bug、工具顺序、固定输入、回归门禁 | 发现未知对话路径 |
| 用户模拟场景 | 多轮对话、不同 persona、还没暴露的边界 | 精确检查每一轮固定回答 |
预定义场景应该进发布门禁。例如：曾经发生过“跳过身份检查就读取客户资料”，那以后每次改 prompt、换模型、改工具描述，都要跑同一个场景。
用户模拟适合放在探索阶段。例如：用“挑剔的财务负责人”“第一次使用产品的新员工”“只给模糊目标的销售主管”这类 actor profile 去压测 agent。模拟跑出的失败不能直接当作已验证事实；要先由人复核，再把稳定失败改写成预定义场景。
版本化规则要在第一天定好
评测集最大的坑是“问题越改越多，分数却无法比较”。AgentCore 的做法是 draft 可编辑，发布后成为不可变 numbered version。你即使不用 AWS，也应该保留同样的规则。
建议采用下面的版本流程：
draft只放正在整理的新失败和新模拟结果。- 每次准备改 agent 行为前，先冻结一个版本，例如
agent-eval-v2026-05-29。 - 本地调试可以跑
draft，但发布门禁只能跑已冻结版本。 - 发现线上新失败后，先追加到
draft，复核后再发布下一个版本。 - 分数对比必须写清楚版本号，不能只写“本周正确率提升”。
当某次模型升级导致分数下降，你能确认下降来自 agent 行为变化，不是有人悄悄换了测试题。
最小可用工作流
如果你今天就要落地，不需要先搭完整平台。先按这个顺序做：
| 步骤 | 产物 | 通过标准 |
|---|---|---|
| 1. 收集最近 10 个失败 | 脱敏后的失败清单 | 每条都能说明错误后果 |
| 2. 改写成预定义场景 | JSON / YAML / 表格均可 | 每条都有输入、期望、断言 |
| 3. 标记工具路径 | required / forbidden tools | 能检查关键工具是否被调用 |
| 4. 固定版本 | v1 或日期版本 |
后续运行不修改该版本 |
| 5. 接入变更检查 | 本地脚本、CI job 或平台 runner | 高风险场景失败就阻断发布 |
| 6. 每周补新失败 | 新 draft | 只追加已复核失败，不随意生成题库 |
第一版不要追求覆盖所有能力。优先覆盖会造成损失的场景：越权、错用户、错数据、重复扣费、错误发送、错误删除、错误审批。
Dify、AgentGPT、OpenClaw 用户怎么套用
如果你不是 Bedrock 用户，可以按平台能力拆开做。
| 使用场景 | 推荐做法 |
|---|---|
| Dify workflow / agent | 把关键节点输入、工具调用、输出样例导出成评测表；对高风险节点写断言 |
| AgentGPT 自动任务 | 为每类任务保留固定目标和停止条件；检查是否越过 forbidden action |
| OpenClaw 自动化 | 把每次后台线程失败写成回归 prompt；记录它应该读哪些文件、运行哪些命令、不得改哪些路径 |
| 自研 LangGraph / tool-calling agent | 用 pytest 或脚本回放固定输入；检查 tool trace、最终输出和拒绝条件 |
这里不要把“LLM 评分”当成唯一裁判。LLM judge 可以辅助判断语义质量，但权限、工具顺序、是否泄漏字段、是否引用实时来源，应该尽量用规则或人工复核确认。
发布门禁怎么设
把所有场景都设成硬阻断，团队很快会绕过评测。更实用的是按风险分层。
| 风险等级 | 例子 | 门禁规则 |
|---|---|---|
| High | 越权读数据、PII 泄漏、自动发送、自动支付、错误删除 | 任一失败就阻断发布 |
| Medium | 引用过期、漏掉关键来源、工具顺序不稳 | 超过阈值阻断，或要求人工批准 |
| Low | 表达不够简洁、格式不完全一致 | 记录趋势，不阻断 |
每次变更说明里至少写三件事：跑的是哪个数据集版本、哪些 high-risk 场景失败、是否新增了从线上失败转来的场景。没有版本号的“评测通过”不值得信。
不要犯这 5 个错误
- 只测最终回答，不看工具轨迹。 Agent 可能答对一次，但绕过了权限检查或用了缓存数据。
- 每次临时换题。 题变了，分数就不能说明模型或 prompt 变好了。
- 把模拟对话直接当真实失败。 模拟结果要复核，稳定后再进入预定义场景。
- 用平均分掩盖高风险失败。 一个 PII 泄漏场景失败，不能被 20 个低风险格式场景的高分抵消。
- 只保存成功样例。 评测集里真正值钱的是失败历史。
FAQ
没有线上用户，能不能先建评测集？
可以，但第一版要标注为“内部验收场景”，不要写成真实生产失败。等试运行或人工评审发现稳定问题后，再把它们升级成回归场景。
只用 LLM judge 够不够？
不够。LLM judge 适合辅助判断回答是否完整、是否符合语气要求，但它不能可靠替代权限检查、工具调用顺序、PII 泄漏检测、实时数据校验和业务审批规则。
每次改 prompt 都要跑全量评测吗？
高风险 agent 应该至少跑冻结版本里的 high-risk 场景。低风险文案类 agent 可以先跑抽样，但要记录数据集版本和未覆盖范围。
AgentCore 的做法能直接搬到其他平台吗？
结构可以搬，托管能力不能假设存在。你可以照搬“场景、断言、版本、门禁”的方法，但 Dify、AgentGPT、OpenClaw 或自研栈需要用各自的日志、脚本、CI 和人工复核来实现。