AWS Machine Learning Blog的一篇文章题为《Scaling cloud migrations with agentic AI on Amazon Bedrock AgentCore》，介绍了一个涉及超过300个应用的迁移项目。文章把工作分给四类智能体：Intake Agent、IaC Agent、Migration Intelligence and Governance Agent，以及SRE Agent。读者可以沿着信息在这些角色之间传递的顺序，理解文章所描述的实施方式。这里的项目规模、工作流程和时间结果，都是AWS对这一具体实施的陈述。

从应用资料形成目标架构

文章称，Intake Agent通过MCP工具读取架构文档、调查问卷和依赖关系记录，并据此产出目标AWS架构。这个步骤的重点，是把有关应用现状与应用之间关系的资料纳入同一项准备工作。架构文档提供架构方面的输入，问卷提供另一类输入，依赖记录则让后续工作能够看到已记录的关联。文章并没有把目标架构写成凭空生成的结果，而是明确列出了供这个智能体读取的材料。

在超过300个应用的项目背景下，这一步还说明了文章为何单独设置一个负责接收材料的角色。每个应用都需要先有可供后续使用的目标架构；依赖关系也不能在交接时消失。文章所给出的流程，是先处理这些输入，再把输出交给负责基础设施代码的角色。这样理解有助于区分“取得应用资料”“形成目标架构”和“编写基础设施代码”三个连续环节，而不把它们混成一项笼统的自动化任务。

具体的交接由AgentCore memory中的共享上下文承担。按文章描述，IaC Agent可以从中读取Intake Agent形成的目标架构和依赖关系映射。这意味着前一个角色的输出，是后一个角色可用的输入。共享上下文在这里的作用，是保留架构与依赖信息之间的联系，使代码生成环节能够依据前面已经整理的结果继续工作。文章用这一安排解释了两个智能体之间如何衔接，但没有把所有迁移工作都归入这次信息交接。

基础设施代码如何进入流程

IaC Agent负责生成基础设施代码。AWS说明，它使用获批的内部模块和组织模式。因此，文章中的代码生成不是一个脱离组织既有模块与模式的独立动作；它与目标架构、依赖关系映射以及获批的生成材料相连。对于阅读项目成果的人来说，这一点限定了“自动生成”所指的工作：这里讨论的是基础设施代码的开发环节，而不是以一个数字概括迁移应用所涉及的每一项工作。

文章还写明，IaC Agent的工具调用在执行之前，要由AgentCore Policy按照Cedar规则进行评估。这个步骤位于执行之前，属于所述实施流程的一部分。把前后的环节连起来看，流程先从应用资料得到架构和依赖映射，再让代码智能体读取共享上下文、使用获批的模块与模式，随后对其工具调用进行规则评估。对读者而言，这些具体安排比单独看到“智能体生成代码”更能说明AWS描述的实际工作顺序。

文章称，这些智能体使用Strands Agents SDK，运行在Amazon Bedrock AgentCore上，并通过AgentCore Gateway暴露的MCP工具访问来源和目标位置。这个技术组合说明了文章所述的智能体如何运行以及如何连接所需的对象。在入站环节，MCP工具用于读取相关资料；在整体描述中，Gateway提供了这些工具的入口。上述细节应与四个角色的任务一起阅读，因为文章讨论的是一组相互衔接的智能体，而不是只讨论单一的代码生成动作。

治理信息与人工批准

Migration Intelligence and Governance Agent汇集来自Jira、Confluence和Webex的信息。文章同时规定了一个明确的执行条件：所述自动更新和创建工单的动作，必须先得到人工批准，才能执行。因而，信息汇集与改变相关记录是两个需要分别理解的环节。智能体可以在治理工作中整合这些来源的信息；至于文章提到的更新与工单创建，执行前还存在人的批准步骤。

这一条件影响对“自动化迁移治理”的理解。文章没有仅仅罗列智能体能够接触哪些系统，还说明了相关动作如何进入执行阶段。读者若只记住来自三个系统的信息被汇集，便会遗漏人工批准；若只看到人工批准，也会忽略智能体先行汇集信息的工作。把两者放在同一条流程中，才能准确复述AWS对治理角色的描述。批准要求限于文章具体提到的自动更新和工单创建，不能由此替文章补写其他动作的规则。

切换之后仍有一个角色

文章把SRE Agent放在应用切换之后的阶段，描述其监测CloudWatch指标、应用性能数据和历史模式。这使四个角色的分工延伸到切换后的运行观察：Intake Agent处理输入与目标架构，IaC Agent处理基础设施代码，治理智能体汇集项目信息并在所述动作执行前保留人工批准，SRE Agent则关注切换后的数据。这里的“监测”是文章对SRE Agent的描述；文章所给出的事实并不需要附加关于自动修复或其他操作结果的推断。

AWS还把这些定制智能体放在其他迁移工具的旁边讨论：AWS Transform用于迁移和现代化工作，AWS DMS用于数据库迁移。这样的定位有助于读者把四个智能体放回文章的项目范围内。它们分别承担文章列出的接收资料、生成代码、治理信息和切换后观察等任务；文章同时提及迁移与现代化以及数据库迁移相关的其他AWS服务。因此，这篇文章并不是只给四个智能体列出名称，而是说明它们与所述迁移工作的哪些环节相接。

如何理解时间结果

对于这一具体实施，AWS报告称，每个应用的基础设施代码开发时间从3至4周，降为数分钟的自动生成。文章说明，比较依据是内部项目跟踪数据。这个结果应保持原有的范围：它说的是所述项目中IaC开发环节的时间变化，而且数据来源是项目内部跟踪。文章没有把该比较写成所有应用迁移项目都能达到的统一时间，也没有用它衡量从读取材料到切换后监测的全部工作。

这个范围之所以重要，是因为同一篇文章还描述了代码生成之外的多个步骤。先要读取架构文档、问卷和依赖记录，形成目标架构及依赖映射；这些结果通过共享上下文供IaC Agent使用；工具调用在执行前接受规则评估。与此同时，治理角色处理来自三个工作系统的信息，而所述更新与工单创建需经人工批准；应用切换后还有监测工作。将“数分钟”放回这条链条，读者就能明白它指向基础设施代码的自动生成，而非宣称整条迁移链都在数分钟内完成。

文章最有用的线索，是各角色之间清楚的信息流。输入资料先变成目标架构；共享上下文让后续角色取得架构与依赖映射；获批模块、组织模式和执行前的规则评估限定了代码环节的做法；治理角色把分散的信息汇集起来，并让指定动作经过人工批准；切换后由SRE Agent观察相关指标与数据。对一个覆盖超过300个应用的项目，AWS用这条流程说明了四类智能体如何分工。至于所报告的效率变化，应继续以该具体实施和内部跟踪数据为边界来理解。