高效商务智能体结构指南
内容提要
本文介绍如何用Claude构建商务智能体，核心架构是单一模型在标准循环中运行，配备技能和工具，而非多个子代理。关键要点包括：技能优于子代理、UI组件作为工具、优化延迟和成本、使用提示缓存、分层记忆管理、安全规则在代码层执行、通过评估快照而非对话来测试。该架构可跨零售、旅行、电信等领域应用，并随模型升级而演进。
延伸解读
技能优于子代理
文章指出，在商务智能体中，使用技能（skills）而非子代理（subagents）能获得更好的质量和更低的延迟。子代理架构在每次交接时都会丢失状态，增加成本和延迟。技能则加载到主代理中，保留完整上下文，适合多意图的紧密耦合对话。仅在需要独立上下文窗口的窄任务（如深度研究）或已有专用代理的领域（如合规）时，才考虑子代理或交接。
UI组件作为工具
将UI组件（如产品轮播、行程）定义为工具，而非让模型输出自定义标签，可提高可靠性并简化历史记录存储。工具调用是原生格式，无需解析，且能记录屏幕布局，便于处理“第一个酒店”等引用。但需注意流式传输的粒度，可通过设置eager_input_streaming来获得令牌级流，但需处理罕见的模式违规。
延迟与成本优化
文章强调，在商务场景中，结果质量比边际延迟更重要，但需同时优化端到端延迟和感知延迟。减少模型轮次、并行工具调用、流式渲染组件和显示进度可降低感知延迟。提示缓存是最大的成本削减机会，通过将请求分为全局、会话和易变三段，可实现90-99%的缓存命中率。选择模型时，应通过评估套件扫描，并衡量每任务成本而非每次调用成本。
安全与评估
安全规则必须在代码层执行，而非仅依赖提示。模型只能提议，实际变更需通过人工审批。所有写入和渲染只接受服务器颁发的ID，防止幻觉或注入。第三方内容需经过消毒。评估应基于快照而非对话，覆盖正面和负面案例，并包含脏状态和跨能力请求。与领域专家合作编写案例，并利用真实事故作为评估来源。
Q&A
构建商务智能体时，为什么推荐使用单一模型加技能，而不是多个子代理？
因为商务对话是跨多个意图和轮次的紧密耦合会话，需要大量共享上下文。子代理架构中，每次交接都会丢失状态，影响响应质量，且增加令牌消耗和延迟。技能则可以在主代理中加载，无需交接，保持上下文完整，通常质量更高、成本更低。
在Claude中，如何决定将指令放在系统提示词还是技能中？
主要根据使用频率：如果指令在大多数轮次中都需要，就放在系统提示词中；如果只在特定情况下需要，就放在技能中。通常，与约三分之一或更多流量相关的指令应放在系统提示词中，其余放在技能中。
为什么将UI组件作为工具调用，而不是让模型输出自定义标签？
因为将UI组件作为工具调用更可靠：模型对工具调用的训练比自定义标记更好，能保证格式正确；避免在系统提示词中定义标签导致上下文膨胀；且工具调用以原生格式存储在消息数组中，便于历史对话的加载。
如何降低商务智能体的延迟？
从两个层面降低延迟：端到端延迟和感知延迟。端到端延迟可通过减少模型轮次（如预加载上下文、使用更智能的模型、并行工具调用）、优化工具后端和选择更快的模型来降低。感知延迟可通过流式传输组件和显示进度来改善。
提示缓存如何帮助降低商务智能体的成本？
提示缓存基于前缀，缓存命中的输入令牌读取成本仅为未命中的十分之一。商务流量适合缓存，因为系统提示词和工具定义在会话间相同。通过将请求分为全局、会话和易变三段，并保持全局段字节一致，可以实现90-99%的缓存命中率，显著降低成本。
商务智能体如何管理长期记忆？
长期记忆存储在外部系统（如数据库）中，而非模型内。记忆分为存储、写入和读取三个部分。存储时使用类型化记录，并考虑数据隐私和合规。写入时使用异步提取器，避免在用户交互中增加延迟。读取时分为三层：始终在上下文中、按需预取和通过查找工具访问。
商务智能体如何确保安全？
安全规则在代码层执行，而非仅依赖提示。具体措施包括：模型只能提议，实际执行由人通过审批流程控制；写入和渲染只接受服务器颁发的ID；对费用等受监管内容，服务器提供批准文案；对交易上限进行强制；对第三方内容进行消毒。
如何对商务智能体进行评估？
评估应基于快照而非对话，即构造测试状态和用户消息，然后评估最终状态和渲染响应。要覆盖多种场景，包括核心请求、上下文相关请求、安全和品牌案例、界面评估以及跨能力请求。同时，要包含负面案例，并与领域专家合作编写测试用例。
