191 篇博文 含有标签「agents」

凌晨 3 点因为宕机而把你吵醒的告警其实是简单的。供应商返回了 40 分钟的 503 错误，你的回退机制生效了，运维手册（runbook）启动了，复盘报告（post-mortem）几乎可以自动完成。而那些没有吵醒你的告警——那些在所有仪表盘都显示绿色的情况下，让你的支持队列在 6 小时内堆满的告警——才是渐变故障（brownout）。供应商的 API 仍然有响应。状态页依然显示“运行正常（operational）”。你的 p99 延迟已悄然从 2.1 秒漂移到 14 秒，错误率从 0.1% 上升到 4%，而唯一察觉到的人是那些已经流失的用户。

供应商的可用性并不是非黑即白的二元状态。大多数团队编写的回退逻辑——“如果供应商宕机，则切换到备用方案”——本质上是用一个只有两种状态的状态机去应对一个连续变量，当供应商处于“惨淡运行”而非“彻底宕机”的状态时，这种机制根本不会触发。为渐变故障（brownouts）而设计是一个与处理宕机完全不同的设计问题，我所见过的几乎每一个生产环境中的 Agent 调度框架在发布时都没有解决这个问题。

智能体最糟糕的两种失败模式看起来截然相反，但它们其实源于同一种失效的策略（Policy）。第一种智能体在执行任何操作前都会先问四个后续问题，这让它的用户因为繁琐而最终放弃使用。第二种智能体从不提问，它自信地生成用户不得不推倒重做的输出，这让它的用户对其产生不信任感。同样的策略，只是一个缺失参数的不同设置：即提问的成本相对于错误答案成本的比例。

大多数智能体根本没有任何策略。模型只是被要求“提供帮助”，然后被留下来独自应对模糊性。因为下一个 Token 预测（next-token prediction）机制奖励对答案的确定性，所以智能体倾向于猜测。又因为 RLHF 奖励礼貌，智能体偶尔会为了安全而过度纠偏并提出问题。其结果就是一种毫无原则的行为，这种行为在不同会话之间波动不定，团队层面也无法直观地判断智能体何时会暂停、何时会盲目推进。

澄清预算（Clarification budget）正是那个缺失的参数。它是针对每个任务制定的、允许智能体施加摩擦力的配额，并配有一套判断何时值得花费预算去提问的决策规则。你可以把它看作是对话领域的“延迟预算（latency budget）”——每个产品都有一个，即使没人把它写下来；而那些把它写下来的团队，就能停止交付那种让人困惑的智能体。

仪表盘显示智能体很快。P50 停留在 1.2 秒，团队开会庆祝，然后放弃率却在持续攀升。没有人关注用户真正体验到的那个图表。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E5%A4%9A%E6%AD%A5%E6%99%BA%E8%83%BD%E4%BD%93%E7%9A%84%E5%BB%B6%E8%BF%9F%E9%A2%84%E7%AE%97%EF%BC%9A%E4%B8%BA%E4%BB%80%E4%B9%88%20P50%20%E4%BC%9A%E8%AF%B4%E8%B0%8E%EF%BC%8C%E8%80%8C%20P99%20%E6%89%8D%E6%98%AF%E7%94%A8%E6%88%B7%E7%9A%84%E7%9C%9F%E5%AE%9E%E6%84%9F%E5%8F%97"]

这是生产环境中多步智能体可靠的失效模式：中位数是你能够达到的指标，而尾部延迟才是你用户感受到的指标。随着你在流水线上不断增加子调用，这两者之间的差距会呈非线性增长。一个包含四个步骤的智能体，即使每一步在“中位数表现”上都很快，其 P99 通常也会比任何单步操作糟糕 6 到 8 倍。用户体验到的不是中位数，而是他们那次特定请求中最慢的一步。

如果你的团队优化了错误的分位线，你交付的系统将拥有出色的基准测试表现和精美的演示效果，但在你从未监测的长尾场景中，用户正不断流失。

“先创建后通知”的序列在开发阶段运行良好。而“先通知后创建”的序列则会为一个尚不存在的实体触发 webhook，导致消费者返回 404，接着你的团队会花上一周时间来调试这个看起来像是不稳定的集成测试。这种不稳定并非随机。它是确定性的，源于你的工具集拥有而你的规划器（planner）却不知晓的隐藏排序不变性。

这就是生产环境中 Agent 工具调用排序 bug 的常见形态：工具集在底层以偏序（partial order）方式组合——某些操作必须先于其他操作执行，而另一些则可以按任意顺序运行——但在规划器看来，它们只是一个无序的能力集合。模型选择了一个昨天行之有效的顺序。而明天，一次提示词修改、模型升级，甚至只是不同的 temperature 采样，都会选出另一个顺序。对于阅读追踪记录（trace）的人来说，这两种顺序看起来都很合理。但其中只有一个是正确的。

如果不声明顺序，团队交付的就是一个最终会被模型的提示词敏感性（prompt sensitivity）触发的 bug 隐患。

大多数团队通过在系统提示词中加入一句话来处理弃权（abstention）问题：“如果你不确定，就说你不知道。”模型偶尔会遵守，但经常不遵守，而且这种失败模式是不对称的。一个自信的错误答案会以全速发布——它直接落入用户手中，在 Slack 讨论串中被引用，在下游摘要中被采纳。而一个诚实的弃权则会触发客户成功（CS）升级，因为用户期望智能体处理请求，而现在必须有人解释为什么它没有处理。六个月后，团队已经了解到哪种失败的发布成本更低，而那个名义上控制弃权的系统提示词修改，已经被悄悄地调整为倾向于顺从，而非诚实。

解决这个问题的准则不是寻找更好的措辞。而是要认识到，弃权是一个路由决策，而不是一种提示词模式。它理应拥有一个一等公民级别的输出通道、自己的 SLO、自己的评估套件，以及在系统拓扑中的独立位置——位于提示词之外，可以被测试、维护和扩展。

当搜索索引失效、供应商 API 对你限流、数据库只读副本出现延迟，或者下游微服务开始返回 503 错误时，你的智能体（agent）必须决定该做什么。在大多数生产环境的智能体系统中，这个决定从未被真正做出。它是被“默默继承”下来的——往往来自于编写工具封装（tool wrapper）的工程师在项目第三周周二下午 4 点随手写下的代码。

其结果就是你的客户最终替你写出的内容：一个 Reddit 帖子、一份客服对话记录，或者是新闻稿中的一段引述。“助手告诉我余额是 0 美元，但其实我的账户没问题——结果发现是他们的查询服务挂了。”那段话就是你的团队没写的降级模式规范。现在它公开了，它属于客户了，而且你的工程部门在接下来的整个季度里都将忙于应对它。

你团队每季度演练的灾备 (DR) 操作手册是为了一套你已经不再完全运行的技术栈编写的。手册上写着：提升从库、重新指向 DNS、清空队列。它假设状态存储在数据库、队列和对象存储中 —— 这些是 SRE 团队已经管理、命名并测试了十年的地方。接着在上个季度，你上线了一个智能体 (agent)。现在，工作内存存在于推理提供商的会话缓存中、工作节点本地磁盘上的草稿文件里、尚未回写的在途工具调用结果中，以及仅存在于单次模型调用提示词历史中的部分“计划-执行”轨迹 (trace) 里。这些都不在资产登记簿上，也不在操作手册里。

当区域宕机时，智能体并不会干净利落地失败，而是处于一种“半完成”的状态。用户看到工作流已经开始，但故障转移后的区域无法恢复进度；客户收到了两次账单，或者根本没收到，因为幂等键存在于已经失效的工作节点上；值班工程师读着 Slack 频道里的讨论，开头是“编排器已启动，但是...”，六小时后以处理信用卡拒付队列告终。

这就是没人点破的鸿沟：智能体特性拥有现有灾备计划未曾描述的状态模型。如果团队还没有记录下这些状态表面，那么只需一次区域性停机，他们就能深刻体会到操作手册的缺失所带来的代价。

周二，客户给支持团队发了一张截图。他们的账户显示六天前有一笔他们从未要求的退款。你的 CRO 转发了这张截图，并问了一个问题：“这是怎么产生的？”你知道是智能体（agent）干的——审计日志显示 actor: refund-agent-v3。但自那以后，提示词（prompt）已经修改了四次。由于财务部门为了追求 12% 的成本削减而更换了供应商，模型 ID 在上周四进行了轮换。系统提示词是根据三个检索到的文档生成的模板，而检索索引在周一重新进行了索引。对话历史被运行时（runtime）裁剪，以适应更小的上下文窗口。

你可以告诉 CRO 是智能体做的。你无法告诉他们为什么。这种差距——即知道发生了某个操作与能够重建导致该操作的输入之间的差距——是大多数智能体团队在工程团队之外的人提出真正的取证问题时发现的。

账单在 3 月份寄达。仅追踪（traces）一项就花费了 8.1 万美元，而 11 月时这一数字仅为 1.2 万美元。团队在 10 月份启用了全量 Agent 追踪，理由是可见性越高越好。到了第一季度，可观测性成本的增速已经超过了推理成本——而当生产环境真正出现性能回归（regression）时，包含故障的追踪记录却被淹没在两千万个无人问津的成功 span 中。

错误并不在于决定进行埋点。错误在于将请求追踪（request-tracing）的心智模型引入了一个行为完全不像传统请求的工作负载中。

一个典型的 Web 请求会生成一个包含少量子节点的 span 树：处理器、数据库调用、缓存查找、下游服务。而一个 Agent 请求生成的树包含 5 个 LLM 调用、3 个工具调用、2 个向量查找、中间草稿（scratchpads），以及一个重新审视其中 3 个步骤的规划器。同样适用于 API 网关的采样策略——头部采样（head-sample）1%，保持其余部分的代表性——在 Agent 场景下会产生一个追踪存储库，其中中位数追踪是拥有 200 个 span 的怪物，长尾效应才是唯一关键的部分，而你发现故障的频率与你花钱的频率完全无关。

在发生第一起涉及六位数损失的智能体（agent）事故后的第二天早晨，董事们不会询问模型是否处于世界领先水平。他们会要求查看风险登记簿（risk register）中列出该场景的那一行、签字的负责人，以及董事会上次审阅该记录的日期。如果你的企业风险登记簿中包含了网络、供应商、监管和运营风险，但唯独没有“自主智能体在我们的凭证下采取了导致客户可见损失的操作”这一行，那么你即将在董事会上花时间解释，为什么其他每一类风险都有的应对方案，在刚刚让你赔钱的这一类风险上却偏偏缺失。

这不再是假设。Gartner 预测，到 2026 年底，企业将面临超过 1000 起因 AI 智能体造成损害而引发的法律诉讼。在短短一年内，AI 相关风险在安联风险指数（Allianz Risk Barometer）中的排名已从第十位跃升至第二位。保险公司现在在董监高责任险（D&O）续保调查问卷中询问：董事会如何将 AI 纳入公司风险登记簿，以及如何跟踪第三方智能体风险敞口。下文列出的项目代表了一个可靠的答案应具备的内容，以及 AI 功能负责人必须据此进行辩护的节奏。

工单上写着 “模型幻觉了一个用户 ID”。分拣标签是 model-quality。修复方案是在系统提示词中多加一句话。六周后，另一个工具开始幻觉日期格式，循环再次开启。一年后，提示词已经演变成一段针对整个后端的 4,000 token 的道歉信，而团队也坚信该模型在工具参数方面就是不可靠的。

模型并非不可靠。模型是一个合约一致性机器，它在阅读你提供给它的合约 —— 而你提供的合约一直在悄悄偏离线路另一端的合约。大多数生产环境中的 “参数幻觉” 并不是模型故障。它们是你的工具描述在默默失败的集成测试，之所以表现为模型输出，是因为这是技术栈中唯一能看到分歧的地方。

一名开发者在 9:00 打开 IDE 的 Copilot，在早会前问了三个问题，然后一直开会到 11:30。聊天面板仍然打开着，对话依然可以滚动查看。模型在两个半小时内没有生成一个 token。然而，这个无人问津的会话整个上午都在悄悄地产生费用。KV 缓存被占用。提示词缓存（Prompt cache）通过定期 ping 保持活跃。对话状态保存在热存储（hot store）中。追踪流水线每跳动一次心跳就写入一行记录。模型提供商预留了并发槽位。乘以一万个席位，这笔账单是真实存在的。

这就是“闲置智能体税”（idle agent tax）。它是你推理预算的一部分，用于支付用户并未使用的容量。由于大多数工程仪表盘是为无状态 API 构建的，因此它在仪表盘上是不可见的。一个请求进来，一个响应出去，容器关闭。搞定。智能体产品在两年前就打破了这一模型，而大多数团队尚未根据这一变化重新调整其架构的成本模型。