一篇关于 SRE 与可靠性工作流的基准研究笔记：当 AI 智能体拥有"因果地图"后，诊断更快、更准、更便宜。
现代软件系统越来越复杂：微服务跨服务依赖、AI 生成代码、交付周期加速。工程团队把 AI 智能体引入 SRE（站点可靠性工程）工作流，希望它们能帮忙检测事件、定位根因、评估变更安全性、容量规划。
但一个核心问题被忽略了：智能体要先"理解"当前环境状态，才能开始诊断。它必须知道：
这些信息本应由一个持久的上下文层提供，但目前大部分智能体每次查询都要从原始遥测数据中重新推导。拓扑是动态的，Pod 会滚动，容器会消失，证据可能是过时的——智能体就像在迷雾中拼图。
论文把上面这种 overhead 称为 Semantic-Interpretation Tax（语义解释税）：智能体为了把原始信号转化为可用知识，必须支付的 Token、延迟和可靠性成本。
大多数企业现在按席位订阅 AI 工具，模型计算被包月在固定费用里。一个调查消耗 10 万 Token 和 100 万 Token 在账单上看起来一样。但论文指出：
当定价模型与实际计算成本对齐时，"语义解释税"就会从被补贴的隐形成本变成直接的账单项目。
Causely 的核心主张是：与其让智能体每次从零推导环境状态，不如维护一个持续更新、语义结构化、因果上下文化的环境表示，作为结构化上下文直接喂给智能体。
论文把它形式化为一个四元组：CI = (GT, KC, GC, GA)
环境里有什么、它们如何连接。实体包括微服务、数据库、缓存、工作负载、节点等；关系包括水平调用、垂直分层、组合包含。
与环境无关的领域知识：每类实体可能出现哪些根因、产生什么症状、症状如何沿关系传播。把通用云原生故障模式和具体部署状态解耦。
把知识库实例化到当前拓扑上，形成有向无环图。给定一组活跃症状，可以反推最可能的根因（溯因推理），并给出条件概率 P(症状|根因)。
描述可测量性能属性之间的函数关系（延迟、吞吐、利用率、队列长度等），让系统不仅能做离散故障推理，还能做连续值影响分析。
论文把实验问题组织成四个核心用例，每个用例对应智能体消费因果层的一种不同方式：
回答"现在发生了什么？"把活跃观测转化为语义化的运营状态：有哪些症状、哪些根因被激活。
回答"影响面有多广？"给定一个根因或症状，沿拓扑和因果关系传播，找出受影响的实体、服务和团队。
回答"问题出在哪里？"基于症状集合在因果图上做溯因推理，选出最可能的根因实体。
回答"这个操作安全吗？"判断 proposed action 是针对根因实体，还是只处理下游症状。
实验采用 2×2 全因子设计，总共 72 次运行：
使用 CNCF 维护的 OpenTelemetry Astronomy Shop，一个 24 微服务的多语言参考应用，部署在本地 kind 集群。服务类型覆盖 Kubernetes 工作负载、PostgreSQL、Valkey/Redis、Kafka、OpenSearch 和对象存储。
在支付服务（payment service）注入代码级缺陷：每笔交易都被拒绝。它不会产生基础设施告警或资源耗尽，但会通过交易路径传播，导致 checkout、accounting、shipping 三个下游服务降级。这是一个典型的"只能通过下游症状暴露"的应用层回归。
接入 Causely 后，所有指标在活跃故障场景下都有显著改善：
平均诊断时间从基线的约 70–75 秒降至约 18–31 秒。最夸张的案例：HolmesGPT(Gemini Pro 3) 从 281 秒降到 13 秒。
在活跃故障场景下，Codex 和两款 HolmesGPT 的基线准确率都是 83%，接入 Causely 后全部达到 100%。Claude Code 基线就是 100%，接入后保持。
Token 消耗下降 59.9%，工具调用下降 78.4%。最有趣的细节是：单次 Causely 调用并不比单次 MCP 调用便宜，但它返回的是已经组装好的因果状态，因此能替代多次小型重建调用。
worst case 上，HolmesGPT(Gemini Pro 3) 基线一次运行用了 813K Token，接入 Causely 后降到 111K，压缩 86%。
在基准模型档位（Claude Sonnet、Gemini 3.1 Flash-Lite、GPT-5.4 mini）下，单次运行成本平均下降 56.9%。如果把同样 Token 轨迹按高端模型（Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro）重新计价，节省幅度在 46%–85% 之间。
| 智能体 | 基准成本/次 | +Causely | 降幅 |
|---|---|---|---|
| Claude Code (Sonnet) | $0.216 | $0.117 | 46.0% |
| Codex (GPT-5.4 mini) | $0.119 | $0.049 | 58.6% |
| HolmesGPT (Gemini) | $0.044 | $0.011 | 75.7% |
| HolmesGPT (Claude) | $0.286 | $0.150 | 47.4% |
论文中最反直觉的发现：在健康基线场景下，基线智能体往往比故障场景花费更多时间和 Token。
为什么会这样？因为：
这导致了两类典型幻觉：
Codex 把 74 分钟前一次 product-catalog Pod 重启后的残留 ECONNREFUSED 错误，解释成当前 checkout 故障的根因。
HolmesGPT(Claude Sonnet) 的 kubectl 探测因为临时工作目录缺少 kubectl 而失败，智能体却据此认为"checkout 在 8080 端口无响应"。
OTel Collector 对 kubelet 的 TLS 验证失败是真实存在的遥测噪声，但与 checkout 路径无关，智能体却把它归因到 checkout 故障。
接入 Causely 后，HolmesGPT(Claude Sonnet) 的幻觉率从 67% 降到 0%，Codex 从 67% 降到 33%。因为"无活跃根因"成了一个明确的类型化答案，而不是推理失败。
论文用保守的线性缩放假设，把 Ops AI 平均 Token 数推演到更大规模环境。假设基线 Token 随服务数线性增长，而 Causely Token 只随活跃问题数增长：
| 规模 | 基线 Token/次 | +Causely | 基线成本/次 | +Causely | 月成本（500次） |
|---|---|---|---|---|---|
| 24 服务（实测） | 319K | 110K | $0.91 | $0.23 | $455 → $115 |
| 200 服务（推演） | ~2.5M | ~220K | $7.30 | $0.45 | $3,650 → $225 |
| 1000 服务（推演） | ~12.8M | ~330K | $36 | $0.68 | $18,000 → $340 |
注意：1000 服务时基线估计每次 12.8M Token，已超过当前主流模型约 100 万 Token 的上下文上限。这不仅是成本问题，而是智能体根本无法完成调查。
作者在结论部分坦诚了若干局限：
纯靠大模型从原始数据推理环境状态，是低效且不可靠的。一个预计算、可查询的语义/因果层，是智能体真正胜任复杂运维的前提。
按席位订阅掩盖了 Token 消耗。当 AI 定价向实际计算成本靠拢时，那些需要大量环境解释工作的智能体将从资产变成预算负担。
健康基线场景提醒我们：智能体不仅需要找到根因的能力，更需要明确判断"没有根因"的能力，否则会在没有故障时编造故障。
Causely 不是让单次调用更便宜，而是减少调用链路和中间状态重建。这提示我们：智能体系统的成本优化，关键是把"解释环境"的工作移出推理循环。