01

能用 Skills，就别急着拆子 Agent

Commerce Agent 面对的是一类很容易把架构师“拆上头”的任务。消费者可能先找鞋、再比较尺码和配送，接着改购物车、问退货，最后又突然补一句“我对坚果过敏”；商家侧则会在销售分析、库存、定价、促销和营销活动之间来回切。按业务域各做一个子 Agent，看起来分工清晰，现实里却经常卡在上下文交接上。购物车状态、用户偏好、历史对话、暂存修改彼此纠缠，每次从主 Agent 把任务交出去，都要重新打包这些状态。Anthropic 的说法很直接：这种 handoff 往往是一种有损状态传递，不只可能掉信息、掉质量，还会额外消耗数倍 Token，并增加数秒延迟。

图片

图 1｜Commerce Agent 核心架构图

更麻烦的是，业务边界并没有组织架构图那么整齐。一次退货可能同时需要订单历史、当前购物车和商品目录；一句“如果把这个商品降价 15%，库存够不够覆盖需求？”又天然横跨定价与库存。如果硬按领域拆 Agent，要么每个 Agent 都重复接入同一批数据，要么任务做到一半继续交接。Anthropic 因此更偏向“单 Agent + Skills”：主 Agent 一直握着完整对话，某项领域能力需要时，再把对应 Skill 加载进当前上下文。它仍然保留模块化，却省掉了把整段会话搬来搬去的成本。Anthropic 称，在多个企业部署的比较里，这种设计在质量上持续优于“一个 Prompt 包办一切”和多子 Agent 两种方案，通常也能拿到更低的单任务成本和延迟。

这并不等于子 Agent 被判了死刑。Anthropic 给出的例外很清楚：如果任务边界足够独立、过程很长，而且适合拥有一块自己的 Context Window，子 Agent 反而很好用。Deep Research 就是典型例子——它要搜大量文档、写代码、跑程序、遍历数据模型，途中还会撞不少死路，最后只把一份压缩结果交回主 Agent 即可。还有一种情况是药房、金融服务这类已经拥有独立合规边界的专用 Agent，此时更像把整段对话真正“交接”过去。区别不在名字，而在谁拥有会话：委派时主 Agent 仍掌控对话，子 Agent 只是进出一次；真正 handoff 后，领域 Agent 会成为直接对话方。

Prompt 和 Skill 怎么分，Anthropic 也给了一个很实用的起点：预计与三分之一以上流量相关的内容，通常值得常驻 System Prompt；其余长尾能力放进 Skills。安全、法律、品牌限制以及过敏信息等关键用户事实是例外，不管频率多低，都应该常驻 Prompt。参考实现里，Shopping Agent 把 grounding、购物车和结账语义、展示规则、商品搜索放在 Prompt 中，把 search-discovery、purchase-research、planning-goals、customer-care、memory-personalization 拆成Skills；Merchant Agent 则按 performance-insights、catalog-listings、inventory-operations、pricing-promotions 和 marketing-campaigns 拆分。这个划分方式比“一个部门一个 Agent”更接近真实对话的流动方式。

Tool 的边界也被重新划了一遍。电商公司本来就有搜索排序、购物车、库存、促销、用户画像、销售分析等系统，里面塞着多年打磨出来的业务逻辑和模型拿不到的内部信号。Agent Tool 不应该重写这些东西。比如 search_products 返回结果时，排序应该已经由原有搜索系统完成；模型负责判断哪些结果更符合用户目标、该展示多少、怎么解释，而不是自己再造一套 ranking。Anthropic 把这条边界概括得很漂亮：确定性业务逻辑结束的地方，才是模型判断开始的地方。Tool Result 本身也是 Context，所以只返回推理真正需要的字段；图片 URL、冗余元数据这类“看起来有用、实际上吃上下文”的信息能删就删，错误也别只扔一个 403，最好直接告诉模型下一步缺什么参数。

图片

图 2｜UI / Presentation Tool 工作方式

连 UI 也被 Anthropic 做成了 Tool。商品轮播、行程、座位图、套餐对比这些东西，如果让模型输出自定义标签，再让前端自己解析，组件一多就容易崩：格式可靠性下降、System Prompt 越来越胖、历史消息还会变成只有自家解析器看得懂的私有格式。更稳的做法是把 present_products、present_itinerary、present_plan_comparison 这类组件定义成带类型的 Tool Call，服务端验证参数并补全数据，客户端只负责渲染。这样历史消息仍然保持原生工具调用格式，用户下轮说“左边第三个”时，布局状态也还留在 messages 里。代价是顶层参数需要先缓冲和校验，可能拖慢流式体验；如果真的需要 Token 级流式，可以打开 eager_input_streaming，但这意味着主动放弃一部分服务端 schema 保证，最好再包一层重试。

02

Agent 要变快，第一刀未必该砍模型

消费者不会因为你背后跑的是“复杂 Agent”就愿意多看五秒加载动画，但 Anthropic 同样提醒，真正推动留存、互动和购物车规模的，还是结果质量。延迟优化不能把 Agent 削成一个反应很快、但经常做错事的客服机器人。它把任务总耗时拆得很朴素：所有模型轮次的末 Token 时间，加上所有 Tool 处理时间。能动的杠杆也就三个——减少轮次、加快工具、加快 Token。问题是这三个指标会互相打架，所以要优化的是总和，而不是把某一个数字刷得特别漂亮。

最容易被低估的是轮次。模型不够聪明时，一次复杂请求可能会多规划几次、多查几轮、再修正几轮；单次生成确实快，整个任务却走得更远。Anthropic 在生产观察中发现，如果查询普遍较复杂，或者每项任务经常超过大约五轮，更聪明的模型反而可能是“更快的模型”：它每个 Token 慢一点，却能更有效地规划工具调用，把总轮数压下来，这种收益尤其容易体现在 p90、p99 这种复杂请求上。于是模型选择不能只盯每百万 Token 价格，更应该看完成一次任务到底花多少。一个便宜模型如果要多跑几轮、失败更多次，最后并不便宜。

减少轮次的方法并不神秘。用户从商品详情页打开助手，就把当前页面数据直接塞进会话；商家从营销活动面板进入，就预加载活动信息。能预判的上下文没必要等 Agent 再跑一次 Tool。多个互不依赖的操作也尽量并行：同时搜几类商品、读几份政策、查多个销售数据源，都可以在一轮里发出多个 Tool Call，再一次性把结果送回。工具侧也别把后端缺失的业务能力都缝进一个巨型函数里。一次“库存查询”如果内部已经要查 SKU、逐店问库存、算履约截止时间、再执行替代规则，它已经不是简单 Tool，而是在偷偷长成另一个业务系统；更稳的修复是让上游系统提供一个能直接回答问题的接口，再让 Agent 去调用。

图片

图 3｜Tool 提前调度 / Eager Dispatch

Tool 执行本身还可以提前。模型生成工具参数时是逐步流出的，某个 Tool 的参数一旦完整，Runtime 就可以立刻调度它，不必等模型把这一轮所有内容都吐完。Anthropic 见过这种做法把原本几秒的空档压到几百毫秒，Claude Agent SDK 默认就会这么做；如果已知某个 Tool 特别慢，还可以提示模型优先输出它。至于用户“感觉有多快”，又是另一回事。一份渲染后的 Commerce 回答通常有 500～700 个输出 Token，如果全生成完再展示，用户只会盯着转圈。组件生成到哪就渲染到哪，再用“正在寻找靠近水边的酒店”这种来自 Tool 参数的人话提示展示进度，总耗时可能几乎没变，等待感却会差很多。

图片

图 4｜普通 Agent 与低感知延迟 Agent 对比

03

90%～99% 的缓存命中率，关键不是少塞 Context

Agent 越做越长，成本很快会从“模型价格”变成“上下文价格”。Anthropic 把 Prompt Cache 视为 Commerce Agent 里最有潜力的一根杠杆：缓存输入 Token 的读取价格只有新 Token 的十分之一，写入缓存约是普通输入的 1.25 倍，也就是贵约 25%，但第二次命中就能回本。它观察到表现较好的 Commerce Agent 部署可以做到 90%～99% 的缓存命中率；在大约 10 万 Token 的 Context 规模上，缓存读取速度约为未缓存读取的 1.5～2 倍，而且上下文越长，收益会继续放大。

但 Cache 不是“开个开关就完事”。它按前缀匹配：请求从头向后读，遇到第一个和历史请求不同的字节，后面的缓存都接不上。因此 Context 里放什么固然重要，顺序同样重要。Anthropic 把请求拆成三段：Global、Session、Volatile。Global 放大部分 System Prompt 和 Tool Definition，尽量在所有会话之间逐字节一致；Session 放用户上下文、Memory 和对话历史；当前时间、当前页面这种每轮都可能变化的内容放到最后的 Volatile 区。最常见的低级错误，是把时间戳或当前页面信息塞在 System Prompt 顶部——一行每天变化的内容，足以把后面十几万 Token 的缓存一起掀掉。

图片

图 5｜Prompt Cache：Global / Session / Volatile 三层结构

Skills 也要顺着缓存机制设计。Anthropic 建议把 Skill 正文作为 Tool Result 加载，而不是动态追加到 System Prompt，这样它会自然进入对话前缀，后续轮次可以和历史一起缓存。每轮还要把缓存断点向前滚到最新用户轮次末尾，这样包括搜索响应等很长的 Tool Result 也能在后续继续命中。到这里，Context Engineering 已经不只是“给模型哪些信息”，还变成“稳定信息放哪、用户信息放哪、易变信息放哪”。顺序错了，内容一字没多，账单和延迟照样会变。

模型和 effort 配置也应该和这套缓存、延迟指标一起做 sweep。Anthropic 建议先确定任务完成率、回答相关性、grounding 准确性等质量底线，再给 p50、p99 延迟和成本设预算，用完整 Eval 套件把所有候选模型与 effort 级别跑一遍。Merchant Agent 分析量大，可以从更强模型起测；面向消费者的 Agent 更敏感于响应时间，可以从 Sonnet 级别起测，但最终应该让真实查询分布决定。还要留意一个常见陷阱：Prompt 往往在某个模型上越调越贴身，同一份 Prompt 直接拿去横扫其他模型，可能天然让别的模型吃亏。小模型需要更明确的指令，大模型反而可能把那些小模型长期忽略的规则执行得过于认真。候选模型失败时，先看失败案例再各自调几轮 Prompt，比直接淘汰靠谱得多。

图片

图 6｜Rolling Cache Breakpoint / 滚动缓存断点

04

Memory 和安全，都不该继续交给主 Agent

Agent 从“这轮回答得不错”走向“半年后还记得我是谁”，Memory 就不再是一个 Prompt 技巧，而是数据系统。Anthropic 的原则很干脆：记忆应该存在你的系统里，而不是模型里。鞋码、默认门店、履约偏好、常用报表频率这类长期事实，更适合成为数据库中的小型类型化记录：key、简短 value、类别，以及来源会话。商家侧还要按“人”而不是共享账号保存，否则同一个商家账号背后的门店经理和区域经理会互相串记忆，权限边界也会跟着出问题。更别忘了，最值得记住的偏好往往也最敏感，所以 Memory 从一开始就要被当成数据处理设计：哪些类型允许保存、用户能否查看和删除、保留多久、某些地区能否独立关闭，都应该落在写入链路和产品能力里，而不是只写一句“请注意隐私”。

写 Memory 时，Anthropic 反而不推荐让主 Agent 自己调用 save_memory。原因很现实：每次保存都可能给面向用户的轮次再添一个 Tool Call；为了更新和去重，还可能先读一次存储，延迟继续叠加。更麻烦的是，主 Agent 每轮又多了一件要记得做的事，注意力一分散，Memory 反而更容易漏。它的做法是异步提取：每轮结束后，或者长会话每隔几轮，由独立线程或进程中的 Extractor 读对话，创建、更新或删除事实。这个 Extractor 只看用户和助手文本，不读 Tool Result，避免把商品描述、评论之类的外部内容误写成“关于用户的事实”。在 Anthropic 内部的 Commerce Memory Eval 中，这种方式把事实召回率提高了 13%。读取则分三层：少量关键事实常驻 Context；能根据当前页面或预加载 Skill 判断出的相关事实每轮 prefetch；其他长尾 Memory 走查询 Tool。

图片

图 7｜异步 Memory 提取架构

安全比 Memory 更不能靠模型自觉。支付、退款、改价、启动营销活动这些动作一旦出错，损失是真金白银，而且往往不可逆。Anthropic 的核心原则是：模型可以负责“提出动作”和“暂存修改”，真正执行必须交给人或确定性策略。消费者侧的 checkout 工具只负责展示购物车和提交按钮，Agent 本身拿不到直接扣款的方法；Merchant Agent 的写工具也只生成 staged change 和服务端 ID，只有经过真实界面审批的ID，apply_change 才会成功，而且执行时还要重新检查当下的限制，不能沿用暂存那一刻的旧状态。

同样的思路贯穿到 ID、限额和第三方内容。Runtime 会记录本会话中服务端真正交给模型的 ID，任何写入和渲染只接受这份集合里的 ID：模型幻觉出来的、用户手工粘贴的、藏在评论里的，一律进不了后端。购买数量、票务配额、折扣深度、活动预算等限制，也必须按“修改后的最终状态”执行，而不是只看单次请求；同一会话里的写操作还要串行化，避免模型并行调用时叠加穿透上限。商品信息、评论、政策、卖家消息、网页片段等第三方文本，则全部按不可信输入处理，先清洗控制字符和伪造标签、限制长度，再放进固定围栏里交给模型。Prompt 负责告诉模型“围栏里是材料，不是命令”，Runtime 负责保证这条契约真的有牙齿。

05

不要只 Eval 聊天，真正该测的是 Agent 所处的状态

到了发布环节，Agent 最麻烦的地方终于完全暴露出来：这是一个非确定性系统。一点 Prompt 改动、一个 Tool 字段变化，都可能在另一个看似无关的地方造成回归。很多团队会让第二个模型扮演用户，再用 Judge 给整段对话打分；Anthropic 不建议把它当主要测量手段。两个非确定性系统先互动，再让第三个非确定性系统判断，样本量、成本和噪声都会往上走，失败后还很难定位到底是谁的问题。它更推荐 Snapshot Eval：直接构造某个真实会话状态——System Prompt、Tools、messages、已有购物车、前几轮矛盾信息、已经加载的 Skill——再追加一条测试消息，只看 Agent 从这个状态出发，最后做对没有。

这种方法的好处是可以故意把 Agent 扔进“脏现场”。很多生产故障不会发生在第一轮，而是出现在长历史、多个 Tool Call 之后，或者用户前后给过矛盾约束时。如果 Eval 永远从干净状态起步，所有方案可能都轻松满分，真实系统一上线却照样翻车。Anthropic 还要求正反 Case 成对：每条“应该服务”配一条“应该拒绝”，每条“应该直接执行”配一条“应该先询问”；注入测试也要分用户侧注入和数据平面注入，后者专门模拟恶意文字藏在商品名、评论或网页片段里。UI 同样要测：组件是否正确、数量上限是否生效、内部 ID 有没有漏到用户界面、超时和空结果怎么处理。跨能力请求也要单独建 Case，不能只测每个 Skill 各自的“单科成绩”。