治理与安全 / 业务验证
业务 Agent 上线前，先证明它能完成闭环
基准分数是起点，真实流程才是上线考试。
先说结论
GDPval 用 44 种职业、每种 30 个任务评估模型交付专业成果；METR 则用真实软件任务测量模型能独立完成多长的人类工作。这些研究能回答“模型能力到了哪里”，却不能直接回答“这个业务 Agent 能否安全上线”。企业还要验证权限、数据、长链路、人工接管与业务结果。
- 公开基准
- 验证通用任务能力
- 场景评测
- 验证企业流程闭环
- 上线门槛
- 结果、风险同时达标
GDPval 的价值，在于把“会不会做工作”变成可以重复比较的交付测试
传统模型基准多用选择题、短答案或编程题衡量能力，离企业交付还有一段距离。OpenAI 在 2025 年发布的 GDPval 选择了美国 GDP 贡献较高的九个行业，覆盖 44 种职业，每种职业设置 30 个任务，共 1,320 项。参与任务设计的行业人员平均拥有 14 年相关经验。
这些任务要求模型制作职业工作中常见的数字化产物，例如财务分析表、演示文稿、工程文件和书面报告。任务提供背景资料、具体要求和参考文件，模型需要选择合适格式并提交完整文件。相关职业专家随后比较模型与人类专家的成果，评价可用性和质量。公开的黄金子集包含 220 项任务，研究者还提供自动评分服务，便于后续模型在同一标准下复测。
这种设计给企业两个启发。第一，评测单位应该是一份可以验收的工作产物，而非一次看起来聪明的对话。第二，任务包需要保存输入材料、操作要求和评分标准，让模型升级后仍能重复测试。员工随意提几个问题再凭印象判断，无法形成可追踪的能力证据。
一次交付测试省略了业务 Agent 最容易出问题的部分
GDPval 的论文清楚列出了限制。初版任务集中在电脑上完成的知识工作，不包含体力任务；它排除了大量默会知识、个人敏感信息、企业专有软件和人与人之间的沟通。研究者还把任务背景完整写进提示，让模型一次性交付，而现实员工常要先追问、寻找材料、协调他人，再决定该做什么。
业务 Agent 需要跨过更多环节。它可能先从工单系统读取客户信息，再查询合同和产品状态，随后调用审批接口，等待人工确认，最后把结果写回多个系统。任何一个环节都可能出现字段缺失、权限拒绝、接口超时、重复执行或状态冲突。模型能写出正确分析，不代表系统能安全完成整条流程。
企业还要面对责任问题。公开基准中的错误会降低评分，真实流程中的错误可能发错报价、泄露数据或影响客户权益。结果相同的两次失败，若一次可以被员工在发送前发现，另一次直接写入生产系统，两者的风险完全不同。上线评测必须把“错误是否可发现、可撤销、可追责”放进验收标准。
METR 的“任务时间跨度”衡量任务难度，不能直接换算成自主工作时长
METR 用约 230 个任务、80 个任务家族测量前沿模型的能力，内容主要来自软件工程、机器学习和网络安全。熟练人类先完成任务，研究者记录所需时间；模型对同一任务尝试多次，结果按成功或失败计分。研究者再用统计模型估计：当一项任务需要人类专家投入多长时间时，模型的成功率会降到 50%。
“两小时时间跨度”因此表示，模型对测试集里相当于低背景人类专家两小时工作量的任务，预测成功率约为 50%。模型完成任务时可能只运行几分钟，也可能反复失败。这个数字没有证明系统可以无人监督运行两小时，更没有证明它能完成任意两小时的知识工作。
数据范围也限制了解读。测试任务描述清楚、可以用算法评分，参与的人类基准更像刚接手材料的承包者，而非熟悉公司历史的员工。METR 说明，不同领域的时间跨度可能相差几个数量级；当前超过 16 小时的估计不够可靠，单个模型的误差区间常达到上下约两倍。企业若需要 98% 以上可靠性，也不能拿 50% 成功率的时间跨度决定授权。
公开能力数字适合观察模型进步趋势，场景上线仍要回到具体失败成本。一个模型可以解决大量一小时编程任务，也可能在库存、日程或权限处理上犯基础错误。业务负责人需要问的是：它在我们的输入、工具和规则下，对这类任务达到多高成功率；失败后员工需要多少时间发现和修复。
企业试点应先让 Agent 在后台旁路运行，积累失败证据
试点适合选择高频、边界清楚、结果可以判断的一类任务。以售后退款审核为例，团队可以让 Agent 读取脱敏订单、政策和沟通记录，在后台给出是否符合条件、建议金额和引用依据。员工仍按原流程处理，系统只记录自己的判断，不向客户发送，也不执行退款。
旁路运行可以比较机器建议与最终人工决定。团队需要保存输入快照、模型版本、工具调用轨迹、输出、员工修改和最终结果，随后给每次偏差归因：模型理解错误、知识过期、接口返回异常、业务规则冲突，或员工本身判断不一致。只有失败进入同一套案例库，产品、业务和安全团队才能针对同一事实修正系统。
第一轮评测关注交付物，确认事实、计算和引用是否准确。第二轮加入真实工具与最小权限，主动注入缺字段、超时、重复请求和过期状态，观察系统能否停止、重试或交给人。第三轮才开放低风险、可撤销的写入动作，高金额、外部发送和权限变更继续要求人工确认。
试点需要保留原流程作为对照。团队同时记录处理周期、一次通过率、人工分钟数、返工和风险事件。调用次数增加只能说明系统更忙，不能说明业务改善。若 Agent 把员工从判断工作转移到逐条检查低质量输出，表面自动化反而增加了总成本。
平均准确率只能描述表现，动作风险决定系统获得什么权限
平均 95% 准确率可能来自大量低风险任务和少量高损失错误。企业应按动作后果设定不同门槛。检索和草拟可以较早开放，员工在使用前复核；更新内部记录需要字段校验和完整审计；对外承诺、付款与权限变更需要更高可靠性，并保留人工确认或双人审批。
上线判断还要考虑错误的可见性。格式错误容易被发现，引用了过期政策的流畅答案更危险；重复写入可以通过幂等机制阻止，错误付款则可能难以追回。团队需要为每类失败定义检测方式、撤销路径、接管人和响应时限，再决定系统能够自动执行到哪一步。
评测也不能在上线当天结束。模型、知识库、接口和业务政策会持续变化，任何一项更新都可能让旧结果失效。企业可以保留一组核心回归任务，并不断加入生产中的新失败案例。版本发布前重跑任务，线上持续监控人工接管、异常和业务结果，系统才拥有可审计的能力记录。
公开基准回答模型在受控任务上的能力，企业评测回答一套具体系统能否承担业务责任。成熟的业务 Agent 会给出结果，也会留下证据、遵守权限、暴露不确定性并接受人工接管。公司最终上线的是一条可以治理的工作流程。