凌晨2点17分，数据库延迟警报响起，多个AI代理同时开始行动。负责性能的代理增加了容量，成本优化代理判断资源过剩而缩减实例，流量管理代理则重新设定了绕行路径。每个判断本身都“正常”，但警报指出结果可能是短短2分钟内的服务中断。
思科系统平台与保障部门副总裁乔·瓦卡罗（Joe Vaccaro）在《硅谷角度》的专栏文章中指出，未来的基础设施故障可能并非因为“某个东西坏了”，而是因为“一切都在按设计运行”。其解释是，如果只看单个日志，并没有错误，但多个代理的决策在极短时间内相互冲突，就可能导致整个系统崩溃。
已现端倪……AWS、Azure、Cloudflare案例
瓦卡罗判断，这类故障甚至在AI代理真正普及之前就已经出现了。他以去年发生的AWS、微软Azure和Cloudflare的案例作为典型例子。
AWS DynamoDB DNS故障发生在两个相互独立的系统各自正确运行的情况下。一个系统在应用旧配置时遭遇了延迟，另一个系统则在应用了新配置后进行了清理操作。问题在于，延迟的系统恰好在清理时间点覆盖了最新配置。原因并非单个系统出错，而是“时间冲突”。
Azure Front Door的故障也有类似的过程。控制区域生成了错误的元数据，自动化系统正常地将其阻断。之后的清理操作也按设计执行，但在这个过程中，唤醒了潜伏在另一组件中的漏洞。每一步都是正确的，但连接起来的顺序加剧了问题。
Cloudflare的机器人管理故障始于权限变更导致了重复的查询结果。配置系统正常处理了这一情况，生成了有效但过大的文件，而代理服务器也正常地应用了容量限制并拒绝了该文件。一个系统的“正常输出”与另一个系统的“正常限制”发生了冲突。
不同于自动化的“代理定义基础设施”
传统的自动化系统本身并非新概念。自动扩展可以调节服务器容量，Kubernetes可以重新分配工作负载，AIOps平台可以重启故障服务。只不过，这些自动化通常在预设规则和有限范围内运行。
相比之下，“代理定义基础设施”会观察情况，权衡成本与性能等相互冲突的因素，并以机器速度做出判断。问题在于，企业试图同时运行数十个代理，而非一两个。当所有代理在共享同一基础设施的情况下，在几秒钟内做出决策时，传统的故障模式非但不会消失，反而可能被更复杂地放大。
瓦卡罗解释说，这种风险通过三种方式扩大。首先，多个代理可能试图同时解决同一个问题，反而使情况恶化。例如，一个代理看到队列A过载，便将任务转移到B；而另一个代理看到B过载，又将任务转回A。每个代理都忠实于其观测值，但合在一起看，就成了一个无限循环。
其次，代理很难区分另一个代理的行为是“有意的决定”还是“需要修正的错误”。一方增加资源，另一方认为是浪费而缩减，接着第一个代理将此解读为性能下降又增加资源。从外部看，这像是基础设施问题，但实际上本质可能是协调失败，即“协作的缺失”。
最后，局部决策可能引发连锁反应，蔓延为系统全局性问题。管理服务A的代理的行为影响到服务B，而B的变化又波及C。等到运维团队着手调查时，每个代理当初做出判断时的条件很可能已经不复存在。这就是事后分析困难的原因。
仅凭传统监控不够
这种“代理故障”很难通过CPU使用率、内存占用率、请求延迟、错误率等传统指标来捕捉。这些工具本质上是为了显示单个系统内部哪里出了问题而设计的。但新问题在于，多个系统都正常运行，却因交互结果而导致失败。
因此，关键在于不能止步于查看服务A是否健康。必须在一个屏幕上同时了解A的变化如何触发B、C、D的行为，以及代理在那一刻是根据什么数据做出判断的。这意味着需要整合网络、计算、应用和数据层面，才能读取实时的连锁效应。
现场站点可靠性工程师（SRE）们早已通过变更冻结、分阶段部署、限制影响范围等方式，在一定程度上管理了此类风险。只不过，在以代理的运行速度下，人类能够介入的时间大大减少。归根结底，看不到就无法协调。
关键在于部署前的设计，而非部署后的应对
瓦卡罗并不认为代理定义基础设施本身是需要回避的风险。因为它带来的响应速度提升、运营负担减轻、资源优化等优势是显而易见的。但他主张，未来的核心不在于单个代理的性能，而在于设计阶段就提前验证：那些各自独立的正确决策，在实际运营环境中会以何种组合方式产生冲突。
最终，下一代基础设施故障很可能并非源于“误操作”，而是源于“过度正常运作的自动化”。如果企业将此仅仅视为部署后的监控问题，那么故障原因可能要到凌晨2点17分的日志中才能被事后追溯。随着AI代理的扩散速度加快，基础设施运维的决胜点将不再是单个功能，而是“交互可见性”。
TP AI 注意事项 本文使用基于TokenPost.ai的语言模型进行摘要。正文主要内容可能被遗漏或与事实不符。