北京
基础设施即代码（IaC）的设计初衷，是匹配人类操作的速度：写计划、审查、执行，再用状态快照记录管理过的资源。这套流程在改动者少、变更频率低的场景下运转良好。
但AI代理（Agent）正在打破这些前提。它们持续运行，多个代理可能同时触碰同一批资源。配置漂移不再是例外情况，而是不可避免的常态。
传统IaC工具的局限
Terraform这类主流IaC工具依然重要，因为它们承载着“意图”。但它们的短板在于反映“当前现实”的能力。代理通常只掌握局部信息，在狭窄范围内操作，而同一片基础设施可能同时被其他代理、其他工具或人类修改。在这种环境下，代理经常会遇到绕过IaC系统、在系统外被改动的资源。
“先查询再变更”（Query-before-mutation）正是应对这一场景的模式：读取云上实时状态，与策略比对，应用有边界的策略门禁，只修改不符合策略的部分，最后验证。每一次运行都从现实出发，而不是依赖缓存的视图。
两个模式，两种职责
正确性来自行动前查询实时状态。安全性则来自另一套机制：策略门禁（Policy Gates），它限制单次运行允许做的事——比如位置锁、资源上限、预算封顶、白名单。这是两个模式，承担两种职责。基于代理的“先查询再变更”模式，与依赖状态快照的集中式IaC方法形成互补；策略门禁则取代了人工审查会议。
这套组合循环之所以“默认正确”，是因为它读取现实；之所以“默认安全”，是因为它无法超出门禁允许的范围。代理可以持续运行，人类也可以手动执行，两种方式最终都会收敛到一致的结果。
一个具体的实现
StackQL实现了这一模式。在它支持的云平台上，任何资源都可以用SQL读取，在提供商暴露变更方法的前提下，也可以用SQL修改。Kubernetes解决了集群内部的协调问题，但还没有工具能跨云协调。这个空白正是该模式的用武之地。
演示使用Google Cloud Storage，因为其变更接口比较干净，但同样的模式适用于AWS S3、Vault密钥、GitHub组织设置，以及任何代理需要推理的资源。
动手实验：十分钟跑通
准备三样东西：Docker（免安装运行StackQL）、一个能读取存储桶并更新加密配置的Google Cloud项目（含一个已有的Cloud KMS密钥）、大约十分钟时间。
克隆教程目录，复制环境变量示例文件并填入服务账号凭据，然后启动交互式Shell即可开始。整个过程围绕一个核心动作：让代理在每次变更前，先问一句“现在真实状态是什么”。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
