摘要：Anthropic 基于零售、旅游、电信落地经验发布电商 Agent 构建指南，核心是用单个 Claude 在标准 Agent 循环里配技能与工具，而非按领域拆子智能体，并开源参考实现。
Anthropic 这次把"怎么在真实业务里搭一个电商 Agent"讲得很落地，而不是停在概念图。指南提炼的核心架构判断有点反直觉：与其按"售前、售中、售后"拆出一堆子智能体，不如用单个 Claude 跑在标准 Agent 循环里，给它配不同的"技能"（skill）和"工具"（tool），让它在同一个上下文里完成跨环节任务。理由是，拆太细反而会让上下文割裂、状态难同步，而真实电商任务本就是连续的——用户可能在问完尺寸之后顺手要下单、再问物流。一个保持全局记忆的 Agent，比三个各管一摊的子智能体更顺。
这套经验来自零售、旅游、电信等团队的实战。比如电信场景里，客户从"查套餐"到"办变更"到"投诉"往往是同一通对话里的事，单一 Agent 配技能切换，比把对话硬切成三段体验好得多。Anthropic 同步开源了 commerce-agents 参考实现，等于把"骨架"直接给你，企业可以照着改自己的业务逻辑。对中小团队来说，这点尤其关键：不用从零设计 Agent 架构，直接在一个经过实战检验的骨架上改，能把试错成本压到最低。开源本身也是一种信任信号——它敢于把"怎么搭"摊开给你看，说明这套方法他们自己跑通了，不怕别人照抄。
对想做行业 Agent 的团队，这篇最大的价值是"少走弯路"：别一上来就追求花哨的多智能体编排，先把"单个 Agent + 清晰技能/工具边界 + 可靠验证"跑通。多智能体不是不能用，而是要在单 Agent 确实不够时再上，否则复杂度会先反噬你自己。一个常见的翻车现场是：团队一上来就设计了五个子 Agent 互相传话，结果 80% 的 bug 出在"谁该在什么时候把什么状态传给谁"上，而用户感知到的体验，和一个设计良好的单 Agent 没有任何区别——纯粹是给自己加了管理负担。
落地时的另一个要点是"验证"要嵌进循环里，而不是事后审计。电商场景里一个错误的下单或退款动作，代价是实打实的钱，所以 Agent 在"要不要替用户点确认"这种节点上，最好有确定的校验和人工兜底。Anthropic 指南里反复出现的"让模型负责生成、让确定性逻辑负责把关"，和本期 #13 的 harness 工程是完全一致的思路。说到底，行业 Agent 能不能活过 POC 阶段，拼的不是模型多聪明，而是这套"生成与把关分离"的工程是否扎实。
要衡量一个电商 Agent 到底成不成功，别只看"对话顺不顺"，得回到业务指标：任务完成率（用户是不是真办成了事）、人工接管率（有多少次得人进来擦屁股）、单次服务成本（比人工客服便宜多少）、以及转化与复购的拉动。这些才是决定它能不能从 Demo 活到生产的硬指标。Anthropic 开源 commerce-agents 的意义也在这里——它把"怎么度量成功"的骨架一并交了出来，企业不必从零摸索 KPI。对那些还在犹豫要不要上 Agent 的零售、旅业团队，务实的切入点是先挑一个"高频、规则清晰、容错空间大"的场景（比如退换货咨询）跑通单 Agent，拿到可信的完成率和成本数据，再考虑往更复杂、容错更低的环节扩。一口吃不成胖子，Agent 落地尤其忌讳贪大。
