AI基础设施自动化：从代码生成到风险自愈闭环实践

引言：AI能生成基础设施，但谁来治理它？

AI已经在基础设施即代码（Infrastructure as Code, IaC）领域展现出惊人的能力。IaC是一种通过机器可读的定义文件来管理和配置计算基础设施的方法，其核心在于将基础设施的期望状态用代码表达，使其具备版本控制、代码审查、自动化测试等软件工程实践的优势。借助前沿大模型，我们生成Terraform、OpenTOFU、策略文件和配置的速度远超以往。Terraform由HashiCorp于2014年发布，使用HCL（HashiCorp Configuration Language）作为声明式语言，支持多云环境的资源编排；而OpenTOFU则是2023年在HashiCorp将Terraform许可证从MPL变更为BSL后，由Linux基金会托管的社区分叉版本，旨在保持完全开源。

然而，Harness的产品团队在近期的技术分享中提出了一个更深层的问题：当基础设施被更快地创建出来后，谁来治理这些基础设施？

当基础设施发生变更、产生漂移（drift）、变得高风险或成本失控时，系统能否真正主动地采取行动？这正是从代码生成走向风险预测与自动愈合的完整闭环所要解决的核心命题。

问题的本质：状态被定义，却未被持续强制执行

从「Day 1运维」到混乱的现实

多年来，行业在「Day 1运维」上不断精进。Terraform和OpenTOFU带来了声明式基础设施，CI/CD与GitOps带来了可重复性和自动化。但现实远比这复杂：多种工具、多份状态、控制台的手动改动、配置漂移，以及「代码声明应该存在什么」和「实际运行了什么」之间的巨大鸿沟。

配置漂移是指基础设施的实际运行状态与其代码定义的期望状态之间出现偏差的现象。漂移的来源多种多样：运维人员通过云控制台直接修改资源（即ClickOps）、自动伸缩策略的副作用、第三方服务的集成变更、甚至云提供商自身的API行为变化。漂移的危害在于它破坏了IaC的核心承诺——代码即真相。当漂移累积到一定程度，团队将无法安全地执行terraform apply，因为变更计划可能意外覆盖生产环境中已经生效的关键配置，导致服务中断。

实际服务客户时看到的最大断层，是平台工程师所提供的东西与实际被消费的东西之间的脱节。例如，某客户希望设置并强制使用「铺装路径」（paved paths），但总有一部分用户遵循，另一部分用户绕过。铺装路径是平台工程中的核心设计理念，源自Spotify等公司的实践——平台团队为开发者提供经过验证、内置最佳实践的标准化路径，使得「做正确的事」比「走捷径」更容易。Netflix将这一理念总结为'make the right thing the easy thing'。然而现实中，总有开发者因特殊需求或时间压力绕过这些路径，这时就需要一个控制平面来盘点哪些资源合规、哪些不合规，并进行干预。

每个工具都正确，系统整体却未必正确

这里揭示了一个反直觉的洞察：每个环节独立来看可能都很强。IaC工具知道自己的声明状态，Ansible知道要应用的配置，CI/CD知道被要求执行什么，安全治理工具也知道自己负责的策略。但这些工具的局部正确，并不意味着系统整体的正确。

于是我们陷入了「多个真相来源」的困境：

• Terraform状态可能与实际基础设施不符
• 配置可以在缺乏基础设施上下文的情况下变更
• 策略虽然存在却只在孤立的检查点生效

问题的关键不在于需要一个更好的单点工具，而在于——状态虽被定义，却没有在整个系统中被持续强制执行。

解决思路：让治理与系统一同流动

从「假定控制」到「强制控制」

AI基础设施自动化的核心解法是：控制必须随系统一同流动。在控制平面的加持下，期望状态被持续对账（reconcile），上下文与所有权随变更一同传递，策略在基础设施的全生命周期——从供应到退役——被贯穿执行。

有意思的是，这一理念正在全行业涌现。GitHub描述了开发者从「编码者」向「编排者」转变的趋势；OpenTofu开始支持人类可读与机器（Agent）可读的双重输出；HashiCorp也在HCP Terraform中新增了跨生命周期阶段强制执行策略的HCL Terraform策略框架。这些信号共同指向一个方向：治理正在被前移，并成为生命周期本身的一部分。

将治理内嵌为工作流的一环

在实践层面，核心强调的是「铺装路径/黄金路径」模式。与其让治理站在基础设施工作流的旁边或并行运行，不如让它成为工作流的组成部分：

1. 初始化
2. 运行Checkov、TFLint、tfsec等安全扫描
3. 生成plan
4. post-plan扫描
5. 理解策略与成本影响
6. 在必要时引入审批
7. 最终应用变更

这三个安全扫描工具代表了IaC安全检查的不同侧面：Checkov由Bridgecrew（后被Palo Alto Networks收购）开发，是一个静态分析框架，支持Terraform、CloudFormation、Kubernetes等多种IaC格式，内置超过1000条策略规则；TFLint专注于Terraform代码的语法检查和最佳实践验证，能够检测出Terraform本身不会报错但可能导致问题的配置（如无效的实例类型）；tfsec则专注于安全漏洞检测，能识别过于宽松的安全组规则、未加密的存储等安全隐患。将这些工具集成到流水线中实现了「安全左移」——在代码提交阶段就拦截安全问题，而非等到部署后才发现。

关键不在于屏幕上是哪些工具的Logo，而在于策略、安全、成本、审批和部署可以全部纳入单一的受治理流水线。这正是「我们有策略」与「我们的基础设施不绕过策略就无法变更」之间的本质区别。

人类判断与自动化的边界

在审批点提供决策上下文

随着部署的基础设施越来越多，让人类审批每一次变更变得不切实际。正确的做法是在应用时刻为审批者提供丰富的上下文。仅仅告诉审批者「EC2从small变为medium」只说明了「改了什么」，而真正有价值的信息是：

• 成本影响是什么？
• 策略检查是否通过？
• 是否涉及漂移？
• 这是在修复此前的漂移吗？

审批者应当审查完整的决策，而不是自己去重建上下文。尽管Agent能力在增强，但目前大量实践仍保留「人在回路」（human in the loop）——因为基础设施变更极其重要，可能导致严重故障。当前的策略是用Agent增强审批的元数据，同时逐步让这些审批信息机器可读，最终在建立足够信心后走向完全自动化。

自动化不等于处处移除人类

一个重要观点是：自动化不应意味着到处删除人类，而应意味着在人类判断真正增加价值的地方引入人类。这与Agentic工作流安全架构理念一致——为Agent提供隔离、约束输出、全面日志。

Agentic工作流是指AI Agent在最少人工干预下自主完成复杂多步骤任务的工作模式。其安全架构面临独特挑战：Agent需要足够的权限来执行有意义的操作，但不受约束的权限可能导致灾难性后果。业界正在形成的安全范式包括：最小权限原则（Agent只获得完成当前任务所需的最小权限集）、沙箱隔离（Agent的操作在受限环境中执行，防止横向扩散）、输出约束（限制Agent可以产生的动作类型和范围）、全面审计日志（记录Agent的每一步推理和动作，支持事后分析）。在基础设施场景中，这意味着Agent可以生成terraform plan但不能直接apply，或者只能修改非生产环境的资源。

绝不能给Agent不受限制的执行权限，尤其是在基础设施这样的高风险领域。

统一控制平面：一个平台管理全生命周期

基础设施并不在Terraform输出「apply complete」时结束。你可能用Terraform、OpenTofu、Terragrunt或CDK供应，之后用Ansible配置，最终它还要支撑某个应用的部署。历史上这轻易就会变成三个独立的工作流。

当供应、配置、部署被当作三个独立系统时，交接会横跨多个团队、多种工具、不同的RBAC和审计方式，治理层也随之碎片化。解法不是替换Terraform或Ansible，而是保留你的工具，让编排在单一控制平面中发生——为这些工具提供共享的编排、治理与上下文。

AI Agent登场：从代码补全到风险预测与自愈

Agent的基础是上下文

行业正快速超越单纯的代码补全或生成。MCP（Model Context Protocol）正成为连接模型与数据、工具、知识的行业标准。MCP是由Anthropic于2024年底推出的开放标准协议，采用客户端-服务器架构，其中LLM应用作为客户端，而数据源、API和工具作为服务器。这解决了此前每个AI应用都需要为每个数据源构建定制集成的N×M复杂度问题，将其简化为N+M。在基础设施领域，MCP使得AI Agent能够标准化地查询Terraform状态、读取策略定义、调用云API，而无需为每种组合编写专门的适配代码。Terraform和OpenTofu相继推出MCP服务器，标志着IaC工具正式进入Agent可编程时代。

真正的问题不再是「AI Agent是否会介入我们的基础设施」——它们已经在介入了——而是「当它们行动时，周围有怎样的上下文和控制」。

在统一Agent架构中，查询进入后被路由到具体Agent（交付、安全、基础设施等）。而让这一切生效的底层是上下文：知识图谱理解环境，企业规则与策略理解什么被允许，记忆补充组织与用户的相关上下文。知识图谱是一种以图结构（节点和边）组织信息的数据模型，其中节点代表实体（如EC2实例、安全组、数据库），边代表实体间的关系（如'依赖于'、'被暴露给'、'属于'）。在基础设施治理场景中，知识图谱能够捕获传统CMDB难以表达的复杂依赖关系——例如，一个VPC的路由表变更可能影响跨多个子网的数十个服务，而这种间接依赖在平面化的资源清单中几乎不可见。没有上下文的Agent或许强大，但拥有正确上下文的Agent才真正有用。

Blast Radius Agent：变更前的风险评估

Blast Radius Agent关注「变更之前」：在做出某次基础设施变更前，它会分析该变更会影响什么、哪些资源依赖它、应用它的真实风险有多大，并给出风险评分（low/medium/high/critical）。通过知识图谱的图遍历算法，Blast Radius Agent能够在毫秒级别计算出任意变更的影响范围，包括多跳间接依赖——这远超人类工程师在审查terraform plan时能够快速识别的范围。

实际演示中：

• 一次创建4个新资源的变更被评为低风险
• 而另一次禁用公共访问阻断、删除服务端加密的变更则被评为10分满分的高风险变更，并在图形视图中用红色清晰标注被删除的资源

系统会在节点级别评估风险，并综合节点密度、类型和上下文变化得出整体评分。

Remediation Agent：变更后的自动修复

Remediation Agent关注「变更之后」：当检测到漂移、成本或安全合规问题后，与其在队列里留下又一条告警，不如让Agent确定合适的修复方案并生成PR。

完整的自愈闭环如下：

1. 漂移检测触发流水线
2. 唤起专精于IaC修复的Worker Agent
3. 识别漂移的具体属性
4. 自动生成Pull Request说明具体改动
5. 人工审查后合并
6. 触发新流水线执行init/plan/审批/apply

这样，工程师的待办从「审查待解决的问题」转变为「审查已完成的修复」。

从「需要被优先处理」到「已经改好，请审批」

这一转变对吞吐量的影响巨大。过去大量漏洞、成本优化、性能优化机会因优先级不足而堆积在Backlog。当对话从「这需要被优先处理」变为「这里已有一个为你做好的变更，请审批」，整个反馈闭环的吞吐量显著提升。这本质上是将工程师的角色从「问题解决者」提升为「决策审批者」——他们的认知负荷从理解问题、设计方案、编写代码转变为审查已生成方案的正确性，极大提高了每位工程师能处理的变更数量。

漂移治理的现实思考与最佳实践

针对「应用进入生产后如何控制漂移」的问题，务实的回答是：理想世界里所有操作都通过IaC完成、彻底封禁ClickOps，但这只是理想化的目标。漂移必然发生，因此需要构建下游动作形成闭环：

• 检测：提供原生漂移检测，周期性运行，精确到具体资源的具体属性
• 可审计的呈现：例如在某项目上下文中告知「42%的资源已漂移」
• 处置：要么由Remediation Agent接受漂移并生成对应代码变更的PR，要么按「不允许ClickOps」原则重置回IaC定义的真相状态

值得注意的是，漂移处置存在两种截然不同的哲学：一是「代码即真相」，将实际状态重置回代码定义；二是「现实即真相」，将代码更新以匹配实际状态。正确的选择取决于漂移的原因——如果是紧急修复生产事故的临时变更，可能应当将其固化到代码中；如果是未经授权的随意修改，则应当回滚。Remediation Agent需要足够的上下文来区分这两种情况。

对于「Blast Radius能否检测无直接API连接的被动接口（如Kafka发布订阅流）」这一深度问题，答案再次回到知识图谱——通过构建基础设施与消费服务之间的节点与边，并结合韧性测试能力，实现更全面的风险评分。这也揭示了当前技术的边界：对于通过消息队列、事件总线等松耦合机制连接的服务，其依赖关系不会出现在Terraform的资源图中，需要额外的服务发现和拓扑建模能力来补充。

结语：既要强大AI，也要安全基础设施

本文的核心结论清晰而深刻：AI让创建基础设施变得极其容易，整个生态（OpenTofu、Terraform的MCP集成、Agentic工作流）也日益机器可读。这意味着答案不能是简单的下游人工审查或人工控制。

随着我们赋予AI越来越多的行动能力，必须极其审慎地界定：哪里可以自主行动，哪里必须保留人在回路。 Agent能力越强，治理层乃至「治理Agent本身」就越重要。我们不应在「强大的AI」和「安全的基础设施」之间二选一——架构必须同时给予两者。这正是统一控制平面在Agent、基础设施与SDLC时代的价值所在。

核心要点