Anthropic 发布 Claude 电商智能体构建指南及参考实现

让在线买卖更便捷的智能体：架构、延迟与成本技术，以及评估实践。

在过去一年里，我们与商业行业的各类团队——零售商、市场平台、旅游、娱乐和电信服务商——合作，使用 Claude 构建商业智能体。

这些智能体已投入生产环境，企业客户在使用后看到了更大的购物车规模和更高效的卖家运营。它们还共享一个简单的架构：Claude 处于智能体循环中，配备一组技能、工具和一套强大的评估套件。

本文面向正在构建这类（或其他面向消费者的）智能体的工程师和工程负责人。第 1 部分介绍架构，这是你只需决定一次的事情。第 2 部分介绍延迟和成本。第 3 部分介绍生产环境：记忆、安全、评估，以及在组织内规模化推广这项工作。

参考实现

我们还提供了一个

蓝图

，帮助在 Claude 上构建商业智能体。它包含工程团队在数天内让商业智能体运行起来所需的框架、模式和护栏，并附有面向零售、旅游、电信和票务平台的购物智能体和商家智能体的参考实现。

anthropics/commerce-agents →

本指南内容

Part 1: The architecture
1. 什么是商业智能体？
2. 技能，而非子智能体
3. 系统提示词还是技能：按频率决定
4. 工程化智能体工具链
5. UI 组件即工具
Part 2: Making it fast and affordable
1. 最小化任务完成延迟
2. 感知延迟
3. 提示词缓存
4. 选择模型及其配置
Part 3: Running it in production
1. 跨会话存续的记忆
2. 安全：执行落在 harness 中
3. 评估：交付一个非确定性系统
4. 在大型组织中交付
展望未来

架构

一个模型运行在标准智能体循环中，用技能覆盖长尾场景，用工具调用你已经在运行的各种系统。这一切你只需决定一次。

什么是商业智能体？

我们将商业智能体定义为一种能够简化在线商品目录中买卖流程的智能体。

有些智能体面向消费者：它们负责搜索、比较、替代和组装订单。这可能是零售购物车、旅行行程、手机套餐变更，或是为某场演出预留座位。有些智能体面向企业：它们回答关于销售的问题、运行促销和营销活动，并管理库存和定价。

核心架构是一个运行在标准智能体循环中的模型：围绕目标进行推理、探索上下文、通过工具采取行动、通过技能学习流程、提出澄清性问题，并观察结果，直到目标达成。

它前面没有用于分割对话的意图路由器，后面也没有一组领域特定的智能体。

工程上下文

技能，而非子智能体

商业智能体必须覆盖众多类别和意图中的广泛能力，这使得人们很容易想为每个领域创建一个子智能体。

在实践中，这被证明并非最优，因为商业对话是一个跨多个意图和轮次的紧密耦合会话，需要大量共享上下文。

在子智能体架构中，编排器持有购物车或暂存变更、用户偏好以及对话历史。

每一次向子智能体的交接都是一次有状态损失的操作，这往往会影响子智能体回复的质量，进而影响整体回复的质量。除此之外，每次交接还可能消耗数倍的 token，并增加数秒的延迟。

这些领域也很少能干净地划分开来。一个退货流程可能同时需要订单历史、当前购物车和产品目录，这意味着按领域划分给子智能体的做法要么在各处重复这些访问权限，要么在任务进行到一半时进行交接。

随着模型变得越来越智能，它们也能处理更长的上下文、更多的技能和更多的工具，因此支撑当今放置规则的种种限制会随着每一代模型而逐渐放宽。

相反，智能体技能能为你提供类似的按领域模块化和上下文控制，却没有交接带来的额外开销，因为技能指令会加载到已经持有完整历史的主智能体中。

在我们对多个企业部署的对比中，配备技能的单一智能体在质量上始终优于“一个提示词包打天下”的设计和子智能体设计，而且通常每个任务的成本和延迟都更低。

子智能体真正能发挥价值的地方，是当编排器可以将它们作为工具来调用，去处理一个狭窄或自成一体的任务，而该任务能受益于拥有自己专属的上下文窗口。

一个常见的生产环境示例是深度研究子智能体，其中子智能体会搜索并阅读文档、编写并运行代码、遍历数据模型，并走入死胡同。所有工作都在一个或多个子智能体内部完成，只有一份精简的答案返回给编排器。

另一个例外是已经拥有自己专用智能体的领域。如果你的药房或金融服务体验运行着一个带有自身合规面的专用智能体，正确的做法可以是移交，即由该智能体接管任务，并通过自己的循环直接与用户协作，直到任务完成。

区别在于对话的归属权。移交让领域智能体成为用户的对话对象，而委派则保留编排器的主导地位，在单轮对话中让领域智能体进进出出，并在每一次交互中逐渐劣化。

系统提示词还是技能：按频率决定

决定把一组指令放进系统提示词还是技能中的主要因素，是智能体需要它的频率。加载一个技能会消耗一次模型轮次，因此智能体在大多数轮次都需要的内容通常放进系统提示词。

不过，这取决于你的流量分布情况，以及你的评估所显示的智能体行为。一个不错的起点是：任何与你三分之一或更多流量相关的内容，无论是在上线前预判到的还是在生产环境中观察到的，都放进系统提示词，其余的放进技能。

如果一个技能可以从你已经拥有的信号中预测出来，例如用户是从哪个页面跳转过来的，我们建议在首次模型调用之前就从 harness 中注入它，并跳过加载该技能的额外轮次。

关键指令，例如安全和法律规则、品牌约束，以及诸如过敏等关键用户事实，始终放在系统提示词中。

对于电商智能体而言，这意味着商品搜索放在提示词中，因为几乎每次会话都会用到它，而技能则承载长尾功能。

在我们的参考实现中，购物智能体的提示词包含 grounding、购物车和结账语义以及展示规则，以下技能覆盖其余部分：search-discovery、purchase-research、planning-goals、customer-care 和 memory-personalization。

商家智能体也以同样的方式拆分，其技能包括 performance-insights、catalog-listings、inventory-operations、pricing-promotions 和 marketing-campaigns，每个运营领域对应一个技能。

在提示词中

购物智能体

Grounding、购物车和结账语义、展示规则以及商品搜索。

购物技能

长尾部分

搜索与发现 · 购买调研 · 规划与目标 · 客户服务 · 记忆与个性化

商家技能

每个运营领域一个

绩效洞察 · 商品目录与上架 · 库存运营 · 定价与促销 · 营销活动

工程智能体工具

我们关于为智能体编写高效工具的文章涵盖了工具设计的总体原则。有两点在电商领域最为关键：

在你的核心系统与逻辑之上构建智能体工具。

一家电商公司已经拥有搜索与排序、购物车、偏好与画像存储、库存系统、促销与活动引擎、销售分析等等，每一项都编码了多年打磨的逻辑，并能看到模型永远无法获取的信号。

智能体的工具应当调用这些系统，而不是重新实现它们，而工具边界正是这些系统的逻辑结束、模型的判断接手之处。

例如，当智能体调用 search_products 时，返回的结果应当已经排好序；它的任务是决定哪些结果服务于用户的目标、展示多少个，以及如何呈现它们。

工具结果是上下文。

只返回模型用于推理的字段，其余全部丢弃。每一行搜索结果里的图片 URL 就是常见的罪魁祸首。

按需在工具内部重塑原始响应，包括在数据本身无法显而易见地给出下一步时，追加一个下一步。

这在错误场景中尤其重要，此时模型更需要的是指令而非错误码。例如，添加一条错误指令“查询可用性时请附带产品 ID”，而不是一个笼统的 403。

UI 组件即工具

大多数电商智能体的响应是 UI 组件而非文字，无论是商品轮播、行程单、座位图还是图表。这意味着智能体必须输出 schema 而非文本。

团队有时会先让模型输出自定义标签，然后在客户端解析它们。随着界面不断扩展，这种做法就会失效，原因如下：

模型对你的标记语言的训练程度不如对工具调用那么充分，因此随着嵌套组件的加入，可靠性会下降。仅靠提示词无法保证数据格式良好。
标签定义存在于系统提示词中，因此每新增一个组件都会让上下文膨胀，而每一次编辑都可能给提示词其他部分带来回归风险。
过去的对话最终会以一种只有你的解析器才能读取的格式存储，因此加载历史记录要么意味着在客户端解析原始消息，要么以模型 API 非原生的格式保留一份副本。

经得起考验的模式是让每个 UI 组件都成为一个工具。模型调用 present_products、present_itinerary 或 present_plan_comparison 并传入带类型的参数；你的服务器验证并丰富该调用并发出一个事件；然后你的客户端将其渲染出来。

由于这些组件就是工具调用，它们已经以原生格式存在于 messages 数组中，因此重新加载旧对话时无需重新解析。下面以及参考仓库中展示了一个演示工具的契约示例。

代价是流式传输的粒度。工具调用的每个顶层参数都会在服务器上缓冲以进行验证，因此即使开启流式传输，演示工具的子组件也是分步到达的。这会影响感知延迟。

要获得 token 级别的流式传输，请在工具定义上设置 eager_input_streaming: 为 true，这会跳过缓冲，同时也跳过服务器端的 schema 保证。

在我们的评测中，在 Claude Sonnet 级及以上的模型上，schema 违规非常罕见，但对于偶尔出现违规的情况，请将调用包裹在重试中。

演示工具还为智能体提供了屏幕上内容的记录。当客户说"第一家酒店"或"左边往下第三个"时，布局就在 messages 数组中，位于最后一次演示调用的参数里。

要做到这一点，参数必须反映渲染后的布局，因此要按 UI 的结构来组织它们，以有序的行和轮播的形式呈现，而不是让客户端重新排列的扁平列表。

让它变得快速且经济

从端到端和感知两个维度攻克延迟，并让缓存承担成本。这一切都不应为此消耗智能。

延迟在电商中很重要，而面向消费者的界面是最不容妥协的。然而，在智能体界面上，我们一直看到能够推动留存率、参与度和购物车金额等指标变化的，是结果的质量。

相比边际延迟的改善，答案是否相关、任务是否真正完成，对这些指标而言更为关键。

因此要从两条战线攻克延迟问题。一方面通过良好的工程实践将端到端延迟降到最低，另一方面同时降低感知延迟（因为观看智能体工作的时间会被感知为进展）。

每个用户都有一个延迟预算，以下技术能让智能体保持在这个预算之内，而无需为此消耗智能。

最小化任务完成延迟

任务完成延迟是各模型轮次上“生成到最后一个 token 的时间”加上工具处理时间的总和。这给了你三个可以努力的方向：更少的轮次、更快的工具、更快的 token。这些方向有时会相互竞争，因此要最小化的是这个总和，而不是其中任何一个单项。

更少的轮次

预先加载可能的上下文，提升模型智能，并让模型并行调用相互独立的工具。

更快的工具

优化工具自身的后端，并在工具的参数就绪时立即派发。

更快的 token

通过遍历你的评测套件来选择模型及其配置。

更少的轮次

查询复杂度会增加轮次，而这通常不在你的掌控之中。模型智能和相关的上下文有助于智能体以更少的轮次完成任务。我们在这一领域的一些关键经验包括：

预先加载可能的上下文。如果用户是从某个产品页面打开助手的，或者商家是从某个活动仪表盘打开它的，就把该页面的数据放进会话上下文中。对话很可能就是关于它的，而基于上下文作答不会产生额外的轮次。
提升模型智能。更聪明的模型可以减少完成任务所需的总体轮次，因为智能体能够更高效地规划并发出工具调用。这通常比其较慢的 token 速度更为重要。如果你的查询偏向复杂，或者生产环境显示每个任务超过约五轮，那么更快的模型往往就是更聪明的那个。具体哪个更快取决于你的流量，因此请通过扫描来选择，如下文“选择模型”部分所述。
让模型并行调用相互独立的工具。商业用例通常需要并行执行许多操作：无论是搜索多个产品、查询大量政策文档，还是从多个销售数据源获取记录。并行工具可确保多个独立查询不会额外消耗轮次。提示模型在一轮内调用多个工具，并在一条用户消息中以工具结果数组的形式返回结果（参见并行工具使用文档）。

更快的工具

优化工具自身的后端。 有时一个工具确实需要扇出调用——一个带有“获取今日快照”查询的商家智能体会通过三次独立调用读取销售、库存和活动状态。但我们经常看到工具边界变成了拼凑缺失后端逻辑的地方：一次可用性检查会针对 SKU 调用商品目录、按门店调用库存服务、为截止时间调用履约服务，然后在工具自身的代码中应用替代规则和自提资格判断，最后才作答。这个工具如今被领域知识压得过载，随着规则变化很难保持正确，并且承载着本应位于上游系统中的逻辑。当你发现自己在工具里编写这类逻辑时，解决办法就是用一个后端端点来回答这个问题，并通过一个智能体工具来调用它。
尽早派发工具调用。 工具参数像其他 token 一样从模型流式输出，因此执行框架可以在每个工具调用的参数完成时立即执行它，并在模型仍在流式输出其他并行工具或内容块时处理它。我们见过这种做法将数秒的间隔缩短到几百毫秒，而 Claude Agent SDK 默认就会这样做。你应该提示模型最先发出最慢的调用，以最大化延迟收益。

感知延迟

感知延迟是指用户感觉到屏幕有所反应之前所经历的时间。它在面向消费者的用例中尤为关键，因为任何交易摩擦都会影响结账率和收入。有两种技术可以在不触碰模型的情况下缩短它：

在流式生成的同时渲染组件。 一个渲染完成的电商响应通常有 500–700 个输出 token，如果不做流式输出，就意味着五秒甚至更久的加载转圈。把展示工具的每个参数在流式生成时同步发送给客户端，并逐步渲染页面。
展示工作过程。 当智能体在收集上下文时，用通俗的语言为每一步渲染一行简短的进度提示（例如“正在寻找水边的酒店”）。你可以用工具现有的参数来构建这行提示（比如商品搜索的查询词），或者额外添加一个 user_facing_message 参数工具，让模型来撰写这行提示。

上面两个面板运行的是同一个智能体，使用相同的工具和提示词，唯一的区别在于运行框架。总耗时大致相同，但用户看到内容出现的时间却大不相同。

提示词缓存

提示词缓存是你最大的成本削减机会，而电商流量非常适合使用它。缓存输入 token 的读取成本仅为全新 token 的十分之一，虽然缓存写入会有大约 1.25 倍的溢价，但一个被缓存的提示词前缀在第二次使用时就能收回成本。在面向客户、流量巨大的应用中，你有独特的机会利用最便宜的、默认 5 分钟过期时间的缓存来达到非常高的缓存命中水平。

我们见过的最佳电商部署运行在 90–99% 的缓存命中率，而这正是从一开始就应当设计的区间。我们的经验表明，在约 100k tokens 时，缓存 token 读取的速度也大约快 1.5 到 2 倍，而且 token 越多，扩展性相对越接近线性。

缓存是基于前缀的。一个请求会从缓存中读取，直到遇到与之前请求不同的第一个字节，因此重要的不仅是上下文里有什么，还有它的顺序。把一个请求看作三个片段，按它们变化的频率排序：

全局：大部分系统提示词和工具定义，在每个会话中都完全相同。这是你最热的缓存，在规模化场景下很可能不会过期。让它在各个轮次和会话之间保持字节级一致，并在其末尾放置一个缓存断点。
会话：每个用户的上下文和对话历史，它们在不同会话之间不同，但在同一个会话内保持稳定。这个片段排在全局片段之后。
易变：任何在会话内会变化的内容，比如当前时间或当前页面。把它放在请求的最末尾，可以作为最新一轮用户消息中的带标签块，或者在支持对话中途系统消息的模型上，作为追加到 messages 数组的 system 角色消息。我们见过的最常见错误，是把时间戳或当前页面放在系统提示词的开头，这会悄无声息地在每次请求时破坏缓存。

这里有两个实现细节需要记住。第一，技能应当作为工具结果加载，而不是追加到系统提示词中。这样技能正文就会落入对话前缀，并随之一起被缓存。

第二，在每一轮中把断点向前滚动：一次请求允许的断点数量有限，因此要把最新的断点移到每个用户轮次的末尾。这样每一轮都能从缓存中读取累积的历史记录，包括搜索响应这类较长的工具结果。

选择模型及其配置

模型规模和 effort 设置是同样的权衡——智能水平与延迟和成本之间的取舍——两者都应当通过实测来选择：

选定你的指标和底线。选定你的业务所依赖的质量指标（任务完成度、答案相关性、有据可依的准确性）、你不愿低于的评测分数，以及你的 p50 和 p99 延迟与成本预算。
全面扫描。在你考虑的每一个模型和 effort 级别上运行你的整套评测。对于商家智能体，我们建议从 Opus 起步，因为其任务偏重分析；对于消费者智能体，则建议从 Sonnet 起步，因为延迟的权重更大。如果你有生产流量，就按你真实的查询构成对结果加权。然后让数据来决定。有时 Opus 5 在加购驱动任务上的提升足以证明它相对 Sonnet 的成本差是合理的，有时则不然。‍
仔细阅读结果。有两件事经常让团队感到意外。第一，提示词是针对某个模型调优的，因此用某个提示词跑的一轮扫描，在它并非为其编写的其他模型上可能表现不佳。较小的模型通常需要当前模型能自行推断出的指令，而较大的模型会严格遵循较小模型所忽略的指令。在排除任何候选模型之前，针对每个候选模型的失败案例进行几轮迭代，是一个成本低廉的步骤。第二，更智能的配置有时会在延迟上胜出（最常见于 p90 和 p99），尽管其 token 速度更慢，因为它能更好地规划工具调用，并且在最复杂的请求上需要的轮次更少。

衡量每个已完成任务的成本，而不是每次模型调用的成本，因为一个需要更多轮次、或失败更频繁的更便宜模型，并不更便宜。当结果接近，且成本符合你每任务的经济性和延迟要求时，选择智能。质量才是推动采用和留存的关键，并为未来 6 个月随着模型变得更好而留出构建空间。

在生产环境中运行

记忆、安全、评估，以及在组织范围内扩展这项工作：是什么让一个智能体通过生产考验并持续留在那里。

最后，我们讨论是什么让一个智能体通过生产考验：记忆、安全、评估，以及在组织范围内扩展这项工作。

能跨越会话存续的记忆

你与客户之间的关系和互动至关重要。记忆让智能体能够在上一次对话中断的地方继续，而不是从零开始。一位在三月提到过坚果过敏的购物者，不应该在六月还要重复一遍；一位每周一都查看同样三个广告活动的商家，不应该每次都要重新说出它们的名字。长期记忆——那些应当跨会话留存的事实——是一套你需要构建的系统，它包含三个部分：事实如何存储、如何写入，以及如何读取。

存储记忆

记忆属于你的系统，而不属于模型。

当用户画像规模较小、且智能体是唯一读取方时，一份扁平的 markdown 画像就够用了。但大多数生产环境的电商智能体会很快超出这一模式，而切实可行的替代方案就是你已经在运营的数据库。一条事实就是一条小型的带类型记录：一个键（例如 shoe_size、default_store、preferred_report_cadence）、一个简短的值、一个类别，以及它来自哪个会话。有些键由你预先确定，每个用户都会有；其余的则由提取器自行发现。随着数据规模增长，数据库始终可查询，让你能够针对特定属性构建确定性的行为，并与你已经拥有的用户数据做关联。

对于面向商家的智能体，记忆应以个人而非账户为键。商家登录账号常常由多个操作员共用，因此每个操作员都需要自己的画像，而读取时必须遵守该操作员的权限：门店经理的智能体不应回忆起区域经理说过的事实。

在电商领域，智能体记忆涉及个人数据。值得记住的事实往往正是受监管最严格的那类，而不同司法管辖区之间的规则又各不相同。要把记忆当作一个数据处理的设计问题，而不仅仅是存储问题。在实践中，这意味着四件事：

确定你愿意保存哪些类型的记忆。要在写入路径上强制执行这一点，让每一次保存都经过一个校验器，而不是仅靠提示词来约束。
给用户提供查看、更正和删除所存内容的方式。把删除操作接入你的账号注销和数据请求流程中。
设定保留期限。几年前的偏好很可能已经过时，因此保留期限有助于让记忆事实保持新鲜。
记忆应当是一个按部署划分的开关。这样，那些无法承担这些义务的地区就可以在不启用记忆的情况下运行。

写入记忆

以异步方式写入记忆。在每一轮对话结束时，或在长会话中每隔几轮，让一个运行在独立线程或进程中的智能体读取对话，并在存储中创建、更新或删除事实，同时随着会话推进维护自己的工作上下文。

它不会给对话增加任何延迟，并且在我们内部的电商记忆评测套件上实现了高出 13% 的事实召回率。

显而易见的替代方案——让智能体调用一个工具来保存事实——对于延迟敏感的电商智能体来说是错误的选择。每一次保存都是面向用户的一轮对话中的一次工具调用，而且除非整个存储都在上下文中，否则一次保存需要先读取才能更新或去重，这本身就是一轮往返。

它还会在每一轮对话中给智能体多增加一个决策，而在我们的评测中，这种对注意力的争夺表现为遗漏的记忆。

将提取器分离出来还能让你精确地编写其提示词。它只读取用户和助手的文本，从不读取工具结果，因此产品描述或评论不会变成关于用户的事实。它的提示词规定了什么算作事实——已声明的尺码、饮食限制、配送偏好、商家常用的物化视图——以及什么不算，比如来自商品列表的任何内容或一次性细节。

读取记忆

分三层读取记忆。

始终在上下文中

一小组固定的事实会在每一轮对话中进入上下文：那些几乎每个请求都依赖的事实，比如购物者的默认门店和配送偏好，或者运营人员的门店和角色。

每轮预取

与当前请求相关的事实会按轮次预先抓取，来源与预加载技能时所用的信号相同：搜索鞋子会拉取尺码和品牌偏好，询问营销活动则会拉取运营者常用的指标。

置于查询工具之后

其他所有内容都置于查询工具之后。

由于记忆是按用户划分的上下文，因此全部放入会话段，位于全局缓存断点之下。

安全：执行落在管控框架中

提示词是安全行为的起点，但在电商场景中，它不能成为安全性的执行之处。这类故障涉及资金且往往不可逆，而一条提示词规则只需一次注入或一个坏样本就会被跳过。以下每条规则都在代码中强制执行，同时作用于消费者端和商家端智能体，并且只定义一次，让每个运行时共享同一套规则。

模型负责分阶段推进；由人或策略来执行

没有任何模型工具调用会转移资金或改变业务。下单、支付、退款、改价和营销活动上线，最终都落在由管控框架而非模型控制的动作上。

在消费者端，这是结构性的：结账工具渲染购物车并附带一个下单按钮，而智能体所调用的后端接口根本没有任何扣款方法。

在商家侧，每个写入工具都会产生一个带有服务器生成 ID 的暂存变更，而 apply_change 仅对已通过真实界面审批的 ID 才会成功：操作员门户中的按钮、CLI 中的确认，或当智能体运行在 Managed Agents 上时平台自带的工具审批提示词。

这些护栏会在应用时根据当前限制重新检查，而不是依据变更暂存时生效的限制。无论通过哪种界面，形态都是一样的：模型最危险的动作是提出建议，而审批会走你的业务中针对该类变更已经在使用的 maker-checker 流程。

写入和渲染只接受服务器签发的 ID

该执行框架会按会话记录服务器交给模型的每一个 ID，而这份记录是任何写入或渲染唯一会接受的键。

购物车只接受服务器返回给本次会话的产品 ID，商家工具只接受智能体实际读取过的商品列表和营销活动 ID。以任何其他方式出现的 ID——模型幻觉生成的、用户粘贴的、植入在评论中的——都会在后端看到它之前被拒绝。

同样的规则也覆盖 UI。展示类工具接收 ID，由服务器自己填充产品、订单或变更记录，因此卡片只会渲染服务器自己填充过的记录。

这条规则同样覆盖委派场景：商家分析子智能体只读取数据，但绝不会增加智能体可写入的 ID 集合。

对于费用、披露信息及其他受监管内容，模型负责选择披露哪款产品，而服务器则从已批准的文案中提供每一个字。相同的费用字段也列在商家智能体的受保护清单上，因此柜台两侧的任何一方都无法更改或转述这些字段，而评估会逐字节检查渲染出的字符串。

设有上限的交易必须对重复请求保持约束

大多数电商场景都会限制单个用户对某件商品的购买数量——用于票务配额、促销定价或欺诈控制——而智能体会以人类点击按钮时从未有过的方式重试、改写措辞并并行发起请求。

因此，上限是在写入后所处的行状态上强制执行的，这样第二次“再加两件”就无法叠加突破上限，而且同一会话的购物车写入会被串行化，使得单轮中并行的工具调用无法合并起来超过上限。

商家侧的变更也以同样的方式，对照价格变动、折扣力度、补货规模和活动预算的上限进行检查，此外还有一份任何变更都不得触碰的受保护字段清单。这条规则可以推广：对结果状态而非请求强制执行每一项限制，并按会话串行化写入。

第三方内容经过净化处理

在电商场景中，大部分上下文是由并非你的人撰写的——卖家、评论者、竞争对手——因此每一次后端读取都是不可信输入，都要经过同一个净化器处理。

每一个由第三方编写的工具结果，例如商品列表、评价、政策、卖家消息和存储的记忆，都会在模型看到之前经过净化处理，并被包裹在带有固定标签的围栏中。

净化器会剥离控制字符和双向字符，移除任何模仿围栏标记的内容，化解模仿对话轮次或工具调用的文本，并限制其大小，目的是阻止恶意商品列表冒充系统或占满上下文。

提示词承载着契约的另一半：围栏内的文本是供报告的材料，绝不能据此采取行动。

评估：交付一个非确定性系统

从微小的提示词改动到新增一个工具，任何变化都可能以难以预测的方式改变智能体的行为，而你交付的改动往往并不是导致回归的那个。评估就是你在部署之前发现这一点的方式。我们之前关于智能体评估的博客文章涵盖了通用实践。本节涵盖的是电商智能体的具体内容。

评估快照，而非对话

模型的 API 是无状态的，因此智能体的输出是系统提示词、工具和消息数组的函数。这意味着电商对话能够达到的任何状态都可以被直接构造出来。所以创建一个评估用例就意味着构造测试状态、追加测试用户消息，然后让智能体从那里开始运行。

然后对结果进行评分：最终状态和渲染出的响应，包括最后一次写入的参数。在大多数情况下，我们建议不要对智能体为达成结果所走的路径进行评分，因为这类测试用例脆弱且限制过多。

模拟用户评测，即由第二个模型扮演用户、由评判模型为整段对话打分，是一种糟糕的测量工具。两个非确定性系统交互需要更大的样本量，每次试验成本更高，更难评判，而且产生的失败难以归因。它们对于发现覆盖缺口以及对智能体做整体感觉检查是有用的，因此用它们来发现问题用例，然后把每个用例写成快照。

在严苛条件下评估行为

大多数团队未能正确测试注入的状态。一个用例应当编码失败的前置条件，而不仅仅是任务本身。如果某种行为只有在经历了一个繁忙的、包含多次工具调用的首轮对话之后才会出现，或者在会话早期出现矛盾之后才会出现，那么一个从干净状态开始的用例会在所有配置下都通过，无法提供有意义的数据。

我们观察到大多数测试套件都偏重于这类干净状态的用例，因此请确保你的一部分用例从冗长、混乱或矛盾的历史记录开始。

覆盖不同类型的电商智能体评测

有效的评测需要同时测试期望的行为和不期望的行为。

针对每一个正例，写出其对应的反例：每一个“应当拒绝”都要配一个“应当服务”，每一个“应当先询问”都要配一个“应当直接执行”。缺失反例是我们在测试套件中发现的最常见缺口。

评估以下方面：

核心请求，它们构成了你流量的主体，因为这里一旦失败就会影响大多数会话。这些包括简单查询、多约束请求、产品与套餐问题，以及多意图消息。对于这些问题，要检查每一个价格、库存状态和属性都能追溯到返回的数据，并且智能体在数据缺失时会如实说明，而不是凭空编造。
依赖上下文的请求，例如对屏幕上内容的引用、从先前轮次延续下来的约束条件，以及针对现有购物车的写入操作。记忆评估也归入这一类。要检查记忆是否被提取、检索，并改变了回答。
安全与品牌案例，这类失败会带来金钱或信任上的代价。这些包括注入尝试、读取其他用户数据的尝试，以及受监管用语——后者需逐字节检查。将注入拆分为两类：用户发起的注入，即指令来自用户自己的消息；以及数据面注入，即指令被植入到通过工具结果传入的产品名称、评论或网页片段中。
界面评估，确保渲染了正确的组件、条目上限得到遵守，并且面向用户的文本中没有内部标识符。还要测试超时和空结果的情况。
同时属于多个能力的请求。一位运营人员问：“如果我把这个降价 15%，我的库存够覆盖需求吗？”这既是一个定价问题，也是一个库存问题。正确的回答会把降价与附带的库存预测结合起来；错误的回答只做其中一个而跳过另一个。按能力分别编写的评估捕捉不到这种情况，因为每个评估只评判自己那一半。要为那些需要两个相邻能力协同的请求编写用例，并对回答的两部分都进行评分。

与 SME 一起编写评估，并利用真实事件

与那些 firsthand 看到失败的业务专家合作来设计测试用例，例如产品、法务、商家运营、客户服务和品类管理团队的成员。真实的失败是最好的评估素材，每个用户流程 50-100 个评估用例是一个不错的起点。

确保用例多样化，如上所述。生产环境的对话记录是获取新用例的绝佳来源，尤其是那些棘手的用例。编码智能体擅长生成额外的用例和对抗性变体。参考仓库包含一个 Claude Code 插件，其中带有一个按照我们推荐方法构建的评估编写技能。

在大型组织中发布

在一家商业企业中，智能体由许多工程团队共同构建。搜索、结账、定价、营销技术、客户服务以及商品目录平台各自拥有智能体所依赖的系统，各自按自己的节奏发布，并且各自都希望添加或更改某个工具、某项技能或某条提示词规则。

与一项服务不同，智能体没有严格的模块边界来保护其他部分：定价团队所做的一处更改会与结账共享同一个上下文窗口。

一个诱人的解决方案是把系统拆分成许多子智能体，每个业务单元一个。正如第 1 部分所讨论的，出于质量方面的原因，我们不建议这样做。相反，我们概述了降低多团队协作风险的流程：

归属关系跟随系统而定。每项技能和工具都有唯一的归属团队。例如，定价团队拥有促销工具和定价技能，客服团队拥有订单和退货工具以及客户服务技能。共享提示词中，通用部分由单一的平台级负责人拥有，领域特定部分则由领域负责人拥有。
每个变更都随附其测试用例，CI 则运行一组为该变更选定的用例。 贡献一项技能的团队也要贡献它的用例，包括负向用例以及与相邻技能之间的边界用例。在每个 pull request 上运行完整测试套件太慢、太贵，难以持续，因此改为从中构建一个 CI 集合。该集合将由一组核心用例构成，包含流量最高的请求以及所有安全用例。在此基础上，还要运行变更所触及内容的用例。对于一项技能，这意味着它自身的用例以及相邻技能的边界用例。对于一个工具，则是所有调用它的用例。对于共享提示词，则是完整的评测套件，因为所有内容都会读取系统提示词。我们建议对多次试验的通过率，以及缓存命中率和每轮成本设置门禁。每晚以及每次发布前运行完整套件也是很好的做法。跨团队的回归问题会在这些运行中被捕获。
智能体也应纳入发布日历。 它是一个部署单元，因此一个糟糕的变更会同时触达每一位用户。先把提示词和技能的变更灰度发布到一小批金丝雀用户，保留一个无需部署即可关闭某项技能的开关，并像冻结其他系统一样，在高峰时段之前冻结智能体。

关于这一安排中人的方面，参见构建高效的人机团队。

展望未来

这篇文章所描述的大部分内容都与模型本身无关。工具调用的是你已经在运行的系统，技能封装的是你已经在遵循的流程，评估集是你把产品需求文档写成了测试，而运行框架执行的是你对任何客户都会执行的政策。模型会不断进步，当更好的模型发布时，我们描述的这套架构只需改一次配置、跑一轮评估就能将其纳入。其余一切照常运转。

同样重要的是思考你的产品界面路线图。这套架构的生命力将超越聊天面板。同一个智能体可以在语音界面上工作，也可以在用户开口之前主动针对票价下降采取行动。对于一个已经拥有评估集和工具的团队来说，这些都是表现层的项目。再往远看，你的店铺将有一部分流量来自替用户购物的智能体。正是那些让你的自有智能体保持合规的溯源、暂存和审批规则，让你能够安全地向这些智能体开放你的工具。

商业历来奖励那些把购买流程做到尽可能顺畅的做法。智能体让这件事变得容易得多。来看看完整的参考实现，包含消费者端和商家端智能体，以及面向零售、旅游、电信和娱乐行业的可运行示例。

致谢

由 Matthew Koen 和 Ali Shazal 撰写。特别感谢 Michael Segner、Rodrigo Olivares、Amandeep Khurana、Aiza Usman、John Lopus 及其他人的贡献。

视频 · 前往原文观看