过去一年，Anthropic 与零售、平台电商、旅行、娱乐和电信行业的团队共同构建了多种商业 Agent。这些系统已经投入生产，部分企业客户观察到客单量提升和商家运营效率改善。它们也逐渐收敛出一套共同结构：一个处于标准 Agent Loop 中的 Claude，配合一组 Skills、业务工具和完整的评测体系。
这篇指南面向商业 Agent 和消费级 Agent 的工程团队。核心问题很具体：架构怎样保持简单，任务怎样更快完成，缓存怎样降低成本，长期记忆如何进入生产系统，以及涉及资金和业务写入时，哪些约束必须由代码执行。
1. 一个模型承担完整对话
Anthropic 将商业 Agent 定义为“简化在线目录中购买和销售过程的 Agent”。面向消费者的 Agent 可以搜索、比较、替换商品并组装订单，也可以规划行程、变更移动套餐或预留演出座位；面向商家的 Agent 则负责销售分析、活动运营、库存和定价管理。
推荐的核心架构是一个模型运行在标准 Agent Loop 中：围绕目标推理、探索上下文、调用工具执行操作、通过 Skills 学习流程、提出澄清问题，并持续观察结果直到任务完成。完整会话由同一个 Agent 持有，无需在入口增加意图路由器，也无需为每个业务域配置一个子 Agent。
商业对话往往跨越多个意图和轮次。购物车、待批准修改、用户偏好与对话历史彼此关联。频繁委派会丢失状态，还会增加 token 消耗和数秒延迟。Anthropic 在多个企业部署中的比较显示，单一 Agent 加 Skills 的方案在质量上持续优于“大而全的单提示词”和按业务域拆分的子 Agent，单任务成本与延迟也经常更低。
子 Agent 仍适合两类场景：一类是深度研究等边界清晰、需要独立上下文窗口的任务；另一类是已经拥有独立合规边界和完整交互循环的专用 Agent。判断标准是对话所有权。窄任务可以委派，完整业务流程可以正式交接。
2. 用访问频率划分 System Prompt 与 Skills
一组指令应该放进 System Prompt 还是 Skill，主要取决于 Agent 使用它的频率。加载 Skill 会额外消耗一个模型轮次，因此大多数会话都需要的内容适合常驻 Prompt，长尾能力适合按需加载。
Anthropic 给出的起点是：与三分之一以上流量相关的指令放进 System Prompt，其余内容放进 Skills。若页面来源等已有信号能够预测所需 Skill，可以由 Harness 在第一次模型调用前直接注入，省去加载轮次。安全与法律规则、品牌约束、过敏信息等关键用户事实始终进入 System Prompt。
在参考实现中，购物 Agent 的 Prompt 包含事实落地规则、购物车和结账语义、展示规则与商品搜索；搜索发现、购买研究、目标规划、客户服务和记忆个性化由 Skills 承担。商家 Agent 则把经营分析、商品目录、库存、定价促销和营销活动拆成独立 Skills。
3. 工具调用已有业务系统
成熟商业平台已经拥有搜索排序、购物车、用户档案、库存、促销、活动和销售分析系统，其中积累了多年业务规则与模型看不到的信号。Agent 工具应该调用这些系统，并把模型判断放在清晰的工具边界之后。
例如，search_products 返回的商品应已经完成排序。Agent 负责判断哪些结果符合用户目标、展示多少条以及如何组织界面。工具结果本身会占用上下文，因此只返回模型推理所需的字段，图片 URL 等重复数据应谨慎保留。错误结果也应提供可执行的下一步，如“查询库存时请包含商品 ID”，避免只给出一个通用 403。
4. 把界面组件建模为工具
商业 Agent 的输出经常是商品轮播、行程单、座位图或分析图表。Anthropic 建议把每种 UI 组件定义为带类型参数的工具，例如 present_products、present_itinerary 和 present_plan_comparison。服务端验证并补充工具调用，再向客户端发送渲染事件。
这种设计让组件调用以原生格式保留在 Messages API 历史里。重新打开旧会话时无需解析自定义标签，Agent 也能从上一次展示调用中理解“第一家酒店”或“左边第三项”等指代。工具参数需要真实反映最终布局，例如按界面顺序组织行和轮播，避免客户端再次重排扁平列表。
顶层工具参数通常需要在服务端缓冲后再验证，组件会分段到达。开启 eager_input_streaming: true 可以获得 token 级输入流，同时会放弃服务端 Schema 保证。Anthropic 的评测显示，Sonnet 级及以上模型很少产生 Schema 违规，但生产系统仍应准备重试路径。
5. 同时优化总延迟与感知延迟
任务完成延迟等于所有模型轮次的末 token 时间与工具处理时间之和，因此有三根杠杆：减少轮次、加快工具、提高 token 生成速度。它们可能互相制约，真正需要优化的是总和。
- **减少轮次：**提前加载高概率相关的页面上下文，选择更强的模型，并让模型在同一轮并行调用互不依赖的工具。生产任务平均超过约五轮时，更强模型经常凭借更好的规划缩短总时间。
- **加快工具：**优化工具背后的业务接口。Harness 还可以在每个工具参数生成完毕时立即派发，让执行与其余模型输出重叠。Anthropic 观察到，这种 eager dispatch 能把数秒空档降至几百毫秒；Claude Agent SDK 默认采用该方式。
- **降低感知延迟：**组件参数生成后立即渐进渲染，并根据工具参数展示简短进度。典型商业界面响应约为 500–700 个输出 token，缺少流式渲染时，用户可能面对五秒以上的加载动画。
Anthropic 也提醒，结果质量对留存、互动和购物车规模的影响经常大于边际延迟改善。速度优化需要守住任务完成率、相关性与准确性。
6. 让 Prompt Cache 承担主要降本任务
缓存输入 token 的读取成本约为新输入的十分之一，写入成本约为 1.25 倍；同一前缀第二次被使用时即可回本。Anthropic 见过的优秀商业部署达到 90%–99% 的缓存命中率，这也应成为系统初期的设计目标。在约 10 万 token 的上下文规模，缓存读取速度大约快 1.5–2 倍。
缓存按前缀工作。请求应按变化频率组织成三段：
- **Global：**跨会话保持完全一致的 System Prompt 和工具定义，在末尾设置缓存断点；
- **Session：**用户上下文与会话历史，同一会话内保持稳定；
- **Volatile：**当前时间、当前页面等高频变化信息，放在请求末尾。
时间戳或当前页面若出现在 System Prompt 顶部，每个请求都会在开头破坏缓存。Skills 应作为工具结果加载，使 Skill 正文进入对话前缀并随历史一起缓存。每一轮还要把最新缓存断点向前滚动到当前用户消息末尾，让搜索结果等较长工具输出在后续轮次中直接命中缓存。
7. 用评测选择模型与 Effort
模型规模和 Effort 都是在智能、延迟与成本之间做选择。团队应先确定质量指标和最低门槛，以及 p50、p99 延迟与成本预算，再让完整评测套件遍历所有候选模型和 Effort。Anthropic 建议分析任务较重的商家 Agent 从 Opus 开始，重视响应速度的消费者 Agent 从 Sonnet 开始。
不同模型往往需要分别调整 Prompt。较小模型需要更多显式说明，较大模型会严格执行一些曾被旧模型忽略的指令。更强配置有时还能改善 p90、p99 延迟，因为复杂请求所需轮次更少。
成本应按“完成一个任务”计算，单次模型调用价格无法反映额外轮次和失败重试。结果接近且预算允许时，指南倾向选择更强的智能水平，为未来六个月的产品增长保留质量空间。
8. 长期记忆进入业务数据库
长期记忆需要解决三个问题：怎样存、怎样写、怎样读。小型档案可以使用扁平 Markdown；大多数生产级商业 Agent 最终会采用已有数据库。每条事实可以是包含键、短值、类别和来源会话的小型类型化记录。
商家侧记忆应按操作人员保存，并在读取时遵守个人权限。共享商家账号内，不同角色看到的事实范围可能不同。用户偏好和健康约束等记忆也属于个人数据，系统需要明确允许保存的类型，提供查看、更正和删除入口，设置保留期限，并允许按部署区域关闭记忆功能。
记忆写入应异步完成。独立线程或进程在每轮结束后读取对话并创建、更新或删除事实，不占用用户当前轮次的延迟。Anthropic 的内部商业记忆评测显示，这种方式让事实召回率提高了 13%。提取器只读取用户与助手文本，忽略工具结果，避免把商品描述或评论误存为用户事实。
读取可以分三层：几乎每次都需要的小型固定事实常驻上下文；与当前请求相关的事实按轮信号预取；其余事实通过查询工具获取。全部记忆都属于 Session 段，放在 Global 缓存断点之后。
9. 由 Harness 执行安全规则
商业操作涉及资金和难以撤销的业务变更。Prompt 可以说明安全行为，真正的约束由 Harness 代码执行，并在消费者端与商家端共享。
- **模型只负责暂存：**下单、付款、退款、调价和发布活动都由 Harness 控制。消费者端由真实按钮提交订单，Agent 后端接口不提供扣款方法；商家端的写工具只生成带服务端 ID 的待审批变更，批准后才能调用
apply_change。 - **写入与渲染只接受服务端 ID：**Harness 记录当前会话实际收到的 ID。购物车、商家工具和展示工具只接受这份集合里的 ID，拒绝幻觉生成、用户粘贴或评论中植入的标识。
- **按结果状态检查交易上限：**商品数量、折扣幅度、补货量和活动预算等限制都对写入后的最终状态执行。单会话写入需要串行化，避免并行调用叠加后越过上限。
- **净化第三方内容：**商品、评论、政策、卖家消息和已存记忆都作为不可信输入，统一移除控制字符、双向文本字符、伪造围栏和仿冒对话或工具调用，并设置长度上限。Prompt 同时约定：围栏中的文本只用于陈述，不能触发操作。
受监管的费用和披露文本由服务端提供经批准的原文，模型只选择适用的产品。系统在真正应用修改时还会按当前规则再次检查，避免使用暂存时已经过期的限制。
10. 用状态快照评测非确定性系统
模型 API 是无状态的，输出取决于 System Prompt、工具和 Messages 数组。团队可以直接构造任意会话状态，追加测试消息并运行 Agent，然后评估最终状态、渲染结果和最后一次写入参数。
这种 Snapshot Eval 比逐步检查 Agent 路径更稳定。模拟用户评测适合发现覆盖缺口和做整体体验检查；稳定测量仍适合把发现的问题固化成状态快照。测试应包含繁忙首轮、较长历史和相互矛盾信息等困难条件，防止所有用例都从干净上下文开始。
完整套件需要覆盖核心请求、依赖上下文的请求、安全与品牌规则、界面输出、多能力交叉任务。每个正向用例都应有对应的负向用例，例如“应该执行”与“应该拒绝”、“直接处理”与“应该提问”。注入测试还要区分用户消息中的指令注入和商品名、评论、网页片段等工具结果里的数据面注入。
Anthropic 建议每条用户流程先积累 50–100 个评测用例，并与产品、法务、商家运营、客服和品类管理等领域专家共同编写。生产事故和真实会话是最有价值的新增用例来源。
11. 让多团队共同维护一个 Agent
大型商业组织中的搜索、结账、定价、营销技术、客服和商品平台会按各自节奏发布。一个团队对 Prompt、Skill 或工具的修改，都可能通过共享上下文影响其他能力。
每个 Skill 和工具应有唯一所有者，共享 Prompt 由平台团队管理通用部分，业务团队管理对应领域段落。变更提交时同时提供正向、负向和相邻能力边界用例。Pull Request 上的 CI 运行高流量核心用例、全部安全用例、变更所属能力及相邻边界用例；共享 Prompt 变化则运行完整套件。完整套件还应每晚和每次正式发布前执行。
Agent 作为单一部署单元进入发布日历。Prompt 与 Skill 先进入 Canary 人群，每个 Skill 都要有无需重新部署即可关闭的开关，业务高峰前也要遵守冻结期。
12. 架构可以跨越聊天界面
这套架构的大部分组成与具体模型解耦：工具连接现有系统，Skills 编码既有流程，Evals 把产品需求写成测试，Harness 执行业务政策。模型升级时，团队可以修改配置并重新运行评测，其他部分继续工作。
同一 Agent 还可以进入语音界面，或在票价下降时主动提醒用户。未来，商店的一部分访问者会是代表用户购物的外部 Agent。来源追踪、变更暂存与人工审批规则既能约束自有 Agent，也能帮助平台安全地向外部 Agent 开放工具。
Anthropic 同时发布了 anthropics/commerce-agents 参考实现，包含消费者和商家 Agent，以及零售、旅行、电信与娱乐票务的可运行示例。这篇文章由 Matthew Koen 和 Ali Shazal 撰写。