# 全面的注册表迁移指南
* AWS 代理注册表-从公共预览版迁移到正式版*
## 简介
作为2026年8月6日正式发布（GA）的一部分， AWS 代理注册局将对服务主体、数据和API模型进行重大更改。如果您在公开预览版期间使用了 AWS Agent Registry，则必须完成跨越三个区域的迁移：
1. **命名空间和配置更改** — 我们正在将 AWS Agent Registry 从 B AWS edrock AgentCore 命名空间移至其自己的专用命名空间。此命名空间更改仅适用于 AWS 代理注册表。所有其他 AgentCore 产品（例如身份、网关、运行时和策略）不受影响。对于 AWS Agent Registry，服务命名空间从变`bedrock-agentcore`为`agent-registry`。这会影响引用该服务的每个表面：终端节点、IAM 策略、SDK 客户端、CLI 命令、资源 ARN 和可观察性集成。您必须更新代码和基础架构才能使用新的命名空间。
1. **API 架构更改** — 注册表和注册表记录数据模型根据公开预览期间的客户反馈进行更新。这些更改破坏了与现有 API 架构的向后兼容性。作为迁移到新命名空间的一部分，必须更新构造或解析 API 请求和响应的应用程序代码以反映新的架构。
1. **数据迁移**-您必须将现有的注册表和注册表记录从旧命名空间迁移到新命名空间。我们提供迁移工具来提取您的数据，将其转换为新架构，然后将其加载到新的命名空间中。数据会迁移到同一个账户和区域，只有命名空间会发生变化。
本指南详细介绍了每个领域，并提供了前后示例，以帮助您规划和执行迁移。
## 迁移时间表是什么？
对于此次迁移，您必须记住两个重要的里程碑：
+ **2026 年 8 月 6 日** — AWS 代理注册表正式发布，新的`agent-registry`命名空间正式启动。如果您有现有的注册表和记录，则可以同时访问`bedrock-agentcore`和`agent-registry`命名空间。迁移工具在 [agentcore-samples 存储库 GitHub ](https://github.com/awslabs/agentcore-samples)中可用。您可以开始迁移过程。
**注意**
如果您是截至 2026 年 8 月 6 日没有现有注册表或记录的新客户，则无法通过命名空间访问 AWS 代理注册表。`bedrock-agentcore`直接从`agent-registry`命名空间开始使用 AWS 代理注册表。
+ **2026 年 9 月 17 日** — 迁移窗口关闭。旧的`bedrock-agentcore`命名空间将在此日期关闭。您将无法 read/write 访问该服务以及旧命名空间中的任何剩余数据。在此日期之后，您必须使用`agent-registry`命名空间。
## 命名空间和配置更改
`agent-registry`命名空间`bedrock-agentcore`将在以下位置替换。本节列出了所有变化的表面，并提供了如何更新代码的示例。
**重要**
命名空间的更改仅影响 AWS Agent Registry 提供的 API，而不影响 B AWS edrock 的其余部分 AgentCore，例如 AWS AgentCore 身份。因此，工作负载身份和 OAuth 凭证提供者资源仍位于命名空间下。`bedrock-agentcore`
### 服务端点
您的应用程序必须指向新的终端节点主机名。新的终端节点使用该`.api.aws`域。
| Surface | 旧值 | 新值 |
| --- | --- | --- |
| 数据平面端点 | `bedrock-agentcore.{region}.amazonaws.com` | `agent-registry.{region}.api.aws` |
| 控制面板端点 | `bedrock-agentcore-control.{region}.amazonaws.com` | `agent-registry-control.{region}.api.aws` |
### IAM 和安全
`bedrock-agentcore`必须更新引用的所有 IAM 策略、服务控制策略 (SCP) 和权限边界。资源 ARN 也会发生变化以反映新的命名空间。
| Surface | 旧值 | 新值 |
| --- | --- | --- |
| IAM 操作前缀 | `bedrock-agentcore:*` | `agent-registry:*` |
| 服务主体 | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` |
| 注册机构 ARN | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}` |
| 记录 ARN | `arn:aws:bedrock-agentcore:{region}:{account}:registry/{id}/record/{rid}` | `arn:aws:agent-registry:{region}:{account}:registry/{id}/record/{rid}` |
如果您的自动化功能可以解析或存储 ARN，请同时更新这些引用。必须更新带有 IAM 操作前缀或服务委托人条件的自定义策略以匹配新值。要查看与 AWS 代理注册表关联的 IAM 权限的完整列表，请参阅[AWS 代理注册表 IAM 权限参考](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-iam-permissions.html)。
**注意**
如果您当前使用[BedrockAgentCoreFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/BedrockAgentCoreFullAccess.html) AWS 托管策略访问 AWS 代理注册表（请参阅[BedrockAgentCoreFullAccess 策略详细信息](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security-iam-awsmanpol.html#security-iam-awsmanpol-BedrockAgentCoreFullAccess)），则必须将其替换为新的**AgentRegistryFullAccess**托管策略（在 GA 上可用）。旧的 BedrockAgentCoreFullAccess 托管策略**不会**更新为包含`agent-registry:*`权限。
### 软件开发工具包、CLI 和基础架构
更新您的应用程序代码、部署脚本和基础设施即代码模板以引用新的客户端类和 CLI 命名空间。
| Surface | 旧值 | 新值 |
| --- | --- | --- |
| Dataplane SDK 客户端类 | `BedrockAgentCoreClient` | `AgentRegistryClient` |
| 控制平面 SDK 客户端类 | `BedrockAgentCoreControlClient` | `AgentRegistryControlClient` |
| CLI 命名空间 | `aws bedrock-agentcore` | `aws agent-registry` |
| Service Quotas 代码 | `bedrock-agentcore` | `agent-registry` |
如果您之前在服务代码下请求增加自定义配额，则必须根据`bedrock-agentcore``agent-registry`服务代码重新申请。
### 可观察性和事件
更新引用旧命名空间的所有 La CloudTrail ke 查询、Athena 查询、SIEM 集成 EventBridge CloudWatch 、规则、仪表板和警报。
| Surface | 旧值 | 新值 |
| --- | --- | --- |
| CloudTrail 事件源 | `bedrock-agentcore.amazonaws.com` | `agent-registry.amazonaws.com` |
| EventBridge 来源 | `aws.bedrock-agentcore` | `aws.agent-registry` |
| CloudWatch 命名空间 | `AWS/BedrockAgentCore` | `AWS/AgentRegistry` |
### 示例：更新 IAM 策略
替换所有 IAM 策略中的操作前缀和资源 ARN 命名空间。
**之前（公开预览）：**
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"bedrock-agentcore:CreateRegistry",
"bedrock-agentcore:GetRegistry",
"bedrock-agentcore:UpdateRegistry",
"bedrock-agentcore:ListRegistries",
"bedrock-agentcore:DeleteRegistry",
"bedrock-agentcore:CreateRegistryRecord",
"bedrock-agentcore:GetRegistryRecord",
"bedrock-agentcore:UpdateRegistryRecord",
"bedrock-agentcore:ListRegistryRecords",
"bedrock-agentcore:DeleteRegistryRecord",
"bedrock-agentcore:SubmitRegistryRecordForApproval",
"bedrock-agentcore:UpdateRegistryRecordStatus",
"bedrock-agentcore:SearchRegistryRecords"
],
"Resource": ["arn:aws:bedrock-agentcore:us-west-2:123456789012:*"]
}]
}
```
**之后（正式上市）：**
```
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"agent-registry:CreateRegistry",
"agent-registry:GetRegistry",
"agent-registry:UpdateRegistry",
"agent-registry:ListRegistries",
"agent-registry:DeleteRegistry",
"agent-registry:CreateRegistryRecord",
"agent-registry:GetRegistryRecord",
"agent-registry:UpdateRegistryRecord",
"agent-registry:ListRegistryRecords",
"agent-registry:DeleteRegistryRecord",
"agent-registry:SubmitRegistryRecordForApproval",
"agent-registry:UpdateRegistryRecordStatus",
"agent-registry:SearchDiscoverableRegistryRecords",
"agent-registry:ListDiscoverableRegistryRecords",
"agent-registry:GetDiscoverableRegistryRecord"
],
"Resource": ["arn:aws:agent-registry:us-west-2:123456789012:*"]
}]
}
```
**注意**
`BatchGetDiscoverableRegistryRecord`API 没有自己的 IAM 操作。它授权每条请求的记录针对该`agent-registry:GetDiscoverableRegistryRecord`操作。确保您的保单包括`GetDiscoverableRegistryRecord`使用`BatchGet`。
**重要**
工作负载身份和 OAuth 凭证提供者资源仍位于命名空间下。`bedrock-agentcore`如果您的注册管理机构使用带有 OAuth 或 IAM 凭证的 URL sync (`source.fromUrl`)，则除了新权限外，您还必须保留以下权限：`agent-registry:*`
```
"bedrock-agentcore:CreateWorkloadIdentity",
"bedrock-agentcore:GetWorkloadIdentity",
"bedrock-agentcore:DeleteWorkloadIdentity"
```
不要替换所有`bedrock-agentcore`操作——这些身份资源会故意保留旧的命名空间。
### 示例：更新 SDK 客户端配置
更新 SDK 调用中的服务名称、客户端类和终端节点 URL。
**之前（公开预览）：**
```
import boto3
session = boto3.Session(region_name="us-west-2")
cp_client = session.client(
"bedrock-agentcore-control",
endpoint_url="https://bedrock-agentcore-control.us-west-2.amazonaws.com"
)
dp_client = session.client(
"bedrock-agentcore",
endpoint_url="https://bedrock-agentcore.us-west-2.amazonaws.com"
)
```
**之后（正式上市）：**
```
import boto3
session = boto3.Session(region_name="us-west-2")
cp_client = session.client(
"agent-registry-control",
endpoint_url="https://agent-registry-control.us-west-2.api.aws"
)
dp_client = session.client(
"agent-registry",
endpoint_url="https://agent-registry.us-west-2.api.aws"
)
```
### 示例：更新 CLI 命令
替换所有脚本和自动化中的 CLI 命名空间。
**之前（公开预览）：**
```
aws bedrock-agentcore-control create-registry \
--name "MyRegistry" \
--description "Production registry" \
--region us-west-2 \
--endpoint-url https://bedrock-agentcore-control.us-west-2.amazonaws.com
```
**之后（正式上市）：**
```
aws agent-registry-control create-registry \
--name "MyRegistry" \
--description "Production registry" \
--region us-west-2 \
--endpoint-url https://agent-registry-control.us-west-2.api.aws
```
## API 架构变更
除了命名空间迁移外，我们还更新了注册表和注册表记录数据模型以供正式发布。根据公共预览版的反馈，这些更改提高了 API 的一致性和可扩展性。本节通过之前和之后的示例介绍了每个更改类别，因此您可以更新应用程序代码。
### 更改 1：注册表实体更新
注册表资源上的授权配置（控制如何访问注册表的数据平面）现在位于专用`discoveryConfiguration`封装器下，该封装器明确了其用途。批准配置（控制提交到`PENDING_APPROVAL`状态的记录是否自动转换为`APPROVED`状态）从布尔值变为可扩展的枚举数组。
具体的字段变化是：
+ `authorizerType`并`authorizerConfiguration`被移动到一个新`discoveryConfiguration`对象内。
+ `approvalConfiguration.autoApproval`（布尔值）替换为`approvalConfiguration.autoApprovalRules`（枚举字符串数组）。该值`"APPROVE_ALL"`的语义含义与相同。`autoApproval: true`将应用枚举列表中指定的规则。未指定（空）表示需要批准。
**之前（公开预览）：**
```
{
"name": "string",
"description": "string",
"authorizerConfiguration": { ... },
"authorizerType": "string",
"approvalConfiguration": {
"autoApproval": true
}
}
```
**之后（正式上市）：经批准全部**
```
{
"name": "string",
"description": "string",
"discoveryConfiguration": {
"authorizerConfiguration": { ... },
"authorizerType": "string"
},
"approvalConfiguration": {
"autoApprovalRules": ["APPROVE_ALL"]
}
}
```
**之后（正式上市）：枚举列表中为 NULL**
```
{
"name": "string",
"description": "Registry with manual approval only",
"approvalConfiguration": {
"autoApprovalRules": []
}
}
```
### 更改 2：注册表记录上新的必填字段
注册表记录增加了两个新的必填顶级字段，以支持更好的分类和重复数据删除。使用 `CreateRegistryRecord` API 创建注册表记录时，必须同时指定这两个字段，以后可以使用 `UpdateRegistryRecord` API 对其进行更改。
| 字段 | Type | 说明 |
| --- | --- | --- |
| `name` | 字符串（必填） | 注册表中的唯一标识符，可以由客户指定。每条记录在注册表中都必须有一个唯一的名称。当还`recordVersion`存在时，`name`和的组合`recordVersion`必须是唯一的。 |
| `recordType` | 枚举（必填） | 记录的语义类型。有效值：`AGENT`、`MCP`、`SKILL`、`CUSTOM`。确定哪个主描述符键在下`descriptors`有效。您可以使用`ListRegistryRecords`和`SearchDiscoverableRegistryRecords`之类的 API 按此语义类型筛选结果。 |
### 变动 3：重组注册表记录
该`descriptors`字段从区分式联合变为扁平键控结构。
在之前的模型中，`descriptorType`字段（`MCP`、`A2A`、`AGENT_SKILLS`、`CUSTOM`）决定了内部形状。这种描述符内容与粗略的协议或格式分类相结合。该字段已不存在。 `recordType`，一个单独的顶级属性，用于语义分类，取而代之。API 在运行时为每个密钥强制执行有效的描述符密钥，而不是`recordType`在形状上强制执行有效的描述符密钥。`descriptors`现在，下面的每个顶级键都代表一种精细的主描述符类型（例如、、`a2aAgentCard``mcpServer``agentSkillsDefinition`、`custom`）。补充描述符（例如`tools`，`skillMd`）嵌套在主描述符的下面。`additionalData`该`inlineContent`字段变成`data`。`schemaVersion`和`protocolVersion`字段合并为`dataSchemaVersion`。
顶级`synchronizationConfiguration`属性变为每个描述符（包括`additionalData`子项）`source`并在其中移动。
现有`name`字段变成`displayName`，使其含义更加明确。net-new `name` 字段用作重复数据删除密钥，并且在注册表中的所有记录中必须是唯一的。如果`recordVersion`为同一条记录同时指定`name`和，则它们的组合必须是唯一的。
以下字段已重命名：
| Before | 晚于 | 注意 |
| --- | --- | --- |
| `name` | `displayName` | 记录的显示名称。还将有一个新`name`字段，即重复数据删除密钥。 |
| `descriptorType` | 已删除 | 替换为顶级`recordType`字段。 |
| `inlineContent` | `data` | 每个描述符中的内容负载。 |
| `schemaVersion` / `protocolVersion` | `dataSchemaVersion` | 所有描述符类型的统一版本字段。 |
| `synchronizationConfiguration` | `source` | 在每个描述符（包括`additionalData`子项）内移动。 |
**之前（公开预览）：**
```
{
"recordId": "string",
"name": "string",
"descriptorType": "string", // A2A, MCP, AGENT_SKILL, CUSTOM
"descriptors": {
"agent": {
"a2aAgentCard": {
"inlineContent": "string",
"schemaVersion": "string"
}
},
"agentSkills": {
"skillDefinition": {
"inlineContent": "string",
"schemaVersion": "string"
},
"skillMd": {
"inlineContent": "string"
}
},
"mcp": {
"server": {
"inlineContent": "string",
"schemaVersion": "string"
},
"tools": {
"inlineContent": "string",
"protocolVersion": "string"
}
},
"custom": {
"inlineContent": "string"
}
},
"synchronizationType": "URL",
"synchronizationConfiguration": {
"fromUrl": {
"url": "string",
"credentialProviderConfigurations": [
{
"credentialProvider": { ... },
"credentialProviderType": "string"
}
]
}
},
...
}
```
**之后（正式上市）：**
```
{
"recordId": "string",
"displayName": "string",
"name": "string",
"recordVersion": "string",
"recordType": "AGENT" | "MCP" | "SKILL" | "CUSTOM",
"descriptors": {
"a2aAgentCard": {
"data": "string",
"dataSchemaVersion": "string",
"source": { "fromUrl": { "url": "string", "credentialProviderConfigurations": [...] } }
},
"mcpServer": {
"data": "string",
"dataSchemaVersion": "string",
"source": { "fromUrl": { ... } },
"additionalData": {
"tools": { "data": "string", "dataSchemaVersion": "string" }
}
},
"agentSkillsDefinition": {
"data": "string",
"dataSchemaVersion": "string",
"additionalData": {
"skillMd": { "data": "string", "dataSchemaVersion": "string", "source": { "fromUrl": { ... } } }
}
},
"custom"?: {
"data": "string"
}
},
"metadata": Document
...
}
```
以下限制适用：
每条记录只能填充一个主描述符键。有效的主描述符`recordType`为：
+ **代理:**`a2aAgentCard`,`mcpServer`, `custom`
+ **MCP:**`mcpServer`, `custom`
+ **技能:**`agentSkillsDefinition`, `custom`
+ **自定义：**`custom`
`source`是每个描述符而不是单个顶级块。它附加到架构中带有`source`字段的描述符上 — `mcpServer` 和。`a2aAgentCard``tools`孩子（下方`mcpServer.additionalData`）、`agentSkillsDefinition`父母和`custom`描述符带有 no `source`。
在 GA 中，`source.fromUrl`仅支持。
Auto-synchronization 仅针对`mcpServer`和`a2aAgentCard`主要描述符（即 MCP 和 AGENT 记录类型）触发。`skillMd`子项`source`上的 A 会保持不变，但不用于运行同步，并且无法自动同步技能记录。必须通过`data`直接提供手动创建自定义记录。
### 更改 4：数据平面过滤器更新
`SearchRegistryRecords`变成 `SearchDiscoverableRegistryRecords` (`POST /discoverable-records-search`)。它的请求和响应采用了新的字段名称和数据模型：
+ 筛选依据`recordType`（替换`descriptorType`）。
+ 筛选依据`recordVersion`（替换`version`）。
+ 响应以新格式返回描述符，不`credentialProviderConfigurations`带。
MCP 搜索工具`search_registry_records`变成`search_discoverable_registry_records`，返回新的描述符格式，并使用新的过滤器名称。
### 第 5 项更改：新的浏览 API
两个新的数据平面 API 支持在已批准的记录上构建浏览和目录体验。这些 API 不需要任何显式迁移；我们在此提及它们是对 GA AWS 代理注册表 API 模型的补充。
**ListDiscoverableRegistryRecords**— 返回已批准的注册表记录的分页列表。使用它来构建浏览已发布内容的界面。
```
// HTTP: POST /registries/{registryId}/discoverable-records-list
{
"registryId": "string", // path param, required (ARN or ID)
"maxResults": 1-100, // query param, optional
"nextToken": "string", // query param, optional
"filters": [ { "name": "recordType", "values": ["MCP"] } ]
}
{
"registryRecords": [
{
"registryArn": "string",
"recordArn": "string",
"recordId": "string",
"name": "string",
"displayName": "string",
"description": "string",
"recordType": "string",
"recordVersion": "string",
"status": "string",
"createdAt": "string",
"updatedAt": "string"
}
],
"nextToken": "string"
}
```
**BatchGetDiscoverableRegistryRecord**— 一次调用即可检索一个或多个注册表中一批记录的完整详细信息。
```
// HTTP: POST /discoverable-records-batch
{
"entries": [
{ "registryId": "reg-AAA", "recordIds": ["rec-111", "rec-222"] }
]
}
{
"registryRecords": [
{
"registryArn": "string",
"recordArn": "string",
"recordId": "string",
"name": "string",
"displayName": "string",
"description": "string",
"recordType": "string",
"descriptors": { ... },
"recordVersion": "string",
"status": "string",
"createdAt": "string",
"updatedAt": "string"
}
],
"errors": [
{
"registryId": "string",
"recordId": "string",
"errorCode": "RESOURCE_NOT_FOUND" | "ACCESS_DENIED" | "INTERNAL_ERROR",
"message": "string"
}
]
}
```
响应包括一个包含完整记录详细信息的`registryRecords`数组和一个用于存`errors`放任何无法检索的记录的数组。
启动时，只接受一个条目（一个注册表，1-100 个记录 ID）。分组的形状与 future 版本中的跨注册表批处理向前兼容。
### 第 6 项更改：列表 API 采用结构化筛选器参数
在公共预览版中，List API 将每个可筛选字段作为自己的查询参数公开（例如`--status READY`，`--recordType MCP`）。在 GA 中，单个结构化`filters`参数取代这些离散参数。该`filters`值是`{ "name": "", "values": [""] }`条目列表，其中`name`以点分隔的属性路径。新的可筛选字段（包括嵌套字段）将成为新的`name`路径，而不是新的 API 参数。列表操作也从变`GET`为`POST`。分页参数 (`maxResults`,`nextToken`) 保持不变。
**之前（公开预览）：**
```
GET /registries?status=READY&authorizerType=AWS_IAM
GET /registries/{registryId}/records?name=my-agent&status=APPROVED&recordType=MCP
```
**之后（正式上市）：**
```
// ListRegistries
// POST /registries-list
{
"filters": [
{ "name": "status", "values": ["READY"] },
{ "name": "discoveryConfiguration.authorizerType", "values": ["AWS_IAM"] }
],
"maxResults": 100,
"nextToken": "string"
}
// ListRegistryRecords
// POST /registries/{registryId}/records-list
{
"filters": [
{ "name": "name", "values": ["my-agent"] },
{ "name": "status", "values": ["APPROVED"] },
{ "name": "recordType", "values": ["MCP"] }
],
"maxResults": 100,
"nextToken": "string"
}
```
## 数据迁移
您必须将现有的注册表和注册表记录从命名空间迁移到`bedrock-agentcore`命名`agent-registry`空间。我们提供了一个脚本来帮助迁移。该脚本处理现有数据的提取、从旧架构到新架构的转换，以及加载到新命名空间中的注册表中。该脚本在同一账户和区域内的`agent-registry`命名空间中创建新的注册表。它会将所有现有记录从旧注册表迁移到新注册表，同时考虑到命名空间和 API 架构的变化。
### 选择您的迁移方法
正确的方法取决于您的注册表使用规模和操作环境。
#### 案例 1：通过直接执行脚本进行 Small-scale 迁移
+ **概要：**少于 5 个注册表，少于 100 个记录。您可以直接访问终端或 CloudShell 目标账户。
+ **方法：**直接运行迁移 Python 脚本。该脚本连接到预览命名空间，列出您的注册表和记录，将数据转换为 GA 架构，并在新的命名空间中创建它们。这是最简单的方法，不需要部署基础架构。
#### 案例 2：使用 Lambda 或 Glue 进行托管迁移
+ **配置文件：**您无法直接终端访问目标环境，或者您更喜欢托管执行模型。
+ **方法：**将迁移部署为 AWS Lambda 函数或 Glue 任务 AWS 。迁移引擎执行相同的提取-转换-加载工作流程，但在您的账户中作为托管作业运行。对于大多数账户来说，完全迁移在 15 分钟内即可完成。
迁移引擎：
+ 从预览命名空间中@@ **提取**注册表和记录，同时支持完整加载和增量加载。它会对所有 API 响应进行分页，并将数据序列化到暂存位置。
+ 通过应用 API 架构更改（字段重命名、描述符重组、新的必填字段）来@@ **转换**每条记录。
+ 将转换后的数据@@ **加载**到新的`agent-registry`命名空间中，使用 GA API 创建注册表和记录。
+ **生成一份报告，**总结已迁移的内容、遇到的任何错误以及记录计数以供验证。
#### 案例 3：为活跃的生产工作负载进行 Dual-write 迁移
+ **简介：**您已经在公共预览版 API 之上构建了平台或自动化管道，并且正在积极地在生产环境中编写新数据。
+ **方法：**使用双写迁移策略来避免在过渡期间丢失数据：
+ **更新您的编写器**-修改您的应用程序以同时写入预览命名空间和新`agent-registry`命名空间。
+ **使用重复数据删除功能运行迁移脚本**-执行迁移工具以迁移历史数据。脚本会根据该`name`字段进行重复数据删除，因此不会复制新命名空间中已存在的记录（来自您的双重写入）。
+ **切换读取器** — 在您确认所有数据都存在于新命名空间中之后，请更新您的应用程序，使其仅从中读取`agent-registry`。
+ **移除双重写入**-确认新命名空间上的所有读取和写入均成功后，从应用程序中移除预览命名空间写入器。
### 验证您的迁移
运行迁移后，请确认您的数据已正确迁移：
+ 使用 `list-registries` CLI 命令列出新命名空间中的所有注册表，并确认计数与您的来源相匹配。
+ 对于每个注册表，使用比较记录数`list-registry-records`。
+ Spot-check 用于确认描述符已正确转换的单个记录（字段重命名、描述符重组）。
+ 按照命名空间和配置更改部分中所述更新您的 IAM 策略、终端节点和 SDK 客户端。
+ 使用新的命名空间，验证您的应用程序是否可以成功读取和写入。
## 常见问题解答
### 发生了什么变化 AWS 代理注册表？
AWS Agent Registry 正在从公共预览`bedrock-agentcore`命名空间移至公开发布的`agent-registry`命名空间。迁移跨三个领域：命名空间和配置更改（终端节点、IAM、SDK、CLI、ARN、可观察性）、API 架构更改（注册表和记录的重构数据模型）和数据迁移（将现有注册表和记录移至新的命名空间）。
### 我能否继续在 b `edrock-agentc` ore 命名空间上使用 Registry？
在迁移窗口期间，您在`bedrock-agentcore`命名空间上的现有注册表使用将继续正常运行，不会中断。但是，我们建议您在工具可用后立即开始迁移，以确保您有足够的时间完成数据迁移和代码更新。
但是，如果您在 2026 年 8 月 6 日之前没有现有的注册表或记录，则从 2026 年 8 月 6 日起，您将无法访问 AWS 代理注册表的`bedrock-agentcore`命名空间。如果您在 2026 年 8 月 6 日之前已有注册表或记录，则可以在迁移时段（2026 年 8 月 6 日至 2026 年 9 月 17 日）访问 AWS 代理注册表的`bedrock-agentcore`命名空间。
### 我的数据会自动迁移吗？
不是。 您必须使用我们提供的迁移工具自行启动迁移。有关基于您的规模的可用方法的详细信息，请参阅数据迁移部分。
### 包括哪些 API 架构更改？
除了命名空间的更改外，我们还更新了六个方面的 API 数据模型：注册表实体（授权配置分组在下面`discoveryConfiguration`）、注册表记录新字段（`name`和`recordType`）、注册表记录重组（描述符扁平化、字段重命名）、搜索 API 筛选器更新（`recordType`、`recordVersion`）、新的浏览 API（`ListDiscoverableRegistryRecords`、`BatchGetDiscoverableRegistryRecord`）和列表操作的结构化筛选器。
### 数据迁移需要多长时间？
迁移时间取决于您账户中注册表和记录的数量。对于记录少于 100 的账户，在本地运行时，迁移将在几分钟内完成。对于拥有数千条记录的账户，作为托管作业运行时，预计迁移将在不到 15 分钟的时间内完成。
### 如果我的大规模部署采用主动写入操作会怎样？
如果您在生产环境中主动向预览命名空间写入数据，请使用案例 3 中所述的双写迁移策略。这种方法可确保在过渡期间不会丢失任何数据，方法是同时写入两个命名空间，使用重复数据删除功能迁移历史数据，然后切断读取。
### 我在哪里可以得到帮助？
如果您对迁移有任何疑问或需要帮助，请联系 Supp [AWS ort](https://aws.amazon.com/support)。