233 篇博文 含有标签「observability」

你的仪表板显示全绿。延迟处于正常水平。错误率为 0.2%。本月正常运行时间为 99.97%。然而，你的 AI 助手正自信地向用户提供错误的信息，格式不对，长度是预期的两倍——而且这种情况已经持续了 11 天。

这就是 SLA 幻觉：基础设施合同保障的是管道，而不是其中流过的水。对于 AI 驱动的功能，“它是否有响应？”与“它的响应是否准确？”之间的差距，正是产品质量悄然崩塌的地方。

2025 年，自动化互联网流量同比增长了 23.5%，是人类流量增速的八倍。其中，agent 驱动的交互增长了 7851%。如果你的产品处理了相当体量的 API 流量，那你的最重度"用户"很可能根本不是人类。而令人不安的事实是：你的产品分析系统对此几乎一无所知。

这不是一个机器人检测问题，而是一个埋点架构问题。当 AI agent 预订差旅、提交费用报告、查询数据库或调用你的支付 API 时，它留下的行为特征与人类完全不同——而你的会话漏斗、NPS 问卷和队列留存图，正在悄悄对你撒谎。

一个客服 Agent 在 12% 的工单中生成了幻觉式的故障排查步骤。HTTP 日志全部显示 200 OK。延迟正常。错误率平稳。从每一项传统指标来看，系统都是健康的——但它却在大规模地悄悄捏造答案。

当工程师最终对决策层进行插桩后，根本原因在几分钟内便浮出水面：检索到的文档块相似度得分全部低于 0.4，对上下文的置信度为 0.28，而模型输出的置信度却显示为 0.91。这是一个巨大的不匹配——在传统日志中完全不可见，但在捕获了决策状态的追踪中一目了然。

这就是将传统日志应用于 LLM 系统时的根本问题。I/O 日志告诉你系统运行了。AI 原生日志告诉你它是否推理正确。

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

一个 AI 系统将某份求职申请标记为低优先级。候选人提出申诉。法务部门向工程团队询问："请展示模型当时看到的确切内容、检索的文档、触发的策略规则以及生成的置信度分数。"工程师打开日志，发现的是：时间戳、HTTP 200、响应体，以及延迟指标。其余的信息已经消失。

这不是日志记录的失败。按照所有传统标准，日志是完整的。问题在于，应用日志从来就不是为记录推理过程而设计的——而 AI 系统不只是在执行代码，它们做出的是依赖上下文的概率性决策，只有给定决策时刻存在的完整输入上下文，才能被理解。

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