# 完整的登錄檔遷移指南
* AWS 代理程式登錄檔 — 從公開預覽遷移到一般可用性*
## 簡介
作為 2026 年 8 月 6 日正式推出 (GA) 的一部分， AWS 代理登錄檔正在為服務主體、資料和 API 模型引入重大變更。如果您在公開預覽期間使用 AWS 客服人員登錄檔，則必須完成跨越三個區域的遷移：
1. **命名空間和組態變更** – 我們將 AWS 代理程式登錄檔從 AWS Bedrock AgentCore 命名空間移至自己的專用命名空間。此命名空間變更僅適用於 AWS 客服人員登錄檔。所有其他 AgentCore 產品，例如 Identity、Gateway、Runtime 和 Policy，都不會受到影響。對於 AWS 客服人員登錄檔，服務命名空間會從 變更為 `bedrock-agentcore` `agent-registry`。這會影響參考服務的每個表面：端點、IAM 政策、SDK 用戶端、CLI 命令、資源 ARNs 和可觀測性整合。您必須更新程式碼和基礎設施，才能使用新的命名空間。
1. **API 結構描述變更** – 在公開預覽期間，登錄檔和登錄檔記錄資料模型會根據客戶意見回饋進行更新。這些變更會破壞與現有 API 結構描述的回溯相容性。建構或剖析 API 請求和回應的應用程式程式碼必須更新，以反映新的結構描述，作為遷移至新命名空間的一部分。
1. **資料遷移** – 您必須將現有的登錄檔和登錄檔記錄從舊命名空間遷移到新的命名空間。我們提供遷移工具來擷取您的資料、將其轉換為新的結構描述，並將其載入新的命名空間。資料會遷移至相同的帳戶和區域，只有命名空間會變更。
本指南提供before-and-after範例，詳細說明每個區域，協助您規劃和執行遷移。
## 什麼是遷移時間表？
您必須為此遷移記住兩個重要的里程碑：
+ **2026 年 8 月 6** 日 — AWS 代理登錄檔正式推出，新的`agent-registry`命名空間正式推出。如果您有現有的登錄檔和記錄，您可以同時存取 `bedrock-agentcore`和 `agent-registry` 命名空間。遷移工具可在 [agentcore-samples GitHub 儲存庫](https://github.com/awslabs/agentcore-samples)中使用。您可以開始遷移程序。
**注意**
如果您是新客戶，且自 2026 年 8 月 6 日起沒有現有的登錄檔或記錄，則無法透過 `bedrock-agentcore` 命名空間存取 AWS 客服人員登錄檔。直接從 `agent-registry` 命名空間開始使用 AWS 代理程式登錄檔。
+ **2026 年 9 月 17** 日 — 遷移時段關閉。舊`bedrock-agentcore`命名空間在此日期關閉。您會失去對服務和舊命名空間中任何剩餘資料的讀取/寫入存取權。在此日期之後，您必須使用 `agent-registry` 命名空間。
## 命名空間和組態變更
`agent-registry` 命名空間`bedrock-agentcore`會在下列位置取代 。本節列出變更的每個表面，並提供如何更新程式碼的範例。
**重要**
命名空間變更只會影響 AWS Agent Registry 提供的 APIs，但不會影響 AWS Bedrock AgentCore 的其餘部分，例如 AWS AgentCore Identity。因此，工作負載身分和 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 政策、服務控制政策 (SCPs) 和許可界限。資源 ARNs也會變更以反映新的命名空間。
| 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}` |
如果您有剖析 ARNs 或存放它們的自動化，也請更新這些參考。具有 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:*`許可。
### SDK、CLI 和基礎設施
更新您的應用程式程式碼、部署指令碼和infrastructure-as-code範本，以參考新的用戶端類別和 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`
### 可觀測性和事件
更新任何參考舊命名空間的 CloudTrail Lake 查詢、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:*"]
}]
}
```
**After （一般可用性）：**
```
{
"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` 命名空間下。如果您的登錄檔使用 URL 同步 (`source.fromUrl`) 搭配 OAuth 或 IAM 登入資料，您必須保留下列許可以及新的`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"
)
```
**After （一般可用性）：**
```
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
```
**After （一般可用性）：**
```
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
}
}
```
**After （一般可用性）：含核准 ALL**
```
{
"name": "string",
"description": "string",
"discoveryConfiguration": {
"authorizerConfiguration": { ... },
"authorizerType": "string"
},
"approvalConfiguration": {
"autoApprovalRules": ["APPROVE_ALL"]
}
}
```
**After （一般可用性）：列舉清單中的 NULL**
```
{
"name": "string",
"description": "Registry with manual approval only",
"approvalConfiguration": {
"autoApprovalRules": []
}
}
```
### 變更 2：登錄檔記錄上的新必要欄位
登錄檔記錄會取得兩個新的必要頂層欄位，以支援更好的分類和重複資料刪除。使用 `CreateRegistryRecord` API 建立登錄檔記錄時，您必須指定這兩個欄位，之後可以使用 `UpdateRegistryRecord` API 進行變更。
| 欄位 | Type | 說明 |
| --- | --- | --- |
| `name` | 字串 （必要） | 登錄檔中的唯一識別符，可由客戶指定。每個記錄都必須在登錄檔中具有唯一的名稱。當 `recordVersion` 也存在時， `name`和 的組合`recordVersion`必須是唯一的。 |
| `recordType` | Enum （必要） | 記錄的語意類型。有效值：`AGENT`、`MCP`、`SKILL`、`CUSTOM`。決定哪個主要描述項索引鍵在 下有效`descriptors`。您可以使用 `ListRegistryRecords`和 等 APIs`SearchDiscoverableRegistryRecords`，依此語意類型篩選結果。 |
### 變更 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`屬性會變成`source`並在每個描述項 （包括`additionalData`子項） 內移動。
現有`name`欄位會變成 `displayName`，使其含義更明確。net-new `name` 欄位做為 dedup 金鑰，且登錄檔中的所有記錄都必須是唯一的。如果您`recordVersion`同時為相同的記錄指定 `name`和 ，則其組合必須是唯一的。
下列欄位會重新命名：
| Before | After | 備註 |
| --- | --- | --- |
| `name` | `displayName` | 顯示記錄的名稱。也會有一個新`name`欄位是 dedup 金鑰。 |
| `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"
}
]
}
},
...
}
```
**After （一般可用性）：**
```
{
"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`描述項不帶 `source`。
在 GA，僅支援 `source.fromUrl` 。
自動同步只會針對 `mcpServer`和`a2aAgentCard`主要描述項觸發，也就是 MCP 和 AGENT 記錄類型。`skillMd` 子`source`系上的 會保留，但不會用來執行同步，且 SKILL 記錄無法自動同步。必須透過`data`直接提供 手動建立 CUSTOM 記錄。
### 變更 4：資料平面篩選條件更新
`SearchRegistryRecords` 會變成 `SearchDiscoverableRegistryRecords`(`POST /discoverable-records-search`)。其請求和回應會挑選新的欄位名稱和資料模型：
+ 依 篩選 `recordType`（取代 `descriptorType`)。
+ 依 篩選 `recordVersion`（取代 `version`)。
+ 回應會以新格式傳回描述項，不含 `credentialProviderConfigurations`。
MCP 搜尋工具`search_registry_records`會變成 `search_discoverable_registry_records`，傳回新的描述項格式，並使用新的篩選條件名稱。
### 變更 5：新的瀏覽 APIs
兩個新的資料平面 APIs 支援透過核准的記錄建置瀏覽和目錄體驗。這些 APIs 不需要任何明確的遷移；我們在此處提及它們作為 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 IDs)。分組的形狀與未來版本的跨登錄批次相容。
### 變更 6：列出 APIs採用結構化篩選條件參數
在公開預覽中，列出 APIs會將每個可篩選欄位公開為自己的查詢參數 （例如，`--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
```
**After （一般可用性）：**
```
// 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：使用直接指令碼執行進行小型遷移
+ **設定檔：**少於 5 個登錄檔，且少於 100 個記錄。您可以直接存取目標帳戶中的終端機或 CloudShell。
+ **方法：**直接執行遷移 Python 指令碼。指令碼會連線至預覽命名空間、列出您的登錄檔和記錄、將資料轉換為 GA 結構描述，並在新的命名空間中建立這些資料。這是最簡單的路徑，不需要部署基礎設施。
#### 案例 2：使用 Lambda 或 Glue 進行受管遷移
+ **設定檔：**您沒有目標環境的直接終端機存取權，或者您偏好受管執行模型。
+ **方法：**將遷移部署為 AWS Lambda 函數或 Glue AWS 任務。遷移引擎會執行相同的extract-transform-load工作流程，但在您的帳戶中做為受管任務執行。對於大多數帳戶，完整遷移會在 15 分鐘內完成。
遷移引擎：
+ 從預覽命名空間**擷取**登錄檔和記錄，同時支援完整負載和增量負載。它會分頁所有 API 回應，並將資料序列化到暫存位置。
+ **透過**套用 API 結構描述變更 （欄位重新命名、描述項重組、新的必要欄位） 轉換每個記錄。
+ 將轉換的資料**載入**新的`agent-registry`命名空間，使用 GA API 建立登錄檔和記錄。
+ **產生報告**，摘要已遷移的內容、遇到的任何錯誤，以及記錄計數以進行驗證。
#### 案例 3：主動生產工作負載的雙寫入遷移
+ **設定檔：**您已在公有預覽 APIs 上建置平台或自動化管道，並積極在生產環境中撰寫新資料。
+ **方法：**使用雙寫入遷移策略，以避免在轉換期間遺失資料：
+ **更新您的寫入器** – 修改您的應用程式以同時寫入預覽命名空間和新的`agent-registry`命名空間。
+ **使用重複資料刪除執行遷移指令碼** – 執行遷移工具來遷移歷史資料。指令碼會根據 `name` 欄位刪除重複項目，因此不會複製已存在於新命名空間 （來自雙寫入） 中的記錄。
+ **切換您的讀取器** – 驗證所有資料存在於新的命名空間之後，請更新您的應用程式以僅從 讀取`agent-registry`。
+ **移除雙寫入** – 在確認新命名空間上的所有讀取和寫入都成功之後，請從應用程式中移除預覽命名空間寫入器。
### 驗證您的遷移
執行遷移後，請確認您的資料已正確遷移：
+ 使用 CLI `list-registries` 命令列出新命名空間中的所有登錄檔，並確認計數與您的來源相符。
+ 對於每個登錄檔，使用 比較記錄計數`list-registry-records`。
+ Spot 檢查個別記錄，以確認描述項已正確轉換 （欄位重新命名、描述項重組）。
+ 更新您的 IAM 政策、端點和 SDK 用戶端，如命名空間和組態變更一節中所述。
+ 確認您的應用程式可以使用新的命名空間成功讀取和寫入。
## 常見問答集
### AWS 客服人員登錄檔中有哪些變更？
AWS 客服人員登錄檔正在從公有預覽`bedrock-agentcore`命名空間移至一般可用的`agent-registry`命名空間。遷移跨越三個領域：命名空間和組態變更 （端點、IAM、SDK、CLI、ARNs、可觀測性）、API 結構描述變更 （登錄和記錄的結構化資料模型），以及資料遷移 （將現有的登錄和記錄移至新的命名空間）。
### 我可以在`bedrock-agentcore`命名空間繼續使用登錄檔嗎？
命名`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`)、新的瀏覽 APIs (`ListDiscoverableRegistryRecords`、`BatchGetDiscoverableRegistryRecord`)，以及清單操作的結構化篩選條件。
### 資料遷移需要多長時間？
遷移時間取決於您帳戶中的登錄檔和記錄數量。對於記錄少於 100 筆的帳戶，遷移會在本機執行時於幾分鐘內完成。對於有數千筆記錄的帳戶， 預期在以受管任務身分執行時，遷移會在 15 分鐘內完成。
### 如果我有具有作用中寫入的大規模部署，該怎麼辦？
如果您正在生產環境中將資料主動寫入預覽命名空間，請使用雙寫入遷移策略，如案例 3 中所述。此方法可同時寫入兩個命名空間、使用重複資料刪除遷移歷史資料，然後切換讀取，以確保轉換期間不會遺失資料。
### 哪裡可以取得協助？
如需遷移的問題或協助，請聯絡 [AWS Support](https://aws.amazon.com/support)。