高效电商 AI 智能体解剖指南 | 选自 Anthropic 的 Claude 博客
内容提要
本文介绍构建高效商业智能体的架构指南，强调采用单智能体循环配合技能和工具，而非子智能体，以提升质量并降低成本。关键点包括：将UI组件作为工具、优化延迟与缓存、分层记忆管理、编排层强制执行安全规则，以及通过状态快照评测系统。该架构旨在适应未来模型升级，并支持多团队协作。
延伸解读
为何单智能体优于子智能体
文章指出，商业对话常横跨多个意图和轮次，需要共享大量上下文。子智能体架构在移交时会损失状态，导致回答质量下降，并增加Token消耗和延迟。相比之下，技能加载到已掌握全部对话历史的主智能体中，避免了移交成本。因此，除非任务范围狭窄且独立，否则应优先采用单智能体加技能的设计。
UI组件作为工具的优势
将UI组件设计为工具，而非自定义标签，可提高可靠性并简化历史记录处理。工具调用以原生格式存在于消息数组中，重新加载对话时无需解析。但需注意流式传输粒度：顶层参数需缓冲，可能影响感知延迟。可通过设置eager_input_streaming跳过缓冲，但会失去Schema保证，需配合重试机制。
缓存优化与延迟控制
提示词缓存是降本关键，商业流量缓存命中率可达90%-99%。请求应按变化频率排序：全局段、会话段、易变段，并将易变内容置于末尾，避免破坏缓存。延迟优化需同时关注任务完成延迟和感知延迟，可通过减少轮次、加快工具、并行调用及流式呈现组件来改善，但不应牺牲智能水平。
安全规则必须由编排层强制执行
提示词无法可靠执行安全规则，编排层需强制实施。模型工具调用不能直接改变业务状态，写入操作需经审批；只接受服务器签发的ID，防止幻觉或注入；交易上限需基于最终状态检查，并串行化写入；第三方内容必须清理，防止提示词注入。这些措施确保安全边界不依赖模型行为。
Q&A
构建商业智能体时，为什么推荐使用单智能体加技能而不是子智能体？
因为商业对话通常是紧密耦合的，横跨多个意图和轮次，需要共享大量上下文。子智能体架构每次移交都会损失部分状态，影响回答质量，并消耗更多Token和增加延迟。而技能加载到主智能体中，没有移交成本，且能提供类似的模块化能力。实际部署比较显示，配备技能的单智能体方案在质量上更优，成本和延迟也更低。
在商业智能体中，如何决定将指令放在系统提示词还是技能中？
主要根据使用频率：如果内容与三分之一或更多流量相关，应放入系统提示词；否则放入技能。安全和法律规则、品牌限制、关键用户事实等重要指令必须始终放在系统提示词中。如果已有信号可预测需要加载的技能，可由编排层在第一次模型调用前注入。
为什么商业智能体应该将UI组件作为工具？
因为商业智能体的大多数响应是UI组件，需要输出结构化Schema。将UI组件作为工具，模型可以使用类型化参数调用，服务器验证并发出事件，客户端渲染。这样组件以原生格式存在于消息数组中，便于重新加载历史对话，且比自定义标签更可靠。
如何优化商业智能体的延迟？
从端到端延迟和感知延迟两方面入手。减少轮次（提前加载上下文、提高模型智能、并行调用工具）、加快工具（优化后端、尽早分发工具调用）、提高Token生成速度（选择合适的模型和配置）。感知延迟方面，组件一形成就开始流式呈现，并展示工作过程。
商业智能体如何利用提示词缓存降低成本？
提示词缓存是最优先的降本手段。将请求按变化频率从低到高排列：全局段（系统提示词和工具定义）、会话段（用户上下文和对话历史）、易变段（当前时间等）。技能作为工具结果加载，每轮滚动缓存断点。最佳部署缓存命中率可达90%-99%。
商业智能体如何实现跨会话记忆？
记忆应存储在外部系统中，而不是模型内。存储时使用数据库中的类型化记录，按人索引（对商家智能体）。写入时异步提取事实，避免增加延迟。读取时分三层：始终放在上下文中的固定事实、每轮预取相关事实、通过查询工具按需获取。同时需考虑隐私和合规，提供查看、更正、删除功能，并设定保留期限。
商业智能体如何确保安全？
安全规则必须由编排层强制执行，不能依赖提示词。模型只能暂存变更，最终由人或策略执行；写入和渲染只接受服务器签发的ID；交易上限必须检查写入后的状态；第三方内容必须经过清理。
如何评测商业智能体？
评测状态快照而不是整段对话，构造待测试状态并追加用户消息。覆盖正向和反向用例，包括核心请求、依赖上下文的请求、安全与品牌用例、界面评测、跨能力请求。与领域专家合作编写评测，使用真实事故案例。
在大型组织中，如何管理多个团队协作构建商业智能体？
采用所有权跟随系统的原则，每个技能和工具归一个团队负责。每项改动需随附评测用例，CI运行匹配的用例集。智能体作为整体部署单元，纳入发布日历，逐步向金丝雀用户发布，并保留关闭单个技能的开关。
