凌晨2点17分，数据库延迟警报一响起，多个AI代理同时响应的情况已不再是虚拟场景。有分析指出，每个代理都会做出各自看似正确的判断，但当这些决定相互冲突的瞬间，整个基础设施都可能崩溃。
思科系统平台与保障部门副总裁乔·瓦卡罗在SiliconAngle的投稿中解释说，下一代基础设施故障的形式可能不再是“某个东西坏了”，而是“一切按设计运行”所导致的。比如，性能管理代理增加数据库容量，成本管理代理认为这是过度分配而缩减实例，流量路由代理则设置绕行路径。每个个体的判断都合理，但结果可能是两分钟内数据库层就会宕机。
大型云故障中已出现类似模式
这种风险在AI代理全面普及之前，就已在实际故障案例中显现。亚马逊云科技的DynamoDB DNS事故，就是由两个不同的系统各自正常应用配置的过程中发生的。一方延迟反映了旧设置，另一方则基于最新设置进行清理工作。就在那一刻，延迟的系统覆盖了新设置，问题爆发。关键在于并非某个系统的错误，而是“时机”。
微软Azure Front Door的故障也类似。控制平面生成了错误的元数据，自动化系统正常将其阻断。随后清理流程也按预期运行，但却触发了隐藏在第三个组件中的漏洞，从而演变成故障。Cloudflare的机器人管理事故同样是因权限变更产生了重复查询结果，配置系统正常处理并生成了过大的文件。代理服务器根据预设的大小限制拒绝了该文件。每个系统都按规则运行，但组合的结果却是失败。
这些案例的共同点是，仅查看单一系统内部日志很难发现异常迹象。分析认为，当数十个代理以机器速度同时进行决策时，同类故障可能会更频繁、更复杂地出现。
现有自动化与“基于代理的基础设施”不同
自动调整服务器容量的自动伸缩、Kubernetes的工作负载迁移、重启故障服务的AIOps等自动化技术已广泛应用。不过这些系统通常是在预先定义的狭窄规则内运行。
而基于代理的基础设施则会观察情况，权衡成本和性能等相互冲突的因素，然后以机器速度做出判断。问题在于，企业试图同时在同一基础设施上运行数十个代理，而非一两个。在这种情况下，故障模式可能会从三个方面加剧。
第一，多个代理试图解决同一个问题，反而可能使情况恶化。例如，一个代理发现队列A过载，将任务转至队列B，另一个代理检测到队列B过载，又将任务转回队列A。两者的应对都正确，但合在一起就成了无限循环。
第二，代理很难区分其他代理的行为是“判断”还是“失误”。一方增加容量，另一方为节省成本而缩减，第一个再次将其视为问题并重新扩展，从而产生冲突。从外部看像是基础设施故障，但实际上更接近于协调失败。
第三，局部决策可能蔓延为整个系统的问题。管理服务A的代理的操作影响到服务B，服务B的代理又影响到服务C，以此类推。当运营团队开始调查时，初始条件早已消失，使得根因排查更加困难。
监控方式也必须改变
现有监控针对CPU使用率、内存、请求延迟、错误率等单个系统状态进行了优化。但在代理时代，所有系统都“正常”时，也可能因交互作用而发生故障。因此，现在重要的问题不再是服务A是否健康，而是A的变化引发了B、C、D的哪些行为。
此外，不仅要看代理做了什么，更应一同查看该代理基于什么数据以及为何做出那样的决定。为此，需要涵盖网络、计算、应用和数据的整体统一可见性。这意味着仅凭单个组件的指标是不够的，必须能够追踪依赖关系、时机以及各项决策如何在实时中相互关联。
经验丰富的站点可靠性工程师已通过变更冻结、分阶段部署、限制故障传播范围等方式管理部分风险。但在代理的速度下，人类可以介入的时间大大减少。归根结底，核心在于看不见的东西也无法协调。
在引入代理之前就应设计“交互可见性”
副总裁乔·瓦卡罗并不认为基于代理的基础设施本身是必须避免的风险。因为其响应速度提升、优化效率提高、运营负担减轻等优点显而易见。但他强调，未来的故障可能不是由于代理失败，而是因为它们“按设计运行得过于完美”。
因此，企业在部署之后才靠监控来补救问题的方法，不如在代理实际运行之前，就将交互结构作为设计约束条件加以考虑。否则，可能在凌晨2点17分，面对日志一切正常但系统却已停摆的局面。
TP AI 提示 本文使用了基于TokenPost.ai的语言模型进行摘要。可能遗漏了原文的主要内容或与事实有出入。