title: "Anthropic 电商智能体构建指南：架构、成本与生产实践"
source_url: "https://claude.com/blog/the-anatomy-of-effective-commerce-agents"
author: "Claude Blog"
excerpt: "公共早报 Anthropic 从已上线的电商项目总结单智能体配合技能的架构，解释如何保持购物会话的共享上下文，并让工具复用现有业务系统。指南进一步覆盖缓存、记忆、交易审批和评测，附可运行的参考实现，方便团队判断哪些能力交给模型、哪些约束由系统执行。"
在过去一年中，我们与商务行业各团队合作——包括零售商、市场平台、旅游、娱乐和电信提供商——利用 Claude 构建商务智能体。
这些智能体已投入生产，企业客户在使用后看到了更大的购物车规模和更高效的销售商运营。它们还共享一个简单的架构：Claude 运行在标准智能体循环中，配合一套技能、工具和一套完善的评测套件。
本文面向构建这些（或其它面向消费者的）智能体的工程师和工程负责人。第一部分涵盖架构，这是一旦确定就不变的。第二部分涵盖延迟和成本。第三部分涵盖生产环境：记忆、安全、评测，以及在组织内扩展工作。 参考实现 我们还提供了一份蓝图来帮助在 Claude 上构建商务智能体。它包含了工程团队在几天内让商务智能体运行起来所需的所有内容：测试框架、模式、护栏，以及一个购物智能体和一个商户智能体的参考实现，适用于零售、旅游、电信和票务平台。 anthropics/commerce-agents → 本文内容
什么是商务智能体？
技能，而非子智能体
系统提示词还是技能：根据频率决策
智能体工具的工程实践
UI 组件即工具
最小化任务完成延迟
感知延迟
提示词缓存
选择模型及其配置
跨会话持久化的记忆
安全：约束力在测试框架中
评测：发布一个非确定性系统
在大型组织中交付
展望未来
01
架构
一个模型运行在标准智能体循环中，配合技能处理长尾场景，工具调用已有系统。这套架构一旦确定就不变。
什么是商务智能体？
我们将商务智能体定义为简化跨在线目录买卖行为的智能体。
有些智能体面向消费者：它们搜索、比较、替代和组装订单。可以是零售购物车、旅行行程、移动套餐变更，或演出预留座位。有些智能体面向企业：它们回答销售问题、运行促销和活动、管理库存和定价。
核心架构是一个模型运行在标准智能体循环中：推理目标、探索上下文、通过工具执行行动、通过技能学习流程、提出澄清问题、观察结果，直到目标达成。
前方没有意图路由器来分割对话，后方也没有特定领域的子智能体集合。
工程背景
技能，而非子智能体
商务智能体需要覆盖广泛的能力范围，跨越多个类别和意图，这使得为每个领域创建一个子智能体变得很有吸引力。
但在实践中，这被证明是次优的，因为商务会话是一个跨多个意图和轮次的紧密耦合会话，需要大量共享上下文。
在子智能体架构中，编排器持有购物车或暂存的更改、用户偏好和对话历史。
每次移交给子智能体都是一次有状态损耗的操作，这通常会影响子智能体响应的质量，进而影响整体响应质量。更重要的是，每次移交可能消耗数倍的 token 并增加数秒的延迟。
各领域也很难完全分离。退货流程可能需要订单历史、当前进车车和产品目录，这意味着按领域划分子智能体的方式要么在各处重复访问，要么在任务中途进行移交。
随着模型变得越来越智能，它们也能处理更长的上下文、更多的技能和更多的工具，因此当前放置规则背后的限制随着每一代模型而放宽。
相反，智能体技能为你提供了类似的领域级模块化和上下文控制，而无需移交税，因为技能指令加载到已经持有完整历史的主智能体中。
在我们对多个企业部署的比较中，单个配备技能的智能体在质量上始终优于"一切用一个提示词"的设计和子智能体设计，而且通常每个任务的成本和延迟更低。
子智能体真正发挥作用的地方是当编排器可以将它们作为一种工具来调用，执行一个狭窄或自包含的任务，该任务受益于其自己专用的上下文窗口。
一个常见的生产示例是深度研究子智能体，子智能体在其中搜索和阅读文档、编写和运行代码、遍历数据模型，并遇到死胡同。所有工作都在一个或多个子智能体内部完成，只有紧凑的答案返回给编排器。
另一个例外是已经拥有自己专用智能体的领域。如果你的药房或金融服务体验运行着一个具有自身合规面的专用智能体，正确的做法可能是移交——该智能体接管任务，通过自己的循环直接与用户交互，直到任务完成。
区别在于对话的所有权。移交使领域智能体成为用户的对应方，而委托则保持编排器不变，在每个回合中弹出和弹入领域智能体，导致每次交互都降级。
系统提示词还是技能：根据频率决策
决定一组指令是放入系统提示词还是技能的主要因素是智能体需要它的频率。加载技能需要一个模型轮次，因此智能体在大多数轮次中需要的内容通常放在系统提示词中。
然而，这确实取决于你的流量分布，以及你的评测显示的智能体行为。一个好的起点是：任何与三分之一或更多流量相关的指令，无论是发布前预期的还是生产中观察到的，都放入系统提示词，其余的放入技能。
如果一个技能可以从你已经拥有的信号中预测，例如用户到达的页面，我们建议在第一次模型调用之前从测试框架中注入它，并跳过加载技能的额外轮次。
关键指令（如安全和法律规则、品牌约束）以及关键用户事实（如过敏信息）始终放在系统提示词中。
对于商务智能体，这意味着产品搜索放在提示词中，因为几乎每个会话都会用到它，而技能则承载长尾功能。
在我们的参考实现中，购物智能体的提示词包含基础、购物车和结账语义以及展示规则，而以下技能覆盖其余部分：搜索-发现、购买-研究、规划-目标、客户服务和记忆-个性化。
商户智能体的划分方式相同，性能-洞察、目录-列表、库存-运营、定价-促销和营销-活动作为其技能，每个运营领域一个。 在提示词中 购物智能体基础、购物车和结账语义、展示规则以及产品搜索。 购物技能 长尾搜索-发现 · 购买-研究 · 规划-目标 · 客户服务 · 记忆-个性化 商户技能 每个运营领域一个性能-洞察 · 目录-列表 · 库存-运营 · 定价-促销 · 营销-活动
智能体工具的工程实践
我们关于为智能体编写有效工具的文章涵盖了工具设计的一般原则。在商务领域最重要的两点是：
在你现有的核心系统和逻辑之上构建智能体工具。
商务公司已经有搜索和排名、购物车、偏好和个人资料存储、库存系统、促销和活动引擎、销售分析等，每个都编码了多年调优的逻辑，并能看到模型永远无法获得的信号。
智能体的工具应该调用这些系统，而不是重新实现它们，工具边界是它们的逻辑结束、模型判断开始的地方。
例如，当智能体调用 search_products 时，结果应该已经排好序返回；它的工作是决定哪些结果服务于用户的目标、显示多少结果以及如何展示它们。
工具结果是上下文。
返回模型推理时使用的字段，丢弃其余字段。每行搜索结果中的图片 URL 是常见的罪魁祸首。
根据需要，在工具内部重塑原始响应，包括在数据不明显时附加下一步操作。
这对于错误场景尤其重要，在这些场景中，模型从指令中受益，而不是错误代码。例如，添加一条错误指令"查询可用性时包括产品 ID"，而不是通用的 403。
UI 组件即工具
大多数商务智能体响应是 UI 组件而不是散文，无论是产品轮播、行程、座位图还是图表。这意味着智能体必须发出模式而不是文本。
团队有时从提示模型发出自定义标签并在客户端解析开始。随着表面增长，这不再有效，因为：
模型对你的标记的训练不如对工具调用那么好，因此随着嵌套组件的增加，可靠性会下降。仅仅通过提示并不能保证数据格式良好。
标签定义存在于系统提示词中，因此每个新组件都会膨胀上下文，每次编辑都有在提示词其他地方引入回归的风险。
过去的对话最终以只有你的解析器可以读取的格式存储，因此加载历史意味着要么在客户端解析原始消息，要么保留第二份不是模型 API 原生格式的副本。
经得起考验的模式是将每个 UI 组件作为一个工具。模型调用 present_products、present_itinerary 或 present_plan_comparison 并传入类型化参数；你的服务器验证和丰富调用并发出事件；你的客户端渲染它。
由于组件是工具调用，它们已经以原生格式存在于消息数组中，因此重新加载旧对话时不需要重新解析。下面展示了一个展示工具契约的示例，也在参考仓库中。
权衡的是流式粒度。工具调用的每个顶级参数都在服务器上缓冲以进行验证，因此即使开启流式传输，展示工具的子组件也会分步到达。这会影响感知延迟。
要获得令牌级流，在工具定义上设置 eager_input_streaming: true，这将跳过缓冲以及随之而来的服务器端模式保证。
在我们的评测中，在 Claude Sonnet 级模型及以上，模式违规非常罕见，但对于漏网的情况，在调用外包裹重试逻辑。
展示工具还为智能体提供了屏幕上内容的记录。当客户说"第一家酒店"或"左边第三个"时，布局在消息数组中，在上次展示调用的参数里。
为此，参数必须反映渲染后的布局，因此按照 UI 的结构来组织它们，作为有序的行和轮播，而不是客户端重新排列的平面列表。 02
让它又快又经济
从两个维度攻破延迟：端到端和感知延迟，并让缓存承担成本。这一切都不应该以牺牲智能为代价。
延迟在商务领域很重要，消费者界面是最不容忍延迟的。然而，在智能体界面上，我们始终看到推动留存、参与度和购物车规模等指标的是结果的质量。
与边际延迟收益相比，答案是否相关以及任务是否实际完成对这些指标更为关键。
所以从两个维度攻破延迟。通过良好的工程实践最小化端到端延迟，并配合降低感知延迟（因为花在观看智能体工作上的时间被感受为进展）。
每个用户都有延迟预算，以下技术让智能体在不以牺牲智能为代价的情况下保持在预算内。
最小化任务完成延迟
任务完成延迟是模型轮次中最后一个令牌的时间加上工具处理时间的总和。这给了你三个可以努力的杠杆：更少的轮次、更快的工具和更快的令牌。这些杠杆有时会相互竞争，所以要最小化的是总和而不是其中任何一个。 更少的轮次提前加载可能的上下文，提高模型智能，并让模型并行调用独立的工具。 更快的工具优化工具自己的后端，并在其参数完成时急切地分发工具。 更快的令牌通过遍历评测套件来选择模型及其配置。
更少的轮次
查询复杂性增加轮次，而且通常不在你的控制范围内。模型智能和相关上下文帮助智能体以更少的轮次完成任务。在此领域我们的一些关键学习包括：
提前加载可能的上下文。 如果用户是从产品页面打开助手，或者商户是从活动仪表板打开它，将该页面的数据放入会话上下文中。对话很可能与此相关，从上下文中回答不会产生额外的轮次成本。
提高模型智能。 更智能的模型可以减少完成任务所需的整体轮次，因为智能体可以更有效地规划和发出工具调用。这通常超过它们较慢的令牌。如果你的查询偏向复杂，或者生产中显示每个任务超过大约五个轮次，更快的模型通常是更明智的选择。这取决于你的流量，因此如下的"选择模型"部分所述，通过遍历来决定。
让模型并行调用独立的工具 。商务用例通常需要许多并行操作：无论是搜索多个产品、查询多个策略文档，还是从多个销售数据源获取记录。并行工具确保多个独立查询不会消耗额外的轮次。提示模型在一个轮次内调用多个工具，并将结果作为工具结果数组在一个用户消息中返回（参见并行工具使用文档）。
更快的工具
优化工具自己的后端。 有时工具确实是扇出的——一个带有"获取今日快照"查询的商户智能体在三个独立调用中读取销售、库存和活动状态。但我们经常看到工具边界成为拼接缺失后端逻辑的地方：一个可用性检查调用目录获取 SKU、每个商店的库存服务和履约服务的截止时间，然后在自己的代码中应用替换规则和取货资格，然后才回答。这个工具现在负载了领域知识，随着规则变化很难保持正确，并且携带了应该放在上游系统的逻辑。当你发现自己在一个工具中编写那种逻辑时，修复方法是一个回答问题后端端点，然后用智能体工具调用它。
急切地分发工具。 工具参数像任何其他令牌一样从模型流出，因此测试框架可以在每个工具的参数完成时执行该工具的调用，并在模型仍在流式传输其它并行工具或内容块时处理它。我们已经看到这将数秒的间隙减少到几百毫秒，Claude Agent SDK默认这样做。你应该提示模型首先发出最慢的调用，以获得最大的延迟收益。
感知延迟
感知延迟是用户感觉到屏幕有响应之前的时间。这在面向消费者的用例中尤为关键，因为任何交易摩擦都会影响结账率和收入。两种技术可以在不触及模型的情况下缩短它：
在形成时就流式传输组件。 渲染后的商务响应通常为 500-700 个输出令牌，不使用流式传输的话就是超过五秒的加载动画。将展示工具的每个参数在流式传输时发送到客户端，并逐步渲染页面。
展示工作进度。 当智能体正在收集上下文时，用简单的语言为每个步骤渲染一行简短的进度（例如，"查找靠近水源的酒店"）。你可以从工具现有的参数构建它（例如产品搜索的查询），或者添加一个额外的 user_facing_message 参数工具，提示模型写出该行。
上面两个面板使用相同的智能体、相同的工具和提示词运行；只有测试框架不同。总时间大致相同，但用户看到内容的时间差异很大。
提示词缓存
提示词缓存是你最大的成本降低候选方案，商务流量非常适合它。缓存的输入令牌读取成本是新令牌的十分之一，而缓存写入携带大约 1.25 倍的溢价，但缓存前缀在第二次使用时就能回本。在客户面向的应用中，量大意味着你可以利用最便宜、默认 5 分钟缓存过期来获得非常高的缓存水平。
我们见过的最好的商务部署运行在 90-99% 的缓存命中率，这是从一开始就要设计的范围。我们的经验表明，缓存的令牌读取在大约 10 万令牌时也快约 1.5 到 2 倍，而且令牌越多，扩展越接近线性。
缓存基于前缀。请求读取缓存直到与先前请求的第一个字节不同，所以重要的不仅是上下文中有什么，还有它的顺序。把请求想象成三个段，按变化频率排序：
全局：大部分系统提示词和工具定义，每个会话都相同。这是最热的缓存，在规模上可能不会过期。在轮次和会话之间保持字节完全一致，并在其末尾放置一个缓存断点。
会话：每个用户的上下文和对话历史，在不同会话之间不同，但在同一个会话中保持稳定。这个段跟在全局段之后。
易变：会话中任何会变化的内容，例如当前时间或当前页面。把它放在请求的最末尾，或者是最新用户回合中的标记块，或者在支持会话中系统消息的模型上，作为附加到消息数组的系统角色消息。我们看到的最常见错误是在系统提示词顶部放置时间戳或当前页面，这会在每次请求时静默破坏缓存。
有两个实现细节要记住。首先，技能应该作为工具结果加载，而不是附加到系统提示词。这样技能体落在对话前缀中并随之缓存。
其次，在每个轮次中向前滚动断点：请求允许有限数量的断点，因此将最新的断点移动到每个用户回合的末尾。然后每轮从缓存中读取累积的历史，包括长的工具结果（如搜索响应）。
选择模型及其配置
模型大小和努力设置是相同的权衡——智能与延迟和成本——你应该通过测量来选择两者：
选择你的指标和底线。 选择你的业务所依据的质量指标（任务完成、答案相关性、基础准确性）、你不会低于的评测分数，以及你的 p50 和 p99 延迟和成本预算。
遍历。 在你考虑的所有模型和努力级别上运行你完整的评测套件。我们建议从 Opus 开始用于商户智能体（其任务偏分析），从 Sonnet 开始用于消费者智能体（延迟权重更大）。如果你有生产流量，按你真实的查询组合对结果加权。然后让数据决定。有时 Opus 5 在推动购物车任务上的提升证明了与 Sonnet 的成本差异是值得的，有时则不值得。
仔细阅读结果。 有两件事经常让团队惊讶。第一，提示词是针对模型调优的，因此在某个提示词上运行的遍历可能对其他它并非为之编写的模型表现不佳。较小的模型通常需要当前模型自行推断的指令，而较大的模型会严格遵循较小模型忽略的指令。在排除任何一个候选之前，对每个候选的失败案例进行几轮迭代是一个廉价的步骤。第二个惊讶是，更智能的配置有时会在延迟上获胜（最常见于 p90 和 p99），尽管令牌较慢，因为它能更好地规划工具调用，并在最复杂的请求上需要更少的轮次。
衡量每个已完成任务的成本，而不是每次模型调用的成本，因为更便宜的模型如果需要更多轮次或失败更频繁，并不意味着更便宜。当结果接近时，且成本符合你的每任务经济性和延迟，选择智能。质量是推动采用和留存的动力，并为未来六个月模型变得更好时的建设留出空间。 03
在生产环境中运行
记忆、安全、评测，以及在组织内扩展工作：什么能让智能体通过生产环境并保持在那里。
最后，我们讨论什么能让智能体通过生产环境：记忆、安全、评测，以及在组织内扩展工作。
跨会话持久化的记忆
你与客户的关系和互动很重要。记忆让智能体能够从上次对话结束的地方继续，而不是从零开始。一个在三月提到坚果过敏的购物者不应该在六月重复它，而一个每周一检查相同三个活动的商户不应该每次都命名它们。长期记忆——应该跨会话保留的事实——是你构建的系统，它有三个部分：事实如何存储、如何写入以及如何读取。
存储记忆
记忆属于你的系统，而不是模型。
当个人资料较小且只有智能体读取时，平面 markdown 个人资料可以工作。大多数生产商务智能体会超越它，实际的替代品是你已经运行的数据库。事实是一条小的类型化记录：一个键（如 shoe_size、default_store、preferred_report_cadence）、一个短值、一个类别和它来自的会话。有些键你提前决定，每个用户都有；其余的由提取器发现。数据库在存储增长时保持可查询，让你可以在特定属性上构建确定性行为，并与你已有的用户数据连接。
对于面向商户的智能体，按人而不是按账户来记忆关键信息。商户登录通常在操作员之间共享，因此每个操作员需要自己的个人资料，读取必须尊重该操作员的权限：店长的智能体不应该回忆起区域经理陈述的事实。
在商务领域，智能体记忆持有个人数据。值得记住的事实通常是最受监管的，司法管辖区之间的规则也不同。把记忆当作数据处理设计问题，而不仅仅是存储问题。在实践中，这意味着四件事：
决定你愿意持有哪种类型的记忆。在写路径强制执行，通过每个保存都必须经过的验证器，而不是仅仅在提示词中。
给用户一种查看、更正和删除所存储内容的方式。 将删除接入你的账户删除和数据请求流程。
设置保留期。 几年前的偏好可能已经过时，因此保留期有助于保持记忆事实新鲜。
记忆应该是每次部署的开关。这允许无法承担这些义务的地区在没有它的情况下运行。
写入记忆
异步写入记忆。在每个轮次结束时，或在一个长会话中每几个轮次，一个智能体在单独的线程或进程中读取对话并在存储中创建、更新或删除事实，在会话进行时保持自己的工作上下文。
它不会增加对话的延迟，在我们内部的商务记忆评测套件中实现了 13% 的事实回忆率提升。
显而易见的替代方案——智能体调用工具来保存事实——对于延迟敏感的商务智能体来说是错误的选择。每次保存都是用户Facing轮次中的一个工具调用，而且除非整个存储都在上下文中，否则保存需要先读取以更新或去重，这是一个自己的来回。
这也给智能体在每个轮次前增加了更多决定，在我们的评测中，这种注意力竞争表现为遗漏记忆。
分离提取器还让你可以精确地提示它。它只读取用户和助手的文本，从不读取工具结果，因此产品描述或评论不会成为关于用户的事实。它的提示词说明什么算作事实——陈述的尺寸、饮食约束、履约偏好、商户通常的具体化视图——什么不算，例如来自列表的任何内容或一次性细节。
读取记忆
分三层读取记忆。 始终在上下文中一小部分固定事实进入每个轮次的上下文：几乎每个请求都依赖的那些，例如购物者的默认商店和履约偏好，或操作员的商店和角色。 每轮预取与当前请求相关的事实从与预加载技能相同的信号中每轮预取：鞋子搜索拉取尺寸和品牌偏好，活动问题拉取操作员通常的指标。 在查找工具后面其他一切都放在查找工具后面。
由于记忆是每用户上下文，所有内容都进入会话段，在全局缓存断点下方。
安全：约束力在测试框架中
提示词是安全行为的起点，但在商务领域，安全不能仅在提示词中执行。失败是财务性的，通常不可逆转，而一条提示词规则距离被注入或一个坏样本跳过只有一步之遥。以下每条规则都在代码中强制执行，在消费者和商户智能体上都是如此，定义一次，这样每个运行时都共享它。
模型进行阶段；人或策略应用
没有模型工具调用移动资金或改变业务。订单提交、付款、退款、价格更改和活动启动都以测试框架控制而不是模型控制的动作结束。
在消费者方面，这是结构性的：结账工具渲染带有提交订单按钮的购物车，智能体调用的后端接口根本没有扣款方法。
在商户方面，每个写工具都产生一个暂存的更改，带有服务器生成的 ID，而 apply_change 仅对通过真实界面批准的 ID 成功：操作员门户中的按钮、CLI 中的确认，或者当智能体在托管智能体上运行时平台自己的工具批准提示。
护栏在应用时根据当前限制重新检查，而不是更改暂存时的限制。无论界面如何，形状都是相同的：模型最危险的动作是提出建议，批准通过你的企业已经用于此类更改的 maker-checker 流程路由。
写入和渲染只接受服务器颁发的 ID
测试框架为服务器交给模型的每个 ID 保持每会话记录，并且该记录是任何写入或渲染接受的唯一密钥。
购物车只接受服务器返回给本会话的产品 ID，商户工具只接受智能体实际读取过的列表和活动 ID。任何其它方式到达的 ID——虚构的、用户粘贴的、植入学Review的——在后端看到之前就被拒绝。
同样的规则覆盖 UI。展示工具获取 ID，服务器自己填充产品、订单或更改记录，因此卡片只渲染服务器自己填充的记录。
它也覆盖委托：商户分析子智能体读取数据但从不添加到智能体可以写入的 ID 集中。
对于费用、披露和其它受监管内容，模型选择要披露哪个产品，服务器从已批准的副本中提供每个词。相同的费用字段在商户智能体的受保护列表上，因此柜台的任何一方都不能更改或改述它们，评测逐字节检查渲染的字符串。
交易上限必须应对重复请求
大多数商务界面限制一个用户可以购买的商品数量——用于票务分配、促销定价或欺诈控制——而智能体会以人类点击按钮从未有过的方式重试、重新措辞和并行化。
因此，上限在写入后的行上强制执行，因此第二个"再加两个"不能超过它，并且一个会话的购物车写入被序列化，这样单个轮次中的并行工具调用不能组合超过它。
商户更改同样根据价格变动、折扣深度、补货规模和活动预算的上限进行检查，外加一个任何更改都不能触及的受保护字段列表。规则泛化：在结果状态而非请求上强制执行每个限制，并按会话序列化写入。
第三方内容经过清理
在商务领域，大部分上下文是由不是你的人写的——卖家、Review者、竞争对手——因此每个后端读取都是不可信的输入，并通过一个清理器。
每个由第三方创作的工具结果，如列表、Review、策略、卖家消息和存储的记忆，在模型看到之前都要经过清理并用固定标签包裹在围栏中。
清理器剥离控制和双向字符，删除任何模仿围栏标记的内容，解除模仿对话轮次或工具调用的文本，并限制大小，这旨在阻止恶意列表冒充系统或填满上下文。
提示词携带合同的后半部分：围栏内的文本是报告的素材，绝不是行动的依据。
评测：发布一个非确定性系统
从小的提示词更改到新工具的任何内容都可能以难以预测的方式改变智能体行为，而你发布的变化往往不是导致回归的那个。评测是你在部署之前找出这些的方法。我们之前关于智能体评测的博文涵盖了常规实践。本节涵盖商务智能体的细节。
评估快照，而不是对话
模型的 API 是无状态的，所以智能体输出的是系统提示词、工具和消息数组的函数。这意味着商务对话可以到达的任何状态都可以直接构造。因此，创建评测案例意味着构造测试状态、附加测试用户消息，然后让智能体从那里运行。
然后对结果评分：最终状态和渲染的响应，包括上次写入的参数。在大多数情况下，我们不建议对智能体到达那里的路径进行评分，因为这样的测试案例是脆弱的且限制性很强。
模拟用户评测，其中第二个模型扮演用户，裁判对整个对话评分，是测量能力较差的工具。两个非确定性系统交互需要更大的样本，每次试验成本更高，更难评判，产生难以归因的失败。它们对发现覆盖差距和对智能体进行一般性的感觉检查很有用，因此用它们来发现案例，然后将每个案例写为快照。
评估困难条件下的行为
大多数团队未能正确测试注入状态。一个案例应该编码失败的前提条件，而不仅仅是任务。如果一种行为仅在忙碌的第一轮（有几个工具调用）或会话中较早的矛盾之后才出现，那么从干净状态开始的案例会在每个配置上通过，并且不提供有意义的数据。
我们观察到大多数套件在干净状态案例上很重，所以确保你的一部分从长、混乱或矛盾的历史开始。
覆盖不同类型的商务智能体评测
有效的评估需要测试期望和不期望的行为。
对于每个正面案例，编写其负面对应物：每个"应该拒绝"的"应该服务"，每个"应该询问"的"应该直接做"。遗漏的负面案例是我们在一个套件中发现的最常见差距。
评估以下内容：
构成流量主体的核心请求，因为这里的失败影响大多数会话。这些包括简单查询、多约束请求、产品和套餐问题以及多意图消息。对于问题，检查每个价格、可用性和属性是否可追溯到返回的数据，并且当数据缺失时智能体会说出来而不是编造。
上下文相关的请求，例如对屏幕上内容的引用、从较早轮次带来的约束以及对现有购物车的写入。评估记忆也属于这一类。检查记忆是否被提取、检索并改变了答案。
安全和品牌案例，其中失败会损失金钱或信任。这些包括注入尝试、读取其他用户数据的尝试和受监管语言，后者逐字节检查。将注入分成两个案例：用户创作的注入，其中指令来自用户自己的消息，以及数据平面注入，其中它被植入通过工具结果到达的产品名称、Review或网络片段中。
接口评估，以确保渲染正确的组件、尊重项目上限，并且用户面向的文本中没有内部标识符。还测试超时和空结果。
同时属于多个能力的请求。 操作员问"如果我降低 15%，我有足够的库存来满足需求吗？"这是定价问题和库存问题的结合。正确答案是在附有库存预测的情况下暂存降价；错误的答案做了一件而跳过另一件。按能力编写的评测不会捕获这一点，因为每个只评分自己的那一半。编写需要两个相邻能力一起的案例，并评分答案的两半。
与主题专家一起编写评测并使用真实事件
与亲眼看到失败的主题专家合作，如产品、法律、商户运营、客户服务和品类管理方面的团队成员，共同设计测试案例。真实的失败是最好的评测，每个用户流程 50-100 个评测案例是一个好的起点。
确保有各种案例，如上所述。生产记录是获取新案例的很好的来源，特别是棘手的案例。编码智能体善于生成额外的案例和对抗性变体。参考仓库包含一个带有评测编写技能的 Claude Code 插件，采用我们推荐的方法构建。
在大型组织中交付
在商务企业中，智能体由多个工程团队构建。搜索、结账、定价、营销技术、客户服务和目录平台各自拥有智能体所依赖的系统，每个都按自己的节奏发布，每个都会想要添加或更改工具、技能或提示词规则。
与服务不同，智能体没有严格的模块边界保护彼此：定价团队所做的更改与结账共享一个上下文窗口。
诱人的解决方案是将系统分解为许多子智能体，每个业务单位一个。正如第一部分所讨论的，由于质量原因，我们不建议这样做。相反，我们概述降低多团队协作风险的过程：
所有权跟随系统。 每个技能和工具都有一个所有者团队。例如，定价拥有促销工具和定价技能，客服拥有订单和退货工具以及客户服务技能。共享提示词对公共部分有一个平台级所有者，对特定领域部分有领域所有者。
更改随其案例一起发布，CI 运行为其选择的一组。 为技能做出贡献的团队也贡献其案例，包括负面案例和针对相邻技能的边界案例。在每个拉取请求上运行完整套件太慢且太昂贵，无法存活，因此从中构建一个 CI 集。该集将包含具有最高流量请求的核心案例集和每个安全案例。在此基础上，运行更改所触及的案例。对于技能，是它自己的案例及其相邻的边界案例。对于工具，是调用它的每个案例。对于共享提示词，是完整评测套件，因为每个都读取系统提示词。我们建议在几次试验中设置通过率门控，以及缓存命中率和每轮成本。在完整套件上运行也是每晚和每次发布前的良好实践。跨团队回归在这些运行中被捕获。
智能体也应该在发布日历中。 它是一个部署单元，所以一个坏的更改会同时触达每个用户。将提示词和技能更改滚降到金丝雀队列，首先有一个关闭一个技能的开关而不需要部署，并在高峰期前像冻结其他系统一样冻结智能体。
关于这种安排的人员方面，请参见构建有效的人-智能体团队。
展望未来
这篇文章描述的大部分内容与模型无关。工具调用你已经运行的系统，技能编码你已经遵循的流程，评测是你的产品需求文档写成测试，而测试框架执行你为任何客户端都会执行的策略。模型将继续改进，当更好的模型发布时，我们描述的架构将其作为配置更改和评测遍历来采用。其它一切继续工作。
考虑产品界面的路线图也很重要。架构将超过聊天面板的寿命。相同的智能体可以通过语音工作，并且可以在用户询问之前主动对票价下降采取行动。对于已经拥有评测和工具的团队来说，这些只是展示层项目。更远来看，你的一些店面流量将来自代表用户的智能体。相同的来源、暂存和批准规则让你的智能体保持在其范围内，这也正是让你能够安全地向那些智能体开放工具的原因。
商务领域总是奖励尽可能使购买过程顺畅。智能体让这变得容易很多。查看完整参考实现，其中包含消费者和商户智能体，以及零售、旅游、电信和娱乐的可运行示例。
致谢
作者：Matthew Koen 和 Ali Shazal。特别感谢 Michael Segner、Rodrigo Olivares、Amandeep Khurana、Aiza Usman、John Lopus 等人的贡献。