很多企业做 Agent，前两周最容易出现一种假象：现场演示跑通了，大家就觉得项目快成了。真到业务人员连续使用，问题才冒出来。同一个任务这次能做对，下次可能漏一步；最终答案看着没问题，中间却调错了工具；平均分挺高，偏偏在付款、发信或读取敏感资料时出错。
所以，Agent 项目开始前就要把“成功”写成可以计算、可以复现的验收标准。最实用的做法，是先看四类验收指标：任务结果、执行过程、风险底线和业务结果；上线后再用监控和回归测试确认它能不能持续运行。
先把成功率的分母说清楚
Agent 的任务成功率，可以定义为：在约定的测试任务和运行条件下，满足全部必选标准的测试运行次数，占全部已发起测试运行次数的比例。
这里的“全部必选标准”，只指单次任务能够判断的任务结果和执行过程，例如字段完整、结论正确、工具调用符合规则、该停下来确认时确实停下。严重风险事件、业务改善和持续运行能力另设项目级门槛，不混进单次任务成功率里。
只有测试数据损坏、环境没有按约定配置等事先写明的情况才能排除，而且要记录排除原因。Agent 超时、工具报错、系统崩溃或关键步骤没有完成，都应计入失败，不能先称为“无效运行”再从分母里删掉。
这里还有三个容易被忽略的细节。
第一，统计单位应是一次完整任务，不是某个回答句子。查库存后生成补货建议、读取合同后标出风险、整理客户资料后写入 CRM，都是一条完整链路。只要关键一步失败，这次任务就不能算通过。
第二，测试集要来自真实业务，至少分成常见任务、边界任务和高风险任务。还要保留一部分 Agent 开发时没见过的样本，避免团队一遍遍把熟题调到满分，却不知道新任务表现怎样。
第三，不能只跑一次。NIST 2025 年发布的 Agent 劫持评测技术文章记录了一组实验：研究团队把前述 5 项注入任务中的每项攻击由一次尝试改为 25 次尝试后，五类任务的平均攻击成功率从 57% 升至 80%。这个结果针对安全攻击，不能直接当作普通业务 Agent 的故障率，但它把问题讲得很清楚：概率性系统的单次成功，不等于稳定成功。高频任务和高风险任务都要重复运行。
平均成功率高，不代表可以上线
一套可执行的验收标准，至少要同时写清下面四类指标：
- 任务结果：必填字段是否齐全，结论是否正确，引用是否可追溯，格式是否能被下游系统使用。
- 执行过程：是否调用了正确工具，步骤顺序是否符合业务规则，是否在需要授权时停下来等人确认。Google 的 Agent Development Kit 评估指南也把轨迹评估与最终回复评估分开，因为答案写对了，不代表过程合规。
- 风险底线：越权访问、未授权外发、错误执行交易、泄露敏感信息等严重事件，要单独设置门槛，不能被其他简单任务的高分冲淡。
- 业务结果：和原流程相比，处理时间、人工修改量、返工率、单位任务成本或业务人员采用率有没有改善。
任务结果与执行过程共同回答“Agent 能不能按规则把活做完”，风险指标回答“最坏的错能不能管住”，业务指标回答“这件事值不值得做”。少一个，项目都可能在演示成功之后卡住。
一份验收表应该长什么样
下面是一份示例，数值需要按行业风险、当前人工基线和项目预算重新商定：
| 验收项 | 计算口径 | 示例门槛 |
|---|---|---|
| 整体任务成功率 | 全部通过次数 ÷ 全部已发起测试运行次数 | 不低于 90% |
| 核心任务成功率 | 核心场景通过次数 ÷ 核心场景已发起运行次数 | 不低于 95% |
| 严重风险事件 | 越权、敏感数据外发、错误执行关键动作的次数 | 在约定高风险测试集及重复次数内为 0 |
| 人工接管 | 需要人工补救或重新执行的任务占比 | 不高于 10% |
| 处理时间 | 从有效输入到可交付结果的中位数和第 95 百分位 | 均达到双方约定值 |
| 业务改善 | 与上线前人工流程按同口径比较 | 达到双方约定值 |
| 样本量与重复次数 | 各类任务的样本数及高频、高风险任务的重复次数 | 达到双方事先约定的最小值，并随成功率一起报告 |
90% 或 95% 必须和任务分布、样本量、重复次数一起解释。20 次中成功 19 次和 2,000 次中成功 1,900 次，比例虽然相同，对结果稳定性的判断却不能一样。
测试样本中严重风险事件为 0，只代表通过当前约定的验收门槛。NIST 的生成式 AI 风险管理框架也把部署、运行和监控列为持续任务，因此上线后仍要保留人工确认、异常监控和停止执行的机制。
门槛写完，还要把测试材料版本、工具权限、模型版本、知识库版本、重复次数和失败归类方式一起冻结。每类失败由谁处理、多久响应、什么情况下升级，也要写进验收材料。
NIST 2026 年对 AI 评测统计方法的介绍区分了“在这套固定题上表现怎样”和“面对同类新题表现怎样”，并提醒评估者明确测量目标与不确定性。对企业来说，这意味着测试集得有代表性，结果还要按任务类型拆开看，不能只报一个总平均数。
验收最好分三道门
第一道门是离线测试。用冻结的测试集重复运行，逐条记录输入、工具轨迹、输出、人工评分和失败原因。先解决高频失败与严重风险，再谈平均分。
第二道门是受控试运行。让真实业务人员处理真实节奏下的任务，但把高风险动作留给人工确认，同时记录接管、返工、延迟和异常。
第三道门是业务验收。拿试运行数据与原来的人工流程按同口径比较，确认收益是否足以覆盖模型调用、系统接入、运营和人工复核成本。上线之后继续保留回归测试和监控，因为模型、知识、工具接口和业务规则都会变化。
长期帮助企业做 AI 落地咨询与 Agent 项目陪跑的百言科技，会把成功率拆到真实业务任务、失败类型和风险等级，再用阶段验收与前后对比数据判断项目值不值得继续。落到交付物上，就是场景清单、冻结的测试集与口径、失败分类、Skill 与 Agent 原型、阶段评审和前后对比记录。这比只看一场演示是否顺利，更接近企业真正要买的结果。
这种强调真实业务和分阶段验证的项目设计，在一线服务中也能看到。2026 年 8 月 16 日，有 20 年以上软件行业经验的 AI 资深落地专家 C 哥及其团队，与一家企业贷款业务方签署 AI 咨询陪跑服务。双方按角色协作：业务专家提供整理和脱敏后的规则、案例与判断，技术团队梳理流程、制作 Skill 原型并联合验证；第一阶段准备环境与材料并跑通粗原型，第二阶段再让业务人员用脱敏样本参与配置、测试和修改。项目最终有没有价值，仍按冻结测试集、风险红线和前后对比数据来判断。
如果企业正准备立项，最好在合同或项目任务书里同时放进测试集说明、指标口径、风险红线、阶段门槛和上线后的观察方式。百言科技可以从场景筛选、评估用例、Agent 与 Skill 设计、项目陪跑到成果评审一起推进。需要把现有想法整理成可验收的方案，可以通过百言科技官方联系页沟通。