搜索商品、比较选项、加入购物车，还要回答退货相关的问题。任何团队着手做一个购物用的 AI 智能体，最后都得把同样的底层结构重新搭一遍。Anthropic 现在把这套底层结构以代码形式公开了。仓库 anthropics/commerce-agents 包含面向消费者和面向商家的两类智能体，采用 Apache 2.0 授权。
两类智能体与四个行业
公开的蓝图里有两个职责完全不同的智能体。
第一个面向购物者。它运行在商家自己的应用或网站中，检索商品目录，处理一次涉及多件商品的请求，比较选项并组装购物车。关于订单状态和退货的提问，也在同一段对话里回答，不打断上下文。接入方需要针对自家的目录、购物车、订单和政策系统实现一个 StorefrontBackend。
第二个面向门店运营人员。员工可以询问销售为何停滞，接收库存预警，索取定价与促销建议，或者让它起草营销文案。这一侧的对接点是 MerchantBackend。
在此之上，仓库还附带了零售、旅行、通信、娱乐四个行业的可直接运行的实现。只要有 Python 3.11 以上版本、Node 22 和一把 API 密钥，就能在本地启动，同一份代码既可跑在 Claude API 上，也可跑在 Amazon Bedrock、Microsoft Foundry 和 Google Cloud Vertex AI 上。配套还提供了名为 commerce-builder 的 Claude Code 插件，用命令即可生成新智能体的骨架或检查已有实现。
不拆分成子智能体的判断
技术上最容易引发争论的，是整体结构的取舍。Anthropic 明确反对在前面放一个意图路由器，也反对按领域各立一个子智能体。
理由很直接：购物对话本身就难以切分。购物车内容、客户偏好、此前的往来都握在主智能体手里，每一次移交都会丢失一部分。移交还会让 token 消耗成倍上升，并给响应额外增加数秒。何况领域之间本来就互相重叠，一个退货问题就需要同时看订单历史、购物车和商品目录。
替代方案是智能体技能。技能的指令会加载进已经持有对话历史的那个智能体内部，因此可以在不付出移交代价的前提下拆分功能。Anthropic 表示，在多个企业落地场景中，带技能的单一智能体在质量上同时胜过单一超长提示词方案和子智能体方案，成本与延迟方面也更有优势。子智能体仍适用于深度调研这类相对独立的任务。
放进系统提示词还是拆成技能，界线按出现频率来划：涉及全体对话三分之一以上的内容进提示词，其余进技能。安全相关规则、品牌约束、用户的关键属性则不论频率，一律放在提示词里。
把界面组件当作工具
购物场景的回应，用界面组件比用文字更合适：商品卡片、行程表、资费方案对照表都是如此。
蓝图没有让模型输出自定义标签，而是把每个组件定义成一个工具。present_products、present_itinerary 之类的调用带有类型化参数，服务端校验之后才交给客户端渲染。由于这些调用原生存在于消息历史中，重新载入对话不需要额外的解析逻辑。用户说“就要第一家酒店”时，智能体能从刚才的展示中定位到对象，也是同一个原因。
延迟与成本的打磨
对体感速度的处理相当具体。一次回应的输出规模在 500 到 700 个 token，若不做流式输出，加载动画会持续接近 5 秒。蓝图的做法是组件成型一个就推送一个，同时用平实的语言显示进度，从而在实际处理时间之外单独缩短体感等待。参数流式到位就立即执行工具调用的方式，据称把数秒的空白压到了几百毫秒。
成本方面的主角是提示词缓存。缓存按前缀命中，因此请求要从最不易变的信息开始排列。把时间戳放在系统提示词开头，会让每次请求都击穿缓存，属于要避免的写法。缓存命中的读取只需新鲜 token 十分之一的费用，写入缓存则有约 1.25 倍的溢价。调校得当的部署，命中率据称能达到 90 至 99 个百分点的区间。记忆抽取也被移出对话流程，交给独立进程处理，Anthropic 测得的事实召回率比在对话内保存的方式高出 13 个百分点。
涉及资金流转、写入操作和标识符的处理，一律要经过代码层的关卡。模型只负责提议，是否执行由程序决定。
总结
这份蓝图，是 Anthropic 对每个做购物智能体的团队都会碰到的结构性问题给出的答案：不拆子智能体而用技能扩展能力，界面组件按工具做类型化，触及资金的操作交给代码拦下。发布时间正对着年末购物季，但既然以 Apache 2.0 公开，对任何设计对话式智能体的人来说，这份材料都值得一读，不限于电商场景。
