读完 Anthropic 的商业 Agent 指南，餐参 AI 我重新搭了一遍

Agent 能搜索、能调工具，一段 demo 顺利跑完，然后呢？把它交给真实用户，接进订单和支付流程，我们还缺哪些东西？

Anthropic 最近分享的商业智能体架构指南，正好在讲这些事。材料来自它过去一年参与的几十个真实生产部署，分为架构、延迟与成本、生产运行三个部分。读完以后，我回头把餐参 AI 改了一遍：结构按单个 Agent 加 Skills 来搭，常用的内容进系统提示词，其余做成 Skill；工具只接已经在跑的系统；评估补上了快照和反向用例；执行边界写进代码，模型只负责提议。

下面沿着指南的顺序，把我读到的取舍整理一遍。这是一篇阅读笔记，效果数字来自 Anthropic 所述的部署或评估。

先别急着拆成一群 Agent

指南里的 commerce agent，主要是简化在线目录中的买卖流程。面向消费者时，它要搜索、比价、找替代品、组合订单；面向商家时，回答销售问题，协助促销，处理库存与定价。两类场景可以共用一套核心架构：一个模型围绕目标持续工作，查看上下文，通过工具采取行动，按需加载 Skills 里的流程，碰到不确定的地方向用户澄清，直到任务完成。

注意这张图里没放什么：前面没有意图路由器，后面也没有按业务领域排开一组专用子智能体。多 Agent 分工明明很常见，为什么商业场景反而不急着拆？

拆开的好处是有的：独立上下文，可以并行，容易观察，错误方便隔离。但购物对话不太容易按部门切开。用户刚说完预算，又补一个配送时间，接着问某件商品能不能替换。购物车、偏好和前几轮约束都得跟着走。拆成多个子智能体后，主模型要反复把这些状态传过去，漏掉一句话，下一步选择就可能偏了。Anthropic 观察到交接带来的质量损失，一次交接还可能多消耗几倍 token，增加数秒延迟。领域边界也没有组织架构图那么整齐，一个退货问题可能同时需要订单历史、当前购物车和商品目录。

Skills 换了个拆法：把某个领域的流程写成指令，加载到已经持有完整对话的主模型里。业务知识仍然可以分模块维护，不用为了加载一段退货流程，连用户对话一起搬走。指南列举的多个企业部署比较中，带 Skills 的单一智能体，质量持续优于“一个大提示词搞定一切”和领域子智能体方案。这个结果有个前提：商业对话共享的状态很多。餐参 AI 我也照这个思路搭的：一个主模型拿着完整的对话，业务流程写成 Skill 按需加载，不拆成一组子智能体。拆开以后要反复搬状态这件事，正是我不想要的。

深度研究适合交出去，主模型把子智能体当工具调用，给它独立的上下文窗口。药房或金融服务已经运行着专用智能体时，可以让对方正式接管。这里得分清“交接”和“委托”：交接改变了对话的所有者，委托时主模型还在中间。名字都叫多 Agent，实际安排很不一样。

系统提示词和 Skill，按使用频率分。按需加载 Skill 通常要多用一个模型回合。预计三分之一以上流量会用到的内容，可以放进系统提示词；其余再考虑 Skills。安全规则、法律要求、品牌约束和关键用户事实，需要一直可见。比起按文档长度硬拆，我更愿意拿一段具体信息来问：什么时候会用到它？漏掉一次会发生什么？

餐参 AI 里，我按这条重新分了一遍：安全和口径这类每次都得在的，放进系统提示词；偶尔才走一次的流程，做成 Skill。分的依据不是文档有多长，是漏掉一次会怎样。

工具接住已有系统，不要把业务逻辑重写一遍。电商公司已经有搜索与排名、购物车、库存、促销系统，没必要让模型重新做一遍搜索排序。工具的边界，放在已有系统完成判断、需要模型继续组织任务的地方。工具返回的结果会直接进入上下文，接口返回的字段不意味着模型全都需要。尤其别只扔回一个错误码，缺少产品 ID，就直接告诉它“查询可用性需要产品 ID，请补充后再调用”。

餐参 AI 的工具，接的也都是已经在跑的系统。模型要做的是把结果组织起来，不是把业务逻辑重写一遍。返回给模型的字段我也挑过一轮，接口给得出的，不等于模型需要的。

把 UI 组件也当成工具。产品轮播、行程单、座位图，都需要结构化的数据。指南把呈现商品、呈现行程也定义成工具，模型提供类型化参数，服务端校验，客户端渲染。组件以原生工具调用的格式留在消息列表里，重新打开旧对话时不必再解析一套自定义标签。代价在流式体验上，参数全部收齐再发出去，用户可能等很久；启用参数即时流式传输可以更早收到内容，但业务校验不能跟着取消。

慢在哪里，要看整个任务

指南把结果质量放得很重。快当然好，可几秒钟就给出一个用不了的结果，用户仍得重来。每个场景都有一笔能接受的“延迟预算”，先弄清楚能等多久，再看怎样把任务完成在这段时间里。

少跑几轮，有时比换一个快模型更有效。任务完成延迟是各轮“到最后一个 token 的时间加工具处理时间”的总和。预加载上下文是一个很具体的办法，用户从商品页打开助手，当前商品的数据本来就知道，可以直接带进会话。更强的模型也可能更快，它生成 token 未必占优，但规划好一些，少绕几轮。指南提到，生产任务经常超过五个回合时，更快完成任务的往往是更智能的模型。

工具本身也可能在浪费时间。一个 Agent 工具内部顺序调用了好几个底层服务，用户等的那几秒有相当一部分花在后端。调度时也不必总等整轮输出结束，模型正在生成多个工具调用，其中一个已经给出完整参数，就可以先处理它。指南中的案例把数秒的间隙缩短到了数百毫秒。

用户什么时候看到东西，是另一条时间线。商业响应通常有五百到七百个 token，全部生成完再显示，可能就是五秒以上的加载动画。组件边生成边呈现，省掉的正是对着空白等待的时间。还可以告诉用户当前在做什么，“正在找临水的酒店”，把实际步骤说清楚就好，不用编造进度。

缓存先看顺序，再看长度。缓存读取的 token 成本约为新输入的十分之一，做得好的部署命中率能到 90% 到 99%。缓存按前缀匹配，开头越稳定越容易复用。请求可以按变化频率排成三段：全局段放系统提示词和工具定义，会话段放当前用户信息与对话历史，易变段放时间、当前页面。把时间戳放在系统提示词最顶部，是一个很容易忽略的问题。

落实到请求里，Skill 作为工具结果加载，不要不断追加到系统提示词中；每轮把缓存断点移到最新用户回合的末尾。

算一次完成任务的钱。先把任务完成率、评估分数的底线，以及 p50、p99 的延迟预算写下来，再让每个候选模型跑完整套用例。计费单位是容易看错的地方，每次调用便宜，不等于完成任务便宜。结果接近时，指南倾向选更智能的配置。这个取舍我能理解，但顺序不能倒过来：预算和评估先过关，再谈余量。

真正上线以后，还要有人管这些事

记忆要落在自己的系统里。用户三月说过自己坚果过敏，六月再来，不该又从头问一遍。指南把长期记忆拆成存、写、读三件事。存储上，每条事实是一条小的类型化记录，有键、短值、类别和来源会话。商家场景要区分账户和操作员，店经理不该读到区域经理的对话内容。合规要在设计记忆时就考虑，系统允许持有哪些类别，要在写入路径用校验器强制；用户要有查看、纠正、删除入口。写入可以挪到对话之外，由独立进程读取对话，新增、修改或删除事实。Anthropic 的内部评估中，这种异步方式让事实召回提高了 13%。提取规则必须清楚，不能因为读过某件商品写着适合运动，就把喜欢运动存成用户的事实。读取分三层：几乎每次都依赖的少量事实始终放在上下文里，和本轮任务相关的预取，剩下的放到查找工具后面。

模型提议之后，谁来执行。商业 Agent 一旦涉及订单、支付、退款、改价，错误就可能直接变成损失。提示词能约束行为，真正的执行边界必须在代码里。模型提出行动，由人或确定的政策机制决定是否执行。写入和渲染只接受服务端签发、在当前流程中可用的 ID，模型编的、用户粘贴的、评论里藏的编号，进入后端前就要拒掉。限制要扛得住重复请求，Agent 可能换一种说法再试，也可能并行发出多个请求。第三方内容不能直接信，商品名、评价、卖家消息都可能夹带伪装成指令的文字。推荐错一件商品，和错误地执行一笔交易，后果差得很远。“请谨慎操作”几个字承担不了这些责任。

餐参 AI 的执行边界，现在写在代码里。模型可以提议，能不能执行、由谁执行，交给代码和既定的政策判断，不放在提示词里靠嘱咐。

评估要能复现那个出错的状态。加一个工具、改一行提示词，都可能影响原来正常的行为。快照评估的思路很直接：模型 API 是无状态的，把系统提示词、工具和消息列表连同业务状态构造好，追加一条用户请求，让 Agent 从这里继续跑，再检查最终状态。要测长对话里的某个问题，不必每次都从第一句话聊起。

餐参 AI 的快照现在造得还比较粗，状态是拼出来的，离指南里那种完整构造还有距离。粗归粗，至少能把出过问题的那一刻重新跑一遍，而不是每次从头聊。对工具调用路径卡得太死，模型稍微换一种合理做法，测试也会失败，更有用的是检查结果是否正确、约束是否遵守。

反向案例是 Anthropic 发现最常见的缺失项。写了“应当拒绝”，也要写什么情况下“应当接受”；写了“必须追问”，就配上信息足够时“应当直接做”的案例。否则测试看着很安全，交给用户的却可能是一个不断打断、什么都不敢继续的助手。餐参 AI 的用例里，我补的就是这一类：信息已经够了的时候，应当直接做，不用再追问一遍。用例覆盖可以沿用指南的五类：核心请求，上下文依赖，安全和品牌，界面，多能力复合。每个用户流程先准备五十到一百个案例，再从生产日志里持续补充。

多个团队共同维护，不等于每队配一个 Agent。指南把所有权放回已有系统：定价团队负责促销工具和定价 Skill，客服团队负责订单、退货工具，每个 Skill 和工具只有一个明确的 owner。变更要带着案例一起交付，改 Skill 跑它自己和相邻能力的用例，改工具跑每个调用它的场景，改共享系统提示词就跑全套。提示词和 Skills 也得排进发布日历，先走灰度，留一个开关，高峰前冻结变更。一段文字更新，可能同时改变所有用户的体验。

回到一次交易怎么完成

读完再回看，里面不少工作其实很熟悉：工具接的是已有系统，Skills 写的是业务流程，评估把产品要求变成测试，运行框架执行本来就该对任何客户端生效的权限和政策。模型参与进来以后，这些工作还在，谁负责也仍得说清楚。

比起一开始选多少个 Agent，我更愿意先把一次交易写清楚：从用户提出需求到订单生效，哪里要确认，谁有权执行，失败了从哪一步继续。模型能承担哪些部分、需要多快、一次完成花多少钱，都放回这条流程里讨论。餐参 AI 里改的那几处，也就是这么来的。