高效电商智能体结构指南

电商智能体的架构、延迟与成本技术，以及评估实践——让线上买卖更简单。

• 分类 智能体
• 产品 Claude 平台
• 日期 2026年9月2日
• 阅读时间 5分钟
• 分享 复制链接https://claude.com/blog/the-anatomy-of-effective-commerce-agents
• 作者 Ali Shazal、Matthew Koen

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

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

这篇文章是写给正在构建这些（或其他面向消费者的）智能体的工程师和工程负责人的。第 1 部分讲架构，这部分你只需要决定一次。第 2 部分讲延迟和成本。第 3 部分讲生产环境：记忆、安全、评估，以及如何在组织内扩展这项工作。

本指南目录

• 第 1 部分：架构什么是电商智能体？技能，而不是子智能体系统提示词还是技能：按使用频率决定工程智能体工具UI 组件也是工具
• 第 2 部分：让它又快又便宜最小化任务完成延迟感知延迟提示词缓存选择模型及其配置
• 第 3 部分：在生产环境中运行跨会话存活的记忆安全：执行逻辑放在框架层评估：上线一个不确定的系统在大型组织中推广
• 展望未来

架构

什么是电商智能体？

我们把电商智能体定义为：简化在线目录中买卖流程的智能体。

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

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

它前面没有意图路由器来切分对话，后面也没有一组领域专用智能体。

工程背景

一个电商智能体需要覆盖多个品类和意图下的广泛能力，这让人很想为每个领域创建一个子智能体。

但实践证明这样做效果不佳，因为一次电商对话是一个跨多个意图和轮次的紧密耦合会话，需要大量的共享上下文。

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

每次切换到子智能体都是一次有损状态的操作，这常常影响子智能体回复的质量，进而影响整体回复。更糟的是，每次切换可能消耗数倍的 token，还会增加数秒的延迟。

各个领域也很少能干净地分开。一个退货流程可能需要订单历史、当前购物车和产品目录，这意味着“每个领域一个子智能体”的做法要么在每个地方重复这些访问权限，要么在任务中途进行切换。

随着模型越来越聪明，它们也能处理更长的上下文、更多的技能和更多的工具，所以今天这些放置规则背后的限制会随着每一代模型的更新而放宽。

相反，智能体技能能给你类似的按领域模块化和上下文控制，却没有切换的代价，因为技能指令加载到已经持有完整历史的主智能体中。

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

子智能体真正有价值的地方在于：编排器可以把它们当作工具来调用，用于那些狭窄或自包含的任务——这类任务受益于自己专用的上下文窗口。

一个常见的生产案例是深度研究子智能体：子智能体搜索和阅读文档、编写和运行代码、遍历数据模型、也会碰壁。所有工作发生在一个或多个子智能体内部，只有一份精简的答案返回给编排器。

另一个例外是某个领域已经有自己专门构建的智能体。如果你的药房或金融服务体验运行着一个带有自己合规体系的专用智能体，那么正确的做法可能是交接——让那个智能体接管任务，通过自己的循环直接与用户协作，直到任务完成。

区别在于对话的所有权。交接让领域智能体成为用户的对话对象，而委派则保持编排器的主导地位，在单轮内反复进出领域智能体，每次交换都会降低质量。

决定一组指令是放在系统提示词还是技能中的主要因素，是智能体需要它的频率。加载技能会消耗一轮模型调用，所以智能体在大多数轮次中需要的东西通常放在系统提示词里。

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

如果一个技能可以从你已有的信号中预测出来，比如用户来自哪个页面，我们建议在第一次模型调用之前从框架层注入它，跳过加载技能的额外轮次。

关键指令，如安全和法律规则、品牌约束，以及重要的用户事实（如过敏信息），始终放在系统提示词中。

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

在我们的参考实现中，购物智能体的提示词包含基础锚定、购物车和结账语义以及展示规则，以下技能覆盖其余部分：搜索发现、购买研究、计划目标、客户关怀和记忆个性化。

商家智能体也采用同样的拆分方式，其技能包括：业绩洞察、目录列表、库存运营、定价促销和营销活动——每个运营领域一个。

工程智能体工具

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

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

一家电商公司已经有搜索和排序、购物车、偏好和用户档案存储、库存系统、促销和活动引擎、销售分析等等，每个系统都编码了多年调优的逻辑，并且能看到模型永远看不到的信号。

智能体的工具应该调用这些系统，而不是重新实现它们。工具边界就是这些系统逻辑结束、模型判断接管的地方。

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

工具结果就是上下文。

返回模型用来推理的字段，丢掉其余的。每条搜索结果上的图片 URL 是常见的罪魁祸首。

根据需要，在工具内部重塑原始响应，包括在数据无法自然说明下一步时附加一个下一步建议。

这在错误场景中尤其重要，模型从指令中获益比从错误代码中获益更多。例如，添加一条错误指令“查询可用性时请包含产品 ID”，而不是一个笼统的 403。

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

团队有时一开始会提示模型输出自定义标签，然后在客户端解析。随着界面增长，这种做法会失效，因为：

• 模型对你自定义标记的训练不如对工具调用的训练充分，所以随着嵌套组件的增加，可靠性会下降。仅靠提示词无法保证格式良好的数据。
• 标签定义放在系统提示词中，所以每个新组件都会膨胀上下文，每次修改都可能让提示词其他部分出现回归问题。
• 过去的对话最终以一种只有你的解析器能读的格式存储，所以加载历史意味着要么在客户端解析原始消息，要么以模型 API 不原生支持的格式保留第二份副本。

经得起考验的模式是把每个 UI 组件做成一个工具。模型调用 present_products、present_itinerary 或 present_plan_comparison，并传入类型化参数；你的服务器验证和丰富调用并发出事件；你的客户端渲染它。

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

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

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

在我们的评估中，Claude Sonnet 级别及以上的模型出现模式违规的情况非常罕见，但还是建议在调用外面包一层重试，以防万一有漏网之鱼。

演示工具还让智能体有了屏幕上内容的记录。当客户说“第一家酒店”或“左边往下第三个”时，布局就在消息数组中，在上一次演示调用的参数里。

要让这起作用，参数必须反映实际渲染的布局，所以要按照 UI 的结构来组织它们——有序的行和轮播图，而不是客户端会重新排列的扁平列表。

让它又快又便宜

延迟在电商中很重要，面向消费者的界面是最不容忍延迟的。然而，在智能体界面上，我们持续看到能推动留存、参与度和购物车规模等指标的是结果质量。

答案是否相关、任务是否真正完成，对这些指标的影响比边际延迟收益更大。

所以要从两条战线来应对延迟。通过良好的工程来最小化端到端延迟，同时配合降低感知延迟（因为花时间看着智能体工作会被解读为进展）。

每个用户都有一个延迟预算，下面的技术让智能体保持在预算之内，而不需要靠更强的智能来达成。

最小化任务完成延迟

任务完成延迟是各模型轮次中“最后一个 token 的时间”加上“工具处理时间”的总和。这给了你三个可以优化的杠杆：更少的轮次、更快的工具、更快的 token。这些杠杆有时会互相竞争，所以需要最小化的是总和，而不是其中任何一个。

查询复杂度会增加轮次，这通常不在你的控制范围内。模型智能和相关的上下文能帮助智能体用更少的轮次完成任务。我们在这一领域的一些关键经验包括：

• 提前加载可能需要的上下文。如果用户是从产品页面打开助手的，或者商家是从营销活动仪表板打开的，就把那个页面的数据放进会话上下文。对话很可能围绕它展开，直接从上下文回答不需要额外的轮次。

• 提高模型智能。更聪明的模型可以减少完成任务的总轮次，因为智能体能更高效地规划和发出工具调用。这通常能抵消它们较慢的 token 速度。如果你的查询偏向复杂，或者生产数据显示每个任务超过大约五轮，那么更快的模型往往就是更聪明的那个。具体是哪个取决于你的流量，所以要通过扫描测试来选择，详见下文“选择模型”部分。

• 让模型并行调用独立的工具。电商用例经常需要并行执行多个操作：无论是搜索多个产品、查询多份政策文档，还是从多个销售数据源获取记录。并行工具调用确保多个独立查询不会额外消耗轮次。提示模型在一轮内调用多个工具，并在一个用户消息中以工具结果数组的形式返回结果（参见并行工具使用文档）。

• 优化工具自身的后端。有时工具确实需要扇出——一个商家智能体收到“获取今日快照”的查询，需要分别调用销售、库存和活动状态三个独立请求。但我们经常看到工具边界变成了缺失后端逻辑被拼凑的地方：一个可用性检查调用目录获取 SKU、按门店调用库存服务、调用履约服务获取截止时间，然后在工具自己的代码里应用替换规则和自提资格，最后才回答。这个工具现在被领域知识压得喘不过气来，规则变化时很难保持正确，而且承载着本应放在上游系统的逻辑。当你发现自己在工具里写这种逻辑时，解决办法是创建一个能回答这个问题的后端端点，然后用智能体工具去调用它。

• 急切地派发工具。工具参数像其他 token 一样从模型流出，所以框架层可以在参数完整后立即执行每个工具调用，在模型还在流式输出其他并行工具或内容块时处理它。我们见过这种方法把数秒的间隔缩短到几百毫秒，Claude Agent SDK 默认就是这么做的。你应该提示模型先发出最慢的调用，以获得最大的延迟收益。

感知延迟

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

• 组件形成时就开始流式传输。一个渲染好的电商响应通常是 500–700 个输出 token，如果不流式传输，就是五秒或更久的加载转圈。把演示工具的每个参数在流式传输时发送给客户端，并逐步渲染页面。

• 展示工作过程。当智能体在收集上下文时，用通俗语言为每一步渲染一行简短的进度提示（例如“正在查找水边附近的酒店”）。你可以从工具已有的参数构建它（比如产品搜索的查询词），或者添加一个额外的 user_facing_message 参数工具，提示模型来写这行文字。

提示词缓存

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

我们见过最好的电商部署运行在 90–99% 的缓存命中率，这就是从一开始就应该设计的目标范围。我们的经验显示，缓存的 token 读取在约 10 万 token 时也快约 1.5 到 2 倍，token 越多，加速效果越接近线性。

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

• 全局：大部分系统提示词和工具定义，在每个会话中完全相同。这是你最热的缓存，在规模下很可能不会过期。保持它在各轮次和会话之间字节级一致，并在其末尾放置一个缓存断点。

• 会话：每个用户特有的上下文和对话历史，在不同会话间不同，但在一个会话内保持稳定。这个段放在全局段之后。

• 易变：会话内会变化的任何内容，比如当前时间或当前页面。把它放在请求的最末尾，可以作为最新用户轮次中的标记块，或者在支持对话中途系统消息的模型上，作为追加到消息数组中的系统角色消息。我们见过最常见的错误是时间戳或当前页面放在系统提示词的开头，这会让每个请求的缓存都悄悄失效。

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

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

选择模型及其配置

模型大小和努力程度设置是同一个权衡——智能对延迟和成本——你应该通过测量来同时选择两者：

• 确定你的指标和底线。选择你业务运行所依赖的质量指标（任务完成率、答案相关性、基于事实的准确性）、你不想低于的评估分数，以及你的 p50 和 p99 延迟和成本预算。

• 扫描测试。在你考虑的所有模型和努力程度上运行完整的评估套件。我们建议从 Opus 开始测试商家智能体（其任务偏重分析），从 Sonnet 开始测试消费者智能体（延迟权重更大）。如果你有生产流量，按你真实的查询组合来加权结果。然后让数字说话。有时 Opus 5 在推动购物车任务上的提升能证明它相对 Sonnet 的成本差异是值得的，有时则不然。

• 仔细阅读结果。有两件事经常让团队意外。第一，提示词是针对模型调优的，所以用一个提示词做扫描测试可能会让其他不是为它写的模型表现不佳。较小的模型通常需要当前模型能自行推断的指令，而较大的模型会逐字遵循较小的模型忽略的指令。在排除任何候选之前，对每个候选的失败案例做几轮迭代是一个便宜的步骤。第二，更智能的配置有时在延迟上胜出（最常见于 p90 和 p99），尽管 token 更慢，因为它能更好地规划工具调用，在最复杂的请求上需要更少的轮次。

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

在生产环境中运行

最后，我们来谈谈什么能让智能体顺利通过生产环境：记忆、安全、评估，以及如何在组织内扩展这项工作。

跨会话存活的记忆

你与客户的关系和互动很重要。记忆让智能体能够从上次对话结束的地方继续，而不是从零开始。一个在三月份提到过坚果过敏的购物者不应该在六月份再重复一遍，一个每周一查看同样三个活动的商家不应该每次都点名它们。长期记忆——那些应该跨会话存活的事实——是你构建的一个系统，它有三个部分：事实如何存储、如何写入、以及如何读取。

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

当用户档案很小且智能体是唯一读者时，一个扁平的 markdown 档案就够了。大多数生产级电商智能体会超出这个规模，实际的替代方案是你已经在运营的数据库。一个事实是一条小的类型化记录：一个键（如 shoe_size、default_store、preferred_report_cadence）、一个短值、一个类别，以及它来自的会话。有些键你预先决定，每个用户都有；其余的由提取器发现。数据库在存储增长时仍然可查询，让你能在特定属性上构建确定性行为，并能与你已有的用户数据关联。

对于面向商家的智能体，按人来记忆而不是按账户。商家登录通常是多个操作员共享的，所以每个操作员需要自己的档案，读取时必须尊重该操作员的权限：门店经理的智能体不应该回忆起区域经理说过的事实。

在电商领域，智能体记忆包含个人数据。值得记住的事实往往是最受监管的，不同司法管辖区的规则也不同。把记忆当作一个数据处理设计问题，而不仅仅是存储问题。实际操作中这意味着四件事：

• 决定你愿意持有哪些类型的记忆。在写入路径上强制执行这一点，用一个每次保存都必须通过的验证器，而不是仅靠提示词。

• 给用户一种方式来查看、更正和删除存储的内容。把删除功能接入你的账户删除和数据请求流程。

• 设置保留期限。几年前的偏好很可能已经过时，所以保留期限有助于保持记忆事实的新鲜度。

• 记忆应该是一个按部署可切换的选项。这让无法承担这些义务的地区可以在没有记忆的情况下运行。

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

这不会给对话延迟增加任何负担，在我们内部的电商记忆评估套件上实现了 13% 更高的事实召回率。

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

它还在每一轮给智能体增加了一个决策，在我们的评估中，这种注意力竞争表现为记忆遗漏。

将提取器分离出来，也让你能精确地给它下达指令。它只读取用户和助手的文本，从不读取工具结果，所以产品描述或评论不会变成关于用户的事实。它的提示词会明确什么算作事实——比如声明的尺寸、饮食限制、配送偏好、商家常用的物化视图——什么不算，比如列表中的任何内容或一次性细节。

分三层读取记忆。

由于记忆是每个用户各自的上下文，所有内容都放在会话段中，位于全局缓存断点之下。

安全：执行机制在框架中

提示词是安全行为的起点，但在商业场景中，它不能是安全执行的地方。失败往往是财务性的，且常常不可逆，而提示规则可能因一次注入或一个坏样本就被跳过。以下每条规则都在代码中强制执行，适用于消费者和商家代理，并且只定义一次，让每个运行时共享。

没有模型工具调用能移动资金或改变业务。订单下达、支付、退款、价格变更和活动启动都以框架控制的操作结束，而不是模型。

在消费者端，这是结构性的：结账工具渲染购物车并带有一个下单按钮，而代理调用的后端接口根本没有收费方法。

在商家端，每个写入工具都会生成一个带有服务器生成ID的暂存变更，而apply_change只对通过真实界面批准的ID成功：操作员门户中的按钮、CLI中的确认，或代理在托管代理上运行时平台自己的工具批准提示。

防护措施在应用时根据当前限制重新检查，而不是根据变更暂存时的限制。无论界面如何，形态都一样：模型最危险的动作是提议，而批准流程通过你的业务已用于该类变更的“制造者-检查者”流程进行。

框架保留每个会话中服务器交给模型的每个ID的记录，而该记录是任何写入或渲染唯一接受的密钥。

购物车只接受服务器在本会话中返回的产品ID，商家工具只接受代理实际读取的列表和活动ID。任何其他方式到达的ID——幻觉、用户粘贴、评论中植入——在后端看到之前就被拒绝。

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

它也覆盖委托：商家分析子代理读取数据，但从不增加代理可写入的ID集合。

对于费用、披露和其他受监管内容，模型选择披露哪个产品，服务器从批准的文案中提供每个词。相同的费用字段在商家代理的受保护列表中，所以柜台两边都不能更改或改写它们，评估逐字节检查渲染的字符串。

大多数商业界面限制一个用户能购买某物品的数量——用于票务分配、促销定价或欺诈控制——而代理会以人类点击按钮从未有过的方式重试、改写和并行化。

因此，上限在行上强制执行，就像写入后那样，所以第二次“再加两个”不能叠加超过它，一个会话的购物车写入被序列化，使单轮中的并行工具调用不能组合超过它。

商家变更以相同方式检查，针对价格变动、折扣深度、补货规模和活动预算的上限，加上一个受保护字段列表，任何变更都不能触及。规则泛化：对结果状态强制执行每个限制，而不是请求，并序列化每会话写入。

在商业中，大部分上下文由不是你的人——卖家、评论者、竞争对手——编写，所以每个后端读取都是不可信输入，并通过一个清理器。

每个由第三方撰写的工具结果，如列表、评论、政策、卖家消息和存储记忆，在模型看到之前都被清理并包裹在带固定标签的围栏中。

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

提示词承载合同的另一半：围栏文本是报告的材料，而不是行动的依据。

评估：发布非确定性系统

从小提示词变更到新工具的任何东西都可能以难以预测的方式改变代理行为，而你正在发布的变更往往不是导致回退的那个。评估是你在部署前发现这一点的方式。我们之前关于代理评估的博客文章涵盖了通用实践。本节涵盖商业代理的具体内容。

评估快照，而不是对话

模型的API是无状态的，所以代理的输出是系统提示词、工具和消息数组的函数。这意味着商业对话能达到的任何状态都可以直接构建。因此，创建评估案例意味着构建测试状态，附加测试用户消息，并让代理从那里运行。

然后对结果评分：最终状态和渲染响应，包括最后一次写入的参数。在大多数情况下，我们建议不要对代理到达那里的路径评分，因为这类测试案例脆弱且限制性强。

模拟用户评估，其中第二个模型扮演用户，一个评判者评分整个对话，是测量效果差的工具。两个非确定性系统交互需要更大样本，每次试验成本更高，更难评判，并产生难以归因的失败。它们对发现覆盖缺口和代理整体感觉检查有用，所以用它们来发现案例，然后将每个案例写成快照。

大多数团队未能正确测试注入状态。一个案例应编码失败的先决条件，而不仅仅是任务。如果行为只在繁忙的第一轮多次工具调用后出现，或在会话早期矛盾后出现，从干净状态开始的案例会在每个配置上通过，并提供无意义的数据。

我们观察到大多数套件偏向这类干净状态案例，所以确保你的一部分案例从长、混乱或矛盾的历史开始。

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

对每个正面案例，写其负面对应物：每个“应拒绝”配一个“应服务”，每个“应询问”配一个“应直接做”。缺失负面案例是我们发现套件中最常见的缺口。

评估以下内容：

• 构成你流量主体的核心请求，因为这里的失败影响大多数会话。这些包括简单查询、多约束请求、产品和计划问题，以及多意图消息。对于问题，检查每个价格、可用性和属性是否追溯到返回数据，以及代理是否在数据缺失时说明而不是编造。

• 上下文相关请求，如引用屏幕上的内容、从早期轮次延续的约束，以及针对现有购物车的写入。评估记忆也属于这个类别。检查记忆是否被提取、检索并改变了答案。

• 安全和品牌案例，失败会花费金钱或信任。这些包括尝试注入、尝试读取其他用户数据，以及受监管语言，逐字节检查。将注入分为两个案例：用户撰写的注入，指令来自用户自己的消息；数据平面注入，指令植入产品名称、评论或通过工具结果到达的网页片段。

• 界面评估，确保渲染正确组件，项目上限被尊重，用户可见文本中没有内部标识符。也测试超时和空结果。

• 同时属于多个能力的请求。操作员问：“如果我降价15%，我有足够库存满足需求吗？”这是定价问题和库存问题一起。正确答案暂存降价并附带库存预测；错误答案做一件事跳过另一件。按能力编写的评估不会抓住这一点，因为每个只评分自己的一半。为需要两个相邻能力一起的请求写案例，并评分答案的两半。

与直接看到失败的主题专家合作，如产品、法律、商家运营、客户关怀和品类管理团队成员，设计测试案例。真实失败是最好的评估，每个用户流程50-100个评估案例是一个好的起点。

确保案例多样化，如上所述。生产转录是获取新案例的好来源，尤其是棘手的。编码代理擅长生成额外案例和对抗变体。参考仓库包含一个Claude Code插件，带有用我们推荐方法构建的评估编写技能。

在商业企业中，代理由许多工程团队构建。搜索、结账、定价、营销技术、客户关怀和目录平台各自拥有代理依赖的系统，各自按自己的节奏发布，各自想添加或更改工具、技能或提示规则。

与服务不同，代理没有严格的模块边界保护其他部分：定价团队做的更改与结账共享上下文窗口。

诱人的修复是将系统拆成许多子代理，每个业务单元一个。如第1部分讨论的，我们出于质量原因建议不要这样做。相反，我们概述降低多团队协作风险的过程：

• 所有权跟随系统。每个技能和工具有单一所有者团队。例如，定价拥有促销工具和定价技能，关怀拥有订单和退货工具及客户关怀技能。共享提示词有单一平台级所有者负责公共部分，领域所有者负责领域特定部分。

• 更改随案例发布，CI运行为其选择的集合。贡献技能的团队也贡献其案例，包括负面案例和针对相邻技能的边界案例。在每个拉取请求上运行完整套件太慢且太贵，无法持续，所以从中构建CI集合。该集合将包括最高流量请求的核心案例集和每个安全案例。在此基础上，运行更改触及的任何内容的案例。对于技能，这意味着其自身案例和邻居的边界案例。对于工具，是每个调用它的案例。对于共享提示词，是完整评估套件，因为所有内容都读取系统提示词。我们建议在几次试验中门控通过率，以及缓存命中率和每轮成本。每晚和每次发布前运行完整套件也是好实践。跨团队回退在这些运行中被捕获。

• 代理也应在发布日历内。它是一个部署单元，所以坏更改一次到达每个用户。先将提示和技能更改滚动到金丝雀队列，保持一个无需部署即可关闭一个技能的开关，并在高峰前冻结代理，就像冻结其他系统一样。

关于这种安排的人类方面，请参阅构建有效的人机代理团队。

展望未来

这篇文章描述的大部分内容不是关于模型的。工具调用你已运行的系统，技能编码你已遵循的程序，评估是你的产品需求文档写成测试，框架执行你会为任何客户端执行的政策。模型会继续改进，当更好的模型发布时，我们描述的架构将其作为配置更改并附带评估扫描来采用。其他一切继续工作。

思考产品界面的路线图也很重要。架构会比聊天面板更持久。同一个代理可以在语音上工作，并可以在用户询问前主动对票价下降采取行动。对于已有评估和工具的团队，那些是展示层项目。更远看，你店面的一些流量将来自代表用户购物的代理。相同的来源、暂存和批准规则让你的代理保持在边界内，也是让你安全地向那些代理开放工具的东西。

商业一直奖励让购买过程尽可能顺畅。代理让这容易得多。查看完整参考实现，包括消费者和商家代理，以及零售、旅行、电信和娱乐的可运行示例。

致谢

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

常见问题

相关文章

探索更多产品新闻和用Claude构建团队的最佳实践。

用Claude构建商业代理

Warp如何在Claude上构建自我改进代理

Slack中的自助数据分析：Anthropic如何部署Claude Tag处理临时问题

Claude 5代模型上下文工程的新规则

用Claude转变你组织的运营方式

获取开发者新闻通讯

产品更新、操作指南、社区亮点等。每月发送到你的收件箱。