本页目录3
- 商务代理推荐用单一代理循环而非意图路由+子代理，避免共享上下文丢失和延迟增加
- 高频功能（如产品搜索、购物车语义）放进系统提示，长尾功能用 Skills 覆盖，判断标准是使用频率是否超过1/3
- 把 UI 组件做成「呈现工具」（如 present_products）调用，能获得类型安全和原生消息历史兼容
- 提示缓存分三层（全局系统提示/工具定义、会话上下文、易变的时间戳类信息），目标命中率90-99%
- 资金操作、下单、退款等必须在框架层由人或既定策略执行，模型只能「分阶段」提出变更，不能直接调用改钱的工具
- 购物车/订单只接受本会话服务器实际下发过的产品ID，防止幻觉ID或用户粘贴的ID被当真
本文是对 Anthropic 官方文章「A guide to the anatomy of effective commerce agents」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/the-anatomy-of-effective-commerce-agents
这篇文章面向想用 Claude 构建「商务代理」（帮消费者搜索比价下单，或帮商家管理销售/促销/库存定价的代理）的团队，给出了架构、性能成本、生产安全与评估四方面的实践建议，并附带了参考实现仓库 anthropics/commerce-agents。
一、架构：单代理循环，而不是子代理路由
文章的核心架构判断是：商务对话往往在一次会话里紧密夹杂多个意图（搜索、比价、加购、结账、售后），因此应该用标准的单一代理循环——推理目标、探索上下文、用工具行动、用 Skills 学习具体流程、必要时反问用户、观察结果——而不是先做意图路由再分发给不同领域的子代理。理由是子代理架构容易丢状态、增加 token 消耗、拉长延迟。
系统提示 vs Skills 的取舍：文章给出一个经验法则——如果某项能力在对话中出现频率超过约三分之一，就直接写进系统提示（比如产品搜索规则、购物车语义、呈现规则）；使用频率更低的长尾能力（搜索发现的边缘场景、购物研究、客户关怀、个性化记忆等）用 Skills 承载。而安全红线、法律合规、品牌约束、用户的关键事实，始终留在系统提示里，不下放给 Skills。
工具设计上强调：工具应该直接调用已有的核心业务系统，而不是在工具层重新实现一遍业务逻辑；返回给模型的字段只保留推理真正需要的部分；出错时给出「怎么办」的指令，而不是单纯的错误码。
呈现型工具：把 UI 组件（如商品列表、行程卡片）包装成工具调用，例如 present_products、present_itinerary，而不是让模型输出自定义标签。好处是类型安全、天然进入对话历史；代价是会牺牲一些流式输出的粒度，可以用 eager_input_streaming: true 之类的设置来缓解。
二、做快、做省：延迟与成本
降低延迟的几条路径：
- 减少模型往返轮次——提前把可能用到的上下文预加载进来（比如从用户所在的产品页面推断意图）、复杂查询宁可用更聪明的模型减少试错轮次、能并行调用的工具就并行调用；
- 加速工具执行本身——工具后端不要重新实现业务逻辑，而是直接接现有系统；支持「急切分发」，工具参数一流出就开始执行；
- 降低「感知延迟」——边生成边流式展示 UI 组件的搭建过程，配合进度提示语（如「正在查找海边的酒店」），让用户不必等完整响应出来。
提示缓存建议按三层组织：
- 全局层——系统提示与工具定义，所有会话共用；
- 会话层——用户上下文与对话历史，一次会话内基本稳定；
- 易变层——时间戳、当前页面等每轮都可能变的信息。
目标缓存命中率在90%-99%区间，命中的输入 token 成本约为全新输入的十分之一，写入缓存本身有约1.25倍的溢价，但从第二次复用起就能打平。Skills 的内容作为工具结果加载进上下文前缀，同样能被缓存命中。原则是每一轮都尽量把缓存断点往前推进。
模型选择上，文章建议先定质量指标和及格线（任务完成率、答案相关性、事实准确性），再在候选模型和不同推理强度上跑一遍完整评估集；经验起点是商家侧分析密集场景用 Opus，消费者侧延迟敏感场景用 Sonnet；衡量成本时应看「完成一个任务的总成本」而非单次模型调用的成本。
三、上生产：记忆、安全与评估
跨会话记忆被定位为「属于系统而不是模型」的能力：用小的、结构化的记录（键/值/分类/来源会话）存储，商家场景要按个人而不是账号键控，避免共享登录导致记忆串号。写入建议异步进行（用独立线程读对话、抽取/更新事实），避免把记忆写入做成同步工具调用而拖慢响应——文中提到内部评估里异步提取比同步调用式记忆多出13%的事实召回率。读取则分三层：始终在上下文里的关键事实（如默认门店）、按当前请求预取的相关事实，以及需要时才调用的查找工具。
安全实践的核心原则是「模型只提议，人或既定策略去执行」：任何涉及资金移动或改变业务状态的操作（下单、支付、退款、改价、活动上下线）都不应由模型直接调用的工具完成，而应落到框架控制的、经过人工或平台确认的操作面上——比如消费者端结账工具只渲染购物车和按钮，后端根本不暴露真正扣款的方法；商家端每个写操作先生成一个「待确认变更」，只能通过门户按钮、CLI 二次确认、平台审批弹窗等真实渠道最终生效。
另外两条具体的防护措施：
- 只认服务器发过的ID：框架记录本会话里服务器实际下发过的所有ID，购物车、商家工具只接受这些ID，拒绝模型幻觉出的、用户粘贴的、或藏在第三方内容里的ID;
- 数量上限要顶得住重复请求：对票务分配、促销价等有限量物品，要在行级别加锁强制上限，并对同一会话内的购物车写入做序列化，防止并发工具调用绕过限购。
此外，任何第三方读回的内容都视为不可信输入，需经过统一的清理器处理（剥离控制字符、双向字符，防止伪装成对话或工具调用的注入文本，并限制长度）。
评估方法上，文章主张对「状态快照」评分而不是对整段模拟对话评分——直接构造好一个测试状态，追加一条测试用户消息，然后评估最终状态和渲染出的响应（包括最后一次写工具的参数），理由是模拟用户对话的方式需要更大样本、成本更高、也更难定位失败原因。评估案例分四类：核心请求（简单查询、多约束、多意图）、上下文相关请求（屏幕引用、购物车写入、记忆效果）、安全与品牌案例（注入尝试、越权读取、事实是否有据可查）、接口正确性（组件对不对、有没有超限、是否泄露内部标识符）。
多团队协作时，建议让工具/技能的归属团队（搜索、结账、定价等）各自负责相应用例和CI，完整评估套件在夜间和发布前跑一遍，变更通过金丝雀方式推出。
文章最后强调：这套架构本身是模型无关的——换模型时理想情况下只需要改配置、重跑一遍评估扫描，工具、Skills、评估集和安全策略作为长期资产不必随模型换代而重写。