我们团队最近把基础设施代码的交付周期从“按周排期”压缩到了“按分钟聊天”本质就是一句话把 IaC 的编写、校验、部署、确认这四件原本靠人肉接力的事拆给四个智能体去干同时用 MCP 把外部工具链全部串起来。这篇文章就把这次落地的拆解思路、关键配置、具体执行过程以及我踩过的坑原原本本写出来。适合手里捏着多云账号、每天被 IaC 交付流程折磨的运维开发同学也适合准备把 Agent 真正接进生产链路、而不是停留在 Demo 阶段的实践者。1. 整体设计思路为什么用“四个智能体”而不是一个超级 Agent1.1 从“人肉流水线”到“智能体流水线”的转变先说我原来的交付链路。开发提需求平台组手工写 Terraform 模块安全组审策略运维组跑部署最后再由运维贴一个状态总结。整个过程在两到三周之间大头不在写代码而在“等人”和“等流程”。更麻烦的是每次交付的内容高度同构无非是一套 VPC、几个子网、一组安全组、若干计算实例但每次都要从头过一遍相同的流程。后来我开始尝试用 Bedrock AgentCore 做编排走的是 Agent MCP 的路线。所谓 AgentCore简单理解就是一个负责“拆任务、调工具、汇总结果”的大脑框架而 MCP 则是让大脑能真正触达外部系统的一组标准化工具接口。组合起来的效果是你告诉 Agent 要什么它自己决定先调哪个 MCP 工具再根据工具返回结果决定下一步动作。当时也犹豫过要不要只做一个超级 Agent把四个环节全塞进去。实测下来的结论是不要这么做。单 Agent 的上下文窗口会被四个环节的状态填满一旦中间某一步出错模型需要反复重读前面所有历史才能恢复状态错误率会快速上升。拆成四个独立智能体每个智能体只做一件事、只保留必要上下文定位问题和回溯逻辑都清晰得多。1.2 四个智能体的职责边界与协作逻辑四个智能体不是简单按顺序排班而是按照“交付物”来切分职责第一是需求解析智能体。它接收开发侧的自然语言请求拆出资源类型、网络拓扑要求、运行环境等关键参数。它的输出是一份结构化需求卡片相当于给后面三个智能体一个统一的工作输入。这里不需要它直接调基础设施 API它只用理解意图、补全缺失参数。第二是模块组合智能体。它拿到需求卡片后从 IaC 模块仓库里选取合适的模块按依赖关系组装成一份模板草案。这个环节会调用代码仓库的 MCP 服务把模块版本、输入变量查询清楚然后拼接出完整的 IaC 文件。它不负责最终正确性只负责生成符合结构的初稿。第三是策略校验智能体。它把模板草案丢给静态检查引擎同时对接策略服务检查资源命名规范、标签合规性、开放端口、存储加密等约束。通过则返回校验通过的代码版本不通过则带着违规项清单退回去触发模块组合智能体修订。这一步是质量闸门。第四是部署巡检智能体。它负责调用部署服务的 MCP 工具执行实际资源创建并轮询部署状态。部署完成后拉取当前资源快照和预期模板做对比确认没有漂移最后输出交付报告。到这里整个交付闭环才算真正结束。协作逻辑上有一个关键决策四个智能体之间不直接说话统一通过一个中间状态存储交换数据。前一个智能体把产物写入存储后一个智能体订阅读取。这样做的直接好处是流程可暂停、可重放、可审计某个环节挂了不会连带整个链路崩溃。2. 工具链选型与 MCP 服务清单2.1 Bedrock AgentCore 的几个关键配置AgentCore 在项目里承担的是编队控制台的角色。重点配置有三块。第一是 Agent 的指令集。我最初犯过一个错误把完整的公司 IaC 规范文档塞进系统提示词结果模型一执行长流程就开始丢三落四。后来改成“指令集只写工作方法与交接格式具体规范通过 MCP 工具实时查询”。指令集保持精简让模型把注意力放在意图理解上规则类内容全部外置成查询接口。第二是 Agent 之间的依赖关系。AgentCore 支持定义启动条件和输入输出参数类型。我给每个 Agent 定义明确的 schema前一个 Agent 的输出必须合法通过 schema 校验后才能触发下一个 Agent 的启动。这一步的价值是把模型生成内容的容错性兜底避免后面的 Agent 收到一个字段缺失的 JSON 就直接断链。第三是模型选择与温度参数。四类任务里需求解析和模板生成属于创意生成型任务温度调到 0.3 左右保留一点灵活度策略校验和部署巡检属于判断型任务温度我开到了 0追求结果稳定。2.2 MCP 服务端怎么规划MCP 在这个架构里等于神经系统所有智能体都是通过 MCP 去触碰真实世界。我这次一共接了五类 MCP 服务。模块仓库服务负责提供 IaC 模块的查询与版本读取策略引擎服务提供合规规则查询和校验结果返回状态存储服务提供各类交付状态的读写算是四个 Agent 之间的公共邮箱部署服务负责接收 plan 输出并触发执行云厂商服务负责拉取资源真实状态用于最终漂移检查。需要注意的一点是MCP 服务端的超时设置不能拍脑袋。早期我把所有超时统一设为 30 秒结果策略引擎在大目录上跑校验经常超时Agent 直接误判为工具不可用。后来按工具类型分开设置查询类短超时校验类中超时部署类长轮询才算稳定。2.3 权限边界怎么收紧智能体带权限是一把双刃剑给大了风险爆炸给小了流程跑不通。我这次的做法是给每个 Agent 单独建一个执行身份按最小权限分配。需求解析智能体不触发任何写操作只读状态存储模块组合智能体能写 IaC 文件到指定路径但无法触达生产集群策略校验智能体只拥有对策略引擎的只读调用权部署巡检智能体是唯一拥有写权限的角色而且它的写权限被限制在特定的资源组和标签范围内。这里的启示就是让 Agent 在既定轨道里运行比试图“教会” Agent 一百种边界更有意义。权限模型设计到位就算模型偶尔幻觉真正能造成的影响也被限制在最小半径内。3. 核心链路实操按一次交付流程走一遍3.1 需求解析与模块推荐拿一次新项目环境申请来演示。开发方原始诉求是“一套预发环境用来跑用户管理服务大约需要 4 个CPU16G 内存需要外网访问能力最好走按量计费不要包月。”需求解析智能体处理这段自然语言时直接抽出了几个核心字段环境级别 pre、资源类型 ecs、CPU 4 核、内存 16 G、网络公网、计费按量。结构化成 JSON 后它会回填一批缺失字段这类服务通常还需要一个云数据库实例、一个对象存储桶、两套安全组和一组告警规则。它按照历史项目模板补全了这些默认假设并把补全项标成“推断值”留给后续环节校验。这个环节的效果非常明显以前人肉沟通时经常出现一个需求聊一周的情况Agent 虽然不能百分百理解隐含语义但它能把所有假设显式列出来开发者一眼就能看出哪里不对修改效率高得多。3.2 模板生成与策略校验模块组合智能体拿到需求卡片后开始在模块仓库里挑选组件。这里有一个亮点它一次拉取所有候选模块的帮助文档再从根模块开始按依赖顺序递归构建。实际生成出来的模板不是一层平铺的资源清单而是按依赖树组织的多层结构。网络模块先生成然后是安全组依赖网络实例依赖安全组数据库依赖网络告警依赖实例与数据库。这种方式的好处是模块间依赖顺序被结构化表达后续部署时不再需要自行解析依赖。模板草案进入策略校验环节后MCP 调用静态检查引擎跑了一轮抓到两个问题一是开放了 22 端口到全网段不合规二是标签缺失。策略校验智能体把违规项打包成修订建议退回给模块组合智能体组合智能体按建议更新代码再提交。这一来回听起来简单在旧流程里意味着一次人工返工通常需要半天以上在智能体流水线里只花了不到两分钟。3.3 部署执行与漂移确认部署阶段体验比预想的顺。部署巡检智能体先对 IaC 模板做预检然后生成执行计划供人工确认。确认后通过部署服务触发资源创建接下来就是轮询状态。这里涉及一个并行度的取舍。第一版我设置每 10 秒轮询一次资源平均创建时间是 3 分钟整个流程耗时很长。后来改成指数退避轮询前 3 次间隔 5 秒然后 15 秒、45 秒逐步拉长整体效率提升明显。资源创建完成后最后一步是漂移检查。云厂商服务的 MCP 工具拉取当前真实资源快照与部署模板期望状态做对比。只要有不一致项就把差异写进交付报告。这一步在旧流程里常常被跳过结果环境出了问题根本说不清哪来的漂移。现在机制上强制校验相当于交付物自带质检报告。4. 效果数据与参数调优记录4.1 交付耗时从哪压下来的我把改动前和改动后的交付周期做了拆解对比。改动前端到端时间是 12 到 18 个工作日其中需求澄清占了 3 天模块开发占了 2 天策略评审排期 4 天部署窗口 3 天。真正在写代码的时间不到一天其余全在等待和沟通。改动后端到端首次成功交付的平均耗时是 8 分钟。需求解析 1 分钟模板生成与修订 2 分钟策略校验 1 分钟部署执行 3 分钟漂移确认 1 分钟。这里面最大的时间节省来自两部分等待时间消失了因为每个环节都是自动衔接返工周期消失了因为质量校验发生在写码环节之内。这里有一个配置项值得展开状态存储选型。我用的是带订阅通知的内存态存储加一个持久化备份。内存态保证事件广播快持久化备份保证流程可回溯。第一次我只用了内存态结果部署巡检智能体在处理延迟时前面的状态丢了导致重复创建资源亏了不小一笔费用。后来加了持久化备份和幂等键彻底根治。4.2 缓存、重试、模型这几个参数怎么调模型参数前面提过温度另外两个参数也直接影响了交付质量。一个是输出长度上限。模块组合智能体生成的 IaC 文件经常超过默认输出上限被截断了还自我感觉良好直接导致后续校验失败。我把输出长度上限提升到 8000 token同时要求模块组合智能体只输出核心代码块不含解释文字才把这类问题压下去。另一个是重试策略。AgentCore 支持自定义工具调用失败后的重试次数。我给的默认值是 3 次重试但实际效果并不理想。因为部分工具错误属于永久性错误比如模板语法错误重试多少次都一样。现在的策略是重试前先读错误类型可恢复错误最多重试 3 次不可恢复错误直接返回给上一级智能体由上层决定是否走修订流程。我动过最奇怪的一个参数是关闭了部分 Agent 的思维链输出。当时为了调试把思维链打开了结果发现这东西非常迷惑人模型思考得头头是道动作却完全跑偏。在 AgentCore 里我最终保留的配置是只输出最终行动摘要不输出完整推理链这样既方便调试又不会被推理过程误导。5. 常见问题与排查技巧实录5.1 交付慢、卡顿、失败三类高频问题速查问题一交付链路卡在“已启动”状态迟迟不往下走。这类问题十有八九是状态存储的订阅机制出了问题。我排查的方式是按事件编号追踪发现有个 MCP 服务端在返回事件时重复发送了一条旧事件导致下游智能体认定状态没有变化一直等待。解决方案是给状态存储补了去重逻辑只接受事件编号递增的消息。问题二模板生成时引用了不存在的模块版本。原因是模块仓库服务返回了缓存数据缓存中的版本号已经被下线。这个坑比较隐蔽因为日常查询正常只在特定版本更新后触发。我的排查方式是在模块组合智能体指令里加了“必须调用版本确认接口不能使用文档中记录的版本号”从根上绕开了缓存过期问题。问题三部署执行报权限错误。这个是配置身份时最容易犯的坑。我在调试阶段图省事给其中一个 Agent 配了大权限后面换回小权限时没有清理旧的会话令牌导致小权限身份一直携带大权限令牌去请求资源。排查半小时最后清掉所有会话记录重来。经验就是权限变更后必须强制刷新会话。5.2 三个避坑建议第一个建议是把 MCP 服务的错误信息规范化。模型对自由文本的错误返回理解能力有限但如果你把错误码和错误类型结构化成 JSON再让模型去判断准确率会高很多。这个改动看似不起眼却把整个系统的自主纠错能力提升了一个量级。第二个建议是给每个 Agent 的结果加“置信度”字段。Agent 自己认为有把握的就推进没把握的直接转人工确认。比如需求解析智能体补全了默认假设它会标注每条为“推断值”部署巡检智能体看到推断值较多时会主动拉人类确认。这套机制避免了智能体过度自信导致的问题。第三个建议是规划好人工介入点。我在这条流水线里留了两个强制人工确认点模板生成后由平台组负责人手动确认一次部署执行前由安全组手动确认一次。虽然压慢了自动化但这两个确认点保护了我们避开很多灾难场景。智能体负责效率人类负责判断这个分工模式我认为是当前阶段最务实的姿势。6. 写在最后的一些体会真正把四个智能体接进 IaC 交付链路后我最大的感受是流程复杂度从“人肉管理”变成了“编排管理”。以前我们被各种等待时间绑架个体的专业能力也经常被流程淹没。现在智能体把机械性部分全部吃掉了人反而回到了做判断的位置。如果你也要复刻这套方案我给一条实操顺序先把现有交付流程拆成可独立验证的环节再针对每个环节寻找对应的 MCP 工具最后才是搭 AgentCore 编排。顺序不能反否则你会陷入“先有智能体再找它的用途”的误区。我们当时是先接了 MCP 服务再让每个智能体围绕它们能触达的能力去设计任务整个过程顺了很多。还有一点印象很深这个架构有一个很好的副产品就是每个交付都能留下完整的执行轨迹。出了事故不用再开复盘会猜“当时到底谁改了哪儿”直接把事件序列拉出来看就行。这一点在推进 IaC 治理时价值甚至比省下的时间还大。