108 篇博文 含有标签「observability」

打开你团队用来发布提示词（prompt）变更的配置仓库。看看最近的 30 个 commit。其中有多少个经过了代码审查（code review）？有多少个在 CI 中设置了评估门禁（eval gate）？有多少个你能——肯定地——归因为对看到它们的用户的生产环境行为产生了可衡量的变化？如果你的答案是“绝大多数”，那你是个例外。对于其他人来说，这些 commit 此刻正在生产环境中运行，而读取它们的系统所做的事情与特性标志（feature-flag）服务完全一致：热加载一个值，分发给用户，改变产品行为。区别在于，你的特性标志服务拥有审计日志、曝光追踪、熔断开关（kill switches）以及针对特定分群的定向投放。而你的提示词发布流水线只有 git push。

这并非隐喻。这是对你团队正在运行的生产系统的准确描述。提示词配置仓库、你的 worker 轮询的 S3 存储桶、数据库中的 “prompts” 集合、你的应用在启动时获取的 LangSmith/PromptLayer/Braintrust 资产——这些全都是特性标志服务。它们具有相同的运行时形态：一个存在于二进制文件之外的值，二进制文件在热路径（hot path）上读取它，更改该值即可在无需部署的情况下改变真实用户的行为。唯一缺少的，是你的 SRE 团队在批准“真正的”特性标志服务之前所要求的所有控制措施。

Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。

这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。

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

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

你的停止按钮是个谎言。当用户点击它时，你的 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 查询决定的——在模型占据九成预算时，没人关心这些。