让 Agent 安全可控地管理云环境：RunIaC 实践
当 Agent 从“回答云上问题”走向“真正操作云资源”，问题就变了。
开发者关心的不是 Agent 会不会写 Terraform，而是：当业务需要时，能不能尽快得到一套真正可用的环境；企业云管关心的也不是自动化跑得有多快，而是：每一次变更是否在授权边界内，是否可见、可审、可追踪，资源创建后能否持续管理并最终回收。
RunIaC 解决的正是这两个问题。它把 Agent 的云资源操作从“拿着凭证执行命令”，变成一条由 IaC 描述、由 Plan 展示、由策略和人工审批把关、由状态持续管理的受控执行链路。
想先实际体验？ 前往 Alibaba Cloud Agent Toolkit，让 Agent 在受控边界内完成一次真实的阿里云任务。
一、使用场景
场景一：为开发者的 Agent 提供安全可靠的阿里云入口
个人开发者或企业研发已经习惯让 Agent 写代码、排查问题和完善应用。但当任务需要真正使用阿里云时，往往会卡在同一个地方：Agent 没有合适的云上入口。把长期 AK 写进本地配置风险太高，为不同云产品逐一安装工具、查文档、配置权限又过于繁琐。
接入阿里云 MCP Server Core 后，用户只需要完成一次受控授权。Agent 可以按需检索 OpenAPI 和文档、查询云上信息，并在需要创建一组资源时生成 IaC，交给 RunIaC 先计算 Plan、确认后再执行。
对个人开发者来说，这意味着不必先成为云产品专家，也不必在本地到处保存凭证，就能让自己的 Agent 快速获得部署测试环境、验证方案和管理资源的能力。
对企业研发来说，这个入口仍然处在身份、权限范围、临时凭证、沙箱、Plan、HITL 和任务审计的边界内。让 Agent 使用阿里云，不等于把整个云账号交给 Agent；它拿到的是完成当前任务所需的能力，而且关键变更始终有人把关。
场景二：活动上线前，快速拉起临时联调环境
一家电商团队准备上线会员积分活动。前端、后端都已接近完成，却还缺一套完整的联调环境：需要网络、运行环境、静态资源存储、日志，以及一个能直接打开的访问地址。活动结束后，这套资源还要完整回收。
过去，这通常意味着申请资源、等待权限、手工创建、反复确认网络和日志配置。环境还没有就绪时，产品、前端和测试都在等待；活动结束后，又要依赖某个人记得清理。
现在，开发者可以直接对 Agent 说：
为会员积分活动准备一套保留 7 天的联调环境，需要公网访问入口、后端运行环境、静态资源存储和日志。先告诉我会创建什么、有哪些风险和费用，再执行真实变更。
Agent 先把业务目标整理成 IaC，再由 RunIaC 生成 Plan。开发者看到资源清单、公网暴露、权限和销毁范围，确认后才执行。完成后，团队拿到可访问地址，马上开始联调；活动结束后，基于同一份状态整体回收。
这里的成功标准不是“Terraform 执行成功”，而是“业务开始联调，而且环境没有脱离管理”。
场景三：售前团队快速交付一套可演示的客户 PoC
售前团队临时收到客户需求：第二天要演示一套“日志采集、实时分析和可视化大盘”方案。环境需要 SLS、运行服务、静态页面和访问入口，既要在短时间内搭起来，也要在演示结束后完整回收。
过去，售前通常需要临时找研发协助，手工创建多种资源，再把零散脚本和配置拼在一起。PoC 数量一多，资源归属、成本和清理时间都容易失控。
现在，售前可以直接告诉 Agent：
为客户准备一套保留 3 天的日志分析 PoC，包含日志生产、SLS 实时分析和可视化大盘。先展示资源清单、公网入口与费用风险，确认后部署，并给出演示地址和回收计划。
Agent 将方案整理为 IaC，RunIaC 先输出 Plan；确认后展开环境并返回可访问页面。演示中如果需要调整规格或增加资源，继续在同一份 State 上变更；PoC 结束后，按 Destroy Plan 整体回收。
这里的价值不是“更快创建几台资源”，而是让每一套 PoC 都能快速交付、清楚解释、持续调整并按时退出。
场景四：企业云管让 Agent 参与变更，但不绕过治理
业务大促前需要扩容 ECS、增加 VSwitch，并调整一条网络策略。企业希望 Agent 帮助分析需求、准备 IaC 和执行变更，但云管团队不能接受 Agent 绕过审批直接修改生产环境。
过去，需求往往以工单、截图和口头说明在团队间流转，云管人员再登录控制台逐项操作。计划与真实操作容易脱节，变更完成后也很难快速还原“谁批准了什么、实际执行了什么”。
现在，Agent 先把变更请求转换为 IaC 差异，RunIaC 生成 Plan 和风险摘要。云管人员可以看到资源创建、修改、删除、公网暴露和权限影响；命中策略的变更进入 HITL，批准后才 Apply，执行过程由 processID 和 GetTask 持续追踪。
RunIaC 并不是用 Agent 取代云管，而是让 Agent 进入企业已有的治理边界：变更先可见，关键动作可审批，执行过程可追踪，资源在同一份 State 中持续可管理。
二、功能介绍
RunIaC 不只是一个“远程执行 Terraform”的按钮。它真正带来的变化，可以概括为四点：受控授权、计划先行、HITL 审批、云资源持续可管理。
受控授权与沙箱执行：能力交给 Agent，边界留在手里
平台并不是把整个云账号交给 Agent，而是为一次连接预先确定一组无法由 Agent 在会话中自行放大的边界。长期凭证不进入 Agent 对话或 IaC 代码；执行侧可按需通过 AssumeRole 换取有效期 1 小时的 STS，并叠加会话 Policy，使实际权限同时受目标角色和临时策略约束。
这组边界会继续沿着“入口、工具、动作、审批、执行环境”逐层收缩：
- 入口与工具边界：
endpointPolicy只允许访问指定的 MCP 端点；toolPolicy只向当前 Agent 暴露被允许的工具，先缩小它能够发现和选择的能力面。 - 动作边界：
safePolicy或cliRamSafePolicy把 RAM 动作转换为 allow/deny 规则，约束 CallCLI 等执行路径的实际调用。配置 allow 集合时会自动补上默认拒绝；无法解析的动作按拒绝处理，涉及拒绝项无法解析时直接 deny-all，避免因规则缺失意外放大权限。 - 策略不漂移：策略与 Bearer Token 绑定，首次设置后不允许用同一个 Token 覆盖；建立 MCP Session 时，
safePolicy和endpointPolicy会复制为会话快照。Agent 不能靠新的提示词临时改大自己的权限。 - 审批边界：当前链接级 HITL 不再依赖 MCP Server 本地的独立
hitlPolicy字段。enableHitl打开后，MCP Server 把产品、API 和可用的版本信息交给 Identity HITL 规则服务，由策略返回ALLOW、ESCALATE或DENY；规则无法判断或服务异常时按失败关闭处理。
在 RunIaC 中，HITL 目前按 Terraform Plan 差异把关：HITL 开启后，只要 Plan 包含创建、更新或删除，Apply 前就会进入审批；显式 Destroy 还会强制经过 HITL 门。也就是说，Agent 不能把“生成了 IaC”直接等同于“获准改变云资源”。
执行层同样隔离凭证。RunIaC 在服务端执行 Terraform，Agent 只提交任务并通过 processID / GetTask 获取状态；RunScript 的隔离更进一步，脚本沙箱没有通用网络，也拿不到 AK/SK/STS，只能带任务 Token 访问本地 OpenAPI Executor，返回结果还会经过敏感信息脱敏。
这套模型依赖的不是“Agent 足够听话”，而是即使 Agent 理解错误或生成了越界方案，系统仍有一组不受提示词影响的硬边界。
Plan-Review-Apply：真实变更先被看见，再被确认
RunIaC 首先计算 Plan，明确本次会创建、修改或删除什么。Review 阶段可以叠加代码校验、策略检查和风险识别；需要人工判断的变更进入 HITL，由人确认后再 Apply。
当前 RunIaC 的审批依据真实 Plan，而不是自然语言风险描述。HITL 开启后，创建、更新、删除都会在 Apply 前暂停；显式 Destroy 会强制经过 HITL。公网暴露、高成本规格等更细粒度风险，目前仍需要在 Review 或企业策略层识别，不能把它们写成 RunIaC 已内置的默认规则。
HITL：让人掌握关键变更的最后决定权
HITL（Human-in-the-Loop）把人工判断放在真实变更生效之前。对 RunIaC 来说，审批对象是已经计算出的 Plan：资源差异不为空且 HITL 已开启时，任务进入待审批；显式 Destroy 路径会强制开启这道门，Agent 不能自行跳过。
审批人看到的不是一句笼统的“是否同意”，而是本次变更的资源差异、触发原因和影响范围。审批通过后继续 Apply；拒绝或超时则停止，云资源不会发生这次计划中的变更。Agent 可以通过 GetTask 获得待审批、已通过、已拒绝、已过期和执行完成等状态。
HITL 也不意味着 MCP Server 的所有操作一律人工确认。CallCLI 和 RunScript 可以将产品、API、版本组成标准事件交给 Identity HITL 策略，分别得到 ALLOW、ESCALATE 或 DENY；只有需要人工决策的操作才进入审批。RunIaC 当前使用独立的 Plan 级审批门，尚未按公网暴露、成本等业务风险细分规则。
让资源创建后仍然可持续变更和管理
IaC 的价值不只是“用代码创建资源”。它用代码声明期望状态，用 State 记录代码资源与真实云资源 ID 的映射，再通过 Plan 计算两者差异。
因此，Agent 第一次可以展开环境，下一次也可以沿用同一份状态修改、扩容或修正，使用结束后还可以完整销毁。相比连续调用多条 API，IaC 留下了可版本化、可复现、可持续变更的管理依据。
用户可以直接提交简单的内联 HCL；面对多文件、多模块项目，也可以先上传工程包，再进入同一条 RunIaC 执行链路。Terraform 仍然存在，但它退到了可复现、可审计的执行面之后。
5. 与 MCP Server Core 协同：用少量工具连接完整云能力
RunIaC 处在 MCP Server Core 的受控执行层中。Agent 可以先检索 API、读取定义和文档，再选择合适的执行方式：查询或单次操作使用 CallCLI；通用脚本使用 RunScript；涉及多资源、状态和持续管理的环境变更使用 RunIaC。
这样，Agent 不需要预先装入数以万计的固定工具，也不必自己拼装一条失去状态的命令链。它可以动态理解云能力，并把真正的基础设施变更交给 RunIaC 管理。
三、实战演示：用 RunIaC 部署一面现场可用的互动问答墙
这次演示使用 AUG 沙龙分享的场景：搭建一个技术沙龙实时互动问答墙。它不是一个为了展示 Terraform 而准备的空壳页面，而是沙龙现场真正要使用的工具：参会者扫码提问和投票，演讲者在大屏查看高票问题，并把已经回答的问题标记完成。
因此，验收标准也不再是“云资源创建成功”，而是活动现场能否真正使用：页面能打开、问题能提交、投票能生效、演讲视图能实时看到变化，活动结束后整套环境还能安全回收。
第 1 步：把业务目标交给 Agent
已有业务包包含一个 Python 服务和前端静态文件。服务同时提供页面与 API，支持提交问题、投票、按热度或时间排序、5 秒自动刷新，以及讲师模式下的统计和“标记已回答”。
可以直接向 Agent 提出下面的目标：
请在 cn-hangzhou 部署 AUG 场景 1“技术沙龙实时互动问答墙”。
这段话描述的是业务结果和安全边界。资源关系、Provider 参数和执行顺序由 Agent 整理成 IaC，用户不需要先把一套 Terraform 命令翻译给 Agent。
第 2 步：先看 Plan，并在 Review 中收紧风险
RunIaC 根据 IaC 计算 Plan。这个场景预期创建：
- 1 个 VPC 和 1 个 VSwitch
- 1 个安全组及 80 端口入方向规则
- 1 台小规格 ECS 和公网带宽
Review 不只是数一遍资源，还要检查公网暴露、登录方式、规格和计费。比如某个初始模板如果出现 0.0.0.0/0 的 22 端口或密码登录，就应该在此处停止：本场景通过云助手下发代码，并不需要公网 SSH，因此应删除 22 端口规则后重新 Plan。
这正是“计划先行”的实际意义。Agent 可以快速生成方案，但真实云资源是否按这个方案变化，仍由 Plan、策略和人共同决定。
第 3 步：确认后 Apply，用 GetTask 跟踪执行
确认计划后，RunIaC 才进入 Apply，并返回 processID。Agent 使用 GetTask 持续查询任务，直到 VPC、VSwitch、安全组和 ECS 创建完成。
执行成功后，Terraform 输出三个关键结果：
instance_id：后续云助手下发文件和执行命令的目标public_ip：页面健康检查和浏览器访问地址service_url：形如http://<public_ip>/的最终入口
同时保留 stateId，后续修改带宽、调整规格或销毁环境都沿用同一份状态，而不是重新猜测这批资源之间的关系。
第 4 步：通过 CallCLI 部署业务代码
RunIaC 负责创建和持续管理基础设施，业务代码则由 MCP Server Core 的配套执行能力完成：
- 将
server.py和frontend/打包； - 通过云助手 SendFile 或 RunCommand 把文件下发到 ECS；
- 解压到
/opt/scene1； - 注册
scene1.service，设置PORT=80和Restart=always； - 启动服务并访问
http://<public_ip>/api/health。
健康接口返回 status: ok，只能证明进程已经运行。真正的验收还要继续走完页面上的业务流程。
第 5 步：打开页面，完成双视角验收
参会者打开 http://<public_ip>/，应该可以：
- 输入昵称和问题并提交
- 按“最热”或“最新”查看问题
- 为问题投票，同一浏览器不能重复投票
- 在 5 秒自动刷新后看到其他人的新问题
讲师打开 http://<public_ip>/?mode=speaker，应该可以：
- 展示二维码，供参会者扫码进入
- 查看提问总数、已回答和待回答数量
- 在大屏上优先看到高票问题
- 将已经讲解的问题标记为“已回答”
最直接的验收方法是：用第一个浏览器提交问题，用第二个浏览器投票，再打开讲师模式确认高票排序并标记已回答。参会者页面刷新后能看到状态变化，才说明这不是“创建了一台 ECS”，而是展开了一套现场可用的业务环境。
第 6 步：持续变更，并在活动结束后回收
活动开始前如果需要提高带宽或调整 ECS 规格，Agent 修改 IaC 后再次提交 RunIaC。新的 Plan 只展示差异，确认后在原有 stateId 上完成增量变更。
活动结束后，Agent 基于同一份 State 生成 Destroy Plan。销毁属于高风险动作，会进入 HITL；审批人确认待删除资源与现场活动已经结束后，再回收 ECS、VSwitch、安全组和 VPC。
当前 Demo 使用内存保存问题，服务重启后数据会丢失，适合一次沙龙现场使用；如果要长期运营，应把问题数据迁移到 Tablestore 或数据库。这个限制属于应用设计，不影响 RunIaC 对基础设施生命周期的持续管理。
四、常见问题
1. RunIaC 和直接调用 OpenAPI 或 CLI 有什么区别？
OpenAPI/CLI 更适合查询和单个动作；RunIaC 更适合多资源、有依赖、需要状态和生命周期的环境变更。前者回答“执行一次什么”，后者管理“这个环境应当长期处于什么状态”。
2. Agent 会拿到我的 AK 吗？
不需要。推荐使用 OAuth 登录，MCP Server 会拿到一个临时凭证，这个凭证在隔离执行环境中使用，用于调用工具链（CLI、Terraform、Python等），不会被 Agent 拿到，不把长期明文 AK 写入代码或交给 Agent。企业还应进一步限定账号、资源组、地域、动作和有效期。
3. Agent 会不会理解错一句话就直接修改云资源？
正确链路是 Plan、Review、Apply。并且，RunIaC加了强卡点，必须先通过 Plan 拿到计划内容，之后才允许执行 Apply。并且，Plan 会展示变更，通过 HITL 策略（可配置）检查识别风险，在检测风险时，强行进入 HITL 阶段，必须由人工审批后才会放行。因此，不需要依赖提示词约束 Agent，系统机制会保障变更前有人工审核。
4. HITL 是不是所有操作都要人工审批？
不是。CallCLI、RunIaC 和 RunScript 可按 Identity HITL 规则对具体 API 做 ALLOW、ESCALATE 或 DENY，查询类和低风险操作可以直接放行。RunIaC 当前是 Apply 级门禁：HITL 开启后，非空 Plan 在 Apply 前进入审批；显式 Destroy 强制经过 HITL。公网暴露、高成本等更细策略需要由 Review 或企业治理层补充。当然后续会开放 HITL 策略，支持用户自定义审批规则。
5. 创建后的资源能持续修改吗？
可以，前提是保留并复用正确的 ProcessId。内联模式可以通过 stateId 做增量变更；复杂 Bundle 场景是否支持状态复用，需要以当前产品约束为准。State 应像数据库数据一样被保护，而不是当作临时文件处理。我们后续会推出 IaCService 的 Plugin，以支持企业级的云上变更的 CICD 流程。通过 IaCService Plugin，Agent 就可以自主管理和维护 IaC 模板、状态和文件。
6. 任务失败时能看到什么？
GetTask 会返回任务状态、错误摘要和必要日志。常见原因包括 HCL 语法错误、权限不足、参数错误、策略拦截、审批拒绝和超时。生产环境还应保留原始 Terraform 诊断、退出码和执行版本，避免只剩一段 Agent 总结。可以使用 ProcessId 继续对任务的模板进行调整、执行。
五、结语
RunIaC 带来的变化，不只是 Agent 多会了一条 Terraform 命令，而是云资源变更开始拥有清晰的边界。
对开发者来说，云环境从一串申请和手工操作，变成可以按需展开、立即使用、持续调整的工作空间；对企业云管来说，Agent 从治理体系外的脚本，变成一个变更可见、关键动作可审、执行过程可追踪、资源持续可管理的受控执行者。
能力交给 Agent，边界留在手里。这才是 Agent 真正开始管理云环境的前提。
现在，把这套能力交给你的 Agent
从一次受控授权开始，体验 MCP Core、RunIaC、RunScript 与 HITL 审批组成的完整云上工作链路。
