2026-11-03 · 28 min read

高效电商AI 智能体解剖指南

电商智能体的竞争力不来自"更聪明的模型编排"，而来自一次性的简单架构决策 + 延迟/成本的工程抠法 + 生产环境里的记忆、安全与评估纪律。

电商架构设计AI 智能体

原文：Anthropic Claude 博客，作者 Matthew Koen、Ali Shazal；

Anthropic 过去一年与零售商、电商平台、旅游/娱乐/电信服务商合作，把 Claude 做成的电商智能体推到了真实生产线上。可观测收益是消费者侧购物车客单价上升、卖家侧运营效率显著提升。而跑通的系统共享一个相当朴素的架构：单个模型跑标准智能体循环（agent loop），靠技能（Skills）覆盖长尾，靠工具接回既有业务系统，再配一套评估套件（eval suite）。

文章分三部分：架构（一次定调的决策）、延迟与成本优化、生产落地（记忆/安全/评估/跨团队发布）。目标读者是工程与技术的负责人。

第 1 部分：架构设计

一个模型、一个智能体循环、技能兜长尾、工具接存量系统。这套基础只需决定一次。

什么是电商 AI 智能体

定义为"能把整条在线商品目录上的买卖过程简化下来"的智能体。两类形态：

消费者侧：搜商品、比价、找替代品，最后收敛成一单——零售购物车、行程单、套餐变更、演出座位都算。
商家侧：回答销售数据问题、执行促销与营销活动、管库存与定价。

核心循环是：围绕目标推理 → 探索上下文 → 工具行动 → 技能加载流程知识 → 必要时反问澄清 → 观察结果，循环到目标完成。值得注意的是这套架构里"没有什么"：前端没有意图路由器（intent router）把对话切碎，后端也没有一堆垂直子智能体。

上下文工程

优先用技能，而不是子智能体

跨品类、跨意图的能力覆盖，很容易诱导团队"一个垂直领域配一个子智能体"。实践中这通常不是最优：

电商对话是连贯的，跨意图跨轮次，共享上下文极重。子智能体架构下，主协调器保管购物车、暂存变更、用户偏好、历史记录，每次交接都是一次 state-lossy 操作——回复质量下降，整体表现被拖累，而且每轮交接多耗数倍 token、多出数秒延迟。
业务边界切不干净。退货同时要看订单历史、当前购物车、商品目录；"一域一智能体"就意味着把权限复制给每个智能体，或者在执行中途反复交接。
模型能力上限一直在抬。更长上下文、更多技能与工具，正在逐代解除过去那些"必须拆分"的老约束。

技能的价值在于：模块化与上下文控制的效果类似按域划分，但没有交接成本——技能指令直接装进已经握有完整历史的主智能体。Anthropic 在多个企业级部署上的对比结论是，单智能体 + 技能在质量上稳定优于"全部塞进一个提示词"，也优于子智能体设计，且通常更便宜、更快。

子智能体仍有两个合理位置：

主协调器把它当工具调用，处理高度垂直、自包含、需要独立上下文窗口的重活。生产里的典型是"深度研究"子智能体：大量检索阅读、写跑代码、遍历数据模型、走不通时自己找岔路，只把压缩后的结论回传主协调器。
该领域已有独立演进的成熟智能体（如药房、金融各有合规要求的专属智能体），此时应做彻底交接，让专业智能体接管用户对话直到完成。

区分点是"对话所有权"：交接（hand-off）= 领域智能体成为面向用户的一方；委派（delegation）= 主协调器保留全局，只在单轮里把领域智能体拉进来又踢出去，信息在往返中持续衰减。

系统提示词还是技能：按使用频率切

判断依据是这组指令被用到的频率——加载技能要消耗一轮对话。规则：

经验阈值：与三分之一及以上流量相关的指令（无论发布前预判还是生产观测到的）进系统提示词，剩下的长尾做成技能。
可预判的技能注入：若有页面来源这类信号，在首次模型调用前由 Harness 直接注入，省掉加载技能那一轮开销。
必须常驻系统提示词的内容：安全与法律底线、品牌调性约束、用户关键信息（如过敏史）。

对电商智能体来说，"商品搜索"几乎每次会话都要用，属于提示词层；技能承接零碎长尾。

参考实现（anthropics/commerce-agents）的切法：

层	内容
购物智能体提示词	背景设定、购物车与结账规则、呈现规则、商品搜索
购物技能（长尾）	搜索发现、购买研究、目标规划、客户关怀、记忆与个性化
商家技能（一个操作域一项）	业绩洞察、目录列表、库存操作、定价促销、营销活动

工具的工程化设计

通用原则见 Writing tools for agents；电商场景有两条特别关键。

1）工具建在既有核心系统与业务逻辑之上。 电商公司普遍已经沉淀了搜索与排序、购物车、偏好与档案、库存、促销引擎、销售分析等系统，里面是多年打磨的逻辑和模型看不提到底层信号。工具应该调用它们，而不是用大模型重实现一遍。"工具边界"的定义就是：你的业务逻辑到此为止，模型的判断力从这里接手。例如 search_products 返回的应当是已排序结果，模型只负责判断哪些符合用户目标、展示多少、怎么呈现。

2）工具的返回就是上下文。 只给模型推理需要的字段，其余丢弃——最常见的违规是每条搜索结果都挂一长串图片 URL。可以在工具内重塑原始数据：下一步动作不够显眼时，直接在结果里补一句指引。错误场景尤其有效，模型偏好明确指令而非裸错误码——比起通用 403，更好的表述是"查询库存请务必携带商品 ID"。

把 UI 组件也做成工具

电商回复的主体通常不是长段散文，而是商品轮播、行程单、座位图、图表这类组件，也就是模型要输出符合 schema 的结构化数据。

起步团队常靠提示词让模型输出自定义标签、客户端解析，规模化后必然失效：

模型对你自造标签的熟悉度远不如其专门训练过的工具调用，嵌套组件一多，可靠性急剧下降；单靠提示词无法保证格式永远不出错。
标签定义堆在系统提示词里，每加一个组件上下文更臃肿，且改动容易引发其他部分倒退。
历史对话被存成只有你的解析器能读懂的格式，重放时要么客户端重新解析原始消息，要么在原生 API 格式之外多维护一份私有副本。

跑得久的做法是每个 UI 组件对应一个工具：模型带类型化参数调用 present_products / present_itinerary / present_plan_comparison，服务端校验并丰富，再发事件，客户端渲染。组件本身即以原生 tool_use 存在于消息数组里，重载旧对话无需二次解析。

代价在流式粒度：工具调用的顶层参数先在服务端缓冲校验，即使开启流式，呈现类工具的子组件仍会整块跳出，影响感知延迟。想要 token 级流式，就在工具定义上设 eager_input_streaming: true，跳过缓冲但放弃服务端格式强保证。Anthropic 的评估中，Sonnet 级别及以上模型格式违规极罕见，仍建议外面包一层重试兜底。

这类呈现工具还顺带给了模型一份"屏幕上现在有什么"的账本：用户说"第一个酒店""左边第三个"时，布局信息就在最后一次呈现调用的参数里，已在消息数组中，立刻可解。前提是参数结构真实映射渲染布局——按界面结构（有序行、轮播）组织数据，别丢一个扁平列表让客户端自己排。

第 2 部分：既快又省钱

同时攻端到端绝对延迟和用户感知延迟，用缓存压成本，且不以牺牲模型"智商"为代价。

延迟在电商是硬约束，消费者界面容忍度极低。但 Anthropic 在智能体场景反复观察到：真正撬动留存、参与度和购物车规模的变量是最终结果质量——答案是否相关、任务是否完成，比挤出来的那一点延迟重要得多。所以兵分两路：工程手段压绝对延迟，同时降低感知延迟（让用户看见智能体在推进，等待就顯得有意义）。每个用户心里都有"延迟预算"，目标是预算内完成任务。

缩短任务完成延迟

任务完成延迟 ≈ 模型思考轮次数 ×（首字时间 + 工具执行时间）。三个杠杆：减少轮次、加快工具、加快 token 生成。三者会互相拉扯，优化目标是总和而不是单项。

减轮次：预加载上下文、提升模型智商、并行调用无依赖工具。
快工具：优化工具自身后端；参数一生成完就急切分发。
快 token：用评估套件扫表选出模型与参数配置。

减少轮次的关键心得

预加载大概率要用的上下文。用户在商品详情页唤醒助手、商家在活动仪表盘打开它，就把该页数据直接塞进会话——后续对话大概率相关，且从已有上下文作答不额外耗轮次。
提升模型智商。更聪明的模型规划与工具下达更高效，总轮次更少，这份节省常常足以抵消它出字更慢。若用户问题普遍复杂，或生产数据显示单任务常超过五个轮次，那么"最快的模型往往是最聪明的模型"；具体选型取决于真实流量，需按后文扫表测试决定。
并行调用无依赖工具。电商常见同时搜多商品、查多份退换货政策、从多个数据源拉记录。用提示词引导模型在同一轮发起多个调用，结果作为一个 tool_result 数组在一次 user message 里返回（见并行工具调用）。

让工具更快

修工具自己的后端。有时一个工具确实需要扇出（"今日快照"要分别读销售额、库存、活动状态），这没问题。问题常见于工具边界成了"缺后端逻辑"的垃圾桶：一个查库存的工具先去目录查 SKU，再去门店库存服务逐店查，再去履约服务查截单时间，最后在工具代码里手写替代规则与自提条件。这个工具承载了过载的领域知识，规则一变就难以保持准确，它其实在替上游系统干活。正解是在后端建一个能直接回答该问题的端点，让智能体工具去调它。
急切分发（eager dispatch）。工具参数和其他文本一样是流式产出的，Harness 可以在某个工具的参数流完时立即发起调用，与其他并行输出重叠。Anthropic 说这一招把数秒级的等待间隙压到几百毫秒内，Claude Agent SDK 默认如此。也可以用提示词引导模型把最慢的调用最先输出。

优化感知延迟

感知延迟是"用户主观等到屏幕动起来"的时间，在消费者场景尤其致命——交易链路上任何摩擦都直接压低结账率与营收。两条不动模型的技巧：

边生成边渲染。一条渲染后的电商回复通常 500–700 输出 token；不流式的话用户要对着 loading 动画等五秒以上。应把呈现类工具各参数在流出的同时下发客户端、逐步渲染。
展示思考过程。智能体密集收集上下文时，用简短自然语言为每步渲染一行进度提示（"正在找海边的酒店…"）。信息可以直接从现有工具参数（如搜索 query）提取，或给工具加一个 user_facing_message 参数让模型自己写。

（原文此处配有三段对照 demo 截图：同一智能体、同一工具与提示词，仅 Harness 不同；总运行时长相近，但用户"感觉到系统开始反应"的时间差别很大。）

提示词缓存

成本削减的最大杠杆，且电商流量形状天然适配。缓存读取的输入 token 成本约为全新读取的十分之一；写入约 1.25 倍溢价，但只要前缀被第二次命中就已回本。高流量消费者应用可以只用最便宜的默认 5 分钟过期时间拿到极高命中率。Anthropic 见过的最佳电商部署命中率为 90–99%，应项目初期就朝这个目标设计。约 10 万 token 规模上，缓存读取速度大约快 1.5–2 倍，且 token 越多收益近似线性放大。

缓存按前缀匹配：请求到来时一路命中，直到与上次不同的第一个字节。所以关键不只是放了什么，而是摆放顺序。把请求想成按变化频率排序的三个区块：

全局区块：绝大部分系统提示词与工具定义，每次会话完全一致。大并发下它几乎不会过期——务必保证跨轮次跨会话字节级不变，并在其尾部放一个 cache breakpoint。
会话区块：用户专属上下文与历史对话。跨用户不同，单用户会话内稳定，紧跟全局区块之后。
易变区块：会话内高频变动项（当前时间、正在浏览的页面）。放在整个请求最末尾，作为最新 user turn 里的带标签文本块，或对支持会话中系统消息的模型，作为追加在消息数组末尾的 system-role 消息。最常见的自毁操作是把时间戳或当前页面链接挂在系统提示词开头，导致缓存每次请求被静默击穿。

两个实现细节：

技能应作为 tool result 加载，而不是硬拼进系统提示词——技能正文因此落进对话前缀，跟着一起被缓存。
每轮把断点向前滚动：单次请求允许的断点数量有限，把最新断点移到每次 user turn 末尾，这样每轮都能从缓存读到累积历史，包括冗长的工具返回（如大段搜索结果）。

选模型与配置

模型档位与 effort 设置是同一道权衡题：智商 vs 延迟与成本，用数据决定。

先定北极星与底线：选出业务赖以生存的质量指标（任务完成率、相关性、事实准确度），定不可妥协的评估分下限，并圈定 p50/p99 的延迟与成本预算。
全面扫表（sweep）：让整套评估在每一个候选模型 × effort 组合上跑。建议商家智能体（分析密集）从 Opus 起测，消费者智能体（延迟敏感）从 Sonnet 起测。有生产真实流量就按真实 query 比例加权，然后让数字说话——有时 Opus 5 在购物车转化上的增益完全值回它比 Sonnet 贵的差价，有时不值。
谨慎解读，两个常见坑：其一，提示词通常针对特定模型调优，用模型 A 的提示词测模型 B 结果会偏难看；小模型常需要"手把手"指令，大模型可能自己悟出来，反过来大模型会死板遵从被小模型无视的指令。淘汰任何候选前，针对它的失败用例做几轮微调，成本极低但关键。其二，更聪明的配置虽然出字更慢，最终延迟（尤其 p90/p99）有时反而更好，因为它规划工具调用更强，最复杂的请求用更少轮次收尾。

成本口径必须是"完成单次任务的成本"，而不是"单次模型调用的成本"：便宜模型轮次更多或频繁翻车，就不便宜。结果相近、成本与延迟仍在单任务经济模型内时，选高智商——驱动采用与留存的是质量，而且这为未来六个月（模型更强时）构建更复杂特性留了余量。

第 3 部分：在生产环境中运行

记忆、安全、评估、跨团队协作发布——这些决定智能体能否跨过生产门槛并长期活着。

跨会话持久化记忆

记忆让智能体"接着上次聊"而不是"假装初见"：三月说过坚果过敏的购物者，六月不该被迫重讲；每周一查看同样三个营销活动的商家，不该每次重报名字。长期记忆（应跨会话留存的事实）是需要自己搭的系统，三段构成：如何存储、如何写入、如何读取。

存储

事实存在你自己的系统里，不是模型里。档案很少且只有智能体自己读时，一个扁平 Markdown 文件勉强够用；生产电商智能体很快撑爆它，最实际的方案是你已在维护的数据库。一条记忆 = 一条结构化小记录：键（shoe_size、default_store、preferred_report_cadence）、简短值、分类标签、来源会话。部分键预先定义且人人都有，其余由提取器自动发现。数据量增长后数据库仍高效可查，可基于特定属性做确定性行为，也容易与现有用户数据关联。

商家侧记忆按"人"建，不按"账号"建——商家登录账号常被多名运营共享，每人需要自己的档案库，读取还必须尊重权限：门店经理的智能体不能调用区域经理陈述的机密事实。

电商记忆必然含个人数据，而最值得记的事实往往也是监管最严的，各地法规差异大。把记忆当作"数据处理与合规"的设计题而非存储题，实践中四件事：

明确界定愿意保留的记忆类型，并在写入环节把关——用校验器硬性拦下不合规的存储请求，而不是只在提示词里写一句。
用户可查看、修改、删除其被保存的信息；删除能力接入现有注销与数据请求流程。
设留存期限。几年前的喜好早已过时，过期机制有助于保持新鲜。
记忆必须是每个部署区域独立可控的开关，承担不了合规义务的区域可以直接关掉。

写入

异步写入。每轮结束时或长会话中每隔几轮，一个独立线程/进程里的另一个智能体读取对话记录，在存储库中创建、更新或删除事实，同时维护自己的工作上下文。对主对话零延迟影响；Anthropic 内部电商记忆评估套件里，这带来 13% 的事实召回率提升。

看起来更简单的替代方案——给主智能体一个"保存事实"工具让它自己调——对延迟敏感的电商智能体很糟：每次保存消耗一个面向用户的轮次；而且除非整个记忆库都在上下文里，保存前还得先读一遍做更新与去重，又是一轮。更麻烦的是它给每一轮都加了一个决策负担，评估中这份对注意力的争夺直接体现为"该记的没记住"。

拆出提取器还让你能给它更精准的提示词：只读用户与助手的纯文本，绝不碰工具结果，避免商品描述或他人评论被误当成关于用户本人的事实。用提示词讲清什么算事实（明确表达的尺码、饮食禁忌、配送偏好、商家常用的自定义报表视图）、什么不算（商品列表内容、一次性琐节）。

读取

三层：

常驻上下文：少量核心事实每轮都挂载——几乎每次请求都要用的，如购物者的默认门店与配送偏好、运营所在门店与职务。
每轮按需预取：与当前请求强相关的事实提前拉取，触发逻辑类似技能预加载——搜鞋自动带出尺码与偏好品牌，关于活动的提问自动带出该运营常看指标。
收进查询工具背后：其余不常用的记忆全部交给一个查询工具按需获取。

记忆属于用户维度上下文，因此都放进"会话区块"、位于全局缓存断点之下。

安全：由 Harness 强制执行

提示词只是引导安全行为的第一道，不是最后一道。在直接涉及金钱且常常不可逆的电商场景，一次提示词注入或一次模型失误就能让提示词里的规矩形同虚设。以下规则必须在消费者端与商家端都在代码层强制，且只需定义一次即可被所有运行环境共享。

模型只打草稿，真人或既有策略拍板

没有任何模型发起的工具调用能直接移钱或改业务。下单付款、退款、改价、上线活动，最终动作全部由 Harness 掌握，模型无从触碰。

消费者端是结构性封死：结账工具只渲染出带"确认下单"按钮的购物车页，智能体可调用的后端接口里根本没有扣款方法。
商家端的写工具只能生成带服务端分配 ID 的"暂存变更"。只有通过真实通道批准过的 ID（运营后台按钮、命令行确认，或运行在 Managed Agents 上时的平台工具审批弹窗）才能调 apply_change 生效。
护栏在"应用变更"的最后一刻按当前约束重新校验，而不是拿暂存时的旧约束放行。无论前端长什么样，逻辑一致：模型能做的最危险动作也只是"提个建议"，审批走业务系统里既有的制单-复核（maker-checker）流程。

写入与渲染只认服务端下发的 ID

Harness 在每会话记录服务端交给模型的每个 ID，这本账是所有写入与界面渲染的唯一通行证。购物车只能加本会话真正返回过的商品 ID；商家工具只接受智能体真正读取过的列表 ID 与活动 ID。ID 从别处来（模型幻觉、用户粘贴、夹在评论里）就在抵达后端前被拒。

UI 同理：呈现类工具只接 ID 参数，服务端亲自补全对应商品/订单/变更记录的详情，因此卡片上渲染的永远是服务端自己取回的真实数据。子智能体同样受管：商家分析子智能体可以任意查数据，但不得往主智能体有权写入的 ID 库里塞新 ID。

费用明细、免责声明这类强监管内容，模型只负责"选哪个产品的条款来展示"，服务端一字不差地提供审核通过的标准话术；商家端受保护字段列表也锁死这些费用字段，两侧都无法篡改或自行改写解释。评估还会对渲染字符串做字节级核对。

设上限的交易必须扛得住高频重复请求

电商普遍限制单用户购买数量（抢票、促销价、防薅羊毛），而智能体重试点、换花样、并发冲刺的速度远超人类点击。因此上限校验焊死在"写入完成后的终态"上：第二句"再加两件"无法叠加突破上限；单会话购物车写入串行排队，即使模型在一轮里并发多个调用也合不出空子。商家侧修改（调价幅度、折扣力度、补货量、活动预算）同样逻辑，外加一份"任何修改都碰不得"的受保护字段黑名单。可泛化的规则：所有约束红线画在最终状态，不画在请求过程中，并且单会话内写入一律排队。

第三方内容必须消毒

电商上下文大多不是你自己写的——第三方卖家、买家评论、竞争对手。每次后端读取都要视为不可信输入并过净化器。任何第三方撰写的工具返回（商品详情、评论、政策、卖家留言、已存储的记忆）在进模型前都要彻底净化，并用固定标签的围栏圈起来。

净化器剥离控制字符与双向文本控制符、删除伪造围栏标记的尝试、拆掉模仿人类对话轮次或工具调用的文本炸弹、限制整体长度，防止恶意上架商品伪装成系统指令或撑爆上下文。提示词负责契约另一半：围栏内内容只能作为待报告的素材，不能作为要执行的指令。

评估：给非确定性系统发版

改几个字的提示词或加一个工具，都可能让行为剧烈变化，而且新功能没事、老功能退化是常态。评估就是在上生产之前把这些揪出来的探测器（通用实践见 Demystifying evals for AI agents）。

评"快照"而不是完整对话

模型 API 本质无状态：输出完全由系统提示词、工具列表和当前消息数组决定。因此电商对话可达的任意状态都能人工构造——写用例就是拼出待测状态、在末尾追加一条测试用 user message、让智能体从这一点跑下去。然后对结果打分：最终状态与渲染出的回复（含最后一次写入操作携带的参数）。绝大多数情况下不建议给"到达结果的路径"打分，那类用例极其脆弱且自我设限。

"模拟用户 + 裁判模型给整段对话打分"不是精确测量的好工具：两个非确定性系统闲聊，需要庞大样本量才有意义，单次成本高、标准难统一、出问题也定位不到哪一步。它的价值在扫盲（发现未覆盖角落）与整体氛围摸底。用它发掘边缘用例，但落地成代码时每个都写成静态快照。

在恶劣条件下测试

多数团队的注入状态测试不到位。好用例要模拟导致崩溃的恶劣前置条件，而不是只抛一个任务。若某个行为只有在首轮经历十几个杂乱工具调用、或对话初期就出现自相矛盾条件后才会暴露，那么永远从干净初始状态启动的用例会在任何配置下都绿灯，提供不了价值。评估套件里普遍塞满这类"过于干净"的用例——务必保证一定比例的用例从冗长、混乱、相互矛盾的历史对话中启动。

有效评估既测"该做什么"也测"不该做什么"。每个正向用例都补一个反向雷区用例：测了"应提供服务"，就测"遇到敏感诉求应果断拒绝"；测了"应直接执行"，就测"条件不足时应主动追问"。缺少反向雷区是见过的测试套件中最普遍的漏洞。

核心评估维度：

高频核心请求：构成绝大部分流量，翻车影响几乎所有会话。含简单信息查询、多重约束搜索、商品与套餐咨询、一句话多意图的复杂消息。查询类任务要检查每处报价、库存与属性说明能否追溯到真实返回的数据源；数据缺失时必须承认，不许编。
依赖上下文的请求：用户指着屏幕上的东西下指令、沿用前几轮的约束、修改现有购物车。记忆评估归这类——检查是否抽取并检索到记忆，且这条记忆是否真的改变了回答。
安全与品牌底线：这类翻车丢的是钱或信任。含提示词注入、越权窥探他人数据、强监管法律话术（字节级核对）。注入要拆两类重点测：用户直接写在对话框里的注入，以及藏在商品名称/评论/网页片段里、随工具结果被带进来的数据层注入。
界面评估：渲染了正确组件、数量上限被严格遵守、面向用户的文本里不出现内部 ID 乱码；同时测超时与空结果。
跨能力域的交叉请求：例如运营问"这个商品降价 15%，现有库存扛得住随之暴增的需求吗"，同时涉及定价与库存。好回答是打好降价草稿并附上库存消耗预测；差的只做一半。按单能力模块写评估抓不到这类错（每个模块只给自己那一亩三分地打分），必须为需要两个相邻能力合体的请求写联合用例，并对两半完成度综合打分。

与一线领域专家（产品、法务、商家运营、客服、类目管理）紧密协作，把真实线上事故改编成用例。每条核心用户链路起步 50–100 个用例是较靠谱的基准线。保证用例多样性（如上），生产真实聊天记录是挖用例的富矿，尤其那些诡异刁钻的对话；擅长写代码的智能体很会扩充用例与生成对抗变体。参考代码库里含一个基于 Claude Code 插件构建的"自动编写评估用例"技能，用的正是这套方法论。

大组织里的协同发布

大型电商企业里这个"超级智能体"由多个独立工程团队拼成：搜索、结账、定价、营销技术、客服、商品目录中台各握有智能体依赖的底层系统，各有发布节奏，都想塞新工具、改技能、往提示词里加规则。由于它不是靠 API 隔离的微服务，内部没有能把大家隔开的硬边界：定价团队写进上下文的一条新规则和结账团队共享同一个上下文窗口。

很诱人的偷懒解法是拆成一堆子智能体、每个部门领一个——第 1 部分已为质量理由明确不推荐。降风险的流程是三条：

谁的系统谁负责：每项技能、每个工具都必须有且仅有一个 owner。定价团队拥有所有促销与定价技能，客服团队包揽订单、退换货工具与客户关怀技能。所有人共用的提示词需要一名平台级"大总管"拍板通用部分，各领域段落由该领域负责人把关。
新代码必须带自己的用例发版，CI 只跑精选集。贡献技能就要连带提交配套用例（含雷区用例、与相邻技能打架的边界用例）。每次 PR 跑成百上千个用例既慢又贵，因此从大库中挑一个 CI 精选集：最高频流量冲击的核心用例 + 每一条安全底线用例，再加上本次改动触碰到的用例。改技能就跑它的用例与邻居的边界用例；改工具就把所有调用它的用例跑一遍；改共享提示词则整个套件全跑（系统提示词影响一切）。除了通过率，还要盯"缓存命中率"与"单轮对话成本"。每晚与每次大版本发布前完整跑一遍全套是极佳实践——跨团队改动的隐性连带破坏通常在这一步被逮住。
智能体发版节奏与大盘对齐：它是牵一发动全身的部署单元，一个带毒改动会立刻影响所有用户。提示词与技能的任何修改先给一小撮灰度用户（金丝雀）；要有后台一键关掉某项技能的开关，而不必重走发版；双十一等流量洪峰前，像封板核心交易系统一样冻结智能体发版。

关于这套机制"人"的一面，见 Building effective human-agent teams。

展望未来

文中绝大多数内容其实与"哪个模型"无关：工具只是调用你早已跑通的系统，技能只是把既有工作流写成代码，评估套件只是用测试用例格式写出的产品需求文档，Harness 执行的是你对任何客户端本就要强制执行的规定。模型会持续变强——新模型上线时，这套架构只需改一行配置、再跑一遍评估即可接管，其余一切照常运转。

同样重要的是想清楚产品界面往哪走。底层架构的寿命会比"聊天面板"这个狭窄形态长得多。同一个智能体可以换成语音交互，也可以在用户开口前主动捕捉票价暴跌并替他锁定；对已经把评估与工具打磨到位的团队，这些都只是前端展现层的小项目。再往后，访问你店铺的流量里有相当一部分可能不是人，而是代表人类来扫货的其他 AI 智能体——而那些让你自家智能体守规矩的溯源、暂存校验与审批规则，正是你敢把 API 工具安全开放给外来智能体的底气。

电商的铁律是扫平用户买单路上的一切障碍，智能体让这件事前所未有地简单。完整参考实现（消费者端 + 商家端，含零售、旅游、电信、娱乐的可运行示例）：https://github.com/anthropics/commerce-agents