CommerceAgentBench：Qwen3.8-Max 的 52.3%，到底测到了什么 (2026)

CommerceAgentBench 的 52.3% 需要连同实验条件一起读：Qwen3.8-Max 在 v1.3.1 的 107 个任务上，由 Accio harness 驱动完成了 56 个任务。Qwen 官方账号把它称为被测开放权重模型中的最高成绩；这个结论适用于 Accio 团队公布的模型集合与评测设置。1 2

Accio 团队在北京时间 2026 年 8 月 31 日 22:08 发布了 CommerceAgentBench，Qwen 官方账号在 2026 年 9 月 1 日 12:21 转发推荐。Accio 的发布信息称，团队从 160 万条对话、20 万条执行轨迹和 2,000 个商业工作流中整理出 107 个端到端任务。3 4

Agent 做完了什么，环境留下了什么

CommerceAgentBench 把 agent 的输出从“回答了一段什么话”改成“多个系统最后变成了什么状态”。任务要求 agent 操作浏览器、原生风格 CLI、API/MCP 接口，或生成文件与文档；验证器随后读取 mock 服务和工作区里的结果，检查业务对象是否真的被创建、修改或保存。2

v1.3.1 共有 107 个任务：53 个 CLI 任务、28 个浏览器任务、16 个文件任务和 10 个 API/MCP 任务。另一种切分方式把任务分成 65 个文本任务、20 个浏览器文本任务和 22 个必须使用视觉的任务。任务界面覆盖产品发布、货运预订、店面主题配置，以及通信协作、业务自动化、采购物流、数据输出、市场社区和网页研究。2 4

这种设计解决了长流程评测里的一个具体问题：中间步骤即使写得很像，业务结果仍然可能没有落地。一个采购任务可以要求 agent 读取邮件、核对供应商、比较报价、保存草稿并创建日历事项；最后的评分依据是这些对象在模拟系统里是否处于正确状态，而不是 agent 是否写出了一份流畅总结。任务的具体工作流来自 Accio 自己的整理，场景代表性仍然需要更多团队复测。2 3

CommerceAgentBench 从业务请求到状态验证的官方评测流水线示意图 — 流程图展示了任务请求、agent 行动、模拟服务状态和最终验证之间的连接；仓库把每次运行的配置、轨迹、验证结果、工件、日志和容器信息保存为可审计输出。2

每个任务都会在一个全新的容器中启动。agent 能看到 task.md 和 workspace，grader、rubric、私有种子、服务实现和 reward record 则由容器外的验证流程管理。任务结束后，host-side verifier 读取输出文件和 mock 服务的最终状态。只有所有必要的 verifier 检查都通过，任务才计入 Pass。六个任务带有 LLM 辅助检查，README 指定 gemini-3.1-pro-preview 作为 judge。2

这个 Pass 定义比“部分完成”更严格，也更容易读错。一个任务完成了大多数步骤，只要有一个必要检查失败，结果仍然是失败。107 个任务的分母因此测量的是端到端全通过率，不是每一步动作的平均正确率。仓库在线排行榜的说明还提供 partial-credit 视图，说明单看 Pass 会压低那些接近完成但未满足全部条件的运行。5

同一个模型，三套驱动层

README 同时给出了 Pi、OpenClaw 和 Accio 三个 harness 的参考结果。Qwen3.8-Max 在三套驱动层上的数据如下：2

Harness	Pass	平均 steps	平均耗时	平均 tokens
Pi	53/107（49.5%）	52.6	13.9 分钟	1.79M
OpenClaw	47/107（43.9%）	47.0	15.0 分钟	2.18M
Accio	56/107（52.3%）	71.2	15.7 分钟	3.39M

steps 是轨迹中的工具调用数，time 是任务平均墙钟时间，tokens 是按不同供应商用量字段归一后的每任务平均 token 数。仓库明确提醒，这三项属于描述性遥测，工具粒度、运行调度和供应商计费口径都不同，不能直接当成标准化效率分数。2

Qwen3.8-Max 在 Accio harness 上比 OpenClaw 多完成 9 个任务，差距达到 8.4 个百分点。这组差异说明 agent 外层驱动会改变结果，但它没有单独测量 harness 代码的贡献。官方排行榜说明写得更窄：OpenClaw 到 Accio 的每个 delta 同时包含 harness 和 provider route 的变化，两侧并未通过完全相同的模型端点访问供应商。5

因此，读者可以确认一件事：Qwen3.8-Max 在这次评测里对驱动层很敏感。读者还需要保留另一件事：9 个任务的差距不能直接解释成“Accio harness 让同一个模型多做了 9 道题”。模型端点、请求适配、推理配置和运行器共同构成了观测到的结果。

52.3% 能证明什么

在 Accio 表格里，Qwen3.8-Max 的 56/107 与 Claude Opus 4.7 并列，低于 Claude Opus 5 的 66/107 和 Claude Opus 4.8 的 59/107。Qwen3.8-Max 在这张表里的意义，是在被测开放权重模型中取得最高 Pass，同时进入整体结果的前列。Qwen 官方账号使用的“开放权重模型中表现最强”与 README 的这一行数据相互对应。1 2

这个分数还说明 CommerceAgentBench 把测量对象放在了状态变更上。一个模型即使能写出完整的操作计划，也可能在权限、工具参数、页面状态或跨系统依赖上失败；CommerceAgentBench 把这些失败留在最终系统状态里。对于产品和工程团队，这种失败记录比一段看起来正确的解释更接近部署风险。

结果的边界同样具体。

评测结果由 Accio 管理的 endpoint 生成。 仓库公开了运行器、任务和验证器，但公开路径要求使用者自行提供模型与 judge 凭证。README 把现有结果称为参考快照，并建议复测时记录模型和供应商端点。2
原始 task-level 结果尚未完全公开。 README 说明，原始任务结果包目前没有公开不可变 URL 或 checksum；公开表格是带结果 ID 的聚合结果，还不是一套可以逐任务下载的独立复现包。2
不同模型使用各自供应商的默认 reasoning effort。 这种设置更接近模型的默认产品形态，却没有把不同模型放到相同推理计算量下比较。2
mock 服务换来了可复现性，也带来了抽象边界。 本地 replica 可以固定接口、状态和验证条件，却无法包含真实 SaaS 的全部 UI 变化、权限配置、网络故障和数据分布。仓库把 Accio harness 标为 reference-only，独立团队仍需自行复测。2 5

这几条边界把“52.3%”限定成一个可复核的陈述：在 v1.3.1 的 107 个固定任务、指定的 Accio harness、对应 provider route、默认 reasoning effort 和 Accio 管理评测端点下，Qwen3.8-Max 完成了 56 个全检查通过的任务。这个陈述足以支持开放权重横向比较，也足以说明完整执行仍然困难；它还不足以推出真实电商系统的成功率。

复测时要把哪些变量锁住

想复测 Qwen3.8-Max 或比较其他模型，至少要把以下字段写进运行记录：

版本与任务集。 固定 v1.3.1、domain_v1_all 和 107 个 task ID。版本变化会改变任务、工作区和 verifier。
Harness 与运行时。 记录 Pi、OpenClaw 或其他驱动层，以及仓库给出的运行时镜像 digest。README 为 OpenClaw 路径提供了固定 digest，便于锁定容器环境。2
模型端点与 judge。 记录具体模型快照、provider route、endpoint class 和 judge 模型。gemini-3.1-pro-preview 只覆盖带 LLM 辅助检查的任务，不能把 judge 名称当成 agent 模型名称。
推理与运行策略。 记录 reasoning effort、重试策略、聚合规则和是否保留跨轮 reasoning。README 特别提醒，Qwen 运行需要在后续 assistant 消息中回放 reasoning_content；丢弃这部分内容会让结果失去可比性。2
先跑一个任务。 仓库要求 Docker 提供 linux/amd64 容器支持、Python 3.11 或更新版本、模型 API key 和 LLM judge API key，并建议先用 --limit 1 做冒烟测试，再运行完整任务集。2

对供应商评估 agent 时，Pass 之外还应该索要失败任务明细、任务版本、harness、provider route、judge、reasoning effort 和平均 token 消耗。只有这些条件同时公开，两个百分比才有比较基础。

CommerceAgentBench 最值得借鉴的部分不是 Qwen3.8-Max 的排名，而是它把“完成工作”变成了可以检查的环境状态。团队如果要评估自己的采购、客服或运营 agent，可以复制受控的业务系统，预先写出最终状态断言，再比较模型和驱动层留下的结果。52.3% 是这套方法在一组商业工作流上的一次测量；方法本身，才是更容易迁移到生产评估中的资产。