企业官网建设流程全解析

把 IaC 交付从数周压到分钟级，靠四个智能体接力完成，这套方案我落地跑通之后，最大的感受是：真正值钱的不是某个模型多聪明，而是把 Agent 的工作流、MCP 工具链和人的检查点编排清楚。

我做的这个模拟项目，核心是用 Bedrock AgentCore 编排了四个智能体，分别负责需求拆解、架构生成、代码落地和复核交付，配合 MCP 协议把 IaC 相关的工具全部暴露给 Agent 调用。以前一个云基础设施的 IaC 模块从需求对齐到 PR 合并，怎么也得两三周——需求来回确认、架构评审、代码 review、环境联调，每一步都有人在等。现在四个 Agent 流水线接力，只要输入一段业务意图，几分钟内就能看到完整的 Terraform 代码和部署方案。

这篇文章我把整个落地的思路、Agent 分工逻辑、MCP 工具的注册方式、踩过的坑和排查实录都整理出来，适合正在做 AI 工程化、想用 Agent 改造内部交付流程的团队参考。不管你是刚接触 Bedrock AgentCore，还是已经用过一阵，这篇能把“Agent 编排 + MCP 工具链”这套组合的落地细节讲透。

1. 整体设计拆解：四个 Agent 为什么这么分？

先说清楚一个问题：为什么是四个智能体，而不是一个超级 Agent 全干完？

我在早期尝试过用一个 Agent 包揽所有事情——给它配置了一堆工具，让它从需求理解一直干到代码输出。实际跑下来的结果是：单 Agent 在长链路任务里非常容易“迷失”，前面步骤的输出质量会直接影响后面，而且出了问题很难定位是哪个环节的锅。用四个职责单一、层层递进的 Agent 接力，本质上是在模仿成熟团队的分工模式——需求分析、架构设计、编码实现、质量把关各司其职。

1.1 分工逻辑：每层只做一件事，输入输出都是标准产物

四个 Agent 的职责划分如下：

• 解析 Agent：接收业务侧的自然语言需求，拆解成结构化基础设施需求，输出部署目标、预算约束、区域优先级等元数据。
• 架构 Agent：基于解析产物，检索公司内部的 IaC 最佳实践库，设计模块划分与云资源拓扑，输出架构描述文件。
• 实现 Agent：根据架构文件，生成具体的 IaC 代码（Terraform / CloudFormation），逐模块落地。
• 复核 Agent：对生成的代码做一致性检查、安全扫描和成本估算，发现问题直接打回前面环节。

这种分层的本质，是把“生成”这个大问题拆成“决策」和“执行”的组合。你可以这样理解：解析 Agent 是在搞清楚“要什么”，架构 Agent 是在决定“怎么设计”，实现 Agent 是在做“物理落地”，复核 Agent 是在保证“不跑偏”。每一步的产物都是下一步的输入，中间任意一步出问题，都只需要替换或者重跑单个环节，而不是把整条链路推翻。

1.2 为什么选 Bedrock AgentCore，而不是自己搭编排框架？

市面上的 Agent 编排方案不少，LangChain、自研工作流引擎我都试过。最终选了 Bedrock AgentCore，核心原因是它把基础设施层面的东西都托管了。

AgentCore 底层跑的是多 Agent 协作框架，你不需要自己维护会话状态、工具调用路由、上下文窗口管理这些琐碎事。它对 Bedrock 系列的模型做了深度适配，调用成本也比直接裸调模型低不少——因为 AgentCore 会自动把对话历史压缩、把工具返回的大段内容截断，只保留与当前任务相关的部分。

用一句话总结就是：AgentCore 帮我把“自己写一个 Agent 框架”这件事省了，我可以把全部精力放在定义 Agent 行为和工作流上。如果你所在的团队已经有自研编排框架的沉淀，不一定非要迁移，但如果你是从零开始，直接用 Bedrock AgentCore 绝对是性价比最高的路径。

2. MCP 工具链接入：Agent 的“手”是怎么长出来的？

Agent 光会“想”不行，它必须能“做”。这里“做”指的是真正去读取 IaC 模板库、调用 Terraform 命令、查询云资源现状。这些动作全部通过 MCP（Model Context Protocol）暴露给 Agent。

2.1 MCP 在项目里承担的角色

MCP 解决的核心问题是：让 Agent 能以一种标准化的方式访问外部工具和数据源。你可以把它理解成一个 USB 接口——外部工具只需要实现 MCP 协议，Agent 就能即插即用地调用，不需要为每个工具单独写集成代码。

这个项目里我搭建了几个关键的 MCP 服务器：

• 模板库 MCP：封装了内部 IaC 模板仓库的检索接口，Agent 可以根据资源类型搜索合适的基线模板。
• Terraform 执行 MCP：封装了terraform validate、terraform plan、terraform apply等命令，Agent 能直接执行并获取输出。
• 云资源查询 MCP：对接云厂商 API，让 Agent 能查当前账号下的资源存量、配额、可用区信息。
• 成本估算 MCP：调用定价 API，对生成的资源配置做成本预估。

每个 MCP 服务的实现都不复杂，核心是把工具调用封装成{name, description, input_schema}的结构，然后注册到 AgentCore 的工具列表里。

2.2 工具定义的细节：描述写得好，Agent 才调得准

我踩过的一个大坑是：工具描述写得含糊，Agent 就不知道该在什么时候用这个工具。MCP 的 tool definition 里有description字段，这个字段不是给人看的，是给模型做意图匹配用的。你必须把“什么时候该调用这个工具”“调用它会得到什么结果”“有哪些典型使用场景”都写清楚。

举个例子，我最初给 Terraform 执行 MCP 的定义一个方法时，描述只写了“execute terraform command”。结果 Agent 经常在需要读取代码的时候去调terraform apply，链路直接断了。后来我把描述改成：

用于执行 Terraform 命令，支持 validate、plan、apply、destroy。 当需要检查 IaC 代码合法性、预览资源变更计划或实际部署资源时调用。 严禁在生产环境直接调用 apply，必须先经过复核 Agent 确认。

改完之后，工具调用的准确率明显上升。这件事给我的启发是：MCP 工具注册的边界、描述、约束条件，本质上是在给 Agent 立规矩，这个环节值得花时间精雕细琢。

2.3 并发与资源控制：四个 Agent 同时跑，怎么不打架？

Agent 之间是有依赖关系的，但实际执行中，某一层的输出可能会触发另一层的多个并行子任务。比如实现 Agent 在生成代码时，可能会同时调用模板库查询、云资源配额查询和 Terraform 校验。这三个工具调用如果串行跑，体验非常差，所以我在 MCP 服务器层面做了并发设计。

具体做法是：每个 MCP 服务器都支持并发请求，但针对云厂商 API 的调用做了限流——单账号下 API 有配额限制，并发太高会被限流甚至封禁。我在工具内部加了一个简单的信号量控制，同一账号的 API 调用最多 5 个并发，超出的排队等待。这个数字是拿实际压测对出来的，官方文档的上限是 10 个请求/秒，但留足余量之后稳定性最好。

3. 实操过程：一个需求从输入到 IaC 落地的完整链路

这一节我直接拿一个典型需求来跑一遍整个流程，把关键步骤、参数配置和产物样式都贴出来，你可以照着这个链路复现。

3.1 需求端：输入的自然语言长什么样？

我们给系统定义了一个标准化的需求输入模板，业务方只要按这个模板填内容：

{ "project_name": "模拟项目X", "environment": "production", "region": "ap-southeast-1", "compute": { "service_type": "web_app", "estimated_qps": 2000, "availability_requirement": "99.95%" }, "data": { "database_engine": "mysql", "storage_size_gb": 500, "backup_required": true }, "constraints": { "monthly_budget_usd": 5000, "compliance_standard": "iso27001" } }

这里有几个设计点需要说明：

• 结构化输入不是限制，反而是在帮解析 Agent 减负。相比让 Agent 从一段散文里抽取意图，结构化的输入能保证必填信息不缺失、格式可校验。这也是我在项目里反复强调的一个原则：不要让 Agent 做不必要的信息提取，能用程序保证的就不用模型猜。
• region 这种字段直接枚举，不做自由填空， Agent 不会拿一个不存在的区域名去生成代码。

3.2 解析 Agent 工作过程：从需求到结构化规格

解析 Agent 拿到输入后，并不会立刻生成架构，而是先做一次需求完整性校验。它通过 MCP 调用云资源查询工具，确认目标 region 的资源配额是否满足要求——比如 ap-southeast-1 默认的 VPC 配额、EC2 运行实例上限，这些数据会直接影响后面的架构设计。

解析 Agent 的提示词（Prompt）里我预设了一组规则：

• 必须输出统一的规格 JSON，字段名固定，缺失字段填null而不是删除键。
• 如果需求中的约束与云厂商默认配额冲突，必须标注conflict_flag并给出调整建议。
• 预算估算结果必须附带计算依据，不能只给一个数。

这段规则非常重要。我发现如果只让 Agent“分析需求”，它输出的东西会非常发散。限定输出格式、限定异常处理方式，解析 Agent 才能产出真正可用的规格文档。

这一步的典型产物长这样：

{ "resource_requirements": { "ec2_instance_type": "m6i.2xlarge", "instance_count": 5, "rds_instance_class": "db.r6g.xlarge", "storage": { "engine": "aurora-mysql", "allocated_storage_gb": 500 } }, "network": { "vpc_cidr": "10.0.0.0/16", "subnet_count": 4, "enable_nat_gateway": true }, "cost_estimate": { "monthly_estimate_usd": 4320, "within_budget": true }, "conflict_flags": [] }

看到没，解析 Agent 干了第一步的“翻译”工作：把业务需求翻译成资源需求。这一步没做好的话，后面全是空中楼阁。

3.3 架构 Agent 工作过程：模板检索与拓扑设计

架构 Agent 拿到规格 JSON 后，第一件事是通过模板库 MCP 检索匹配的基线模板。我在模板库里按场景预置了几套方案——Web 应用三节点架构、批处理任务集群、微服务基础骨架——并给每个模板打了标签，比如high_availability、cost_optimized、data_heavy。

架构 Agent 的工作不是从零设计，而是“选模板 + 按需调整”。这背后是一个重要的设计取舍：让 Agent 在成熟模板上做增量修改，远比自己从零生成一套架构可靠。模型再聪明，也不可能比团队沉淀多年的最佳实践更懂你的业务。

架构 Agent 输出的产物是一份拓扑描述文件，包含了 VPC、子网、安全组、实例、数据库等资源的逻辑关系。这里我要求它同时输出一份架构决策记录（ADR），说清楚为什么选这个实例类型、为什么这样划分子网，方便后面复核 Agent 做一致性检查。

实际上跑下来，架构 Agent 是四个 Agent 里最“省力”的一个——因为模板库把大部分复杂决策都承载了，它只需要做参数映射和偏差判断。这也是我在项目里体会最深的一点：给 Agent 减负，就是把专业知识前置到工具和模板里，而不是指望模型全知全能。

3.4 实现 Agent 工作过程：生成代码与逐模块校验

实现 Agent 是整个链路里最“重”的环节。它根据架构文件，按模块生成 Terraform 代码，每生成一个模块就调用一次terraform validate，语法通过才继续下一个模块。

我放一段实际生成的主配置片段：

# VPC 模块 resource "aws_vpc" "main" { cidr_block = var.vpc_cidr enable_dns_support = true enable_dns_hostnames = true tags = { Name = "${var.project_name}-vpc" Environment = var.environment ManagedBy = "agentcore" } } # 子网模块 resource "aws_subnet" "private" { count = length(var.private_subnet_cidrs) vpc_id = aws_vpc.main.id cidr_block = var.private_subnet_cidrs[count.index] availability_zone = var.azs[count.index] tags = { Name = "${var.project_name}-private-${count.index + 1}" } }

实现 Agent 这里有一个关键参数：单次生成的资源数量上限。我最初设置成一次性生成所有资源，结果超过 20 个资源后代码质量明显下降——变量名开始混乱、资源间引用关系出错。后来改成按模块分批生成：先 VPC，再子网，再安全组，再 EC2/RDS，每批控制在 10 个资源以内，质量立刻稳定了。

这种问题的本质是 LLM 生成长文档时的“注意力漂移”——信息太多，模型就容易顾此失彼。分批生成 + 每批验证，实际上是在用流程对抗模型的注意力上限。

3.5 复核 Agent 工作过程：打回、修正、终审

复核 Agent 拿到完整代码后，会做三重检查：

• 一致性检查：对比架构文件与生成的代码，确认每个子网、安全组、路由表都对应上了。
• 安全扫描：检查安全组是否放通了过于宽泛的端口范围、是否有敏感信息硬编码。
• 成本复核：调用成本估算 MCP，把最终资源配置的月成本重新算一遍，与预算对比。

这里我设置了一个非常实用的规则：复核 Agent 发现问题时，不能直接修改代码，而是要打回给实现 Agent，附带问题描述和修改建议。这个设计看起来很绕，但实际效果很好。直接让复核 Agent 改代码会出现连锁错误——它改了一个资源，可能导致另一个资源的依赖关系也变了，而它没有能力检查这种隐式影响。打回重改则保证了每次都经过实现 Agent 的“完整理解 + 重新校验”流程。

实测下来，四层链路走一遍，第一次通过率大概在 65% 左右。剩下的 35% 需要打回一到两轮，但每轮耗时基本在 1-2 分钟，相比整个流程来说完全可接受。

4. 关键技术参数与配置详解

这一节把 AgentCore 和 MCP 的配置细节整理成表，方便你直接对照落地。

4.1 AgentCore 侧的关键配置项

让我展开说一下“不同 Agent 用不同模型”这个选择。解析和复核 Agent 的任务本质上是对已有信息做整理和判断，用轻量模型（比如 7B-14B 量级）完全能胜任，成本低、速度快。架构和实现 Agent 需要真正的推理能力——把模板适配到具体需求、跨资源生成维护关系——这时候必须用大模型。分模型部署一个月跑下来，成本比全部用大模型能省差不多一半，而交付质量没有可见下降。

4.2 MCP 工具注册时的 schema 写法注意事项

MCP 工具的 input schema 直接决定了 Agent 怎么组织参数。有一点我要特别提醒：不要把太多参数做成必填项，要给 Agent 留出自行判断的空间。

比如模板检索工具的 schema，我最初把所有过滤条件都设成必填——资源类型、区域、高可用等级、成本档位。结果 Agent 在信息不足的时候会胡编参数去调用工具，反而拿回错误的结果。后来我把大部分过滤条件改成可选，只在 description 里写清楚“推荐结合规格 JSON 中的字段进行过滤”。这样 Agent 会把已有的结构化信息自然映射到工具参数上，而不是强行补全未知字段。

下面是优化后的模板检索工具 schema 示例：

{ "name": "search_template", "description": "根据资源类型、高可用需求、成本档位检索内部 IaC 基线模板。适用于架构设计阶段的模板匹配。", "input_schema": { "type": "object", "properties": { "resource_type": { "type": "string", "enum": ["web_app", "batch_job", "data_store", "lambda_microservice"], "description": "资源类型，来自解析 Agent 输出的 resource_requirements" }, "availability": { "type": "string", "enum": ["standard", "high"], "description": "高可用等级，可选。99.9% 以下用 standard，99.95% 及以上用 high" }, "cost_tier": { "type": "string", "enum": ["economy", "balanced", "performance"], "description": "成本档位，可选。按预算松紧程度选择" } }, "required": ["resource_type"] } }

4.3 提示词设计：让 Agent 知道边界比知道方法更重要

在 Agent 编排项目里，提示词的核心功能不是教 Agent 怎么做，而是告诉它“什么不能做、做错了怎么纠正”。我在这套系统里给每个 Agent 都配了行为准则区，这里挑三个关键规则：

• 规则一：禁止跳过验证步骤。实现 Agent 每完成一个模块，必须调用terraform validate，未通过之前不得进入下一个模块。这条规则保证代码质量是“过程产出”而不是“事后补救”。
• 规则二：不确定时必须标注。任何一步，如果 Agent 对需求理解没有把握，必须在产物里打上uncertainty标记，而不是带着疑问继续往下走。这个设计是为了避免 Agent “硬着头皮猜”，如果架构 Agent 猜错了拓扑，实现 Agent 会在错误的基础上生成一套精妙的错误代码。
• 规则三：禁止编造工具输出。如果工具调用失败，Agent 必须如实记录错误信息并报告上一环节，不能自己在回复里写一个“假输出”凑数。这个现象在早期测试里真实出现过——某个 Agent 调用模板库超时，直接在下一步里编了一个模板 ID 继续跑，最后产出的代码引用了不存在的基线。

这三条规则看着简单，但每一条都是从实际故障里提炼出来的。我建议你在自己的项目里也建立一份“负面清单”——把你遇到过的问题转写成规则，比用任何提示词模板都管用。

5. 常见问题与排查技巧实录

这一节是实战撞出来的经验。我按问题出现的频率排序，每个问题都说清楚现象、排查过程和最终的解决方案。

5.1 Agent 之间上下文“串味”

现象：解析 Agent 输出的规格里带了上一轮对话的残留信息，比如上一次需求里的项目名，这次也带出来了。

排查过程：最开始我以为是大模型幻觉，后来发现是 AgentCore 共享会话上下文导致的。四个 Agent 虽然在逻辑上是链路关系，但底层共用了一个会话线程，前面的对话历史没有被清理干净。我翻了 AgentCore 的日志，确认问题出在会话管理上，不是模型问题。

解决方案：在 Agent 间切换时强制做上下文隔离。每个 Agent 的输入输出都用独立的会话 ID 管理，转交产物时只传结构化 JSON，不传原始对话记录。改造之后，“串味”问题再没出现过。

5.2 Terraform 校验偶尔超时

现象：实现 Agent 调用terraform validate时，偶发超时（超过 60 秒无响应），导致整个链路卡住。

排查过程：观察超时发生的时间点，发现集中在模板库 MCP 返回大体积模板文件之后。原因是 Terraform 初始化需要在 provider 加载时访问插件仓库，如果本地没有缓存，网络波动会导致下载超时。

解决方案：在 Terraform 执行 MCP 里加了缓存预热的逻辑——每次链路启动前，先预执行一次terraform init把所有插件缓存到本地。另外把超时时间从 60 秒调到 180 秒，给网络波动留足余量。两个改动之后，超时问题基本消失。

5.3 复核 Agent 漏检安全问题

现象：有一次生成的安全组规则放通了 0.0.0.0/0 对 3306 端口的访问，复核 Agent 没有标红，代码直接通过了。

排查过程：回看复核 Agent 的调用日志，发现它确实调用过安全扫描工具，但工具返回的结果是“warning 级别，未阻断”，Agent 看漏了。原因是我配置的扫描规则把高危规则设成了 warning 而不是 error，Agent 在“通过”倾向驱动下直接忽略了 warning 信息。

解决方案：把所有高危规则（公网访问数据库、管理端口任意来源等）的扫描级别提升到 error，并且强制要求复核 Agent 在最终结论里列出所有已发现的 warning 及其处置决定。这相当于给 Agent 加了一道“必须表态”的流程，不能默默忽略。

5.4 工具调用参数幻觉

现象：架构 Agent 在调用云资源查询工具时，有时会把 region 参数填成eu-west-2，但需求明明指定的是ap-southeast-1。

排查过程：对比工具调用记录和输入上下文后发现，Agent 是从模板库里示例数据的 region 字段偷了参数。这个问题本质上是我在模板库里放了一条包含 region 字段的示例记录，Agent 被示例“带偏”了。

解决方案：把模板库的示例记录改为不包含具体区域名，并用代码在工具调用前做一层参数校验——如果调用参数与输入规格冲突，直接拒绝调用并提示 Agent 重新检查。这层校验是硬性的，不依赖模型自觉。

5.5 链路重试风暴

现象：一次云厂商 API 临时故障，导致多个工具调用同时失败，四个 Agent 同时进入重试循环，几分钟内打了几百次 API，账单明显升高。

排查过程：查日志发现重试逻辑是 AgentCore 内置的默认行为——工具调用失败时自动重试，默认 3 次。但因为链路中多个环节同时失败，3 次重试被级联放大，形成了风暴。

解决方案：给关键的云资源查询工具设置了自定义重试策略——最多 2 次，且重试间隔呈指数退避（1 秒、4 秒）。同时增加了全局熔断开关：连续失败超过 5 次就暂停整个链路，转人工处理。调整后，API 故障时链路会快速失败而不是硬耗。

6. 经验总结：这套方案的迁移价值与适用边界

整套系统从设计到落地，我最大的体感是：Agent 工程的复杂度不在模型选择，而在工作流编排和工具链打磨。四 Agent 接力的架构，本质上是把“需求-设计-实现-复核”这个成熟团队的协作模式固化成了可自动运行的流水线。

关于这套方案的迁移价值，我建议你根据自己的场景做判断：

适合直接复用的场景：交付链路长、环节分工明确的工程任务。比如 IaC 生成、API 脚手架生成、数据管道配置生成，这些任务都有清晰的阶段划分、有明确的中间产物（设计文档、配置文件）、有可校验的最终产出。

需要改造后使用的场景：任务链条较短但单步复杂度高的场景，比如独立算法实现。这时候四 Agent 的划分就太重了，更合理的做法可能是“一个执行 Agent + 一个复核 Agent”的轻量组合。

不适合用这套模式的场景：需要连续多轮人机共创、需求高度开放的任务。比如产品规划、数据探索，这些任务的价值不在“生成结果”，而在“对话过程中逐步明确目标”，流水线式的 Agent 编排帮不上忙。

最后说一个我踩过多次之后沉淀下来的心得：Agent 系统的稳定性上限，由“校验工具的严格程度”决定，而不是由“模型能力”决定。模型会给你一个 90 分的结果，但如果没有强校验把它背后那 10% 的隐性错误兜住，这个结果落到生产环境就是事故。所以做 Agent 工程，一定要把“校验逻辑”和“回退机制”放在和“生成逻辑”同等重要的位置。

这套方案目前的扩展方向，我还在做两件事：一是把复核 Agent 的检查规则从硬编码迁移到可配置规则库，让运营人员可以在不碰代码的情况下调整扫描策略；二是把解析 Agent 的接入方式从结构化 JSON 扩展为支持自定义字段映射，降低业务方的接入成本。后续有结果了再来同步。