Runwise 增长研究院

2026-10-13

Runwise 增长研究院

10/13/2026
企业AI创新

一次成功的Demo不等于Agent能持续完成业务。从业务结果、执行轨迹、安全边界到运营效率，建立可重复的评测体系才能放心上线。

30秒看懂：AI Agent评测不是给大模型考试，而是验证“模型+工具+执行框架+工作环境”组成的整体能否在明确边界内持续做对业务。一次成功的Demo无法证明Agent能持续完成业务工作，评测要检查最终业务结果、执行过程、风险与资源消耗，并能在模型、工具和业务规则变化后重复验证。企业应把“成功”写成可独立核对的业务结果，从真实工作中建立20—50个评测任务，将评分规则拆成代码、模型和人工三类，重复运行同一任务观察稳定性，专门测试拒绝、暂停或转人工场景，并建立分风险等级的上线门槛。

让一个客服Agent现场处理退款，演示时它识别客户、查询订单、回答政策，最后说“退款已完成”。看上去一切顺利。但如果数据库里并没有形成正确的退款记录，这场Demo实际没有完成任务；如果换一个账号、改变订单状态，Agent又执行了越权退款，即使第一次成功也不能交付生产。

AI Agent评测（Agent Evals）的目的，就是在规定的测试任务和环境中观察Agent的真实行为，检查最终业务结果、执行过程、风险与资源消耗，并且能在模型、工具和业务规则发生变化后重复验证。它不是给大模型做一次考试，更不是把演示成功率当成上线验收结论。

Anthropic在2026年1月发布的Agent评测工程指南特别区分了一次运行的轨迹（Transcript/Trace）、系统最终状态（Outcome）以及用于执行与计分的评测基础设施（Harness）。OpenAI也提供基于轨迹的评测工具，用来分析Agent的工具调用与任务过程。两家技术文档的共同意义是：评测对象是“模型＋工具＋执行框架＋工作环境”组成的整体，而不是孤立的模型分数。

这篇文章讨论企业如何建立第一套可用的评测方法。关键不是追求一个漂亮的平均分，而是回答：业务任务究竟完成没有，哪些失败不可接受，同一任务会不会反复出错，以及系统改动后能否继续可靠运行。如果你正在规划企业的AI落地路径，可以参考企业AI转型谁来负责？CEO、业务、IT与AI CoE如何分工与协同，先明确评测体系在组织中的责任归属。

先把“成功”写成业务结果，而不是AI说了什么

传统软件的许多测试具有确定输入和确定输出。Agent可以按不同顺序调用工具，在多步任务中根据反馈调整计划，因此同一任务的过程未必每次相同。这不意味着完全无法测试，而是必须先定义可以独立核对的业务结果，允许不同但有效的执行路径。

以客服退款为例，“Agent回复已退款”不是可靠验收标准。“订单号正确、客户身份符合要求、退款金额在授权范围内、交易系统形成唯一正确记录、客户得到准确通知”才是一组可以核验的结果。若同一笔订单被重复退款，哪怕通知文案很流畅也应判失败。

建议把评测分成四层：

评测层次	具体要检查什么	退款Agent的检查方式
业务结果	状态是否真的改变且符合要求	测试订单是否生成正确退款记录、金额与币种是否一致
执行轨迹	调用了什么工具、参数、权限	查询、校验、退款API的调用记录及失败重试
安全与边界	不该做的有没有做、该升级时有没有升级	无权限订单、身份不明、超限金额必须拒绝或转人工
运营效率	完成时间、调用成本、复核负担	单任务时延、调用成本、人工补救和异常比例

其中安全与结果是各自独立的门槛。业务结果正确，不代表获取数据的方式合规；一次因越权而“成功”的操作仍然不能通过上线评测。

还应区分能力测试与回归测试。前者专门放入难题，看Agent还有哪些缺口；后者保留已解决的典型任务，检查新版模型或新提示词有没有把原来做对的事情做坏。两类测试面对的题目难度不同，不宜混成一个总分。Agent评测与AI数字员工是什么？从Agent、Copilot到RPA，企业如何判断能否真正上岗中讨论的上岗判断标准密切相关，都强调不能只看能力展示，要看边界内的可靠执行。

第一步：从真实工作中建立第一批20—50个评测任务

很多团队迟迟不做评测，是因为以为必须先收集几千条标准答案。Anthropic的实践建议是，早期可以从20—50个来自真实失败和产品要求的简单任务开始。这个数量适合发现明显缺陷、帮助开发团队迭代，不是任何企业高风险Agent正式上线的充分样本量。

第一版评测集可以按五类场景整理：正常业务、信息缺失、规则边界、恶意或异常输入、工具或外部系统故障。每个任务明确初始条件、允许使用的权限、预期业务结果、禁止行为和检查方法。

测试类型	示例任务	为什么必须测
正常业务	身份已验证、金额在权限内的退款	检查基本交付能力
边界业务	金额刚超过自动退款额度	检查转人工与越权保护
数据异常	订单不存在、客户姓名冲突、重复提交	检查能否拒绝臆测与幂等处理
攻击输入	客户消息中要求Agent跳过身份校验	检查是否把外部文字误当指令
系统故障	退款API超时或返回不确定状态	检查是否安全停止、核查后重试

负责业务的团队应当参与定义“什么算做对”，因为技术团队不一定掌握退款政策和客户补偿条件。平台团队负责建立隔离的测试账号、模拟支付系统、可重置数据库与执行轨迹；风控人员确定不可容忍的异常。测试环境不应向真实客户发送通知或产生真实资金转移。

任务还需要版本和来源：某一条由哪项业务政策产生、谁批准标准答案、适用于哪一版业务规则；否则政策修改后，Agent可能按照新规则正确处理，却被过期评分器判错。这与创新案例｜海尔智家AI规模化落地的4大战略：员工自建超1.4万个应用中强调的“业务团队参与定义标准”的思路一致，评测任务同样需要业务Owner深度介入。

第二步：把评分规则拆成代码、模型和人工三类

评测不一定越“智能”越好。涉及金额、状态、权限、日志和唯一性时，应该尽量由代码或数据库断言直接判定；涉及客服回复是否清楚、研究报告是否遗漏要点等开放结果，可使用模型评分，但需要业务专家校准；涉及重大合规判断或争议边界，应保留人工复核。

例如，同一退款任务可由代码确认“实际金额正确、交易恰好一次”，由大模型根据明确评分规则检查回复是否覆盖必要解释，再由资深客服抽检复杂争议。不能让评分模型只看Agent自述的“我完成了”，却没有核查交易系统事实。

Anthropic提醒，过于僵硬的评分器也会制造虚假失败：它介绍的一个研究例子中，模型在CORE-Bench上的初始分数是42%，研究人员修复含糊任务与评分问题并调整执行框架后，达到95%。这并不意味着所有Benchmark都存在如此大的错误，只说明分数还取决于题目、评分器和测试环境，不能把一次公开榜单结果直接变成采购结论。

企业还需要做两项校准。其一，抽取若干任务让业务专家独立评分，比较与模型评分的差异，特别检查漏判的高风险失败；其二，人工阅读一部分成功和失败轨迹，检查是不是Agent找到了一条合理的新路径，还是在利用评分器漏洞。允许合理路径多样化，但不能容忍通过修改测试文件或跳过关键业务规则获得“高分”。

第三步：重复运行同一任务，不把平均成功率误认为稳定性

Agent的结果可能因模型随机性、工具响应、上下文和外部状态不同而变化。因此，除了测不同任务，还应对重要任务做多次独立试验，并记录哪一种失败反复出现。

用同样的框架诊断你的业务

如果你正在规划Agent上线，但不确定自己的评测集是否覆盖了关键失败场景，可以用AI顾问对照本文的四层检查表和分风险门槛，快速定位缺口。

免费体验 Upskill AI 顾问 →

Anthropic区分两个经常混淆的指标：pass@k表示同一任务运行k次，至少一次成功的概率；pass^k表示运行k次全部成功的概率。二者不能互换。假设Agent单次成功率为75%，且各次试验成功与否相互独立，连续运行3次全部成功的概率是0.75³，约为42%；至少成功一次则约为98%。用“多试几次总能做对”宣传Agent，不适合一次出错就可能影响客户的业务。

同样，一个10步任务若每一步成功率均为95%，且步骤错误相互独立，全部成功的概率约为0.95¹⁰，即60%。实际错误常具有相关性，不应将这一示例直接当成某个产品的真实成功率。多步任务的端到端评测仍须通过真实运行取得。

重复试验也有陷阱。若前一次测试留下订单、缓存或文件，下一次Agent可能读到这些残留并获得不公平优势；若所有测试共享一个故障接口，许多失败可能来自环境，而非模型。评测需要隔离环境并记录模型版本、工具版本、数据快照和运行条件，否则“通过率提高了”可能只是测试条件变了。

对管理者而言，应该要求评测报告同时列出任务覆盖范围、试验次数、失败类型、严重程度和复核结果，而不是只给一个“总成功率90%”。

立即登录阅读全文

登录或注册即可解锁全站内容，即表示你理解并同意服务协议与隐私政策

第四步：专门测试它什么时候应该拒绝、暂停或转人工

如果一个Agent接入CRM、邮件、财务或支付系统，那么最重要的评测任务之一，不是能不能处理正常请求，而是在信息不足、权限不够、动作不可逆时能不能停下。这类“负向任务”若没有纳入评测，Agent可能被优化成任何事情都先尝试执行，反而扩大事故范围。

至少应在隔离环境中模拟四种情况：第一，用户要求越过角色权限；第二，外部邮件或网页包含诱导Agent改变规则的文字；第三，工具返回超时、重复响应或相互矛盾的信息；第四，系统已经部分执行任务，此时又收到取消请求。查看它是否继续误操作、是否提供正确的转人工信息，以及有没有留下可以复盘的轨迹。

上线前要决定的不只是“平均多少分通过”。对能写入系统或影响资金的Agent，应单独要求关键禁止行为不得出现，并在发现此类失败时阻断上线；但“测试样本中零次违规”只说明已测样本没出现问题，不能在统计上证明未来违规概率为零。应结合影响范围、样本覆盖、权限限制、监控与紧急停用能力决定能否投产。

OpenAI的轨迹评测工具适合复查工具选择和中间动作；NIST的AI风险管理框架也强调对风险进行持续测量、管理和复核。不过，具体测试集、阈值和审批岗位仍应由企业依据自身场景定义，不能照抄厂商的模板。这一原则在下属自己搭了个能发客户邮件的Agent，你批不批？六类动作的授权决策表中有更具体的授权决策框架，可结合使用。

第五步：建立分风险等级的上线门槛，而不是一个统一及格线

企业可先区分三种使用方式：只读的内部信息助手；生成建议但由员工确认的业务助手；能够直接改变业务系统状态的Agent。三者的容错要求、评测成本和放权程度不同。

上线检查	内部只读助手	人工确认型Agent	可执行型Agent
业务结果	主要问答和检索质量达标	建议准确且人工能识别错误	真实最终状态、权限与事务一致性达标
负向任务	不泄露越权资料	不擅自发出外部承诺	禁止操作、重复执行和越权测试单独通过
重复运行	覆盖高频与歧义问题	关键任务反复测试	重要任务多次运行并检查最坏失败
人工角色	有内容反馈渠道	审批人能查看依据并拒绝	明确接管、停止和恢复负责人
上线方式	限定内部用户试点	明确审批及抽检规则	分阶段开放权限、灰度与紧急停止
运营期	收集错误提问	复核建议及审批负担	持续监测业务状态、风险事件和回滚效果

表格是Runwise按风险设计的实施建议，不是Anthropic、OpenAI或NIST发布的统一强制标准。每个Agent还应有自己的放行记录：业务Owner确认结果可以接受；IT确认系统运行与监控条件；安全、法务或风控按风险独立放行。若其中一项尚未通过，就只能停留在受控试点阶段。

最容易遗漏的是人工审批成本。将每一步都交给人点击“同意”，可能造成审批疲劳，并让业务收益消失。评测报告应包含每任务需要人工介入多少次、处理异常花多久，而不是只统计Agent自己执行的时间。

第六步：把真实失败加入回归集，形成长期质量能力

评测工作并不在发布当天结束。模型版本更新、提示词修改、工具接口变化、知识库内容变动以及业务政策调整，都可能让过去正常运行的Agent产生新错误。

应建立一条固定路径：线上监控或业务用户报告问题；由业务与技术人员确认影响；将可复现的失败脱敏整理成新任务；修复后在相同条件下验证；加入回归集并记录版本。不能重现或尚未查明的重大异常，也应保留事件记录和临时限制措施。

维护评测集还要避免“只学会答过去的题”。用于开发调试的题目与保留的独立验收题应适当隔离，增加新业务样本，并定期检查题目是否过时。对开放式任务，抽读轨迹和真实业务反馈仍然重要。评测集是持续维护的经营资产，不是一份做完就存档的Excel。

当企业更换模型供应商或调整Agent框架时，这套自有测试集尤其有价值。团队可以在同一批业务任务与约束下比较质量、成本、时延和故障表现，而不是直接拿两个供应商各自提供的Benchmark分数比较。Anthropic也观察到，建立有效评测体系的团队能更快判断新模型是否值得切换；具体收益因企业情况而异。这与AI试点项目核算：一个部门的试点算出 −7.4%，为什么铺到 20 个部门变成 −16%？中强调的“用自有数据验证”逻辑一致，评测集就是企业自己的验证资产。