过去一年，Anthropic 和零售、电商、旅游等行业的不少企业合作， 用 Claude 搭建了落地企业真实场景的智能体。客户反馈效率更高，运营更省心了。
9月2日 Anthropic 将一线实战经验沉淀为智能体搭建手册，公开供大家学习参考。
https://claude.com/blog/the-anatomy-of-effective-commerce-agents
这套方法以 Claude 为主，但背后的组织逻辑同样适用于Codex、WorkBuddy等其他智能体平台。
本篇文章按落地方法论整理重排：核心结论是什么，背后的逻辑怎么成立，每个环节怎么落地，哪里容易踩坑。
PART 01
先定架构：别拆成多个子智能体
先说核心结论，别把智能体拆成多个子智能体，用一个主脑配一组技能就够了。
Anthropic 同时在 Github 开源了电商智能体框架。
分为两种形态，面向客户的智能体，负责搜商品、比价、推荐、组订单，用在购物车、旅游行程、换套餐、选座这些场景。面向员工的负责答销售问题、运营促销、管库存、调价格。
两种形态的底层架构一致：一个模型，围绕目标推理、调工具、学流程、看结果，直到干完。
为什么别拆成多个子智能体
商业对话是连贯的，客户会在同一段对话里先搜商品、再改购物车、再问退货，全程可以共享上下文。
很多团队的第一反应是按业务领域拆子智能体，用调度器分派，Anthropic 团队实践下来效果并不好。
每次交接都丢上下文，回复质量下降，还多烧几倍 token、多等几秒。领域之间也很难切干净，退货要订单、购物车、商品目录三份数据，拆了子智能体要么各处重复建数据，要么中途交接。
Anthropic 团队对比过多个企业部署，带技能的单智能体效果始终最好，单任务成本更低，延迟更短。
Skill体系才是正解
Skill 体系能实现和子智能体一样的分领域模块化，但没有交接成本。技能指令加载进主智能体，主智能体本来就握着完整对话历史。
子智能体只在两种情况下用：
1. 窄而自足的任务场景，比如深度研究。子智能体自己搜索、读文档、跑数据，只把精简结果交回来。
2. 该领域本身有成熟专用智能体，比如医药或金融。这时完整交接，让它直接对客户。
两条路的核心区别是对话归谁管。这条判断标准，值得每一个想要 AI 落地的人记住。
系统提示词和技能怎么选？
先说清这两者的区别。
系统提示词是你提前写好的固定指令，每次对话都会自动带上，给智能体定身份和规则。技能是遇到特定场景才按需调用的能力模块。
判断标准就一条：使用频率。
覆盖三分之一以上流量的内容需要放进系统提示词，其余放技能。原因很简单，加载技能要多花一轮模型调用，放进系统提示词里能省掉这轮。
关键指令永远放系统提示词，比如安全规则、法律约束、品牌要求、客户核心信息，这是智能体搭建的红线。
PART 02
工具的组织原则：接已有系统，别重造
这里要守住一个原则：智能体的工具优先调用公司已有的系统，别让团队重写。
公司早就有搜索排序、购物车、库存、促销这些系统。它们沉淀了多年业务逻辑，藏着模型学不到的业务信号。
工具的边界就是业务逻辑的终点、模型判断的起点。
举个例子，智能体调用搜索工具时，返回结果已经排好序。智能体只判断哪些匹配客户目标、展示几条、怎么呈现。
工具的返回结果，只给模型要用的字段，砍掉其余。最常见的浪费是每条结果都带图片 URL。
这条原则还有一个组织上的好处：工具的边界清楚了，负责系统的团队边界也就清楚了。后面讲跨团队协作时会用到。
补充一条商业场景下的常见做法：电商智能体的回复大多是 UI 组件，比如商品轮播、行程单、选座图、图表。
比较可靠的工程做法是把每个 UI 组件也做成一个工具，模型调用"展示商品""展示行程"这类工具，传结构化参数，服务端校验补全后下发客户端渲染。这样组件以原生格式存在消息里，重载历史不用重新解析。
PART 03
延迟和成本，是上线后的两道关口
商业场景对延迟极其敏感，尤其是面向客户的界面，延迟容忍度更低。
但这里有个反直觉的结论：真正驱动留存和互动的是答案质量，而非延迟。
所以优化要两手抓，一手降真实延迟，一手降感知延迟（客户会看着智能体干活，可以理解为进度）。
降真实延迟：抢先调度
降真实延迟的关键是让工具在模型还在输出参数时就启动执行。工具参数会像文字一样从模型流式输出，编排层可以在参数接收完整的那一刻就启动工具，而不必等整个工具调用块结束，这样能把数秒的等待压缩到几百毫秒。
降感知延迟：让用户先看到变化
感知延迟是用户感觉到屏幕有变化的时间，有两条做法：
1.组件成型即流式下发。一条回复通常 500 到 700 token，不流式就是 5 秒加载动画。
2.展示进度。收集上下文时渲染每一步，比如"正在找海边的酒店"。
下面这张图直观对比了两种方式的差别：同样的智能体、同样的工具、同样的系统提示词，总耗时相近，用户看到内容的时间却差异显著。
降成本的最管用的一招：提示词缓存
这是最该记住的一招，因为它是纯省钱。
缓存输入 token 的读取成本，只有新 token 的十分之一。同样的内容，已经算过一次的部分，下次再读只需花十分之一的钱，最优的商业部署能达到 90% 到 99% 命中率，几乎每次都命中缓存。
换句话说，上了缓存，模型调用成本能砍掉一大块，这是从一开始就该设计进去的目标。
选模型，靠实测不靠感觉
别拍脑袋选模型，按三步走：
- 定指标和底线。想清楚业务要什么：任务完成率还是答案相关性，再加上可接受的延迟和成本预算。有了底线，才知道哪个模型算及格。
- 全量测试。一个实用的方法是偏分析的商家智能体从高阶模型开始，偏延迟敏感的消费者智能体优先从更快的模型开始。有生产流量就按真实分布加权，让数据说话。
- 仔细解读。提示词是针对特定模型调的，用同一套提示词跑所有模型，会让其他模型表现偏低。在排除某个候选之前，针对它的失败案例迭代几轮，成本很低。
按完成任务的单位成本衡量，不按单次调用。更便宜的模型如果需要更多轮次、更高失败率，综合并不便宜。
PART 04
记忆：把客户信息当治理来做
智能体和客户的关系，比单次对话更重要。
记忆让它从上一次停下的地方继续，比如三月份有一个顾客提过对坚果过敏，那六月时也不要再重复询问。
要把记忆当成一个治理问题，而非单纯的存储问题。所谓治理，就是提前想清楚数据归谁管、谁能看、存多久、合不合规。
下面三个决策点或许可以帮到你。
1. 存哪里。存在你的业务系统里，别塞进模型，规模大了就用已有的数据库。商家智能体按人存，不按账号，共用账号时记得分权限。
2. 怎么存。异步写入，每轮结束由独立进程更新事实。实测事实召回率提升 13%，不增加对话延迟。
3. 合规底线。记忆承载个人数据，最值得记的信息往往监管最严。要给客户查看、更正、删除的途径，要设留存周期，要支持按部署开关。
PART 05
安全：规则写进代码，别只写进系统提示词
这是企业落地最不能省的一步，安全问题带来的财务损失往往不可逆。
一句系统提示词里的规则，可能被一次注入、一个坏样本绕过，所以每条规则都要在代码层强制。
四条铁律，必须严格遵守：
- 模型只提案，人或政策审批。任何动资金的调用，模型都不能直接执行。下单、支付、退款、调价、上线都需要系统层管控。
- 写入只认服务端签发的 ID。模型幻觉的、客户粘贴的、评论植入的 ID，到后端前就被拒。
- 限额对重复请求生效。智能体会用重试、改写、并行各种方式突破限额。限额要在最终写入时校验。
- 第三方内容必须净化。商品列表、评论、政策都是第三方写的，要防伪装成系统指令。
核心逻辑一句话：模型最危险的动作，也只是提出方案，审批走你业务里既有的流程。
PART 06
评估：上线前先考核
模型 API 是无状态的，输出只取决于提示词、工具、消息。所以评估用例就是：构造一个状态，追加一条客户消息，看结果。
评估要包含五个要点：
- 评估快照状态，不评估对话过程。多数情况别评估路径，太脆弱。
- 在严苛条件下评估。让一部分用例从冗长、混乱、矛盾的历史开始。
- 每写一个正向用例，配一个反向用例。每个"应当响应"配一个"应当拒绝"。
- 覆盖五类场景。核心请求、上下文依赖、安全合规、界面一致、跨能力复合。
- 和业务专家共写，用真实事故做素材。每个用户流程 50 到 100 个用例，是好的起点。
这一条的组织含义很重：评估不能只靠技术团队，要拉业务、法务、客服一起写。
PART 07
跨团队落地：靠分工，不靠拆解
这是大组织的核心挑战。
企业里，智能体往往由多个团队共建，搜索、结账、定价、营销、客服，各管一摊。
智能体要真正落地可用的难点就在于智能体没有严格的模块边界。定价团队的改动需要和结账逻辑共享上下文，但别因此拆成多个子智能体。
可以使用以下三条方法管理：
1. 所有权随系统走。每个技能和工具有唯一负责团队。定价团队拥有促销工具，客服团队拥有订单工具。系统提示词的公共部分由平台团队统一负责。
2. 变更随测试发布。每个团队贡献技能时，同时提供对应测试用例，包括负向用例和相邻技能的边界用例。合并请求跑精选集，不跑全量。
3. 智能体纳入统一发布日历。它是一个完整部署单元，一次故障影响所有用户。变更先小范围灰度，保留开关，高峰前冻结。
PART 08
最 后
这套架构大部分与模型无关。
模型会持续进步，当更好的模型出来时，只需换配置、重跑评估。其余一切照常。
所以你现在投入搭架构和组织流程，不亏。你搭的是能一路用下去的“数字员工”，而非绑死某个模型的应用。
商业的本质是让交易更顺畅，而智能体可以让这件事简单得多。
欢迎大家关注万象AI实验室，帮你把 AI 工具真正用起来。
