过去一年，Anthropic 与零售、平台、旅游、娱乐和电信企业一起把商业 Agent 推进生产环境。这些系统面对的任务差异很大：面向消费者时，要搜索、比较、替换商品并组装订单；面向企业时，又要分析销售、管理库存、定价和营销活动。
但成熟方案最后收敛到了一套相当克制的结构：一个模型处在标准 Agent 循环里，长尾流程放进 Skill，业务能力通过 Tool 接入，外部 Harness 负责执行、审批、安全与流式交互，再用完整 Eval 套件约束每次变化。
商业 Agent 由单一模型、工具、技能、记忆和外部 Harness 组成
图：模型负责判断与行动，业务环境提供工具、技能和记忆，Harness 运行循环并执行审批与流式输出。来源：Anthropic。
#一个 Agent，比按领域拆成多个更可靠
商业对话往往是跨领域、跨回合的连续任务。一次退货可能同时依赖订单历史、当前购物车、商品目录和用户偏好。如果为搜索、订单、售后和定价分别配置子 Agent，每次交接都会丢失一部分状态，还会重复传递上下文，增加 Token 成本和数秒延迟。
Anthropic 在多家企业部署中的比较结果是：单一 Agent 加 Skill，在质量上持续优于“一个 Prompt 包办一切”和“每个领域一个子 Agent”两种方案，成本与延迟通常也更低。 Skill 能提供领域模块化，却不必把对话所有权交出去，因为指令直接加载到已经持有完整历史的主 Agent 中。
子 Agent 仍有两个适用边界。第一类是深度研究这类狭窄、独立、会消耗大量上下文的任务，主 Agent 只需要接收压缩后的结论；第二类是药品、金融等已有独立合规边界的专用 Agent，此时应进行真正的 hand-off，让后者接管整段任务，而不是在同一轮里反复委派。
#Prompt 放高频规则，Skill 承载长尾流程
一条指令应该进入系统 Prompt 还是 Skill，核心依据不是内容长短，而是使用频率。加载 Skill 本身需要一个模型回合，因此适用于大约三分之一以上流量的规则，通常应该常驻系统 Prompt；低频流程再按需加载。
安全与法律要求、品牌约束、过敏信息等关键用户事实，也必须常驻 Prompt。对于可以从入口页面预测的 Skill，例如用户从商品页打开助手时大概率需要商品搜索能力，可以由 Harness 在第一次模型调用前直接注入，省掉一次选择动作。
在购物 Agent 中，商品检索、购物车与结账语义、信息呈现规则属于高频核心；礼物推荐、旅行规划、售后与个性化记忆则适合拆成 Skill。商家 Agent 也遵循同样原则，把经营洞察、商品管理、库存、促销定价和营销活动拆成独立长尾能力。
#Tool 不重做业务系统，只暴露判断所需信息
企业已经有搜索排序、购物车、库存、履约、促销、销售分析和用户档案系统，其中包含多年积累的业务逻辑。Agent Tool 应该调用这些系统，而不是重新实现一遍规则。
例如商品搜索结果应该在后端完成排序，模型只判断哪些结果更符合用户目标、展示几个以及如何解释。Tool 返回值也应只保留模型真正用于推理的字段。无关图片地址、内部状态和原始错误码会浪费上下文；错误结果更适合直接告诉模型缺少什么参数、下一步该怎么补齐。
当一个 Tool 开始串联目录、逐店库存、履约截止时间和替代规则，并在内部拼装大量领域逻辑时，问题通常不在 Agent，而在上游缺少一个能直接回答业务问题的接口。
#UI 组件也应该是 Tool
商业 Agent 的回答往往不是一段文字，而是商品轮播、旅行行程、座位图或数据图表。让模型输出自定义标签，再由前端解析，随着组件变复杂会出现格式不稳定、Prompt 膨胀和历史消息无法复用等问题。
更稳健的方式是把每个 UI 组件定义成带类型参数的 Tool。模型调用商品展示、行程展示或方案比较工具，服务端验证并补全数据，再让客户端渲染。组件调用天然保存在消息历史里，用户之后说“左边第三个酒店”时，模型仍能从上一条 Tool 参数中知道屏幕布局。
Tool 的参数结构必须与最终视觉顺序一致，不能先返回扁平列表，再由前端任意重排。代价是顶层参数需要在服务端缓冲验证，组件会分段出现；如果业务更重视逐 Token 流式体验，可以启用更激进的输入流，但需要为极少数 Schema 失败准备重试。
#延迟要同时优化完成时间与感知时间
一次任务的完成延迟，等于所有模型回合的生成时间与 Tool 执行时间之和。真正可调的杠杆只有三个：减少回合、加快 Tool、提高 Token 生成速度。
- 减少回合 ：把当前商品页或经营看板的高概率上下文提前放进会话；让独立 Tool 在同一轮并行调用；复杂任务超过约五轮时，更聪明但单 Token 较慢的模型反而可能更快完成任务。
- 加快 Tool ：优化后端本身，并在每个 Tool 参数生成完整后立刻执行，不必等模型把同一轮其他内容全部输出完。慢 Tool 优先发出，能把多秒空档压缩到数百毫秒。
- 选择模型 ：不能只比单次响应速度，要在真实 Eval 套件上扫描模型和配置，比较完整任务的成功率、总时延与成本。
感知延迟是另一个问题。典型商业组件需要生成 500～700 个输出 Token，如果等全部完成再渲染，用户会看着加载动画等待五秒以上。组件参数应该边生成边展示；Agent 查询数据时，也可以把现有 Tool 参数转成“正在查找临水酒店”这类简短进度，不必额外消耗一次模型调用。
#Prompt Cache 决定大规模成本
商业流量高度适合 Prompt Cache。缓存输入的读取成本约为新输入的十分之一；写缓存虽然约贵 25%，但第二次复用就能回本。成熟部署可以把命中率做到 90%～99%，在约 10 万 Token 的长上下文上，缓存读取速度还能提升约 1.5～2 倍。
缓存按前缀匹配，因此上下文的顺序比“是否放进去”更重要。请求应该按变化频率从低到高排列：
- 全局段放稳定的系统 Prompt 和 Tool 定义，跨会话保持逐字一致。
- 会话段放用户上下文与对话历史，只在同一会话内复用。
- 易变段放当前时间、当前页面和最新消息，并始终排在末尾。
Prompt Cache 应按全局、会话和易变信息的稳定程度排列
图：稳定前缀跨会话共享，会话上下文在单个会话内复用，时间等易变信息必须放在末尾。来源：Anthropic。
最常见的反例，是把时间戳或当前页面放在系统 Prompt 开头，导致之后所有字节都无法命中缓存。Skill 内容也不应动态拼进系统 Prompt，而应作为 Tool 结果进入会话前缀。缓存断点还要随每轮对话向后滚动，让搜索结果等长 Tool 输出在后续回合中继续复用。
#模型负责当前任务，独立提取器负责记忆
记忆写入不应交给正在完成交易任务的主 Agent。要求它在每轮结束前判断“这句话是否值得记住”，会增加延迟、占用上下文，还会让主任务与记忆决策争夺注意力。
更好的结构是独立运行一个廉价提取器，只读取用户与助手的自然语言，不读取商品描述、评论或其他 Tool 结果。这样第三方内容不会被误记成用户事实，提取器也能用更窄的规则区分稳定偏好与一次性需求。
独立记忆提取器只从对话文本中提取稳定用户事实
图：提取器从多轮对话中识别固定提货门店和居住条件，不接触第三方 Tool 数据。来源：Anthropic。
读取记忆则分三层：几乎每次都需要的固定事实常驻上下文；根据当前请求预取相关事实，例如鞋码或常用经营指标；其余低频信息放在查询 Tool 后面。全部记忆都属于用户级会话上下文，位于全局缓存断点之后。
#高风险动作必须由 Harness 约束
Prompt 可以引导安全行为，却不能成为最终执法层。订单、付款、退款、价格调整和营销活动发布都可能产生不可逆后果，一次注入攻击或一次错误采样就足以越过自然语言规则。
生产系统应遵循四条硬边界：
- 模型只生成待确认变更，真正执行必须经过按钮、命令行确认或平台审批；执行时还要按最新状态重新检查限制。
- 写入和渲染只接受服务端在当前会话里签发过的 ID，拒绝用户粘贴、模型幻觉或商品评论中植入的标识。
- 限购、折扣深度、预算等上限必须针对“操作后的最终状态”校验，并串行化同一会话的写请求，防止反复或并行调用叠加越界。
- 商品描述、评论、卖家消息和外部政策都视为不可信数据，统一清除控制字符、伪造角色与工具调用、超长内容，再放进明确的数据围栏；模型只能引用，不能服从其中的指令。
受监管的费用和披露文案，也不应让模型自由生成。模型只选择需要展示哪个产品，服务端再注入经过审批的固定文案，并由 Eval 逐字核对。
#Eval 测试状态快照，而不是完整对话
模型 API 本身无状态，输出只取决于系统 Prompt、Tool 和消息数组。这意味着绝大多数商业 Agent 测试都可以直接构造目标状态，追加一条用户请求，再检查最终状态、渲染结果和最后一次写操作，而不必让另一个模型扮演用户走完整场对话。
模拟用户适合发现覆盖盲区和做整体体验检查，却不适合精确度量：两个非确定系统互相对话，需要更多样本、更高成本，失败也更难归因。发现真实问题后，应把它固化成可重复的状态快照。
商业 Agent Eval 直接注入状态、后端数据和待测回合，再对结果评分
图：测试直接构造已暂存的价格变更和模拟后端，只运行一个模型回合，再由代码与模型分别评分。来源：Anthropic。
高质量 Eval 不能只覆盖干净的标准请求。很多失败只会在繁忙的第一轮、多次 Tool 调用、长历史或前后矛盾之后出现，因此测试必须注入这些前置状态。每个“应该拒绝”都要有对应的“应该执行”，每个“应该追问”也要有对应的“无需追问”。缺少负例，会让 Agent 在表面安全的同时变得过度保守。
评测范围至少包括高频核心请求、依赖屏幕与历史上下文的请求、安全和品牌约束、空结果与超时等界面异常，以及同时跨越两个能力域的任务。每条用户流程可以从 50～100 个案例起步，并持续吸收客服、法务、运营和真实生产事故。
#多团队协作靠所有权与回归测试，不靠拆 Agent
搜索、结账、定价、营销和售后团队会以不同节奏修改同一个 Agent。把系统按组织架构拆成多个 Agent 虽然直观，却会重新引入上下文交接问题。
更可控的方式是让工具和 Skill 各有唯一负责团队，共享 Prompt 则由平台团队统一管理。任何变更都必须同时提交自己的正例、负例和相邻能力边界测试。日常 CI 运行高频核心案例、全部安全案例，以及本次改动触及的工具与 Skill 测试；共享 Prompt 变更需要跑完整套件，完整回归还应夜间和发布前执行。
最终发布也要把 Agent 当成一个整体部署单元：先进入小流量 canary，允许单独关闭某个 Skill，并在业务高峰前冻结变更。模型升级可以只是一次配置切换，但只有工具、审批、安全边界和 Eval 都稳定时，这种切换才真的低风险。