摘要：AI虽改变代码编写，但在基础设施部署上面临缺乏上下文、技术复杂及合规挑战。环境编排和预批准蓝图能提供结构和护栏，助力实现安全、快速的AI辅助基础设施交付。
AI虽改变代码编写，但在基础设施部署上面临缺乏上下文、技术复杂及合规挑战。环境编排和预批准蓝图能提供结构和护栏，助力实现安全、快速的AI辅助基础设施交付。
译自：What Does It Take for AI Agents To Deploy Infrastructure?
作者：Idan Yalovich
AI 正在改变开发人员编写代码的方式。这种改变的程度以及它是否完全积极是无休止争论的根源，但其影响已然存在。一旦 AI 代码变得更好，团队将更频繁地发布功能。
对于基础设施而言，情况并非如此。
部署和维护支持应用程序的环境，无论是用于测试还是生产，都是一个严重的瓶颈。大多数组织在任何东西投入生产之前仍然依赖工单队列和人工审查，而其中一些工作严重依赖于“部落知识”和几乎是手工匠人的工作。
因此，虽然 AI 可以生成看起来还不错的 Terraform，但云基础设施的管理方式仍然处于生成式 AI 时代之前。
为什么会这样？
每家公司都有不同的合规框架、架构和业务需求，这导致了不同的基础设施。这些信息不仅仅体现在基础设施即代码（IaC）中；它们存在于 DevOps、平台和安全团队的“部落知识”中。
要求 AI 代理启动一个数据库，它可能会为 Amazon Web Services (AWS) 关系数据库服务 (RDS) 实例生成有效的 Terraform 代码。但它不会知道：
这个数据库应该是多区域还是单区域？灾难恢复的复制策略是什么？哪些合规标准适用于这个数据集？如果没有组织上下文，AI 可能会生成技术上正确但在操作上危险的代码——配置错误、不合规或不安全。是的，你可以要求 AI 从你现有的基础设施设置中“学习”上下文，但这足够吗？
现代环境是相互关联的工具网络：Terraform、Helm、Ansible、云命令行界面 (CLI) 和自定义脚本。AI 可以为每一层生成代码片段，但正确地编排它们——以正确的顺序，并意识到依赖关系——则完全是另一个挑战。这就是可怕的 Terralith，而生成另一个这样的东西并不是一个好的开始。
基础设施并非独立部署。Kubernetes 集群依赖于虚拟私有云 (VPC) 网络、身份和访问管理 (IAM) 策略、密钥、监控集成等等。缺失或错误排序其中一个部分——或排序错误——都可能导致生产中断。
基础设施真正需要的是关注点分离，这样复杂性和依赖关系才能被解开，然后安全地部署。
与应用程序代码不同，错误的基础设施变更风险很高。一个失误就可能导致停机、安全漏洞或失控的云成本。
AI 代理本身不理解组织的合规义务、成本阈值或审批工作流。缺乏这种上下文，自主部署就会成为一种负担。
这就是为什么团队可能接受让 AI 生成基础设施代码，但不会让它部署这些代码。
为了弥补这一差距，AI 代理需要三个基本要素：
一组受控的预批准选项，而不是无限的配置可能性。明确的依赖关系定义，以了解要部署什么、按什么顺序以及在什么条件下部署。内置的“护栏”，以自动执行成本、安全和合规策略。简而言之：AI 不需要更多智能；它需要结构或蓝图。
这就是环境编排的未来所在。
为此，需要环境编排。
这种方法将原始的基础设施代码转化为可重用和版本化的蓝图，定义了如何安全地创建、修改和使用基础设施。同时，它保持了严格的关注点分离，实现了跨不同 IaC 工具的端到端自动化并维护了标准。这最终形成了编码了组织规则和依赖关系的标准化部署包。
在这一点上，AI 代理不会自行编写 Terraform，也不会创建部署工作流。它们也不会访问内部开发人员门户中编码的“上下文”。
相反，它们访问的是一个“蓝图”目录，一个固定的、不可变的选项菜单。
构建依赖关系的有向无环图 (DAG)，执行正确的部署序列。强制执行组织策略、成本限制和审批工作流。结果是安全、合规和可预测的基础设施交付，即使在 AI 代理参与其中时也是如此。
这种方法使目录成为基础设施如何部署的单一事实来源。它不是由代理推断出来的；而是由平台团队准备的。
哪些服务和配置已获批准。哪些参数和默认值可以安全使用。各组件如何相互依赖。因此，当开发人员请求一个暂存环境时，AI 代理无需猜测。它会选择一个预批准的蓝图，其中包含网络、安全组、Kubernetes 集群和数据库——所有这些都与公司策略保持一致。
AI 代理不再探索无限的配置空间。它是在受控框架内做出经过验证的选择。
重要的是，目录中的所有内容也应具有策略感知能力。DevOps 团队需要一次性定义标准。合规性是目录中所有内容的固有属性。
这意味着：
成本控制得到一致应用。安全策略内置于每次部署中。合规性要求在设计之初就得到强制执行。每个蓝图都经过版本控制，因此当 AI 代理部署数据库蓝图的 2.3 版本时，你会确切地知道正在部署什么——没有意外，没有偏差。
并非所有部署都应完全自主。你需要决定何时增加人工审查。这可能基于环境、影响范围、成本影响或合规性关键程度，或者你可能希望在所有情况下都应用人工审查。
这使得可以谨慎地从人工审查的部署开始，并随着信任的建立逐步增加 AI 的自主性。
并非所有基础设施任务都能从 AI 中受益。但在某些场景中，与蓝图和“护栏”协同工作的 AI 代理可以带来变革性的价值。
当监控工具检测到负载增加时，AI 代理可以利用环境编排动态扩展基础设施，根据工作负载类型、时间模式和成本效率选择最佳伸缩方法。
CPU 密集型任务需要更多计算资源？向上扩展。处理突发性工作负载？向外扩展。想要优化成本？在非高峰时段选择竞价实例。因为每次伸缩操作都使用经过认证的蓝图，因此结果是安全、合规且完全可审计的。
AI 辅助的自助服务是另一个重大胜利。开发人员无需等待数天才能处理完基础设施工单，他们可以用自然语言请求环境。他们可以要求 AI“为支付服务启动一个暂存集群”，然后 AI 会使用预批准的蓝图立即对其进行配置。
这种体验感觉是自主的，但流程仍然合规。开发人员行动更快，而平台团队则保持完全控制。
速度：功能创建和部署之间的时间差距从数天缩短到数分钟。安全：标准化蓝图确保每次部署都遵循经过测试的模式和经过验证的配置。智能：AI 代理在组织“护栏”内做出上下文感知的配置决策。这些能力共同重新定义了 DevOps 和平台团队的可能——这并非增量的效率提升，而是基础设施交付方式的根本性转变。
AI 代理已经改变了开发人员编写和审查代码的方式。下一个前沿是基础设施，但要实现这一目标，AI 不仅仅需要生成能力。它需要结构、上下文和“护栏”。
在这种新模型中，平台和 DevOps 工程师成为标准的架构师，将机构知识封装在蓝图中。AI 代理成为可靠的执行者，部署快速、合规且与业务对齐的基础设施。
来源：阿康聊科技