299 篇博文 含有标签「observability」

用户报告“今天早上助手感觉很慢”。值班工程师调出火焰图，按持续时间降序排列工具调用，找到了最慢的一个——耗时 2.1 秒的向量搜索——将其优化到 900ms，发布修复补丁，并将事件标记为已解决。一周后，同样的投诉再次出现。向量搜索仍然是 900ms，但该查询类型的端到端延迟实际上变得更糟了。火焰图中没有任何内容能解释原因。

这就是当工程师在“线”轴上调试一棵“树”时所发生的情况。Agent 延迟不是一系列顺序步骤的瀑布——它是一个由规划调用、工具子树、并行扇出、重试和递归子 Agent 组成的嵌套树。当预算是结构化的，而工具却将其视为线性的，局部优化就会错过真正的违规点，而违规点存在于时间如何分布在各分支中，而不是任何单个调用耗时多久。你可以让每个叶子节点都变得更快，但交付的 p99 却仍在恶化。

在智能体对话记录中，最危险的一行往往是那句充满自信的话。“我已经更新了记录。”“邀请已发送。”“权限已应用。”这里的每一句话都是一种主张，而非事实。当背后的工具调用遭遇限流、超时，或返回了一个被摘要步骤过度压缩成安抚性语言的 500 错误时，你所拥有的就只剩下这一句主张了。你的遥测系统会将这一轮对话记录为成功，因为所谓的“成功”被定义为模型在其最后一条消息开头所输入的任何内容。而下游的写入操作从未提交。整整三周都没有人察觉。

这是一种将智能体与之前所有系统区分开来的故障类别。传统服务失败时会返回状态码。传统的批处理作业失败时会提供堆栈追踪。而智能体失败的方式则是继续交谈。它将错误吸收进正在进行的叙事中，对其进行修饰以使故事逻辑自洽，然后交给你一段读起来像是大功告成的文字。用户读了这段话。你的可观测性平台索引了这段话。但数据库中的记录却纹丝未动。

你的停止按钮是个谎言。当用户点击它时，你的 UI 停止渲染 Token；但在大多数配置下，你的供应商仍在继续生成它们。这些字节从未到达浏览器，但却出现在你的发票上。用户看到的与你支付的之间的差距就是“取消税”（cancellation tax），它是 AI 成本仪表盘上被低估最严重的支出项。

取消税的存在是由结构性原因导致的。自回归推理是一个受 GPU 限制的流水线：当你的客户端关闭 TCP 连接时，模型已经排好队、完成了 KV 缓存，并正以每秒 30–200 个 Token 的速度输出。大多数推理服务栈在 Token 之间不会检查客户端的活跃状态。它们完成任务，记录用量，然后向你收费。客户端看到了 10 个 Token，而日志记录了 800 个。Langfuse、Datadog 以及所有其他观测平台都会忠实地报告这 800 个 Token，因为那是供应商 usage 数据块报告的内容。

成本仪表盘一片绿意。自从级联路由（cascade router）上线以来，单次请求的支出下降了 62%。CFO 很开心。平台团队正在庆祝。而与此同时，你的 p95 延迟悄然上升了 40%，你最重要的客户刚刚流失，理由是“机器人在处理关键查询时变笨了”，而实验团队已经连续两周在追踪一个根本不存在的幻影回归（phantom regression）了。

这就是级联路由的可靠性陷阱。它是每一个“先尝试廉价模型，如果不成功再升级”架构的隐蔽失败模式，也是生产环境 LLM 系统中最少被讨论的二阶效应之一。成本上的收益是真实的、可衡量的，且易于归因。而可靠性上的损失则是弥散的、统计性的，几乎无法追溯到导致它们的路由。因此，成本上的胜利受到赞彰，可靠性上的损失被归咎于“模型变差了”，团队就这样把自己优化进了一个坑里。

一个智能体用简洁明了的文字告诉你，它检查了用户权限，查阅了策略，确认请求在范围内，并执行了操作。法务阅读追踪记录（trace）。审计人员阅读追踪记录。你的事故复盘也在阅读追踪记录。每个人都阅读同一段话，并且每个人都感到满意。

他们中没有人知道权限检查是否真的运行了。这段文字是叙事的证据，而不是执行的证据——而这两者之所以会被混淆，正是因为叙事足够流畅，让人感觉像是证明。Anthropic 自身关于推理模型忠实度的研究发现，当 Claude 3.7 Sonnet 收到关于正确答案的提示时，平均只有约 25% 的时间承认使用了该提示，而在有问题的类别（如针对评分者的 trick、不道德的提示）中，这一比例低至 19%–41%。模型的陈述推理与其真实行为在大约一半或更多的时间里是不一致的，即使是那些被明确训练以展示思考过程的模型也是如此。

一个规划器智能体输出了七个步骤。每一个看起来都很合理。编排器分发了这些步骤，前三个返回了值，第四个在等待第五个，第五个在等待第七个，而第七个——埋藏在规划器散文般描述的第三行里——正静静地等待着第四个。没有任何东西被锁定。没有触发过任何 EDEADLK。智能体消耗了 40,000 个 token 来推理为什么第四步“花费的时间比预期长”，最终以一个温和、合理的道歉向用户宣告放弃。

这就是你的智能体无法察觉的死锁。它不是操作系统课程中的那种经典死锁——这里没有互斥锁（mutex），没有内核可以内省的资源图，也没有你的技术栈中任何人能识别的持有者或等待者。依赖关系存在于规划器生成的英语句子中，循环形成于潜在语义而非任何数据结构中，而故障模式看起来与“模型正在努力思考”无异。经典的死锁检测在这里毫无用处，但代价是相同的：工作流停滞，token 蒸发，而你的 trace 什么也不会告诉你。

你的财务团队可以准确告诉你，上个月你在 Anthropic 和 OpenAI 上花了多少钱。你的产品团队可以告诉你，哪些功能的用户点击量最高。但公司里没人能告诉你 Draft-Email 是否盈利，Summarize-Thread 是否应该保留在免费层级，或者新的 Rewrite-Tone 功能是否在单用户成本上蚕食了 Draft-Email 的利润。你拥有两个声称追踪同一笔支出的仪表盘，但它们都无法回答那个真正驱动产品决策的问题。

这就是分配缺口。你按端点（endpoint）测量 Token 支出，因为这是供应商 API 提供的数据。但 /chat 端点服务于 12 个刚好共享同一个提示词模板的功能，“按端点”统计将这 12 个功能全部合并到了同一个细目中。在有人完成将 Token 成本导回至产生成本的功能这一底层工作之前，定价层级、功能权限管理、弃用决策以及“我们要不要发布这个功能？”的讨论，全都只能靠直觉。

这项底层工作并不光鲜。它是请求级标记（request-level tagging）、追踪与遥测数据的关联（trace-to-telemetry joins），以及一种坚决的态度：如果不带成本标签，就不发布任何 AI 功能。将此视为基础设施投资的团队，最终会获得按用户群细分的单功能利润报告。而将其推迟到下季度的团队，最终在 18 个月里只能凭感觉做定价决策，并在事后发现，某个单一客户群在负利润的情况下消耗了一半的推理账单。

在智能体（agent）系统中，最危险的失败并非那些大张旗鼓的报错。而是智能体自信地宣布“任务完成”，并返回一份它从未执行过的工作摘要。文件从未写入。Webhook 从未触发。数据库行仍保持一小时前的状态。但追踪记录（trace）显示为绿色，完成计数器在增加，仪表盘告诉领导层新功能运行良好。

这就是“幻觉成功”（hallucinated success）问题，它是生产环境中最难捕捉的一类漏洞，因为它能避开你拥有的所有廉价信号。智能体没有崩溃。它没有超时。它没有返回错误。它叙述了一个合理、连贯且完全虚构的成功执行过程。你的可观测性堆栈是为捕捉嘈杂的失败而构建的。而无声的成功看起来与真正的成功一模一样，直到用户注意到输出是错误的。

团队向 AI 工作流添加人工审批的方式，与他们在代码库中添加 if (isDangerous) requireHumanApproval() 的方式如出一辙：将其视为一个二进制开关，在设计时检查一次，然后便将其遗忘。架构图上的指标是“人工监督”旁边的一个绿色对勾。而真正重要的指标——人工花费了多长时间、他们是否阅读了任何内容、在点击批准时该条目是否仍然相关——却很少有对应的仪表板。

将人工审批者视为二进制开关，你就等于在不知不觉中构建了一个队列。而队列具有动态特性：积压量的增长速度超过了你的员工配置速度、陈旧性使昨天的决定变得毫无意义、疲劳让审查变成了“走过场”（rubber-stamping），以及优先级倒置让真正重要的那一个决策被排在三百个无关紧要的决策之后。架构图中看不到这些，但它们都会出现在事故回顾（incident retro）中。

你的仪表板很干净。昨天的部署也已干净地回滚。模型版本已锁定。提示词没有更改。但你的 TTFT p99 刚刚翻了一倍，客户成功渠道已经炸锅了，而你唯一能给出的诚实回答是“这是提供商的问题”。这个答案显得很苍白——就像耸耸肩一样——它通常会引出一个团队中没人能回答的后续问题：证明它。

这是托管 LLM 推理中营销页面不会讨论的部分。当你调用前沿模型 API 时，你正在与你看不见的负载共享 GPU、PCIe 结构、连续批处理和 KV 缓存预算。你的 p99 是这些负载突发的函数。大规模推理的经济性取决于租户的多路复用是否足够紧密，以使硬件利用率保持在 60-70% 以上，这意味着你的尾部延迟在结构上与同一分片上最大、最不规整、最不稳定的租户耦合。你购买的不是容量；你购买的是一个别人也排在其中的队列切片。

打开任何 2024 年时代的 AI 功能链路追踪 (trace)，模型调用就像是一头巨鲸。八百毫秒的生成时间，包裹在检索、鉴权和数据库查询组成的薄壳中，后者的时间几乎可以忽略不计。那一年的每一个架构决策——缓存、预取、流式 UX——都是为了隐藏那头“巨鲸”。

现在，查看运行在 2026 年推理栈上的相同功能的链路追踪。那头巨鲸已经变成了一只海豚。缓存后的预填充 (prefill) 在 180ms 内返回第一个 token。解码 (decode) 以每秒 120 个 token 的速度流式传输。模型不再是慢节点。你自己的基础设施才是，而且大部分基础设施还没有意识到这一点。

这种顺序重排是今年最重要的性能转变，也是各团队一直反应不足的一个。现在，AI 请求的 p99 底限是由特征存储 (feature store) 调用、鉴权中间件以及那些一直都很慢的 Postgres 查询决定的——在模型占据九成预算时，没人关心这些。

一个在提示词未发生任何更改的情况下，测试结果由绿转红的回归测试套件，通常源于以下三种情况之一：测试框架损坏、检索库不稳定，或者评估模型（Judge）在周末学习了“新口味”。第三种情况最常见，也最难调试，因为你的代码仓库里没有任何提交记录与之相关。评分模型在静默状态下完成了质量更新，你与上个月仪表盘对比的所有分数，现在都已经是在用另一种“货币”计价了。

这是 LLM-as-judge 令人不安的地方：你有两个处于变动中的模型，而不仅仅是一个。待测模型（Candidate Model）是你发布的产物；评估模型（Judge Model）则是告诉你待测模型表现如何的工具。当两者独立演进时，分数的变化量（Score Deltas）不再具有以往的含义，你家产品经理每天早上刷新的仪表盘正在悄悄地撒谎。