348 篇博文 含有标签「observability」

一位客户对贷款被拒提出异议。监管机构开启调查。原告律师提交证据开示请求。这三者都带着同一个看似简单实则棘手的问题：你的系统做了什么决定，以及为什么？ 决策发生在 18 个月前。你调出案例，发现产生原始输出的每一个组件都已经发生了变化。托管模型版本已被弃用并迁移。系统提示词（System Prompt）被修改了 9 次。你的智能体（Agent）检索到的文档被重新分块（re-chunked）、重新嵌入（re-embedded）并重新排序（re-ranked）到了一个新的索引中。而让整个过程具有非确定性的采样设置从一开始就根本没有记录。

你无法复现该决策。这不是因为你疏忽大意，而是因为你的技术栈中没有任何东西是为了可复现性而构建的。事后解释性（Explainability-after-the-fact）归根结底是一个伪装成解释问题的可复现性问题——而可复现性这种东西，你要么在决策发生的时刻就通过工程手段将其固化，要么就会永远失去它。

令人不安的事实是，大多数团队发现这个漏洞时，恰恰是他们最承受不起后果的时候。重建决策的需求几乎从不会在正常运营期间出现。它往往伴随着诉讼、审计，或是带着监管机构电话号码的愤怒客户而来。到那时，捕获正确证据的窗口期早在一年半前就已经关闭了。

一个研究员智能体向一个检索智能体请求一份文档。检索智能体在任务执行到一半时，决定需要研究员智能体澄清查询意图后才能继续搜索。而正在等待文档的研究员智能体，在拿到文档之前不会做出响应。它们谁都没有出错，也没有陷入死循环。它们只是都在礼貌地、无限期地等待着对方——而你的编排器（orchestrator）根本没有“这两个智能体正在互相阻塞”的概念，它会一直愉快地维持这个状态，直到你从未配置过的超时设置最终触发，或者直到某个大活人注意到这个运行已经“进行中”整整 40 分钟了。

这就是死锁（Deadlock）。它是计算领域最古老的故障模式之一，且与你的模型有多聪明毫无关系。它是工作协调方式的一种属性，而不是工作执行方式的属性。过去一年多智能体研究中一个令人不安的发现是：在智能体集群中，大部分出问题的地方都在这里，即协调层，而不是任何单个智能体的推理能力。

单智能体思维永远无法暴露这些 Bug。当一个模型运行工具调用循环时，它最坏的情况也就是空转——而空转至少是肉眼可见的。一旦你拥有两个或更多可以互相等待的智能体，你就继承了分布式系统所有的病理特征：循环等待、活锁、丢包、过早终止、共享状态下的竞态条件。没有人会坐下来决定构建一个分布式系统，但在你添加第二个智能体的那一天，你就已经构建了一个分布式系统。

你对生产系统的每一次更改都遵循某种纪律。代码在 feature flag 后发布，灰度测试（canary）到 1% 的流量，当仪表盘变红时可以一键回滚。Schema 迁移是分阶段且可逆的。即使是 CSS 的微调也要经过人工阅读的 pull request。然而 Prompt 却并非如此。有人在文本框中编辑一段文字，点击保存，你产品的行为就会立即对所有用户发生改变——没有灰度测试，没有经过审查的 diff，也没有真正能让你回到先前状态的回滚按钮。

令人不安的是，这并非粗心的团队所导致的疏忽，而是工具链产生的默认结果。Prompt 被归类为“配置（configuration）”，因为它们是存在于编译后的二进制文件之外的字符串，而配置一直以来被认为是可以快速更改且无需完整发布周期的东西。但 Prompt 并不是配置。它是一个用英语编写的程序，由一个你无法控制的非确定性解释器编译，其行为你只能通过统计学来观察。将它视为配置值，是导致一整类生产事故的范畴错误（category error）。

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

你的 Agent 有一个延迟 SLO。有人把它写在了文档里：“响应时间低于 8 秒，p95”。但没人决定这 8 秒该如何分配。检索调用没有细分预算，规划步骤没有细分预算，模型因为感到不确定而决定调用的第三个工具也没有细分预算。预算在边界处只是一个数字，而在内部则完全不存在。因此，当一个五跳链路冲破 8 秒时，值班工程师盯着追踪链路（trace），却无法回答那个唯一重要的问题：到底是哪一跳超时了？

这就是拥有“延迟预算”的服务与拥有“延迟愿望”的服务之间的区别。预算是分配给每个组件并强制执行的；而愿望是在出口处测量并祈祷达标的。大多数 Agent 系统发布时都带着愿望，因为跳数结构是动态的——模型决定调用多少次工具——而且为无法控制的事情制定预算感觉是不可能的。事实并非如此。正因为你无法控制它，你才更需要为它制定预算。

一个支持请求发送了进来：“我的订阅被扣了两次费，请取消其中一个并退款。”一个路由代理将其归类为计费问题并进行了移交。一位计费专员查看了账户，确认了两笔扣费，并将退款操作移交给了一个工具调用子代理。该子代理执行了一次退款，随后一个总结代理给客户回信：“搞定了——你的重复扣费已退还。”每一个步骤单独看都是正确的。但实际上客户被扣了三次费，而不是两次。其中一笔重复扣费仍在他们的卡上，而总结代理无从得知这一点，因为当对话传导到它那里时，“ 2 ”这个数字已经在上游的四个步骤中固化成了事实。

让我们进行一次复盘。这是谁的 Bug？路由代理分类正确。计费专员读取了它收到的两笔扣费。工具代理准确地按照指令进行了退款。总结代理进行了准确的总结。单独调出每个代理的 Trace，每一个都通过了。系统失败了，但没有任何组件出错。这就是“无主对话”，它是多代理架构中定义性的操作性失败——不是模型太笨，而是责任在移交链条中不断扩散，直到没有任何一个代理需要对用户实际体验到的结果负责。

你的评估仪表盘是一片绿色。单轮准确率（turn-level accuracy）保持在 95%，LLM 裁判（LLM judge）与你的标注人员意见一致，每一项回归测试在上线前都顺利通过。然后，一名用户提交了一个 bug：在第九轮对话中，智能体推荐了一个 Postgres 索引，但这直接违反了用户在第一轮中设定的“我们使用的是 DynamoDB”这一约束。你调出对话记录。每一轮对话如果拆开来看，都是合理的回复。但如果把整个对话作为一个整体来看，那就是一场灾难。

这是单轮评估（turn-level evaluation）的核心谎言。它对“请求-响应”对进行评分，因为这是标注成本最低的单位，并且它默认假设一段对话仅仅是你可以取平均值的独立轮次的组合。事实并非如此。第九轮的响应是以之前发生的一切为条件的，而那些真正触达用户的失败几乎从未存在于单轮对话内部——它们存在于轮次之间的缝隙中，在那里状态丢失、假设变得僵化，微小的错误复合成一个完全错误的最终答案。

事故排查会议（incident bridge）安静得有些异样，这意味着大家都卡住了。一份支持工单显示，智能体（agent）告诉客户其退款已获批准，而事实并非如此。你有完整的追踪记录：提示词（prompt）、检索到的账户记录、工具调用、模型的推理过程以及最终的消息。你重放了一遍，智能体的操作是正确的。你又重放了一遍，依然正确。十次中有九次，产生该事故的追踪记录反而生成了正确的结果。会议上终于有人提出了那个复盘模板（retro template）无法处理的问题：那么，根本原因是什么？

根本没有。至少不是模板所指的那种。五个为什么（five-whys）的链条是这样运作的：“智能体告诉了客户错误的信息” → “因为模型生成了批准” → “因为它采样了一个断言批准的 Token 序列” → “因为……这是概率分布所允许的。”最后一个“为什么”最终以耸耸肩告终。“模型采样了一个错误的 Token”在技术上是正确的，但在操作上毫无用处。它没有指明修复方案，没有分配负责人，也没有弥补差距。你可以把它写进报告，但每个读到它的人都知道，你记录的是一个巧合，而不是一个原因。

你按照每一份可观测性指南的要求对代理（agent）进行了插桩。每一个回合都有一个 span：完整的 prompt、检索到的块（chunks）、模型的思维链、它考虑过的工具调用、它起草随后又放弃的计划，以及最终的行动。存储费用是每 GB 三分钱，而在事件响应期间，这些追踪（traces）已经救了你十几次。你保留了一切，因为保留一切几乎是免费的，而且偶尔还能立大功。

这是平台团队中没人建模过的部分：那个追踪记录是用流畅的英语写成的，它点名道姓地揣测你的客户，还起草了你从未实际执行的操作。它是你公司产生的最容易被引用的制品，而原告律师会对着幻灯片上印着的你公司 Logo，向陪审团宣读其中最“精彩”的 200 个单词。让你的系统具备可调试性的推理追踪（reasoning trace），正是让它承担法律责任的推理追踪。

财务在月底打开发票。一个供应商。一个数字。它比上个月大，而且下个月还会更大。然后他们提出了唯一重要的问题 —— 这是哪个功能花的钱？ —— 房间里没人能回答。

这是在生产环境中运行 AI 的一种隐蔽失败模式。并不是说账单数额巨大；如果价值匹配，数额大也没关系。失败之处在于账单是无法归因的。它作为一个单一的费用项出现 —— OpenAI、Anthropic、Bedrock、Azure —— 没有任何财务部门真正需要的维度：没有按功能、按团队、按客户，也没有按成功的任务进行拆分。你能看到总额在上升。但你看不出 原因，而当发票寄到时，原本可以解释它的请求上下文早已消失了。

你的 Agent 内部指标看起来棒极了。任务完成率达到了 94%。#agent-feedback Slack 频道已经安静了三周。领导层正准备将其推向客户。接着外部用户进场了，不到一个月，数据全线崩溃：工单量激增，信任度降至冰点，复盘时每个人都会问：“Dogfooding 怎么会漏掉这些问题？”

Dogfooding 并没有漏掉问题，而是掩盖了问题。内部用户并不是客户群体的缩影 —— 他们是一群专家级操作员，在无声地修补 Agent 的错误，学习避开哪些提示词（Prompt），并在私信里分享变通方案而不是提交 Bug。每一次修补都让仪表盘（Dashboard）看起来更好，却让产品变得更难理解。你读到的清晰信号并非质量，而是补偿（Compensation）。

你的云账单可以具体到标签，告诉你上个月一个被遗忘的 S3 存储桶花费了 14,000 美元。但如果你问 LLM 账单同样的问题——到底是哪个功能烧掉了价值 40,000 美元的 token——大多数公司的真实反应只能是耸耸肩。供应商的发票上每个模型、每个 API 密钥只有一行记录，而三个团队共享这个密钥，财务报表中的 “AI 成本” 行则是根据人头、感觉，或者在上次规划周期中抱怨最少的人来分摊的。

这不仅仅是一个小的簿记烦恼。当没人能说出每一美元的 token 支出背后具体对应哪个功能时，会出现两种失败模式。低成本的功能被限制了，因为它们与昂贵的功能共用一个预算额度。而真正浪费的功能却永远存在，因为它们的成本是隐形的——被分摊到了共享的密钥、共享的缓存以及服务于六个不同产品界面的共享智能体（agent）循环中。

FinOps 基金会 2026 年的调查发现，目前 98% 的组织都在积极管理 AI 支出，而一年前这一比例为 63%，再前一年仅为 31%——这是该基金会有记录以来最快的采用曲线。每个人突然都在做 “AI 领域的 FinOps”。但很少有人注意到，云 FinOps 的核心原语——资源标签（resource tag）——在 token 的世界里并不存在，而且现代 LLM 使用的三个特定机制正活跃地破坏着成本归因。