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