智能监控提升系统运维
Agentic Monitoring
通过使用Claude Tag等工具，团队实现了对系统各组件的监控，创建了专注于单一组件健康的“超级粉丝”监控代理，这些代理能检测传统警报难以发现的细微和新问题，显著提升软件系统运维水平。
一篇 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年开始以某种形式研究它，但一直难以取得进展。通过与行业内的各界人士交谈，我了解到有一些方法可以‘很好地’进行变化点监控，但这些方法在很大程度上仍然依赖于人类来做正确的事情（例如，勤勉地标记指标/警报，精确地定义信号等），并且需要大量的组织投入。
更具体地说，将变化点监控作为平台工程的一部分实现‘起飞’之所以困难，是因为：
- 你的第一反应可能是针对那些高度积极且已经拥有良好运维态势的用户。然而，这些团队的发布已经 mostly 安全，实际上并没有 much 提升运维水位。这里你要推销的是 减轻负担，这虽然‘不错’，但本身并不是首要的安全改进。对于高度积极的团队来说，实现精确性更容易，但这意味着变化点系统需要在召回率和延迟方面与传统的警报‘竞争’。
- 或者，你可以选择针对广泛的服务群体。换句话说，你 go super wide，选择‘所有服务’，并在选定的通用健康指标子集上进行 opt in。在实践中，大多数这些通用健康指标都是 irreducibly noisy 的。这种噪声导致精确性差和警报疲劳。
- 在 LLMs 之前，也存在一个明显的精确性/延迟权衡。在这个谱系上包括：结构化日志（精确，慢），指标（粗略，快），以及警报（甚至更粗略，召回率 pretty bad，精确性 pretty bad，但‘至少它是什么’）。
令人震惊的是，代理 largely “just” 解决了这个问题。代理很乐意运行大量的查询，可以现场编写 per-change 查询，并且可以 ad nauseam 地扫描日志。结果，你可以以低成本同时获得良好的精确性和召回率。在这个基本设置版本中，你只需要能够将你的代码库（例如，以推理配置消耗）和你的可观察性堆栈（例如，以查看和监控实时生产状态）连接到代理。
我针对这个问题的原型：一个基于服务代码提出监控计划的代理，一个执行该计划的脚手架，以及一个调查触发的监控器的代理，以及一个升级路径到人类。即使在这样一个早期的原型中，我也能够以去年不可能实现的精确性和延迟，检测到我对系统 零 理解的回归。
在我对这个问题的迭代中，我发现纯代理循环并不是 agentic 监控的最佳形状。相反，一个允许代理编写监控规范的 harness，以及一个确定性地运行这些规范的系统，可以产生 significantly cleaner signals，并 dramatically 降低 token 使用。如果在这个模式中有‘秘密酱汁’，它就在噪声减少启发式算法，让代理编写良好规范的提示，以及一个足够大的标记评估集来验证进一步的调整。2
代理在结构上非常适合监控
在这个模式 catch on 之前，需要发生两次心态转变：
- 代理实际上可以比人类做得更好的监控工作。
- 监控代理需要脚手架，就像其他软件开发生命周期为了适应编码代理而必须适应一样。还没有出现过‘Claude Code moment’的时刻用于监控。
一旦你做出这些转变，监控代理在多个方面比人类操作员具有“不公平的优势”：
- 能够全天候24/7跟踪所有内容。如果代币很便宜，那么你关心的任何指标回归以及任何可疑的日志行都可以进行调查——而不仅仅是之前会超过“人类注意力截止线”的事件。代理不需要 “追逐太阳”。
- 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 提交，挑选出要监控的内容，并对这些更改做出特殊的短期快速触发警报。然而，现在每百万代币几美分就可以做到，并将成为行业标准。
持续改进性能：代理可以监控性能，查看堆转储和堆栈跟踪以及 CPU 分析，并根据他们发现的模式提出优化建议。如有必要，将建议的改进放在 A/B 测试后面，并像监控服务的任何其他更改一样进行监控。
有一次，我观察到几次 Astra/Opus 调查发现，人类已经花费了相当大的努力来优化一个常见的热点路径库，该库的堆内存节省了 50%，延迟降低了 30%。一旦你给一个足够强大的 LLM 一个虚拟机和一个基准来运行，当前一代 LLM 的“爬山”能力非常惊人。
采取行动：到目前为止，我主要讨论的是“只读”监控系统。当然，代理不必是“只读的”。在正确的 harness 和 guardrails（约束条件）到位的情况下，代理将能够在前线采取行动来纠正事件。这可能涵盖从范围明确的管理任务（如调整实例大小或旋转计算池）到确定性操作（如回滚配置更改或二进制文件）再到开放式任务（如根本原因分析错误、提出修复方案以及即时重新部署等）。显然，你交给代理的控制权越多，风险就越大，但考虑到代理能力在过去 12 个月中的扩展程度，可以负责任地交给代理的写路径工作肯定会增加。真正自愈系统的承诺令人兴奋。
成本不再是限制。 Luna/Haiku 级别的模型3现在能够胜任图启动工作。一个中等规模的技术公司可能每天只需花费大约 100 美元就能监控其整个舰队。初创规模的舰队将只是其中的一小部分。与人力成本相比，甚至与运行可观察性的基础设施成本相比，这都微不足道。
创建良性循环：如果做得好，代理式监控会形成一个积极的反馈循环：编码代理让你能够发布更多代码，监控代理让你能够支持更多系统，反过来又释放出人类时间来指导更多事情发布。人类越来越多地花费时间“构建工厂”或“照料花园”。
代理式监控值得投资。很快，没有代理监控你的系统就会变得鲁莽。直到整个行业都跟上，现在开始就能获得不公平的优势.
来源：Hacker News · benjamincongdon.me