AWS Professional Services 基于 Bedrock AgentCore 构建多 Agent 框架,自动化企业云迁移全流程——发现、IaC 生成、组合治理、迁移后运营,IaC 开发时间从数周缩短至分钟级。
大规模云迁移的症结在于识别哪些环节会出现瓶颈。每次应用发现需要消耗数周时间。工程师为每个工作负载从头编写基础设施代码。迁移后的运维沦为被动救火。如果将这些瓶颈乘以 300 多个应用和固定的财年截止日期,迁移项目就很难跟上进度。本文中的多智能体框架将每个应用的基础设施即代码(IaC)开发时间从 3–4 周缩短到几分钟,覆盖了 300 多个应用组合。这是基于内部项目跟踪数据得出的结果。
AWS Professional Services 构建了一套专用 AI 智能体来应对迁移生命周期各阶段的瓶颈,从自动化发现到主动式迁移后运维。这些智能体使用 Strands Agents SDK 并运行在 Amazon Bedrock AgentCore 上——这是一个用于大规模构建、连接和优化智能体的平台,支持任何框架或模型。
在本文中,你将探索一个多智能体编排框架的架构,它能够端到端加速企业云迁移。你还将看到定义智能体、连接工具和应用负责任 AI 控制措施的代码。该框架包含四个智能体:
** Intake Agent(受理智能体)**——用于自动化发现。
IaC Agent(基础设施即代码智能体)——生成符合你安全最佳实践的基础设施即代码。
Migration Intelligence and Governance Agent(迁移情报与治理智能体)——提供组合层面的报告和 Well-Architected 评估。
Site Reliability Engineering Agent(SRE 智能体)——用于主动运维。
要跟随本文进行实践,你需要拥有一个 AWS 账户,可访问 Amazon Bedrock AgentCore 和 Amazon Bedrock 基础模型(FM)。你还需要熟悉 Strands Agents SDK 和 Model Context Protocol(MCP)服务器模式,以及组织使用的 IaC 工具。
在大型企业数据中心退出迁移项目中,三个核心瓶颈反复出现。
手动受理开销:大多数应用迁移从发现开始:了解本地架构、资产清单、依赖关系和受理问卷。手动发现每个应用需要消耗数周时间。在 300 多个应用的情况下,仅此瓶颈就会威胁到激进的迁移时间表。
冗余的基础设施开发:当工程师定义目标架构时,他们会编写 IaC 来配置 AWS 基础设施。没有自动化的情况下,每个应用从头编写 IaC 通常需要 3–4 周。在 300 多个应用组合中,这相当于数年的工程工作量。
被动的迁移后运维:迁移后,团队依赖手动监控和被动响应。没有主动式情报来检测性能下降或自动修复问题,持续的运维负担会随时间累积。
这三个瓶颈贯穿整个迁移生命周期。解决它们需要将重复性工作转移到 AI 智能体,同时由人类保留决策权。
多智能体编排框架用专用智能体能力应对每个瓶颈。该架构跨越整个迁移生命周期,从本地发现到迁移后运维。该框架在生命周期的每个阶段都应用了安全措施。下图展示了这些智能体、工具和 AWS 服务如何连接。
图 1:智能体如何通过 Model Context Protocol 工具调用在迁移和运维旅程中连接
该框架将智能体组织成两条旅程。迁移旅程智能体处理从发现到部署的工作。运维旅程智能体处理迁移后的监控。
迁移旅程智能体:
运维旅程智能体:
AWS 托管服务补充了自定义智能体:
本节描述框架组件在运行时如何交互。
每个智能体都是一个 Strands 智能体,由基础模型、系统提示词和一组工具定义。Amazon Bedrock AgentCore 运行时将它们托管在具有会话隔离和多智能体编排的无服务器环境中。Amazon Bedrock 基础模型为解释文档、生成代码和驱动多步骤工作流提供了推理能力。关于 AWS 区域的基础模型可用性,请参阅 Amazon Bedrock 中支持的基础模型。
每个智能体通过 AgentCore Gateway 调用限定于其功能的 MCP 工具——AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项功能,可将你的 API、AWS Lambda 函数和现有服务转换为 MCP 兼容工具。AgentCore Identity 是 Amazon Bedrock AgentCore 的一项功能,通过限定范围的 AWS Identity and Access Management(IAM)角色和你的身份提供商对每次调用进行身份验证。
Amazon Bedrock AgentCore 内存存储智能体会话状态和共享上下文。智能体使用此共享上下文来持久化输出并跟踪 300 多个应用的迁移进度。当 Intake Agent 完成发现后,它将目标架构和依赖关系映射写入 AgentCore 内存。IaC Agent 读取此共享上下文以开始代码生成,无需手动交接。
以下 Python 示例定义了 IaC Agent 并为其准备 Amazon Bedrock AgentCore 运行时。该智能体通过 AgentCore Gateway 访问你的 MCP 工具,并通过附加了 Amazon Bedrock Guardrails 策略的 Amazon Bedrock 调用基础模型。
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 lets the SDK run the client_credentials grant and re-mint the
# token on expiry. A statically captured bearer token would go stale.
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 owns the connection lifecycle and paginates
# tool discovery, which list_tools_sync() alone does not.
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 运行时处理会话隔离和扩展。有关可部署的端到端示例,请参阅 Amazon Bedrock AgentCore 示例仓库和 GitHub 上的 Strands Agents 示例仓库。关于部署步骤,请参阅 AgentCore 运行时入门。
Intake Agent 将迁移中最耗时的第一步自动化:了解本地存在什么,以及定义它应该迁移到 AWS 的哪个位置。
智能体摄入本地架构文档、应用清单列表、 intake 问卷和依赖关系图。然后生成目标 AWS 架构,并提供推荐的迁移模式、资源规模规格和合规性验证报告。
Intake 智能体解决了手动 intake 的瓶颈问题。其输出直接馈送到 IaC 智能体,实现了从发现到基础设施置备的自动化交接。
AWS Professional Services 在整个智能体组合中首先部署了 IaC 智能体,它产生了最直接可衡量的影响。它生成的 IaC 代码符合你的安全最佳实践和标准。
智能体工作流分五个步骤进行:
Step 1:摄入 steering 文档。 智能体读取 wave 团队的 steering 文档。它提取部署范围、合规性约束以及安全办公室批准的具体 wave 覆盖项。
Step 2:解读目标状态架构图。 IaC 智能体使用 Intake 智能体的输出,识别基础设施组件及其关系和依赖关系。
Step 3:生成 IaC。 基于此解读,智能体使用你定义和建立的模式生成 IaC。它使用特定 wave 的参数填充配置,并配置远程状态管理。然后应用强制标签,并添加组织标准要求的监控配置。
Step 4:通过 Amazon Bedrock AgentCore 中的 Policy 进行验证。 在执行之前,AgentCore 中的 Policy 根据 Cedar 规则评估每个工具调用。它计算潜在变更的范围,检查与并发 wave 的依赖冲突,并确认合规性窗口的有效性。
Step 5:执行和报告。 集中式执行平面触发 IaC,监控部署,并通过 Amazon Bedrock AgentCore 的一项能力 AgentCore Observability 报告结果。部署后验证自动运行,合规性指标实时更新。
自定义 MCP 工具:安全基础
每个操作都通过 Amazon Bedrock AgentCore Gateway 公开的自定义 MCP 工具传递,并由 AgentCore Identity 和 Policy in AgentCore 管理。AgentCore Identity 通过具有最小权限访问范围 scoped IAM 角色对每个智能体操作进行身份验证。该框架根据定义的 schema 验证输入,并在边界处拒绝格式错误的输入。
没有凭据或敏感值通过智能体上下文传递,因为 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) 布局以及强制标签。
这种方法在各个 wave 之间提供一致性,为不从头编写基础设施代码的 wave 团队提供速度,并通过安全更新在下一个部署周期传播给消费者来实现治理。
智能体为每个应用生成 IaC 代码、自动化测试用例、合规性报告和部署手册。
IaC 智能体将生成的代码直接推送到你的代码仓库(如 AWS CodeCommit、GitLab 或 Bitbucket)。从那里,它进入你现有的审查和部署管道,无需更改你现有的工具链。
Migration Intelligence and Governance 智能体:整个产品组合级别的可见性
超过 300 个应用的迁移产品组合需要全职运营管理。状态报告、进度跟踪、执行后续操作以及手动验证 Well-Architected 对齐,为项目经理和交付负责人创造了大量开销。
Migration Intelligence and Governance 智能体通过整个产品组合的自动化按需智能和治理解决这一问题。它通过 AgentCore Gateway 从三个来源聚合数据。Jira 提供 Sprint 进度和障碍。Confluence 提供架构文档和手册。Webex 提供会议记录和操作项。
智能体提供跨已迁移工作负载的 Well-Architected 评估、合规性和治理验证,以及架构模式 adherence 跟踪。
自动化操作包括使用最新迁移状态更新 Confluence 页面、为已识别的操作项创建 Jira 任务,以及为升级生成 ServiceNow 工单。这些操作需要在执行前获得明确的人类批准。这种审批门控架构是整个智能体套件的核心设计原则。智能体支持人类决策而非取代人类决策。
跨超过 300 个应用产品组合的按需报告取代了手动聚合,基于内部项目跟踪数据。你的结果可能因产品组合规模和工具集成而异。
Phase 3:SRE 智能体实现主动式迁移后运营
SRE 智能体代表最后阶段:主动式迁移后运营。应用在 AWS 上运行后,SRE 智能体将团队从被动救火转变为主动改进。
智能体监控 Amazon CloudWatch 指标、应用性能数据和历史模式。它在问题影响生产环境之前发出告警。智能体还为常见故障模式发布自动化修复手册,并推荐效率改进。
目标领域(需人工参与批准)包括数据库集群 right-sizing、性能调优、存储分层以及计算扩展和效率改进。
SRE 智能体完成了迁移生命周期。应用不会在部署到 AWS 后就此停止。它们会随着时间不断改进。
使用 AWS DMS 和 AWS Transform 进行数据迁移
除了自定义 AI 智能体外,两个 AWS 托管服务处理数据和应用程序现代化层。
带有生成式 AI 的 DMS Schema Conversion 减少了手动 schema 映射工作。它转换基于规则的转换无法完成的代码对象,如存储过程、函数和触发器。此功能在部分 AWS 区域普遍可用,因此请在 wave 规划期间确认区域支持。然后 AWS DMS 通过自动化迁移任务缩短切换窗口。该服务直接集成到智能体管道中。IaC 智能体置备目标基础设施,然后 AWS DMS 迁移数据。
AWS Transform 处理超出基础设施直接迁移的应用程序级转换。它为遗留代码提供特定于应用程序的现代化,提供真正的现代化而非单纯的迁移。
安全与合规:嵌入式而非附加式
此架构从一开始就嵌入安全,而非事后考虑,在迁移生命周期的每个阶段应用安全。整个智能体套件的关键控制:
安全标准执行: IaC 智能体直接从 Confluence 提取企业安全办公室标准,并使用自定义 MCP 工具将其应用于生成的 IaC。
着陆区验证: 该框架在部署前根据企业的着陆区合规性要求验证生成的基础设施。
人工批准门控: 套件中所有智能体的自动化操作在执行前需要明确的人类批准。没有智能体在生产系统上自主行动。
AgentCore Gateway 协调: Amazon Bedrock AgentCore Gateway 跨智能体协调上下文和安全控制,在整个迁移生命周期中保持一致的政策应用。
持续集成和持续交付 (CI/CD) 集成: 该框架将安全控制集成到 CI/CD 管道中,与 IaC 一起生成自动化测试用例,以在问题进入生产环境之前发现合规性问题。
推理层的 Responsible AI 控制: Amazon Bedrock Guardrails 为每个提示和每个模型响应应用内容过滤器、拒绝的主题、敏感信息过滤器和上下文基础检查。智能体仅对通过护栏的输出采取行动。护栏跟踪与工具调用审计跟踪一起流入 AgentCore Observability。
此方法符合 AWS 共同责任模型。AWS 提供底层基础设施的安全,而你负责云中的安全。智能体自动化你的配置责任,同时保持人类对批准决策的监督。
在这个实现中,该框架在整个超过 300 个应用的组合中维护了企业级安全标准,速度是手动流程无法企及的。根据你的安全要求和组织标准,结果可能会有所不同。
在整个迁移计划中,该框架取得了以下成果。这些指标反映了本次特定实现的结果。根据应用复杂度、团队规模和组织要求的不同,你的实际结果可能会有所差异。
为避免测试完成后产生持续费用,请删除你创建的资源:
仅靠增加工程师并不能解决在激进时间线上将 300 多个应用迁移至 AWS 的问题。它需要一种不同的方法——让 AI 智能体处理重复性、高工作量的事务,而人类专注于决策、审批和战略。
本文描述的多智能体框架如今已能交付可衡量的成果。专门构建的 Strands AI 智能体解决特定瓶颈,Amazon Bedrock AgentCore 在结构层面应用安全措施,而人在循环(human-in-the-loop)设计确保自动化支持而非取代决策。
根据你的使用场景,考虑以下路径:
启动大规模迁移? 首先评估 IaC AI 智能体模式。根据本次实现,IaC 开发时间从数周缩短至数分钟。参阅 Amazon Bedrock AgentCore 了解如何构建和部署 AI 智能体。
需要组合可见性? 考虑使用 Migration Intelligence and Governance AI 智能体自动生成状态报告和架构完善评估。了解更多关于 Amazon Bedrock AgentCore memory 实现 AI 智能体状态管理。
迁移后? 探索 SRE AI 智能体模式,从被动运营转向主动改进。使用 Amazon CloudWatch 进行监控和自动告警。
构建你自己的 AI 智能体? 从 Strands Agents SDK 和 Amazon Bedrock AgentCore 开始,使用针对你迁移瓶颈定制的 MCP 服务器。打开 Amazon Bedrock AgentCore 控制台开始使用,参阅 Deploying Strands Agents to Amazon Bedrock AgentCore runtime。
探索本文使用的服务:
关于本文使用的服务和 SDK 的背景知识,请参阅以下 AWS 文章: