最近，Anthropic 的一篇博客文章中包含了一小段文字，这段话并不是文章的重点，但自从我读到它以来，它一直萦绕在我的脑海中：一个新的运营卓越水平是可能的。我们的团队大量使用 Claude Tag，这帮助我们监控系统的每个组件。例如，我们创建了 Slack 渠道，委派 Claude 专注于单个组件的健康状况。我们称这些 Claude 为“超级粉丝”。我们有一个 scion-daemon 超级粉丝，一个 scion-cache 超级粉丝，一个 Antique merge queue 超级粉丝，等等。它们可以访问我们的遥测和日志，像经验丰富的工程师一样，只需刷新图表并寻找任何异常。我们还有所有系统的传统警报，但我们的超级粉丝可以检测出微妙和新颖的问题，使这些警报显得相对单一。显然，这条道路是软件系统运营的未来。我在过去几周一直在思考使用代理进行监控，这段话使我对这些想法有了更清晰的认识。现代软件系统，如同编写它们的 LLM，一直在变得更加“成长”而非“设计”。是的，人类工程师通常仍然为系统提供高层次的设计和形状，且在目前，软件系统比 LLM 要更易于解释——因为如果你愿意，可以坐下来阅读代码。然而，随着编写和发布代码的数量以指数级增长，任何系统的运营人员对代码的实际了解程度正在下降。系统监控从来都不是一件容易的事情。市面上有一整套可观察性 SaaS 公司——例如 Sentry、Datadog、Splunk、Honeycomb 等。可观察性很昂贵。要做好这一点需要专业的人才技能，并依赖于在规模化的实际系统中积累经验。只有在行业中工作，才能真正发展这些技能。这是一个需要数年才能培养出初级工程师的领域。与 2026 年软件行业的其他似乎所有领域一样，系统监控有望因代理而发生重大变化。我……很惊讶我没有看到更多人写关于这个话题，特别是在当前“代理狂潮”的环境中。这个问题就在我们面前，它确实有效。许多初创企业试图做“AI SRE”，但来自从业者的书面记录却很少。但你并不需要一个完整的“AI SRE”来改善运营卓越，也不需要一个完善的 SaaS 产品。根据 Opus 5.5 / Astra 类模型，稍加注意，完全可以构建一个“只需工作”的代理驱动监控系统。案例研究：变更点监控 我将这个讨论基于一个我非常关心的问题：变更点的生产监控，例如二进制发布和配置推送。其思想是你希望在系统的关键变化点进行专门和密集的监控；这些变化点更可能引发回归，因此如果你密切监控这些事件，可以限制其影响。引用 Google SRE 书中的陈词滥调：“~70% 的停机时间是由于实时系统中的变更。”这是一个棘手的问题。从 2023 年起，我便开始以某种形式致力于这个问题，而推动它的进展很困难。与行业中的人们交谈后，我了解到有一些方法可以“好好”进行变更点监控，但这些方法在很大程度上仍然依赖于人类的正确操作（例如，认真标记指标/警报，定义精确的信号等），并需要相当大的组织投资。更具体地说，将变更点监控作为平台工程的一部分实现“起飞”是困难的，因为：你的第一反应可能是针对高志向的用户，他们已经拥有良好的运营姿态。然而，这些团队的部署大部分已经是安全的，因此你实际上并没有大幅提高运营水平。你在这里销售的东西是繁琐工作降低，这是“可有可无的”，但本身并不是一项第一阶的安全改进。对于高度有动机的团队，精确度更容易实现，但这意味着变更点系统在回忆率和延迟方面正在与传统警报“竞争”。另一方面，你可以瞄准广泛的服务群体。换句话说，你会选择“所有服务”，并选择一组通用健康指标。在实践中，这些通用健康指标大多数都是不可减少的噪音。这种噪音导致精度差和警报疲劳。在 LLM 出现之前，确实存在清晰的精度/延迟权衡。沿着这个光谱有：结构化日志（精确、慢）、指标（粗略、快）和警报（更加粗略，回忆率相当糟糕，精确度也相当糟糕，但“至少它是某种东西”）。令人震惊的是，代理在很大程度上仅凭“就”解决了这个问题。代理愿意运行大量查询，可以动态编写每个变更的查询，并且会扫描日志到令人厌烦的程度。