348 篇博文 含有标签「observability」

你的 LLM API 调用在 P99 分位下于 500 毫秒内完成。但你的用户却在等待 12 秒。这两个数字都是准确的，谁都没有撒谎——它们只是在测量完全不同的东西。两者之间的差距正是大多数 Agent 系统性能无声流失的地方，而且大多数团队从未对其进行过监控（instrumentation）。

问题是结构性的：P99 LLM 延迟是一个应用于多步执行模型的单次调用指标。一个 ReAct Agent 进行五次连续的工具调用、重试一个幻觉化的函数、组装不断增长的上下文并生成 300 个 token 的推理链，这并不是一次 LLM 调用。这是一个分布式工作流，其中 LLM 只是一个节点，而其他每个节点都有其自身的延迟开销。

当你的 AI 功能输出错误答案时，第一个问题总是：“是模型的问题吗？”大多数工程师会进行模型评估，运行几个测试提示词，并得出模型看起来没问题的结论。他们通常是对的。模型没问题。故障发生在其他地方——在你的组件相互通信的那些无形接缝处。

这一结论的证据是一致的。对生产环境 RAG 部署的分析显示，73% 的故障是检索故障，而不是生成故障。在多智能体系统中，最常见的故障模式是消息顺序冲突、状态同步间隙和 schema 不匹配——这些都不会出现在任何单组件健康检查中。GPT-4 在处理复杂的提取任务时，产生无效响应的比例接近 12%，这不是因为模型坏了，而是因为模型与下游解析器之间的输出格式契约从未被强制执行。

模型背了锅，边界才是元凶。

季度开始三周后，生产告警触发了。核心任务的准确率下降了八个百分点。你打开仪表盘，立即注意到同一个发布窗口内落地了三件事：上下文长度从 8k 增加到 32k token、模型版本从 gpt-4-turbo-preview 升级到 gpt-4o，以及基础设施团队为提升吞吐量推送的批处理大小变更。三项变更中没有一项单独被认为是高风险的。合在一起，它们制造了一个无法干净解决的调试难题。

欢迎来到发布顺序问题。

用户报告说助手在上午 9:47 给了他们一个错误答案。你打开 Trace。这里有 340 个 Span。它们几乎都被命名为 agent.run、llm.invoke 或 tool.call。有些有父节点，有些是兄弟节点。其中三个进行了重试，一个重试后被取消了。没有一个能告诉你错误的输出是来自 Planner、Worker、Critic、Reflection 过程，还是在 Critic 标记后 Worker 的第二次重试。

在接下来的一个小时里，你根据截图中的 UUID 前缀搜索日志行，比对 Slack 通知的时间戳，并根据 Trace 查看器中的缩进模式在脑海中重建 Agent 拓扑。最终，你猜想第三次 Worker 调用使用的模型别名在昨晚被静默切换到了另一个快照。但你无法仅凭 Trace 证明这一点。

Agent 正常运行，Trace 完整无缺。杂乱无章的 Trace 团（Hairball）本身就是 Bug。

AI 功能拥有仪表板。提示词（Prompt）有版本控制。评估套件（Eval suite）有轮值表。然后是一个写于 2022 年的上游定时任务（cron job），由一个在两次重组前就退出了分析部门的团队负责，它生成了构建你的检索索引所需的 CSV 文件。那个定时任务没有 SLA。那个 CSV 没有 Schema 契约。负责它的团队根本不知道它正在为一个 AI 功能提供数据。当它发生变化时——它一定会变——AI 团队将花费三周时间去调试一个完全没有出错的提示词。

你即将追踪的 AI 质量回退几乎从来不是 AI 问题。它是一个穿着 AI 外衣的 ETL 问题。需要落实的规范是两者之间的衔接点——契约、血缘（lineage）、新鲜度信号、成对的轮值——而没有将其正式化的团队，所交付的 AI 功能的可靠性将受限于公司里最不受待见的定时任务。

为期两周的金丝雀发布（canary）是那种听起来足够自律，以至于让人可以跳过更难问题的实践之一。工程团队从微服务中引入了它——逐步放量 1% 几天，观察错误率，放量到 100%，宣布完成——并将它嫁接到 AI 功能上，却没问过 AI 特有的失效模式是否会在两周内显现。它们不会。扼杀该功能的账单在第六周才寄到。暴露出长尾意图的客户群体在第五周才开始使用。上线当天评分提升 3% 的评估偏移（eval drift）在第四周开始产生真金白银的损失，因为新 prompt 产生的更冗长的输出一直在累积 Token 开销，而由于仪表盘只盯着崩溃，没人注意到这一点。

一个围绕 p95 延迟和 HTTP 500 错误构建的金丝雀发布会告诉你 LLM 运行正常。它不会告诉你该功能是否有效。AI 功能失效的形式是部署仪式从未设计去捕捉的——用户行为的缓慢变化、缓存的逐渐侵蚀、检索质量的崩溃、拒绝率的攀升、以及走向错误的成本轨迹——而且几乎所有这些都需要两周以上的时间才能显现。按微服务时钟发版的团队，其发版节奏与失效发生的节奏并不匹配。

一个用于市场数据研究的多智能体系统在无人察觉的情况下，在四周内悄悄烧掉了 47,000 美元的推理成本。原本的每周账单仅为 127 美元。原因既不是流量激增，也不是模型升级——而是两个智能体在十一天里来回传递同一个对话，每个智能体都确信对方才是处理该请求的正确位置。没有任何报错。没有任何警报触发。一个机器人的“队列已转移”指标和另一个机器人的“任务已接收”指标都在同步增长，两边的仪表盘看起来都很健康。

这就是闭环升级漏洞 (closed-loop escalation bug)。它是两个热心的同事互相坚持“不，你来处理”的多智能体版本，只不过他们谁都不会感到厌烦并走开。你在设计时画的架构图中，每个专业智能体都拥有一块清晰的问题领域。而运行时实际执行的架构却包含了一个房间里没人能看到的路由循环。

用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。

这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。

你的评估流水线分数在稳步上升。响应质量在持续改善。LLM 评判者（LLM judge）捕获到了更多劣质输出。仪表盘一片绿色。

与此同时，支持工单零星涌来："助手老是给我冗长正式的回答，我只是随口问了个简单的问题。"紧接着又来了一条："它不再主动给出下一步建议了，以前会的。"然后你们的产品经理给你看了一张图表：上个季度用户满意度下跌了 12%，而这段时间，恰恰与你自动化评估指标爬升最快的那段时期高度吻合。

这就是评估自动化陷阱。你的度量体系开始为自身的优化而服务，而非为用户真正看重的事情服务 —— 由于整个反馈循环完全自动化，没有人察觉到问题，直到伤害已经落地生产。

AI 功能上线后的 Bug 数量并非质量问题。它是一个发现序列——一个非常可预测的序列，以至于你可以在发布公告发布之前，在白板上逐周、逐个工单地勾勒出来，并且在仪表盘数据跟上时，你会发现自己预测得惊人地准确。每个上线 AI 功能的团队都会经历这个序列。唯一的选择是，你是带着操作手册（runbook）去执行，还是通过一系列临时的紧急会议来应对。

我已经观察了足够多的发布，足以相信这个序列实际上与工程质量无关。它关乎信息差。发布前，团队拥有合成流量组合、精选的评测集（eval set）、理想路径的演示和董事会演示文稿。发布后，真实用户带着合成流量从未模拟过的意图蜂拥而至，市场团队开展了工程团队仅略有耳闻的营销活动，模型提供商发布了未经团队授权的更改，而隐私审查员在功能上线时正在休假。下面的序列就是当这两个世界碰撞时产生的摩擦。

我的团队第一次发现我们依赖的模型即将退役时，是从客户那里得知的。弃用通知邮件躺在一个被三名工程师退订了的共享收件箱里。提供商的状态页上挂着横幅。Webhook 事件发射到了虚空中，因为我们从未配置过接收端。60 天的预警时间，被我们浪费成了 0 天，最终以一场停机事故和塞满“紧急迁移”同步会的日程表收场。

我交流过的大多数团队目前都处于这种状态，只是他们自己并不知道。每个主流 LLM 提供商都在悄悄构建通知层面 —— 针对故障的 Webhook、变更日志中的弃用事件、通过电子邮件发送的账户警告、账单异常提醒、区域故障转移信号 —— 而大多数团队要么禁用了这些功能，要么将其路由到了一个没人看的邮件列表。提供商一直在提前告诉你坏消息。是你选择不去听。

我上个季度交流过的一个团队，他们的所有仪表盘都显示绿色。工具错误率稳定在 0.3%。端到端成功率为 98%。SLO 预算几乎没动过。但他们的 Token 支出却是预计的四倍，而且没人能解释原因。当他们最终对每个 Trace 的重试深度进行埋点时，情况发生了反转：成功请求的中值实际上进行了 2.7 次工具调用，而不是架构图里承诺的 1.0 次。智能体（Agent）并没有失败。它是在同一个 Span 内部不断失败又不断恢复，而成功率指标根本无法体现这一点。

这是传统可靠性词汇无法涵盖的智能体可靠性部分。MTBF（平均故障间隔时间）假设故障是断续的、可观测的事件，你可以在两次故障之间进行计数。你测量间隔，计算平均值，并在间隔缩短时发出警报。这对于硬盘、网络和确定性服务都很有效。但对于那些在单个用户可见的操作内部进行重试、重定向、降级并静默恢复的系统来说，它失效了。