商店已经提供商品搜索工具，却仍可能进不了顾客的候选清单。工具返回了结果，助手也写出一段像样的推荐，但真正符合要求的那一款，可能从头到尾都没出现。商店做过翻译，也不一定容易发现这个问题：一句英文和一句自然中文，可能触发不同的搜索词、语言环境和回退逻辑。
10月21日，Cloudflare 与 Commerce.com 宣布为 BigCommerce 商店接入 WebMCP。对准备做购物助手的小团队来说，这提供了一个具体的检查契机：在增加购物动作之前，先验证商品发现。本实验只回答一个问题：在团队打算上线的英文和中文购物体验中，走工具路径还能不能找到符合全部要求的商品款式？
下文是建议实验方案，并非已经完成的接入复盘。本文没有测试真实商店、浏览器 Agent 或付费模型。商品目录、运行次数、预算和决策规则都由作者为实验设计，供团队按实际情况调整。它们可以帮助定位值得修复的故障，不能证明转化提升，也不能用来给当下的购物 Agent 排名。
1. 先区分平台已接入与自己的商店已可用
Cloudflare 的公告介绍了面向 Commerce.com 近十万个域名的边缘接入，以及商户单独退出的机制。原文也明确说明，WebMCP 仍是处于早期预览的实验性浏览器标准提案，需要测试旗标、Origin Trial 或部分支持它的 Agent 环境。平台级接入不代表每位访客的浏览器都兼容，更不代表每家店都已经暴露购物工具。
Commerce.com 的公告描述的是在商户自己的店内搜索商品、准备购物车，并在商店页面完成结账。这是一手发布方对预期流程的说明，不是独立检索质量证据。本实验到候选商品清单就结束，不涉及购物车写入或购买授权。
还需要核对一个配置差别。BigCommerce 的 WebMCP 文档说明，符合条件的商店可以启用桥接脚本，但购物工具需要先开启服务端 Storefront MCP。只看到默认图片工具，不能算已经验证商品搜索。要在准备测试的具体店面和会话里查看实际注册的工具列表，保存搜索、商品详情工具的 schema、说明文字和检查时间。
同时记录浏览器版本、Agent 版本、模型、店面渠道、会话类型和启用的语言。Chrome 文档介绍了 Origin Trial 和本地测试旗标，也指出客户端需要访问网站，才能发现网站提供的工具。因此，本文检查的是进入某家商店之后的商品发现，不是通用助手会不会从整个互联网里主动选择这家商店。
2. 把发现工具、检索商品和给出推荐拆开
WebMCP 让网页向 Agent 提供结构化函数。项目原始说明介绍了带描述和 schema 的 JavaScript 工具，以及它们如何与页面当前上下文协作。这种结构有助于明确交互方式，却不会自动判断某个商品是否满足顾客需求。
实验里使用三个不同概念。工具发现，指预期的可调用工具确实存在；检索，指搜索路径返回了候选商品；推荐，指 Agent 选择某个商品或具体款式，并把它描述成符合要求的选项。三者可能出现分歧：符合条件的候选被检索到了，却被错误舍弃；搜索找到了父商品，却没有找到合格款式；不合格的商品被自信地推荐了出来。
这里的合格款式，是指在冻结的购物上下文中满足全部明确硬性要求的商品记录。漏检，是明明存在合格款式，最终清单却没有推荐任何一个。错误匹配推荐，则是把违反某项硬性要求的款式说成符合需求。一份回答可以既包含正确建议，又包含错误推荐，两件事必须分别记账。
商店原有的可视化搜索只是对照路径，不是标准答案，它也可能漏商品。标准答案要来自独立核对过的商品目录快照。两条路径也不必给出完全相同的排序：多个商品都可能合理。需要验证的是，在相同顾客约束下，每条路径能否给出有证据支持的候选清单。
3. 先做一个答案可以查清的小目录
假设有一家虚构的双语包袋商店 Northline。它的预发布店面有30个可售款式，分布在双肩包、托特包和收纳包中。每个款式都有稳定 ID、父商品 ID、SKU、颜色、容量、价格和库存状态；涉及兼容性时，还需要明确的属性说明。英文名和中文名描述的是同一批商品。这是建议使用的测试目录，不是真实商户，也不代表平台默认会提供这样的数据。
例如，英文请求是“Find a black commuter backpack, at most USD 80, with a listed 14-inch laptop compartment.” 对应中文可以写成“找一款黑色通勤背包，价格不超过80美元，并且商品资料明确支持14英寸笔记本。”让双语审查者确认两句要求等价，而不是强求语序相同。货币和预算必须一致，把美元改成人民币就已经换了任务。
假设合成记录 N14-B 售价76美元，满足全部要求；N14-G 是灰色，N16-B 售价92美元，N12-B 没有明确的笔记本兼容信息。那么只有 N14-B 合格。父商品文案再吸引人，也不能让灰色款变成黑色款；模型更不能凭图片猜测能否装下笔记本。每个案例都应建立这样清楚的记录。
运行 Agent 之前，请第二个人根据商品导出表，为每条需求列出全部合格款式 ID，再与预发布页面中的商品详情核对。先解决分歧，再冻结答案。Agent 只能看到普通顾客能看到的资料，不能拿到答案清单。英文和中文目录、可售状态、价格、店面渠道分配都要保留不可变副本。如果对照过程中有数据变化，应作废受影响的配对；重新冻结后，两条路径都重跑。
4. 用双语需求检查搜索契约里的薄弱处
准备24条信息需求，每条分别写成自然英文和中文。其中20条至少有一个合格款式，4条确实没有匹配项。下面六类各占四条。这个规模用于组织排错工作，不代表真实顾客的统计分布。
| 类别 | 四条案例分别变化什么 | 标准答案需要确认什么 |
|---|---|---|
| 精确商品身份 | 商品名、型号、翻译后的名称 | 展示名不同，仍能对应正确 ID |
| 多条件筛选 | 颜色、明确容量、预算 | 必须同时满足所有条件 |
| 简短品类请求 | 较短的中文品类词及英文等价表达 | 搜索词改写是否仍保留原意 |
| 款式区分 | 同一父商品下合格与不合格的款式 | 具体款式正确，而非父商品看起来相似 |
| 较深位置的候选 | 合格商品不在初始结果页 | 有限搜索能否到达合格项 |
| 确实无匹配项 | 不存在的条件组合及接近的替代品 | 不虚构符合条件的选项 |
当前契约里有一个很适合核验的细节。B2C MCP 参考文档列出的必填 term 至少需要三个字符，还提供分页用的可选 cursor；商品详情可返回款式和 SKU。“背包”只有两个汉字，因此短词值得放进诊断集。但这不等于已经证明运行中的服务会拒绝中文：实际 schema、校验方式、字符计数逻辑，以及 Agent 怎样改写，都需要查看。
不要为了通过校验给搜索词乱加字符，也不要悄悄把所有请求先翻成英文。如果 Agent 把“背包”改为“通勤背包”，要记录它增加了“通勤”约束。如果改成另一种有效等价说法，也要保留实际词语，让双语审查者判断意思有没有变化。调用时以当前注册的 schema 为准，不要照抄发布公告里的示意参数。B2C 参考文档没有为 search_products 列出专门的价格或尺码输入。
“较深候选”这一类，需要先用诊断检索确认相关商品的位置，随后再冻结案例。如果某条路径没有稳定分页能力，就如实记录，不要声称存在第四页。合格项也必须在后续规定的三次搜索操作内可达；初始页加一到两次翻页就够了。如果30个款式在所有相关查询中都只有一页，就先标记这一类暂时无法测试，重做目录后再评分，不能把单页查询算成分页实验。诊断调用与正式 Agent 会话分开保存，也不要把诊断找到的成功搜索词透露给 Agent。
5. 对照四种条件，不能偷偷混用路径
将两种语言体验与两条交互路径交叉，得到英文／页面、英文／WebMCP、中文／页面、中文／WebMCP 四种条件。这里的“语言体验”同时包括请求语言和计划使用的店面 locale，也就是应用所采用的语言及地区设置。实验可以比较每种语言体验内部的路径差异；英文和中文之间的差别，却不能单独归因为翻译、locale 配置或模型语言能力。这些原因要靠后续干预拆开。
页面条件使用同一个 Agent，通过可视化店面操作，并禁用 WebMCP 调用。工具条件只允许注册的只读搜索和详情工具，禁止通过页面搜索，也禁止改购物车。两种条件都可以打开初始商店页面。测试环境必须能执行并记录这些限制。若某次运行越过了限制，即使清单正确，也要标记为混合路径，并在原分配路径的主要比较中记为未成功。单靠口头提示，不能算证明限制得到遵守。如果测试环境根本不能约束或观察路径，就停止路径对照实验；所得结果只能描述混合路径产品。
固定模型版本、推理设置、公开访客身份、货币、库存快照和输出要求。请 Agent 最多给出三个合格款式，附稳定商品链接或 ID，并说明每项硬性要求的依据。找不到时，应说明“在本次有限搜索中未找到”，不要强迫它断言整家店都不存在合适商品。
初始预算可以设为每次会话120秒、最多三次搜索提交或结果翻页、最多六次商品详情查看。首次搜索计一次，每次翻页也计一次；页面和工具条件使用相同计数，同时另记全部交互步骤。这是作者为有限购物过程选择的预算，不是纯后端检索算法对比，也不代表消耗了相同 token 数。
每条信息需求在每种条件下，用新会话重复两次：24条 × 2种语言 × 2条路径 × 2次重复，共 192次会话。在每个案例块内打乱条件顺序，交替安排哪条路径先跑。不能把聊天历史、搜索提示或上一轮候选 ID 带进下一轮。重复运行检查的是同一需求的稳定性，不是又增加了一位独立顾客。
6. 先看实际语言环境，再决定是否改模型
中文提示词不等于中文商品上下文。BigCommerce 的多语言 API 指南区分“已启用语言”和“实际解析出的语言”，说明偏好设置的优先级，也说明缺少本地化商品数据时会回退到全局数据。这些是可以在相应接口中检查的 GraphQL 行为，不能据此断言每个 MCP 桥接层都有相同的控制参数或诊断字段。
分面与文本搜索文档又单独说明了依赖语言环境的检索、目录刷新要求和筛选前提，并将多语言搜索的可用范围限定在 Storefront GraphQL API。不要从这一页推导 WebMCP 全流程保证支持某种语言。这些说明只是提供了关于目录状态、搜索配置的诊断假设，仍要在商户实际路径上确认。
每次正式运行都保存请求的 locale、页面上选择的语言、相关会话偏好，以及应用实际暴露的语言解析证据。Cookie 和令牌必须脱敏。无法观察时直接写“未知”。出现中文商品名，只能帮助确认展示内容，不能证明后端具体索引了哪些字段。
评分后，再逐层诊断失败配对。先看预期工具是否存在，再对照实际查询、分页行为、候选 ID、详情证据和最终清单。如果工具已经返回合格项，而 Agent 把它忽略了，改翻译未必有用。如果两条路径都检索不到一个标签明确且翻译正确的商品，就应先查目录发布或索引，再考虑改提示词。
后续只改一层。例如，在请求和目录不变的情况下，提供已经核验的 locale 设置。保留最初失败记录。修复后的成功只能说明，这个干预在该配置下帮助了某个案例，不能倒过来把原始运行改成通过。
7. 配对比较必须保留明确的分母
先依据款式 ID 和硬性要求评分，再看文案是否好读。对有匹配项的案例，计算覆盖率：最终清单中至少出现一个合格款式的会话数，除以全部有匹配项的会话数。主要统计采用“按原分配条件统计”的原则：超时、错误调用、工具缺失和混合路径越界都留在原条件的分母里，不能计为覆盖成功。每条路径、每种语言的分母都是20条需求 × 2次重复，即40次。还要报告20条需求中，有多少条两次都成功，避免一次碰巧成功掩盖不稳定。
另算错误匹配推荐会话的比例：只要某次会话把一个不合格款式说成满足需求，就计入分子；分母是该路径与语言条件下的全部48次会话。替代品明确标注“超过预算”，不算错误匹配；把它说成符合80美元上限，才算。即便 ID 本身合格，凭空添加属性仍是独立的顾客体验缺陷，需要另记。
四条确实无匹配项的需求，在每个条件下共有八次会话。分别报告虚构匹配项的次数、诚实说明有限搜索结果的次数，以及运行故障。超时或混合路径不能算成功判断“无匹配”。只要仍能观察到输出，即便运行故障，也应保留错误推荐和无依据描述的标记。全部分配运行及其失败原因都要报告，不能靠删掉失败来提高覆盖率。
按“案例＋语言体验＋重复轮次”配对比较两条路径。每种语言的表格都保留全部40组有匹配项的配对，统计两者都成功、只有工具成功、只有页面成功、两者都未成功。混合路径或故障的一方，记为未成功。如果另外提供“仅合规运行”的诊断分析，要单独命名；只要任一方越界，就从诊断配对表里排除整组，并明确缩小后的分母，不能用它替代主要比较。
举一个虚构算例：某种语言的40组配对中，八组只有工具成功，三组只有页面成功，净差为五组，即12.5个百分点。但仍需一起查看错误推荐和故障分布。这不能证明工具在总体顾客中更优，也不能证明另一种语言受到某个因素的因果影响。
经典检索评估会区分固定结果深度下的精确率和召回率，斯坦福信息检索教材解释了这种区别。这里特意选择“至少找到一个合格选项”作为购物任务指标，它不是完整目录召回率。如果团队需要召回率，就必须列出全部相关项，并事先声明检查多深的结果。前三项清单完全一致，不是本实验的成功标准。
8. 用一张发现记录表，让下一次修复有据可查
每次会话一行，另建案例文件，保存双语请求与冻结的合格 ID 集合。下面这张表就是可复用交付物。原始轨迹放在受访问控制的附件里，共享表格不能含凭据或真实顾客资料。
| 字段 | 应保存什么 |
|---|---|
| 案例与配对键 | 需求 ID、语言体验、路径、重复轮次、块内顺序 |
| 冻结标准答案 | 目录版本、合格款式 ID、硬性要求 |
| 运行环境 | 浏览器、Agent、模型、配置、测试环境的路径限制 |
| 会话上下文 | 店面渠道、访客身份、货币、请求／实际 locale 或未知 |
| 工具可用情况 | 已注册的只读工具名与 schema 快照 |
| 搜索过程 | 实际词语、确实使用的筛选、cursor 或页面翻页 |
| 候选证据 | 返回 ID、查看过的详情及时间戳 |
| 最终清单 | 推荐款式 ID、链接、声称满足要求的依据 |
| 预算消耗 | 搜索／详情次数、耗时、超时或其他结束原因 |
| 结果标签 | 覆盖、错误匹配、无依据描述、运行故障 |
| 人工裁定 | 审查者、分歧、基于证据的最终标签 |
| 后续修复 | 怀疑的层次、单项变更、新确认案例 ID |
条件允许时，让审查者在不知道路径标签的情况下检查 ID 和属性证据。再由双语审查者独立判断请求是否等价、改写是否改变含义。不能把同一个模型的自信解释当作商品目录的权威。证据不足时，记录待裁定状态，按未经验证处理，不能算成功；上线前必须解决。
这张表应该能导向具体行动。“中文搜索不好”没有指出该改什么。“两个字的请求被改成更窄的词；合格托特包没进入候选；商品详情从未被查看”，则提供了可以逐一核验的环节。不过，在完成下一次受控检查之前，这仍不等于已经查明根因。
9. 根据证据选择修复，再用新案例确认
看结果之前先定好产品的停止规则。对于这个小型商品发现试验，可以考虑要求：错误匹配为零、关键属性的无依据描述为零、未裁定案例为零；修复后，原本通过的需求不能倒退。覆盖率和重复稳定性的具体门槛由商户事先选择，不是本文提供一个放之四海皆准的阈值。发现一个缺陷，可以先暂停受影响的范围，不必立刻对整个平台下结论。
修复要对应证据所在层次。工具缺失，先查接入设置；locale 错误，修上下文；翻译字段缺失，修目录；候选正确而清单错误，检查约束判断。预算耗尽，需要另做预算实验；只给工具路径延长时间，就破坏了原来的比较。调用中出现 schema 不支持的参数，则应核对当前定义与 Agent 指令。
修复后，先重跑受影响的原始案例块，作为回归检查，再创建12条新需求：六类各两条，其中最后一类贡献两条无匹配需求。运行之前重新审查双语表达和标准答案，然后按相同的四种条件、每种两次重复执行，增加 96次确认会话。发现阶段和确认阶段分开报告。如果确认集又出现缺陷，就修改后重新准备未见过的保留集，不要围着同样的12个答案反复调参。
这是一组可控的离线工作量，不是要求小商店复现研究基准。如果团队承担不起192次发现会话，可以减少案例块，但每个案例仍要完整配对，并把结论标注为探索性结果。保留全部四种条件，报告缩小后的分母。为赶上线日期而删掉难处理的中文请求，已经改变了产品准备承诺的能力范围。
10. 上线范围要与能够支持的语言体验一致
实验应当改变一个发布决定。团队可能先为资料清楚的品类提供只读助手，补齐中文商品字段，或者在工具路径修复期间继续以可视化搜索为主。也可能发现，两条路径都能取回正确商品，真正的问题是助手描述错了款式属性。此时需要的是推荐校验，而不是庆祝 WebMCP 接入完成。
这套方案适合能控制商品目录、正在提供双语购物体验的小团队。它不覆盖开放互联网购物、B2B 议价、按客户变化的可见商品范围、受监管商品建议、结账同意、付款或履约。这些问题要在各自上下文中另测。公开访客会话通过，不能宣传成对登录买家也同样有效，因为后者的商品权限和价格可能不同。
两种语言体验的捆绑设计也留下了明确未知项：实验不能拆分提示词语言与店面 locale 各自的影响，不测真实需求分布，也不能建立转化或留存结论。更广泛的主张需要更大、也更有代表性的研究。未来进入真实试点时，应在恰当的同意与测量安排下，独立观察合格商品发现、用户纠正和放弃行为。
今天就能做的改变更具体：把“Agent 已就绪”落实为一条从自然顾客需求通往合格款式、且经过验证的路径。从实际注册的工具契约开始，保留每种语言自己的失败，再修复证据指向的环节。搜索工具能够被调用，只是这项工作的起点。
参考资料
- Cloudflare，How Commerce.com and Cloudflare are getting storefronts ready for AI agents，2026年10月21日。
- Commerce.com，Commerce and Cloudflare bring AI shopping assistants to BigCommerce merchants，2026年10月21日。
- Chrome for Developers，WebMCP，2026年10月22日查阅当前文档。
- Web Machine Learning Community Group，WebMCP 项目说明与提案仓库，2026年10月22日查阅。
- BigCommerce，WebMCP，2026年10月22日查阅当前接入说明。
- BigCommerce，B2C Storefront MCP 参考文档，2026年10月22日查阅。
- BigCommerce，GraphQL Storefront API 多语言支持，2026年10月22日查阅。
- BigCommerce，GraphQL Storefront API 分面与文本搜索，2026年10月22日查阅。
- Manning、Raghavan、Schütze，排序检索结果的评估，《Introduction to Information Retrieval》。