生产 Agent 别只跑 demo：先补 6 类评测样本

假设一个设备数据 Agent 已经能回答“这周发电量是多少”，现在准备交给运营同事试用。交出去之前，还要检查少一座电站的数据、权限外字段、接口超时等情况。把输入、预期处理和核对依据写下来，业务和技术才能一起判断试用范围。

这里最常见的问题，不是模型完全不会做，而是评测样本还是停留在演示样本。

很多系统在内部验收时，跑的都是这些内容：

• 几条已经调顺的 happy path；
• 少量静态文档问答；
• 一两个成功的工具调用案例；
• 能在会议里稳定展示的脚本化任务。

这些样本能证明“它跑过”，但证明不了“它进生产后还能稳”。

对生产级 AI Agent 系统来说，评测不是做一组漂亮分数，而是提前回答两个问题：

1. 哪些任务它现在真的能稳定做；
2. 哪些失败模式已经被样本覆盖，不会一上线才第一次遇到。

下面这 6 类评测样本，是 Agent 要进真实流程前至少该补齐的。

1. 标准成功样本：先把基础能力测稳

第一类当然还是标准成功样本，但它的作用不是做宣传，而是建立基线。

这类样本至少应该覆盖：

• 常见用户请求；
• 典型知识检索；
• 标准工具调用；
• 正常返回后的输出结构；
• 单轮和多轮两种常见交互。

如果这层都不稳，后面谈边界、审计和自动化比例都没有意义。

但问题在于，很多团队把这类样本跑通以后，就误以为“评测已经够了”。

2. 歧义样本：需求不清时系统会不会乱猜

真实业务里，用户输入经常并不完整。

比如：

• “帮我查一下这个客户现在什么情况”；
• “把这个问题处理一下”；
• “按之前那个方案继续推进”；
• “给我看看最近设备有没有异常”。

这些请求对人来说都需要追问或补上下文，对 Agent 也一样。

评测里如果没有歧义样本，团队很容易只看到“模型会做题”，看不到“它在信息不足时会不会强行给结论”。

这类样本要测的重点不是回答得多快，而是：

• 会不会先澄清；
• 会不会暴露自己缺少上下文；
• 会不会误选工具；
• 会不会把模糊请求直接推进成真实动作。

3. 证据冲突样本：检索到了，但依据互相打架

很多生产事故不是因为完全查不到，而是因为查到了两份互相冲突的依据。

常见场景包括：

• 新旧制度文档不一致；
• CRM 状态和工单状态不一致；
• 设备实时状态和缓存快照不一致；
• 两个数据源对同一客户给出不同标签。

如果评测只测“命中一条正确答案”，系统上线后就很容易在证据冲突时继续硬答。

这类样本应该强制检查：

• 是否能暴露冲突来源；
• 是否会暂停执行；
• 是否能要求人工确认；
• citations 能不能回指到具体证据片段。

4. 权限与边界样本：不该看到、不该做的会不会被拦下

很多 Agent demo 看起来很顺，是因为测试账号权限太大，或者样本根本没碰真正的边界。

但生产里最值得测的，往往恰恰是这些“不该发生”的场景：

• 当前角色是否看到了不该看的字段；
• 当前任务是否调用了超出范围的工具；
• 当前环境是否把只读动作误走成写动作；
• 高风险对象是否绕过了审批或转人工规则。

如果没有这类负向样本，所谓“权限控制”就很容易只停留在配置表里，没经过真实回归。

5. 失败与超时样本：下游不稳定时系统怎么停

真实业务需要为下游不可用的情况准备处理路径。

例如：

• 检索接口超时；
• 外部工具返回 500；
• 数据源暂时不可用；
• 第三方 API 配额打满；
• 某一步成功，后续动作失败。

很多 demo 之所以“看起来稳定”，只是因为评测环境从来不主动制造失败。

生产评测更该检查的是：

• 失败是否有明确分类；
• audit logs 能不能留下完整链路；
• 是否会触发重试、降级或停机；
• 写操作半成功时有没有补偿或回滚记录。

6. 成本与时延样本：结果对了，但代价能不能接受

有些 Agent 在 demo 环境里效果不错，但一放大到真实流量就会暴露另一种失败：

• 每次都走高成本模型；
• 工具调用链太长；
• 上下文堆太厚；
• 同一问题重复查多次；
• 平均时延能接受，尾延迟却过高。

这类问题如果不进评测样本，团队上线前几乎不会认真讨论。

所以评测不该只产出“正确率”，还应该记录：

• 不同任务等级对应的模型路由；
• 每条链路的工具调用次数；
• 平均与 P95/P99 时延；
• 单任务估算成本；
• 失败重试后的代价变化。

这才是能真正指导生产决策的数据。

把检查项写成同事能使用的验收表

下面以设备数据查询为主，补一个假设的工单写入任务。全部是手工设计的模拟样本，尚未运行 Agent，不是实际通过率或客户事故记录。

三站模拟输入与手工预期沿用公开周报示例。

下载六行样本、核对依据与空白运行记录。记录表包括用户权限、数据条件、预期/实际结果、证据、负责人和复测，不要在没有运行时填写“通过”。成本和时延另用真实任务记录，不从这张功能样本表推出性能成绩。

业务和技术怎样一起决定试用范围

先由业务负责人确定要完成的工作与可接受结果，工程负责人准备能核对的输入和权限条件。双方一起检查实际输出；越权、未批准写入、明知缺数仍冒充完整结果的能力，先阻止开放。修复后用同一组样本复测，保留前后结果，再决定可以交给哪些人、允许做哪些事。

示例中出现的设备数据查询、来源和报告能力，可以查看Sam 的个人项目经历；本表的具体输入和预期是另外制作的方法材料。

为什么“样本覆盖”比“再调一轮 prompt”更优先

因为很多上线问题并不是 prompt 不够细，而是样本没有覆盖真实失败模式。

如果评测集里只有成功案例，团队最后学到的只会是：

• demo 能跑；
• 分数不难看；
• 会议里可以展示；
• 真正危险的情况没有被提前暴露。

更稳妥的做法，是把评测当成生产前的风险样本集，而不是模型能力宣传册。

一个够用的补齐顺序

如果团队最近正准备把 Agent 接进真实业务，我更建议按这个顺序补评测：

1. 先补标准成功样本，建立最低可用基线；
2. 再补歧义样本，检查会不会乱猜；
3. 再补证据冲突样本，检查 citations 和停机规则；
4. 再补权限边界样本，验证 tool-calling 与字段暴露；
5. 再补失败超时样本，验证 audit logs、重试和回滚；
6. 最后补成本时延样本，决定模型路由和自动化比例。

这样团队讨论的就不再只是“这个 Agent 看起来聪不聪明”，而是“它在真实任务分布下，哪些风险已经被测过，哪些还没资格放进生产”。

AgentKick 的首次合作是AI Agent 生产就绪审查与路线图：围绕一段工作，交付就绪评分卡、P0/P1/P2 问题清单和整改路线图，代码实施另行确定。先选一段准备交给同事的工作，用Agent 场景自检整理输入、权限、结果与负责人。