过去一年里，我们与零售商、市场平台、旅游、娱乐及电信等多个商务行业团队合作，基于Claude构建了商务代理。这些代理已投入生产，企业客户使用后发现购物车金额增加，卖家运营效率提升。它们共享一个简单的架构：Claude作为核心，运行在代理循环中，配备一套技能、工具和完善的评估体系。
本文面向构建此类（或其他面向消费者）代理的工程师及技术领导。第一部分介绍架构设计（一次性决策），第二部分讲述延迟与成本优化，第三部分涵盖生产环境中的内存、安全、评估及跨组织扩展。
架构设计
什么是商务代理？
商务代理是简化在线目录买卖流程的智能代理。部分代理面向消费者，负责搜索、比较、替代及组装订单，如零售购物车、旅游行程、手机套餐变更或演出票务。部分代理面向企业，处理销售咨询、促销活动及库存定价管理。
核心架构是一个标准代理循环：围绕目标推理，探索上下文，通过工具执行操作，学习技能流程，提出澄清问题，观察结果直至完成目标。没有意图路由器或领域特定子代理的分割。
工程实践
技能而非子代理
商务代理需覆盖多类别多意图，初看似乎适合为每个领域创建子代理。但实际中，商务对话是紧密耦合的多意图多轮会话，需共享大量上下文。子代理架构中，每次切换都会丢失状态，影响响应质量并增加延迟和成本。
领域间边界不清晰，退货流程可能同时需订单历史、当前购物车和产品目录，子代理方案要么重复访问，要么中途切换。随着模型智能提升，单一代理加载更多技能和工具变得可行且优越。
代理技能提供类似模块化和上下文控制，避免切换成本。多次企业部署对比显示，单一代理加技能在质量、成本和延迟上均优于多子代理或单提示方案。
子代理适合被主代理作为工具调用，处理独立复杂任务，如深度研究子代理负责文档检索、代码执行、数据模型遍历，最终只返回简洁答案。
已有专用领域代理（如药房、金融服务）时，可通过任务切换让专用代理直接与用户交互，区别在于对话所有权的转移。
系统提示还是技能？
决定将指令放入系统提示还是技能，关键看使用频率。加载技能需额外模型调用，频繁需求放系统提示，偶尔需求放技能。一般超过三分之一流量相关内容放系统提示，其余放技能。
若技能可由已有信号预测（如用户来源页面），建议在调用模型前注入，节省加载技能的调用。
关键指令如安全、法律、品牌约束及用户重要信息应始终放系统提示。
例如，产品搜索因几乎所有会话都会用，放系统提示；长尾功能放技能。参考实现中，购物代理提示包含基础信息、购物车和结账语义及展示规则，技能包括搜索发现、购买研究、规划目标、客户服务和记忆个性化。
商家代理同理，技能覆盖性能洞察、目录列表、库存操作、定价促销和营销活动。
工具设计
构建代理工具应基于已有核心系统和业务逻辑。商务公司已有搜索排序、购物车、偏好存储、库存系统、促销引擎、销售分析等多年调优的系统，代理工具应调用这些系统，而非重写逻辑。工具边界是系统逻辑结束、模型判断开始的分界。
例如，调用search_products时，结果应已排序，代理负责筛选展示。
工具结果即上下文，返回模型推理所需字段，剔除无关信息（如每条搜索结果的图片URL）。必要时在工具内重塑响应，添加下一步指令，尤其是错误处理时，提供具体指令代替错误码。
UI组件即工具
商务代理响应多为UI组件（产品轮播、行程、座位图、图表），需输出结构化schema而非纯文本。初期团队常让模型输出自定义标签，客户端解析，但随着界面复杂度增加，可靠性下降，且标签定义膨胀上下文，历史对话难以复用。
更稳健的做法是将每个UI组件做成工具调用，模型调用present_products、present_itinerary等，服务器验证丰富调用并发事件，客户端渲染。组件作为工具调用，消息数组中已有结构化数据，重载历史无需重新解析。
缺点是流式传输粒度较粗，服务器需验证完整参数后才发送，影响感知延迟。可通过设置eager_input_streaming:true跳过缓冲，获得更细粒度流，但失去服务器端schema保证。评估显示Claude Sonnet及以上模型中schema违规极少，建议调用时加重试机制。
UI工具调用记录当前屏幕内容，便于理解用户指代（如“第一个酒店”），参数结构应与UI布局一致，按行和轮播排序，而非客户端重排的扁平列表。
提升速度与降低成本
延迟对商务体验至关重要，消费者界面尤为敏感。但我们发现，结果质量对留存、参与和购物车大小的影响远大于边际延迟提升。
因此应双管齐下：通过工程优化最小化端到端延迟，同时降低感知延迟（用户看到代理工作即感知进展）。
最小化任务完成延迟
任务完成延迟是模型调用次数乘以每次响应时间加工具处理时间之和。优化方向有减少调用次数、更快工具响应和更快模型输出。三者有时相互制约，目标是整体最小。
- 减少调用次数：复杂查询增加轮次，难控。提升模型智能和上下文相关性可减少轮次。关键经验包括提前加载相关上下文、使用更智能模型（如复杂任务用Opus，延迟敏感用Sonnet）、并行调用独立工具。
- 加快工具响应：优化工具后端逻辑，避免工具承担过多业务逻辑，调用统一后端接口。工具调用参数流式传输，调用完成即执行，减少等待。Claude Agent SDK默认支持。
降低感知延迟
感知延迟是用户感受到界面响应的时间。两种方法：
- 流式传输组件，逐步渲染页面，避免长时间加载等待。
- 显示进度信息，告知用户当前步骤（如“正在查找附近酒店”），可用工具参数或额外消息生成。
提示缓存
提示缓存是最大成本节约点，商务流量适合高缓存率。缓存读取成本远低于新请求，写入稍贵，但多次复用收益大。优秀部署缓存命中率达90%-99%。
缓存基于前缀匹配，顺序影响缓存效果。请求分为三段：
- 全局：系统提示和工具定义，跨会话不变，最热缓存。
- 会话：用户上下文和对话历史，会话内稳定。
- 易变：会话内变化，如当前时间、页面，放末尾，避免破坏缓存。
技能应作为工具结果加载，缓存于会话前缀。断点应随用户轮次前移，保证缓存最大化。
模型选择与配置
模型大小和努力级别权衡智能与延迟成本，应基于指标测量选择：
- 确定业务质量指标、最低接受分数及延迟成本预算。
- 全面评估所有候选模型和努力级别，结合实际流量权重。
- 细致分析结果，调整提示以适配模型，智能配置有时能减少复杂请求的轮次，降低整体延迟。
以完成任务成本为准，非单次调用成本。质量驱动采用和留存，支持未来迭代。
生产环境运行
会话持久记忆
记忆让代理延续用户关系，避免重复信息。长时记忆系统包括存储、写入和读取三部分。
- 存储：记忆存于数据库，非模型。事实为键值对，带类别和会话来源。商家代理按操作员区分，遵守权限。
- 写入：异步写入，独立线程提取对话事实，避免增加延迟，提升记忆召回率。工具调用保存事实延迟高且易遗漏。
- 读取：分层读取，记忆作为会话上下文一部分。
记忆含个人数据，需合规处理：限定记忆类型、提供用户查看修改删除接口、设置保留期限、支持按部署开关。
安全保障
安全从提示开始，但执行层面靠代码强制。财务操作如下单、支付、退款、价格变更均由后端控制，模型仅提议。
- 写操作仅接受服务器发放的ID，防止伪造。
- 交易限额严格执行，避免重复请求叠加超限。
- 第三方内容均经过清洗，防止注入攻击。
评估体系
评估非确定性系统行为，重点测试快照状态而非完整对话路径。模拟用户评估成本高且不稳定，适合发现覆盖盲点。
评估应涵盖：核心请求、上下文依赖请求、安全与品牌合规、界面渲染、多能力交叉请求。每个正面案例应有对应负面案例。
与产品、法律、运营、客服等专家合作设计评估，利用真实故障案例，推荐每个用户流程50-100个评估用例。
多团队协作
商务代理由多个团队共同构建，需明确工具和技能归属，变更附带评估用例，持续集成执行相关测试。
代理作为单一部署单元，变更先在金丝雀用户中发布，支持无部署关闭技能，关键时段冻结更新。
展望未来
本文描述的架构独立于具体模型，模型升级只需配置和评估调整。架构支持多种交互方式，如语音，支持主动行为。
未来部分流量将由代理代表用户购物，现有的溯源、审批规则可确保安全开放工具。
商务始终追求顺畅购物体验，代理极大简化流程。欢迎查看完整参考实现，涵盖消费者和商家代理，支持零售、旅游、电信和娱乐场景。
本文作者：Matthew Koen 和 Ali Shazal。特别感谢 Michael Segner、Rodrigo Olivares、Amandeep Khurana、Aiza Usman、John Lopus 等贡献者。
