AWS 专业服务使用基于 Amazon Bedrock AgentCore 的智能体 AI 扩展云迁移

以Agentic AI在Amazon Bedrock AgentCore上扩展云迁移，首先要认识到大规模迁移在哪些环节会陷入困境。发现阶段每个应用要耗费数周时间。工程师为每个工作负载从头编写基础设施代码。迁移后的运维退化为被动救火。将这些瓶颈乘以300多个应用和固定的财年截止日期，迁移项目便难以跟上节奏。本文中的多智能体框架将基础设施即代码（IaC）开发时间从每个应用3至4周缩短至几分钟，覆盖300多个应用组合。该结果基于内部项目跟踪数据。

AWS Professional Services构建了一套专用AI智能体，以应对迁移生命周期中的这些瓶颈，从自动化发现到主动式迁移后运维。这些智能体使用Strands Agents SDK，并运行在Amazon Bedrock AgentCore上——这是一个可大规模构建、连接和优化智能体的平台，支持任何框架或模型。

在本文中，你将探索一个多智能体编排框架的架构，该框架可端到端加速企业云迁移。你还将看到定义智能体、将其连接到工具以及应用负责任AI控制的代码。该框架包含四个智能体：

• Intake Agent，用于自动化发现。
• IaC Agent，用于生成符合你安全最佳实践的IaC。
• Migration Intelligence and Governance Agent，用于组合级报告和Well-Architected评估。
• Site Reliability Engineering（SRE）Agent，用于主动式运维。

要继续操作，你需要一个可访问Amazon Bedrock AgentCore和Amazon Bedrock基础模型（FM）的AWS账户。你还需要熟悉Strands Agents SDK和Model Context Protocol（MCP）服务器模式，以及你所在组织使用的IaC工具。

为什么迁移项目需要不同的方法

在大型企业数据中心退出迁移项目中，始终会出现三个核心瓶颈。

手动接收开销：大多数应用迁移从发现开始：了解本地架构、清单、依赖关系和接收问卷。手动发现每个应用要耗费数周时间。在300多个应用中，仅这一瓶颈就可能威胁到激进的迁移时间表。

重复的基础设施开发：当工程师定义目标架构时，他们会编写IaC来配置AWS基础设施。如果没有自动化，为每个应用从头编写IaC通常需要每个应用3至4周。在300多个应用组合中，这相当于数年的工程工作量。

被动式迁移后运维：迁移后，团队依赖手动监控和被动响应。如果没有主动智能来检测性能下降或自动修复问题，持续的运维负担会随时间累积。

这三个瓶颈贯穿迁移生命周期。解决它们需要将重复性工作转移给AI智能体，同时人类保留决策权。

架构概述

多智能体编排框架通过专用智能体能力应对每个瓶颈。该架构覆盖从本地发现到迁移后运维的整个迁移生命周期。框架在生命周期的每个阶段都应用了安全措施。下图展示了智能体、工具和AWS服务之间的连接方式。

该框架将智能体组织为两个旅程。迁移旅程智能体处理从发现到部署的工作。运维旅程智能体处理迁移后的监控。

• Intake Agent（阶段1）：自动化应用发现和目标状态架构定义，并包含依赖关系映射。
• IaC Agent（阶段2）：生成符合你安全最佳实践和标准的IaC代码。
• Migration Intelligence and Governance Agent：在Jira、Confluence和Webex中提供自动化组合报告、Well-Architected评估和迁移治理。

• SRE Agent（阶段3）：提供主动式迁移后监控和自动修复。

• AWS Database Migration Service（AWS DMS）：用于数据库迁移的生成式AI辅助架构转换和自动切换。
• AWS Transform：针对遗留代码的应用特定现代化改造。

组件如何连接

本节描述框架组件在运行时如何交互。

每个智能体都是一个Strands智能体，由基础模型、系统提示词和一组工具定义。Amazon Bedrock AgentCore运行时在具有会话隔离和多智能体编排的无服务器环境中托管它们。Amazon Bedrock基础模型驱动推理能力，用于解释文档、生成代码和推动多步骤工作流。有关各AWS区域中的模型可用性，请参阅Amazon Bedrock中的支持基础模型。

每个Agent通过AgentCore Gateway（Amazon Bedrock AgentCore的一项功能）调用与其职能范围相匹配的MCP工具，该网关可将您的API、AWS Lambda函数及现有服务转换为兼容MCP的工具。AgentCore Identity（Amazon Bedrock AgentCore的另一项功能）通过作用域限定的AWS Identity and Access Management（IAM）角色和您的身份提供商对每次调用进行身份验证。

Amazon Bedrock AgentCore内存存储Agent会话状态和共享上下文。Agent利用此共享上下文来持久化输出，并跟踪超过300个应用程序的迁移进度。当Intake Agent完成发现阶段后，它会将目标架构和依赖映射写入AgentCore内存。IaC Agent读取此共享上下文即可开始代码生成，无需人工交接。

用代码定义Agent

以下Python示例定义了IaC Agent，并为其在Amazon Bedrock AgentCore运行时中运行做好准备。该Agent通过AgentCore Gateway访问您的MCP工具，并通过Amazon Bedrock调用基础模型，同时附加了Amazon Bedrock Guardrails策略。

import logging
 import os
 from bedrock_agentcore.runtime import BedrockAgentCoreApp
 from strands import Agent
 from strands.models import BedrockModel
 from strands.tools.mcp import MCPClient
 from strands.tools.mcp.mcp_types import MCPClientCredentials

 logger = logging.getLogger(__name__)
 app = BedrockAgentCoreApp()

 REGION = os.environ["AWS_REGION"]

 # url+auth 让SDK执行client_credentials授权，并在令牌过期时重新签发。
 # 静态捕获的bearer令牌会过期失效。
 gateway = MCPClient(
     url=os.environ["GATEWAY_MCP_URL"],
     auth=MCPClientCredentials(
         client_id=os.environ["GATEWAY_CLIENT_ID"],
         client_secret=get_secret("gateway/client_secret"),
         scopes=[os.environ["GATEWAY_SCOPE"]],
     ),
 )

 model = BedrockModel(
     model_id=os.environ["MODEL_ID"],
     region_name=REGION,
     guardrail_id=os.environ["GUARDRAIL_ID"],
     guardrail_version=os.environ.get("GUARDRAIL_VERSION", "1"),
     guardrail_trace="enabled",
 )



 @app.entrypoint
 def invoke(payload, context):
     prompt = (payload.get("prompt") or "").strip()
     if not prompt:
         return {"status": "error", "error": "missing required field: prompt"}

     try:
         # tools=[gateway]: SDK负责连接生命周期并分页处理
         # 工具发现，这是list_tools_sync()单独无法完成的。
         agent = Agent(
             model=model,
             system_prompt=IAC_AGENT_PROMPT,
             tools=[gateway],
         )
         result = agent(prompt)

         if result.stop_reason == "guardrail_intervened":
             logger.warning("guardrail blocked request, session_id=%s",
                            getattr(context, "session_id", None))
             return {"status": "blocked_by_guardrail"}

         return {"status": "ok", "iac": str(result)}

     except Exception as e:
         logger.exception("invocation failed, session_id=%s",
                          getattr(context, "session_id", None))
         return {"status": "error", "error": str(e)}



 if __name__ == "__main__":
     app.run()

入口点将生成的IaC返回给调用方，AgentCore运行时负责处理会话隔离和扩展。有关可部署的端到端示例，请参阅GitHub上的Amazon Bedrock AgentCore示例仓库和Strands Agents示例仓库。有关部署步骤，请参阅AgentCore运行时入门指南。

阶段1：Intake Agent用于自动化发现

Intake Agent自动化了迁移中最耗时的第一步：了解本地现有环境并确定其在AWS上的目标位置。

该Agent摄取本地架构文档、应用程序清单列表、迁移调查问卷和依赖映射。随后，它生成目标AWS架构，包括推荐的迁移模式、资源规格说明和合规性验证报告。

Intake Agent解决了人工接收瓶颈问题。其输出直接输入IaC Agent，实现了从发现到基础设施配置的自动化交接。

阶段2：IaC Agent用于自动化基础设施代码生成

AWS Professional Services率先在组合中部署了IaC Agent，它带来了最直接可衡量的影响。该Agent生成符合您安全最佳实践和标准的IaC代码。

工作原理

步骤1：摄取指导文档。Agent从wave团队读取指导文档，提取部署范围、合规约束以及安全办公室批准的wave特定覆盖项。

步骤2：解读目标状态架构图。IaC Agent利用Intake Agent的输出，识别基础设施组件、它们之间的关系和依赖。

步骤 3：生成 IaC。 基于此解读，代理使用您定义并建立的模式生成 IaC。它使用特定于波次的参数填充配置，并配置远程状态管理。然后，它应用强制标签，并添加组织标准所需的监控配置。

步骤 4：通过 Amazon Bedrock AgentCore 中的 Policy 进行验证。 在执行前，AgentCore 中的 Policy 会根据 Cedar 规则评估每个工具调用。它计算潜在变更的范围，检查与并发波次的依赖冲突，并确认合规窗口的有效性。

步骤 5：执行并报告。 集中式执行平台触发 IaC，监控部署，并通过 AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）报告结果。部署后验证自动运行，合规性指标实时更新。

自定义 MCP 工具：安全基础

每个操作都通过由 Amazon Bedrock AgentCore Gateway 暴露并由 AgentCore Identity 和 AgentCore 中的 Policy 管理的自定义 MCP 工具进行。AgentCore Identity 通过具有最低权限访问范围的 IAM 角色对每个代理操作进行身份验证。框架根据定义的架构验证输入，并在边界拒绝格式错误的输入。

没有凭据或敏感值通过代理上下文传递，因为 AgentCore Identity 在运行时从集中式凭据提供程序解析密钥。AgentCore Observability 和 AWS CloudTrail 将每个代理操作写入不可变的集中式审计跟踪。AgentCore 中的 Policy 强制执行 Cedar 规则，有助于防止单个操作影响超过定义的阈值。

基于您模式的 IaC 生成

IaC 代理根据您定义并建立的模式生成基础设施代码。这些模式将组织标准编码为可重用的构造。它们包括网络配置、安全组规则、IAM 角色、Amazon CloudWatch 警报、Amazon Elastic Compute Cloud（Amazon EC2）配置、Amazon Virtual Private Cloud（Amazon VPC）布局和强制标签。

这种方法为各波次提供了一致性，为无需从头编写基础设施代码的波次团队提供了速度，并实现了治理，安全更新可在下一次部署周期中传播给使用者。

输出产物

该代理为每个应用程序生成 IaC 代码、自动化测试用例、合规性报告和部署运行手册。

IaC 代理将生成的代码直接推送到您的代码仓库（例如 AWS CodeCommit、GitLab 或 Bitbucket）。从那里，它进入您现有的审查和部署管道，无需更改您现有的工具链。

迁移智能与治理代理：组合范围内的可见性

超过 300 个应用程序的迁移组合需要全天候的运营管理。手动进行状态报告、跟踪进度、执行后续操作以及验证 well-architected 对齐，会给项目经理和交付负责人带来巨大的开销。

迁移智能与治理代理通过跨组合的自动化、按需智能和治理解决了这个问题。它通过 AgentCore Gateway 聚合来自三个来源的数据。Jira 提供冲刺进度和障碍。Confluence 提供架构文档和运行手册。Webex 提供会议记录和行动项。

该代理提供跨已迁移工作负载的 well-architected 评估、合规性和治理验证，以及架构模式遵循度跟踪。

自动化操作包括使用最新迁移状态更新 Confluence 页面、为已识别的行动项创建 Jira 任务，以及为升级问题生成 ServiceNow 工单。这些操作在执行前需要明确的人工批准。这种基于批准门控的架构是整个代理套件的核心设计原则。代理支持而非取代人类决策。

基于内部项目跟踪数据，跨超过 300 个应用程序组合的按需报告取代了手动汇总。您的结果可能因组合规模 and 工具集成而异。

阶段 3：SRE 代理，用于主动的迁移后运维

SRE 代理代表了最后一个阶段：主动的迁移后运维。在应用程序在 AWS 上运行后，SRE 代理使团队从被动救火转变为主动改进。

该代理监控 Amazon CloudWatch 指标、应用程序性能数据和历史模式。它在问题影响生产之前发出警报。该代理还为常见故障模式发布自动化的修复运行手册，并推荐效率改进建议。

目标领域（需人工参与审批）包括数据库集群合理调整大小、性能调优、存储分层以及计算扩展和效率改进。

SRE Agent 完成迁移生命周期的收尾工作。应用部署到 AWS 后并非就此止步，而是会随着时间推移持续优化改进。

使用 AWS DMS 和 AWS Transform 进行数据迁移

在自定义 AI Agent 之外，两项 AWS 托管服务负责处理数据和应用程序现代化层。

DMS Schema Conversion 借助生成式 AI 减少了手动 schema 映射的工作量。它能转换基于规则的转换工具未完成的代码对象，例如存储过程、函数和触发器。此功能在部分 AWS 区域已正式可用，因此在波次规划期间请确认区域支持情况。随后，AWS DMS 通过自动化迁移任务缩短了切换窗口。该服务直接集成到 Agent 管道中。IaC Agent 负责预置目标基础设施，然后由 AWS DMS 迁移数据。

AWS Transform 负责处理基础设施直接迁移之外的应用程序级转换。它为遗留代码提供针对特定应用的现代化改造，实现真正的现代化而非仅仅迁移。

安全与合规：内嵌而非外挂

此架构从一开始就将安全内嵌其中，而非事后补救，并在迁移生命周期的每个阶段加以落实。整个 Agent 套件中的关键控制措施包括：

• 安全标准执行：IaC Agent 直接从 Confluence 获取企业安全部门的标准，并使用自定义 MCP 工具将其应用到生成的 IaC 中。
• Landing Zone 验证：框架在部署前根据企业的 landing zone 合规要求验证生成的基础设施。
• 人在环审批门禁：套件中所有 Agent 的自动化操作在执行前均需获得明确的人工审批。任何 Agent 都不会在生产系统上自主行动。
• AgentCore Gateway 协调：Amazon Bedrock AgentCore Gateway 协调各 Agent 之间的上下文和安全控制，在整个迁移生命周期中保持一致的策略应用。
• CI/CD 集成：框架将安全控制集成到 CI/CD 管道中，在生成 IaC 的同时生成自动化测试用例，以便在合规问题进入生产环境之前将其捕获。
• 推理层的负责任 AI 控制：Amazon Bedrock Guardrails 对每个提示词和每个模型响应应用内容过滤器、拒绝主题、敏感信息过滤器和上下文接地检查。Agent 仅对通过护栏的输出采取行动。护栏追踪信息与工具调用审计日志一同流入 AgentCore Observability。

此方法符合 AWS 共享责任模型。AWS 负责底层基础设施的安全性，而您负责云中的安全性。该框架自动化了您的配置责任，同时保留人工对审批决策的监督。

在此次实施中，该框架在超过 300 个应用程序的投资组合中维持了企业安全标准，其速度是手动流程无法比拟的。您的实际结果可能因安全要求和组织标准而异。

可量化的影响

在整个迁移项目中，该框架取得了以下成果。这些指标反映了此次特定实施的情况。您的实际结果可能因应用程序复杂性、团队规模和组织要求而异。

• IaC 开发时间从数周缩短至数分钟：从每个应用 3-4 周缩短至数分钟的自动生成（基于内部项目跟踪数据）。
• 各波次均应用模式一致性：任何波次都不能偏离已批准的 IaC 模式基线。
• 安全合规：每次部署时自动验证，完整的审计跟踪无需任何手动操作。
• 架构到部署的一致性提升：Agent 解读架构图，IaC 按设计意图将其实现。
• 按需生成超过 300 个应用程序的投资组合报告，指标精确，零手动汇总。
• 波次团队入职体验改善：团队上传文档，框架处理其余一切。

清理资源

• 从 AgentCore runtime 中删除 Agent，然后移除 Gateway 目标和 Gateway。
• 删除保存会话状态和共享上下文的 AgentCore 内存资源。
• 删除 Guardrail、AgentCore definitions 中的 Policy，以及为 Agent 创建的 IAM 角色。
• 如果不再需要历史记录，请删除 AgentCore Observability 写入的 CloudWatch 日志组。
• 删除为测试迁移预置的任何 AWS DMS 复制实例和端点。

在 Amazon Bedrock AgentCore 控制台中确认没有 Agent 会话仍处于活动状态。

结论

仅靠增加更多工程师并不能解决在紧迫时间表内将超过 300 个应用程序迁移到 AWS 的问题。这需要一种不同的方法——让 AI Agent 处理重复性、高工作量的任务，而人类专注于决策、审批和战略。

本文所述的多智能体框架如今已能带来可量化的成果。专建的Strands智能体针对特定瓶颈逐一突破，Amazon Bedrock AgentCore从架构层面落实安全机制，而人机协同的设计则确保自动化始终服务于决策，而非取代决策。

后续步骤

• 准备启动大规模迁移？建议先评估IaC智能体模式。基于本次实践，IaC开发时间从数周缩短至数分钟。请参阅Amazon Bedrock AgentCore，了解如何构建和部署智能体。
• 需要组合资产全景视图？可考虑使用迁移智能与治理智能体，自动生成状态报告和well-architected评估。进一步了解Amazon Bedrock AgentCore记忆功能，用于智能体状态管理。
• 迁移已完成？探索SRE智能体模式，从被动运维转向主动改进。使用Amazon CloudWatch进行监控和自动告警。
• 想构建自己的智能体？从Strands Agents SDK和Amazon Bedrock AgentCore入手，使用针对您迁移瓶颈定制的MCP服务器。打开Amazon Bedrock AgentCore控制台即可开始，或阅读《将Strands智能体部署到Amazon Bedrock AgentCore运行时》。

• Amazon Bedrock AgentCore：大规模安全部署和运营AI智能体。
• Strands Agents SDK：使用模型、提示词和工具构建AI智能体。
• AWS Database Migration Service (AWS DMS)：将数据库迁移至AWS。
• AWS Identity and Access Management (IAM)：管理对AWS服务的访问权限。
• Amazon CloudWatch：监控AWS资源和应用程序。
• Amazon Bedrock AgentCore文档：运行时、网关、记忆、身份与可观测性。

• 推出Amazon Bedrock AgentCore：任意规模下安全部署和运营AI智能体
• 推出Strands Agents，一个开源AI智能体SDK
• 借助AWS DMS Schema Conversion上的智能体AI加速数据库现代化

关于作者