有效电商 agent 的架构指南
来自 Claude Blog · 期号 2026-09-02
摘要
电商 agent 的核心架构是一个模型在标准 agent loop 里运行，没有前置意图路由，也没有按领域拆成多个子 agent。 关键设计是 skills 而非 subagents。子 agent 每次交接都会丢失状态、增加 token 消耗和延迟，而 skills 在主 agent 的上下文里按需加载，避免了这些开销。只有两种场景值得用子 agent：一是需要独立上下文窗口的封闭任务（如深度调研），二是已有独立合规面的专用 agent。 指令放 system prompt 还是 skill，取决于使用频率。三分之一以上流量会触发的指令放 prompt，其余放 skill。安全规则、品牌约束、用户过敏信息等关键指令永远放 prompt。 工具设计上，agent 的工具应调用公司已有的核心系统（搜索、购物车、库存、促销引擎），而不是重新实现它们。工具返回的是模型需要推理的字段，其余全部丢弃。UI 组件也做成工具调用，而不是让模型输出自定义标签——工具调用天然在 messages 数组里，历史对话无需重新解析。 延迟优化分两端：端到端延迟靠工程手段压，感知延迟靠流式渲染和 UI 反馈来掩盖。prompt caching 是控制成本的主要手段。
深读
导读 电商 agent 的核心架构出奇地简单：一个模型跑在标准 agent loop 里，没有前置意图路由，也没有按领域拆成多个子 agent。关键设计是用 skills 替代 subagents，避免状态丢失和 token 浪费。读完能带走一套从架构选型、延迟优化到生产部署的实战经验，适合正在构建面向消费者的 agent 的工程团队。 关键信息 - 子 agent 架构每次交接都是状态有损操作，且每次交接的 token 消耗和延迟增加数倍；而 skills 在主 agent 的上下文里按需加载，避免了这些开销。 - 指令放 system prompt 还是 skill 的分界线是使用频率：三分之一以上流量会触发的指令放 prompt，其余放 skill。安全规则、品牌约束、用户过敏信息等关键指令永远放 prompt。 - 工具应调用公司已有的核心系统（搜索、购物车、库存、促销引擎），而不是重新实现它们。工具返回的是模型需要推理的字段，其余全部丢弃。 - UI 组件应做成工具（tool）而非自定义标签，因为工具调用是模型 API 的原生格式，历史对话无需额外解析即可回放。 - 最佳部署实践的缓存命中率达到 90–99%，缓存读取速度比未缓存快约 1.5–2 倍（在约 10 万 token 时）。 - 记忆写入应异步进行，在每轮或每几轮对话后由独立线程处理，不增加对话延迟，且在内部评测中事实召回率提高了 13%。 逐节讲解 架构：一个模型，一套 skills，没有子 agent 电商 agent 的核心架构是一个模型在标准 agent loop 里运行：推理目标、探索上下文、通过工具执行操作、通过 skills 学习流程、提出澄清问题、观察结果直到目标完成。没有前置的意图路由，也没有按领域拆分的子 agent。 作者明确反对子 agent 架构。理由是电商对话是一个紧密耦合的会话，跨越多个意图和轮次，需要大量共享上下文。子 agent 每次交接都是状态有损操作，影响响应质量，且每次交接的 token 消耗和延迟增加数倍。领域边界也极少清晰，退货流程可能需要订单历史、当前购物车和产品目录，子 agent 按领域拆分要么到处重复授权，要么在任务中间交接。 替代方案是 skills。Skills 在主 agent 的上下文里按需加载，提供类似的领域模块化和上下文控制，但没有交接开销。在多个企业部署的对比中，单一 agent 加 skills 在质量上持续优于「一个 prompt 包一切」和子 agent 设计，且通常成本更低、延迟更短。 子 agent 只在两种场景下值得用：一是需要独立上下文窗口的封闭任务（如深度调研子 agent），二是已有独立合规面的专用 agent（如药房或金融服务 agent），此时采用 hand-off 而非 delegation——ha…