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 依然有价值。