--- layout: post.njk source: https://baoyu.io/translations/2026-09-02/the-anatomy-of-effective-commerce-agents speaker: baoyu.io title: 高效电商 AI 智能体解剖指南 | 选自 Anthropic 的 Claude 博客 | 宝玉的分享 date: '2026-09-02' summary: 本文是一份关于构建高效电商 AI 智能体的解剖指南，重点探讨了架构设计、延迟与成本优化、生产环境中的记忆管理、安全性约束以及评估实践。核心思想是优先使用技能而非子智能体，将 UI 组件工程化为工具，并通过提示词缓存、模型选择和严格的评估套件来平衡模型智商、延迟和成本，最终实现用户体验和业务指标的统一。 area: tech-engineering category: ai-application tags: - commerce-agent - agent-loop - context-engineering - prompt-caching - agent-evaluation people: [] companies_orgs: [] products_models: [] media_books: [] draft: true status: evergreen --- 宝玉的分享 Menu See all posts Published on 2026-09-02 Translated on 2026-09-02 # 高效电商 AI 智能体解剖指南 | 选自 Anthropic 的 Claude 博客 原文： A guide to the anatomy of effective commerce agents 作者： Claude 探讨如何让在线买卖变得更轻松的 AI 智能体架构、降低延迟 (Latency) （用户发出指令到看到系统响应所等待的时间）与成本的技巧，以及评估实践。 在过去的一年里，我们与整个商业领域的各个团队——从零售商、电商平台到旅游、娱乐和电信服务提供商——密切合作，使用 Claude 构建了专属的电商 AI 智能体 (Commerce Agents)。 这些 AI 智能体 (AI Agent) 已经投入实际生产线。企业客户发现，使用它们后，用户的购物车客单价变高了，卖家的运营效率也大幅提升。有趣的是，这些系统都有着一个极其简单的共享架构：将 Claude 放置在一个智能体循环 (Agent Loop) （大模型不断观察、思考、行动，直到完成目标的往复过程）中，并为其配备一系列技能、工具，以及一套强大的评估套件 (Eval Suite) （用来系统性测试和给模型表现打分的自动化工具）。 这篇文章是为那些正在构建这些（或其他面向消费者的）AI 智能体的工程师和技术领导者准备的。第 1 部分涵盖了架构设计，这是一项一劳永逸的决策。第 2 部分讨论了如何优化延迟与成本。第 3 部分则深入探讨生产环境中的实际问题：记忆管理、安全性、系统评估，以及如何在大型组织内部跨团队推广这项工作。 本指南内容： 第 1 部分：架构设计 什么是电商 AI 智能体？ 优先使用技能，而非子智能体 系统提示词还是技能：根据使用频率来决定 智能体工具的工程化设计 将 UI 组件也作为工具 第 2 部分：让它既快又省钱 尽可能缩短任务完成的延迟 优化感知延迟 提示词缓存 选择合适的模型及其配置 第 3 部分：在生产环境中运行 跨会话的持久化记忆 安全性：让 Harness 来把关 评估：如何为一个非确定性系统发版 在大型组织中协同发布 展望未来 01 ## 架构设计 在标准的智能体循环中运行单一模型，用各项技能覆盖长尾需求，用工具去调用你现有的系统。这是一个你只需要做一次决定的基础架构。 ### 什么是电商 AI 智能体？ 我们将电商 AI 智能体定义为：一种能够简化整个在线商品目录中买卖过程的智能体。 有些 AI 智能体是面向消费者的：它们可以搜索商品、对比价格、寻找替代品，并把它们整理成最终的订单。这可能是一个零售购物车、一份旅行行程单、一次手机套餐变更，或者是预留的演出座位。另外一些则是面向商家的：它们负责回答有关销售数据的疑问、执行促销和营销活动，以及管理库存和定价。 它的核心架构就是将模型置于一个标准智能体循环中：围绕目标进行推理、探索上下文、通过工具采取行动、通过技能学习操作流程、提出需要澄清的问题，并观察执行结果，直到最终完成目标。 在这个架构中，前端没有意图路由器 (Intent Router) （一种负责判断用户想做什么并分发任务的中间件）来对对话进行切片，后端也没有一堆特定领域的子智能体。 ### 上下文工程 (Context Engineering) #### 优先使用技能，而非子智能体 一个电商 AI 智能体需要涵盖横跨多个商品类别和用户意图的广泛能力。这就很容易让人产生一种冲动：干脆为每个垂直领域创建一个专门的子智能体 (Subagent) 吧。 但在实践中，这种做法往往不是最优解。因为一场电商对话往往是紧密相连的，它跨越了多种意图和对话轮次，需要共享大量的上下文信息。 在子智能体架构中，通常由一个主协调器来保存购物车信息或暂存的更改、用户的偏好以及历史对话记录。 每次将任务交接给子智能体，都是一次状态丢失 (State-lossy) （在系统切换时遗忘掉之前累积的数据和上下文）的操作。这通常会影响子智能体的回复质量，并最终拖累整体表现。更糟的是，每次交接都会消耗几倍的 Token，并增加好几秒的延迟。 而且，不同的业务领域也很难被干净利落地切割开来。比如，一个退货流程可能同时需要查看订单历史、当前购物车和商品目录。这就意味着，如果你采用“每个领域一个子智能体”的策略，要么你就得把这些访问权限复制到每个智能体上，要么就得在任务执行中途频繁交接。 随着模型变得越来越聪明，它们能够处理更长的上下文、掌握更多技能并使用更多工具。因此，过去那些限制我们将任务放在同一个模型里处理的旧规则，正随着每一代新模型的迭代而逐渐解绑。 相反，使用 智能体技能 (Agent Skills) 可以在不产生交接成本的情况下，为你提供类似“按领域划分”的模块化和上下文控制能力。因为技能指令会直接加载到已经掌握了完整历史记录的主智能体中。 在我们对多个企业级部署的对比测试中，单一智能体加技能的架构，在质量上始终优于“把所有东西塞进一个提示词”的设计，也优于“子智能体”设计，并且在处理每个任务时，通常成本更低、延迟更小。 那么，子智能体在什么情况下能派上用场呢？当主协调器将它们作为一个工具来调用，去处理那些高度垂直、自成一体，且需要专属上下文窗口的任务时，它们就能大显身手。 在生产环境中的一个典型例子是“深度研究”子智能体：它负责搜索和阅读大量文档、编写并运行代码、遍历数据模型，甚至在遇到死胡同时摸索出路。所有这些繁杂的工作都在一个或多个子智能体内完成，最后只把一个精简的答案传回给主协调器。 另一个例外情况是，某个业务领域已经有了一个专门定制的成熟智能体。如果你公司的药房业务或金融服务早就运行着一个有着独立合规要求的专属智能体，那么最正确的做法就是彻底“交接”——让那个专业智能体接管任务，并直接通过它自己的循环与用户交互，直到任务完成。 这里的核心区别在于“对话的所有权”。“交接 (Hand-off)”意味着领域智能体成为了直接面对用户的角色；而“委派 (Delegation)”则是主协调器仍然把控全局，只在单轮对话中把领域智能体拉进来用一下又踢出去，这会导致信息在来回传递中不断衰减。 #### 系统提示词还是技能：根据使用频率来决定 在决定是将某组指令放在系统提示词 (System Prompt) 中还是作为一项技能时，最重要的考量因素是：智能体需要用到它的频率有多高？因为加载一项技能会消耗模型的一轮对话周期，所以，只要是智能体在大多数轮次中都会用到的信息，通常都应该放进系统提示词里。 不过，这也取决于你的流量分布情况，以及你的评估结果所揭示的智能体行为。一个好用的经验法则是：任何与你三分之一及以上流量相关的指令——无论是你在发布前预见到的，还是在生产环境中观察到的——都请放进系统提示词里，剩下的长尾需求则做成技能。 如果你可以通过已有的信号（例如用户是从哪个页面跳转过来的）来预判用户需要某项技能，我们建议在模型进行第一次调用之前，就通过 Harness 把它注入进去，从而省去单独加载技能的那一轮额外开销。 至于那些至关重要的指令，比如安全和法律底线、品牌调性限制以及用户的关键信息（如过敏史），必须永远待在系统提示词里。 对于电商 AI 智能体而言，这意味着“商品搜索”必须写在提示词中，因为几乎每一次会话都会用到它；而技能则用来承载长尾的零碎功能。 在我们提供的 参考实现方案 中，购物智能体的提示词包含了背景设定、购物车和结账规则以及界面呈现规则。而其余的功能则由以下技能包揽：搜索发现、购买研究、目标规划、客户关怀以及记忆与个性化。 商家端智能体也采用了相同的拆分方式：它的技能包括业绩洞察、目录列表、库存操作、定价促销和营销活动——每一个操作领域对应一项技能。 在提示词中 购物智能体 背景设定、购物车和结账规则、呈现规则、商品搜索。 购物技能 长尾功能 搜索发现 · 购买研究 · 目标规划 · 客户关怀 · 记忆与个性化 商家技能 每个操作领域一个 业绩洞察 · 目录列表 · 库存操作 · 定价促销 · 营销活动 ### 智能体工具的工程化设计 我们关于为智能体编写有效工具的文章涵盖了工具设计的通用原则。而在电商领域，有两点尤为关键： 将智能体工具建立在你的核心系统和业务逻辑之上。 一家电商公司通常已经拥有一套成熟的搜索和排序系统、购物车、偏好与个人资料库、库存系统、促销与活动引擎、销售分析等等。这些系统每一个都包含了历经多年打磨的业务逻辑，并且能够获取到大模型永远无法直接看到的底层信号。 AI 智能体的工具应该去调用这些系统，而不是试图用大模型去重新实现它们。所谓的“工具边界”，就是指你现有系统的业务逻辑结束，大模型的判断力接管的地方。 例如，当智能体调用 search_products（搜索商品）时，返回的结果应该是已经排好序的；大模型的工作是去判断哪些结果符合用户的目标、该展示多少个，以及如何向用户呈现它们。 工具的返回结果即是上下文。 只返回大模型在推理时需要用到的字段，把其余没用的数据全部丢掉。最常见的违规者就是每条搜索结果里都带着的长长一串图片 URL。 如果需要，可以在工具内部对原始的返回数据进行重塑。比如，如果下一步的操作从数据本身看不出那么明显，你可以在结果里附加一句下一步的指示。 这在处理错误场景时特别有用，因为大模型更喜欢明确的指示，而不是干巴巴的错误代码。例如，与其返回一个通用的 403 错误，不如添加一句错误说明：“查询库存情况时，请务必包含商品 ID。” #### 将 UI 组件也作为工具 大多数电商 AI 智能体的回复并不是大段的散文，而是具体的 UI 组件——无论它是商品轮播图、旅行行程单、座位图还是一张图表。这就意味着智能体需要输出符合特定格式（Schema）的数据，而不是纯文本。 团队在起步阶段，有时会通过提示词让大模型输出自定义的标签，然后在客户端进行解析。但随着业务范围的扩大，这招很快就会失效，原因如下： 相比于专门训练过的工具调用，大模型对你的自定义标签标记法的熟练度没那么高。因此，随着嵌套组件越来越多，系统的可靠性会急剧下降。仅仅依靠提示词是无法保证数据格式永远不出错的。 标签定义全堆在系统提示词里，每一个新增加的组件都在使上下文变得臃肿，每一次修改都有可能引发提示词其他部分的倒退（Bug）。 过去的对话记录最终会被存储成一种只有你的解析器才能看懂的格式。这意味着，当需要加载历史记录时，你要么在客户端重新解析这些原始消息，要么就得在原生模型 API 格式之外，再保留一份你自己的数据副本。 经受住考验的最佳模式是：把每一个 UI 组件都做成一个工具。大模型带着特定类型的参数去调用 present_products（展示商品）、present_itinerary（展示行程）或 present_plan_comparison（展示方案对比）；你的服务器验证并丰富这些调用，然后发出一个事件；最后由你的客户端进行渲染。 既然这些组件本质上是工具调用，它们就已经以原生格式存在于消息数组中了。当你重新加载一段旧对话时，根本不需要再重新解析一遍。你可以在下方以及 参考代码库 中看到展现类工具的契约示例。 上面两个面板运行的是同一个 AI 智能体，使用的是完全相同的工具和提示词；唯一的区别在于 Agent Harness。总的运行时间差不多，但用户察觉到系统做出反应的时间却大相径庭。 这里的取舍在于流式传输的粒度。工具调用的每个顶层参数都会先在服务器端缓冲进行验证，因此，即使开启了流式传输，呈现类工具的子组件也是一步一步跳出来的。这会在一定程度上影响用户的感知延迟。 如果想实现细到 Token 级别的极致流式传输，可以在工具定义上设置 eager_input_streaming: true，这会跳过缓冲阶段，但代价是放弃服务器端的数据格式强保证。 在我们的评估中，在 Claude Sonnet 级别及以上的模型上，格式违规极为罕见。但以防万一，建议给调用包裹一层重试机制，以处理偶尔漏网的错误。 这类呈现工具还能为智能体提供一份屏幕上正显示着什么的记录。当客户说“第一个酒店”或者“左边数下来第三个”时，由于布局信息就藏在最后一次呈现类调用的参数里，存在于消息数组中，智能体立马就能知道用户在指什么。 为了让这一招奏效，参数的结构必须真实反映 UI 的渲染布局。所以，请按照界面的结构（比如有序的行和轮播图）来组织数据，而不是扔给客户端一个扁平的列表让它自己去排序。 02 ## 让它既快又省钱 从端到端和用户感知两个层面猛攻延迟问题，让缓存帮你分担成本。所有这些优化，都不应该以牺牲大模型的“智商”为代价。 在电商领域，延迟是致命的，尤其是面向消费者的界面，对延迟的容忍度极低。然而，在智能体应用场景中，我们持续观察到一个现象：真正能撬动留存率、参与度和购物车规模等核心指标的，往往是最终结果的质量。 相比于挤牙膏般节省出的一点点延迟，答案是否相关、任务是否真正完成，对这些指标的影响要关键得多。 因此，我们要兵分两路来攻克延迟问题。一方面通过优秀的工程设计来尽力缩短端到端的绝对延迟；另一方面，配合降低用户的“感知延迟”（因为看着智能体一步步推进工作，会让用户觉得等待是有意义的）。 每个用户的心里都有一个“延迟预算”，下面的这些技巧能帮助你的智能体在这个预算范围内完成任务，而且不需要牺牲模型的聪明才智。 ### 尽可能缩短任务完成的延迟 任务完成的延迟，等于大模型思考的轮次数，乘以“首字显示时间加上工具处理时间”的总和。这就为你提供了三个优化杠杆：减少对话轮次、让工具跑得更快、让 Token 生成得更快。这三个杠杆有时会互相拉扯，所以你要优化的目标是它们的总和，而不是死磕其中的某一个。 减少对话轮次： 提前加载可能用到的上下文，提升模型的智商，让模型并行调用互不依赖的工具。 让工具跑得更快： 优化工具自己的后端逻辑，在工具的参数一生成完毕就立刻“急切地 (Eagerly)”触发分发。 让 Token 生成得更快： 通过跑一遍你的评估套件来选择最合适的模型及其参数配置。 #### 减少对话轮次 用户提问越复杂，需要的对话轮次就越多，而这通常不是你能控制的。模型的智商越高、上下文里的信息越相关，智能体就能用越少的轮次完成任务。我们在这一领域的一些关键心得包括： 提前加载大概率会用到的上下文。 如果用户是在商品详情页唤醒了助手，或者商家是在某个活动的仪表盘页面打开了它，那就把该页面的数据直接塞进会话的上下文中。因为接下来的对话很可能与此相关，而且从已有的上下文中作答是不需要消耗额外对话轮次的。 提升模型智商。 更聪明的模型可以更高效地规划并下达工具调用指令，从而减少完成任务的总轮次。这种轮次上的节省，往往足以抵消它们生成 Token 速度稍慢的缺点。如果你的用户提问往往很复杂，或者生产环境数据显示完成一个任务经常需要超过五个轮次，那么速度最快的模型通常是那个最聪明的模型。具体该选哪个，取决于你的真实流量，所以请像下文“选择模型”部分描述的那样，通过扫表测试 (Sweep) 来决定。 让模型并行调用互不依赖的工具。 电商场景经常需要并行执行大量操作：比如同时搜索多个商品、查询好几份退换货政策文档，或是从多个销售数据源拉取记录。并行调用工具可以确保多个独立的查询不会浪费额外的对话轮次。你可以通过提示词引导模型在同一轮中调用多个工具，并将结果作为一个工具结果数组，在一次用户消息中返回（参见 并行工具调用文档）。 #### 让工具跑得更快 优化工具自己的后端。 有时候，一个工具的背后确实需要向外发散——比如一个商家智能体收到“获取今日快照”的查询时，需要发起三次独立的调用去分别读取销售额、库存和活动状态。但我们经常看到，工具边界变成了东拼西凑各种缺失后端逻辑的垃圾桶：比如一个“查库存”的工具，非得先去商品目录查 SKU，再去门店库存服务查每家店，再去履约服务查截单时间，最后还要在工具自身的代码里应用一套替代规则和自提条件，搞完这一切才肯返回结果。这个工具现在承载了过载的领域知识，只要规则一变，想保持它的准确性就难如登天，它其实在干上游系统该干的活。当你发现自己正在一个工具里手写这种业务逻辑时，正确的解法是：在后端创建一个能直接回答这个问题的端点 (Endpoint)，然后让智能体工具去调用这个端点。 急切地 (Eagerly) 分发工具。 工具的参数就像大模型输出的其他普通文本一样，是以流式的形式出来的。因此，Harness 可以在某个工具的参数一输出完毕时，就立刻执行它的调用，并在模型还在并行流式输出其他工具或内容块的时候，就开始处理这个请求。我们曾看到这个技巧将长达数秒的等待空隙缩短到了几百毫秒以内，而 Claude Agent SDK 默认就是这么做的。你可以通过提示词引导模型把最慢的调用放在最前面输出，以此最大化地压缩延迟。 上面两个面板运行的是同一个 AI 智能体，使用的是完全相同的工具和提示词；唯一的区别在于 Agent Harness。总的运行时间差不多，但用户察觉到系统做出反应的时间却大相径庭。 ### 优化感知延迟 感知延迟是指用户在感觉上，屏幕做出反应之前等待的时间。在面向消费者的场景中，这一点尤其致命，因为交易过程中的任何摩擦都会直接拉低结账率和营收。有两个不涉及修改模型的技巧可以大幅缩短感知延迟： 边生成边渲染组件。 一个经过渲染的电商回复通常包含 500–700 个输出 Token。如果不使用流式传输，用户就得盯着转圈圈的加载动画看上五秒甚至更久。你应该在呈现类工具的各个参数流出时，就把它们同步发送给客户端，并在页面上逐步渲染出来。 展示思考过程。 当智能体在疯狂收集上下文时，用简明扼要的自然语言为它的每一个步骤渲染一行简短的进度提示（例如，“正在查找海边的酒店...”）。你可以直接从工具现有的参数（比如商品搜索的查询词）中提取信息来生成这行字，或者在工具中添加一个额外的 user_facing_message 参数，让模型自己来写这行提示语。 上面两个面板运行的是同一个 AI 智能体，使用的是完全相同的工具和提示词；唯一的区别在于 Agent Harness。总的运行时间差不多，但用户察觉到系统做出反应的时间却大相径庭。 ### 提示词缓存 (Prompt Caching) 提示词缓存是你削减成本的最大杀器，而电商领域的流量特征简直是为它量身定做的。读取被缓存的输入 Token，成本只有全新读取的十分之一；虽然写入缓存时有大约 1.25 倍的溢价，但只要缓存前缀被第二次使用，它就能把成本赚回来。在面向客户的高流量应用中，你拥有得天独厚的机会，只需使用最廉价的、默认 5 分钟的缓存过期时间，就能达到极高的缓存命中率。 我们见过的最棒的电商部署案例，缓存命中率高达 90–99%。在项目初期，你就应该奔着这个目标去设计。我们的经验还表明，在处理大约 10 万个 Token 时，读取缓存 Token 的速度大约能快 1.5 到 2 倍，而且 Token 越多，速度提升越呈线性扩大。 缓存是基于前缀匹配的。当一个请求发来时，系统会从缓存中一直读取，直到遇到与上一个请求不同的第一个字节为止。所以，关键不仅在于上下文里放了什么，更在于它们摆放的顺序。你可以把一次请求想象成由三个按变化频率排序的区块组成： 全局区块 (Global)： 包含了绝大部分的系统提示词和工具定义。这部分内容在每一次会话中都是完全相同的。这是你最火热的缓存，在大规模并发下，它几乎永远不会过期。请确保这部分内容在不同轮次和会话之间连一个字节都不要变，并在它的末尾放置一个缓存断点 (Cache Breakpoint)。 会话区块 (Session)： 包含了每个用户专属的上下文和历史对话记录。这些内容在不同用户的会话中各不相同，但在单个用户的对话过程中是保持稳定的。这个区块紧跟在全局区块之后。 易变区块 (Volatile)： 任何在一个会话内会频繁变动的东西，比如当前时间或用户目前正在浏览的页面。请把它放在整个请求的最末尾，要么作为最新一次用户轮次中打上特定标签的文本块，要么（对于支持 会话中系统消息 的模型）作为附加在消息数组末尾的 system-role 消息。我们最常看到的一个愚蠢的错误，就是有人把时间戳或当前页面链接直接挂在系统提示词的最开头，这会导致缓存每次请求都会被静默击穿（失效）。 这里有两个需要牢记的实现细节。首先，技能应该作为“工具结果 (Tool Results)”被加载，而不是被硬生生地拼接到系统提示词里。这样，技能的主体内容就会落入对话的前缀中，从而跟着一起被缓存。 其次，在每一轮对话中把你的断点往前滚：因为每次请求允许的断点数量是有限的，所以你要把最新的一个断点移到每次用户轮次的末尾。这样一来，每一轮就都能从缓存中读取累积的历史记录了，包括那些像长篇搜索结果一样冗长的工具返回数据。 ### 选择合适的模型及其配置 模型规模与努力程度设置 (Effort Setting) 面临的是同一个权衡题——在智商与延迟、成本之间做取舍。你应该用实打实的数据测试来做决定： 确定你的北极星指标和容忍底线。 挑出你的业务赖以生存的质量指标（比如任务完成率、回答相关性、基于事实的准确度），定下一个绝不能妥协的评估分数底线，并圈定你的 p50 和 p99 延迟及成本预算。 全面扫表测试 (Sweep)。 让你的整个评估套件在你考虑的每一个模型和努力程度上跑一遍。我们建议商家智能体（大量涉及分析任务）从 Opus 开始测，消费者智能体（对延迟更敏感）从 Sonnet 开始测。如果你手头有生产环境的真实流量，就按照真实的查询比例对测试结果进行加权。然后，让数字说话。有时候，Opus 5 在促成购物车转化这类任务上的表现带来的收益，完全能值回它比 Sonnet 贵出的差价；但有时候则不然。 仔细解读测试结果。 有两件事经常让团队大跌眼镜。第一件事是：提示词通常是针对特定模型调优过的，因此，如果你用为模型 A 写好的提示词去测试模型 B，结果可能会很不理想。小模型往往需要那种“手把手教”的指令，而当前的大模型可能自己就能悟出来；反之，大模型可能会死板地遵从那些小模型根本就无视了的指令。所以在淘汰任何一个候选模型之前，针对它的失败用例进行几轮微调，是一步成本极低但极其关键的操作。第二件事是：一个更聪明的配置，尽管它吐字（Token 生成）的速度更慢，但有时却能在最终的延迟数据上（最常见的是在 p90 和 p99 上）胜出。这是因为它能够更好地规划工具调用，在处理最复杂的请求时，能够用更少的轮次一锤定音。 在计算成本时，请以“完成单次任务的成本”为准，而不是“单次模型调用的成本”。因为如果一个便宜的模型需要更多轮次才能搞定，或者频繁翻车，那它其实一点都不便宜。当测试结果不相上下，而且成本也在你的单任务经济模型和延迟容忍度之内时，请毫不犹豫地选择“高智商”。因为最终推动用户采用和留存的是质量，而且这也为你预留了空间——在未来 6 个月随着模型变得更强，你还有底气去构建更复杂的特性。 03 ## 在生产环境中运行 记忆、安全性、评估，以及跨团队的协作与发布：这些才是让一个 AI 智能体跨越生产门槛并基业长青的基石。 最后，我们来聊聊让一个智能体在生产环境中存活下来的关键：记忆、安全性、评估，以及如何在大型组织内协同作战。 ### 跨会话的持久化记忆 你与客户建立的关系和互动至关重要。记忆，正是让智能体能够“接着上次聊”而不是“假装第一次见面”的魔法。一个在三月份提到过坚果过敏的购物者，绝不应该在六月份还要被迫再重复一遍；一个每周一都要检查相同三个营销活动的商家，也不应该每次都要把活动名字重新报一遍。长期记忆（那些应该在会话之间留存下来的事实）是一个需要你亲手搭建的系统，它由三个部分组成：记忆如何被存储、如何被写入、以及如何被读取。 #### 存储记忆 记忆应该存放在你自己的系统里，而不是大模型里。 当个人资料很少，且智能体是唯一的读取者时，弄个扁平的 Markdown 文件记录一下还算行得通。但大多数生产环境下的电商智能体会很快撑爆这种简陋的方式，最实用的替代方案就是你目前已经在维护的数据库。一条记忆事实应该是一条结构化的小记录：一个键 (Key)（比如 shoe_size 鞋码、default_store 默认门店、preferred_report_cadence 偏好的报表频率）、一个简短的值 (Value)、一个分类标签，以及这条记忆是产生于哪个会话的。有些键是你预先设定好、每个用户都有的；其余的则是靠提取器去自动发现的。随着存储量增长，数据库仍然支持高效查询，让你能够基于特定属性构建确定性的行为，并且能轻松地跟你现有的用户数据进行关联查询。 对于面向商家的智能体，记忆应该以“人”为维度来建立，而不是以“账号”为维度。因为商家的登录账号经常是几个运营人员共享的，每个运营人员都需要拥有自己的个人资料库，而且读取记忆时必须尊重该人员的权限：一个门店经理的智能体，绝对不能调用区域经理所陈述的机密事实。 在电商领域，智能体的记忆必然包含个人数据。那些最值得被记住的事实，往往也是受监管最严的数据，不同国家和地区的法规也大相径庭。请把记忆视为一个“数据处理与合规”的设计难题，而不仅仅是一个存储问题。在实践中，这意味着四件事： 明确界定你愿意保留哪些类型的记忆。 要在数据写入环节就把好关，用一个验证器强行拦截所有不合规的存储请求，而不能仅仅在提示词里轻飘飘地写上一句规则。 让用户有权查看、修改和删除他们被保存的信息。 将记忆的删除功能，无缝接入你现有的“注销账号”和“数据请求”流程中。 设定一个留存期限。 几年前的喜好早就过时了，设定一个过期时间有助于保持记忆的新鲜度。 记忆功能必须是一个每个部署区域独立可控的开关。 这样那些无法承担这些合规义务的区域，就可以直接关掉它“裸奔”。 #### 写入记忆 采用异步方式写入记忆。在每一轮对话结束时，或者在漫长会话中每隔几轮，在一个独立的线程或进程中运行的另一个智能体会去阅读对话记录，并在存储库中创建、更新或删除事实。同时，它也会维护好它自己的会话工作上下文。 这种方式对主对话的延迟没有任何影响。在我们内部的电商记忆评估套件中，它实现了 13% 的事实召回率提升。 显而易见的替代方案——给主智能体配备一个“保存事实”的工具让它自己调用——对于对延迟极度敏感的电商智能体来说，是极其糟糕的。因为每一次保存都会消耗一个面向用户的对话轮次；而且，除非整个记忆库都在上下文中，否则在保存之前它还得先读取一遍以进行更新或去重，这又得浪费一轮。 更何况，这等于在每一轮对话中都给主智能体增加了一个决策负担。在我们的评估中，这种对大模型注意力的争夺，直接表现为了错失该记住的信息。 把提取器拆分出来，还让你能更精准地对它下达提示词。它只负责阅读用户和助手的纯文本对话，绝不碰工具返回的结果，这样就能防止商品描述或者其他人的评论意外变成关于用户本人的事实。你可以用提示词明确告诉它什么才算是事实——明确说明的尺码、饮食禁忌、配送偏好、商家常用的自定义报表视图——以及什么不是（比如商品列表里的内容或一次性无关紧要的细节）。 #### 读取记忆 分三层读取记忆。 始终挂在上下文中： 一小部分固定的核心事实要在每一轮对话中都挂载到上下文中：即那些几乎每次请求都离不开的，比如购物者的默认门店和配送偏好，或者运营人员所在的门店和职务。 每轮按需预取： 与当前请求高度相关的事实，在每一轮中预先拉取，触发逻辑与预加载技能类似：比如一次搜索鞋子的请求，会自动带出用户的尺码和偏好的品牌；一个关于活动的提问，会自动带出运营人员常看的指标。 藏在查询工具背后： 所有其他不那么常用的记忆，统统丢给一个“查询工具”去按需获取。 因为记忆属于用户维度的上下文，所以所有的记忆都应该塞进“会话区块 (Session)”里，放在全局缓存断点的下方。 ### 安全性：让 Harness 来把关 提示词是引导大模型做出安全行为的第一步，但在电商这种直接涉及钱且往往不可逆的场景下，提示词绝对不能成为执行安全防护的最后一道防线。只需一次提示词注入攻击，或者大模型抽了一次风，提示词里的规矩就形同虚设了。以下列出的每一条规则，都必须在面向消费者和商家的两端智能体中，在代码层面进行强制约束。由于只需定义一次，所有运行环境都能共享这套铜墙铁壁。 #### 模型只管“打草稿”；由真人或既定策略来“拍板” 没有任何大模型的工具调用能够直接转移资金或篡改业务。不管是下单付款、退款、改价格还是上线活动，所有的最终动作都必须由 Harness 来牢牢把控，大模型连碰都别想碰。 在消费者端，这是从结构上堵死的：结账工具只负责渲染出一个带有“确认下单”按钮的购物车页面，而智能体调用的后端接口里，压根就没有“扣钱”这个方法。 在商家端，所有的“写入”工具都只能生成一个带有服务器分配的 ID 的“暂存更改”。只有那些通过了真实途径（比如在运营后台点了按钮、在命令行里敲了确认，或者当智能体运行在 Managed Agents 上时，通过平台自带的工具审批弹窗）被批准的 ID，才能调用 apply_change 真正生效。 这些防护栏在“应用更改”的最后一刻，还会根据当前的限制条件再做一次校验，而不是拿着“暂存”时的限制数据来放行。不管前端界面长什么样，核心逻辑永远是同一个：大模型能做出的最危险动作顶多是“提个建议”，而审批流程必须老老实实走你们业务系统里早就建好的“制单 - 复核 (Maker-checker)”老路子。 #### 写入和渲染操作只认“服务器下发的 ID” Harness 会在每个会话中，记下服务器交给大模型的每一个 ID，并且这本账是任何写入或界面渲染操作唯一认准的通行证。 购物车里只允许添加服务器在这个会话中真正吐出来过的商品 ID；商家工具也只接受智能体真正读取过的商品列表 ID 和活动 ID。如果一个 ID 是通过其他歪门邪道进来的——比如大模型幻觉瞎编的、用户自己复制粘贴的，或者是夹带在某条评论里的——它在抵达后端之前就会被无情地拒绝。 这个规则同样适用于 UI 界面。呈现类工具只接收 ID 参数，服务器会亲自去填补这个 ID 对应的商品、订单或更改记录的详细信息。所以，前端卡片上渲染出来的东西，永远是服务器自己拿回来的绝对真实的数据。 它同样也管着代理子智能体：商家分析子智能体可以随便查数据，但绝不能往主智能体有权写入的 ID 库里私自塞入任何新 ID。 至于各种费用明细、免责声明等受高度监管的内容，模型只负责挑选“要把哪个产品的条款展示出来”，而服务器则会一字不差地提供审核通过的标准话术。商家端智能体的受保护字段列表里也同样锁死了这些费用字段，所以柜台两边谁都别想篡改或用自己编的话去解释它们。评估系统也会针对渲染出的字符串，进行严格到字节级别的核对。 #### 设有上限的交易必须能扛住高频重复请求的轰炸 大多数电商系统都会限制一个用户能购买同一件商品的数量——无论是为了抢票、享受促销价，还是防范薅羊毛——而一个 AI 智能体会以人类点击按钮绝对达不到的速度疯狂重试、换着法子要、甚至并行并发去冲撞这个限制。 因此，“数量上限”的校验逻辑被死死地焊在了写入完成后的那条底线上。这样一来，第二句“再给我加两件”根本无法叠加突破上限。单次会话的购物车写入操作也是串行排队的，哪怕大模型在一轮对话里并发了多个工具调用，也休想合起来钻数量上限的空子。 针对商家的各种修改操作——比如调价幅度、打折力度、补货数量以及活动预算——也会被采用同样的逻辑进行校验，外加一份“任何修改都碰不得”的受保护字段黑名单。这条规则放之四海而皆准：把一切限制条件的红线画在“最终状态”上，而不是画在“请求过程”中，并且在单次会话里让所有写入操作乖乖排队。 #### 第三方内容必须经过消毒净化 在电商环境里，绝大部分的上下文都是由非你们公司的人写的——比如第三方卖家、写评论的买家、甚至竞争对手。因此，每一次后端数据读取，都必须被视为“不可信输入”，且必须经过一道净化器的消毒。 任何由第三方撰写的工具返回结果（如商品详情、买家评论、政策规定、卖家留言以及存储的记忆），在交给模型查看之前，都必须被彻底净化，并用一种带有固定标签的围栏给圈起来。 这个净化器会剥离掉所有控制字符和双向文本控制符，删除任何试图伪造围栏标记的东西，拆掉那些试图模仿人类对话轮次或大模型工具调用的文本炸弹，并限制整体长度，防止恶意上架的商品试图伪装成系统指令或恶意塞爆上下文窗口。 而提示词则负责履行契约的另一半：围栏里的内容只能用来作为报告的素材，绝不能用来作为执行动作的指令。 ### 评估：如何为一个非确定性系统 (Non-deterministic System) 发版 即使只是修改了几个字的提示词或者新增了一个工具，都有可能让智能体的行为发生无法预测的巨变，而且你试图发布的新功能没事，原有的老功能却经常跟着遭殃（退化）。而评估 (Eval)，就是帮你赶在发布到生产环境之前，揪出这些幺蛾子的探测器。我们之前发布的关于 AI 智能体评估 的博客文章详细探讨了通用实践法则。下面这部分则专门针对电商 AI 智能体的评估。 评估“快照 (Snapshots)”，而不是“完整对话” 模型的 API 本质上是无状态的（它没有记忆），智能体最终吐出什么，纯粹是由系统提示词、工具列表和它当前看到的消息数组（历史对话）决定的。这意味着，电商对话能达到的任何一个状态，都可以被我们直接人工构造出来。因此，创建一个评估用例，就是去把测试状态给“拼”出来，再往末尾加上一句测试用的用户消息，然后让智能体从这个节点跑下去。 接着，就去给跑出来的结果打分：评估最终的状态以及渲染出来的回复（包括最后一次写入操作携带的参数）。在绝大多数情况下，我们极度不建议去给智能体到达那个结果所“走过的路径”打分，因为这种测试用例极其脆弱且画地为牢。 那种让另一个大模型来扮演用户，然后让一个“裁判模型”给整个对话打分的“模拟用户评估法”，并不是一个用来精确测量的趁手工具。两个非确定性系统（相同输入可能产生不同输出的模型）在一块儿胡侃，需要极其庞大的样本量才能得出有意义的结论，不仅单次测试成本高昂、评判标准难以统一，而且一旦测出问题，你甚至都不知道问题出在哪一步。这种方法最大的价值在于用来扫盲（发现未被覆盖到的角落）以及对智能体进行整体的“氛围感”摸底。所以，请用它去发掘新的边缘用例，但当你把这些用例写进代码里时，请把每一个都写成静态的“快照”。 #### 在恶劣条件下测试系统的行为 大多数团队根本没有把注入的状态测试到位。一个优秀的测试用例，应该去模拟导致系统崩溃的“恶劣前置条件”，而不是仅仅抛出一个任务。如果某个特定的行为，只有在第一轮经历了手忙脚乱的十几个工具调用，或者在对话初期就出现了自相矛盾的条件后才会原形毕露，那么一个永远从“干净初始状态”启动的测试用例，就会在任何配置下都绿灯放行，根本提供不了任何有价值的数据。 我们发现大多数评估套件里都塞满了这种“过于干净”的用例，请务必保证你的测试库里，有一定比例的用例是从冗长、混乱甚至相互矛盾的历史对话中启动的。 ##### 覆盖各种类型的电商评估用例 有效的评估，不仅要测“它应该怎么做”，还要测“它不应该怎么做”。 为你写下的每一个“正向期望用例”，都补上一个“反向雷区用例”：测了“它应该提供服务”，就要测“它遇到敏感词应该果断拒绝”；测了“它应该直接执行”，就要测“它在条件不具备时应该主动提问确认”。缺少反向雷区测试，是我们见过的测试套件中最普遍的漏洞。 请评估以下几个核心维度： 核心高频请求： 这些构成了你绝大部分的流量，这里一旦翻车，几乎所有会话都会受影响。包括简单的信息查询、带有多重约束条件的搜索、商品和套餐咨询，以及一句话里包含了多种意图的复杂消息。对于查询类的任务，要重点检查它的每一次报价、每一个库存数据和属性说明，是否都能追溯到真实返回的数据源；当数据缺失时，智能体必须老实承认，绝不允许大开幻觉瞎编乱造。 依赖上下文的请求： 比如用户指着屏幕上的东西发号施令、延续之前几轮提出的限制条件，或者是对现有的购物车发起修改。对“记忆”的评估也属于这个篮子。要检查系统是否成功提取、检索到了记忆，并且这条记忆是否真的改变了最终的回答。 安全性与品牌底线用例： 在这些地方翻车，丢掉的要么是真金白银，要么是用户信任。包括恶意提示词注入攻击、试图偷窥其他用户数据的违规越权尝试，以及受强监管的法律条款话术（必须进行字节级的精准核对）。将注入攻击拆分为两类重点照顾：一类是“用户发起的注入”，即恶意指令直接写在用户的对话框里；另一类是“数据层注入”，即恶意指令被悄悄藏在商品名称、评论区或网页片段里，随着工具查询结果被顺手牵羊带入系统。 界面 (Interface) 评估： 确保渲染出了正确的前端组件，商品数量上限得到了严格遵守，而且面对用户的文本里绝对不能出现内部的神秘 ID 乱码。别忘了连超时 (Timeouts) 和空结果也一并测了。 横跨多个能力领域的交叉请求： 一位运营人员问道：“如果我把这个商品降价 15%，我的现有库存够撑得住随之暴增的需求吗？”这同时涉及了定价和库存两个领域的知识。完美的回答是：帮他把降价草稿打好，顺便贴心附上一份库存消耗预测表；而那些糟糕的智能体，只做了其中一半，然后把另一半忘到了九霄云外。如果你是按单个能力模块来写评估的，那你根本抓不到这个错，因为每个模块只负责给自己那一亩三分地打分。所以，请一定要为那些需要两个相邻能力“合体”才能搞定的请求编写联合测试用例，并对这两半的完成度进行综合打分。 ##### 拉着业务专家一起写评估，并从真实的线上事故中取材 请与那些冲在第一线、最先看到惨痛翻车现场的领域专家 (SMEs) 紧密合作——比如产品经理、法务、商家运营、客服团队以及类目管理团队。把真实的线上事故改编成测试用例是极好的，对于每个核心用户链路，起步阶段积累 50-100 个用例是一个比较靠谱的基准线。 请务必保证用例的多样性，正如上文所述。生产环境中的真实聊天记录是挖掘新用例的富矿，尤其是那些极其诡异和刁钻的对话。善于写代码的 AI 智能体非常擅长扩充测试用例和生成对抗性的变种。我们提供的 参考代码库 里就包含了一个基于 Claude Code 插件构建的“自动编写评估用例”技能，它正是采用了我们推荐的这套方法论。 #### 在大型组织中协同发布 在大型电商企业里，这个超级智能体往往是由好几个互相独立的工程团队拼凑而成的。搜索组、结账组、定价组、营销技术组、客服组以及商品目录中台，各自把持着智能体依赖的底层系统。每个团队都有自己的发布节奏，也都会想要往里面塞新的工具、改动某项技能，或者在提示词里加上几条“必须遵守”的规则。 由于它不是一个通过 API 隔离的微服务，智能体内部没有那种能把大家隔开的铁板一块的模块边界：定价团队往里面写的一条新规则，实际上跟结账团队共享着同一个上下文窗口。 一种非常诱人的偷懒做法是：干脆把它拆成一堆“子智能体”，每个业务部门领走一个各管各的。我们在第 1 部分中已经苦口婆心地劝过了，出于对整体质量的考虑，极其不推荐这么搞。相反，我们总结了一套旨在降低跨团队协作风险的流程： 谁的系统谁负责。 每一项技能和每一个工具都必须有且仅有一个明确的主人。比如，定价团队负责拥有所有促销工具和定价相关的技能；客服团队则包揽订单、退换货工具以及客户关怀技能。而那个所有人都在用的共享提示词 (Shared Prompt)，必须有一个属于平台级的“大总管”来拍板通用部分，各个领域的部分则由各自的领域负责人把关。 新代码必须带着它自己的测试用例一起发版，CI (持续集成运行) 只跑精选集。 如果一个团队想贡献一项新技能，他们必须自己连带着把配套的测试用例（包括雷区用例以及与隔壁技能打架的边界用例）一起交上来。在每次提交代码 (Pull Request) 时把成百上千个测试用例全跑一遍，既慢得让人抓狂，又烧钱烧得让人心疼。因此，你应该从庞大的测试库里挑选一个 CI 精选集。这个精选集包含了遭遇最高频流量冲击的核心用例以及每一条安全底线用例。在这个基础上，再额外加上专门针对这次代码改动所触碰到的用例。如果改的是一项技能，那就跑它自己的用例和它邻居的边界用例；如果改的是一个工具，那就把所有调用了这个工具的用例全跑一遍；如果动的是“共享提示词”，抱歉，老老实实把整个庞大的测试套件跑完吧，因为所有的东西都会受到系统提示词的影响。我们建议，除了看通过率是否稳定，还要重点盯防“缓存命中率”和“单轮对话成本”等指标。此外，每天夜里以及每次大版本发布前，把整个测试套件完完整整跑一遍也是一项极佳的实践。跨团队修改造成的隐性连带破坏，通常都是在这个环节被逮住的。 智能体的发版节奏必须与大盘对齐。 它是一个牵一发而动全身的部署单元，一旦发布了一个带毒的修改，所有用户都会立刻遭殃。所以，对提示词和技能的任何修改，都必须先给一小撮灰度测试用户（金丝雀发布）使用；务必留有一个可以直接在后台一键关掉某项技能的“救命开关”，而不需要重新走发版流程；在双十一等流量洪峰到来之前，请像封板其他核心交易系统一样，果断冻结智能体的任何发版。 关于这套机制背后关于“人”的一面，请参考 构建高效的人机协作团队。 ## 展望未来 这篇文章里洋洋洒洒写的绝大多数内容，其实都跟“大模型”本身关系不大。工具只是负责去调用你早就跑得很溜的系统；技能只是把你日常工作流程用代码写下来；评估套件其实就是你用测试用例的格式写出来的产品需求文档；而 Harness 则是在执行你本来就会对任何客户端强制执行的死规矩。模型注定会不断进化变得更强，当一个更牛的新模型问世时，我们所描述的这套架构只需要修改一行配置，然后把评估跑一遍就能完美接管。其他的所有东西，依然会稳稳当当地继续运转。 思考你的产品界面未来将走向何方同样重要。这套底层架构的寿命，绝对会比那个狭窄的“聊天面板”长得多。同一个底层智能体，完全可以披上语音的外衣进行交互；它也可以在用户开口之前，就主动捕捉到票价暴跌的信号并替用户锁定。对于一个早就把评估套件和各种工具打磨得炉火纯青的团队来说，这些都只不过是前端展现层的小项目罢了。再往远看，未来访问你店铺的流量，很大一部分可能根本不是人，而是代表人类来扫货的其他 AI 智能体。而正是那些把你自家的智能体管得服服帖帖的溯源、暂存校验和审批规则，也将成为未来让你敢于把自己的 API 工具安全地向这些外来智能体开放的底气。 电商行业永远信奉一条铁律：尽可能扫平用户买单道路上的一切障碍。而 AI 智能体，让这件事变得前所未有地简单。快去看看我们提供的 完整参考实现方案 吧，里面既有消费者端的智能体，也有商家端的智能体，并且自带了零售、旅游、电信和娱乐等多个行业开箱即用的可运行示例。 ### 致谢 作者：Matthew Koen 和 Ali Shazal。特别鸣谢 Michael Segner、Rodrigo Olivares、Amandeep Khurana、Aiza Usman、John Lopus 及其他同事的贡献。 See all posts Built by 宝玉. RSS . 本站原创内容，独家授权赛博禅心公众号发布。 Toggle theme