呢個做法喺工具數量少嘅時候冇問題，但一旦公司內部有幾百個 API（例如定價、訂單、庫存、客户資料），成個系統就開始崩潰。
問題喺邊？
每新增一個能力，都要改程式碼、重新部署、同多個團隊協調發布。而模型本身會喺「辨析工具名稱」上面花大量 token（語言模型處理單位），反而冇資源去理解用户真正想做嘅嘢。簡單講：工具越多，Agent 越痴。
AWS 喺 2026 年 10 月 20 日喺 Machine Learning Blog 發表嘅技術文章，就係針對呢個問題提出一個方案：喺運行時（runtime）動態發現工具，而唔係喺編譯時把成個目錄編碼入 Agent。
Discover → Instantiate → Execute
方案核心係一個三步循環，建喺 AWS Agent Registry（一箇管理式服務，用於為 Model Context Protocol (MCP) 伺服器、Agent 同 Agent 技能建立目錄同提供搜索）上面：
- Discover：Orchestrator（統籌 Agent）以自然語言向 Agent Registry 發送查詢。Registry 回傳記錄身份、名稱、描述、記錄類型、狀態、版本同協議描述符（例如 MCP 伺服器元資料或 A2A Agent Card）。重點：搜索結果唔包含調用憑證。
- Instantiate：Orchestrator 根據回傳嘅描述符類型，逐一建立客户端。MCP 描述符指向 Amazon Bedrock AgentCore Gateway 嘅 endpoint；Orchestrator 需另行透過 Cognito 獲取 OAuth 存取權杖，再用嚟建立 MCPClient。A2A 記錄則包含 Agent Card，URL 指向 AgentCore runtime endpoint，透過 boto3 數據面客户端簽名調用。Registry 只提供連接元資料，唔提供認證資料。
- Execute：用動態發現到嘅工具建立一個即棄式（ephemeral）內部 Agent，LLM 喺呢批工具入面揀選合適嘅執行，結果綜合後回傳用户。完成後，內部 Agent 同客户端即時拆除，下一個請求會重新搜索。
個範例包含乜？
AWS 提供一個 Python 範例，部署內容包括：一個訂單管理 MCP 伺服器（經 Amazon Bedrock AgentCore Gateway）、兩個運行喺 AgentCore runtime 嘅 A2A Agent、一個 Registry、以及一個 Orchestrator。目錄包含部署腳本、Orchestrator 程式碼、輔助模組同清理腳本。
阿調搞兩下
呢個設計嘅核心洞察其實唔新：將「工具發現」由部署時移去運行時，本質上就係個動態連結庫 vs 靜態連結庫嘅問題，只係搬去咗 Agent 層面。真正值得留意嘅係認證同授權係完全分離——Registry 只回傳「邊度」同「點樣識別」，唔回傳「點樣登入」。呢個設計避免咗 Registry 變成攻擊面，但亦意味部署者要自行確保「別條可信配置路徑」嘅安全性。AWS 冇公佈任何效能基準或生產環境採用數據，呢篇係架構説明，唔係產品發布。
