为什么人工智能代理在缺乏云基础设施上下文时会陷入困境？

仅仅为人工智能代理提供更强的模型，并不足以让它们独立管理云基础设施。env zero 赞助文章所强调的问题，在于缺少一种运行上下文，将基础设施即代码（IaC）工具所描述的应有状态，与云中实际运行的状态连接起来。

当代理基于 IaC 文件或单一信息源工作时，它可能只看到某个独立资源，却不知道该资源与应用、治理策略或安全和成本要求之间的关系。因此，代理可能提出一个局部看来正确的变更，但该变更会造成违规，或影响其可用上下文中未显示的其他组件。

应用程序编程接口税

代理需要持续查询云应用程序编程接口，以探索当前状态。但这种模式会带来文章所称的“API 税”：请求速率限制、查询链失败、延迟和成本增加，以及在工具争夺同一容量时影响 CI/CD 流水线或自动扩展等敏感操作的可能性。

代理的工作方式不同于人类用户；人类倾向于提出明确的问题，而代理可能会探索一长串查询。文章援引该公司首席执行官 Steve Corndell 的例子：某代理完成了 90 次查询，却在第 91 次查询时失败，迫使其重新执行整条查询链。在这种情况下，损失不仅限于失败的查询，还会因重复已经完成的工作而被放大。

这一理念并不建议取消实时查询，而是建议对其进行智能分配。可以将所有权等相对稳定的信息保存在同步上下文中，并按照适当频率更新；对于需要了解当前状态的问题，则限定使用直接查询。目标是在保留运行信息准确性的同时，减少重复请求。

从声明的意图到运行现实

文章描述了一种上下文层，将声明的基础设施数据与实际资源发现结合起来，并将其与应用、策略、所有权以及环境之间的边界关联起来。假定本体层或知识图谱能够统一通常分散在状态文件、标签、电子表格、控制面板中直接执行的变更以及未记录知识中的信息。

一个假设案例表明，Wiz 之类的工具可能会强制执行要求多个实例的高可用策略，而仅依赖 IaC 的代理看到的却是单个实例，因此无法意识到违规。将这些数据与应用和策略上下文关联起来，可以让代理在提出修复建议之前评估影响。

完整控制环路

env zero 提出一种模型：先捕获声明的意图，然后发现实际状态、匹配两种状态、检查策略、以合并请求的形式提出变更供审核和执行，最后再次检查，以验证偏差或问题是否已经消除。数据层可以连接 Terraform、OpenTofu 和 Pulumi 等执行工具。

该公司将 EZ Control 描述为一种自主控制环路，用于连接声明状态与发现状态，在策略控制下提出或执行修复，然后验证变更是否成功。该产品目前处于早期访问阶段，公司计划最迟于 2026 年 12 月底普遍推出；因此，所描述环路中的部分要素仍是 env zero 正在构建的能力。

为什么这一模型很重要？

这一方案的实际价值不只在于发现问题，还在于完成整个流程，直到验证问题已经解决。停留在告警阶段的工具会把最困难的步骤留给工程师，而文章以修复时间衡量成功，也就是从确定需要采取行动的问题，到确认变更已经修复该问题之间的时间。

不过，这一愿景仍与赞助公司的主张以及产品的早期阶段有关，来源没有提供关于客户表现或成本和延迟降低幅度的独立数据。此外，上下文层并不会消除审核和策略控制的必要性，反而会使其成为任何能够在云环境中执行实际变更的自动化系统的核心组成部分。