跳到正文
AWS Machine Learning Blog· Vibhu Pareek·· 2 小時前精選AI 評分66

AWS Agent Registry 如何在執行時探索工具

Discover tools at runtime with AWS Agent Registry

AI 導讀

AWS 的示例展示如何透過 AWS Agent Registry，在執行時搜尋已核准的 MCP 伺服器、智能體及技能，並按結果建立本次請求所需的用戶端。示例以訂單狀態、價格折扣及退貨退款三種情境，展示 MCP 單獨呼叫、MCP 與 A2A 串接，以及語義搜尋。搜尋結果只提供連線描述資料，不含呼叫憑證；記錄須經核准才會透過可搜尋資料平面提供，各項能力所需的呼叫憑證須另行處理。

推薦理由

文章以 MCP 與 A2A 的訂單管理示例拆解執行時探索流程，並説明搜尋描述資料、核准治理與能力呼叫憑證之間的責任邊界。

正文 · 繁體中文

AWS Agent Registry 的執行時探索功能，有助解決一個 Agent 示範可能掩蓋的問題。硬編碼工具只有幾個時運作良好，增至數十個便開始出現問題，更多時則難以管理。企業系統會提供數百個內部 API，涵蓋定價、支援服務、訂單、庫存及客戶資料。在這些系統中，模型花在辨別工具名稱上的 token，可能比用於推理用戶請求的 token 還多。每項新能力都需要修改編排器的程式碼、重新部署，並由多個團隊協調發布；這些團隊其實更希望按自己的節奏發布。

在各類企業軟件即服務（SaaS）合作項目中，若團隊向具備 Agent 能力的系統開放大量內部 API，便可能出現這種模式。隨着目錄擴大，建置時連接各項工具可能會成為瓶頸。一種做法是改變編排器存取工具的方式：不再將每項工具編入 Agent，而是讓 Agent 在執行時探索相關工具。

AWS Agent Registry 是一項受管理服務，用於編目和探索 Model Context Protocol（MCP）伺服器、Agent 及 Agent 技能。發布者會註冊各協定專用的描述資料，以及可供搜尋的説明。在執行時，編排器可搜尋已核准且可供探索的記錄，並使用傳回的端點及描述資料建立用戶端。Registry 搜尋結果不會傳回該能力的呼叫憑證或驗證方案。

本文會介紹重構後的 Python 範例所示範的「探索 → 建立實例 → 執行」流程。程式碼會透過 Amazon Bedrock AgentCore Gateway 部署訂單管理 MCP 伺服器；Amazon Bedrock AgentCore 的一項能力、兩個部署在 AgentCore runtime 上的代理對代理（A2A）Agent、一個 Registry，以及一個編排器。範例目錄包含部署指令碼、編排器、輔助模組及清理指令碼。

方案概覽：探索、建立實例、執行

此範例中的編排器 Agent 並沒有內置任何工具或 Agent 的相關知識。

Comparison of hardcoded tool endpoints versus runtime discovery with AWS Agent Registry

圖 1：使用 AWS Agent Registry 前（左），端點以硬編碼方式設定，新增 Agent 代表需要修改程式碼並重新部署。使用 AWS Agent Registry 後（右），編排器可透過語義搜尋探索各項能力；新整合在註冊並獲批後即可使用

探索

編排器會向 AWS Agent Registry 資料平面傳送自然語言查詢。搜尋回應包括記錄識別資料、名稱、描述、記錄類型、狀態、版本，以及協定描述資料，例如 MCP 伺服器中繼資料或 A2A Agent Card。回應不包括呼叫憑證。應用程式必須透過獨立且可信的設定途徑取得並套用適當的憑證。

建立實例

對於每項傳回的記錄，編排器會根據描述資料類型建立用戶端。在此範例中，已註冊的 MCP 伺服器代表一組工具；這些工具最初以目標形式新增至 Amazon Bedrock AgentCore Gateway。因此，MCP 描述資料指向 Gateway 端點。編排器會另外取得 Cognito OAuth 存取 Token，並在建立 MCPClient 時使用該 Token。A2A 記錄包含一張 Agent Card，其 URL 用以識別 AgentCore runtime 端點。包裝程式透過 boto3 資料平面用戶端呼叫該 runtime；該用戶端會使用呼叫方的 AWS 憑證為請求簽署。Registry 探索提供的是連線中繼資料，而非驗證資料。

執行

系統會建立一個短暫存在的內部 Agent，當中只有動態探索到的工具。大型語言模型（LLM）會為要求選取合適的工具，並綜合結果後回覆用戶。回合結束後，內部 Agent 及其用戶端會被拆除。下一個要求會重新搜尋，並取得一組全新的工具。

End-to-end architecture: the orchestrator queries AWS Agent Registry, then invokes MCP servers through AgentCore Gateway and A2A agents on AgentCore runtime

圖 2：端對端架構。Amazon Bedrock AgentCore runtime 上的單一協調器會查詢 AWS Agent Registry。透過 Amazon Bedrock AgentCore Gateway 呼叫符合條件的 MCP 伺服器，並在 Amazon Bedrock AgentCore runtime 上呼叫符合條件的 A2A Agent

此範例採用的參考架構包括 AWS Agent Registry、Amazon Bedrock AgentCore Gateway、Amazon Bedrock AgentCore runtime、Amazon Bedrock、Amazon Cognito、AWS Lambda 和 AWS Secrets Manager。

三個示範情境會以不同的能力組合測試探索循環。第一個只呼叫 MCP（訂單狀態）。第二個串接 MCP + A2A（定價和折扣）。第三個測試對含糊用戶意圖進行純語義匹配：退貨和退款；這些詞語不會出現在符合條件的 A2A Agent 名稱中。

技術實作

連結中的 runtime-discovery 範例會部署相依項目、建立並填入 Registry、驗證探索功能、部署協調器，並執行三個示範。orchestrator_agent.py 包含每項要求的探索循環。utils.py 會剖析 Registry 描述符，並建立 MCP 和 A2A 用戶端。cleanup.py 會移除資源。

1. 註冊模式

Registry 記錄包含可搜尋的描述，以及特定協定的描述符。此範例使用 Agent Registry 控制平面用戶端執行 Registry 和記錄的生命週期操作，並使用 Agent Registry 資料平面用戶端進行 runtime 探索。

建立採用手動審批及 IAM 授權的 Registry。

registry_client = session.client("agent-registry-control")
dp_client = session.client("agent-registry")
reg = registry_client.create_registry(
    name="OrderManagementRegistry",
    description=(
        "Registry for Order Management & Customer Service — "
        "agent discovers tools and agents via semantic search"
    ),
    approvalConfiguration={"autoApprovalRules": []},
)
REGISTRY_ARN = reg["registryArn"]
REGISTRY_ID = REGISTRY_ARN.split("/")[-1]

建立記錄時必須提供 recordType 欄位。在此範例中，MCP 伺服器使用 recordType="MCP"，由 A2A 支援的 Agent 則使用 recordType="AGENT"。協定中繼資料會儲存在 descriptors 物件中的 mcpServer 或 a2aAgentCard。MCP 描述符包含伺服器中繼資料和工具定義。A2A 描述符包含 Agent 卡片。描述符包含連線中繼資料，但不包含用戶呼叫該能力時必須提供的憑證。

建構 MCP 和 A2A 記錄所用的目前公開 SDK 描述符結構。

# MCP descriptor
mcp_descriptors = {
    "mcpServer": {
        "data": json.dumps(server_metadata),
        "dataSchemaVersion": "2025-12-11",
        "additionalData": {
            "tools": {
                "data": json.dumps({"tools": tool_schemas}),
                "dataSchemaVersion": "2025-06-18",
            }
        },
    }
}

# A2A descriptor
a2a_descriptors = {
    "a2aAgentCard": {
        "data": json.dumps(agent_card),
        "dataSchemaVersion": "0.3",
    }
}

請以面向用戶的語言撰寫描述，清楚區分該能力與相鄰記錄。描述資料需提供協定專用的伺服器、工具或 agent card 資料。搜尋品質應以具代表性的查詢評估。本文不假設目錄擴大便會自動改善排名。

以目前的控制平面結構建立 Registry 記錄。

descriptors = (
    mcp_descriptors
    if cfg["protocol"] == "MCP"
    else a2a_descriptors
)

response = registry_client.create_registry_record(
    registryId=REGISTRY_ID,
    name=name,
    description=cfg["description"],
    recordType=cfg["protocol"],
    descriptors=descriptors,
    recordVersion="1.0",
)
record_id = response["recordId"]

2. 核准流程

將 autoApproval 設為 false 後，新記錄必須由 DRAFT 轉至 PENDING_APPROVAL，再轉至 APPROVED。提交及狀態更新操作均須經 IAM 授權，以便分開設定發布者與核准者的權限。只有已核准的記錄會由可供探索的 Registry 數據平面傳回。

兩步核准狀態轉換。

record = registry_client.get_registry_record(
    registryId=REGISTRY_ID,
    recordId=record_id,
)
if record["status"] == "DRAFT":
    registry_client.submit_registry_record_for_approval(
        registryId=REGISTRY_ID,
        recordId=record_id,
    )
    registry_client.update_registry_record_status(
        registryId=REGISTRY_ID,
        recordId=record_id,
        status="APPROVED",
        statusReason="Approved",
    )

3. 探索層

數據平面用戶端支援對可供探索的記錄進行混合式關鍵字及語意搜尋。最新的方法名稱為 search_discoverable_registry_records。結果會提供正規化的記錄欄位及可供探索的描述資料，但不會公開該能力的呼叫憑證。

跨協定搜尋已核准且可供探索的記錄。

response = dp_client.search_discoverable_registry_records(
    registryIds=[REGISTRY_ARN],
    searchQuery=query,
    maxResults=3,
)
records = response.get("registryRecords", [])

在示範情境中，退貨及退款查詢會找到 Customer Support Agent，因為其描述涵蓋該意圖。應將此視為示範結果，而非認為目錄擴大就必然改善排名的一般性主張。

4. 協調器

協調器是一個部署至 Amazon Bedrock AgentCore runtime 的 Strands agent。它提供 discover_and_execute，用來搜尋 Registry、解析每個傳回的描述資料、建立相應的 MCP 或 A2A 用戶端，並僅根據探索到的能力建立專用於該請求的內層代理。

The orchestrator’s per-request flow, where an outer agent searches the Registry and assembles a request-scoped inner agent from the results

圖 3：協調器按請求執行的流程。外層代理將用戶請求轉換為 Registry 搜尋。內層代理根據搜尋結果組建，並在該輪結束時銷毀

discover_and_execute的核心可用單一程式碼區塊呈現：

協調器的探索／建立實例／執行循環。

​​​@tool 
 def discover_and_execute(request: str) -> str: 
     records = dp_client.search_discoverable_registry_records( 
         registryIds=[REGISTRY_ARN], 
         searchQuery=request, 
         maxResults=5, 
     ).get("registryRecords", []) 
  
    # Registry returns descriptors, not invocation credentials. 
     oauth_token = fetch_oauth_token_from_config() 
     mcp_clients, a2a_tools = [], [] 
     for record in records: 
         metadata = parse_server_metadata(record) 
         if metadata["protocol"] == "MCP": 
             mcp_clients.append( 
                 create_mcp_client_from_metadata(metadata, oauth_token) 
             ) 
         elif metadata["protocol"] == "A2A": 
             a2a_tools.append( 
                 create_a2a_tool_from_metadata(metadata, session, REGION) 
             ) 
  
    return run_request_scoped_agent(request, mcp_clients, a2a_tools)​​ 

​​model = BedrockModel(model_id=MODEL_ID, region_name=REGION) 
​    started_clients = [] 
​    try: 
​        mcp_tools = [] 
​        for c in mcp_clients: 
​            c.start() 
​            started_clients.append(c) 
​            mcp_tools.extend(c.list_tools_sync()) 

​ 	    ##agent compiled in realtime within agent 
​        sub_agent = Agent( 
​            model=model, 
​            tools=mcp_tools + a2a_tools, 
​            system_prompt=( 
​                "You are an Order Management & Customer Service assistant. " 
​                "Use the RIGHT tool for each request:\\n" 
​                "- Order lookups, status, cancellations, address changes: use MCP tools\\n" 
​                "- Pricing, discounts, promo codes: use the pricing_agent tool\\n" 
​                "- Returns, refunds, complaints, escalations: use the customer_support_agent tool\\n" 
​                "Always use the most specific tool for the task." 
​            ), 
​        ) 
​        return str(sub_agent(request)) 
​    finally: 
​        for c in started_clients: 
​            try: 
​                c.stop() 
​            except Exception: 
​                pass​

此示範會針對其訂單管理領域發出多個搜尋查詢，以提高召回率；它亦會對記錄去重，並在請求完成後銷毀 MCP 用戶端。這種多路搜尋是示範程式特有的協調方式，並非 Registry 的要求。驗證仍在探索流程之外處理：Gateway OAuth 權杖透過 Cognito 設定及 Secrets Manager 取得，而 A2A 執行階段呼叫則透過 boto3 工作階段簽署。

5. 執行三個示範

每個示範展示探索流程的不同形式。

示範 1：訂單狀態（僅 MCP）

一個會對應至單一 MCP 工具呼叫的請求。

result = invoke_orchestrator(
    "What is the current status and tracking info for order 123?",
    agentcore_client, orchestrator_arn,
)

Registry 傳回訂單管理 MCP 伺服器。協調器透過 Gateway 呼叫 get_order_status，LLM 綜合生成易於理解的回應，然後內層代理終止。這一輪不涉及 A2A。

示範 2：定價及折扣（MCP + A2A）

一個會對應至多協定鏈的請求。

result = invoke_orchestrator(
    "Order 123 has 2x Widget Pro at $99.98. What discount tiers or "
    "promo codes can reduce the price?",
    agentcore_client, orchestrator_arn,
)

Registry 傳回訂單管理 MCP 伺服器及定價 A2A 代理：兩種協定，一個自然語言查詢。LLM 先呼叫 get_order_status 取得明細項目，再於執行階段呼叫定價代理進行折扣分析，最後綜合生成單一建議。

示範 3：退貨及退款（語意匹配）

一個意圖並未直接出現在任何工具名稱中的請求。

result = invoke_orchestrator(
    "I want to return order 789 (Premium Headphones, delivered "
    "March 10). Am I eligible for a return and what is the refund "
    "amount?",
    agentcore_client, orchestrator_arn,
)

這個示範展示了語義探索的價值。「退貨退款」一詞並未出現在 Customer Support Agent 的註冊名稱中。混合式搜尋會將它排在較前位置，因為該 Agent 的描述涵蓋了這個意圖。若沒有 Registry，協調器便需要硬編碼哪些 Agent 負責處理退貨的知識。

6. 可觀測性

在適當情況下，使用 Amazon Bedrock AgentCore Observability 和 Amazon CloudWatch，為探索及呼叫流程加入監測。實用的訊號包括 Registry 搜尋成功或失敗、所選記錄的識別碼、用戶端建構錯誤、下游呼叫結果、端到端追蹤關聯，以及應用程式錯誤。範例授予 Amazon CloudWatch Logs 權限，但不會建立自訂指標或儀錶板。正式環境團隊應按其營運模式定義所需的追蹤、日誌及警示。正式環境部署亦應將 Amazon Bedrock Guardrails 用作 Agent 回應的標準控制措施。

受治理的執行階段探索可為團隊帶來甚麼

建立探索流程後，以往與協調器版本發佈綁定的多項功能便可獨立運作。

  • 解耦發佈流程。各團隊可以部署並註冊自己的 MCP 伺服器、Agent 和技能。審批政策決定已發佈記錄何時可供使用者使用。
  • 新增已批准記錄時無須更改協調器程式碼。採用此模式時，新增相容且已批准的 Registry 記錄，無須在協調器加入專用於特定工具的匯入項目或端點。若要更改通訊協定、身份驗證設定或協調政策，仍可能需要更新程式碼或設定。
  • 受治理的探索。採用人工審批時，只有經審查及批准的記錄才可供探索。IAM 權限可將記錄發佈者與審批者分開。
  • 身份驗證分開處理。Registry 授權可使用 IAM 或自訂 JWT。能力呼叫的身份驗證則獨立處理：範例對 Gateway 使用 Cognito OAuth，對 AgentCore 執行階段使用 Boto3/IAM 簽署。搜尋結果不會傳回這些憑證。
  • 以目錄搜尋取代將內容塞入提示詞。透過 Registry 混合式搜尋，協調器只會擷取少量候選項，而非將整個目錄放進模型上下文。搜尋品質取決於描述、描述檔品質、查詢設計及評估。

何時不應使用執行階段探索

並非所有工作負載都需要執行階段探索。以下兩種模式仍可能較適合在建置時明確配置：

  • 規模小而穩定的目錄。如果完整的能力清單規模小而且甚少變動，在建置時明確配置可能更簡單，亦可避免額外的探索請求。
  • 固定流程。如果同一組能力總是按固定次序執行，將其實作為確定性流程會更直接，亦可讓追蹤更聚焦。

結論

在執行階段從 Registry 探索資產，可減少協調器對固定目錄的依賴。透過 AWS Agent Registry，協調器可使用語義與關鍵字混合式搜尋，搜尋已批准的能力、解析 MCP 或 A2A 描述檔，並建立每個請求專用的用戶端。治理機制決定哪些內容可供探索。Registry 及每項被呼叫的能力仍須分別明確處理身份驗證。

AWS Agent Registry 已正式推出，其功能不止於這個單一帳戶範例：

  • 全組織探索和跨帳戶分享可透過支援的AWS Organizations和分享機制，讓受管治記錄跨越帳戶邊界供人存取。
  • 自動能力同步可從網址填入支援的描述資訊。該同步請求中的憑證提供者設定用於擷取描述資訊內容，不會以呼叫驗證資料的形式傳回執行階段用戶端。
  • 審批工作流程可使用 Registry 狀態 API 和 IAM 權限，將 CI 檢查、安全審查或人工核准連繫至 DRAFT → PENDING_APPROVAL → APPROVED 生命週期。
  • 標籤、AWS CloudFormation 支援和基礎架構即程式碼模式，可讓 Registry 的部署和管治流程得以重複執行。評估時應確認搜尋相關性和呼叫行為符合組織自身目錄的要求。

執行執行階段探索範例，然後註冊一個兼容的 MCP 伺服器或自己的 Agent。確認其描述資訊、審批狀態、驗證途徑和搜尋行為符合生產環境的要求。

瞭解更多

作者簡介

Vibhu Pareek

Vibhu Pareek

Vibhu 是 AWS 的資深解決方案架構師。自 2016 年起，他一直透過架構完善且可重複使用的模式，指導客戶採用雲端技術。憑藉在資料庫、數據分析和 AI 方面的專長，他熱衷於將複雜挑戰轉化為創新解決方案。工作以外，他喜歡短途遠足，以及羽毛球、足球和游泳等運動。

Shubham Gupta

Shubham Gupta

Shubham 是 AWS 的解決方案架構師，常駐印度班加羅爾，為獨立軟件供應商（ISVs）提供支援。他與工程和領導團隊合作，協助他們在 AWS 上設計、構建和運行產品，從初步架構到投入生產，並專注於生成式 AI 和大規模韌性。工作以外，Shubham 熱愛遠足，並將行山時所需的準備和毅力，同樣應用於構建經久耐用的系統。

來源：AWS Machine Learning Blog · aws.amazon.com

#教學/實踐#Agent#MCP/工具調用#部署/工程