簡介什麼是遷移時間表？命名空間和組態變更 API 結構描述變更資料遷移常見問答集

完整的登錄檔遷移指南

AWS 代理程式登錄檔 — 從公開預覽遷移到一般可用性

簡介

作為 2026 年 8 月 6 日正式推出 (GA) 的一部分， AWS 代理登錄檔正在為服務主體、資料和 API 模型引入重大變更。如果您在公開預覽期間使用 AWS 客服人員登錄檔，則必須完成跨越三個區域的遷移：

命名空間和組態變更 – 我們將 AWS 代理程式登錄檔從 AWS Bedrock AgentCore 命名空間移至自己的專用命名空間。此命名空間變更僅適用於 AWS 客服人員登錄檔。所有其他 AgentCore 產品，例如 Identity、Gateway、Runtime 和 Policy，都不會受到影響。對於 AWS 客服人員登錄檔，服務命名空間會從變更為 bedrock-agentcore agent-registry。這會影響參考服務的每個表面：端點、IAM 政策、SDK 用戶端、CLI 命令、資源 ARNs 和可觀測性整合。您必須更新程式碼和基礎設施，才能使用新的命名空間。
API 結構描述變更 – 在公開預覽期間，登錄檔和登錄檔記錄資料模型會根據客戶意見回饋進行更新。這些變更會破壞與現有 API 結構描述的回溯相容性。建構或剖析 API 請求和回應的應用程式程式碼必須更新，以反映新的結構描述，作為遷移至新命名空間的一部分。
資料遷移 – 您必須將現有的登錄檔和登錄檔記錄從舊命名空間遷移到新的命名空間。我們提供遷移工具來擷取您的資料、將其轉換為新的結構描述，並將其載入新的命名空間。資料會遷移至相同的帳戶和區域，只有命名空間會變更。

本指南提供before-and-after範例，詳細說明每個區域，協助您規劃和執行遷移。

什麼是遷移時間表？

您必須為此遷移記住兩個重要的里程碑：

2026 年 8 月 6 日 — AWS 代理登錄檔正式推出，新的agent-registry命名空間正式推出。如果您有現有的登錄檔和記錄，您可以同時存取 bedrock-agentcore和 agent-registry 命名空間。遷移工具可在 agentcore-samples GitHub 儲存庫中使用。您可以開始遷移程序。

注意
如果您是新客戶，且自 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 許可參考。

注意

如果您目前使用 BedrockAgentCoreFullAccess AWS 受管政策進行 AWS 代理登錄檔存取（請參閱 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": "<dotted.path>", "values": ["<value>"] }項目清單，其中 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。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

疑難排解

安全

完整的登錄檔遷移指南

簡介

什麼是遷移時間表？

注意

命名空間和組態變更

重要

服務端點

IAM 和安全性

注意

SDK、CLI 和基礎設施

可觀測性和事件

範例：更新 IAM 政策

注意

重要

範例：更新 SDK 用戶端組態

範例：更新 CLI 命令

API 結構描述變更

變更 1：登錄實體更新

變更 2：登錄檔記錄上的新必要欄位

變更 3：登錄檔記錄重組

變更 4：資料平面篩選條件更新

變更 5：新的瀏覽 APIs

變更 6：列出 APIs採用結構化篩選條件參數

資料遷移

選擇遷移方法

案例 1：使用直接指令碼執行進行小型遷移

案例 2：使用 Lambda 或 Glue 進行受管遷移

案例 3：主動生產工作負載的雙寫入遷移

驗證您的遷移

常見問答集

AWS 客服人員登錄檔中有哪些變更？

我可以在bedrock-agentcore命名空間繼續使用登錄檔嗎？

我的資料是否會自動遷移？

包含哪些 API 結構描述變更？

資料遷移需要多長時間？

如果我有具有作用中寫入的大規模部署，該怎麼辦？

哪裡可以取得協助？

我可以在`bedrock-agentcore`命名空間繼續使用登錄檔嗎？