AWS 四 Agent 级联编排：IaC 开发从数周压缩到分钟级

AWS Professional Services 刚刚发布了关于多智能体系统的生产数据，该系统将基础设施即代码开发周期从数周压缩到数分钟。系统使用 Amazon Bedrock AgentCore 原语将四个专业智能体（发现、IaC 生成、治理、运维）串联起来。这不是演示，是已部署的企业迁移工作流，有真实的客户案例支撑。

有趣之处在于 AWS 如何在智能体之间路由任务而不产生循环依赖，以及当一次迁移跨越四个具有不同失败模式的智能体时如何实现交接。

架构：四个智能体，一个工作流

系统将云迁移分解为四个智能体角色：

Discovery Agent：扫描现有基础设施，构建依赖图，识别迁移候选资源

IaC Generation Agent：将发现的资源转换为 Terraform 或 CloudFormation 模板

Portfolio Governance Agent：根据组织策略、成本预算、安全基线验证生成的 IaC

Post-Migration Operations Agent：监控已部署资源，处理漂移检测，执行修复

每个智能体都是一个具有工具访问权限的 Bedrock Agent，权限范围限定在其领域内。发现智能体无法部署基础设施。IaC 生成智能体无法读取生产凭证。治理智能体对策略存储库仅有只读访问权限。

AgentCore 使用状态机模式编排交接。当发现智能体完成扫描时，它将结构化输出（包含资源元数据、依赖关系和迁移就绪分数的 JSON Schema）写入 S3 桶。IaC 生成智能体通过 EventBridge 订阅该桶，仅在发现智能体将扫描标记为完成后才开始生成模板。

状态管理与交接原语

核心编排原语是存储在 DynamoDB 中的迁移清单。每个迁移项目都有一个包含以下字段的清单：

• project_id：迁移的唯一标识符
• current_stage：枚举值（discovery、iac_generation、governance_review、deployment、post_migration）
• agent_outputs：智能体名称到结构化输出 S3 URI 的映射
• validation_results：带通过/失败状态的管理检查数组
• deployment_state：Terraform 状态文件位置或 CloudFormation 堆栈 ARN

当智能体完成任务时，它更新清单并发布 EventBridge 事件。链中的下一个智能体订阅该事件类型，从 S3 读取前一个智能体的输出。

这种设计避免了循环依赖，因为智能体之间从不直接调用。它们通过不可变产物（S3 对象）和状态转换（ DynamoDB 更新）进行通信。如果治理智能体拒绝 IaC 模板，它会将 current_stage 设置回 iac_generation，并将拒绝原因写入 validation_results。IaC 生成智能体轮询清单，根据反馈重新生成模板。

Governance Agent：关键检查点

组合治理智能体是唯一可以阻止迁移的智能体。它运行一套验证工具：

成本估算：调用 AWS Pricing API 预测生成资源的月度支出

安全态势：对 IaC 模板运行 checkov 或 tfsec 以捕获配置错误

合规检查：验证资源是否符合组织标签策略、加密要求、网络分段规则

如果任何检查失败，治理智能体会将结构化拒绝消息写入清单并停止工作流。IaC 生成智能体必须解决所有失败问题，工作流才能继续。

此检查点防止了自动 IaC 生成创建违反组织策略的资源这一常见失败模式。治理智能体充当断路器。

授权边界

AWS 使用 IAM 角色在智能体之间强制执行最小权限访问：

只有运维智能体可以部署基础设施。发现和 IaC 生成智能体以只读或仅生成模式运行。这种分离限制了爆炸半径。如果 IaC 生成智能体生成了无效模板，治理智能体会在部署前捕获它们。

运维智能体承担具有时间限制凭证的角色。部署后，该角色过期。迁移后监控使用单独的就只读角色。

可观测性与失败模式

AWS 使用 CloudWatch Logs Insights 和 X-Ray 检测智能体交接。每个智能体记录包含这些字段的结构化 JSON：

{
  "project_id": "migration-12345",
  "agent_name": "iac-generation",
  "stage": "template_generation",
  "status": "success",
  "duration_ms": 4200,
  "output_uri": "s3://migrations/12345/iac-templates.zip",
  "errors": []
}

交接失败时，系统捕获：

超时错误：如果智能体在 15 分钟内未更新清单，EventBridge 触发死信队列处理器

验证错误：治理智能体将详细拒绝原因写入清单，IaC 生成智能体读取并用于优化模板

部署错误：运维智能体捕获 Terraform 或 CloudFormation 错误消息并写入 CloudWatch Logs

最常见的失败模式是 IaC 生成智能体生成的模板未通过治理检查。AWS 报告称，生成 IaC 的第一次迭代约有 60% 的时间能通过治理。智能体通常需要两到三次迭代才能满足所有策略。

代码示例：清单更新模式

以下是智能体完成任务后更新迁移清单的方式：

import boto3
from datetime import datetime

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('migration-manifests')

def complete_discovery(project_id, scan_results_uri):
    table.update_item(
        Key={'project_id': project_id},
        UpdateExpression='SET current_stage = :stage, agent_outputs.discovery = :uri, updated_at = :ts',
        ExpressionAttributeValues={
            ':stage': 'iac_generation',
            ':uri': scan_results_uri,
            ':ts': datetime.utcnow().isoformat()
        }
    )

    # Publish event to trigger next agent
    events = boto3.client('events')
    events.put_events(
        Entries=[{
            'Source': 'migration.discovery',
            'DetailType': 'DiscoveryComplete',
            'Detail': json.dumps({
                'project_id': project_id,
                'scan_results_uri': scan_results_uri
            })
        }]
    )

IaC 生成智能体订阅 DiscoveryComplete 事件并在收到事件时开始工作。

AWS 将此系统部署为一组 Lambda 函数（每个智能体一个），由 Step Functions 编排。每个 Lambda 函数：

• 从 DynamoDB 读取迁移清单
• 从 S3 下载输入产物
• 调用 Bedrock Agent API 执行智能体任务
• 将输出产物写入 S3
• 更新清单并发布 EventBridge 事件

Step Functions 提供重试逻辑和超时处理。如果智能体 Lambda 超时（15 分钟限制），Step Functions 以指数退避重试最多三次。

系统使用 Bedrock Agents，以 Claude 3.5 Sonnet 作为基础模型。每个智能体都有自定义指令集和工具定义。IaC 生成智能体具有用于读取 AWS 文档、查询 Terraform 注册表和验证 HCL 语法的工具。治理智能体具有用于运行策略即代码检查和查询成本估算 API 的工具。

AWS 报告了生产部署的这些指标：

• 发现阶段：典型企业应用程序（50-100 个资源）需要 5-10 分钟
• IaC 生成：每次迭代 3-5 分钟（平均需要 2 次迭代才能通过治理）
• 治理审查：1-2 分钟（仅自动化检查）
• 总工作流时间：从发现到部署就绪 IaC 需要 15-30 分钟

每个迁移项目的成本：

• Bedrock API 调用：$2-5（取决于资源数量和迭代次数）
• Lambda 执行：$0.50-1.00
• DynamoDB 和 S3：可忽略不计
• 总计：每个迁移项目 $3-7

相比之下，手动 IaC 开发，AWS 估计每个应用程序需要 2-4 周的工程师时间。

最大的运营风险是治理智能体成为瓶颈。如果组织策略模糊或相互矛盾，IaC 生成智能体可能会无限迭代而无法满足所有检查。AWS 建议从一小套高优先级策略开始，逐步扩展。

适用场景

当存在以下情况时使用此模式：

• 需要迁移的应用程序组合（10+ 个项目），手动 IaC 开发成为瓶颈
• 组织有明确定义的基础设施策略，可以编码为自动化检查
• 需要在部署生成的基础设施之前提供审计跟踪和治理检查点
• 已在使用 AWS 和 Bedrock（集成工作量最小）

当存在以下情况时避免此模式：

• 迁移单个应用程序（开销大于收益）
• 基础设施策略仍在演变或记录不佳（治理智能体会阻止一切）
• 需要对 LLM 提示和工具定义进行细粒度控制（Bedrock Agents 将这些抽象掉了）
• IaC 生成需要亚秒级延迟（多智能体交接增加了协调开销）

真正的价值不在于 IaC 生成的速度，而在于能够对数十或数百个迁移项目应用一致的治理策略，而无需人工审查。多智能体架构使得添加新的验证检查（安全扫描、成本优化、合规审计）变得容易，而无需重写整个系统。