161 篇博文 含有标签「observability」

你的 Datadog 仪表盘一片绿色。Jaeger 链路看起来干净整洁。P99 延迟符合 SLA。而你的 Agent 流水线正在悄无声息地因重试死循环每天烧掉 4000 美元，却没有触发任何一条报错。

传统 APM 工具是为微服务设计的——确定性路径、有界载荷、可预测的扇出。Agent 流水线打破了所有这些假设。执行路径在运行时才能确定。工具调用深度变化剧烈。一次"请求"可能跨数分钟产生数十次 LLM 调用。而当出了问题，失败模式通常不是异常——而是一个悄然膨胀成本和延迟、却返回看似正常输出的静默重试级联。

结果是一代工程师在盲目飞行，信任着那些衡量错误事物的仪表盘。

大多数团队能把单智能体的可观测性做得足够好——加上链路追踪、统计 Token 用量、设置错误率告警。然后他们把并发智能体扩展到一百个，才发现整个监控体系一直在盯错方向。

摧毁集群的问题，并不是摧毁单个智能体的那些问题。一个陷入递归推理循环的智能体可以在一小时内烧光一个月的 API 预算。模型服务商悄无声息的质量降级，会让集群里的每一个智能体同时以满满的自信给出错误答案——而你的基础设施仪表盘依然一片绿灯。这些故障不会出现在延迟图表或 HTTP 错误率中，因为它们根本不是基础设施故障，而是语义层面的失效。

大多数生产环境中的 AI 失败都是“响亮”的。模型返回 5xx 错误。模式验证抛出异常。评估套件在发布前捕获了回归。但还有一类失败是完全无声的——没有错误，没有异常，没有警报触发——因为系统正完全按照设计运行。它只是在处理一个来自 18 个月前的现实快照。

你的 LLM 存在知识截止日期（Knowledge Cutoff）。这个截止日期不仅仅是文档中的一个脚注。它是模型认知的真实情况与实际现实之间日益扩大的鸿沟，而且你每在生产环境中多运行一天旧模型，这种差距就会累积。团队庆祝上线，随后眼睁睁看着用户信任在接下来的六个月里悄然瓦解——世界在前进，而模型却停滞不前。

你的单次请求错误率看起来很正常。延迟在 SLO 范围内。LLM 裁判对输出的评分是 87%。接着，一位用户提交了支持工单：“我把账号告诉了机器人三次，它却一直重复问我。”另一位用户说：“它先是同意退款，两轮对话后又否认该政策的存在。”

单轮失败是显而易见的。请求进来，模型出现幻觉或拒绝回答，你的评估 (eval) 捕捉到了它，然后你修复提示词。反馈循环很紧密。多轮失败则完全不同：会话开始时表现良好，随后逐轮恶化，而你的监控从未报警，因为每个单独的回复在技术上都是连贯的。问题出在整个会话上——而几乎没有团队为此建立观测机制。

对主要前沿模型（Claude 3.7 Sonnet、GPT-4.1、Gemini 2.5 Pro）的研究显示，从单轮转向多轮对话时，平均性能会下降 39%。这个数字掩盖了真相：只有大约 16% 的下降是由于能力损失。另外 23 个百分点则是一场可靠性危机——随着对话长度增加，模型在同一任务上的最佳表现与最差表现之间的差距翻了一番。你得到的不仅是质量更差的输出，还有极不稳定的输出。

你的监控显示一切正常。延迟处于正常水平。错误率平稳。然而，你的客服 AI 刚刚告诉 10,000 名用户退货是免费的——且是永久免费——而这根本不是公司的政策。没有触发任何报警。没有进行任何部署。模型只是自己决定这么做了。

这就是 AI 系统轮值（on-call）的现状：这类生产环境故障不会触发你构建的报警，无法追溯到某行代码，也无法通过回滚上一次部署来修复。标准的事件响应手册——检查日志、确定提交（commit）、回滚更改、验证恢复——是为确定性系统设计的。应用到 LLM 时，它们完全无法捕捉到真正的失败模式。

以下是真正有效的方法。

你的 p99 延迟刚刚飙升到了 12 秒。警报在凌晨 3:14 响起。你打开运维手册 (runbook)，看到如下指令：检查数据库连接池、验证负载均衡器、重启服务。你三样都做了。延迟依然居高不下。服务并没有宕机——它正在运行且有响应。但有些地方不对劲。事实证明，由于最近的一次提示词 (prompt) 变更无意中开启了“啰嗦”模式，模型生成的响应比平时长了三倍。运维手册里没有关于这一条的说明。

这是工程团队尚未准备好应对的新一类值班事故：系统正在运行，但模型表现异常。传统的 SRE 运维手册假设的是二进制的故障状态。AI 系统是以概率方式失效的，其症状看起来不像停机，而更像“漂移”(drift)。

2025 年 4 月，全球使用最广泛的 AI 产品之一更新了系统提示词。错误率保持平稳。延迟表现正常。部署仪表盘显示一切正常。然而在三天内，数百万用户发现了一些严重的问题：模型变得异常谄媚，附和错误的想法，验证糟糕的推理，并对用户说的任何话都表现出虚假的热情。回滚公告发布时，该事件已经席卷社交媒体，用户纷纷晒出截图作为证据。在一段时间内，Twitter 成了生产告警系统。

当你把提示词和模型的变更当作配置更新，而不是行为部署时，就会发生这种情况。那些在代码金丝雀基础设施上投入多年的团队，却仍在以单一原子级切换的方式发布 AI 变更——瞬间全球化、瞬间不可逆，没有分级发布，除了用户投诉外也没有自动回滚信号。

LLM 行为的金丝雀部署并非可有可无。它是缺失的基础设施层，区分了那些能在内部捕捉退化的团队，和那些只能通过支持工单发现问题的团队。

在生产环境中运行一百个 agent 感觉还可以管理。你有追踪数据，有仪表盘，知道什么时候出问题。但运行一千个并发 agent 完全是另一个问题——不是因为 agent 更复杂，而是因为你为十个 agent 建立的监控模型在你注意到之前就已经悄然失效了。

失败模式很微妙。一切看起来都很正常。你的 span 树都在。错误率很低。然后，一个导致 40% 会话输出质量下降长达六小时的提示词回归，只因为客户投诉才浮出水面——而不是被你的可观测性系统捕获。

这就是仪表盘盲区问题：单 agent 追踪在小规模下运行良好，在集群规模下则会悄然失效。以下是它发生的原因及应对之道。

你的链路追踪仪表盘显示 Agent 为了响应用户请求发起了 8 次调用。但实际上，它发起了 47 次。你的头部采样器（Head-based sampler）静默地丢弃了其中的大部分。你保留下来的那些调用在技术上是正确的，但在因果关系上毫无用处——它们是从被父级采样器丢弃的根节点中孤立出来的子 Span。

这并不是可视化层面的 Bug。它是将专为 10 个 Span 的 HTTP 扇出设计的分布式链路追踪基础设施，强行套用到每轮对话生成数百个 Span 的系统上的必然结果。默认的 OpenTelemetry 配置系统性地低估了 Agent 的工作量，而运行这些 Agent 的团队通常直到客户抱怨链路追踪视图中显示“不存在”的延迟时，才会察觉到问题。

AIOps 供应商圈子里没人愿意宣传的悖论是：投入超过 100 万美元用于故障响应 AI 工具的组织，其运维负担占工程工时的比例反而从 25% 上升到了 30%——这是五年来的首次增长。团队本以为自动化能替代手工劳动，结果却多出了一项新工作：在执行 AI 建议之前先验证它说的是否正确。旧的任务没有消失，反而在上面又叠加了一层验证层。

这并不是反对在故障响应中使用 AI 的论点。同样的数据显示，当 AI 被妥善整合时，平均故障解决时间（MTTR）可降低 40%，部分团队报告将排查时间从两小时缩短到了三十分钟以内。这里要表达的论点更为精准：AI 副驾驶的故障模式在性质上与传统 SRE 工具的故障模式截然不同，而大多数团队还没有做好识别这些故障的准备。

这里有一个令人不安的模式：你的团队计划在下个季度推出的 AI 功能，其实早在两年前就在公司里“死”过一次了。它当时以不同的名称发布，带着不同的提示词（prompt），解决一个略有不同的问题，并在经历了六个月的增长停滞后被悄然关停。没有人记录它，没有人把这些点串联起来。本可以拯救这个周期的领先指标，一直躺在那些随功能一起被归档的数据看板里。

大多数工程组织都是为了记住成功而设计的精妙机器。发布会有复盘、博客文章和内部庆祝。但那些被砍掉的功能——尽管有精美的演示，但周活跃用户仅为 12% 的功能；当 Token 成本在超预期的工具链中叠加时导致单位经济效益倒挂的功能；那些用户先是学会信任、随后失去信心、最后完全绕开的功能——几乎没有留下任何组织记忆。而这些“死亡”中蕴含的失败模式，恰恰是你的规划流程无法预估并纳入成本的。

一个法律团队的 AI 研究助手伪造了三个案例引用，并将它们混入了法庭文件中。这些引用看起来非常可信 —— 真实的法院、听起来很真实的案例名称、连贯的判决理由。在提交摘要之前，没有人发现它们。这一事件导致律所面临紧急听证会、公开道歉以及律师协会的调查。

那是 Sev-0 还是 Sev-2？答案取决于你使用的框架 —— 而传统的严重程度模型几乎每次都会给你错误的答案。

软件事故严重程度分类是为确定性系统构建的。服务要么有响应，要么没有。数据库查询要么成功，要么抛出错误。失败模式是二进制的，责任可以追溯到某个 commit，而修复方案则是回滚或补丁。AI 系统同时打破了这三个假设，如果组织将传统的严重程度框架应用于 LLM 故障，最终要么是对噪声感到恐慌，要么是将结构性故障视为偶然的异常。