导语：📌 AI 模型评测正在从知识问答、数学推理和短代码生成，转向浏览器操作、软件修复、文档处理以及跨应用协作等真实工作流。评测对象也随之改变：过去主要观察“模型答得对不对”，现在更关心“模型能否在规定环境、成本和权限内，把事情完整做成”。然而，如果不同机构对任务完成、运行预算和失败处理的定义不一致，“任务成功率”仍然可能只是一个看似直观、实际难以横向比较的数字。
一、真实工作流为什么需要新的成功标准
传统准确率通常对应一道题和一个标准答案，而真实工作流包含多个相互依赖的环节。例如，处理一项软件缺陷可能需要理解需求、定位文件、修改代码、运行测试并检查回归；制作业务报告则可能涉及检索资料、读取表格、计算指标、生成文档和保存到指定位置。任何关键步骤失败，都可能导致最终交付不可用。
SWE-bench 使用真实软件仓库中的问题检验智能体能否生成通过测试的修复方案，其官方榜单同时展示模型、智能体框架、解决率、运行成本和轨迹等信息。这说明最终成绩并非只由底层模型决定，检索方式、工具权限、提示模板和执行框架同样会影响结果。不同系统即使调用同一个模型，也不能简单视为同一种能力配置。相关评测结构可参考 SWE-bench 官方榜单。
OSWorld 则把智能体放进真实计算机环境，让其操作桌面应用、文件系统和跨应用流程，并通过执行后的系统状态判断任务是否完成。该项目强调可复现的任务初始化和执行式验证，比单纯比较自然语言答案更接近实际用工场景。其任务设计与环境说明可参见 OSWorld 官方页面。
二、统一“任务成功率”应先统一分母与判定条件
✅ 一个可比较的成功率，至少应明确“成功任务数除以有效任务数”。这里的有效任务不能直接等同于计划运行的任务：如果环境启动失败、外部服务不可用或评分脚本异常，应单独列为基础设施错误，而不是静默计入模型失败，也不能随意从分母中删除。
建议统一记录六类核心字段
- 任务版本：固定数据集快照、任务编号、软件版本和初始状态，避免不同时间运行的任务已经发生变化。
- 成功定义：优先检查最终产物和系统状态，而不是只看智能体是否声称“已完成”。
- 运行预算：公开最大步骤数、超时时间、令牌预算、重试次数及可调用工具。
- 失败分类：区分理解错误、规划错误、工具调用错误、权限受限、环境故障和评分器故障。
- 重复试验：对具有随机性的配置运行多次，报告均值、波动范围和单次结果，避免只展示最佳成绩。
- 成本指标：同步公布每次任务成本、成功任务平均成本、执行耗时及人工接管次数。
统一口径并不意味着所有任务只能采用“全对或全错”。更合理的方式是同时保留三层指标：第一层是严格端到端成功率，回答任务是否真正交付；第二层是关键里程碑完成率，用于定位流程在哪个阶段中断；第三层是质量、安全和效率指标，用于判断成功是否以高成本、越权操作或不稳定行为为代价。斯坦福 HELM 所倡导的多场景、多指标、标准化和透明评测思路，也说明单一准确率不足以呈现模型的完整表现，可参考 HELM 项目说明。
三、如何看待厂商自测成绩
🔍 厂商自测并不等于不可信。模型开发者通常最早掌握新版本，也有能力进行大规模测试，自测结果可以帮助外界了解能力边界和推荐配置。真正的问题不是“谁测的”，而是第三方能否知道它“怎么测”，并在相同条件下复现。
阅读自测报告时，首先要检查测试集版本是否明确，以及是否存在训练数据污染或针对公开题目的过度优化；其次要看模型之外使用了什么智能体框架、检索器、系统提示和专用工具；再次要确认推理强度、步骤上限、并行策略和重试机制。若报告只给最终百分比，却没有任务日志、失败样例和运行配置，其结论更适合作为产品宣传线索，而不是采购决策依据。
SWE-bench Pro 在设计说明中专门关注数据污染、任务多样性、问题过度简化以及测试环境不可复现等风险，并通过容器化环境、人工检查和测试验证提高可靠性。这类机制值得企业在内部评测中借鉴，具体方法可参阅 SWE-bench Pro 方法说明。
厂商自测可信度可以分为四档
- 仅有结论：只有成绩或排名，没有任务清单、配置和日志，参考价值有限。
- 方法公开：披露数据集、提示、工具、预算和评分规则，但尚无外部复现。
- 结果可审计：提供运行轨迹、失败案例、版本信息及异常任务处理方式。
- 独立可复现：第三方能按相同协议得到接近结果，并公开差异原因，可信度最高。
判断自测是否可信，不应只问“分数高不高”，而应追问“测试条件能否复现、结果能否审计、成绩能否迁移到我的工作流”。
四、企业应该怎样建立自己的评测闭环
🛠️ 企业选型时可以先从真实业务日志中抽取一批高频任务，再按难度、风险和工具类型分层。每个任务都要定义初始状态、允许操作、必需交付物、禁止行为和自动验证方法。公开基准适合衡量通用能力，内部任务则负责验证模型对本企业数据结构、软件环境和业务规则的适配程度。
实际执行时，应在同一运行器、同一预算和同一任务快照下比较多个模型，并保留完整轨迹。第一轮关注严格成功率，第二轮分析失败类型，第三轮再调整提示、工具和流程。这样才能分清问题究竟来自模型能力、智能体框架，还是业务系统本身不适合自动化。
对于高风险场景，还应把“需要人工接管”设计为正常结果，而不是强迫智能体继续操作。一个能够识别不确定性、及时停止并提交清晰上下文的系统，可能比表面成功率更高但偶尔造成严重错误的系统更有生产价值。🚦
总结
AI 评测转向真实工作流之后，任务成功率必须建立在统一任务版本、运行预算、工具权限、成功判定、异常处理和重复试验之上。严格端到端成功率负责回答“事情是否做成”，里程碑、成本、安全和稳定性指标则负责解释“如何做成、是否值得部署”。对于厂商自测，既不应全盘否定，也不能照单全收；最可靠的判断依据是方法透明、轨迹可审计、第三方可复现，以及结果能够在企业自身工作流中再次验证。最终，真正有价值的不是排行榜上的最高数字，而是一套能够持续发现问题、比较方案并指导上线决策的评测体系。
