86 篇博文 含有标签「observability」

一家金融科技创业公司的多智能体成本追踪系统在没人察觉的情况下运行了 11 天。原因是：智能体 A 向智能体 B 寻求澄清，智能体 B 向智能体 A 寻求帮助以解释回复。两者都没有打破循环的逻辑。在人类查看发票之前，每周 127 美元的账单变成了 47,000 美元。

没有抛出错误，没有触发告警，延迟也正常。系统正完全按照设计运行——只是在永远运行下去。

这就是 AI 事故真实的样子。它们不是堆栈跟踪和 500 错误。它们是无声的行为失效、失控的循环，以及在生产规模下以十足信心交付的似是而非的错误答案。你现有的故障响应手册几乎肯定没有涵盖其中的任何一种。

你的 AI 智能体完成了任务。日志中没有错误。延迟看起来很正常。输出是格式良好的 JSON，语法完美的散文，或者是执行起来毫无怨言的有效 SQL 查询。仪表盘上的每一个指标都是绿色的。

而用户盯着结果，叹了口气，然后从头开始。

这就是语义失效模式 —— 这类生产环境中的 AI 失败表现为：系统运行正常，模型自信地响应，输出按时交付，但智能体并没有做用户真正需要的事情。传统的错误监控对这些失败完全视而不见，因为并没有报错。HTTP 状态码是 200。模型没有拒绝。输出符合 Schema。从每一项技术指标来看，系统都成功了。

你的生产系统运行正常。可用性为 99.9%。延迟处于正常水平。错误率告警为零。然后一个用户提交了一个工单：“最近的摘要变得莫名其妙地偏差。”你调取日志，一切看起来都没问题。你检查模型版本 —— 还是三个月前部署的那个。到底发生了什么变化？

是模型提供商变了。而且是悄无声息地变了。

这就是模型升级陷阱：基础模型在你不知情的情况下发生了变化，而标准的观测基础设施对这种行为偏移（behavioral drift）完全视而不见。等到用户注意到时，性能下降已经持续累积数周了。

你的 Datadog 仪表板显示 99.4% 的在线率，低于 500ms 的 P95 延迟，以及 0.1% 的错误率。一切都是绿色的。与此同时，你的支持队列却充满了抱怨 AI 给出了完全错误答案的用户。你毫无头绪，因为每个请求都返回了 HTTP 200。

这是传统可观测性与你在 LLM 系统中真正需要的可观测性之间的本质区别。语言模型可能会以标准 APM 工具无法留下痕迹的方式发生故障：幻觉事实、从错误的产品版本中检索文档、在代码更改修改了系统提示词后将其忽略，或者在模型更新后对特定查询类型静默降级。在你的延迟图表上，这些看起来都一切正常。

大多数将 LLM 应用推向生产环境的团队，其日志设置常被误认为是可观测性。他们在数据库中存储提示词（prompt）和响应，在表格中跟踪 token 数量，并在 Datadog 中设置延迟告警。然而，当用户反馈聊天机器人已经连续两天给出错误回答时，没人能告诉你原因 —— 因为收集到的数据都没有告诉你模型是否真的正确。

传统监控回答的是“系统是否在线且速度多快？”而 LLM 可观测性回答的是一个更难的问题：“系统是否在做它应该做的事情，以及它在什么时候停止了这种正常行为？”当你的系统行为是概率性的、依赖上下文的，并且经常以不触发任何告警的方式出错时，这种区别就显得至关重要。

你的团队花了三周时间构建了一个严谨的评估套件。它涵盖了各种边缘情况，包括对抗性示例。LLM 作为评测员（LLM-as-judge）在所有维度上的得分都达到了 92%。你发布了产品。

接着，客服工单接踵而至。用户反馈 AI “听不懂他们在问什么”。会话放弃率上升了 30%。满意度得分仅为 41%。

这种差距 —— 即评估表现与现实世界结果之间的鸿沟 —— 是当今生产级 AI 系统最常见的失败模式。这不是模型问题，而是衡量标准的问题。

大多数构建 AI Agent 的团队都犯了同样的错误：在没有证据表明需要复杂架构之前就过度设计。对 47 个 Agent 部署案例的生产分析发现，68% 的案例如果使用设计良好的单 Agent 系统，会获得相同甚至更好的结果。多 Agent 税——更高的延迟、复合的故障模式、运维复杂度——往往在用户感知到收益之前就将其消耗殆尽。

这并不是在反对 Agent，而是主张以构建任何严肃生产系统的方式来构建它们：从能工作的最简单方案开始，监控一切，只有在更简单的版本明显失效时才增加复杂度。

你的 Agent 正在返回 HTTP 200 状态码。延迟在 SLA 范围内。错误率平稳。仪表板上的一切都显示为绿色 —— 但你的用户却得到了言之凿凿的错误答案。

这是 AI 系统中核心的可观测性差距：传统上标志系统健康状况的指标，与你的 Agent 是否真正胜任工作几乎完全无关。一个 Agent 可以流利地产生幻觉、跳过必需的工具、使用陈旧的检索结果，或者陷入逻辑自相矛盾 —— 而此时你的监控却显示零异常。服务可观测性的标准手册并不适用于 Agent 系统，不理解这一差距的团队会发布他们无法信任、调试或改进的 Agent。

当 AI Agent 在生产环境中失败时，你很少能准确知道它是何时出错的。你看到的只是最终输出——一个幻觉答案、一个跳过的步骤，或者一个参数错误的工具调用——但实际的失败可能发生在三个步骤之前。这是软件工程尚未解决的核心调试问题：Agent 以一系列决策的形式执行，当你意识到出问题时，证据已经埋藏在交织的 LLM 调用、工具调用和状态变更的长轨迹中。

传统的调试假设确定性。你可以重现 bug，设置断点，检查状态。Agent 调试同时打破了这三个假设。相同的输入可以产生不同的执行路径。重现失败需要捕获发生那一刻的精确上下文、模型温度和外部状态。而且在实时推理循环中“设置断点”甚至不是大多数 Agent 框架所支持的功能。

你构建的一个智能体在最终输出评估中获得了 82% 的分数。你发布了它。两周后，你的支持队列里塞满了用户的投诉，抱怨智能体获取了错误的数据，使用了错误的参数调用 API，并且在错误的中期工作基础上生成了听起来很自信的回复。你回头查看追踪记录（traces）—— 发现智能体在 40% 的查询中路由都是错误的。最终输出评估从未捕捉到这一点，因为智能体往往还是误打误撞地得到了正确答案。

这是智能体评估中的核心陷阱：仅衡量最后输出的结果，无法告诉你智能体是如何到达那里的，而“到达那里”的过程正是大多数失败发生的地方。

大多数将生成式 AI 技术栈视为模型集成项目的团队，最终都会发现他们实际上构建了——或需要构建——一个平台。模型是最简单的部分。难点在于它周围的一切：将查询路由到正确的模型、可靠地检索上下文、过滤不安全的输出、缓存冗余调用、在由五个 LLM 调用组成的链条中追踪出错原因，以及随着使用规模扩大，防止成本逐月翻倍。

本文讨论的就是这个平台层。不是模型权重，也不是提示词——而是将一个可行的原型与一个你可以放心交付给百万用户的系统区分开来的基础设施。

你的监控栈能告诉你关于请求率、CPU 和数据库延迟的一切。但它几乎无法告诉你你的 LLM 是否刚刚幻觉出了一个退款政策，为什么一个面向客户的智能体在回答一个简单问题时循环调用了三次工具，或者你的产品中哪个功能正每天悄悄烧掉 800 美元的 Token。

传统的可观测性是围绕确定性系统构建的。LLM 在结构上完全不同 —— 每次都是相同的输入，不同的输出。故障模式不再是 500 错误或超时；而是一个听起来自信且合理、但恰好错误的答案。成本也不再稳定可预测；当一个配置错误的 Prompt 遇到流量高峰时，成本会激增。调试也不再是“在堆栈跟踪中查找异常”；而是“重建为什么智能体在周二凌晨 2 点选择了这条工具路径”。

这正是 LLM 可观测性（Observability）所要解决的问题 —— 而这一领域在过去 18 个月里已经显著成熟。