打造高效商业智能体：架构、优化与生产指南
近一年来，多家零售、电商平台、旅游服务、娱乐及电信运营商团队，与技术方合作开发商用AI智能助手，这类工具已经在生产环境中稳定运行。企业客户使用后，不仅购物车转化率有所提升，商家的运营效率也得到了显著优化。经过实践总结，这类高效的商用智能助手普遍采用一套简洁统一的架构：让AI模型运行在标准的智能交互循环中，搭配专属技能集、工具调用接口与完善的评测体系。
本文面向正在开发这类商用智能助手的工程师与技术团队负责人，内容主要分为三个核心模块：首先是只需一次性规划的基础架构设计，其次是兼顾性能与成本的优化策略，最后是生产环境落地所需的记忆管理、安全管控、评测体系，以及团队规模化协作的方法。
商用智能助手的核心定义
我们将商用AI智能助手定义为：能够简化线上商品目录中买卖双方交互流程的智能工具。这类工具分为两类面向不同用户的形态：面向消费者的助手可以帮助用户搜索商品、对比选项、查找替代产品并组装订单，比如整合零售购物车、规划旅行行程、办理手机套餐变更，或是为演出活动临时锁定座位；面向企业商家的助手则可以解答销售咨询、执行促销与营销活动、管理库存与定价策略。
这类智能助手的核心运行逻辑，是让AI模型在标准的智能交互循环中工作：围绕用户目标进行推理、探索对话上下文、通过工具调用现有业务系统、通过技能集学习处理流程、主动提出澄清问题，并观察每一步操作的结果，直到完成用户的全部需求。这套架构没有前置的意图路由模块拆分对话，也不需要按业务领域划分的多个子智能体协作。
架构选型：优先使用技能而非子智能体
商用智能助手需要覆盖多品类、多意图下的大量功能，很容易让人想到为每个业务领域单独开发子智能体。但实践证明，这种架构并不适合商业场景：商业对话往往是高度耦合的会话，横跨多个意图与多轮交互，需要共享大量上下文信息。
在子智能体架构中，购物车数据、临时变更内容、用户偏好与对话历史都由中央编排器持有。每次将任务移交子智能体时，都会丢失部分会话状态，这不仅会降低子智能体的回答质量，还会额外消耗数倍的Token，增加数秒的响应延迟。同时，业务领域很难被完全拆分，比如退货流程同时需要订单历史、当前购物车与商品目录数据，为每个领域设置子智能体要么需要重复开放访问权限，要么只能在任务执行中途移交，进一步加剧状态丢失的问题。
随着AI模型能力的提升，更长的上下文窗口、更多的技能与工具支持，正在逐步放宽这类架构限制。相比之下，智能体技能集既能提供按领域划分的模块化能力与上下文控制，又不会产生子智能体的移交成本——技能指令会直接加载到掌握完整对话历史的主智能体中，无需额外的会话状态传递。
我们对比了多家企业的部署方案，结果显示，采用技能集的单智能体架构，在回答质量上始终优于“单提示词包打天下”和子智能体设计，同时单任务的成本与延迟也普遍更低。
只有两种场景适合使用子智能体：一是将其作为工具调用，交给范围狭窄、相对独立且适合专用上下文窗口处理的任务，比如深度研究类子智能体，负责搜索阅读文档、编写运行代码、遍历数据模型，最终只返回精简后的结果给主编排器；二是当某个业务领域已经拥有独立合规边界的专用智能体时，比如药房或金融服务的专属助手，可以直接移交任务，由该智能体接管会话直接与用户协作直到完成。
两者的核心区别在于会话的控制权：移交会让领域智能体成为用户的直接对话方，而委派则仍由中央编排器掌控会话，在同一轮交互中反复调用子智能体，每次调用都会带来质量损失。
提示词与技能的分配：按使用频率决策
决定将一组指令放在系统提示词还是技能中，首要依据是智能助手的使用频率。加载一个技能会消耗一次模型调用，因此，大多数会话轮次都需要的通用指令，应该放入系统提示词中。当然，这也需要结合流量分布与实际评测的智能体行为来调整。
一个实用的初始原则是：凡是覆盖三分之一及以上流量的功能，无论是上线前的预期还是生产环境的实际数据，都应该放入系统提示词；其余低频功能则放入技能集。如果已经有信号可以预测需要加载的技能，比如用户从哪个页面进入助手，可以由编排层在首次模型调用前直接注入该技能，省去额外的技能加载轮次。
安全与合规规则、品牌限制、用户关键信息（比如过敏史）等重要指令，都应该始终放在系统提示词中。对于商用智能助手，商品搜索属于几乎每次会话都会用到的功能，应该放入提示词；而长尾功能则由技能集承载。
在官方参考实现中，购物类助手的提示词包含事实依据约束、购物车与结账逻辑、展示规则与商品搜索功能，其余能力则通过以下技能覆盖：搜索发现、购买调研、目标规划、客户服务与记忆个性化。商家类助手采用相同的拆分逻辑，其技能集包括业绩洞察、目录与商品信息、库存运营、定价与促销，以及营销活动管理，每个运营领域对应一个专属技能。
智能体工具的工程规范
我们曾在通用工具设计指南中介绍过智能体工具的开发方法，在商业场景中，有两点尤为重要：
基于现有核心系统构建工具
商业企业通常已经拥有搜索排序、购物车、用户档案存储、库存管理、促销引擎、销售分析等成熟系统，这些系统封装了经过多年调优的业务逻辑，也包含模型无法直接获取的业务信号。智能体工具应该直接调用这些现有系统，而非重新实现业务逻辑，工具的边界应该恰好位于现有系统的逻辑终点，也就是模型开始做出决策的位置。
比如，当智能体调用search_products时，返回的结果应该已经完成排序，智能体的工作仅需判断哪些结果最符合用户目标、需要展示多少内容以及如何呈现。
工具结果仅保留必要上下文
只返回模型推理所需的字段，其余内容全部丢弃。最常见的反例是在搜索结果中附带图片URL这类无关信息。必要时，可以在工具内部重塑原始响应格式，如果无法从数据中直接推断下一步操作，可以附加简要的下一步指引。
这一点在错误场景中尤为重要：相比错误代码，模型更能从明确的操作指令中获益。比如，不要仅返回笼统的403错误，而应该附上错误处理说明：“查询库存时请提供正确的商品ID。”
将UI组件转化为工具调用
商用智能助手的大多数响应并非纯文本，而是UI组件，比如商品轮播、旅行行程、座位图或数据图表。这意味着智能助手需要输出结构化Schema而非普通文本。
部分团队最初会让模型输出自定义标签，再由客户端解析，但随着产品界面复杂度提升，这种方案会逐渐失效：一是模型对自定义标记格式的训练不足，嵌套组件越多，格式可靠性越低，仅靠提示词无法保证数据格式始终正确；二是标签定义存放在系统提示词中，每新增一个组件都会膨胀上下文，修改标签也可能导致提示词其他部分出现回归；三是历史对话会以只有自定义解析器才能读取的格式保存，重新加载对话时要么需要客户端再次解析原始消息，要么需要额外维护一份非模型API原生格式的副本。
经过实践验证的可靠方案，是将每个UI组件都作为工具。模型通过类型化参数调用present_products、present_itinerary或present_plan_comparison，服务器验证并补充调用参数后触发事件，由客户端负责渲染。由于这些组件本身就是工具调用，它们已经以原生格式存在于消息数组中，重新加载旧对话时无需再次解析。
这种方案的代价在于流式传输的粒度：工具调用的每个顶层参数都需要在服务器端缓冲以完成验证，因此即使开启流式传输，UI组件的子内容也只能分批到达，会影响用户感知到的延迟。如果需要实现Token级流式传输，可以在工具定义中设置eager_input_streaming: true，这种方式会跳过缓冲步骤，但也会放弃服务器端的Schema校验保障。
在我们的评测中，主流的AI模型极少违反Schema规范，但仍建议在调用外层增加重试机制，以应对偶发的格式错误。此外，展示工具还会为智能助手保留屏幕状态记录，当用户提到“第一家酒店”或“左数第三个座位”时，页面布局会保存在消息数组中，具体位于最近一次展示调用的参数内。要让这种机制生效，工具参数必须如实反映渲染后的布局，参数结构应该与UI结构保持一致，比如按顺序组织为多行或轮播，而非给客户端一个可自行重新排列的扁平列表。
兼顾性能与成本的优化策略
商用智能助手的性能优化需要同时从端到端延迟与感知延迟两个维度入手，同时通过缓存实现成本控制，所有优化都不能以牺牲智能水平为代价。
延迟在商业场景中至关重要，面向消费者的界面对延迟的容忍度极低。但我们在多款智能助手产品中观察到，真正推动用户留存、互动量与购物车金额的核心因素，是回答的准确性与任务完成度，相比之下，缩短几毫秒的延迟对指标的影响远不如回答质量。因此，我们需要从两个维度解决延迟问题：一是通过工程实践降低端到端实际延迟，二是优化用户感知到的延迟，让用户在等待过程中感受到任务正在推进。
每个用户都有自己的延迟预算，以下方法可以让智能助手在不牺牲智能水平的前提下，将响应控制在预算范围内。
降低实际任务完成延迟
任务完成延迟等于所有模型调用的最终Token生成时间与工具处理时间的总和，我们可以通过三个杠杆优化：减少模型调用轮次、加快工具处理速度、提升Token生成效率。这三个杠杆有时会相互冲突，因此需要优化的是总延迟而非单一指标。
减少模型调用轮次
查询越复杂，所需的模型调用轮次越多，这通常不受直接控制，但更强的模型能力与更完整的上下文，可以帮助智能助手用更少轮次完成任务。我们在实践中总结了三个关键经验：
- 提前加载高概率需要的上下文：如果用户从商品详情页打开助手，或是商家从营销活动仪表盘进入助手，可以将当前页面的数据直接放入会话上下文，后续对话很可能与该页面内容相关，直接从上下文提取信息无需额外调用工具。
- 提升模型智能水平：更智能的模型可以更高效地规划与调用工具，减少任务的总轮次，这种收益往往会超过Token生成速度较慢的负面影响。如果你的业务查询普遍较复杂，或是生产数据显示单任务平均需要五轮以上的调用，那么能更快完成任务的模型通常就是更智能的选择，具体选型需要结合流量分布通过评测确定。
- 支持模型并行调用互不依赖的工具：商业场景经常需要并行执行多项操作，比如同时搜索多种商品、查询多份政策文档，或是从多个销售数据源读取记录。并行调用工具可以避免这类互不依赖的查询额外消耗轮次，提示模型在一轮调用中同时使用多个工具，并将所有结果作为工具结果数组在一条用户消息中返回。
加快工具处理速度
- 优化工具自身的后端逻辑：部分工具确实需要扇出多个调用，比如商家助手执行“获取今日概况”查询时，需要分别读取销售、库存与营销活动状态。但我们经常发现，工具边界变成了拼接缺失后端逻辑的地方：一次库存可用性检查，可能先调用商品目录获取SKU信息，再逐店调用库存服务、履约服务获取截止时间，随后在工具代码中应用替代规则与到店自提资格，最终返回结果。这类工具承载了过多领域知识，规则变更时难以保证正确性，也承担了本应属于上游系统的逻辑。当发现需要在工具中编写这类逻辑时，正确的做法是构建一个可以直接回答该问题的后端接口，再由智能体工具直接调用。
- 尽早分发工具调用：工具参数与其他Token一样，会从模型中流式生成。因此，编排层可以在每个工具调用的参数生成完成后立即执行，在模型仍在流式输出其他并行工具或内容块时处理结果。我们曾通过这种方式将数秒的等待时间缩短到几百毫秒，主流的AI助手SDK默认也采用这种机制。为了最大化延迟优化效果，应该提示模型优先输出最慢的工具调用。
优化用户感知延迟
感知延迟是用户从开始等待到界面首次出现响应的时间，在面向消费者的场景中尤为关键，因为交易过程中的任何等待阻力都会影响结账率与收入。以下两种方法无需修改模型即可缩短感知延迟：
- 组件生成后立即流式呈现：一条完整的商用智能助手响应通常包含500到700个输出Token，如果不使用流式传输，用户需要等待至少五秒才能看到完整结果。展示工具的每个参数一旦流式生成，就可以发送到客户端并逐步渲染页面。
- 实时展示工作进度：当智能助手收集上下文时，可以用简洁的语言为每一步操作显示简短进度，比如“正在搜索海边的酒店”。可以根据工具已有参数自动生成这类文字，比如使用商品搜索的查询词，也可以给工具添加用户-facing消息参数，提示模型生成对应的进度说明。
通过缓存降低成本
提示词缓存是最值得优先考虑的降本手段，商用场景的流量非常适合使用缓存。读取缓存的输入Token成本仅为新Token的十分之一；写入缓存虽然需要支付约1.25倍的溢价，但同一前缀第二次使用时即可回本。面向消费者的应用流量通常较大，只需使用默认的5分钟缓存有效期，就有机会达到非常高的缓存命中率。
我们观察到，最佳的商用智能助手部署，缓存命中率可以达到90%到99%，从项目初期就应该以这个范围为设计目标。我们的经验还显示，在约10万Token的规模下，读取缓存Token的速度会比新Token快1.5到2倍，Token数量越多，性能收益大致呈线性增长。
缓存基于请求前缀匹配，系统会从缓存中读取内容，直到遇到与上一次请求不同的第一个字节。因此，不仅上下文的内容很重要，内容的排列顺序也会影响缓存命中率。可以将一次请求分为三个部分，按变化频率从低到高排列：
- 全局段：包含大部分系统提示词与工具定义，每个会话都完全相同，这是最稳定的缓存命中部分，在规模化流量下几乎不会过期。需要确保该段在不同轮次与会话之间逐字节相同，并在末尾设置缓存断点。
- 会话段：包含每位用户的上下文与对话历史，不同会话之间内容不同，但同一会话内保持稳定，位于全局段之后。
- 易变段：包含会话内会发生变化的内容，比如当前时间或当前页面。应该将其放在请求的最末端，可以作为带标签的内容块放入最新的用户消息中；如果模型支持中途系统消息，也可以作为system角色消息追加到消息数组中。我们最常见的错误，是将时间戳或当前页面放在系统提示词开头，导致每次请求都会悄悄破坏缓存命中率。
这里还有两个重要的实现细节：第一，技能应该作为工具结果加载，而非追加到系统提示词，这样技能正文会进入对话前缀，并随前缀一起缓存。第二，每一轮请求都需要将缓存断点向前滚动：一次请求允许设置的断点数量有限，因此应该将最新的断点移到每一轮用户消息的末尾，这样每轮请求都可以从缓存中读取累积的对话历史，包括搜索响应等较长的工具结果。
选择合适的模型与配置
模型大小与推理强度设置需要在智能水平、延迟与成本之间做好权衡，两者都需要通过实际测量来选择：
- 确定核心指标与底线：选定业务真正依赖的质量指标，比如任务完成率、回答相关性与有据可查的准确性，确定不可低于的评测分数，同时设定p50、p99延迟与成本预算。
- 全量遍历测试：用完整的评测套件测试所有可能的模型与推理强度组合。商家类助手的任务偏重分析，建议从更高性能的模型开始；消费者类助手更看重延迟，建议从平衡性能的模型开始。如果已经有生产流量，可以按照真实查询分布为测试结果加权，让数据做出最终选择。有时更高性能的模型在促进购物车转化的任务上表现更好，足以覆盖相对更高的成本；有时则未必。
- 仔细解读测试结果：有两件事经常让团队感到意外。第一，提示词通常是针对特定模型调优的，直接使用同一套提示词测试其他模型时，可能表现不佳。小模型通常需要更明确的指令，而大模型则会严格执行小模型容易忽略的细节，在淘汰候选模型前，针对其失败案例迭代几轮提示词是成本很低的优化方式。第二，更智能的模型配置有时反而能在延迟上胜出，尤其是p90和p99延迟，尽管其Token生成速度较慢，但可以更好地规划工具调用，在复杂请求上减少总轮次。
应该衡量单任务的总成本，而非单次模型调用的成本。一个单价更低的模型如果需要更多轮次调用，或是失败率更高，实际成本反而更高。当多个选项的结果接近，且成本符合你的单任务经济模型与延迟要求时，优先选择更高的智能水平。质量会推动用户 adoption 与留存，随着模型不断进步，更高的智能水平也能为未来六个月的产品迭代预留空间。
生产环境落地的关键要素
记忆管理、安全管控、评测体系，以及团队规模化协作的方法，是决定智能助手能否顺利进入生产环境并稳定运行的核心要素。
跨会话的记忆管理
与用户建立的长期关系与交互历史非常重要，记忆可以让智能助手从上次对话中断的位置继续，而非每次都从零开始。比如，用户在三月提到过对坚果过敏，到六月就不需要再次说明；商家每周一都需要检查的三项营销活动，也不需要每次都重复点名。长期记忆是需要自行构建的系统，包含三个核心部分：记忆存储、记忆写入与记忆读取。
记忆的存储方式
记忆应该存储在你的业务系统中，而非模型内部。当用户档案较小且仅由智能助手读取时，使用扁平化的Markdown档案即可，但大多数生产级商用智能助手很快会超出这种方案的能力范围，更实用的替代方案是使用已有的业务数据库。每条记忆都是一条小型类型化记录，包含键（比如鞋码、默认门店、偏好报告频率）、简短值、类别以及该记忆来自哪个会话。部分键由你预先定义，每个用户都有；其余键则由记忆提取器自动发现。随着存储规模扩大，数据库仍然支持高效查询，你还可以围绕特定属性构建确定性行为，并将记忆与已有用户数据关联。
对于面向商家的助手，记忆应该按“操作员”而非“账户”索引，因为商家登录账户通常由多名操作员共享，每名操作员都需要独立的档案，读取操作还必须遵守操作员的权限：门店经理的助手不应该回忆起区域经理的对话内容。
在商业场景中，智能助手的记忆会包含个人数据，最值得保留的记忆往往也是受监管最严格的内容，不同司法辖区的规则也存在差异。因此，应该将记忆视为数据处理设计问题，而非单纯的存储问题，实践中需要做到四点：
- 明确可存储的记忆类型：在写入路径上强制执行规则，每次保存都需要经过验证器，而非仅在提示词中规定。
- 提供用户管理记忆的途径：允许用户查看、更正与删除已存储的记忆，并将删除操作接入账户删除与数据请求流程。
- 设定记忆保留期限：几年前的用户偏好很可能已经过时，保留期限可以帮助记忆保持新鲜。
- 提供记忆的可配置开关：对于无法承担数据合规义务的地区，可以在不启用记忆功能的情况下运行助手。
记忆的写入流程
记忆的写入应该采用异步方式。在每轮对话结束时，或是长会话中每隔几轮，让独立线程或进程中的智能体读取对话内容，在存储系统中创建、更新或删除记忆，同时在会话进行中维护自己的工作上下文。这种方式不会增加用户-facing的对话延迟，在我们的内部商业记忆评测中，这种方式将事实召回率提升了13%。
最直观的替代方案是为主智能体提供一个保存记忆的工具，但对于延迟敏感的商用智能助手而言，这并不是最优选择。每次保存记忆都会在面向用户的轮次中增加一次工具调用，除非整个存储系统都已放入上下文，否则保存前还需要先读取现有记忆以更新或去重，这会额外增加一轮调用。同时，这也会让智能体在每一轮都增加一项决策，在我们的评测中，这种注意力竞争会导致记忆遗漏的问题。
将记忆提取器独立出来，还可以实现更精确的提示词控制。提取器仅读取用户与助手的对话文本，不会读取工具结果，因此商品描述或评论不会被误存为用户事实。其提示词会明确说明哪些内容属于可存储的事实，比如用户主动说明的尺寸、饮食限制、履约偏好，以及商家常用的物化视图；同时明确哪些内容不属于记忆范畴，比如商品信息中的内容或仅出现一次的细节。
记忆的读取策略
记忆的读取应该分为三层：
- 始终放入上下文的固定记忆：将一小部分高频依赖的事实放入每一轮的上下文，比如购物者的默认门店与履约偏好，或是操作员所在的门店与角色。
- 每轮预取的关联记忆：从触发技能预加载的同类信号中，预取与当前请求相关的事实，比如搜索鞋子时读取用户的尺码与品牌偏好，询问营销活动时读取操作员惯用的指标。
- 按需查询的剩余记忆：其余所有事实都通过查询工具按需获取。
记忆属于每位用户的会话上下文，因此所有记忆都应该放在会话段中，位于全局缓存断点之后。
安全管控：由编排层强制执行规则
提示词是安全行为的起点，但在商业场景中，不能仅依靠提示词强制执行安全规则。这类安全失败会造成不可逆的经济损失，一次提示词注入或不当的模型采样就可能绕过提示词规则。以下所有安全规则都应该同时在消费者与商家助手的代码中强制执行，且只定义一次，让所有运行环境共享。
模型仅负责暂存，最终执行需经人工或策略审批
任何模型工具调用都不能直接转移资金或修改业务状态。下单、支付、退款、价格变更与营销活动发布，最终都必须交给编排层控制的操作，而非直接由模型执行。
在消费者场景中，这种限制由系统结构保证：结账工具仅渲染购物车并提供下单按钮，智能体调用的后端接口根本没有扣款功能。在商家场景中，每个写工具都会生成一个带有服务器签发ID的暂存变更，只有当该ID通过真实交互界面批准后，应用变更的接口才会成功。批准可以来自操作员门户的按钮、命令行的确认，或是当助手运行在托管平台上时，由平台自带的工具审批提示完成。
真正应用变更时，安全护栏会根据当前限制重新检查，而非沿用暂存变更时的规则。无论使用哪种交互方式，核心模式都是一致的：模型仅能提出变更建议，最终审批必须经过业务已有的“发起与复核”流程。
写入与渲染仅接受服务器签发的ID
编排层会为每个会话保存一份记录，列出服务器曾交给模型的所有ID，任何写入或渲染操作都只接受这份记录中的ID。购物车仅接受本次会话中服务器返回过的商品ID，商家工具仅接受智能体确实读取过的商品信息ID与营销活动ID，任何其他途径出现的ID，无论是模型幻觉、用户粘贴还是藏在评论中的，都会在抵达后端前被拒绝。
同样的规则也适用于UI展示：展示工具仅接收ID，再由服务器自行补全商品、订单或变更记录，因此每张卡片只能渲染服务器亲自填充的内容。这项规则也适用于委派的子智能体：商家分析子智能体可以读取数据，但永远不能将新ID加入主智能体的允许写入ID集合。
对于费用、披露信息等受监管内容，模型仅负责选择需要披露的产品，所有文字都由服务器从已批准的文案中提供。商家助手也会将一批费用字段列入受保护清单，因此交易双方都不能修改或改写这些内容，评测会逐字节核对渲染结果。
交易上限需经得住重复请求校验
大多数商业界面都会限制单个用户的购买数量，比如门票配额、促销定价或反欺诈限制。智能助手会以真人点击按钮时不会出现的方式重试、改写请求并并行操作，因此执行上限时必须检查写入后的行项目状态。这样用户第二次提出“再加两个”时，不会叠加突破上限；同一会话中的购物车写入也需要串行执行，避免单轮内的多个并行工具调用合并后超出限制。
商家变更也采用相同的规则，检查价格变动、折扣幅度、补货数量与营销活动预算的上限，并保护任何变更都不得触碰的字段清单。该规则可以概括为：根据请求执行后的最终状态强制执行所有限制，而非仅检查单次请求；同一会话中的写入操作必须串行化。
第三方内容必须经过清理
商业场景中的大多数上下文都由外部人员撰写，比如卖家、评论者与竞争对手，因此后端读取的所有内容都必须视为不可信输入，并通过统一的清理器处理。所有由第三方生成的工具结果，包括商品信息、评论、政策、卖家消息与已存储的记忆，在交给模型之前都必须经过清理，并封装在带有固定标签的边界内。
清理器会移除控制字符与双向文本字符，删除任何模仿边界标记的内容，解除伪装成对话轮次或工具调用的文本，并限制内容长度。这套设计可以防止恶意商品信息冒充系统指令，或用垃圾内容填满上下文。提示词则承担另一半契约：边界内的文本仅可作为需要转述的材料，绝不能作为需要执行的指令。
评测体系：发布非确定性系统的关键
从微小的提示词修改到新增工具，任何改动都可能以难以预测的方式改变智能助手的行为，真正出现回归的地方往往并非你正在修改的部分。评测体系可以让你在部署前发现这些问题。我们曾在通用智能体评测指南中介绍过基础实践，本节聚焦商用智能助手的专属评测方法。
评测状态快照而非整段对话
模型API是无状态的，因此智能助手的输出是系统提示词、工具与消息数组共同作用的结果。这意味着商业对话可能到达的任何状态都可以直接构造，因此创建评测用例的方式是：构造待测试的会话状态，追加测试用户消息，然后让智能助手从该状态开始运行。随后评判结果，包括最终状态、渲染后的响应与最后一次写入操作的参数。在大多数情况下，我们不建议评判智能体抵达结果的路径，因为这类测试既脆弱，又会限制实现方式。
用第二个模型扮演用户、再让裁判评判整段对话的模拟用户评测，并不适合测量性能。两个非确定性系统相互作用需要更大的样本量，每次试验的成本更高，结果更难评判，也很难定位失败的来源。这类评测适合用于发现覆盖盲区与整体观感检查，因此可以先用它们发现案例，再将每个案例转化为状态快照用例。
在复杂条件下测试行为
大多数团队都没有充分测试异常状态下的表现。评测用例不仅应该描述任务，还应该编码失败发生的前置条件。如果某种行为只有在首轮进行多次工具调用后才会出现，或是只有在对话上下文存在矛盾时才会触发，那么从干净状态开始的用例会在所有配置下通过，无法提供有意义的数据。我们观察到，大多数评测套件都塞满了这类干净状态用例，因此必须确保一部分用例从冗长、混乱或相互矛盾的对话历史开始。
覆盖全类型的评测用例
有效的评测既要测试期望行为，也要测试不期望出现的行为。每编写一个正向用例，都应该对应一个反向用例：每个“应该响应”的用例都要对应一个“应该拒绝”的用例，每个“直接执行”的用例都要对应一个“应该询问澄清”的用例。缺少反向用例是我们在评测套件中最常见的漏洞。
需要覆盖的评测类型包括：
- 核心请求用例：这类用例占据大部分流量，失败会影响多数会话，包括简单查询、多约束请求、商品与套餐问题，以及包含多个意图的消息。对于问答类请求，需要检查每个价格、库存状态与属性是否都能追溯到返回数据，缺少数据时智能体是否如实说明而非编造。
- 上下文依赖请求用例：比如指代屏幕上内容的请求、从前几轮延续下来的约束，以及对现有购物车的写入，记忆评测也属于这一类。需要检查记忆是否被正确提取、检索，并真正改变了回答结果。
- 安全与品牌合规用例：这类失败会造成金钱或信任损失，包括提示词注入尝试、读取其他用户数据的尝试，以及需要逐字节核对的受监管措辞。注入测试应该拆分为两种：用户自行在消息中写入指令的用户侧注入，以及埋在商品名、评论或工具结果返回的网页片段中的数据面注入。
- 界面交互用例：确保渲染了正确的组件、商品数量上限得到遵守，面向用户的文字中没有内部标识符，同时测试超时与空结果场景。
- 跨领域能力请求用例：操作员可能会提出同时需要多项能力的问题，比如“如果我将商品降价15%，库存是否足够满足需求？”，这既是定价问题也是库存问题。正确的回答应该暂存降价操作并附上库存预测，而错误的回答仅会处理其中一半。按单项能力编写的评测无法发现这类问题，因此需要为同时需要相邻两项能力的请求编写用例，并评判答案的两个部分。
与领域专家协作编写评测，使用真实事故案例
应该与亲眼发现过问题的领域专家合作设计测试用例，比如产品、法务、商家运营、客户服务与品类管理团队的成员。真实的生产故障是最好的评测用例来源。每条用户流程先准备50到100个用例是不错的起点。如上所述，确保用例类型足够丰富，生产环境的对话记录会源源不断提供新案例，尤其是棘手的边缘案例。编程智能体也适合用于生成额外的用例与对抗性变体。官方参考实现中包含一个AI助手代码插件，其中的评测编写技能采用了我们推荐的方法。
大型组织中的协作发布流程
在大型商业企业中，智能助手通常由多个工程团队共同开发。搜索、结账、定价、营销技术、客户服务与商品目录平台等团队，各自拥有智能助手依赖的系统，按照自己的节奏发布，也都会希望添加或修改工具、技能或提示词规则。智能助手不同于普通服务，它没有严格的模块边界来保护其他部分：定价团队的改动会与结账逻辑共享同一个上下文窗口。
一种很诱人的解决方案是将系统拆分为多个子智能体，每个业务单元一个，但正如前文所述，出于质量原因我们不建议这样做。以下是我们用于降低多团队协作风险的流程：
- 所有权跟随系统：每个技能与工具仅由一个团队负责。比如，定价团队负责促销工具与定价技能，客户服务团队负责订单、退货工具与客户服务技能。共享提示词的通用部分由平台级团队统一管理，其中各领域专属的小节则由对应领域的团队负责。
- 每项改动随附评测用例，CI运行匹配的测试集：提交技能的团队需要同时提交对应的测试用例，包括反向用例与相邻技能的边界用例。为每个拉取请求运行完整的评测套件既太慢又太贵，无法长期维持，因此应该构建一套CI测试集，包含覆盖最高流量请求的核心用例与全部安全用例。在此基础上，再运行与本次改动相关的测试：如果修改的是技能，就运行该技能自身的用例与相邻技能的边界用例；如果修改的是工具，就运行所有调用该工具的用例；如果修改的是共享提示词，就运行完整的评测套件，因为所有能力都会读取系统提示词。我们建议对多次测试后的通过率、缓存命中率与每轮成本设置合入门槛。每晚以及每次发布前运行完整的评测套件也是好的实践，可以暴露跨团队的回归问题。
- 将智能助手纳入统一发布日历：智能助手是一个整体部署单元，糟糕的改动会同时影响所有用户。先向小范围的金丝雀用户群逐步发布提示词与技能变更，保留无需重新部署即可关闭单个技能的开关，在业务高峰前冻结智能助手的更新，就像其他生产系统一样。
关于这类组织方式中的人类协作细节，可以参考相关的人机协作团队建设指南。
未来展望
本文介绍的大部分内容其实与模型本身无关。工具调用的是你已经在运行的业务系统，技能集编码的是你一直遵循的业务流程，评测体系是转化为测试用例的产品需求，编排层执行的是你原本就会为任何客户端落实的业务政策。AI模型会不断进步，当更好的模型发布时，这套架构只需修改配置并运行一轮全量评测，即可切换到新模型，其余部分可以继续正常工作。
产品交互界面的路线图也值得认真思考，这套架构会比聊天面板存在得更久。同一个智能助手可以通过语音交互工作，也可以在票价下降时主动采取行动，无需等待用户发起请求。对于已经具备评测与工具体系的团队而言，这些都只是展示层的优化项目。再往后看，访问你线上商店的一部分流量，将来自替用户完成购物的智能助手。那些让自家智能助手保持在安全边界内的来源追踪、暂存与审批规则，也正是你安全地向外部智能体开放工具的基础。
商业竞争始终会奖励那些让购买流程尽可能顺畅的公司，而智能助手可以让这件事变得容易得多。欢迎查看官方参考实现代码，其中同时包含消费者与商家助手的实现，提供可运行的零售、旅游、电信与娱乐场景示例。
