在逛多了“大模型榜单”之后，你可能会发现一个现象：很多模型在聊天、写作、数学推理里表现惊艳，可一旦让它去执行“帮我挑一款 200 元以内、今天能发货的礼物，放到购物车”，它就开始顾左右而言他——要么只给推荐理由，要么把商品页信息解析错，要么甚至编造一个不存在的 SKU。
这正是购物类 Agent 评测最难的地方：你要检验的不是“会不会说话”，而是“能不能把事情办成”。最近 Accio 开源 CommerceAgentBench 基准，并在社区公布了一批模型表现，其中最受关注的信息是：在开源权重模型里，Qwen3.8-Max 整体表现最强。
先说结论：这件事值得关注，不是因为又多了一个榜单，而是它把“电商 Agent”这个细分赛道的评测标准往前推了一步。通用 Agent 评测回答不了的问题——商品的真实价格怎么解析、库存和发货承诺怎么校验、加购和结算到底怎么算完成——正是 CommerceAgentBench 这类专业化基准想解决的。
这篇文章不会只做新闻转述。我会从五个层面展开：这个基准到底在测什么；为什么电商 Agent 需要专门评测而不是套问答基准；“开源权重模型整体最强”这句话意味着什么；如果想让自己的 Agent 也跑通类似评测，环境、代码、打分流程该怎么搭；最后给出工程落地时的常见问题和建议。
1. 为什么一个电商 Agent 基准值得认真看
过去一年，Agent 应用层最热闹的方向之一就是“帮用户做决策、做执行”的智能体。购物类 Agent 又是其中天然适合商业化的一类：需求高频、价值可量化、流程边界相对清楚。
但做过的团队都知道，购物 Agent 的实际体验要做到“可用”，远不是一个能聊天的模型加一个商品搜索接口那么简单。真实用户指令往往是这样的：
- “预算 200 元以内的生日礼物，适合送女生。”
- “帮我找一款支持明天到的机械键盘，茶轴优先。”
- “这个手机在另一家店是不是更便宜？如果便宜 50 块以上就换一家买。”
这些指令看起来不难，但放到真实的电商环境里，Agent 要先理解用户约束，再去检索商品、打开详情页、核对价格与库存、考虑发货时间，最后还要安全地执行动作。整个链路里，任何一个环节出错，最后都等于任务失败。
问题在于，多数传统评测只能证明“模型知道怎么回答”，很难证明“模型能在真实环境里按步骤完成任务”。这也是 CommerceAgentBench 这类基准的切入点：它试图把一个购物 Agent 的完整执行过程拆成可重现、可打分、可对比的任务。
对普通开发者来说，它的参考价值有三层：
- 选型价值：如果你要在项目里接入开源权重模型，可以看它们在 Agent 执行链路里的真实排序，而不是只看单轮问答分。
- 工程价值：它展示了电商类 Agent 评测任务应该如何设计，包括环境、动作、约束、打分。
- 行业价值：它推动了“执行能力”而不是“对话能力”成为 Agent 的核心评价维度。
需要提前说明的是，这篇文章的代码与命令属于通用演示，目的是帮你建立评测工程的基本框架，并不代表 Accio 官方仓库的实际实现。真要复现 CommerceAgentBench，请以官方文档为准。
2. CommerceAgentBench 评测的对象：会聊天与会下单是两种能力
“Accio”这个名字取得很聪明。在《哈利·波特》里，它是“飞来飞去”咒，喊一声就能让远处的物体飞到你手里。AI 购物助手的核心任务恰好接近这个动作：不是给用户一段正确句子，而是把符合要求的商品、价格、库存以及最后的交易结果一步步“召唤”回来。
2.1 Agent、Benchmark、Task 是什么关系
先理清概念。这里的“Agent”指的是能自主调用工具的智能体，它接收一个自然语言目标，在多次交互里决定调用哪些工具、解析什么结果、最终执行什么动作。“Benchmark”是一套可重复运行的评测标准，是多个任务、环境和评分规则的集合。“Task”则是其中最基础的一条条任务，通常包含一条指令、一个初始环境，以及判定成功与否的条件。
一条典型电商 Agent 任务可能长这样：
- 初始状态：一个模拟商城环境，有商品页、搜索页、购物车。
- 用户指令：自然语言描述的购物需求。
- 可用工具：搜索商品、查看详情、加购、结算、返回上一页等。
- 完成条件：用户约束被满足，并且执行到了指定的结束动作。
2.2 一个电商 Agent 需要什么能力
从我接触的同类项目看，电商 Agent 的能力地图通常分五层：
| 能力层 | 要解决的问题 | 评测时重点观察 |
|---|---|---|
| 指令解析 | 把“预算200以内送女生礼物”拆成可执行条件 | 是否遗漏预算、对象、时间等限制 |
| 商品检索 | 在商品列表里找到候选商品 | 是否用了合理的关键词与筛选条件 |
| 页面理解 | 从详情页读出价格、库存、发货承诺 | 是否把“满减价”与“原价”搞混 |
| 决策规划 | 在多步搜索、对比后做出选择 | 是否在信息不足时反复横跳 |
| 交易执行 | 加购、结算、提交订单 | 是否真正走到了指定动作 |
这个分层很重要。它会直接影响评测任务的设计：如果只测“模型最后输出的那段话是否像推荐语”，那很多模型都能过关。但 CommerceAgentBench 这类以执行为导向的评测，会去看模型有没有真正调用加购工具、加购的商品是否满足预算约束、页面解析到的价格是否和用户要求一致。
所以，读它的结果时，别把“Agent 能力强”简单理解成“生成能力强”。能稳定完成电商任务，需要的是指令跟随、工具调用、结构化输出、长上下文利用和结果校验五种能力的组合。
3. 为什么购物类 Agent 不适合只用通用问答基准打分
一个常见的误区是：既然大模型都能做多轮对话，那只要找一个强的推理模型，包装成 Agent 就行。实际踩过坑的人会告诉你，完全不是这么回事。
通用问答基准测的是“正确答案”，比如“下列哪个选项符合描述”。这类题目不依赖网页、不依赖商品详情、不需要执行动作，模型只要在记忆里检索知识就能回答。购物 Agent 却是在一个动态、结构复杂、充满噪音的环境里做多步决策。同样是“给我推荐一款防晒霜”，问答模型可以凭借训练记忆给出一段漂亮文案，但 Agent 必须回答另外几个问题：现在有货吗？价格是多少？有没有运费？能及时发货吗？
后一类问题，模型无法纯粹靠记忆作答，必须去读环境返回的数据。
更深一层的问题是，通用评测往往会“因为生成流畅就给分”，但购物场景里流畅不等于正确。一个模型完全可以写出一句话：“我推荐 A 商品，它定价 189 元，满足你的 200 元预算。”可如果它看到的真实页面显示价格是 259 元，那这句话就是幻觉。再往下，如果模型把一个“已下架”的商品推荐出去，那它在真实场景里造成的不是丢分，而是用户时间与信任的损失。
电商 Agent 评测还要特别注意两个容易被忽视的指标。
第一是约束不违反率。用户说“预算 200 元以内”，Agent 最后推荐了 199 元的商品，表面看成功了；但如果有 18 元运费，最后结算变成 217 元，这算不算完成？在真实购物语境里，这大概率不算。基准设计得好的话，会把这类“隐性越界”单独计分。
第二是“加购”和“成交”要分开。一个只会把商品放进购物车的 Agent，和一个能确认库存、价格并走到结算的 Agent，能力门槛完全不同。如果评测只把“推荐了商品”当成功，模型很容易用“文本层面完成任务”来刷分——这在可执行的购物 Agent 里恰恰是最需要警惕的。
所以，专门的电商 Agent 基准存在的理由很朴素：它在努力测量“用户目标是否真实达成”，而不是“模型解释得是否足够动听”。
4. “开源权重模型整体最强”这句话的分量
围绕 CommerceAgentBench 发布的信息里，讨论最集中的判断是：在开源权重模型中，Qwen3.8-Max 整体表现最强。
读这句话时，先要把“开源权重模型”和“开源模型”区分开。开源权重通常意味着模型参数文件公开可下载，使用者可以自托管推理，但训练数据、完整训练代码不一定公开，商用许可也各有条款。是否允许商用、是否需要额外授权，要以后续具体协议为准。
那“在开源权重模型中整体最强”到底意味着什么？我觉得要从三个维度理解。
一是能力边界。Agent 评测的复合性很强，不是单点能力突出就能拿总冠军。一个模型想排名靠前，必须同时在指令理解、工具调用格式、多轮上下文一致性、最终决策上都不拉胯。能从整体维度跑赢其他开源权重模型，说明 Qwen3.8-Max 在这些能力的综合表现上取得了相对优势。
二是落地含义。开源权重模型能进前排，对开发者是实打实的好消息。电商类 Agent 经常要处理商家商品库、用户行为等带有敏感性的数据，很多团队并不愿意把所有请求都送到外部 API。如果能自托管一个开源权重模型，并且它在执行类任务上不掉队，那意味着“性能”和“可控性”不再必须二选一。
三是需要冷静的部分。“整体最强”是相对排名，不等于在所有子任务里都最强。某个模型可能在中文长尾商品识别上更好，另一个可能在英文结算流程里更稳。你在实际项目中选型，还是要拿自己的任务子集做验证，不能只看一条总榜。
另外，开源权重模型的 Agent 能力受到部署条件影响很大。同一个模型，用不同推理框架、不同上下文长度、不同工具定义方式去跑，最终结果可能有明显差异。这提醒我们，评测时必须固定推理服务和 prompt 模板，否则很难判断差别的来源。
5. 动手跑这类评测之前：环境与前置条件
如果你也想在自己的项目里搭一套电商 Agent 评测，并不需要一开始就做得很重。一个最小评测工程通常包括四部分：
- 可选模型的推理服务。
- 一个确定性的商城环境快照。
- 一组带指令与约束的评测任务。
- 对执行轨迹的记录与自动打分。
下面用通用命令演示环境准备。要注意，这里不是 Accio 官方仓库的安装步骤，只是一个可参考的模板。版本号请以实际项目为准，不要照抄。
5.1 创建 Python 虚拟环境
python -m venv .venv source .venv/bin/activate pip install -U pip如果你的 Agent 要操作真实网页，通常会用到浏览器自动化工具。下面是 Playwright 的安装示例。
pip install playwright playwright install chromium这里提醒一句：评测环境越接近真实生产，结果越可信，但也会越不稳定。真实商城页面一天一变，会给回归评测带来噪音。入门阶段更推荐先录制一份固定的页面快照，或在本地跑一个模拟商城服务。
5.2 准备推理服务与模型
如果你评测的是开源权重模型，可以先在本地启动一个兼容 OpenAI 协议的推理服务，把地址和密钥写进环境变量。
export LLM_BASE_URL=http://127.0.0.1:8000/v1 export LLM_API_KEY=EMPTY这只是示意。实际部署需要根据模型情况配置显存、并发和上下文长度，不同推理框架的启动参数也不一样，请参考对应模型与框架文档。
6. 评测流水线的核心环节拆分
环境准备完之后，评测不是“跑一个脚本看看结果”这么简单。电商 Agent 评测流水线通常要拆成四个环节。
6.1 任务生成与真值定义
先要有一组带有明确约束的任务。比如下面这个任务，核心约束是“预算 200 元以内”“可以今天发货”。
定义任务时，最需要注意的是“可验证”。每一条约束都要能通过结构化的方式判断。比如价格约束不能只看模型输出的自然语言，而要去查它最终加购的商品详情里，结构化价格字段到底是多少。如果评测任务本身不可验证，后面所有分数都会失去意义。
6.2 模型与环境交互
评测脚本把用户指令发给模型，模型决定调用工具，评测脚本执行工具后把结果返回给模型。如此多轮，直到模型输出最终回复或触发终止条件。
这一环节最容易出的问题是“工具返回结果不结构化”。如果直接把整个 HTML 塞给模型，模型往往会在长篇文本里看漏价格或发货字段。更稳的方案是在工具层做一次抽取，返回 JSON。
6.3 过程日志与最终打分
评测真正有价值的部分在于“过程可回放”。每一轮模型回复、每一次工具调用、每个商品的价格与库存状态，都应该记成 JSONL 日志。最后打分时，不仅看 Agent 是否执行了加购动作，还要回放日志，检查动作对应的商品是否真的满足所有约束。
这也是评测与普通对话测试最大的差异：对话测试关心“说了什么”，Agent 评测关心“做了什么、做对没有”。
7. 最小示例：从任务定义到执行与打分
下面用一套极简代码演示电商 Agent 评测的基本结构。再次强调，这是为了讲清链路而写的演示模板，不是 Accio 官方实现，也不保证所有细节都和官方一致。
7.1 定义一条评测任务
文件：tasks/demo_task.json
{ "task_id": "gift_budget_v1", "instruction": "帮我找一个预算 200 元以内、适合送女生的生日礼物，最好今天能发货。找到后把商品加入购物车。", "environment": "demo_mall_snapshot_v1", "constraints": [ { "type": "price_lte", "value": 200, "currency": "CNY" }, { "type": "ship_mark", "value": "today" } ], "finish_action": "add_to_cart" }这里的约束设计很关键。我不建议把约束只放在自然语言指令里，因为自然语言需要二次解析，会引入不确定性。把关键约束结构化后，打分阶段就能用代码直接判断 Agent 的选择是否合规。
7.2 模型调用与工具执行循环
文件：eval_runner.py下面代码是一个“模型调用 + 工具执行”的骨架。真正评测时，execute_tool需要连接你自己的商城快照环境，并返回结构化结果。
# eval_runner.py # 演示用模板：需要根据你的实际评测环境补齐 execute_tool 的实现 import json import os from openai import OpenAI client = OpenAI( api_key=os.getenv("LLM_API_KEY", "EMPTY"), base_url=os.getenv("LLM_BASE_URL", "http://127.0.0.1:8000/v1"), ) TOOLS = [ { "type": "function", "function": { "name": "search_product", "description": "根据关键词搜索商品，返回商品列表。", "parameters": { "type": "object", "properties": { "keyword": {"type": "string", "description": "搜索关键词"} }, "required": ["keyword"] } } }, { "type": "function", "function": { "name": "get_product_detail", "description": "获取商品详情，包括价格、库存、发货信息。", "parameters": { "type": "object", "properties": { "product_id": {"type": "string"} }, "required": ["product_id"] } } }, { "type": "function", "function": { "name": "add_to_cart", "description": "把指定商品加入购物车。", "parameters": { "type": "object", "properties": { "product_id": {"type": "string"}, "quantity": {"type": "integer", "minimum": 1} }, "required": ["product_id"] } } } ] def execute_tool(name: str, args: dict, env: dict): # 真实评测时，这里要连接沙箱商城或页面快照， # 并返回结构化的商品数据，而不是把整段 HTML 丢给模型。 if name == "search_product": return env["catalog"].search(args.get("keyword", "")) if name == "get_product_detail": return env["catalog"].detail(args.get("product_id", "")) if name == "add_to_cart": return {"ok": True, "product_id": args.get("product_id")} return {"error": "unknown_tool"} def run_one_task(task: dict) -> dict: # 按 env_id 加载一个确定性的商城快照 env = __import__("catalog_snapshot").load(task["environment"]) messages = [{"role": "user", "content": task["instruction"]}] trace = [] for step in range(20): resp = client.chat.completions.create( # 部署时可替换成你要评测的开源权重模型ID model="qwen3.8-max", messages=messages, tools=TOOLS, tool_choice="auto", ) msg = resp.choices[0].message messages.append(msg) trace.append({ "step": step, "role": "assistant", "content": msg.content, "tool_calls": msg.tool_calls and [c.model_dump() for c in msg.tool_calls], }) if not msg.tool_calls: return { "task_id": task["task_id"], "status": "finished", "trace": trace, } for call in msg.tool_calls: fn_name = call.function.name fn_args = json.loads(call.function.arguments) result = execute_tool(fn_name, fn_args, env) messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False), }) trace.append({ "step": step, "tool": fn_name, "args": fn_args, "result": result, }) return { "task_id": task["task_id"], "status": "max_step", "trace": trace, }这段代码想表达三个重点。
第一，模型的目标不是直接输出“
