我们团队最近把基础设施代码的交付周期从“按周排期”压缩到了“按分钟聊天”，本质就是一句话：把 IaC 的编写、校验、部署、确认这四件原本靠人肉接力的事，拆给四个智能体去干，同时用 MCP 把外部工具链全部串起来。这篇文章就把这次落地的拆解思路、关键配置、具体执行过程，以及我踩过的坑原原本本写出来。适合手里捏着多云账号、每天被 IaC 交付流程折磨的运维开发同学，也适合准备把 Agent 真正接进生产链路、而不是停留在 Demo 阶段的实践者。
1. 整体设计思路：为什么用“四个智能体”而不是一个超级 Agent
1.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 个CPU，16G 内存，需要外网访问能力，最好走按量计费，不要包月。”
需求解析智能体处理这段自然语言时，直接抽出了几个核心字段：环境级别 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 治理时，价值甚至比省下的时间还大。
