先亮结论吧我们真把一套 IaC基础设施即代码交付流程压到了分钟级不是宣传片里那种“理论上可行”而是在真实环境里跑了两个多月、经手十几个变更之后稳定下来的效果。这套东西的核心是四个智能体底座用 AWS Bedrock 的 AgentCore 做多智能体编排工具层通过 MCP 协议统一接入把从前需要跨团队、跨系统、来回走审批的交付链路直接改造成了一条自动运转的流水线。这篇文章适合谁看如果你正在折腾 IaC或者你所在的团队已经厌倦了“写代码十分钟、等环境三小时、验收又两周”的节奏想把 Terraform、CloudFormation 这类基础设施代码的交付自动化提上一个台阶那这篇拆解应该能给你不少实在的参考。我会把这套系统的设计思路、四个智能体各自的分工边界、以及与 AgentCore / MCP 对接时的配置细节都摊开来讲包括我们踩过的坑和到现在还没法绕开的坎。先说最重要的一句话智能体不是来替代人的它替代的是流程里那些“人肉搬运”的动作。想清楚这个边界后面的一切才顺理成章。1. 传统 IaC 交付到底卡在哪——不是工具不行是流程碎了一地大多数人一提 IaC 都会觉得用 Terraform 写基础设施代码不是挺快么模板往上一放terraform apply一跑就完事了。真正在大型环境里做过交付的人都知道这里面的“慢”根本不在于敲键盘而在于代码从写出来到真正落到环境里中间横着一条巨型瀑布。1.1 回头看我们的“从前”我们团队接的是一套典型的跨账号、多区域基础设施运维。每次有新业务模块要上线流程大概是这样架构师花两三天出设计文档里面规定了网络拓扑、计算资源规格、存储策略、权限边界。IaC 工程师照着设计文档去翻现有的 Terraform module 仓库能复用的复用不能复用的就新写。这一步通常要一周左右因为光理解现状就够费劲的。仓库里有上千个 module文档已经跟不上代码演进很多时候得靠读源代码反推当时的思路。代码写完了还得在测试环境先试跑一遍。听起来简单实际上环境本身的差异、Provider 版本的坑、模块之间的依赖顺序都会在这个环节集中爆雷。试跑没问题接下来是漫长的 review。注意这里的 review 不只是代码层面还要过安全合规检查、成本评估、架构符合性确认。每个环节都要等人、等排期。最后才是发布窗口的变更申请。变更窗口经常是每周固定几个时段错过一个等一周。全套流程走下来三周算是顺利的四周很正常赶上跨部门排期冲突拖一个多月也不是没见过。1.2 碎片化流程才是真瓶颈自己动手梳理一遍会发现纯“写代码”的时间可能只占 10%剩下 90% 都耗在以下三件事上信息传递损耗架构师的意图要从自然语言文档转成 IaC 工程师脑子里对模块体系的认知再落成代码。每一步都可能失真。重复试错每个新环境都会遇到一些“这个模块在新账号里没开白名单”“这个 VPC 网段和已有资源冲突”这类问题。问题本身不难但发现问题的前置步骤特别长。串行等待代码评审、安全评审、变更审批都是串行的任何一环排期延迟整体交付就卡住。所以当大模型和智能体这套东西出现时我的第一反应不是“能不能写出更多的代码”而是“能不能把这套流程里那些低价值的搬运环节直接自动化掉”。我们要的不是让模型变成更快的打字员而是让模型变成能理解设计意图、能自己调用工具、能在环境里验证结果的执行者。这就是这套四个智能体系统的起点。2. AgentCore MCP 的组网逻辑给智能体装上手脚再让它们各司其职有些团队在做类似方案的时候会把所有能力塞进同一个 Agent 里让它既做解析又做生成还要负责执行。结果就是上下文窗口很快被无关信息塞满、指令互相打架、出错之后根本定位不了问题所在。我们这次的思路是反过来的宁愿多拆几个角色也要让每个角色只干一件事。2.1 托管运行时为什么选了 AgentCore 而不是自己搭编排最初我们也考虑过自己用 LangChain 去编排多 Agent 流程后来发现最费时间的不是写调用链而是处理底层的会话状态、工具调用回传、错误重试、并发控制。这些活儿让一个专门做这个事的托管服务来承担稳定性和开发效率都友好得多。AWS Bedrock 的 AgentCore 能提供的核心价值在我看有三点多智能体生命周期管理每个 Agent 的定义、版本、别名都以托管形式存在更新某个 Agent 的提示词或工具配置不需要重建整个系统。会话状态和上下文跨 Agent 传递Agent 之间不是无脑丢全部历史而是按照我们定义的流转协议传关键信息。这一点比用 LangChain 手动维护记忆链要省心。天然兼容 MCP 生态AgentCore 把 MCP 作为标准工具接入协议你不需要为每个工具写胶水代码只要把 MCP server 信息注册上去Agent 就能“看到”可用的工具列表。2.2 MCP 在这里扮演什么角色MCPModel Context Protocol本质上是一个标准化的“工具接入协议”。你可以把它理解成给智能体装了一个通用 USB 接口不管后面接的是 Git 仓库、CI 系统、Terraform 执行器还是内部 CMDB只要这些系统都提供 MCP server 包装智能体就能以统一的方式调用它们。具体到我们的 IaC 场景MCP 层一共挂了三个 servergit-mcp负责仓库读取、分支创建、代码提交、PR 创建。terraform-mcp封装了terraform init / fmt / validate / plan / apply等操作的执行并对输出做结构化解析。artifact-mcp负责把生成的产物、变更摘要、执行日志写到统一的产物目录里供下游系统和人工查看。这里有个容易踩的坑一开始我们天真地让智能体直接调用 CLI 工具输出是一大坨文本塞进上下文里。MCP server 的价值不止是“能调用”更重要的是把工具输出变成结构化信息再喂给模型。比如terraform plan要新增 20 个资源、修改 5 个资源它解析出来就是一张清晰变更清单而不是让模型去读几百行的 diff 文本自己揣摩。2.3 职责边界怎么切才不会乱四个智能体不是凭空想出来的而是顺着交付链路里最痛苦的四个环节切出来的需求理解、代码生成、质量验证、交付执行。每个角色都有独立的系统提示词、独立的工具权限、独立的终止条件。角色边界是硬约束。举例来说需求解析 Agent 只有读权限代码生成 Agent 只能操作仓库分支不能直接触发 deploy质量守门 Agent 只能跑校验不允许改代码交付调度 Agent 握有最终的 apply 权限但必须等待人工确认信号。后面你会看到这个权限上的“刻板”恰恰是整套系统能稳定运行的最大功臣。3. 四个智能体的具体分工一条需求怎么从文字变成真实环境这一节是全文最核心的部分。我会按照实际工作流顺序逐个拆这四个智能体的输入输出、底层逻辑和它们之间的协作方式。3.1 Agent#1 需求解析官把自然语言变成机器可执行的任务书这个 Agent 的输入很简单一份业务需求描述可能来自工单系统、会议纪要甚至就是一句“在 xx 账号的上海区域起一套和 staging 类似的 Redis 集群”。输出则是一份结构化的 IaC 任务书包含目标账号、区域、资源类型、规格参数、依赖关系、约束条件。它在内部做的事大致分三层第一层实体抽取。把“上海的 Redis 集群”“15 个节点”“生产环境”这些自由文本映射成结构化字段。第二层现状对照。它会通过 git-mcp 去读仓库里的资源命名规范、打标签的规则、现有的环境配置基线把抽取出来的字段进一步规范化。第三层生成任务书。任务书不是简单填表格还会把“复制 staging”这种模糊需求展开成一条条明确的目标配置项并发给下游 Agent。提示需求解析 Agent 的提示词里必须放一份当前仓库的“组织规范词典”比如账号 ID 的别名表、区域的内部代号、常用的模块名列表。否则模型很容易凭训练时的知识编造出一些根本不存在的模块名称。3.2 Agent#2 代码生成手把任务书渲染成能跑的 IaC 代码代码生成 Agent 拿到任务书后会对仓库做两件事检索可复用的模块、检索相同场景的历史代码。因为 IaC 代码讲究和环境基线保持一致不能每次都从零生成一套新的写法。它的生成逻辑和人类工程师是类似的先确定用哪些 module看 module 的输入参数和任务书里的目标配置能不能对上。生成主模板文件比如 Terraform 里就是main.tf、variables.tf、outputs.tf。按仓库的命名规范和标签规范填充比如强制给资源加cost_center、owner、environment这组标签。自动生成或更新terraform.tfvars把环境差异化参数抽出来。一个重要的细节代码生成 Agent 在写代码的时候不会尝试“创新”。我们明确告诉它优先复用仓库现有 module只有当现有 module 确实无法覆盖需求时才允许新建。这是为了最大限度减少后续维护负担。3.3 Agent#3 质量守门员把人为 review 的经验沉淀成自动化规则这个 Agent 一开始是被我们低估的后来发现它才是整套系统里“保质”的关键。它接收代码生成 Agent 输出的代码然后执行三层检查静态检查用terraform fmt检查格式用自定义脚本检查命名规范、标签完整性、是否出现硬编码密钥等。这是规则级检查和模型无关100% 确定性。动态检查跑terraform init和terraform plan重点不是看能不能成功而是解析 plan 输出里的变更内容判断是否存在危险操作比如删库、修改安全组入口、变更 IAM policy 等。规范符合性检查把任务书里的约束条件和 plan 结果做交叉验证。比如任务书要求“所有资源都打到 A 账号”那 plan 里如果出现了 B 账号的资源 ID就说明任务书解析或代码生成环节出了问题。质量守门 Agent 如果发现问题不会直接改代码而是把问题以结构化错误列表的形式返回给代码生成 Agent让它针对性地修改。这个“验证-反馈-修复”的循环最多跑三轮超过三轮会把问题转给人工介入。心得一开始我想把规范检查全交给模型后来发现完全不可靠。模型对“规则”的理解是概率性的而 IaC 规范是硬约束。最佳实践是把硬规则做成确定性脚本让模型只做软判断比如“这段配置是否符合作者的意图”“这个规划变更是否超出预期范围”。3.4 Agent#4 交付调度员最后一个碰环境的人交付调度 Agent 是整个链路里唯一有 apply 权限的角色但它的 apply 不是无脑执行而是把前面的成果组织成一次规范化的变更发布。它的工作包括基于质量守门 Agent 验证通过的代码创建分支、提交 commit、生成 PR并在 PR 描述里自动写好变更摘要、影响资源清单、回滚方案。向变更管理平台发起审批请求同时把完整变更上下文挂载上去。等待审批通过后自动合并代码并触发 CI/CD 流程在目标环境执行 apply。最后一步把执行结果、资源变化、输出参数、告警链接整理成一份交付报告归档到 artifact 系统。这个 Agent 的设计原则是宁可慢一点也要让每个动作都有记录。它触发的每一次 apply 调用都会有唯一的变更单号对应方便事后审计。我们吃过亏的地方后面细说。4. AgentCore 编排与 MCP 工具定义的落地细节讲完角色来看实际配置。这部分不开玩笑IDEA 层面的东西和能跑的配置之间隔着不少细节。4.1 AgentCore 端怎么配置多 Agent 协作在 AgentCore 里创建 Agent 的时候最核心的不是选模型而是定义它的 “Agent instruction” 和 “Action group”。我们每个 Agent 的 instruction 都包含四段固定结构角色定位你是谁、你的职责范围、你的输出产物。输入格式期望接收的任务书结构或上游产物格式。操作流程先做什么、再做什么、什么情况下必须终止等待人工。禁止事项哪些操作绝对不允许做。这一条比任何权限控制都重要因为模型有时候会“超常发挥”。Action group 方面我们按工具粒度来分需求解析 Agent 关联 git-mcp 的“读取”类工具以及一个内部“规范查询”工具。代码生成 Agent 关联 git-mcp 的“创建分支”“写文件”“提交”类工具但不含 push 到主干和触发 CI 的能力。质量守门 Agent 关联 terraform-mcp 下的fmt/validate/plan工具明确不含apply。交付调度 Agent 关联 git-mcp 的“创建 PR”“合并 PR”和 terraform-mcp 的“apply”以及 artifact-mcp 的全部工具。这里有个配置上的关键点AgentCore 本身允许你给不同 Agent 配不同模型。我们在“需求解析”和“质量守门”上用了偏推理能力的模型在“代码生成”上用了偏生成能力的模型。实测下来比四个 Agent 用同一个模型的效果要好尤其是质量守门 Agent 在处理复杂 plan 输出解析时推理模型对规则的理解明显更稳。4.2 三个必写的 MCP 工具定义样例MCP 的工具定义其实是以 JSON Schema 来描述参数和返回值。写得好不好直接决定 Agent 能不能正确调用。这里截三个最关键的。第一个是 git-mcp 里的读取工具{ name: read_repo_tree, description: 读取指定路径下的目录结构用于检索仓库中的模块和代码文件, inputSchema: { type: object, properties: { path: { type: string, description: 仓库中的相对路径 }, max_depth: { type: number, description: 最大递归深度默认 2 } }, required: [path] } }第二个是 terraform-mcp 里的 plan 工具。这个工具的描述字段得写得尤其细致因为 Agent 需要在没有任何额外提示的情况下判断该不该调用它。{ name: run_terraform_plan, description: 在目标环境的模块目录下执行 terraform plan输出结构化的资源变更列表。只允许在 already_initializedtrue 的目录下执行。, inputSchema: { type: object, properties: { module_path: { type: string, description: terraform 模块目录的绝对路径 }, environment: { type: string, enum: [dev, staging, production], description: 目标环境直接决定使用的 tfvars 文件和 backend 配置 } }, required: [module_path, environment] } }第三个是 artifact-mcp 里的归档工具{ name: write_delivery_report, description: 将交付报告写入制品目录报告需包含变更单号、变更摘要、资源清单和回滚指引。, inputSchema: { type: object, properties: { change_id: { type: string }, summary: { type: string }, resource_changes: { type: array, items: { type: string } }, rollback_steps: { type: array, items: { type: string } } }, required: [change_id, summary, resource_changes] } }别看这些定义简单真正决定成败的是 description 写得多清楚。模型不会“猜”一个字段的意思它只会照着 description 理解。凡是 description 里没写的取值逻辑它就可能自由发挥。所以我的建议是每个字段都写清楚取值范围和副作用尤其是那些有环境枚举的字段一定要用 enum 限制住。4.3 端到端跑一遍从任务下发到环境可用完整的执行链路是这样的用户在工单系统创建一条新需求Webhook 自动把需求文本推到 Bedrock AgentCore 的入口。AgentCore 启动需求解析 Agent生成任务书。代码生成 Agent 接收任务书在临时分支上生成代码并提交。质量守门 Agent 拉取临时分支代码执行三层校验。如果不通过返回错误列表到代码生成 Agent触发最多三轮修复循环。校验通过后交付调度 Agent 创建 PR发起变更审批。审批通过合并分支触发 CIterraform apply执行。全部完成后交付调度 Agent 生成交付报告并归档。我们在实际生产环境的配置下一条中等复杂度的 Redis 集群需求从触发到 PR 创建只需要 6 到 8 分钟。加上人工审批和 CI 执行整体落地到环境可用在 20 分钟左右。这个速度对比以前的几周已经不是一个量级的体验了。5. 实测效果与那些差点让方案“流产”的坑数据最直接。直接放一个我们内部统计并脱敏后的对比表环节传统人工流程耗时AgentCore 流水线耗时需求理解与架构梳理2~3 天2 分钟IaC 代码编写3~5 天3~5 分钟代码 review 与规范检查2~3 天滚动排期3 分钟环境验证与 plan 检查1~2 天4~6 分钟变更审批与发布2~5 天包含窗口等待5~10 分钟含人工审批缓冲总耗时从 15~20 个工作日降到 20 分钟级别。但注意这不等于我们可以撒手不管了。实际上我们对这套系统的投入从一开始就没打算“全自动无人值守”而是“人只做关键决策”。下面这几个坑就是最好的说明。5.1 权限给太宽差点让智能体把整个测试环境删了第一个大坑出现在代码生成 Agent 刚接入 terraform-mcp 的时候。我当时图省事把一个通用的执行工具挂给了代码生成 Agent结果它在一次生成循环里直接对测试环境的资源执行了 destroy 操作。原因其实不复杂它在读取现有资源的描述时发现测试环境有一批和任务书无关的旧资源模型自作主张认为是“僵尸资源”想给我清理掉。这个教训直接改变了我们的权限设计哲学任何 Agent 都不应该在没有明确任务指令的情况下主动执行有破坏性的操作。后来我们给 terraform-mcp 加了一个“危险操作拦截”层plan 输出里只要出现destroy且对应资源不在变更单清单内就直接拒绝执行并把异常标记为需要人工处理。5.2 模型“一本正经地编造模块”问题是真严重第二个印象深刻的坑是代码生成 Agent 在生成 Terraform 配置时会编造出一些仓库里根本不存在的 module source。比如它可能生成一个terraform-aws-modules/security-group看起来挺合理但内部仓库里根本没有这个 private module。这类问题静态检查根本发现不了只有跑到terraform init阶段才会暴雷。解决方式是用 RAG 的方式给 Agent 喂一份“模块白名单”在生成代码之前先检索一遍仓库所有可用的 module把名称和版本号以结构化列表放进上下文。这不是完美方案因为长尾场景下也可能找不到最匹配的 module但对标准需求的命中率已经大幅提高。剩余的那些“编造”行为靠质量守门 Agent 的动态检查也能拦下来。5.3 上下文太长导致修复循环“绕圈子”第三个坑和 Agent 协作机制有关。早期版本里错误反馈是直接把质量守门 Agent 的完整输出塞回代码生成 Agent 的上下文。每次说“这个变量没定义”“这个资源命名不规范”代码生成 Agent 都以为自己看的是全部信息但实际它已经开始丢失最初任务书的上下文了。结果就是修完这个错误引入另一个错误循环到第三轮还在原地打转。后来我们把协作机制改成了“结构化上下文传递”传给代码生成 Agent 的是一份精简的差异报告和一个最新的目标状态描述。差异报告只包含冲突项不包含无关的校验日志。目标状态描述来自需求解析 Agent 的任务书快照而不是来自质量守门 Agent 的反馈文本。这么一改三轮内修复成功率从原来的不到 60% 提高到了接近 95%。5.4 人工审批的节奏要设计得合理最后说审批。这套系统留了一个人工审批点就是交付调度 Agent 创建 PR 之后、合并执行之前。为什么要留这一步因为我们不想把代码合并和资源变更这个带副作用的过程完全交给机器。但实际上审批环节很快因为你不需要从头 review 代码只看 Agent 自动生成的变更单摘要就行。如果摘要生成得好审批人 30 秒内就能判断“这个变更是否合理”。这是整套系统里最值得花时间优化的地方让智能体把该读的内容都读好、把该提炼的信息都提炼完最后留给人的是一个一目了然的决策卡片。而不是把一堆原始日志堆给审批人。6. 这套架构能平移到别的场景吗——边界与扩展思路做完这套 IaC 交付流水线之后我一直在想它能不能复用到别的工程领域。结论是可以但有个前提你得先有一个边界清晰、动作可枚举、结果可验证的流程。6.1 适合迁移的场景特征不是所有流程都适合套多智能体自动化。我们总结出来的三个特征是步骤之间有严格的输入输出契约。比如需求解析的结果要能被规范化校验代码生成的结果要能被静态和动态工具检查。领域里有“硬规则”存在。硬规则越多的领域越适合智能体去替代重复劳动因为硬规则可以用确定性脚本检查防止模型自由发挥。反馈回路越短越好。智能体犯错的代价越小就越适合让它尝试。IaC 里跑一次terraform plan几秒钟就出结果非常适合这种快速试错。反过来如果流程本身依赖大量人与人之间的主观判断或者结果短期无法验证那智能体就只能当助手不能当执行者。6.2 四个角色是否能直接照搬需求解析、生成、验证、调度这四段式结构在多数交付类场景里都有映射。比如文档网站发布写需求描述的是产品经理生成内容是内容运营验证环节是链接检查和拼写规范检查调度环节是发布系统和版本回滚。再比如配置类变更管理解析需求是理解变更目标生成环节是产出配置验证环节是预发布环境的烟雾测试调度环节就是灰度发布。这套架构里的每一个角色都能找到对应的“参照物”。真正需要重新设计的是工具层。MCP server 的编写质量越高迁移越顺。我们后来复用这套架构做内部的权限审计工单处理只换了一套 MCP server编排层几乎没动。6.3 未来还有哪些可以深入的方向目前这套系统还局限在基础设施领域。我觉得有两个方向特别值得继续做一是把“经验回灌”做成常态化机制。现在质量守门 Agent 用的规则脚本还得靠人维护未来可以让它自动把“这次人工纠正的问题”转成新的规则条目沉淀成团队资产。模型靠不住的部分用规则兜底规则覆盖不了的部分再靠人工补。这套正循环跑起来以后系统会越用越稳。二是让交付调度 Agent 具备更强的“关联分析”能力。现在它只是负责触发变更但如果它能结合监控数据判断这次变更有没有引起资源使用率异常、要不要自动回滚那整个系统的闭环程度又会往上走一个台阶。当然这里涉及到生产环境自动回滚的信任门槛短期我们不太敢把最后这道闸也交给智能体。我现在的体会是智能体自动化这事儿最大的艺术不是“让它做更多”而是“让它只做它擅长的事”然后把剩余的执行权牢牢握在人的手里。这套 IaC 交付流水线就是一个例子——四个智能体各司其职把过去几周的搬运活儿压缩到了几十分钟而我们释放出来的人力则真正扑到了架构设计和流程优化上。所谓压到分钟级省下的不是时间是整个团队的心力和节奏。