智能体监控

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