9 月 2 日，Anthropic 发布了一套很值得电商和 Agent 开发者研究的东西。
它没有再发布一个单纯的购物聊天 Demo，而是把过去一年和零售、电商、旅游、电信等企业共同实践的 Commerce Agent 架构整理成 Blueprint，并将参考实现直接放到了 GitHub。仓库采用 Apache 2.0 协议，包含面向消费者的 Shopping Agent、面向商家的 Merchant Agent、Claude Code 插件、测试框架，以及零售、旅游、电信和娱乐四个可运行示例。
Anthropic 同时公布了一组商业侧数据：使用 Claude 购物智能体的部分企业客户，购物车金额最高提升约 35%，用户完成购买的可能性提高约 60%。路透社引用 Adobe Analytics 数据还提到，来自 AI 的零售访问流量，其转化率已经比其他来源高出约 60%。这些数字都需要结合具体企业场景理解，但至少说明一件事，Agentic Commerce 已经开始从概念验证走向交易指标。
对开发者来说，这次开源真正有价值的地方，是 Anthropic 把电商 Agent 在生产环境里最容易踩坑的部分讲得非常细。模型只是其中一层，真正决定电商智能体能不能上线的，是商品、搜索、购物车、库存、支付、记忆、安全和评测怎么组织起来。
一、一口气做了两个电商智能体
先看整体产品设计。
Anthropic 没有把所有电商需求塞进同一个万能助手，而是拆成了两个角色。
Shopping Agent 面向消费者。
它被嵌入商城 App 或网站，可以理解自然语言购物需求、搜索商品、比较方案、组合多个商品、记住用户偏好、加入购物车，也可以继续回答订单查询、退换货和退款政策等售后问题。官方举的例子很典型，用户只需要说「一家四口周末露营，需要帐篷、睡袋和炉子」，Agent 就可以围绕整个目标组织商品，而不需要用户逐个关键词搜索。
Merchant Agent 面向平台运营和商家。
它可以读取销售、库存、商品和营销数据，回答什么卖得好、哪些商品快断货，进一步给出定价、促销和营销活动建议。比如运营人员可以直接问：上一季库存应该打几折才能更快清掉？Agent 会结合实际销售数据进行分析。
这两个 Agent 对应的其实就是电商平台最核心的两条价值线。
Shopping Agent 提升消费者的「找货和决策效率」，Merchant Agent 提升商家的「经营效率」。
这比单独在商城里增加一个 AI 客服要深入得多。传统 AI 客服解决的是问答；电商 Agent 开始碰搜索、推荐、购物车、库存、价格、订单和营销，已经进入核心交易流程。
二、一个主 Agent + Skills
这次技术文章里，我认为最值得关注的是 Anthropic 对多 Agent 架构的态度。
现在很多 Agent 产品有一个很流行的设计：商品 Agent、订单 Agent、售后 Agent、营销 Agent各自负责一块，再由 Orchestrator 负责调度。
Anthropic 在多个企业项目中的实践结论却比较克制。对于电商这种连续对话场景，他们更推荐：一个主 Agent + Skills + Tools。
原因来自实际运行成本：一次购物对话经常同时涉及商品、库存、用户偏好、购物车、订单和售后。如果频繁把任务转交给不同子 Agent，用户历史、购物车状态和当前意图就需要不断传递。Anthropic 发现，每次 handoff 都会带来上下文损耗，同时增加 Token 和延迟。
所以它选择让主 Agent 保留完整会话上下文，再按需加载 Skills。
Shopping Agent 目前就拆出了 search-discovery、purchase-research、planning-goals、customer-care、memory-personalization 等能力；Merchant Agent 则包含经营分析、商品管理、库存运营、价格促销和营销活动。
只有那些真正独立、上下文很重的任务，才值得交给 Subagent，比如深度研究。
这个设计对国内做 Agent 的团队很有参考价值：多 Agent 数量并不代表系统更高级。
电商的核心体验是连续决策，用户上一句话说预算 3000 元，下一句话说家里有两个孩子，再下一句要求明天送达，这些信息最好始终留在一个主上下文里。
Agent 架构需要服从业务状态，而不是追求 Agent 数量。
三、不要让大模型重新发明你的电商系统
Anthropic 这套方案还有一个很重要的工程原则：Agent 应该调用企业已有系统。
一家成熟电商平台本来就已经有搜索排序、商品库、价格、库存、购物车、订单、会员、促销系统。这些系统可能运行了十年，里面沉淀了大量业务规则。
所以当 Agent 调用 search_products 时，后端应该先按照现有搜索算法返回排好序的商品。
大模型负责理解：这些商品里哪些更符合用户目标，应该展示几个，应该怎么解释。它不负责重新实现搜索排序。同样，库存是否可售、优惠券能不能叠加、会员价怎么算，也应该继续由业务系统计算。
这个边界非常重要。很多企业第一次做 Agent 时，会把大量原本确定性的逻辑交给大模型，比如让模型自己判断价格、库存甚至优惠规则。结果就是系统越来越难控制，更成熟的结构应该是：业务系统负责事实和规则，模型负责理解、选择和决策。
这也是为什么未来企业 Agent 的技术竞争，很大一部分会落在 Tool 层。
谁把商品、订单、会员、营销、库存这些能力封装得足够标准，谁就更容易接入不同模型和 Agent。
四、把电商 UI 也设计成了工具
这部分非常有意思。现在很多聊天式购物产品的做法，是让模型生成一段 Markdown 或特殊标签，再由前端解析成商品卡片。Anthropic 在实际项目中发现，这套方式越做到后面越麻烦。
商品列表、对比表、购物车、酒店方案、座位图等 UI 越来越复杂，靠模型输出自定义标签容易产生格式错误，System Prompt 也会越来越臃肿。所以他们采用了另一种方式：把 UI Component 本身做成 Tool。
比如：present_products、present_itinerary、present_plan_comparison
模型决定调用哪个组件，同时传入结构化参数，服务器完成 Schema 校验和数据补充，客户端负责渲染。
这个设计有两个好处。
第一，UI 变得可控。商品价格、库存、图片、按钮都可以继续由服务端提供，不依赖模型自由生成。
第二，Agent 可以知道用户刚才看到了什么。比如用户说「我要左边第三个」，上一次 present_products 的 Tool Call 里已经包含页面结构，因此 Agent 能理解用户指的是哪个商品。
这实际上把传统 GUI 和 Agent 的会话状态连接起来了。
未来电商 Agent 很可能越来越少输出大段文本，更多是在动态生成交互界面。聊天框只是入口，商品卡片、购物车、支付确认、订单状态才是完整体验。
五、最大的工程难题，其实是速度和成本
电商是一个对延迟极其敏感的行业。用户问一句「帮我找三款适合跑步的鞋」，如果 Agent 思考二十秒，体验很容易崩。Anthropic 把任务延迟拆成了三个变量：模型轮数 + Tool 执行时间 + 模型生成速度。
其中一个很反常识的结论是，更便宜、更快出 Token 的模型，未必拥有更低的任务成本。
如果小模型规划能力较弱，需要反复调用五六次工具才能完成任务；更强的模型可能两三轮就完成，最终耗时和成本反而更低。所以 Anthropic 给出的指标不是单次 API Cost，而是：Cost per completed task，完成一次任务到底花多少钱。
这和现在越来越流行的 Agent 成本管理思路完全一致。衡量模型的时候，至少应该一起看任务成功率、平均轮数、P50/P99 延迟和完成任务的 Token 成本。另外一个非常现实的成本优化点是 Prompt Cache。
Anthropic 表示，在他们看到的优秀 Commerce Agent 部署中，Prompt Cache 命中率可以做到 90% 到 99%。Claude 当前缓存 Token 的读取成本约为正常输入的十分之一，而且在大约 100K Token 的上下文场景里，缓存读取速度还能快约 1.5 到 2 倍。
实现方式也很工程化，把上下文分成三层：全局固定 Prompt 和 Tool 定义放最前面；用户长期信息和历史会话放中间；当前页面、时间、实时状态等高频变化内容放最后。
这样才能尽量保持前缀稳定，提高缓存命中率。对于大型电商平台，这里的成本差异可能非常大。一天几百万次对话之后，Prompt 结构本身就会成为一项基础设施能力。
六、涉及钱和价格时，让模型及时刹车
我认为整套方案里最成熟的设计其实在安全部分。Anthropic 明确规定：模型负责提出动作，真正执行由 Harness、业务规则或人工确认完成。
Shopping Agent 可以帮用户把商品放进购物车，但它没有直接扣款接口。真正支付需要用户点击确认。
Merchant Agent 可以建议把某个商品降价 15%，但系统只会先创建一条 staged change。运营人员确认之后，后端才真正执行。退款、价格修改、促销上线、预算调整同样遵循这套结构。这非常适合电商。
因为 Agent 一旦开始拥有执行能力，风险会迅速从「回答错了」升级成「钱真的动了」。Anthropic 甚至要求写操作只能接受服务端之前真实返回过的 ID。如果模型幻觉出了一个商品 ID，或者有人把恶意 ID 藏进评论里，Harness 会在请求抵达业务系统之前直接拒绝。第三方商品描述、评论和卖家消息也全部被视为不可信输入，需要经过Sanitizer 后才能进入模型上下文。
这里其实给企业 Agent 提供了一条很清晰的安全原则：**Prompt 负责告诉模型怎么做，代码负责保证它不能做错得太离谱。**凡是涉及资金、库存、价格、权限和真实业务状态的规则，都应该落在 Harness 和后端。
七、评测方式也值得借鉴学习
Agent 最大的麻烦，是同一句话运行两次，路径可能并不完全一样。传统软件测试很喜欢检查过程。Anthropic 对 Commerce Agent 的建议更关注最终状态。
比如用户要求：帮我找一双 42 码、500 元以内、有库存的跑鞋并放进购物车。评测应该重点检查：最后商品是否符合条件，价格和库存是否来自真实数据，购物车最终状态是否正确。至于 Agent 先调用搜索还是先读取用户偏好，通常没有必要强行规定。Anthropic 把这种方法叫 Snapshot Eval。
同时，他们特别强调要测试脏状态，包括很长的历史对话、前后矛盾的信息、恶意商品描述，以及 should serve / should refuse 这样的正反案例。这比只准备几十个标准问题看回答对不对，要更接近真实电商环境。
Agent 真正容易出问题的地方，往往就在脏数据、上下文冲突和边界场景里。
八、为什么现在把电商 Agent 开源
把视角从技术拉回行业，会发现这个时间点并不偶然。
Shopify 今年已经明确表示，正在为 Agentic Shopping 带来的变化做准备。Shopify 总裁 Harley Finkelstein 直接把 AI Agent 称为电商商家的新入口。Google 也已经联合 Shopify、Walmart、Target、Etsy、Wayfair 等公司推出 Universal Commerce Protocol，让 Agent 可以参与商品发现、购买和售后流程。
消费者的行为也开始发生变化。路透社 8 月报道，Walmart、Ulta Beauty、Wayfair 等零售商已经在主动优化自己的商品数据，希望进入 ChatGPT、Gemini 等 AI 推荐结果。AI 推荐带来的用户消费能力很强，但零售商同时又非常在意一件事：最终交易最好仍然发生在自己的平台里。
订单发生在哪里，客户数据就沉淀在哪里。会员、复购、广告归因和品牌关系都依赖这些数据。这恰好解释了 Claude Commerce Agents 的产品策略，Anthropic 没有试图直接成为新的电商平台。Shopping Agent 负责帮用户搜索、比较和组装购物车，支付仍然交给企业原有 Checkout 或第三方 Agentic Payment。官方开源代码甚至明确说明，示例不会真正下单、扣款或者修改线上商品。所以 Anthropic 真正想争夺的是：电商 Agent 的基础设施层。
模型、Agent Runtime、Skills、Tools、Harness、Eval，再通过 Visa、Mastercard、Shopify、Wix 等生态合作伙伴进入真实交易网络。这和它之前围绕 Claude Code、Agent SDK、MCP 做的事情其实是同一条路线。
九、国内电商平台我建议从这四步开始
看完这套开源项目，我反而不建议电商团队第一天就做一个万能 AI 导购。更现实的路径应该从现有业务系统出发。
第一步，先把搜索、商品、库存、购物车、订单和会员能力封装。Agent 先做到「能够正确使用现有系统」。
第二步，选择一个高价值场景。比如复杂商品组合、售前咨询、订单售后，或者商家库存分析。先把成功率做高，再扩展能力。
第三步，把支付、价格修改、退款、营销预算这些高风险操作全部放进 Harness，并保留人工确认。Agent 可以建议、预填、准备执行，但不要第一天就把最终权限交出去。
第四步，尽早建立 Eval。每一次 Prompt、模型、Tool 和 Skill 的修改都跑一遍固定案例，关注任务成功率、平均轮数、延迟和单任务成本。
这四件事都做完之后，再考虑多 Agent、主动推荐、自动运营，就会稳妥很多。
写到最后
Claude 这次开源的 Commerce Agents，最大的价值是第一次比较完整地把一个消费级智能体从 Demo 走进生产环境。当 Agent 能够帮用户完成「我要买什么」，也能帮助商家完成「我要怎么卖」，电商的交互入口就会从搜索框和菜单，逐渐增加一层新的自然语言入口。
对平台来说，真正值得投入的方向已经很清楚：别急着先做一个会聊天的 AI 导购。
先把自己的商品、订单、库存、会员、支付和营销系统，变成一套 Agent 能够安全调用的能力。
模型会继续换代，这套业务能力，才是未来每一代 Agent 都需要调用的。
