EComAgentBench：面向长周期任务与分布式隐藏意图的购物代理基准测试

# EComAgentBench: Benchmarking Shopping Agents on Long-Horizon Tasks with Distributed Hidden Intent
来源：https://arxiv.org/html/2606.17698
Zeyao Du, Tong Li, Haibo Zhang Shopee \{zeyao\.du,litonglt,peter\.wu\}@shopee\.com

###### 摘要

随着基于LLM的购物代理进入生产环境，现有基准测试未能捕捉到购物者需求出现的方式：这些需求可能在查询中隐含说明，记录在用户资料中，或仅在提出正确问题时才显露。那些一开始就暴露全部意图、仅对最终选择进行评分的基准测试，既无法提出这种长周期挑战，也无法解释购物代理遗漏了哪个需求。为填补这一空白，我们引入了EComAgentBench，一个基于真实亚马逊产品和评论的662个任务的基准测试。每个任务将这些需求分散到可见查询、工具门控的资料和脚本化的澄清中；代理必须揭示隐藏意图，根据属性和评论证据验证候选产品，并在100次工具调用内确定一个产品。此外，带有类型和来源标记的评分项目对每个任务进行评分，将每次失败归因于一个需求及其来源。构建过程自动化且可靠，每个答案在生成任何文本之前已在代码中固定，每个样本都经过验证。我们对七个模型的评估显示，即使最强的模型也仅达到57.1%的整体准确率，且评分满意度从可见来源向隐藏来源递减。总体而言，我们相信EComAgentBench将为将购物代理从单次查询搜索转向长期可靠的辅助提供可复现的基础。

EComAgentBench: Benchmarking Shopping Agents on Long-Horizon Tasks with Distributed Hidden Intent

Zeyao Du, Tong Li, Haibo Zhang††thanks:通讯作者。 Shopee \{zeyao\.du,litonglt,peter\.wu\}@shopee\.com

## 1 引言

电子商务购物代理正从单次查询的产品查找转向通过多工具步骤为购物者提供服务的助手。因此，为部署选择模型需要一个基准测试，该基准测试能够区分模型、解释每个模型失败的原因，并反映购物请求实际到达的方式，同时其构建和评分足够可靠，以信任由此产生的排名。先前的购物和Web代理基准测试已经表明，现实评估是一个关于工具和部分信息的长周期交互问题，而非单次问答（Yao等人，2022 (https://arxiv.org/html/2606.17698#bib.bib5)；Deng等人，2023 (https://arxiv.org/html/2606.17698#bib.bib6)；Zhou等人，2023 (https://arxiv.org/html/2606.17698#bib.bib7)；Yoran等人，2024 (https://arxiv.org/html/2606.17698#bib.bib9)）。

我们识别出当前购物代理评估中的三个弱点，每个都促使了我们的一项贡献。（i）粗粒度的非诊断性评分：先前的购物基准测试仅通过精确产品匹配或与目标特征的重叠来对答案进行评分（Yao等人，2022 (https://arxiv.org/html/2606.17698#bib.bib5)；Wang等人，2026a (https://arxiv.org/html/2606.17698#bib.bib1)）。这样的评分无法说明一个多步骤任务中遗漏了哪个需求，也无法说明需求来源：是来自查询、资料，还是后续问题。（ii）隐藏意图很少：真实的购物者会隐晦地陈述一些需求，将另一些保留在资料中，还有一些仅在询问时才提及。然而，大多数基准测试将所有需求放在初始查询中，使得长轨迹中没有什么新发现；少数具有个性化的基准测试直接暴露资料或模拟用户。（iii）构建不可靠：长周期任务编写成本高，评分噪声大。现有基准测试各自至少省略了验证、自动化或真实产品中的一项；许多还模拟用户或让评判者不受约束，增加了与被测试能力正交的方差。

为解决所有这三个问题，我们提出了EComAgentBench，一个基于真实Amazon Reviews 2023目录（Hou等人，2024 (https://arxiv.org/html/2606.17698#bib.bib14)）的单产品购物基准测试，它将每个购物者的需求分散到三个来源：一个*可见查询*，仅隐晦地说明某些需求；一个*隐藏角色*，仅通过`get_user_profile`工具读取；以及*隐藏澄清*，仅通过向`ask_user`工具提出其识别的问题来获得。由于两个来源位于工具之后，完整意图无法在单一步骤中读取；必须在整个事件中拼凑出来（图1 (https://arxiv.org/html/2606.17698#S3.F1)；工作示例见第3节 (https://arxiv.org/html/2606.17698#S3)）。我们使用称为*评分项*的检查来对每个事件进行评分，每个检查按类型和来源（查询、角色或澄清）标记，因此失败的检查能识别出遗漏了哪个需求以及来自哪里。构建过程自动化且可靠：每个答案在生成任何文本之前已在代码中固定，澄清是脚本化的而非模拟的，并且每个样本都经过多阶段验证。

我们围绕三个问题组织本文，并使用在共享环境和评判者下评估的七个代表性模型的证据来回答每个问题：

- •RQ1：该基准测试能否在长周期任务中区分模型并按需求和来源定位失败？整体准确率范围为19.5%–57.1%，带有类型和来源标记的评分项能精确指出每个模型遗漏了哪些需求及其来源。
- •RQ2：隐藏的分布式意图是否构建了现实的长周期任务？将需求分散到查询、资料和澄清中，反映了购物者表达意图的方式，并且对每个模型来说都一致更难，这隔离了可见查询评估所遗漏的能力。
- •RQ3：长周期评估能否被信任并扩展？构建过程自动化但基于真实目录进行验证，评判者很少出错：它拒绝正确答案最多每个模型一次，并且在独立审计中未接受错误答案；类别无关的流水线通过采样更多产品来扩展，而非重新标注。

简而言之，EComAgentBench展示了如何构建长周期购物任务（隐藏的分布式意图）、诊断其失败（带类型和来源标记的评分项），并保持两者可复现（自动化、经过验证的构建）：这是之前没有购物基准测试提供的组合。

## 2 相关工作

#### 电子商务购物基准测试。

WebShop（Yao等人，2022 (https://arxiv.org/html/2606.17698#bib.bib5)）将代理置于真实购物页面中，但侧重于浏览器交互，而非恢复隐藏需求。近期的购物基准测试在*隐藏的意图*和*构建方式*上有所不同。ShoppingBench（Wang等人，2026a (https://arxiv.org/html/2606.17698#bib.bib1)）基本上将意图保持为查询可见，并自动生成任务但无独立验证；ShopSimulator（Wang等人，2026b (https://arxiv.org/html/2606.17698#bib.bib2)）通过模拟用户增加了个性化，但依赖于昂贵的手动标注；DeepPlanning（Zhang等人，2026 (https://arxiv.org/html/2606.17698#bib.bib4)）提供可验证约束的长周期规划，但基于合成产品而非真实目录。然而，即使在授予部分信用时，也没有一个揭示失败需求的来源。这些差距共同促使了EComAgentBench的出现：一个任务，其意图分散在三个来源中，其中两个位于工具之后，因此恢复它需要长周期；带有类型和来源标记的评分项，将每次失败归因于一个需求及其来源；以及一个同时自动化、经过验证且基于真实亚马逊目录的流水线（表1 (https://arxiv.org/html/2606.17698#S2.T1)）。

- •✓ 支持；∼ 部分支持；✗ 不支持。
- c 分数分解到单个需求；∼ = 分解到产品特征部分或任务检查点。
- • 基准测试：ShoppingBench（Wang等人，2026a (https://arxiv.org/html/2606.17698#bib.bib1)），ShopSimulator（Wang等人，2026b (https://arxiv.org/html/2606.17698#bib.bib2)），DeepPlanning（Zhang等人，2026 (https://arxiv.org/html/2606.17698#bib.bib4)）；VitaBench（美团长猫团队，2025 (https://arxiv.org/html/2606.17698#bib.bib3)）作为评判者设计灵感的来源而非主要比较目标讨论。

表1：EComAgentBench与近期电子商务购物基准测试的对比，按其三个目标分组：解释失败（RQ1）、现实隐藏意图（RQ2）以及可靠自动化构建（RQ3）。EComAgentBench是唯一满足所有三个目标的基准测试；每个先前的基准测试已经在可靠性组中至少缺少一个能力（ShoppingBench没有任务验证，ShopSimulator是手动标注的，DeepPlanning使用合成产品）。
#### Web代理和交互评估。

Mind2Web（Deng等人，2023 (https://arxiv.org/html/2606.17698#bib.bib6)）、WebArena（Zhou等人，2023 (https://arxiv.org/html/2606.17698#bib.bib7)）、VisualWebArena（Koh等人，2024 (https://arxiv.org/html/2606.17698#bib.bib8)）和AssistantBench（Yoran等人，2024 (https://arxiv.org/html/2606.17698#bib.bib9)）表明，真实的代理评估应该捕捉代理如何收集信息和使用其环境，而不仅仅是最终答案；EComAgentBench将这一理念聚焦于购物，其中意图必须从查询、资料和澄清中恢复。

#### 评判者设计和评分项分解。

VitaBench（美团长猫团队，2025 (https://arxiv.org/html/2606.17698#bib.bib3)）开创了基于评分项的复杂代理轨迹分解；我们将这种方法扩展为*带类型和来源标记*的评分项。关于LLM作为评判者的工作支持基于模型的评分，但提醒不要使用无约束的评判者评分（Zheng等人，2023 (https://arxiv.org/html/2606.17698#bib.bib10)；Wang等人，2024 (https://arxiv.org/html/2606.17698#bib.bib11)；Chiang和Lee，2023 (https://arxiv.org/html/2606.17698#bib.bib12)），这促使我们在设计中，评判者的目标在代码中固定并与带类型的评分项相关联，而非留给自由形式的判断。

## 3 任务和环境

我们现在正式定义此任务。EComAgentBench将购物从理解单个查询转变为恢复分散在三个来源的需求，其中两个位于工具之后；代理从用户意图的部分视图开始，必须通过搜索、资料访问和澄清来获取其余部分。隐藏性在两个独立轴上出现：*来源*，当需求位于工具之后（角色、澄清）时；以及*表达*，当可见查询仅隐晦地说明一个需求时。图1 (https://arxiv.org/html/2606.17698#S3.F1) 端到端地展示了其中一个任务，从三个来源经过代理的工具使用，到带来源标记的评分项评分（完整案例见附录C (https://arxiv.org/html/2606.17698#A3)）。

\(a\) 任务：意图隐藏在三个来源中
查询（可见）——隐晦线索：
▶ 连接器 = micro-USB
▶ 安装方式 = 桌面
▶ 评论：“直立或平放”
角色（隐藏 · `get_user_profile`）：
▶ 颜色 = 黑色
▶ 设备 = 智能手机
澄清（隐藏 · `ask_user`）：
▶ 平均评分 ≥ 3.5
▶ 连接方式 = USB

\(b\) 代理如何交互
购物者  代理
Shop 沙盒
`ask_user`/ 回复
动作 / 观察
代理必须*主动*获取资料并询问购物者。
API 沙盒：10个工具，≤100步，一个产品。

\(c\) 带来源标记的类型化评分项评分
推荐产品：B07DJB5F29
查询（8/8）：
▶ `attribute_match` micro-USB ✓
▶ `entity_match` 无线充电器 ✓
▶ `review_opinion` 直立或平放 ✓
角色（2/2）：
▶ `attribute_match` 颜色=黑色 ✓
澄清（2/2）：
▶ `numeric_range` 评分≥3.5 ✓
▶ `attribute_match` USB ✓
正确 = 精确产品匹配 或 所有评分项都满足。

工作示例：gpt-5.4 恢复隐藏意图，然后推荐一个产品（步骤从上到下运行；共32次工具调用）

图1：EComAgentBench 在一个任务（无线充电器）上。顶部：(a) 完整需求分散在三个来源中：带有隐晦线索的可见查询、位于 `get_user_profile` 之后的隐藏角色，以及位于 `ask_user` 之后的隐藏澄清；(b) 代理与购物者和沙盒商店交互以恢复它们；(c) 推荐产品根据由来源标记的类型化评分项进行评分（正确情况是精确产品匹配或完全满足评分项）。底部：恢复过程的简化轨迹。来源颜色（查询蓝色、角色橙色、澄清绿色）跨面板保持一致。
#### 环境。

代理在API沙盒而非浏览器中操作。这将特定于购物的工作（查找信息和检查需求）与网页导航分开，并允许具有固定工具行为的确定性回放。工具集包含10个工具，涵盖目录搜索和检查（搜索、筛选、产品详情、评论证据）、用户交互（资料访问、澄清）以及决策支持（轻量级计算、最终推荐）。每次运行限制为100个工具步骤（每步一次调用）和10次澄清轮次，代理必须通过推荐恰好一个产品来终止。恢复分散的意图需要持续的多步骤获取，使得每个事件成为一个长周期轨迹。

#### 评分项和指标。

评估使用类型化评分项而非单一标签。每个评分项带有一个类型（例如，`attribute_match`、`numeric_range`、`review_opinion`）和一个来源标签（查询、角色、澄清），这六种类型在第4节 (https://arxiv.org/html/2606.17698#S4) 中详细说明。我们的主要指标是准确率：精确产品匹配或完全满足评分项。我们还按来源报告评分项满意度、完成率和工具使用统计。这将购物评估视为检索、资料使用、澄清、评论验证和选择的联合测试。

## 4 基准测试构建

为了填充这个环境，我们从源自Amazon Reviews 2023 (Hou等人，2024 (https://arxiv.org/html/2606.17698#bib.bib14)) 的真实目录中构建了EComAgentBench，该目录包含370万产品和2140万条评论，集中在电子相关类别。有效拆分包含662个样本，涵盖8种意图，从产品搜索和评分质量到优惠券预算和评论驱动购物；在921个生成候选者中，71.9%通过了最终验证（意图定义和按意图统计见附录B (https://arxiv.org/html/2606.17698#A2)）。

#### 受控流水线（RQ3）。

每个样本由七阶段流水线构建（图2 (https://arxiv.org/html/2606.17698#S4.F2)；详情见附录D (https://arxiv.org/html/2606.17698#A4)）。核心设计原则是*正确答案在生成任何文本之前就已固定*。一旦评分项的ID、类型、字段、期望值和来源在代码中设置，后续LLM调用仅将其言语化，不能更改正确性标准：LLM控制表面实现，而非底层需求。让LLM编写评估标准会将其噪声引入真实答案；将其锁定在代码中从源头消除了这种方差。

真实亚马逊目录
采样并提取特征
分成三个来源
编译类型化评分项
实现语言
分层验证
有效拆分
语义在语言之前锁定

图2：构建流水线。EComAgentBench从真实产品目录开始，将需求分散到查询、角色和澄清中，在任何文本编写之前固定类型化、带来源标记的评分项，并在每个样本进入有效拆分之前对其进行验证。
#### 三来源拆分（RQ2）。

提取的特征被拆分为查询可见、角色隐藏和澄清隐藏的需求。