A最近的一篇 Anthropic 博客文章包含了一小段话，完全不是那篇文章的重点，但自从我读到它之后，它就一直在我脑海里盘旋：
运营卓越可以达到一个新的层次。我们的团队大量使用 Claude Tag，这帮助我们监控系统的每个组件。例如，我们创建了 Slack 频道，让 Claude 专注于单个组件的健康状态。我们把这些 Claude 称为“超级粉丝”。我们有一个 scion-daemon 超级粉丝、一个 scion-cache 超级粉丝、一个 Antique 合并队列超级粉丝，等等。它们可以访问我们的遥测数据和日志，表现得像一位经验丰富的工程师，除了刷新图表和寻找任何异常之外无事可做。我们也有针对所有系统的传统告警，但我们的超级粉丝能够检测到微妙而新颖的问题，相比之下这些告警显得过于单一。
这显然就是软件系统运维的前进方向。过去几周我一直在思考用智能体进行监控，而这段话让我的一些想法变得清晰起来。
现代软件系统，就像编写它们的 LLM 一样，正变得越来越“生长而成”而非“设计而成”。是的，人类工程师通常仍然给出系统的高层设计和形态，而且是的，软件系统（目前）比 LLM 可解释得多——因为如果你愿意，你可以坐下来直接阅读代码。然而，随着编写和交付的代码量呈指数级增长，任何系统的人类操作者所拥有的真正“亲眼看过代码”的知识量正在减少。
系统监控从来都不容易。有一整个可观测性 SaaS 公司的行业——Sentry、Datadog、Splunk、Honeycomb，仅举几例。可观测性很昂贵。1要做好它需要专门的人类技能组合，并依赖于在真实系统上大规模运维所积累的经验。人们实际上只能通过业界工作来培养这些技能。这是一个需要花费数年时间培训初级工程师的领域。
就像 2026 年软件行业里几乎一切事物一样，系统监控也因智能体而即将迎来一次阶跃式变化。我……很惊讶居然没看到更多人写这个话题，尤其是在当下这股“智能体狂热”的氛围里。它就明明白白摆在我们所有人面前，而且它确实管用。已经有一批初创公司在尝试做“AI SRE”，但来自实践者的文字却少之又少。
但你其实并不需要一个完整的“AI SRE”来提升运维卓越度，也不需要为此打造一个成熟的 SaaS 产品。到了 Opus 5.5 / Astra 这一级别的模型，只要稍加用心，完全有可能做出一个“开箱即用”的、由智能体驱动的好用监控系统。
案例研究：变点监控
我将用一个我格外关心的问题来展开讨论：生产环境中的变点监控，比如二进制发布和配置推送。其思路是，你希望对系统的关键变更点做专门、密集的监控；这些变点更容易触发回归，因此如果你密切监控这些事件，就能限制其影响。引用 Google SRE 书中那句老生常谈的话：“约 70% 的故障源于对在线系统的变更”。
这是一个棘手问题。我从 2023 年起就以某种形式在做这件事，一直很难推动起来。通过与业内各方人士交流，我了解到确实有办法把变点监控“做好”，但这些方法在很大程度上仍依赖人去做正确的事（比如勤勉地给指标/告警打标签、定义精确的信号等），并且需要大量的组织投入。
更具体地说，把变点监控作为平台工程的一部分做到“起飞”很难，原因在于：
- 你的第一反应可能是瞄准那些已经具备良好运维姿态、积极性很高的用户。然而，这些团队的发布本来大多就是安全的，你实际上并没有把运维水位线抬高多少。你在这里卖的东西是减少繁琐劳动，这属于“锦上添花”，但本身并非一阶的安全改进。对于积极性高的团队来说，精确率更容易实现，但这意味着变更点系统在召回率和延迟上是在与传统告警“竞争”。
- 你也可以选择面向广泛的服务群体。换句话说，你采取超宽范围，在选定的通用健康指标子集上选择“所有服务”。在实践中，这些通用健康指标大多具有不可消除的噪声。这种噪声会导致较差的精确率和告警疲劳。
- 在 LLM 出现之前，同样存在明显的精确率/延迟权衡。沿着这一谱系有：结构化日志（精确、慢）、指标（粗略、快）和告警（更粗略，召回率相当差、精确率也相当差，但“至少有点用”）。
令人惊讶的是，智能体在很大程度上“仅仅”就解决了这个问题。智能体乐于运行大量查询，能够即时编写针对每次变更的查询，并且会不厌其烦地扫描日志。因此，你可以低成本地同时获得良好的精确率和召回率。在这种设置的基本版本中，你只需要能够将你的代码库（例如用于推理配置的消费情况）和你的可观测性技术栈（例如用于查看和监控实时生产状态）连接到智能体。
我针对这一思路做了原型验证：一个根据服务代码提出监控方案的智能体、一个执行该方案的脚手架，以及一个调查被触发监控项的智能体，并带有升级到人工的路径。即使在这个早期原型中，我也能够检测到我完全不了解的系统中出现的回归，其精确率和延迟在一年前是不可能实现的。
在对此的迭代中，我发现纯智能体循环并不是智能体化监控的最佳形态。相反，一个允许智能体编写监控规范的 harness，再加上一个用于运行这些规范的确定性系统，能产生明显更干净的信噪比，同时 token 用量大幅降低。如果说这种模式中存在“秘方”，那就在于降噪启发式、让智能体编写良好规范的提示词，以及一个足够大、可用于验证进一步调整的带标注评测集。2
智能体在结构上非常适合监控
在这种模式流行起来之前，需要发生两个思维方式的转变：
- 智能体在监控方面实际上可以比人类做得更好。
- 监控智能体需要脚手架，就像软件开发生命周期的其余部分必须为编码智能体做出适配一样。监控领域还没有出现属于自己的“Claude Code 时刻”。
一旦你完成这些转变，监控智能体相对于人类操作员就拥有若干“不公平优势”：
- 能够全天候 24/7 追踪一切。如果 token 足够便宜，那么你关心的任何指标回归以及任何可疑的日志行都可以被调查——而不仅仅是那些过去会越过“人类注意力阈值”的事件。智能体不需要“跟随太阳”。
- 能够并行展开并调查多条解决生产问题的路径。当多个问题同时出错时，智能体可以并行调查，并快速协调。这已经是我做事故分诊的首选方式：我只需启动一批智能体，去调查若干潜在线索或推测的事故原因。目前这仍由人类驱动，但未来完全没有理由不能由智能体发起。你可以弹性地扩展一支事故响应者队伍。
- 我们已经看到，这对安全事件正变得至关重要。智能体团队/集群/蜂群正被用于进攻性网络攻击，而防御方也开始构建类似的防御能力（例如 OpenAI 的Daybreak Blue、Anthropic 的Project Glasswing、Google 的Fairwind）。
- 能够比人类更快地响应问题。智能体读代码比人类快。智能体查询和消化指标与日志信号的速度也显著更快。这种速度并不总能转化为更快的事故检测时间；一个对系统有深入理解的人类，在找到正确信号并直觉判断根因方面可能仍然更快。但只要隐性知识能够被记录并提供给智能体，智能体最终将在速度上胜过人类。
- 推而广之，对于操作人员经验并不丰富的系统来说，智能体达到“理解”所需的时间会更短。
“有望实现全新水平的运营卓越。”
更加勤勉：你不会花钱请一位全职软件工程师去翻遍某个服务的所有 Git 提交，从中挑出要监控的内容，并专门针对这些变更设置短期的快速触发告警。然而，如今每百万 token 只需几美分就能做到这一点，而且这将成为行业标准。
持续提升性能：智能体可以监控性能，查看堆转储、堆栈跟踪和 CPU 性能剖析，并根据发现的模式提出优化建议。如有必要，将建议的改进置于 A/B 测试之后，并像对待服务的任何其他变更一样进行监控。
在一个实例中，我观察到 Astra/Opus 的几次调查就发现，在一个人类已经投入相当多精力优化过的常用热路径库中，堆内存节省了 50%，延迟降低了 30%。一旦给足够强大的 LLM 一个虚拟机和可运行的基准测试，当前代际 LLM 的“爬山”能力就非常惊人。
采取行动：到目前为止，我主要讨论的是“只读”监控系统。当然，智能体不必是“只读”的。有了合适的运行框架和防护措施，未来智能体肯定能够采取一线行动来修复事故。这可能涵盖从范围明确的操作任务（如调整实例大小或轮换计算池），到确定性操作（如回滚配置变更或二进制文件），再到开放式任务（如定位缺陷根因、提出修复方案并即时重新部署）。显然，交给智能体的控制权越多，风险就越大，但考虑到过去 12 个月智能体能力的扩展幅度，可以负责任地交给智能体的写路径工作量必然会增加。真正自愈系统的前景令人兴奋。
成本不再是限制。Luna/Haiku 级模型3现在都成了盯着图表看的行家。一家中等规模的科技公司很可能只需每天 100 美元左右，就能监控其整个机群。初创公司规模的机群则只需其中很小一部分。与人力成本，甚至与运行可观测性基础设施的成本相比，这都微不足道。
创建良性循环：如果做得好，智能体监控会形成正反馈循环：编码智能体让你能交付更多，监控智能体让你能支撑更多系统，这反过来又释放出人的时间，去指挥更多要交付的东西。人类越来越多地把时间花在“建造工厂”或“照料花园”上。
智能体监控值得投入。很快，不安排智能体监控你的系统就会显得鲁莽。在行业其他部分赶上之前，现在就开始会带来不公平的优势。