跳到主要内容
翻译页面

本页面由 AI 辅助从英文翻译而来。如两者存在差异，以英文版本为准。

从 IaC 到智能体基础设施

基础设施工具经历了 3 个时代，每个时代都由谁（或什么）在操作控制平面来界定。命令式脚本让人坐在键盘前；声明式 IaC 让人处于围绕收敛引擎的评审循环中；智能体基础设施（agentic infrastructure）则把 AI 智能体直接放到控制平面上，对接口的要求也随之改变。

第一个时代：命令式自动化​

shell 脚本、CLI 调用和配置工具编码的是过程：先做这个，再做那个。期望状态的模型存在于运维人员的头脑中。这种方式难以扩展：过程会漂移，错误处理成倍增加，并且没有任何机制对照意图检查结果。

第二个时代：声明式 IaC​

Terraform、CloudFormation 及同类工具把这一模型反转过来：声明期望状态，让引擎计算过程。这是一次真正的进步（可评审的差异、可重复的环境、模块化复用），并且构建了如今大多数平台团队所运行的工作流。支撑它的关键产物是状态文件：引擎对其所管理内容的记录，用于将声明映射到真实资源并计算计划。

这一模型的假设是按人的工作方式设定的：变更通过代码评审成批到达；状态在有人运行 plan 时刷新；所有重要的内容都在受管集合之内。在这些假设之内它运作良好，这也是它得以延续的原因。在这些假设之外（持续观测、跨 Provider 的问题、无人声明的资源），它能提供的很少：IaC 工具无法提出问题，其记录也只描述它们所管理的内容。请参阅为什么状态文件对 AI 智能体失效。

第三个时代：智能体基础设施​

AI 智能体改变的是运作模式，而不只是运维人员。智能体持续行动，而不是按发布批次行动；它们针对整个基础设施资产提出即席问题；它们并发运行；并且它们需要可由机器检查的护栏，而不是口口相传的流程。为它们服务的接口具有 4 项特征：

  1. 可发现：智能体在运行时了解 Provider、资源、操作和必需参数（SHOW METHODS、MCP 发现工具），而不是预置硬编码的 Provider 知识。
  2. 实时：答案反映的是控制平面当前的状态，而不是按人的节奏刷新的副本。
  3. 统一：所有 Provider 使用同一套语法（SQL：SELECT/INSERT/UPDATE/DELETE），因此智能体的能力可以在整个基础设施资产中迁移。
  4. 受治理：对自主调用方可以做什么有明确的契约（从只读到完全访问），在需要时由人工审批，并有完整的审计跟踪。

这就是 StackQL 实现的接口：将 Provider API 呈现为基于实时状态的自描述 SQL 表，变更使用同一套语法，并通过带有分级安全模式和始终开启的审计日志的内置 MCP 服务器公开给智能体。

IaC 时代延续下来的内容​

期望状态的定义会延续下来：意图必须存放在某处，而受版本控制的声明仍然是它合适的归宿。智能体时代所取代的是意图与现实之间的机制：针对私有状态记录的周期性 plan/apply 循环，让位于针对实时控制平面的持续查询、比较和受治理的调谐。IaC 定义了目的地；智能体基础设施改变的是如何以及以多高的频率度量并弥合与目的地之间的差距。