拒绝「差不多」，电商模型测评迎来「最严厉的父亲」

测评 AI 这件事，如今越来越难做了。 几年前，AI 还是聊天机器人时，测评主要就是做题：写作的、数学的、编程的……最后形成一套跑分，用分数代表模型能力。 但当 AI 从聊天框里走出来，变成能够调用工具、操作网页、处理文件、跨系统执行任务的 Agent，情况就变得复杂起来。 平时我们看到的，是 AI 出现在手机上，能够刷淘宝、加购物车，最后下单。实际上在商家的那一端，也有 AI 的参与，承担着比选购和下单更复杂的工作。 在专门考察电商环境中模型表现的 RealReplicaBench 测试中，经过 107 个真实商业任务的考核，所有参评模型都没有达到 60 分——都没有及格。 选手一共 13 位，但连同 GPT、Claude、GLM、Qwen 、Deepseek 和（毫无意外排名最末的）Gemini ，它们当中最高分只有 56.1 分。 以最高分的 Claude Opus 5 为例，在 Accio Work 执行框架中的通过率（66/107） ，要比 OpenClaw 上（60/107）和 PI （65/107）上的通过率更都要高，整体来看 Accio 框架对多数模型的性能增益都更明显。 执行框架来自阿里旗下Accio Work ，是全球首个聚焦于电商领域的 AI Agent，目标是帮商家在一个 AI 工作台上统一管理、自动操作、快速分析多个平台的店铺，降低门槛、提升效率，实现生意的增长。 RealReplicaBench 正是脱胎于 Accio Work 的技术团队，他们观察到，靠做题是看不出模型解决问题的真实能力的，尤其是在电商中，工作繁琐而具体：采购要从邮件和报价里确认信息，发品要处理图片、价格、物流和后台状态，经营分析要跨多个平台比对数据…… 为了把货品准确无误地交到你手上，AI 已经卯足了劲，却未必做得够好， 因为真实世界里的工作，很少是一连串彼此孤立的问题。 看似考做题，实则考「上岗」 如果只看分数，RealReplicaBench 的结果很容易引发误读：「怎么 AI 都不太行」。但摸着良心说，还真不能怪模型们不够强，这个结果很难简单归咎于模型能力——这套「题」，确实难。 传统 Benchmark 关注答对多少题、完成多少步骤，就获得对应的分数。类似于考高考，数学最后一道大题不会做，写个「解」字或把条件抄一下，也能拿点儿分。 可是当 AI 真正进入商业工作流以后，用户需要的不是一份过程尽力的答卷，而是一项项真正完成、且能够继续向下流转的工作。 对于「完成」的坚持，构成了 Accio Work 团队技术哲学的核心 ，这源于他们长期沉浸在电商场景里形成的判断，电商工作需要把判断转成行动，再让新的业务状态成为下一步行动的依据。 供应商有没有选对，决定后面的采购动作；价格有没有算对，决定商品能不能正常发布；物流路线是否满足时限，决定订舱有没有实际意义……前面的一次错误，可能沿着整个工作流一路传递到最后。 因此，重要的不只是某一步「做对了」，更在于每一步的判断和行动，能不能被完整串起来。 RealReplicaBench 对「完成」的定义也由此变得接近真实交付： 一项工作只有在结果能够被下一环节直接接手时，才算真正完成。 技术负责人解释道，「哪怕一个任务已经完成了 80%，如果最后还留下 20% 需要用户手动处理，而这 20% 恰恰可能是最关键的部分，那么对用户来说，它依然没有形成可以直接使用的交付。」 基于这一点，在 RealReplicaBench 的测评中， 不存在「将就」；没有完成，就是 0 分 。 如果一定要找一个更直观的比喻，传统 Benchmark 更像考交规，科目一，而 RealReplicaBench 更像路考。脑袋里知道什么时候该打转向灯是一回事，真正把车从起点安全开到终点又是另一回事。就算每一次转向灯都打对了，最后撞车了，也不能称作是合格的司机。 那么问题也随之而来，这种高完成度的表现，究竟要怎么被做成一套可重复、可验证的评测 benchmark？ 为了测试「真实工作」，先造一个接近真实的世界 任何 Benchmark 都绕不开一个最基础的问题：它测到的，究竟是不是它想要测的东西。 如果目标是判断 Agent 能不能完成真实商业任务，那么只把一个真实需求改写成几段文字，再让模型输出答案，显然还不够。难点往往藏在那些被文字省略掉的地方：页面状态会变化，历史信息和新信息会冲突，系统之间的字段并不统一…… RealReplicaBench 的做法，是尽可能把这些复杂性搬到测试环境中，它不只提供题面，还复刻了前端 UI、浏览器操作、CLI、API/MCP、文件系统以及后台状态，让 Agent 面对的不是一张纸上的问题，而是一套能够被真正操作的业务环境。 供应商采购任务就是一个典型例子。Agent 需要从约 300 封高噪声邮件中还原真实采购需求，还要完成供应商选择、邮件标签、回复草稿和 Kickoff 日历。 它测试的显然不再是「能否总结邮件」，而是能不能从一堆真实形态的噪声中还原业务事实，并把这个事实继续变成行动。 另一个更复杂的任务，则要求 Agent 把 5383 条海关记录变成一套跨系统采购控制塔。模型要先按品类和供应商聚合数据，再根据采购政策筛选 Top 3 供应商，随后分别在 Google Workspace、Box 和 Jira 中建立 Dashboard、证据文件夹和项目任务。 这类任务之所以可以作为考题，都在于它们保留了真实工作里一个很关键的特征： 状态会不断变化，而 Agent 必须在变化中仍然准确理解上下文，并随之校准。 前面筛出来的供应商、后面创建的文件夹和 Jira Task，必须属于同一套业务关系。否则，一个动态 ID 写错，后面的交接和审计就可能全部失效。 因此，RealReplicaBench 所测试的，并不是模型在某一个单独的问题上能达到多高的正确率，这不符合他们的技术哲学， 关键要看它能不能在复杂环境中持续维持正确状态，并把一个业务目标真正推进到结束。 用高仿真环境，证明高完成度 把真实环境复刻出来，还只是第一步，真实工作评测还有另一个容易被忽略的问题：模型可以说「任务已经完成」，而用户却无法确认，或者确认成本很高。 在聊天机器人中这问题不大，Chatbot 要交付的本来就是文本。可 Agent 不一样，它的文本输出只是行动过程中的一部分，因此 RealReplicaBench 的另一个核心设计，是让 Verifier 直接读取最终环境状态，而不是相信 Agent 的自我报告。 例如在物流履约中，Agent 需要为一票从中国到美国的运单枚举可行路线，把海运、拖车、尾程、保险、清关、Bond 和平台费全部计入，排除超过 30 天或港口衔接不成立的方案，再完成海运段 Booking 和 Shipment Verification。最终的验证对象不是一段看起来合理的路线建议，而是实际生成的 Shipment ID。 这套逻辑把「完成」的定义从模型的思维链中拿出来，交还给环境本身。 Listing、Booking、日历、文件关系、动态 ID，这些真实状态共同构成了 Agent 是否完成工作的证据。 既然测评不该对一个只有「长得像答案」的答案给分