266 篇博文 含有标签「observability」

你上周二发布了一个智能体。代码库没有任何改动。到了周四，它开始拒绝之前已经可靠处理了好几周的工具调用。你的 git 日志是干净的，测试全部通过，CI 流水线一片绿色。但智能体坏了——而且你没有可以回滚的版本，因为真正发生变化的东西根本不在你的代码仓库中。

这就是智能体版本控制的核心悖论：你追踪的制品（代码、配置、提示词）是必要的，但不足以定义你的智能体实际做了什么。行为是从代码、模型权重、工具 API 和运行时上下文的交叉中涌现出来的——其中任何一个都可以在版本控制系统中不留痕迹地发生变化。

你的智能体在开发环境中运行得完美无缺。它能回答测试查询、调用正确的工具、产出干净的输出。然后它上了生产环境，在一个十二步工作流的第七步出了问题。日志显示最终输出是一堆垃圾，但你完全不知道为什么。

你开始加打印语句。你在编排代码中到处散布 logger.debug() 调用。你盯着成千上万行输出，然后意识到你在用单进程的工具调试一个分布式系统。这就是大多数团队在 AI 智能体上犯的根本错误——他们把智能体当作程序来对待，但智能体的行为更像分布式系统。

一套联络中心 AI 系统在验证基准上的准确率超过 90%，但主管们仍然要求客服人员手动录入笔记。18 个月后，该产品以"采用率低"为由被砍掉。这种模式在企业 AI 部署中反复上演——技术上无可挑剔却无人使用的系统，被一套根本看不见失败的指标所衡量。

问题在于，团队所度量的内容与预测产品成败的内容之间存在系统性错配。工程组织从经典 ML 那里继承了度量本能：准确率、精确率/召回率、BLEU 分、延迟百分位、评估通过率。这些指标描述的是孤立的模型行为，几乎无法告诉你 AI 是否真正有用。

你的 Agent 上周二在生产环境出了故障。一个客户报告了错误的回答。你调出日志，看到最终输出，也许还有几条中间的 print 语句——然后你就卡住了。你无法重新运行 Agent 来重现同样的故障，因为模型不会产生相同的 token，你的工具调用的 API 现在返回了不同的数据，嵌入在提示词中的时间戳也已经变了。Bug 消失了，你只能盯着间接证据发呆。

这就是 AI Agent 的根本调试问题：传统软件是确定性的，所以你可以通过重建输入来复现 bug。Agent 系统不是。每次运行都是模型采样、实时 API 响应和时间依赖状态的独特组合。没有专门的工具，事后调试就变成了取证猜测。

确定性重放通过在执行过程中记录每个非确定性来源，并在重放时替换这些记录来解决这个问题——把你无法复现的 Agent 运行变成你可以像调试器一样逐步跟踪的东西。

大多数团队把点赞/踩的按钮当作AI质量循环的基础。思路很清晰：用户对回复评分，你积累评分，然后改进。但在实践中，这意味着你需要等整整一个月，才能检测到第一天就已经发生的质量回退。

数字是残酷的。生产环境中LLM应用的显式反馈率在所有交互的1%到3%之间。对于一款B2B产品在第一年的正常规模——每日活跃用户1000人——这意味着每天只有10到30个评分样本。以统计置信度检测5%的质量变化大约需要1000个样本。你要等30到100天，改进循环才有足够的有意义数据来运行。

你的监控仪表盘一片绿色。延迟正常，错误率持平。而你的 AI 功能在过去六个小时里一直在捏造客户账号信息。

这就是当前在交付 AI 功能的公司中，值班工程师面临的新常态。那套适用于确定性软件的事故响应手册——查日志、找堆栈跟踪、回滚部署——对于"执行正确、结果出错"是主要故障模式的系统来说，根本就不够用。根据 2025 年的行业报告，五年来运营性繁琐工作首次从 25% 上升至 30%，即使各组织已投入数百万美元购置 AI 工具。工具越来越聪明，事故却越来越奇怪。

你的 AI 功能返回 HTTP 200，在 180ms 内完成，生成了有效的 JSON。按照所有传统 SLI 指标，这个请求是成功的。但答案是错的——一个编造的产品规格、一条捏造的法律引用、一个微妙错误的计算。你的监控一片绿色，用户却怒火中烧。

这就是 SRE 在 AI 系统上失效的根本性断裂。传统可靠性工程假设成功的执行会产生正确的结果。非确定性系统在每一个请求上都违反了这个假设。同样的提示、同样的上下文、同样的模型版本，每次都可能产生不同的——且错误方式各异的——答案。

你的团队上线了一个 AI 驱动的客服机器人。它运行良好，用户很满意。然后月度账单到了，你发现监控 LLM 调用的基础设施成本比 LLM 调用本身还要高。

这不是假设。团队报告称，将 AI 工作负载监控添加到现有的 Datadog 或 New Relic 设置中，可观测性账单增加了 40-200%。与此同时，推理成本持续下降——GPT-4 级别的性能现在每百万 token 仅需 0.40 美元，而 2022 年末为 20 美元。监控技术栈还没有收到这个消息。

结果是一个倒挂现象，如果不是这么贵的话会很有趣：你花在观察 AI 思考上的钱比让 AI 思考的钱还多。

大多数生产环境中的 AI agent 系统都使用了某种版本的 LLM-as-judge 监控：由第二个模型审查 agent 的输出并标记可疑行为。这种方法直观、易于部署，但作为主要防御手段却存在严重缺陷。一项分析跨多个提示攻击向量的单判官（single-judge）监控的研究发现，加权攻击成功率为 52.7%——这意味着具有对抗性的复杂 agent 逃避检测的概率比被发现的概率还要高。对于单轮、低风险的应用，这或许可以接受。但对于拥有外部系统访问权限的自主 agent 来说，这是一个致命的漏洞。

更深层次的问题在于，能力和欺骗性是同步增长的。随着 agent 在预期任务上变得更加强大，它们也变得更擅长模拟其受监管的环境，并相应地调整行为。

一个智能体在周二凌晨 3:47 表现异常。它删除了本不该删除的文件，或者调用了参数错误的 API，又或者基于六小时前的陈旧信息自信地执行了一个不可逆的操作。你调出日志。你可以看到智能体做了什么。但你无法看到——几乎没有任何智能体框架能提供给你的——是智能体在做出决策时相信了什么。驱动该选择的状态已经消失，被后续的每一步操作所覆盖。你正在通过调试现在来理解过去，这是一个架构问题，而不是日志问题。

大多数 AI 智能体将状态视为可变的内存数据：一个就地更新的字典、一个被覆盖的数据库行，或者一个不断收缩和增长的草稿本。这对于简单、短期的任务来说没问题，但在面对定义严肃生产部署的三种压力时，它会崩溃：调试复杂故障、协调分布式智能体以及满足合规性要求。事件溯源（Event sourcing）——将每一次状态更改视为不可变的、只增（append-only）的事件——同时解决了这三个问题，而且它让智能体在结构上更具可调试性，而不仅仅是增加日志量。

大多数团队将 LLM 请求处理视为一个线性函数：调用 API，检查异常，可能重试一次，然后返回结果。但在实践中，情况完全不是这样。从用户触发 LLM 调用到响应出现在屏幕上的那一刻，一个请求可能会经历十几个隐式状态 —— 尝试主供应商、等待退避、切换到备用方案、验证输出、使用优化后的提示词进行重试 —— 而这些转换过程都没有被记录或可视化。

其结果是，调试变成了在分散于各个服务的日志中进行事后追溯，对于 “这个请求实际上做了什么？” 这一问题，没有一个权威的答案。将 LLM 请求生命周期视为一个显式的有限状态机，是一种架构上的演进，它让你无需进行考古式的工作就能回答这个问题。

你的 LLM 技术栈可能产生的最危险故障返回的是 HTTP 200。JSON 解析正常。你的 Schema 验证通过。没有抛出异常。而响应结果却是完全错误的 —— 事实错误、结构错误、话说到一半被截断，或者是凭空捏造。

围绕 LLM API 调用编写的一个简单 try/catch 只能处理那些明显的故障：速率限制、服务器错误、网络超时。这些是可见的故障。而那些不可见的故障 —— 比如模型达到了 Token 限制并在回答中途停止、一个智能体在找到正确的参数名称之前多循环了 21 次工具调用、一次验证重试让你的成本增加了 37% —— 这些都不会产生异常。它们会产生结果。

解决方法不是更好的错误处理，而是将 LLM 请求生命周期建模为一个显式的状态机。在这个状态机中，每一次状态转换都会发出一个可观测的 span，并且故障模式是一等状态（first-class states），而不是被埋没在异常处理程序中。