183 篇博文 含有标签「observability」

团队向 AI 工作流添加人工审批的方式，与他们在代码库中添加 if (isDangerous) requireHumanApproval() 的方式如出一辙：将其视为一个二进制开关，在设计时检查一次，然后便将其遗忘。架构图上的指标是“人工监督”旁边的一个绿色对勾。而真正重要的指标——人工花费了多长时间、他们是否阅读了任何内容、在点击批准时该条目是否仍然相关——却很少有对应的仪表板。

将人工审批者视为二进制开关，你就等于在不知不觉中构建了一个队列。而队列具有动态特性：积压量的增长速度超过了你的员工配置速度、陈旧性使昨天的决定变得毫无意义、疲劳让审查变成了“走过场”（rubber-stamping），以及优先级倒置让真正重要的那一个决策被排在三百个无关紧要的决策之后。架构图中看不到这些，但它们都会出现在事故回顾（incident retro）中。

你的仪表板很干净。昨天的部署也已干净地回滚。模型版本已锁定。提示词没有更改。但你的 TTFT p99 刚刚翻了一倍，客户成功渠道已经炸锅了，而你唯一能给出的诚实回答是“这是提供商的问题”。这个答案显得很苍白——就像耸耸肩一样——它通常会引出一个团队中没人能回答的后续问题：证明它。

这是托管 LLM 推理中营销页面不会讨论的部分。当你调用前沿模型 API 时，你正在与你看不见的负载共享 GPU、PCIe 结构、连续批处理和 KV 缓存预算。你的 p99 是这些负载突发的函数。大规模推理的经济性取决于租户的多路复用是否足够紧密，以使硬件利用率保持在 60-70% 以上，这意味着你的尾部延迟在结构上与同一分片上最大、最不规整、最不稳定的租户耦合。你购买的不是容量；你购买的是一个别人也排在其中的队列切片。

打开任何 2024 年时代的 AI 功能链路追踪 (trace)，模型调用就像是一头巨鲸。八百毫秒的生成时间，包裹在检索、鉴权和数据库查询组成的薄壳中，后者的时间几乎可以忽略不计。那一年的每一个架构决策——缓存、预取、流式 UX——都是为了隐藏那头“巨鲸”。

现在，查看运行在 2026 年推理栈上的相同功能的链路追踪。那头巨鲸已经变成了一只海豚。缓存后的预填充 (prefill) 在 180ms 内返回第一个 token。解码 (decode) 以每秒 120 个 token 的速度流式传输。模型不再是慢节点。你自己的基础设施才是，而且大部分基础设施还没有意识到这一点。

这种顺序重排是今年最重要的性能转变，也是各团队一直反应不足的一个。现在，AI 请求的 p99 底限是由特征存储 (feature store) 调用、鉴权中间件以及那些一直都很慢的 Postgres 查询决定的——在模型占据九成预算时，没人关心这些。

一个在提示词未发生任何更改的情况下，测试结果由绿转红的回归测试套件，通常源于以下三种情况之一：测试框架损坏、检索库不稳定，或者评估模型（Judge）在周末学习了“新口味”。第三种情况最常见，也最难调试，因为你的代码仓库里没有任何提交记录与之相关。评分模型在静默状态下完成了质量更新，你与上个月仪表盘对比的所有分数，现在都已经是在用另一种“货币”计价了。

这是 LLM-as-judge 令人不安的地方：你有两个处于变动中的模型，而不仅仅是一个。待测模型（Candidate Model）是你发布的产物；评估模型（Judge Model）则是告诉你待测模型表现如何的工具。当两者独立演进时，分数的变化量（Score Deltas）不再具有以往的含义，你家产品经理每天早上刷新的仪表盘正在悄悄地撒谎。

你的 LLM 调用耗时 2,340 毫秒。你的 APM Span 是这么记录的。这个数字是你可观测性堆栈中最昂贵的谎言，因为四种完全不同的故障模式都被渲染成了同一个不透明的紫色条块。长提示词下的 Prefill（预填充）浪涌。一个一小时没访问的租户导致的冷 KV 缓存。提供商连续批处理（continuous batching）中的“吵闹邻居”。一次无声的路由变更将你的流量导向了不同的区域。同样的 Span。同样的耗时。同样的 p99 告警。却是四个截然不同的复盘分析。

适用于微服务的分布式追踪准则 —— 每个网络跳数一个 Span、一个时长、几个标签 —— 在面对托管推理时失效了。LLM 调用并非单一实体。它是一个由多个阶段组成的流水线，每个阶段都有截然不同的扩展特性，运行在行为取决于队列中其他人的共享硬件上。将其视为一个单一且不透明的 Span，会导致你花费三天时间去调试“模型变慢了”，而实际上模型根本没变。

你的智能体在评估测试集上达到了 94% 的准确率。然而你的轮值告警却响个不停。房间里没人撒谎，这两个数字都是真实的。实际情况是，测试框架（harness）在测试提示词（prompt），而生产环境在测试智能体（agent），这是两个完全不同的产物，只是恰好共享了权重。

Mock 工具的评估通常是产生这种差距的原因。你用预设的 JSON 存根（stub）了 search_orders、charge_card 和 send_email，给模型输入一个用户回合，并对最终响应进行断言。这种运行方式成本低、具有确定性且可复现——这些都是 CI 系统喜欢的特性。但它对工具选择、延迟、速率限制（rate limits）、部分失败和重试行为保持沉默，也就是说，它忽略了那些在事故回顾中占主导地位的失败因素。

一家中型 AI 公司的财务负责人在上个季度告诉我，他们通过将 Agent 骨干模型从 Sonnet 切换到 Haiku，“优化了他们的 LLM 支出”。Token 账单下降了 22%，而每个已解决工单的总推理成本仅下降了 4%。当我们进行完整的成本拆解时发现，模型这一项支出大约仅占单次请求成本的三分之一。检索、重排序（reranking）、可观测性、重试放大以及人工介入（human-in-the-loop）审核队列吃掉了剩下的部分——而且当你更换模型时，这些环节都没有变得更便宜。

这是我目前在 AI 团队中看到的最常见的财务核算错误。Token 成本是你每月支付的发票上的分项，因此它成了每个人都在优化的数字。但对于任何非平凡的生产系统——RAG、Agent、任何带有工具调用或评估门控的系统——模型推理往往只占实际单位经济效益的 30% 到 50%。剩下的部分隐藏在你的工程仪表盘不会显示、且财务团队不会将其归类为 “AI 支出”的地方。

智能体（Agent）打印了一个五步计划。第三步是“从发票服务中获取用户的账单历史”。追踪链路（Trace）显示，第三步实际上调用了订单服务，关联了一个过时的客户表，并产生了一个看起来正确的数字。输出通过了评估（Eval）。六个月后，财务部门发现仪表盘与事实源（Source-of-truth）悄然出现了 4% 的偏差，复盘时才发现了这次回归（Regression）。

没有人写出 Bug。规划器（Planner）写下了一份执行器（Executor）从未签署的契约。

这就是“计划与执行”架构在其优雅的架构之下所掩盖的失败模式。这种模式被推销为一种赋予智能体长程连贯性的方式：由一个强大的模型起草计划，较弱的模型执行步骤，计划起到脚手架的作用。在实践中，计划只是一种“营销产物”——在 t=0 时发出的一个看起来合理的预告，随后在 t>0 时发生的每一件趣事都会迅速令其失效。追踪链路显示了计划，追踪链路也显示了行动。但几乎没有人去衡量两者之间的距离。

错误报告显示服务很慢。仪表板显示服务很健康。每分钟 Token 使用量处于层级上限的 62%，稳稳处于绿色安全范围内。然后你打开追踪（traces）查看形态：一个用户请求生成了一个规划步骤，该步骤发出了 11 个并行工具调用，其中 4 个是搜索扇出，每个都触发了子智能体，而这些子智能体又分别并行调用了 3 个工具——那个单一的“请求”现在正同时从 47 个不同的工作线程猛击你自己的 Token 桶。产品的其他 99 名用户被堵在它后面，收到了他们本不该得到的 429 错误。你的智能体正在对自己发起 DoS 攻击，而速率限制器（rate limiter）正在忠实执行你给它的指令。

这就是速率限制层级崩塌。你购买了为 HTTP API 设计的边界防御系统，在那样的系统中，一个请求等于一个工作单元；然后你把它连接到一个请求意味着深度未知且分支因子无界的树形系统前端。单一桶模型不仅无法提供保护，而且它的失败是隐形的，因为你的聚合数据从未突破任何限制。损害发生在尾部、相关的爆发中，以及那些恰好在时间上紧邻重度请求的专注用户身上。

在值班文档的表格上，搜索工具的错误率为 2%。事故审查报告称，在三个小时的时间窗口内，Agent 平台的故障率为 20%。没人对这两个数字有异议。搜索团队没有过错。平台团队也没有发布 Bug。这两个数字之间的差距就是故事的全部，而这是一个关于算术的故事，而不是工程能力的平庸。

重试逻辑是 Agent 系统中最常被借用且最少针对性调整的模式之一。团队从他们的 REST 客户端复制 tenacity 装饰器，将它们堆叠在 SDK、网关和 Agent 循环中，然后直接上线。每一层单独看都是合理的。但这种组合就像是一件指向集群中最不稳定依赖项的攻城武器，而且它恰恰在那个依赖项最需要降低负载的时刻开火最猛烈。

本篇文章将探讨这种数学逻辑是如何运作的，为什么 Agent 循环比请求-响应系统更剧烈地放大错误，以及如何通过重试规范防止瞬时波动演变成印着你自己公司 Logo 的关联性宕机事故。

你团队每个周一盯着看的调试语料库并不是生产环境的代表性样本。它具有明显的偏差，而且偏差的方向完全错误。1% 的头部采样在保留一个罕见的灾难性轨迹之前，会先保留一百次中位数请求——大多数团队只有在某种静默循环了数月的失败模式最终导致退款或停机，并试图在追踪存储（trace store）中寻找示例却一无所获时，才会发现这一点。

这并不是什么罕见的边缘情况。这是所有专为无状态 Web 服务设计、随后又被用于长时程（long-horizon）Agent 的可观测性栈的默认行为。同样的采样算法在处理 HTTP 请求追踪时表现良好，但在处理 Agent 时却会系统性地抹除那些最重要的轨迹——因为在这里，每个“请求”都是一个包含三十个步骤的计划，可能会调用数十个工具，重新生成三个子计划，并在第 27 步发生细微错误之前消耗数万个 token。

解决方法不是“增加采样”。增加采样只会让账单爆炸，而不会改变偏差——你只会得到更多已经过剩的普通数据。解决方法是改变你采样的对象，以只有在轨迹结束后才能获知的预测结果为基准。这需要抛弃基于头部的默认设置，并围绕尾部信号、异常权重以及能在 Agent 执行的长尾效应中存续的有界蓄水池（bounded reservoirs）重新构建保留层。

你技术栈中最灵敏的泄露信号并不在 SIEM 中。它隐藏在财务人员月初打开的一份电子表格里。当攻击者窃取了 LLM API 密钥、利用提示词注入（prompt injection）窃取数据，或者通过被入侵的租户会话查询相邻客户的内存时，痕迹首先会表现为 Token 使用异常——这远在任何 DLP 规则触发、任何身份验证警报响起或任何终端代理察觉到异常之前。财务看到了，而安全部门却没看到。

这种差距并非理论上的。Sysdig 的威胁研究团队在观察到攻击者利用窃取的云凭据产生每日五位数的账单后，创造了“LLMjacking”一词。这一类别现已演变成一个有组织的犯罪产业，出现了每个账号 30 美元的交易市场，且有记录显示某些活动让受害者的损失每天超过 100,000 美元。OWASP 记录了一家初创公司因为密钥泄露，在 48 小时内产生了 200,000 美元的账单。斯坦福大学的一个研究小组由于在 Jupyter notebook 中遗忘了一个 Token，在 12 小时内烧掉了 9,200 美元。所有这些事件的共同点是：在安全团队察觉之前，账单图表就已经在几个小时甚至几天前揭示了真相。