Anthropic 发布了一份电商 Agent 架构指南，同时开源了参考项目 commerce-agents。

这份指南来自 Anthropic 过去一年与零售、电商平台、旅游、娱乐和电信团队合作的经验。官方把内容分成三部分。第一部分讲架构，第二部分讲速度和成本，第三部分讲如何投入生产。顺着这个次序读，整件事会清楚很多。

如果你需要在工作流中接入API，自由切换全球200+大模型，魔芋提供合规保障、财务开票、企业级网关、技术支持与定制服务，助力更高效地管理应用AI能力。

链接注册：https://www.konjac.ai/sign-up?aff=qBX9

一 先把 Agent 的结构弄明白

先想一个普通的购物场景。

用户对助手说，想给两个大人和两个孩子准备一套周末露营装备。Agent 要搜索帐篷、睡袋和炉具，比较价格与规格，确认库存，把合适的商品加入购物车，最后交给结账页面。中途用户还可能改预算、换品牌，或者追问退货政策。

这些动作看起来属于不同部门，对用户来说却是一件连续的事。购物车、偏好、商品和前面的对话，后面每一步都可能用到。

Anthropic 因此推荐一套很简洁的结构。

用户
  ↓
一个主 Agent
  ├─ System Prompt  放常用规则和安全要求
  ├─ Skills         按需加载具体流程
  ├─ Tools          调用搜索、库存、购物车等系统
  └─ Harness        检查权限、限额和人工确认

主 Agent 一直保留完整对话。它通过 Skills 学习具体流程，再用 Tools 查询或操作企业已有的系统。Harness 可以理解成 Agent 外面的一圈程序，它不负责聊天，专门检查哪些动作可以做，哪些动作必须先让人确认。

为什么没有给每项业务配一个子智能体

很多团队会给搜索、优惠、退货和客服各造一个子智能体，再让一个总 Agent 分派任务。这种设计看起来分工明确，放进电商会话里却容易出问题。

每次转交任务，都要重新传递购物车、用户偏好和对话历史。Anthropic 表示，一次交接可能花掉数倍 Token，并增加几秒延迟，信息也可能在传递中丢失。

业务范围也很难切干净。处理一次退货，可能要查历史订单，也可能要看当前购物车和商品目录。各个子智能体都接入这些数据，权限和工具会大量重复。继续把任务转来转去，系统又会更慢。

Skills 更适合这种连续会话。退货流程可以做成一个 Skill，直接加载给当前主 Agent。它学到了新的操作步骤，同时保留着前面的所有信息。

子智能体依然有用。深度研究这类独立任务可以交给它在单独的上下文中完成，最后返回一份简短结果。药品、金融等拥有独立合规要求的业务，也可以交给专用 Agent 完整接管。Anthropic 反对的是频繁交接，并没有否定所有子智能体。

常用内容放提示词，低频流程放 Skills

一条规则应该放进 System Prompt，还是做成 Skill，主要看它出现得有多频繁。

Anthropic 给出的起步参考值是三分之一。预计会影响三分之一以上流量的内容，可以直接放进 System Prompt。低频、专门的流程再做成 Skills。实际项目还要根据上线后的流量和评测调整，三分之一并非硬性标准。

购物 Agent 的商品搜索、事实来源、购物车与结账规则经常被用到，所以适合常驻。购买研究、长期购物计划、客户服务和个性化记忆等流程，可以在需要时加载。

安全、法律、品牌要求，以及坚果过敏这类重要用户信息，不管使用频率高低，都应该一直放在系统上下文中。

Tools 要调用企业已有系统

电商公司通常已经有搜索排序、库存、促销、购物车、订单和用户资料系统。Agent 没有必要重新实现这些规则。

当 Agent 调用 search_products 时，搜索系统应当先把商品排好顺序。模型只负责判断哪些结果符合用户要求，应该展示几个，以及怎样向用户解释。

工具也不用把后端返回的所有字段都塞给模型。价格、规格、库存和政策等判断所需信息可以保留，大量无关图片地址与内部字段可以删掉。上下文更短，模型也更容易抓住重点。

商品卡片和座位图也做成 Tools

购物助手很少只回复一段文字。它还要展示商品卡片、酒店列表、行程单、套餐对比和座位图。

早期做法常让模型输出自定义标签，再由前端解析。组件越来越复杂以后，标签格式容易出错，定义也会挤占提示词。

Anthropic 建议把每种界面组件做成一个 Tool。模型调用 present_products，服务端校验参数，客户端再把它画成商品卡片。工具调用会保存在消息历史中。用户接着说“选第一个酒店”时，Agent 能从上一轮参数中看到商品的排列顺序。

如果开启 eager_input_streaming，组件参数可以边生成边发给前端，页面会更早出现内容。代价是服务端不再等待完整参数做 Schema 校验，因此还要准备失败重试。

二 怎样让 Agent 更快、更省

Agent 慢，通常有三个原因。模型来回调用的轮数太多，工具本身执行得慢，或者模型输出速度不够快。优化时要看完成整项任务花了多久，不能只盯着某一次模型调用。

先减少无用轮次

用户从商品详情页打开助手，系统可以把当前商品信息提前放进会话。商家从活动看板进入，也可以预先带上活动数据。Agent 第一轮就拿到大概率会用的信息，无需再调用工具查询一次。

互不依赖的工具也可以并行执行。用户一次要买帐篷、睡袋和炉具，Agent 可以同时搜索三类商品。等一项搜完再搜下一项，会平白增加等待时间。

模型更强，有时也会更快。它更容易一次规划好工具调用，少走几轮。Anthropic 建议按完整任务测量成本和延迟。便宜模型如果经常多跑几轮，最后未必便宜。

工具能执行就尽快执行

工具参数会随着模型输出逐步生成。一个工具所需的参数已经完整时，Harness 可以立即开始执行，不必等同一轮的其他内容全部生成完。

Anthropic 称，这种提前派发工具的做法能把几秒的空等缩短到几百毫秒。Claude Agent SDK 默认会这样处理。若有多个并行工具，还可以让模型先生成最慢的那个调用。

让用户早点看到东西

总耗时暂时降不下来，页面也不必一直显示一个转圈图标。

一份完整的电商展示通常有 500 到 700 个输出 Token。等全部生成以后再渲染，用户可能要盯着空白页面五秒以上。更合适的做法是让商品和参数生成一个就展示一个。

Agent 查询数据时，页面还可以显示简短进度，例如正在查找靠近海边的酒店。任务总时间也许没有变化，用户至少知道系统正在做什么。

Prompt 缓存是省钱的重点

Anthropic 的 Prompt 缓存按前缀匹配，从开头一直复用到第一个发生变化的字节。缓存输入 Token 的读取价格约为新输入的十分之一，写入价格约为新输入的 1.25 倍。同一段前缀第二次使用时，额外写入成本就已经收回。

官方观察到，表现较好的电商部署能达到 90% 到 99% 的缓存命中率。这个数字是设计目标，不代表所有项目都会自动达到。

想提高命中率，请求内容可以按变化频率排列。

• 最前面放 System Prompt 和工具定义，这部分尽量保持完全一致

• 中间放用户资料与历史消息，同一会话内逐步增加

• 最后放当前时间、当前页面等经常变化的内容

很多团队会把当前时间写在 System Prompt 开头。时间一变，缓存从很早的位置就失效了。Skills 也应通过工具结果加载，让技能正文进入会话历史，后续轮次可以继续复用。

Anthropic 还观察到，在大约十万 Token 的上下文中，缓存读取速度约为新输入的 1.5 到 2 倍。缓存既省费用，也能缩短模型读取长上下文的时间。

三 投入生产以后怎么用

Agent 能完成演示，只能说明基本流程跑通。接入真实订单、价格和付款以后，记忆怎样存、安全由谁保证、改一次提示词会不会弄坏旧功能，这些问题才麻烦。

长期记忆交给后台处理

用户三月告诉 Agent 自己对坚果过敏，六月再来购物时，不应该重新说一遍。商家每周一都查看同样的三个活动，Agent 也可以记住这个习惯。

这些长期记忆要存进企业自己的数据库。每条记录包含一个简单字段、内容、类别和来源会话。用户还应当能够查看、更正和删除记忆，系统也要设置保留期限。

记忆写入可以异步进行。每轮结束后，单独的进程只读取用户与助手的对话文本，提取需要保留的事实，再写进数据库。工具返回的商品描述和评论不参与提取，避免把商家写的内容误记成用户偏好。

Anthropic 表示，这套异步方案不会增加当前会话延迟，在其内部电商记忆评测中，事实召回率提高了 13%。这个结果来自内部评测，具体项目仍要自己验证。

读取记忆时，常用的少量信息直接放进上下文。根据当前问题可以判断会用到的信息提前查询，其余内容等 Agent 调用工具时再取。

安全不能只靠提示词

提示词可以告诉模型不要擅自付款，程序还要保证它根本没有擅自付款的接口。

购物 Agent 的结账工具只展示购物车和下单按钮，模型能够调用的后端没有扣款方法。商家 Agent 修改价格、库存或营销活动时，也只会生成一条待确认变更。用户或企业审批流程同意以后，系统才执行。

Harness 还会记录服务器在当前会话中返回过哪些 ID。模型猜出的商品 ID、用户随手粘贴的 ID、评论里夹带的 ID，都不能直接用于写入或展示。

限购数量、折扣幅度和活动预算，则按照写入后的最终结果检查。同一会话中的写操作要排队执行，避免多个并行请求一起突破限制。

商品描述、评论、商家留言和外部网页都要当成不可信内容。系统先清理控制字符和伪造标签，再用固定标记包住。Agent 可以阅读这些内容，不能把里面的话当成系统指令执行。

评测从固定状态开始

多轮 Agent 很难只靠一句测试问题测准。前面购物车里有什么，用户说过哪些限制，工具返回过哪些商品，都会改变下一步结果。

Anthropic 推荐状态快照。测试人员先构造一份固定的购物车、消息历史和工具结果，再追加用户问题，最后检查页面展示和系统状态。这样更容易重复问题，也更容易判断是哪次改动造成了失败。

另一个模型扮演用户的模拟对话可以继续使用，它适合寻找没覆盖到的情况。用它衡量版本好坏时，两个随机模型会互相影响，成本和波动都比较高。发现具体问题后，最好把那段状态保存成固定测试。

正向和反向用例要成对出现。系统既要测试什么时候拒绝，也要测试什么时候照常执行。只测试拒绝，一个什么都不肯做的 Agent 反而可能拿到高分。

Anthropic 建议每条业务流程先积累 50 到 100 个真实案例。日常提交代码时运行高频功能、安全规则和受影响模块的测试，全量评测放到夜间和正式发布前执行。

commerce-agents 适合怎样落地

开源仓库提供购物 Agent 和商家 Agent 两套完整参考实现，包含零售、旅游、电信和票务四组演示，也提供 Claude Code 插件来生成项目、增加流程和编写评测。

团队可以先接商品搜索和详情查询，让未完成的接口明确返回不可用。等只读流程稳定以后，再接购物车、订单、库存和定价。涉及付款、改价和活动发布的动作，始终保留人工确认。

也要留意仓库写明的限制。示例中的公司、商品和人物都是虚构内容，不会真实下单、扣款或修改线上商品。演示项目没有身份认证，业务规则、权限和合规工作要由部署团队完成。仓库采用 Apache 2.0 许可证，目前不接受外部贡献，也没有持续维护承诺。

这份项目很适合用来搭第一版，也适合拿来检查现有系统。主 Agent 是否保留完整上下文，Skills 是否只装低频流程，Tools 是否直接调用已有业务系统，Harness 是否能在模型出错时拦住危险动作。把这几件事检查清楚，电商 Agent 才能从演示走到真实用户面前。

参考资料

• Anthropic 电商 Agent 架构指南

• commerce-agents 官方代码仓库