Anthropic 于 2026 年 9 月 2 日发布了 Claude for Commerce 代理蓝图。这是参考代码。不是自动商家注册,不是保证转化率提升,不是证明 Headless 架构排名更高。它是什么:一份详细规范,说明 AI 代理到达你店铺 API 时应该找到什么。如果这些 API 无法清晰地给出答案,代理就会跳过你。这正是这份检查清单要解决的问题。下面你会找到一份目录到结账的准备度矩阵、蓝图实际规范的逐部分覆盖说明,以及分阶段实现计划。
代理从你的店铺需要什么
暂时忘掉用户体验的框架。AI 购物代理不会浏览你的主页。它发送 API 调用、解析结构化数据,做出二元决策:我能在这个店铺上行动,还是不能?
Paladio 的 25 点准备度检查清单很好地框架化了这一点:代理不排序产品,它们筛选产品。失败筛选的产品会无声地从考虑集合中消失。没有错误消息,没有压制通知。你就是不会出现。
所以第一个问题不是"我们如何整合代理?"而是"代理能读取我们已有的东西吗?"三件事立即会破坏这一点:
- 缺失或无效的标识符。没有 GTIN、没有 UPC、没有 EAN 意味着代理无法跨渠道匹配你的产品。品牌筛选返回不完整的结果。
- 模糊的属性。"混合"作为包装尺寸,"变化"作为尺寸。运行合规或定价检查的代理无法继续。
- 仅可人类阅读的页面。如果你的产品数据存在于 CMS 文本而不是结构化 API 响应中,代理要么无法解析,要么推断不正确。
DeepLumen 的定义将无代理准备度定为比 SEO 更广泛、比数据源卫生更广泛、比结账整合更广泛。这是准确的。所有三层都必须同时工作。
对于 Headless 店铺来说,前端和后端之间的架构分离实际上是这里的优势,因为你已经在 API 优先的思路中思考。但作为 Headless 不会自动让你为代理做好准备。API 中仍然需要正确的数据。
Claude 商务蓝图提供了什么
Anthropic 蓝图(2026 年 9 月 2 日)是在 Claude 上构建商务代理的参考代码。它不是插件,不会将你的店铺注册到任何东西中。把它想象成用代码表达的规范文档。
它描述了什么:
- 代理应该如何发现商家的目录,包括它期望找到的数据字段
- 结账流程应该如何以编程方式公开,以便代理可以在没有人工干预的情况下完成交易
- 代理应该如何处理支付委托,特别是有人在场和无人在场购买场景之间的区别
- 应如何将错误、库存变化和结账失败等情况反馈给代理,使其能够响应而不是无声地失败
该蓝图引用的协议仍在演进中。在针对ACP(代理通信协议)、UCP(通用商务协议)、AP2(自主支付协议)和A2A进行开发前,请与各协议所有者核实其当前状态。这里引用的研究资料涉及这些协议,但它们的生产就绪状态和确切规范可能会变化。
蓝图明确指出的一点是:合作伙伴对参考实现结果的报告并不能证明你的店铺也会看到相同的效果。阅读案例研究是为了获得架构洞察,而不是转化基准。
如果你的店铺在进行代理集成前需要一个无头基础设施,那么在深入代理集成路径之前,值得审查一下无头电商开发。
数据、结账和支付责任划分
审计前先分配责任。代理商务集成最常失败的原因是,当凌晨2点重新订购触发时出现问题,没人知道应该由谁负责。

这是跨三个层级的实际责任映射:
| 层 | 代理需要什么 | 谁负责 |
|---|---|---|
| 目录数据 | 规范品牌、有效GTIN、明确变体、当前价格 | 商品化/PIM团队 |
| 结账API | 编程购物车创建、运费费率选择、税计算 | 后端/平台工程团队 |
| 支付 | 委托支付授权、范围内授权令牌 | 支付/财务团队 |
| 库存 | 实时库存状态、低库存阈值、补货ETA | 运营/仓库系统 |
| 政策数据 | 退货规则、保修条款、促销资格 | 法律/商品化 |
BigCommerce的平台准备度报告详细说明了为什么这种映射在技术层面很重要:代理以编程方式创建购物车时需要选择运费、计算税费和完成支付,无需人工干预。如果这些步骤中的任何一个需要人工点击,代理要么会出错,要么会放弃。
AP2区分(来自LinkedIn研究)值得在这里深入理解。自主支付打破了人工发起点击的假设。购物车授权适用于人工存在的会话。意图授权适用于委托的、无人工干预的场景,如降价重新订购或补充触发。在你的代理访问结账之前,你的支付团队需要知道哪种授权类型适用于哪个流程。
审计目录、变体、价格和库存
这是大多数团队跳过的部分。他们专注于API合约,并假设后面的数据没问题。通常不是这样。
在将任何代理连接到你的商店之前,先进行以下目录审计:
产品标识符
- 每个产品都有有效的GTIN、UPC或EAN,而不是占位符
- 品牌名称是规范的(不是"制造商"、"OEM"或"N/A")
- 型号与制造商格式完全一致
- 包装尺寸和尺寸明确,不是"混合"或"可变"
变体和属性
- 颜色、尺寸、材料变体表示为离散的、可查询的字段
- 危险品标志、食品安全认证、兼容性数据在相关位置存在(缺失的标志会导致在筛选查询中被静默排除)
- 子类别映射足够具体,可以进行精确匹配查询
定价和促销
- 价格在API响应中是当前和准确的,不仅仅是在CMS中
- 促销资格表示为代理可以解析的结构化逻辑,而不是营销文案
- 忠诚度规则和保修条款在API层中,而不是埋在PDF下载中
库存
- 库存状态是实时的,不是缓存24小时延迟
- 库存不足阈值已设置并在API中显示
- 缺货产品返回清晰的信号,而不是包含空数据的200响应
一个具体的例子:想象一个名为"陶瓷滴滤咖啡壶,600ml,哑光黑"的产品。代理查询是"陶瓷滴滤,低于£45,当天送达"。你的价格API返回£42。你的库存API返回库存状态:null,因为没有人设置该字段。代理将你的产品筛选出去。竞争对手的instock: true字段已填充,赢得推荐。这就是失败模式。
对于管理珠宝或其他高考量度产品目录的无头商店,变体和属性问题特别严重。查看无头商务精细珠宝文章,了解该产品类型如何映射到结构化数据要求。
处理授权、退货和人工转接
代理最常犯的三个错误:权限范围划分不当、退货资格判断错误,以及不知道何时该停止。
权限范围划分
给予代理有范围限制的权限,而不是无限制访问。完成重新订购的代理不应该有权限修改账户详情或查看完整订单历史。令牌范围应该与任务相匹配。这是标准OAuth做法,但值得明确说明,因为快速建立集成时往往会有诱惑使用宽范围的管理员令牌。
退货资格
退货规则需要能被机器解析。"30天内接受退货、商品原况完好、需提供购证、不含个性化商品"必须表达为结构化逻辑:
return_window_days: 30condition_required: originalproof_of_purchase_required: trueexclusions: ["personalised"]
如果这些数据仅存在于为人类编写的退货政策页面中,代理就无法验证退货资格,或者向购物者提供错误信息。
人工转接
并非每笔交易都应该自动完成。定义触发人工转接的条件:
- 订单金额超过指定阈值
- 收货地址异常或账单不匹配
- 商品需要年龄验证或符合监管要求
- 客户明确要求与人工客服交流
代理需要有明确的升级机制和确认升级成功的清晰信号。没有这些,就会导致无声失败或循环。
关于如何构建内容以便代理首先正确读取的上下文,可以参考代理可读网站内容文章,这是支撑所有这些工作的内容层。
分阶段实施计划
不要试图在一个冲刺内完成所有工作。这是一个对具有现有工程团队的无头商店来说切实可行的分阶段方法:
第1阶段:数据基础(第1-4周)
- 审计目录中缺失的GTIN、无效的品牌字段、模糊的属性
- 在所有SKU中填充实时库存状态
- 将定价和促销资格结构化为API可查询的字段
- 向产品和订单API添加机器可读的退货规则
第2阶段:结账开放(第5-8周)
- 确认程序化购物车创建端到端工作,不依赖UI
- 通过 API 公开运费选择和税费计算
- 为代理会话实施代币范围的授权
- 测试失败的结账场景:会话中途将缺货商品添加到购物车。代理是否收到明确的错误和恢复路径,还是超时?
第 3 阶段:支付委托与交接(第 9-12 周)
- 与您的支付提供商合作了解mandate类型(有人在场 vs 委托)。在针对 AP2 进行构建前,请直接向您的提供商验证 AP2 的支持状态。
- 定义和记录人工交接触发条件
- 设置代理会话日志,以便审计代理在结账中的实际操作
- 以 Claude 商务蓝图作为参考规范运行结构化测试
第 4 阶段:持续维护
- 指定商品目录数据所有者。这是大多数商店目前尚不存在的职位,也是导致最多无声失败的原因。
- 为关键属性上返回 null 或空字段的 API 响应设置监控
- 每季度审查来自 ACP、UCP 和 AP2 所有者的协议更新。这些规范在不断演变。
此次迁移的 SEO 影响值得单独追踪。Shopify 至 Headless 迁移 SEO 文章涵盖了任何架构变更中需要保护的内容。
就绪矩阵:商品目录至结账
使用此矩阵评估您的现状。三个示例场景以针对您的实际 API 响应进行测试:
| 场景 | 代理检查的内容 | 通过信号 | 失败信号 |
|---|---|---|---|
| 产品发现:"陶瓷滤杯,哑光黑色,售价 45 英镑以下" | GTIN 存在、价格准确、变体可查询 | 返回的产品包含所有已填充的字段 | 产品缺失或返回的价格为 null |
| 库存变化:商品在交易中途售罄 | 实时库存API | instock: false立即返回 | 过期的instock: true导致代理进入失败结账流程 |
| 失败结账:支付授权被拒 | 错误响应和恢复路径 | 代理接收结构化错误,上报或重试 | 超时或200响应但无确认 |
如果你的商店通过全部三项检测,你已为第2阶段做好准备。如果任何一项失败,请从第1阶段开始。
FAQ
无头架构是否让代理商务集成更容易?
无头意味着你已经在思考API优先,这消除了一些摩擦。但它不能解决数据质量问题。代理命中无头API时,如果缺少GTIN或库存字段为空,失败方式与在整体架构商店上完全相同。架构有帮助,但本身不充分。
我需要注册Anthropic的商务项目才能使用该蓝图吗?
不需要。Claude for Commerce蓝图(发布于2026年9月2日)是参考代码。它描述如何构建代理交互,不是你需要申请的项目。构建集成时,你可以用它作为规范。
AP2购物车授权和意图授权之间的区别是什么?
购物车授权涵盖人工在场的结账:购物者在会话中,代理在协助。意图授权涵盖委托的、人工不在场的场景:自动重新订购、补货触发、降价购买。你的支付提供商需要支持适用于你用例的授权类型。在构建之前,请向提供商确认当前AP2支持状态,因为规范仍在演进。
代理商务准备程度会改善我的搜索排名吗?
不会。无头架构和代理准备工作不是排名信号。它们影响AI购物代理是否能在你的商店上运作,这是一个不同于有机搜索的分销渠道。
如果产品库存在代理产品查询和结账之间发生变化会怎样?
这是会话中期库存变化失败模式。你的库存API需要返回实时状态,你的结账API需要在两次调用之间某件商品缺货时提供清晰的结构化错误。如果代理收到超时或含糊的200响应,它没有恢复路径,交易要么默认失败,要么错误完成。
上述所有内容中最尖锐的单一警告:Claude for Commerce蓝图是参考代码,不是准备程度保证,它引用的协议(ACP、UCP、AP2、A2A)仍在演进中。在生产环境中构建之前,请向各协议所有者确认当前状态。
