商品搜索、加入购物车、人工付款在很多电商系统里由不同模块负责。搜索归搜索引擎管购物车归前端状态管付款跳到收银台后前面搜过什么、聊过什么常常就丢了。让顾客重新说一遍顾客可能直接离开。Anthropic在2026年9月2日发布的Claude Commerce Agents试着把这条链重新接起来但它交付的不是一个聊天窗口。这套蓝图把购物智能体、商户智能体、技能、工具合同和安全护栏放在同一个工程框架里。购物端负责搜索、比较、组装购物车再把顾客交给原有收银台商户端负责读数据、提建议把写入动作留在待审批状态。本文按这条边界拆开4个行业示例读者可以看清两类智能体各自能做什么也能拿到从后端接口、审批门到部署验证的落地清单。这次发布值得关注的地方不是模型又多会聊天而是业务系统终于被当成了智能体的一部分。商品目录、库存、订单和政策不再只是被动查询的接口它们决定了模型能看到哪些事实、能提出哪些动作。把这些约束写进工具调用比在提示词里反复提醒一句“请谨慎操作”可靠得多。一次开源真正改变的是谁的工作最先被改变的不是顾客而是开发团队手上那张“又要做人工智能又要搞电商”的需求单。过去接到“做一个能帮顾客挑东西的助手”这类需求团队要自己搭对话循环、工具调用、购物车状态和错误处理。现在仓库直接提供了购物智能体和商户智能体的核心代码、技能定义、工具合同、安全护栏与参考实现。开发者仍要接自己的业务系统但不用从空白文件开始发明整套执行框架。仓库把通用部分和业务部分分得很清楚。通用层负责会话、技能加载、工具执行、结果展示和安全检查业务层负责目录、购物车、订单、政策、分析和库存。你要做的不是把模型塞进现有系统而是让自己的后端实现蓝图定义的接口。接口一旦稳定换零售、旅行或电信场景时智能体的主循环不用跟着重写。项目还提供了Claude代码插件能生成项目骨架、增加业务流程、编写评估用例并检查已有代码。这个入口的价值在于把常见工程动作变成可重复的命令而不是让每个团队重新整理目录。它不能替你决定权限和业务规则也不能凭空生成商品数据。开发速度能否真正提高仍取决于后端是否有清楚、可测试的接口。这份代码的边界也写得很诚实。仓库里的公司、商品和人物都是示例示例不会下单、扣款或修改线上商品。收银台只负责把购物车交给宿主系统商户写操作只停留在待审批变更。生产部署要自己补上认证、授权、真实数据和合规流程不能把演示仓库当成已上线的电商平台。角色服务对象可以做的事必须停下来的边界购物智能体顾客搜索商品、比较方案、组装购物车、回答订单与退货问题不处理付款购物车交给宿主收银台商户智能体运营人员分析销售、查看库存、提出定价与营销建议写操作先暂存必须经过宿主审批才能应用购物智能体为什么停在购物车购物智能体的流程里有一个刻意保留的停点它不执行付款。它可以搜索目录、比较商品、做多件商品的组合建议、加入购物车、查询订单和回答退换货政策。对话结束时它把已经整理好的购物车交给宿主系统的收银台。付款凭证、地址校验和风险控制仍由原有交易系统负责模型不会接触这条资金链。把付款留在收银台有两层考虑。付款涉及支付凭证、地址验证、风控和扣款任何一步出错都不再是对话质量问题而是资金与责任问题。第二层是责任边界智能体负责帮助顾客完成选择和准备电商系统负责完成交易。顾客看到的是连续对话后台仍然保留清楚的系统分工。官方发布页引用的合作结果也提醒开发者购物智能体不该只看成交额。相关零售商的购物车最高增大35%购物者完成购买的可能性提高60%。这两个数字描述的是企业观察到的结果不是所有商家的保证。运费、支付方式、库存和顾客信任都会影响真正成交所以评估时要把加车、收银台跳转和实际支付分开记录。购物端的能力被拆成搜索发现、购买研究、目标规划、客户关怀和记忆个性化等技能。每个技能是一组可以按需加载的操作规则主智能体始终保留完整的会话、购物车和用户偏好。工程深度文章给出的取舍是电商对话里的多个意图往往互相牵连硬拆成许多子智能体会带来状态交接。把长尾流程放进技能比在每次交接时重新解释上下文更稳。购物工具还要带着来源走。加入购物车的商品应当来自本次会话中目录或订单工具返回的商品记录不能只接受模型自己写出的商品编号。展示组件里的价格、库存和政策文字也应由服务端记录补齐。这样做会让工具合同更细但能阻止一个看似合理的商品名称直接变成真实购物车里的商品。商户智能体怎样把建议变成待审批变更商户智能体的方向与购物端相反。它面向运营人员读取销售表现、库存预警和商品目录给出定价、促销与营销建议。它可以起草一项改动却不会把改动直接写进生产系统。每个写操作先形成待审批变更再由商家后台的审批界面决定是否应用。仓库对这条规则写得很明确每个写入操作都是暂存变更由宿主的审批界面应用。这样就把“智能体有权限”和“智能体可以自动生效”拆成了两件事。智能体可以准备调价、补货、修改商品信息或起草活动但它只能提交提案。真正的应用动作需要一个来自宿主的明确批准。审批门不能只写在提示词里。工具执行器应检查操作对象是否来自本次会话、字段是否允许修改、变更幅度是否超限、审批状态是否有效。检查通过后仍然只返回待应用的变更编号后台应用接口再次检查审批标记。即使有人通过提示词注入要求“忽略规则”工具链的硬检查也不会因此消失。落地时可以把一项改动分成提议、待审、已批准、已应用和已撤销几个状态。每个状态都写入操作人、时间、目标对象、旧值和新值撤销动作也要有自己的权限检查。这样的记录比在聊天记录里寻找一句“同意了”更容易审计。对于价格、库存和营销预算审批面板还应显示影响范围让人知道这一点确认会改变什么。商户端的技能覆盖业绩洞察、目录上架、库存操作、定价促销和营销活动。它们可以共用同一套工具合同和变更门差别只在读取的数据和生成的提案类型。安全规则需要在工具调用时执行不能寄希望于模型每次都记得一段提醒。对运营团队来说这和内容平台的先审后发很像只是被审核的对象变成了人工智能提出的业务动作。同一套工具合同如何复用到四个行业蓝图附带4个可以运行的行业示例分别是零售、旅行、电信和娱乐。每个示例使用同一套核心代码只替换后端接口和行业数据。零售面对商品和库存旅行面对日期与行程电信面对套餐与合约娱乐面对场次、座位和票务。智能体的流程保持相近业务差异落在后端。零售示例搜索商品、价格和库存旅行示例查询航班、酒店和套餐电信示例处理套餐、设备和合约娱乐示例处理票务、座位和场次。四个场景都需要意图解析、后端查询、结果展示和状态回写。开发者因此可以先学会一套流程再把注意力放在行业规则上。接口复用不是把业务抹平而是把重复的编排工作抽掉。购物端的后端接口负责目录、购物车、订单和政策商户端的后端接口负责分析、目录编辑、库存、定价和营销。智能体只通过这些接口得到结果不直接访问数据库。这样做可以让企业继续使用原有的搜索排序、库存锁定和促销引擎。模型判断该选哪一个结果业务系统仍然掌握数据和写入权。界面组件也被当作工具来处理。商品列表、行程卡片、套餐对比、座位图和运营图表都可以用带类型参数的工具调用表达再由服务端校验后交给客户端渲染。这样重新打开历史会话时系统读取的是原生工具消息不必再从一大段文本里猜哪一件商品排在第一位。模型输出的是结构化调用页面展示由客户端掌握。一份可用的工具合同至少要说清输入字段、数据来源、权限范围、失败状态和下一步动作。服务端返回的结果应包含模型真正需要判断的字段不要把内部日志和无关图片地址全部塞回上下文。错误也要写成模型能理解的行动提示例如要求补充商品编号而不是只返回一个没有解释的状态码。工具越靠近真实业务规则智能体越少机会靠猜测补洞。记忆、溯源与护栏如何卡住幻觉电商里的幻觉比普通闲聊更贵。智能体说一件衣服“尺码偏大”顾客按这个建议购买收到货后发现不合身退货和投诉只是表面成本信任损失更难补回来。蓝图的处理方式不是要求模型更自信而是让商品、订单和政策都通过工具回到对话里。没有来源的细节就不应该被写成确定答案。第一层是工具调用的凭证溯源。目录工具返回了哪些商品购物车写入就只能使用哪些商品展示价格和库存时服务端再次根据记录补齐。收银台地址也由宿主后端生成模型只得到“交给收银台”的结果。这样的设计把模型的语言能力放在解释和选择上把商品事实留在业务系统里。第二层是记忆的范围控制。安全文档说明记忆抽取读取最近一轮用户与助手的文字不读取工具结果写入的事实还要经过长度、类别和敏感信息检查。部署方要提供查看、删除和账户清理机制也要决定保留多久。记忆不是越多越好能解释来源、允许撤回比无限保存更适合商业系统。第三层是安全门控。商品推荐、政策回答、价格修改和库存操作都应由工具执行器检查资源、参数和权限。商户写操作要在暂存时检查一次在应用时再检查一次因为审批期间业务数据可能已经变化。提示词可以帮助模型理解规则真正决定能不能动数据的地方必须是代码。日志和凭证同样属于生产边界。部署文档把认证、授权、凭证管理、限流、支付、个人记忆、日志访问和审批界面都留给接入方负责。示例里的服务适合本机演示不能直接暴露给互联网。上线前要先确认谁能调用工具、谁能批准变更、谁能删除记忆以及每个动作怎样留下可追溯记录。从参考蓝图到生产系统还差哪些接口蓝图给出的是架构不是成品。从仓库到上线至少有3类接口需要自己接还有一类评估工作不能省。你要把自己的数据模型映射到购物端和商户端的后端合同。你还要选择模型运行路径并为真实用户建立认证、限流和审批。代码能启动只说明开发环境通了不说明业务可以上线。第一类接口是购物后端。它要覆盖商品目录、购物车、订单和政策4个系统决定商品怎样搜索、购物车怎样读写、订单怎样追溯、政策怎样按场景返回。接口返回的数据要有稳定的字段和明确的空结果。库存变化、商品下架和优惠失效都要被转成模型能够处理的状态而不是让模型继续沿用旧答案。第二类接口是商户后端。它要连接分析数据、目录编辑、库存操作、定价工具和营销系统5个领域。与其让模型直接改生产表不如让后端生成包含目标、旧值、新值和影响范围的变更提案。审批通过后应用接口再读取当前数据并重新检查条件。这样可以避免提案生成时看到的库存到了真正执行时已经过期。第三类接口是模型运行方式。蓝图支持消息接口、智能体开发套件和托管智能体也给出了Anthropic API、Amazon云服务、Google云上的Vertex人工智能与Microsoft Foundry等部署方向。选择时要看数据合规、网络位置、成本和运维能力。切换平台不应改写业务流程但要重新确认模型名称、凭证、日志和评估结果。需要自己测的是评估体系。仓库提供了评估工具和示例场景但换上你的目录和政策后搜索准确性、推荐理由、政策回答、加车可靠性和审批安全都要重新测。测试不只看回答像不像人还要检查工具是否被正确调用、无权限动作是否被拦截、失败后是否能恢复。没有这些结果生产发布只能算一次演示。部署前还要把示例中的默认值逐项替换。认证不能依赖演示环境凭证不能进入模型上下文支付不能由模型代办商户审批不能由聊天中的一句话代替。每一项开关都要对应一个真实系统能力没有购物车就关闭购物车流程没有订单追踪就不要显示追踪按钮。能明确关闭的能力比让模型在运行时猜系统有没有这项能力更安全。开发团队今天可以照着做的最小路径如果今天开始动手第一步是用仓库自带的演示数据跑通一个行业。先准备好模型凭证再启动购物端和商户端确认网页能搜索商品、组装购物车后台能生成待审批提案。这一步只验证运行链路不要急着接真实支付。演示能完成才有资格进入后端替换。第二步从4个行业示例里挑一个与业务最接近的版本先读后端实现再列出自己的接口差异。把每个方法的输入、输出、失败情况和权限写成表格。不要一上来就修改提示词因为很多问题其实来自商品字段不全、库存状态不清或政策数据过期。先把数据合同讲明白后面的模型调试会短很多。第三步把自己的商品数据映射到商品模型。产品标题、价格、库存状态和规格参数可以作为起点但还要考虑变体、价格有效期、税费、配送范围和退货条件。模型只能根据返回的数据回答缺字段时要明确说无法确认。先做能搜、能看、能加购物车的版本再逐步增加订单和个性化流程。第四步实现一个最小审批面板。商户智能体提出变更后面板要显示目标对象、旧值、新值、建议理由、影响范围和当前状态。批准按钮只改变宿主记录不要把“同意”当成聊天文本再交给模型解释。若审批面板还没准备好就先关闭所有商户写技能只开放分析和只读查询。from dataclasses import dataclass dataclass(frozenTrue) class Change: change_id: str field: str old_value: str new_value: str approved: bool False def apply_change(change: Change) - str: if not change.approved: return blocked: host approval required return fapplied {change.change_id}: {change.field} if __name__ __main__: pending Change(price-001, price, 299, 269) print(apply_change(pending)) approved Change(price-001, price, 299, 269, approvedTrue) print(apply_change(approved))第五步给最核心的流程写评估用例。可以从商品搜索、退货政策、加入购物车、库存建议和审批应用这几个场景开始每个场景同时记录模型回答与工具结果。跑测试时要故意放入过期商品、无效编号、超范围调价和未批准变更。能稳定拦住这些情况才说明工具合同真的在工作。参考蓝图可以缩短第一版开发但生产环境必须把审批、权限、溯源和回滚做成系统边界。你本地跑通演示只验证了代码能协作接上真实商品、真实库存、真实收银台和真实运营人员后责任才真正落地。每个已应用的变更都要保存旧值发现价格、库存或政策不一致时审批人可以按记录撤销而不是让模型再猜一次。验收记录还应保留输入、工具调用、变更编号、批准人和结果方便上线后定位问题也方便复盘一次错误究竟发生在模型、工具还是业务接口。蓝图提供的是一套可复用的脚手架不是替你完工的系统。能让智能体知道事实、提出建议并在未经批准时停下来才是这次开源最值得带回团队的工程答案。