以智能体重塑系统监控：实践、优势与权衡

一篇Anthropic 最近的博客文章中有一段简短的文字,与文章的主题毫无关系,但自从我读完之后就一直在我脑海中挥之不去：

一种新的运营卓越水平是可以实现的。我们的团队大量使用 Claude Tag,它帮助我们监控系统的每个组件。例如,我们创建了 Slack 频道,让 Claude 专注于监控单个组件的健康状况。我们称这些 Claude 为"超级粉丝"。我们有一个 scion-daemon 超级粉丝、一个 scion-cache 超级粉丝、一个 Antique 合并队列超级粉丝,等等。它们可以访问我们的遥测数据和日志,表现得就像一位资深工程师——除了不断刷新图表、寻找任何异常之外无事可做。我们也为所有系统设置了传统的告警机制,但我们的超级粉丝能够发现那些微妙且新颖的问题,相比之下,这些传统告警显得十分单薄。

这显然是软件系统运维的未来之路。过去几周我一直在思考使用智能体进行监控,这段话把我的一些想法具体化了。

现代软件系统,正如同编写它们的 LLM 一样,越来越像是被"培育"出来而非"设计"出来的。没错,人类工程师通常仍然会给出系统的高级设计和形态,而且是的,软件系统(至少目前)比 LLM 更容易理解——因为只要你愿意,可以坐下来读代码。然而,随着编写和发布的代码量呈指数级增长,任何人类系统运维人员实际拥有的代码知识却在减少。

系统监控从来都不容易。有一整个可观测性 SaaS 公司行业——Sentry、Datadog、Splunk、Honeycomb,仅举几例。可观测性成本高昂。¹要做好它需要专业化的人才技能,并依赖于在大规模真实系统上积累的运维经验。这些技能只能通过在业界工作才能真正培养出来。这是一个需要数年时间才能培养初级工程师的领域。

正如 2026 年软件行业中看似一切都在经历的事情一样,系统监控也即将因智能体而发生跨越式变革。我……很惊讶没有看到更多人写这方面的内容,尤其是在当前"智能体狂热"的氛围中。它就在我们所有人眼前,而且它确实有效。已经有一批创业公司在尝试做"AI SRE",但从业者的撰文却寥寥无几。

但要提升运营卓越水平,你并不真的需要一个完整的"AI SRE",也不需要一个成熟的 SaaS 产品。从 Opus 5.5 / Astra 级别的模型来看,只要稍加用心,就完全可以打造出一个"开箱即用"的、由智能体驱动的优秀监控系统。

案例研究：变更点监控

我将围绕一个我非常关心的问题来展开讨论：变更点的生产监控,例如二进制发布和配置推送。其核心思想是：你希望围绕系统的关键变更点进行专门的、密集的监控；这些变更点更有可能引发回归,因此如果你密切关注这些事件,就能限制其影响。引用 Google SRE 书中那句老生常谈的话："约 70% 的故障是由于在线系统的变更引起的。"

这是一个棘手的问题。我从 2023 年起就以某种形式在处理它，但一直难以取得实质性进展。通过与业内同行的交流，我了解到有一些方法可以把变点监测做得“不错”，但这些方法在很大程度上仍然依赖人做出正确的操作（例如，认真地给指标和告警打标签、定义精确的信号等），并且需要大量的组织投入。

更具体地说，要把变点监测作为平台工程的一部分实现“起飞”很难，原因如下：

你的第一反应可能是瞄准那些运维已经很到位且积极性很高的用户。然而，这些团队的发布过程已经基本是安全的，你并没有真正把运维水平线抬高多少。你在这里兜售的是减少苦活，这属于“锦上添花”，但本身并不是一阶的安全改进。对于积极性很高的团队来说，精确性更容易实现，但这也意味着变点系统要在召回率和延迟上与传统告警“竞争”。
你也可以选择面向服务的广大群体。换句话说，你做得很广，在一个选定子集的通用健康指标上让“所有服务”都默认开启。实际上，这些通用健康指标大多本质上就是充满噪声的。这种噪声会导致精确性较差和告警疲劳。
在大语言模型出现之前，也存在明显的精确性与延迟之间的权衡。在这个谱系上有：结构化日志（精确，但慢）、指标（粗粒度，但快）、以及告警（更粗粒度，召回率和精确率都很差，但“至少有总比没有好”）。

令人惊讶的是，智能体基本上“就”能把这个问题解决。智能体乐于运行大量查询，能够即时编写针对每次变更的查询，并且会无休止地扫描日志。这样一来，你就能以较低成本同时获得良好的精确性和召回率。在这个设置的基础版本中，你只需要具备把代码库（例如，用于推理配置的加载方式）和可观测性平台（例如，用于查看和监控实时生产状态）接入智能体的能力。

我做了一个完全符合上述思路的原型：一个根据服务代码提出监控方案的智能体、一个执行该方案的脚手架，以及一个对被触发的监控器进行调查的智能体，并配备升级到人工的路径。即使在这个早期原型中，我也能在我毫无了解的系统上检测到回归问题，其精确性和延迟是一年前不可能做到的。

在我对这个方案的迭代中，我发现纯粹依赖智能体循环并不是智能体化监控器的最佳形态。相反，一个允许智能体写出“如何监控”规范的脚手架，再配上一个用来确定性运行这些规范的确定性系统，能够产生显著更干净的信号，并大幅降低 token 用量。要说这个模式里有什么“独门秘诀”的话，那就是降噪启发式方法、引导智能体写出好规范的提示词，以及一个足够大的标注评估集，以便对进一步的微调进行验证。²

智能体在结构上天生就适合做监控

在这种模式流行之前，需要发生两个思维转变：

智能体实际上在监控上可以比人类做得更好。
监控智能体需要脚手架，就像软件开发生命周期的其他环节不得不为编码智能体做出适配一样。监控领域还尚未出现一个“Claude Code 时刻”。

一旦你做出这些转变，监控智能体相比人类操作员就有几个"不公平的优势"：

全天候跟踪一切的能力。如果 token 价格便宜，那么你所关注的任何指标回归以及任何可疑的日志行都可以被调查——而不仅仅是那些以前会上升到"人类注意力阈值线"以上的事件。智能体不需要"跟随太阳"。
Ability to fan out and investigate several paths toward resolving a production problem. Agents can parallelize investigations when multiple things go wrong at once, and coordinate quickly. This is already my go-to for incident triage: I just launch a bunch of agents to investigate several potential threads or theorized incident causes. Right now, this is human-driven, but there’s really no reason it couldn’t be agent-initiated in the future. You can elastically scale up a fleet of incident responders.
- 我们已经看到，这对安全事件正变得至关重要。智能体团队/集群/蜂群正被用于攻击性网络攻击，而防御者也开始建立类似的防御能力（例如 OpenAI 的Daybreak Blue、Anthropic 的Project Glasswing、Google 的Fairwind）。
Ability to respond faster to a problem than can a human. Agents can read code faster than humans. Agents can also query and digest metrics and log signals significantly faster. This speed doesn’t always translate into faster incident detection time; a human with a deep understanding of a system may still be faster at finding the right signal and intuiting the root causes. But to the extent that tacit knowledge can be recorded and made available to an agent, the agent will eventually beat the human on speed.
- 由此延伸，对于人类操作员经验不足的系统，智能体的"理解时间"会更短。

"一个新的运营卓越水平是有可能实现的。"

更加勤勉：你不会雇佣一个全职软件工程师来逐一查看某个服务的所有 Git 提交，挑出要监控的内容，并仅针对这些变更设置特殊的短期快速触发告警。然而，现在以每百万 token 几美分的成本就可以做到，并且这将成为行业标准。

持续改进性能：智能体可以监控性能，查看堆转储、堆栈跟踪和 CPU profile，并从它们发现的模式中提出优化建议。如有必要，将提议的改进置于 A/B 测试之后，并像对待服务的任何其他变更一样进行监控。

在某个案例中，我观察到几次 Astra/Opus 调查会话发现了一个常见热路径库中 50% 的堆节省和 30% 的延迟降低，而人类已经在优化该库上花费了相当大的精力。一旦你给一个足够强大的 LLM 一台虚拟机和要运行的基准测试，当代 LLM 的"爬山"能力是非凡的。

采取行动：到目前为止，我主要在讨论"只读"监控系统。当然，智能体不一定非得是"只读"的。在具备合适的框架和护栏的情况下，智能体绝对有未来能够采取一线行动来修复事件。这可以涵盖从范围明确的任务（如调整实例大小或轮换计算池），到确定性操作（如回滚配置变更或二进制文件），再到开放式任务（如定位根本原因、提出修复方案并动态重新部署）。显然，你交给智能体的控制越多，风险就越大，但考虑到过去 12 个月智能体能力的扩展程度，能够负责任地移交给智能体的写路径工作量必然会增加。真正自愈系统的前景令人振奋。

成本不再是限制因素。Luna/Haiku 级别的模型³现在已经是称职的图谱观察者。一家中等规模的科技公司可能可以以每天约 100 美元的成本监控其整个集群。初创公司规模的集群只需其中一小部分。相比人力成本，甚至是运行可观测性基础设施的成本，这都是微不足道的。

创造一个良性循环：如果做得好，代理监控会形成一个正反馈循环：编码代理让你能交付更多，监控代理让你能支持更多系统，进而腾出人类时间来指挥更多事情交付。人类越来越多地把时间花在"建造工厂"或"打理花园"上。

代理监控值得投入。不久之后，没有代理监控你的系统将是鲁莽之举。在行业其他玩家赶上之前，现在开始便能获得一种不公平的优势。

我的团队最近完成的一系列优化为我们节省了数百万美元的年度可观测性成本，而……那仅仅是仅我所在的团队在可观测性上花费的一小部分。 ↩︎
关于代理监控工具的设计，还有很多、很多内容可以写。这是我最近一段时间以来最强烈的"我们还非常早期"的感觉之一。根据原文，像 Anthropic 的"Claude Tag"这样的通用工具显然在代理监控方面已经做得相当不错。不过，根据我的观察，即使是少量的、专门针对监控的工具工程也能收获许多唾手可得的成果。 ↩︎
这里我指的是 GPT-6-Luna 和 Claude Haiku 5.5。 ↩︎