用智能体做系统监控：从 Anthropic 的 superfans 到变更点监控原型

最近 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年起就以某种形式在做这件事，但一直很难取得进展。通过与业内各方人士交流，我了解到有一些方法可以把变化点监控做得“很好”，但这些方法在很大程度上仍然依赖人去做正确的事（例如勤勉地给指标/告警打标签、定义精确的信号等），并且需要大量的组织投入。

更具体地说，作为平台工程的一部分，变化点监控要实现“起飞”之所以困难，是因为：

你的第一直觉可能是瞄准那些已经具备良好运维姿态、积极性很高的用户。然而，这些团队的发布流程本来大多就是安全的，你实际上并没有把运维水位线抬高多少。你在这里卖的东西是减少苦役，它属于“锦上添花”，本身并不是一阶的安全改进。对于积极性高的团队，精确度更容易实现，但这意味着变化点系统要在召回率和延迟上与传统告警“竞争”。
你也可以转而瞄准广大的服务群体。换句话说，你铺得极宽，在一组选定的通用健康指标上选择“所有服务”。在实践中，这些通用健康指标大多具有不可约的噪声。这种噪声导致精确度差和告警疲劳。
在LLM出现之前，也存在明确的精确度/延迟权衡。沿着这个谱系有：结构化日志（精确、慢）、指标（粗糙、快）和告警（更粗糙，召回率相当差、精确度也相当差，但“至少有点东西”）。

令人惊讶的是，智能体在很大程度上“只是”解决了这个问题。智能体乐于运行大量查询，能够即时编写针对每次变化的查询，并且会不厌其烦地扫描日志。结果是，你可以低成本地同时获得良好的精确度和召回率。在这种设置的基本版本中，你只需要能够将你的代码库（例如用于推理配置消费）和你的可观测性栈（例如用于查看和监控实时生产状态）连接到智能体。

我已经做了一个正是这样的原型：一个根据服务代码提出监控计划的智能体、一个执行该计划的脚手架，以及一个调查被触发监控项的智能体，并带有升级到人工的路径。即使在这个早期原型中，我也能够以一年前不可能实现的精确度和延迟，检测出我完全不了解的系统中的回归。

在我对此的迭代中，我发现纯智能体循环并不是智能体化监控的最佳形态。相反，一个允许智能体编写如何监控的规范的执行框架，再加上一个运行这些规范的确定性系统，能产生明显更干净信号，同时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 剖析，并根据发现的模式提出优化建议。如有必要，将建议的改进置于 A/B 测试之后，并像对待服务的任何其他变更一样进行监控。

在一个实例中，我观察到 Astra/Opus 的几次调查发现，在一个人类已经花费了不小精力优化的常见热路径库中，堆内存节省了 50%，延迟降低了 30%。一旦你给一个足够强大的 LLM 一台虚拟机和可运行的基准测试，当前代际 LLM 的“爬山”能力就令人惊叹。

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

成本不再是限制。Luna/Haiku 级模型³现在已能胜任盯着图表看的工作。一家中等规模的科技公司很可能能以每天约 100 美元的成本监控其整个集群。初创规模的集群成本只是其中一小部分。与人力成本，甚至与运行可观测性基础设施的成本相比，这微不足道。

建立良性循环：如果做得好，智能体监控会形成正反馈循环：编码智能体让你能交付更多，监控智能体让你能支撑更多系统，这反过来又释放出人的时间，去指挥更多要交付的东西。人类会越来越多地把时间花在“建造工厂”或“打理花园”上。

智能体监控值得投入。很快，不让智能体监控你的系统就会是一种鲁莽之举。在业界其他公司赶上之前，现在就开始行动会带来不公平的优势。

我的团队最近完成的一组优化，为我们每年节省了数百万美元的可观测性成本，而……这仅仅我所在的团队在可观测性上花费的一小部分。 ↩︎
关于智能体监控框架的设计，还可以写很多很多。这是我近来最强烈的“我们还处在早期”的感受之一。正如原帖所说，像 Anthropic 的“Claude Tag”这样的通用框架显然已经在智能体监控上做得很好。然而，根据我所见，哪怕只做一点针对监控的框架工程，也能收获大量唾手可得的成果。 ↩︎
这里我指的是 GPT-6-Luna 和 Claude Haiku 5.5。 ↩︎