让 Amazon Quick 具备企业级能力：自动化、可审计的跨账户资源晋升

Amazon Quick 是亚马逊专为工作构建的智能体式 AI 伴侣。您可以构建能够对您的数据进行推理、调用操作连接器并完成多步骤任务的智能体。将这些资源(聊天智能体、操作连接器、知识库、流程和空间)从开发 AWS 账户提升到生产 AWS 账户——就像处理其他任何应用程序那样——一直是一项手动且容易出错的工作。本文介绍如何通过 Amazon Bedrock AgentCore 上一个幂等、可审计的 Model Context Protocol (MCP) 服务器来实现自动化。

代理式解决方案的构建模块是它的 代理、操作连接器、知识库和空间：配置了自定义指令的聊天代理、Slack、Jira 及其他集成的连接器、以您自己的文档为基础的知识库，以及将它们整合在一起的 Space。团队可以在开发账户中快速组装并迭代这些内容。

大多数企业为开发环境和生产环境运行独立的AWS账户，有时中间还设有质量保证（QA）环境。当智能体（agent）、操作连接器和知识库在开发账户中完成验证后，并没有原生的、一键式的方式将它们提升到下一个账户。团队不得不手工重建每一项资源：使用相同的指令和起始提示词重新创建每个智能体，重新挂载每个智能体的操作连接器，重新授予资源权限，并重新预置每个知识库背后的Amazon Simple Storage Service（Amazon S3）存储桶、存储桶策略和数据源。这项工作缓慢、难以审计，且很容易出现细微错误，从而削弱了企业所需的治理能力。

通过 API 管理 Amazon Quick 资源

Amazon Quick 资源是可编程的。空间、代理、操作连接器、知识库和流通过 Amazon Quick API（属于 Amazon Quick Sight API 接口")，它提供了完整的资源生命周期：创建、读取、更新、删除和列出。业务用户在 Amazon Quick 中配置的任何内容——带有其指令和起始提示词的智能体、连接器、知识库或流程——我们都可以以编程方式进行检查、重新创建、更新和管理，包括权限。

这个可编程的接口正是实现受管控晋升的关键。我们无需手动重建每个资源，而是通过 API 读取资源及其权限，并将它们在另一个账户中原样重新应用。本文中的迁移器将 create、read、update 和 list 操作组合成一个可重复的工作流，并且它从不对目标执行 delete 操作，因此每次运行只会添加或更新。

在本文中，我们将介绍 Quick Resource Migrator，这是一个托管在 Amazon Bedrock AgentCore runtime（Amazon Bedrock AgentCore 的一项功能）上的示例 MCP 服务器，它可以通过单次工具调用自动完成 Amazon Quick 资源的跨账户提升。它是资源驱动的：你可以选择一种资源类型（agent、connector、知识库、flow 或 space），然后按 id、按名称或全选。它是幂等的（可以安全地重复运行），并且它通过描述源环境并在目标环境中重放相同的操作来忠实复制权限。完整的源代码可在 aws-samples 仓库.

解决方案概述

该迁移工具通过单次调用推广一组选定的资源。它是一种 upsert 操作:目标中尚不存在的资源会被创建,已存在的资源则被就地更新。每次更新都有带版本号的备份保护,该备份在变更之前写入 Amazon S3,因此每个资源都保留完整的历史记录,可供查看和回滚。在提交之前,只读预览会准确报告一次运行将创建或更新的内容,而迁移本身在 Amazon Bedrock AgentCore 上运行,因此可以从 Amazon Quick 或任何兼容 MCP 的客户端驱动。

迁移哪些内容

1. 选择模型: 选择一种资源类型(agent、connector、knowledge base、flow 或 space),然后按 id、按名称或全部选择资源。选择以资源为驱动。可以直接迁移某种资源类型,也可以迁移一个 space,将其关联的资源一并带走。
2. Chat agents: 以自定义指令、身份、语气、启动提示和欢迎消息重新创建,并重新附加其 action connectors(重新映射到目标账户)。当迁移一个 space 时,其 agent 会自动重新关联到该 space。
3. Action connectors: 以其配置重新创建。密钥值绝不会从源端读取。connector 以占位符凭据创建,并在目标中重新进行身份验证。
4. Knowledge bases: knowledge base 在目标账户中注册,其数据源被重新创建,其权限被复制。对于基于 S3 的 knowledge base,迁移工具还会提供目标存储桶及其存储桶策略(这是迁移的一个独立输出)。文档(S3 对象)本身不会被复制。
5. Flows: 根据其定义在目标账户中重新创建。由于 flow ID 在不同账户之间不同,flow 按名称匹配:如果存在同名目标 flow 则更新它,否则创建新 flow。flow 权限会被复制。
6. 空间： 在目标账户中重新创建并重新链接到其代理、连接器和知识库（资源 Amazon 资源名称（ARN）被重新映射到目标）。请先迁移被链接的资源，以便目标 ARN 能够解析。空间权限会被复制。

关键设计原则

1. 以资源为驱动的选择。 您每次迁移一种资源类型（代理、连接器、知识库、流或空间），可以按 id、按名称选择，或全部选择。代理在重新创建时会重新附加其操作连接器。空间被重新创建并重新链接到其代理、连接器和知识库，ARN 被重新映射到目标账户。
2. 权限保真。 权限不是硬编码的。服务器会调用每个源资源的相应 Describe*Permissions API，并在目标中重放完全相同的操作列表，将主体重新映射到目标账户中已注册的用户。
3. 幂等性。 每个资源都是创建或更新。服务器先描述目标资源，再决定是创建还是更新，因此重复运行迁移会收敛到相同状态，而不会产生重复资源或失败。
4. 最小权限与隔离。 源角色是只读的。目标角色只拥有迁移所需的操作。运行时使用 Cognito JSON Web Token（JWT）对调用者进行身份验证，并可以在虚拟私有云（VPC）网络模式下运行。
5. 安全、可回滚的更新。 在迁移器更新任何现有目标资源之前，它会将该资源及其依赖项的带版本快照写入专用的备份存储桶。如果无法写入该备份，更新将被中止。每个创建或更新的资源也会被快照，还原工具可以将任何资源回滚到较早的版本。

架构

该解决方案采用三账户模型。一个中央运行器账户在 Amazon Bedrock AgentCore runtime 上托管 MCP 服务器。服务器使用 AWS Security Token Service（AWS STS）承担源账户中的只读角色和目标账户中的读写角色，因此任何地方都不存储长期凭证。

图 1：Amazon Quick Resource Migrator MCP 服务器的架构

组件职责

表 1：架构组件

迁移流程

1. 解析资源：根据资源类型和选择器（id、name 或 all），在源账户中解析出具体的资源 ID。
2. 描述源资源：describe 每个选定的资源，以捕获其配置和权限。
3. 连接器：重新创建每个连接器。认证配置会被清理为 create（write）模型并使用占位密钥，然后在目标账户中重新认证。复制权限。
4. 知识库：创建目标存储桶（knowledge-base-<env>-<account>）、存储桶策略、数据源和知识库，然后复制知识库权限。S3 对象不会被复制。
5. 代理：重新创建每个代理及其附加的操作连接器（重新映射到目标账户），然后复制代理权限。当空间本身被迁移时，代理与空间的关联会被恢复（参见空间步骤）。
6. 流（Flow）：按名称匹配，从其定义重新创建每个流（流 ID 在不同账户之间不同）：更新同名目标流或创建新流，然后复制流权限。
7. 空间（Space）：重新创建每个空间，并将其代理、连接器和知识库重新关联，ARN 重新映射到目标账户（先迁移这些资源），然后复制空间权限。
8. 报告：返回一份 JSON 报告，列出已创建或更新的资源、存储桶、备份、被跳过的权限以及任何错误。

MCP 服务器公开的工具

该服务器公开五个工具，全部定义于 server.py.

preview_migration（只读）

preview_migration 接受一个源账户 ID、一个资源类型（agent、connector、knowledge base、flow、space 或 all）、一个选择器（id、name 或 all）以及一个 AWS 区域。它返回将被迁移的代理、操作连接器、知识库和流的清单，包含名称和类型，且不进行任何更改。可将其作为试运行，用于确认范围，并在提升之前支持变更管理审批步骤。当你同时传入目标账户 ID 时，响应还会添加一个源到目标的映射，将每个资源标记为 CREATE 或 UPDATE，因此你可以在运行迁移之前确切看到迁移将做出的更改。

migrate_resources（完整迁移）

migrate_resources 接受源账户和目标账户 ID、一个资源类型（agent、connector、knowledge base、flow 或 space）、一个选择器（id、name 或 all）、一个区域、源和目标环境名称（用于知识库存储桶名称）以及 Quick Sight 服务角色名称。它执行上述完整的创建或更新迁移，并返回一份结构化报告，列出其创建、更新和授权的所有内容以及任何错误。由于它是幂等的，你可以反复运行它，例如在每次发布时运行，它都会收敛到相同的目标状态。

list_backups（只读）

list_backups 搜索备份目录并列出每个资产的可用版本。备份是迁移器写入备份存储桶的更新前快照，每次更新生成一个带版本的对象，因此你可以查看任何已迁移资源的完整历史。

get_backup（只读）

get_backup 返回给定资产和版本的完整存储备份（默认为最新版本），包括捕获的资源配置及其依赖项。

restore_backup

restore_backup 将存储的备份版本重新应用到目标资源，就地更新它，或在它不再存在时重新创建它。它首先会进行一次新的恢复前备份，因此该回滚本身也是可撤销的。

部署该解决方案

完整的源代码和分步部署说明位于 aws-samples 仓库 的 README 中。大致而言，你需要部署三个 AWS CloudFormation 堆栈，即跨账户 AWS Identity and Access Management (IAM) 角色、VPC 网络以及托管 MCP 服务器的经 Cognito 认证的 AgentCore 运行时，然后将该运行时注册为 Amazon Quick 中的操作连接器。

通过 Quick App 使用迁移器

通过将运行时注册为操作连接器，你可以用自然语言从 Amazon Quick 驱动迁移器，还可以构建一个 Quick App：一个构建在相同 MCP 工具之上的点击式网页体验。你无需手动构建该 UI。该仓库包含一个开箱即用的 app-builder 提示词 ，你可以将其粘贴到 Amazon Quick 应用构建器中，将占位符连接器和操作 ID 替换为你自己的 ID 以生成应用。该应用将工作流程转变为引导式流程：选择源账户和目标账户以及要提升的资源，预览将要创建或更新的内容，运行迁移，并查看每次历史迁移的记录，每次迁移均由服务器写入的带版本 S3 快照提供支持。以下屏幕展示了该体验。

一个 Quick App 示例

1. 由于应用是从提示词生成的，每次构建都各不相同。以下屏幕展示了其中一个示例。在该示例中，着陆页提示输入源账户 ID、目标账户 ID、资源类型（agent、connector、knowledge base、flow 或 space）和选择器（id、name 或 all），并可按需提供其他选项。

图 3：着陆页上提供的其他迁移选项

1. 选择 Confirm & migrate后，你会看到类似以下的响应：

图 4：选择 Confirm and migrate 后的确认响应

1. 确认并迁移后，你应该会看到 MCP 服务器返回的响应，其中列出了已创建/更新的资源。

图 5：MCP 服务器响应，列出了已创建或更新的资源

1. 打开 History 标签页可查看每一次历史迁移。每条记录都由迁移器写入 Amazon S3 的带版本快照作为支撑，因此你可以获得关于何时晋升了什么内容的完整、可审计的记录，并且可以选择检查任何早期版本。

图6：History 标签页显示过去迁移的可审计记录

1. 要执行回滚，请选择某个资源的备份版本并选择 Restore。该应用会将保存的版本重新应用到目标。由于它在恢复之前会先捕获一份新的备份，因此此次还原操作本身也是可逆的。

图7：将资源回滚到较早的备份版本

结论

跨账户推广是企业软件的基本要求,而在此之前它一直是 Amazon Quick 缺失的一环。Quick Resource Migrator 将一个缓慢、手动、难以审计的任务转变为快速、可重复且受治理的任务:只需一次工具调用即可在目标账户中重建代理、连接器和知识库,并忠实复制权限,而且整个过程是幂等的,因此你可以在每次发布时运行它。

克隆 示例存储库,将其部署到运行器账户中,并尝试将一个代理或知识库从开发环境推广到生产环境。然后根据你自己的治理和加固要求调整该模式。

关于作者