이미지: 앤스로픽 공개 영상 갈무리
摘要
- Anthropic于9月2日以Apache 2.0许可证公开了打造购物、商家智能体的设计蓝图。
- 零售、旅行、通信、娱乐四个领域的示例以及Claude Code插件都收录在这个代码仓库里。
- 支付和价格变更都不会由模型直接执行,只会进入待人工审批的队列。
整套设计图都公开了
Anthropic于9月2日开源了打造商业智能体的设计蓝图。GitHub仓库anthropics/commerce-agents中,以Apache 2.0许可证上传了面向顾客的购物智能体、负责运营店铺的商家智能体的实现代码,还有零售、旅行、通信、娱乐四个领域的示例。
Anthropic的用意就是让大家直接拿这套仓库去分叉使用。仓库里不含具体连接器,后端接口留空,设计上是让各家公司通过MCP把自己的库存、订单系统接进去。示例中出现的店铺和商品全是虚构的,不会产生真实的下单或支付。仓库说明里明确写着,这只是参考实现,不会持续维护,也不接受外部贡献。
一个管顾客,一个管店铺
购物智能体接收顾客的口头提问。它能检索商品目录、比较多款商品并展示在屏幕上、把商品加入购物车,还能回答订单状态或退货政策之类的问题。围绕它配备了五项技能——搜索发现、购买调研、方案规划、客户应对,以及记忆与个性化。
商家智能体则运行在店铺后台界面上。它分析销售数据、追踪库存、提出价格和促销建议,还能起草营销活动方案。这一侧同样配了五项技能:业绩分析、目录管理、库存运营、价格促销、营销活动。
哪些内容放进系统提示词、哪些做成技能单独调用,遵循同一条规则:占整体对话约三分之一的常见任务常驻在提示词里,剩下那条长尾则交给技能模块处理。
这套架构里一个引人注意的地方是,前端没有设置意图分类器。它没有采用把对话切分、转给各部门专门智能体的做法,而是由单一模型跑一套标准的智能体循环,按需调用相应技能。拿政务大厅打比方就很清楚了:在窗口听完诉求后说"那个去三楼办"是意图路由器的做法,而这套设计更像是一位服务台工作人员从头跟到尾,需要时随手抽出相应的文件夹。
界面呈现方式也是同样的思路。模型不直接写标记语言,而是调用present_products或present_itinerary这类工具,由服务器校验参数、补全内容后生成界面。工具返回的结果也会被裁剪,只保留必要字段传递下去——比如图片地址这类信息会直接被抹掉。
模型碰不到钱
这套系统里最花心思的地方不是营收,而是刹车装置。Anthropic把"模型的任何工具调用都不会动用资金或改变业务状态"定为一条设计原则。
具体做法分三层。第一层是让操作停在等待状态,而不是直接执行。支付流程止步于购物车和按钮的展示,商家一侧的价格变更或活动启动也都会进入待审批队列,只有负责人在后台点击确认或通过CLI核实后,变更才会真正生效。
第二层是只认服务器签发的ID。每次会话中返给模型的ID,服务器都会全部记录在案,凡是模型编造的ID、用户随手粘贴的ID,或是藏在评论里的ID,都会在触达后端之前被拦截过滤。
第三层是手续费、提示文案、监管相关文字只能来自经过审批的固定文案。模型不能自行编造措辞,商家智能体也碰不到价格条款这类受保护字段。
限流的设置点也不一样。限额施加在结果状态上,而不是请求本身,同一会话内的写操作被强制按顺序排队执行,这是为了堵住那种同时并发多个工具调用、借机绕过限额的漏洞。
记忆不是记事本,而是数据表
长期记忆没有采用Markdown格式的用户画像,而是存进数据库里带类型的记录,这也是一个特点。每条事实被拆分成键、值、分类、来源会话四个部分,组成一行记录。
写入记忆的时机是在每轮对话结束之后、异步进行的。这是为了不让用户等待响应,而且提取器只读取对话文本,不会读取工具返回结果——目的是防止商品描述被误当成用户的个人喜好。Anthropic表示,采用这种方式后,内部测试中事实召回率提升了13%。
读取记忆分三层:一层是默认门店、配送偏好这类始终附带的固定值;一层是像找鞋子尺码这样每轮对话都提前预取的值;剩下的则通过查询工具随需查找。
15分钟与一小时
Anthropic表示,使用Claude运行购物智能体的零售商,购物车规模最高扩大了35%,完成购买的比例提高了60%。谈到落地速度时,Anthropic引用了客户的说法。Wix商业业务负责人Dror Zalika表示:"我们的工程师在15分钟内就上线了一个能接收提示词的商业智能体。"Faire的高级产品经理Ashley Nader则说:"我们不到一小时就把蓝图里的两个智能体跑通了本地环境,而且第一次尝试就实现了真实的对话交互。"
工程文档里还附带了一些运营数据。已部署案例的缓存命中率在90%到99%之间,缓存命中的token处理成本只有新读取token的十分之一,速度却快1.5到2倍。单个任务通常在3到5轮模型交互内完成,商业场景回复的输出长度大约在500到700个token。文档建议评估集从每个用户流程50到100个案例起步。
执行路径分三条:基于Messages API运行的参考循环、Claude Agent SDK,以及处于测试阶段的托管智能体。此外还配有用于搭建脚手架的Claude Code插件。可部署平台包括Claude API、Amazon Bedrock、Microsoft Foundry和Google Cloud Vertex AI。
编辑视角
读这份发布材料时,一直让我在意的不是那些业绩数字,而是仓库里的目录命名。docs/safety.md、gates、guardrails、审批控制台——这些通常是动手搭建商业智能体时最后才补上、也最常被忽略的东西,这次却从一开始就被固定成了文件夹名字。
这份蓝图的分量正在于此。它写的不是怎么做出一个演示,而是怎么把一个演示改造成可以放到真金白银交易场景里也不出问题的状态。
接入过智能体的团队都清楚问题出在哪。一个演示效果不错的系统上线之后,第一次出事故几乎总是发生在两种情况:模型编造出根本不存在的商品编码,或者拿着不知从哪冒出来的ID去动了别人的订单。"只认服务器签发的ID"这一条规则,就把这类事故整个堵死了。
这也恰好和国内电商公司眼下正在头疼的问题对上了号。接入商品搜索和咨询聊天机器人的事,不少公司早就试过了,但大多都卡在"说话是挺利索,可支付这一步还是不敢交给它"这一关。
而这次代码给出的答案是:跨过最后这一道坎,靠的不是更聪明的模型,而是从模型手里收回执行权限的设计。支付按钮不是模型按下的,是人按下的。商家端的价格变更全部堆在审批队列里等待处理。在这套架构下,出事故的上限被死死限定在"审批队列里多了一条奇怪的建议"这个程度。
还有一点值得一提,那就是把记忆做成数据库记录的选择。现在不少智能体习惯把用户记忆以句子形式堆进Markdown文件,但在商业场景里这种做法很危险——一句商品描述一旦被固化成用户偏好,后续的推荐就可能整个跑偏。这正是为什么要单独设置一个完全不读取工具结果的提取器,而13%的召回率提升,正是这种隔离带来的结果。
Anthropic选在这个时间点放出代码,理由也很明显。美国零售业在9月初正好进入年末旺季备战期,这套操作抢在竞争对手之前铺好了一条标准路径:"在我们的模型之上搭建你的商业智能体。"以Apache 2.0许可、连接器留空的架构,意味着它能接入任何一家的后端,而一旦接入,跑在上面的模型就是Claude。开源出去的是蓝图,真正要卖的,是接下来在这套蓝图上流转的token。
评论