每个Agent的决策看起来都对，但最终结果却是糟糕的。这个局怎么破

现在是凌晨 2:17，你的应用监控系统标记出了数据库延迟升高的警报。在你的值班工程师还没读完这条警报时，三个代理（Agents）已经做出了响应。

性能代理将数据库容量增加了一倍。成本代理看到看似过度的资源供给，开始合并数据库实例。路由代理则将流量重新导向数据库层。每一个决策都被记录在案。每一个决策在孤立来看时都完全合理。每一个决策都正是该代理被设计出来要做的事。

到了凌晨 2:19，你的数据库层瘫痪了——这并不是因为什么东西坏了，而是因为一切都“正常工作”了。没有任何一个代理的日志中会显示错误。要重构出这短短两分钟内发生的一切（其中每个单独的决策都是正确的，但组合在一起却是灾难性的），将花费整整三天时间。

这就是下一类基础设施故障的模样。

它已经在发生了

代理会放大的这种故障模式，并不一定始于人工智能。去年发生的三起重大事故就清晰地证明了这一点：

AWS DynamoDB DNS 故障 —— 两个独立的系统各自都在正常工作。一个系统应用了较旧的配置并遇到了延迟；另一个系统应用了较新的配置并触发了清理程序。延迟的系统恰好在新配置被清理程序移除的那一刻覆盖了它。故障完全存在于两者之间的时间差中。

Azure Front Door 故障 —— 控制平面生成了错误的元数据，一个自动化系统正确地将其拦截。清理流程按设计正常工作，但却触发了第三个组件中一个潜伏的漏洞。故障源于一系列正确操作的顺序。

Cloudflare 机器人管理故障 —— 一次权限变更导致了重复的查询结果。配置系统正确地处理了这些结果，生成了一个有效但体积过大的文件。代理服务器正确地执行了其大小限制并拒绝了该文件。一个系统的正确输出超出了另一个系统的正确约束。

从任何一个单一系统的内部来看，这些故障都是隐形的。现在，想象一下同样的模式在数十个代理之间上演，它们以机器的速度同时做出决策。

超越自动化

自动化管理基础设施并不是新鲜事。自动扩缩容调整服务器容量，Kubernetes 移动工作负载，AIOps 平台重启失败的服务。这些系统都在狭窄且定义明确的边界内遵循预定的规则。

但“代理定义的基础设施”是不同的。它观察条件、权衡利弊，并以机器速度做出判断。而且，组织部署的不仅仅是一两个代理；它们有数十个在同时工作，都在几秒钟内对共享基础设施做出决策。导致 AWS、Azure 和 Cloudflare 故障的那种交互模式在这种环境中并不会消失；它们会以三种特定的方式成倍增加：

多个代理解决同一个问题反而会让情况更糟。 一个代理看到队列 A 不堪重负，便将任务分流到队列 B。另一个代理看到队列 B 不堪重负，又将流量分流回队列 A。两者都是对自己观察到的情况做出正确响应，但合在一起，它们制造了一个双方都无法单独解决的死循环——这与金融市场中的“闪崩”以及自动扩缩容系统中的资源颠簸背后的动态如出一辙。

代理无法区分“错误”和“决策”。 当一个代理看到另一个代理的行动时，它面临着一个无法可靠回答的问题：这个举动是有意为之还是出错了？如果是有意为之，逆转它会造成混乱。如果是错误，修复它就是它的职责所在。如果没有协调机制，代理最终会互相“打架”；一个将容量调高，另一个将其调低，第一个又将其调回。每一个日志都显示出完全理性的行为。从外部看像是基础设施问题，实际上却是协调失败。

局部决策演变成系统性问题。 管理服务 A 的代理影响了服务 B。服务 B 的代理做出响应，进而影响了服务 C。等到你的团队开始调查时，驱动每个决策的初始条件可能已经不复存在。事后复盘就像是在解一个拼图，而其中一半的拼图片形状已经改变了。

凌晨 2:17 的场景同时击中了这三个方面，而且没有任何人的日志显示有任何异常。这就是共同点：除非你关注正确的指标，否则这些故障在为时已晚之前都是隐形的。

碎片化的认知

在生产环境中加入足够多的代理，潜在交互模式的数量并不会稳步增长；每增加一个代理，每扩大一次它们的权限范围，这些模式就会呈复合式增长。

传统监控是为不同的问题而构建的。CPU 利用率、内存使用量、请求延迟和错误率能告诉你单个系统内部何时发生故障。它们并不是为了向你展示当多个系统都表现正常，却以集体产生故障的方式相互作用时会发生什么而设计的。

需求已经发生了根本性的变化。问题不再仅仅是“服务 A 是否健康”，而是“对服务 A 的更改如何触发服务 B、C 和 D 中的行动”。重要的不仅仅是代理做了什么，还有它在做出决策时正在观察什么。

回答这些问题需要跨越网络、计算、应用和数据的可见性，并对一个领域的行动如何实时在其他领域引发连锁反应拥有统一的视图。事故之所以变得可诊断，并不是通过更好的组件指标，而是通过观察依赖关系、时间点和个体决策如何组合成故障。

经验丰富的站点可靠性工程师（SRE）已经通过变更冻结、分阶段发布和爆炸半径（blast radius）控制来管理其中的一些风险。但在代理的速度下，这个时间窗口已经关闭了。同样的直觉依然适用，但你无法协调你看不见的东西。

接下来会发生什么

代理定义的基础设施并不是需要规避的风险，而是一种需要管理的变革。更快的响应时间、更好的优化和更少的运维负担，这些好处是真实存在的。

代理引发的故障并不是因为代理发生了故障，而是因为它们正如预期那样工作了。保障机制必须考虑到在 生产环境中，相互独立的正确决策是如何组合在一起的。这使得“交互可见性”不再是一个部署后才去解决的监控问题，而是一个设计约束。你必须在代理上线之前就为此做好构建，否则你就只能在凌晨 2:17 去调试它。