Anthropic 放出了一份电商智能体的架构指南，同时在 GitHub 上开源了参考实现 anthropics/commerce-agents，覆盖购物智能体、商家智能体，以及零售、旅行、电信和票务四类场景的框架与评测工具。文章由 Ali Shazal 和 Matthew Koen 撰写。
开篇的建议朴素得有些反直觉：一个模型，一个标准智能体循环，长尾能力交给 skills，工具直接调已有的后端系统。
技能优于子智能体
这份文档把”skills，不用子智能体”放在架构原则的第一条。理由是子智能体架构的交接过程是状态有损的，质量会掉。Anthropic 称，在他们的对比里，单智能体加技能的组合在质量上稳定超过两种替代方案——一个万能提示词打天下，以及拆成多个子智能体。
系统提示词和 skills 之间怎么分，给的是一条频率规则：三分之一以上的请求会用到的指令写进系统提示词，其余放进 skills。购物场景里商品搜索几乎每个会话都会碰到，所以留在提示词里。
界面组件也被当成工具来处理，而不用让模型吐出自定义标签。后一种做法在生产环境里的可靠性一直不好，模型输出的标签格式没有强约束。
缓存命中率决定延迟账单
性能这节的干货集中在缓存上。文档称生产环境的缓存命中率能做到 90% 到 99%，缓存读取的价格只有新 token 的十分之一。做法是把请求切成三段并固定顺序：全局段放系统提示词和工具定义，会话段放用户上下文，易变段放当前状态。
有一个坑写得很直接：把时间戳或者当前页面放到系统提示词顶部，缓存每次请求都会失效。这个错误在电商场景里很常见，因为开发者习惯把”当前购物车”塞到最前面。文档还给了一个参考量级，电商类回复通常在 500 到 700 个输出 token。
选模型的方法论是把整套评测集在所有候选模型和推理档位上跑一遍，质量指标与延迟成本预算一起看，不分开评。
安全不能只靠提示词
生产部署这节的立场很硬：提示词是安全行为的起点，在电商里却不能是执行点。支付、退款、改价这类动作一律要经服务端暂存与审批。文档描述的机制叫 ID 级访问控制——harness 为每个会话记录服务端交给模型的每一个 ID，只有这份记录里的 ID 才能被写入或渲染接受。模型自己编出来的商品 ID 直接被挡在外面。
记忆同样被推到模型之外：长期记忆存进自家数据库，用带类型的记录（键、值、类别、来源会话），由另一个线程或进程异步读会话并增删改事实。异步抽取让事实召回率提高了 13%。
评测放弃了模拟多轮对话，采用快照方式：构造测试状态，追加一条用户消息，给结果打分。建议的起步规模是每条用户流程 50 到 100 个用例，正反例成对出现，并覆盖依赖上下文的请求和横跨多个能力的请求。
Anthropic 说这些智能体已经在线上跑，企业客户看到了更大的客单量。具体客户名字没有公开。
参考来源：Anthropic 官方博客、GitHub 仓库 anthropics/commerce-agents、CocoLoop；缓存命中率、13% 召回提升与 500-700 输出 token 等数字均引自该文档。