Anthropic“开源”电商Agent：不用多智能体，一个就够

AI应用风向标（公众号：ZhidxcomAI）编译｜毕伟豪编辑｜漠影

智东西9月3日消息，今天，Anthropic发布了一份电商Agent蓝图，并开源了代码库，其中包含完整可运行的购物、商家Agent参考实现，用户可自行部署并通过Claude Code进行自定义。

虽然说是开源，但Anthropic的“开源”有点不太正宗，就像有网友在评论区所说，开源内容是代码示例，必须使用Claude的付费API，严格来说并不能称为开源。

(资料图片仅供参考)

这个商业Agent蓝图所包含的架构和参考实现，都需要通过Claude Code或者Claude托管智能体平台实现，非Claude用户并不能“开箱即用”。虽然“开源”不太正宗，但Anthropic所发布的工程博客倒是有不少干货，他们系统梳理了商业场景中Agent的运行模式。

有趣的是，之前一直在推崇多Agent编排的Anthropic，这次却坦言最好只用一个Agent。

过去一段时间，Anthropic明显在强化多Agent协作，不论是随Claude Opus 4.6上线的实验性Agent Teams，还是和Claude Opus 4.8一起推出的动态工作流，本质上都是在强调一个方向：一个Agent干不完，就叫更多Agent来干。

但这次面对商业场景，Anthropic却换了个思路，在处理同样复杂的购物任务时，商业Agent没有继续增加搜索、推荐、客服等子Agent，而是让一个Agent负责完整的购物对话，Skills负责承载长尾能力，Tools直接连接企业已有的业务系统。

一、任务复杂，并不等于一定要多Agent

为什么不拆分为多个Agent？

对此，Anthropic给出的理由是，商业场景对应的是高度依赖连续上下文的任务，购物车、预算、用户偏好、已经选中的商品和订单状态都在同一条对话里。

如果拆成多个子Agent，就意味着状态需要不断交接，而交接本身会带来额外token、延迟和上下文损耗。

所以，Anthropic在自己的多Agent路线之外，做出了另一个架构判断：复杂，不等于一定要多Agent。

他们认为，在需要长期共享状态的任务里，一个Agent配上足够好的Skills，可能是更合理的解法。

为了佐证这套理论，Anthropic还拿实际客户数据来背书：采用其购物Agent的零售商，购物车规模最高增长35%，消费者完成购买的概率提升60%。

官方博客还进一步拆解了这套单Agent架构：Skills如何划分，哪些能力常驻Prompt、哪些按需加载，模型的决策边界如何划定，以及Harness和后端代码如何把它真正带进生产环境。

在配套的工程博客里，Anthropic把这套架构讲得非常清楚：前面没有意图路由器，后面也没有一排按领域划分的子Agent。整个商业Agent就是一个模型跑在标准Agent循环里，需要什么能力，再去调用对应的Skills和工具。

Anthropic给出的理由，首先和购物流程本身有关。

比如用户说：“周末带两个孩子去露营，需要帐篷、睡袋和炉子。”看起来只是一个购物需求，真正执行起来，却要连续处理商品搜索、多商品搭配等多个环节。

这些动作很难真正切开，如果把这些事情分别交给搜索Agent、推荐Agent、购物车Agent和客服Agent，就得再找一个编排器站在中间。

它要保存购物车、预算、已经选中的商品和对话历史，再把这些信息不断交给下一个Agent。

这也是Anthropic认为子Agent在商业场景里容易吃亏的地方：每次交接都要重新传递上下文，会增加Token消耗和延迟，也可能丢掉一部分前面的状态。

像退货这种同时涉及订单历史、当前购物车和商品目录的流程，拆开之后反而容易出现重复调用和来回交接。

Anthropic对比不同方案后认为，在Commerce场景里，单Agent加Skills的方案，效果稳定优于把所有能力都塞进一个Prompt，也优于子Agent方案，而且通常更快、更便宜。

不过，Anthropic也没有把子Agent一棒子打死。

如果一个任务足够窄、足够独立，比如深度调研，就可以把整段任务交给子Agent，让它在自己的上下文里完成，最后只返回精简结果。

另一种情况是，某个领域已经有一个拥有独立权限和合规边界的专用Agent，比如药房、金融服务，同样适合直接做整段交接。

所以这里真正被否定的，是为了拆而拆的行为。如果一段任务从头到尾都需要共享购物车、用户偏好和历史对话，把它硬切给多个Agent，可能只是把原本一个Agent要解决的问题，变成了编排器要解决的问题。

二、一个Agent怎么装下这么多能力？

如果保持一个Agent不拆分，系统提示词的累计长度是个很大的问题。

Anthropic的做法是把一部分能力放进Skills里。官方给出的标准是，和三分之一以上流量相关的内容留在系统提示词，其余按需加载；安全规则、品牌约束、过敏史等高优先级信息则始终保留在系统提示词中。

在参考实现里，购物Agent的系统提示词只保留数据锚定、购物车与结算、展示规则、商品搜索等高频内容，商品发现、购买调研、购物规划、客服和用户记忆等长尾能力，则分别放进Skills。

商家Agent也是同样的思路，把销售分析、目录、库存、定价促销和营销活动拆开。

不过，Skills也不是随便加载的，如果Harness能根据页面来源等已有信号提前判断用户需要什么，就可以在第一次模型调用前直接注入，少走一轮。

Skills解决的是能力怎么装进去，工具解决的则是这些能力怎么接上真实业务。

Anthropic建议直接调用企业已经在用的搜索、购物车、库存、促销等系统，不要让Agent重新实现一遍。工具返回的数据也尽量只保留模型真正需要的字段，避免把图片URL等无关信息全部塞进上下文。

错误处理同样如此，与其只返回一个笼统的403，不如直接告诉模型缺少商品ID，让它知道下一步该怎么修改。

这样，Agent本身不用记住一整套业务系统，只需要在需要时加载对应能力，再通过工具调用现有系统即可。

三、Agent能提案，但不能直接改业务

商业Agent面对的很多任务，在执行中都有真实业务风险。比如改价格、调库存、改促销预算，Anthropic把最终执行权放在了Harness和后端，而不是Prompt里。

以商家Agent改价为例，Agent会先生成一个由服务端签发ID的暂存改动，只有经过真实界面或CLI审批后才能执行。

真正落地时，系统还会重新检查权限和限额，避免审批通过后规则发生变化。

商品ID、购物车限额等也由后端控制。购物车只接受当前会话里服务端返回过的商品ID，模型自己生成的ID、用户或评论里夹带的ID都会被拦截；

限额则看最终状态，重试、改写请求甚至并行调用都不能绕过。

第三方内容清洗方面，诸如商品描述、评论、卖家消息、政策和用户记忆等在进入模型前，都要经过清洗，避免其中夹带伪装成指令或工具调用的内容。

四、真正跑起来，还得解决速度和评测

商业Agent进入生产后，Anthropic重点处理的是UI、延迟、缓存、记忆和评测这些工程问题。

UI不再依赖模型输出自定义标记，而是直接做成工具。速度方面主要靠流式输出、工具提前调用和Prompt缓存。

官方数据显示，一条购物回复通常有500—700个输出Token，如果等全部生成完再展示，等待时间可能超过5秒。

因此，组件和进度信息会边生成边展示，工具参数一旦完整，也可以提前执行。Prompt缓存则把稳定的系统提示词、工具定义放在前面，把易变的内容放到后面，在这种结构下，部分电商部署的缓存命中率能达到90%—99%。

记忆则于异步流程里处理，不让每次对话额外承担存储决策。官方内部评测显示，加入这套记忆机制后，事实召回提升了13%，用户也可以查看、修改和删除记忆。

最后是评测，Anthropic通过直接构造不同业务状态做快照测试。每条用户流程准备正反两类用例，通常从50—100个案例起步，再由产品、法务和业务团队共同维护，并接入CI和夜间全量评测。

结语：电商场景虽然复杂，但并不一定需要多Agent

回到商业场景，Anthropic这次给出的答案其实是在给多Agent对应的场景划线，像电商中购物、客服、订单这些环环相扣的任务，更适合让一个Agent持续接住上下文，再用Skills扩展能力、Tools连接业务系统，最后由Harness和后端把执行权限管住。

这并不意味着多Agent没用了，企业需要判断的，是任务能不能被独立切开。如果各个环节彼此高度依赖状态，频繁交接反而可能增加成本和复杂度。

同时，如果任务本身足够独立，或者涉及完全不同的权限和合规边界，拆成子Agent依然有价值。

标签： 调用 电商 上下文 智能体 网络环境 agent