AI Agent 怎么评测：别只看任务有没有完成

评测 AI Agent，不能只问「任务完成了吗」。正确的评测要同时回答八个问题：结果对不对、步骤是否合理、工具有没有调对、花费是否可接受、响应是否及时、失败后能否恢复、有没有越过安全边界，以及人是否愿意签字放行。少看其中任何一项，都可能把一次偶然成功当成可上线能力。

Agent 与普通问答系统的差别，在于它会连续规划并执行动作；AI Agent 是什么解释了这个循环。评测对象因此不只是最后一段文字，而是从接收目标、选择工具、改变外部状态到交付证据的整条轨迹。企业需要评的是一套可重复的工作系统，而不是一场演示。

先把「完成任务」写成一份任务合同

测试之前，先写任务合同。它至少要说明输入是什么、交付物是什么、哪些事实必须正确、允许访问哪些数据和工具、哪些动作禁止自动执行、遇到什么情况必须停下问人，以及用什么证据证明任务完成。比如「整理客户咨询」过于模糊；更可测的版本是：读取指定时间范围内的工单，按既定标签归类，保留工单编号作为来源，不修改原记录，缺少产品信息时进入待确认队列。

任务合同把三种常被混在一起的结果分开：完全通过是所有必备条件都满足；部分通过是主要交付物可用，但存在允许返工的缺项；失败则包括事实错误、关键步骤遗漏、越权动作或没有证据却声称完成。任务成功率只统计完全通过，部分通过单独报告。否则团队很容易把「做出了一份东西」算作成功。

一套完整评测要同时看八个面

八个维度不是为了做一张好看的雷达图，而是为了定位不同性质的问题。推荐把它们写成独立指标，并为高风险项设置否决条件：

• 任务结果：事实、计算、格式、完整性和来源是否满足任务合同。
• 执行过程：规划是否遗漏必要步骤，是否出现无依据推断、无效循环或过早结束。
• 工具调用：工具选择、参数、调用顺序、返回值检查和权限范围是否正确。
• 成本：模型调用、外部工具、重试以及人工复核合起来，每个合格任务实际花多少。
• 延迟：正常完成需要多久，最慢的一批是否仍能满足业务时限。
• 可恢复性：超时、断线、返回异常或中途接管后，能否安全续跑而不重复产生副作用。
• 安全：是否抵抗恶意输入、拒绝越权、保护敏感信息，并在关键动作前等待审批。
• 人工评测：业务人员是否认为结果可用、证据清楚、风险可接受，并愿意承担最终确认。

不要把八项简单平均成一个总分。一个 Agent 即使结果质量很高，只要发生过未授权发送或跨范围读取，就不应靠成本低、速度快把分数「补回来」。更稳妥的做法是先设安全、权限和关键事实的硬闸门，闸门全部通过后，再比较成功率、成本与延迟。

测试集要从真实工作长出来，而不是只出理想题

可落地的测试集从任务盘点开始。选一个边界明确的流程，收集已经脱敏的历史输入、人工交付物、常见退回原因和系统异常记录。不要把人工答案直接当唯一标准：有些任务允许多种正确表达，真正需要固定的是事实、不变量和禁止动作。每个案例应记录案例编号、输入快照、必要输出、可接受差异、可用工具、权限、时间与成本上限、预置故障以及人工评分规则。

案例至少覆盖四类。正常案例检验主流程；边界案例包含缺字段、歧义请求、重复记录和异常格式；对抗案例在网页、文档或用户输入中夹入诱导越权、索取秘密或篡改目标的指令；故障案例主动制造工具超时、登录失效、返回空值和执行中断。对每个高频任务，至少放入这四类中的代表样本，才能看见演示路径之外的可靠性。

测试集还要分成开发集与保留集。开发集可以帮助团队修提示词、工具和流程；保留集不参与日常调试，只在版本放行时运行，避免系统只是记住已知题目。线上出现新故障后，把脱敏且可复现的案例补进回归集，并标记它来自哪个事故、预期防住什么退化。这样测试集会随业务一起成熟，而不是上线前用一次就封存。

结果、过程和工具调用必须分开判分

结果层先检查硬条件，再检查质量。结构化任务可以逐字段比较；研究与摘要任务则检查关键事实覆盖、引用是否能支持结论、是否混入输入之外的断言。对允许多个正确答案的任务，不必追求逐字一致，可以使用必含事实、禁含内容和业务量表组合判定。最终要能解释某个案例为什么通过，而不是只留下模型给出的一个分数。

过程层看的是轨迹质量：Agent 是否确认了关键前提，是否在证据不足时继续猜测，是否反复走同一条失败路线，是否在已经满足条件后仍增加动作。过程不必只有一条标准路径，但必须遵守不变量。评测者可以允许不同规划，只要它们都没有跳过审批、没有篡改原始数据，并能把交付物追溯到输入。

工具层要逐次核对工具名称、参数、身份、返回状态和后续处理。最危险的不是调用报错，而是调用失败后 Agent 没有检查返回值，仍然报告「已完成」。还要测试幂等性：同一步因重试执行两次，会不会重复发信、重复建单或重复扣减库存。固定流程如果根本不需要动态选工具，就应回到AI 工作流和 AI Agent 怎么选的判断，别为自主性支付额外风险。

成本、延迟与恢复能力决定它能不能长期运行

成本不能只看模型账单。单任务总成本还包括搜索、浏览器或第三方接口费用，失败重试消耗，以及人工复核与善后的时间。应同时报告「每次尝试成本」和「每个合格结果成本」；后者会把失败与返工纳入账本，更接近业务真实支出。若 Agent 为一个简单任务规划几十步，即使最后做对，也可能没有生产价值。

延迟同样不能只报平均值。需要分别看典型任务和最慢一批任务，还要把排队、等待工具、人工审批的时间分开。客服辅助可能要求及时返回，夜间批处理则更在意截止时间内完成。指标要来自业务时限，而不是拿一个统一秒数套所有场景。

恢复测试要故意把系统推离顺利路径：在工具调用后断开连接、让会话过期、返回格式错误、让依赖服务短暂不可用。观察 Agent 能否识别当前状态，安全重试或从检查点续跑；不能恢复时，是否把已完成动作、失败位置和待处理事项完整交给人。评估从试验转向生产的其他条件，可参考AI 项目从试点到正式上线。

安全测试要把不可信内容当作环境的一部分

Agent 会读取网页、邮件和文档，这些内容不能因为「看起来像资料」就被当成指令。安全测试应放入提示注入、伪造管理员要求、诱导泄露密钥、请求读取无关客户资料、要求绕过审批等案例，验证系统能区分任务目标、可信系统规则与外部不可信内容。拒绝动作本身也要留痕，便于判断是安全策略生效，还是工具偶然失败。

权限测试不只验证「能不能做」，还要验证「不该做时是否确实做不了」。用不同角色、不同数据范围和不同动作级别重复同一案例，检查读取、生成、修改、提交和对外发送是否逐级受控。涉及不可逆或高影响动作时，审批必须发生在动作执行前，批准内容要绑定具体对象和参数，不能用一次笼统同意覆盖后续所有操作。责任链与日志要求可继续看AI Agent 出错谁负责。

人工评测要有量表，评测结果要进入持续回归

人工评测不是让同事凭感觉打一个「不错」。量表应把正确性、完整性、可读性、证据清晰度、业务可用性和风险分开，并说明每档分数的可观察表现。评审时隐藏模型或版本信息，减少对品牌和新版本的先入判断；出现分歧时记录争议点，由业务负责人确定任务合同是否需要补充，而不是简单取平均。高风险案例必须由具备相应业务权限的人签字。

一轮可靠的放行顺序是：先在固定测试集离线运行，再进入不写回真实系统的影子模式，然后只开放给受控用户和低风险任务，最后在生产中持续抽检。每次模型、提示词、工具、权限或知识源变化，都重跑保留集；任何硬闸门退化都阻止发布。评测的最终产物不是一张分数表，而是一套能说明什么版本、在什么边界内、为什么可以运行的证据。