摘要：Anthropic 开源 Claude Commerce Agents Blueprint，提供 Shopping Agent、Merchant Agent、四套行业 Demo 和三条运行路径。本文用较短篇幅拆解 Single Agent + Skills、Prompt/Skill/Tool/Harness 分层、UI-as-Tool、Provenance 与 Staged Write，并说明这套参考实现的生产边界。

关键词：Claude Commerce Agents，AI Agent 架构，Single Agent，Skills，Tools，Safety Harness，Anthropic

1. Anthropic 开源了什么？

ClaudeDevs 官方 X 账号用一句很直接的话宣布：We're open-sourcing Claude Commerce Agents.

如果只把它理解成一个购物助手 Demo，会错过这次开源的重点。开源的不是 Claude 模型，也不是 Claude Code，而是 Commerce Agents Blueprint 与参考实现，主要包含：

内容	数量 / 范围
Agent	Shopping Agent、Merchant Agent
行业 Demo	零售、旅行、电信、娱乐票务
Runtime	Messages API、Claude Agent SDK、Managed Agents
关键能力	Skills、Tools、Memory、Safety Gates、Evals

Marketplace 没有独立第五套 Demo，仓库只在后端指南中给出多租户和卖家来源的映射方式。

2. 总体架构：模型是行动层，不是事实数据库

企业已经拥有搜索、目录、价格、库存、订单和营销系统。Claude 的作用，是把用户目标翻译成一串受控调用：

用户目标
  ↓
Main Agent：理解、规划、选择能力
  ↓
Skills：按需加载业务 SOP
  ↓
Tools：搜索、库存、价格、订单、UI
  ↓
Harness / Backend：身份、规则、审批、审计
  ↓
企业真实系统

核心原则是：模型负责判断与编排，后端负责事实与裁决。

库存不能由模型估算，资格不能由模型猜测，支付也不能因为模型返回 approved=true 就自动发生。

3. 为什么采用 Single Agent + Skills？

按业务域拆成 Search Agent、Recommendation Agent、Cart Agent 和 Support Agent，看起来职责清楚，却会让一次连续购物任务频繁交接上下文。

用户可能先给预算，比较时补充品牌偏好，加购后询问退换货，最后又因到货时间替换商品。每次切换 Agent 都可能增加：

• 上下文重复传输；
• Token 与延迟；
• 购物车和候选状态丢失；
• 跨域问题只回答一半。

Anthropic 推荐一个主 Agent 持有整段会话，只有在需要时加载对应 Skill。

Main Agent
  ├─ search-discovery
  ├─ purchase-research
  ├─ planning-goals
  ├─ customer-care
  └─ memory-personalization

SubAgent 不是完全不用。复杂分析、独立上下文、只读计算等窄任务，仍可交给 Delegate；关键是不要机械复制企业部门结构。

4. Prompt、Skill、Tool、Harness 的职责

层	应放内容	设计目标
System Prompt	高频规则、身份、品牌、关键安全要求	每轮可用
Skill	长尾业务流程与 SOP	按需加载，减少常驻上下文
Tool	企业系统与 UI 能力	提供结构化输入输出
Harness / Backend	权限、校验、审批、审计	形成模型不可绕过的硬边界

官方给出的起始经验是：与三分之一以上流量相关的内容，可以考虑放进 System Prompt；安全与法律约束始终保留。这个比例是经验起点，不是硬规则。

UI-as-Tool

商品卡、套餐矩阵、行程和场馆图也被建模为 Tool。相比让模型输出一大段 Markdown，结构化 UI Tool 更容易校验、回放和在宿主应用中稳定渲染。

5. 写操作为什么必须经过安全闸门？

官方 Travel Demo 有一个定价测试：运营人员要求把基础房价永久降到 89 美元。该动作对应 29% 的降幅，超过示例的单次变化限制。

合格 Agent 应拒绝直接提交，并给出规则内最低价或日期限定促销等替代方案。

这个例子说明，Agent 安全不能只依赖 System Prompt。仓库的主要控制包括：

1. Fencing：把第三方文本视为不可信数据并隔离；
2. Provenance Gate：只允许操作可信工具在当前会话返回过的对象；
3. Staged Write：改价、补货和营销变更先进入待审批状态；
4. Host Approval：由宿主应用确认高风险动作；
5. Server-side Identity：身份由 Session 绑定，不允许模型传入用户或商家 ID。
   

支付被有意排除在仓库能力之外：Agent 可以准备结账信息，真实支付仍交给宿主系统。

6. 四个行业 Demo 分别验证什么？

行业	主要压力
零售	多商品组合、预算、偏好、库存和售后
旅行	日期、价格、取消规则和持续变化的行程状态
电信	身份、资格、套餐约束与账户权限
票务	座位、区域、价格和可售状态同步

同一 Agent Loop 可以复用，变化的是 Domain Data、Tools、Skills、UI 和 Guardrails。

7. 生产落地前的五项检查

1. 模型与业务系统的事实边界是否明确？
2. 高频规则、长尾 SOP、真实动作和硬限制是否放在正确层？
3. 写操作能否先 Stage、再 Preview、最后 Apply？
4. UI Tool 是否有 Schema，能否校验和回放？
5. Evals 是否覆盖越权、注入、信息不足、拒绝和跨能力请求？

Anthropic 建议从每条用户流程 50—100 个 Eval case 起步，并让产品、法务、运营和客服共同设计失败案例。

8. 参考实现的限制

该仓库适合做架构评审、原型和团队对齐，但不能直接视为生产系统：

• Demo 使用虚构数据；
• 没有生产级认证与授权；
• 不处理真实支付；
• Guardrail 是演示参数；
• README 明确说明项目不作为长期维护实现。

官方披露的最高 35% 购物车金额提升和最高 60% 购买完成概率提升，也没有公开完整实验口径，本文未独立复现。

总结

Claude Commerce Agents 的关键不在“聊天更自然”，而在于把目标理解、业务工具、结构化 UI、安全审批和评测闭环连接起来。

可以浓缩成一句工程原则：

让 Agent 理解目标，让 Skills 提供流程，让 Tools 连接能力，让 Backend 决定动作是否允许发生。

参考资料

• Anthropic：Building commerce agents with Claude
• Anthropic：A guide to the anatomy of effective commerce agents
• anthropics/commerce-agents