AWS Agent Registry 執行時探索讓工具串接不再綁死於建置階段
AWS 於 10 月 20 日詳細介紹 AWS Agent Registry 的執行時探索，展示一種毋須將每項能力硬編碼至代理程式的方法。這種方式將工具選擇移至運行中的應用程式，由協調器（即統籌處理請求的代理程式）在選擇連接方式前搜尋目錄。這一轉變挑戰了許多團隊一直能輕鬆維護的架構，直至其工具目錄開始跨部門擴張。
核心較量在於建置時串接與執行時選擇。建置時串接讓開發人員清楚掌握可用能力的清單。執行時選擇則容許這份清單獨立變動，但亦令搜尋結果成為應用程式行為的一部分。問題在於，團隊能否在容許能力於協調器發布週期以外演進的同時，維持可預測的執行結果。
Anthropic 亦一直推廣按需載入工具，令這個 AWS 範例具備容易辨識的業界參照。AWS 將討論帶入企業目錄管理的範疇；除了模型上下文外，批准、擁有權、連接詳情及存取規則同樣重要。對開發人員和企業買家而言，關鍵改變在於組織層面：工具是否可用，可能取決於目錄管治，而非另一次應用程式部署。
AWS Agent Registry 執行時探索改變連接選擇的時機
這份 執行時探索教學介紹了「Discover、Instantiate、Execute」循環。其範例將訂單管理伺服器連接至定價及客戶支援代理程式。這些均屬示範情境，而非來自經獨立評估的企業部署證據。
範例採用 MCP，即 Model Context Protocol，這是一項標準化協助應用程式向 AI 系統提供工具與上下文的協議。它亦採用 A2A，即用於代理程式之間通訊的代理程式對代理程式協議。將兩者納入同一探索循環，令此範例的意義不止於個別功能目錄。
架構上的改變是，協調器在收到請求後才選擇連接方式，而不是在建置時攜帶每一項連接。
這個分別值得比「探索」一詞本身更多關注。供開發人員查閱的目錄，有助人們在實作期間選擇整合方案。供執行期間查閱的目錄，則有助決定應用程式可就特定請求使用哪些整合。
這亦改變新增能力的意義。在明確串接的模式下，開發人員通常會在發布協調器前決定整合應放置的位置。在執行時選擇模式下，相容的能力可透過目錄進入考慮範圍。應用程式仍須制定規則，以解讀及使用其探索到的內容。
這項分別亦改變審查人員應檢視的內容。審查協調器的原始碼，不再必然揭示其完整的未來能力組合。有效的審查還必須考慮目錄、發布權限、批准慣例及相容性預期。
設想一個假設的企業助理，現時已能處理訂單查詢。支援團隊引入一個專門處理保養索償的服務。此架構的好處，是讓該專家服務可被探索，而毋須在統籌應用程式中再加入另一個具名整合。
這項好處取決於相容性。新發布而採用陌生連接方式的服務，仍然會帶來整合工作。執行時探索只是將部分決定延後，並不會令所有可能的服務即時可用。
因此，重要界線在於應用程式所支援的連接合約。開發人員可以容許該合約範圍內的新能力，同時保留對協議、存取方式及執行政策的控制。這比宣稱通用的即插即用整合更收窄，亦更有用。
對正在評估 AWS Agent Registry 執行時探索的讀者而言，第一個問題應是該架構實際解耦了哪些變更。新增一項相容能力，與改變能力運行所依循的規則，是兩回事。
平台團隊承接目錄發布的難題
AWS 將其受管治能力目錄描述為設有發布及批准工作流程的受管理探索服務。其文件區分發布者、策展人及使用者。這些角色突顯一項重要的組織影響：能力探索需要持續的擁有權。
執行時選擇將協調工作，從個別整合發布轉移至目錄發布、審查及維護。
平台工程師承受最直接的壓力。採用建置時串接時，應用程式儲存庫提供一個明確的協調點。面對持續變動的目錄，他們需要另一套方法，定義哪些能力應歸屬一起，以及哪些變更需要更廣泛的審查。
能力擁有者面對不同責任。若使用者無法理解何時應選擇某個端點，單有可運作的端點並不足夠。擁有者應清楚說明預期任務、重要排除情況、預期輸入及營運限制，讓另一支團隊能評估該連接。
這近似維護團隊之間的共享介面。描述承載意義，連接合約則決定軟件實際可做甚麼。兩者任何一環薄弱，都可能造成統籌代理程式無法可靠解決的混亂。
批准亦需要具體目的。組織或會在接納能力前審查其安全狀況、擁有權、支援承諾或相容性。這些檢查回答不同問題，因此「已批准」標籤不應成為所有可能保證的代稱。
一項已獲批准的服務，對特定使用者請求而言仍可能不適合。生產報表工具或與主題相關，但未必可供提出請求的僱員使用。支援能力或能解釋政策，卻未必有權更改訂單。
對企業買家而言，這意味著採購討論應更具體。應詢問誰維護目錄記錄、誰批准變更，以及已發布能力無法使用時由誰回應。受管理探索服務本身無法分配這些內部責任。
同樣的區分亦適用於組織知識。團隊需要一個共享位置，儲存決策、例外情況及操作程序，並與機器可讀記錄並行。一個可搜尋的知識庫可滿足這類文件需要，而 registry 則負責執行時探索。
壓力並不只是要將一切集中化。過於廣泛的目錄可能難以管治，而過度分隔的狹窄目錄則可能保留探索原應減少的協調問題。團隊應根據實際擁有權及使用模式劃定界線。
一項有用的進度指標，應是發布之間的依賴關係有所減少。若每項新能力仍須修改協調器、進行協調批准及手動更新使用者，組織便只是獲得一個目錄，卻未真正實現多少架構自主性。
反過來說，獨立發布不應代表看不見的行為改變。使用者需要有方法了解哪些能力已進入其應用程式可觸及的範圍。當擁有權及變更溝通仍然清晰時，營運自主性才能發揮最佳效果。
這個循環分開尋找、連接與行動
將每個階段視為獨立決策後，AWS Agent Registry 執行時探索背後的機制便更清晰。尋找相關能力、建立連接，以及決定採取何種行動，雖然互有關連，卻需要不同證據和控制措施。
AWS 文件介紹混合 registry 搜尋，結合按意義進行的語義配對與關鍵字配對。名稱、描述及協議描述符都會影響相關性。描述符是描述某項能力及其連接詳情的結構化中繼資料。
搜尋文件亦指出，可被探索的結果僅限於已獲批准的記錄。搜尋索引採用最終一致性，意味著已獲批准的變更不會即時在所有地方可見。這些特性令探索既是一種管治機制，亦是一項持續變動的執行時依賴。
搜尋可縮小候選集合；應用程式仍須建立有效連接，並選擇適當行動。
在 AWS 的範例中，探索會回傳不含調用憑證的連接中繼資料；調用憑證是呼叫能力所需的驗證資料。應用程式會另外取得憑證，然後從已探索的能力組裝臨時內部代理程式，並在請求完成後釋放其用戶端。
這種分隔十分重要，因為相關性不等於權限。一項服務可與某個請求極為匹配，卻仍可能無法供應用程式存取。相反，應用程式亦可能持有某服務的有效憑證，但該服務不應處理目前任務。
因此，實例化階段——即應用程式建立相關用戶端的階段——應被視為整合邊界。軟件必須解讀描述符、辨識連接類型，並套用既定的驗證路徑。搜尋結果不能取代這些檢查。
執行階段引入另一道界線。選擇支援能力，並不能決定應用程式應檢索資訊、提出變更建議，還是實際執行該變更。組織應在執行政策中界定這些分別，而不應期望檢索相關性能夠表達它們。
假設的退款請求可說明這個分別。探索可能識別出政策專家及訂單資訊服務。應用程式仍須確認客戶身分、檢索正確交易，並區分資格建議與獲授權發出退款。
這種架構具吸引力，因為它可縮小模型針對請求所見的範圍。但它亦建立上游依賴：正確能力必須先進入候選集合，模型才可選擇它。有能力的模型無法選擇它從未收到的整合。
這表示應分別評估各個階段。缺少候選項是探索問題。被拒絕的連接是驗證或相容性問題。成功連接後採取不恰當行動，則是執行問題。將它們混合為單一失敗類別，會令改善工作更難鎖定目標。
這個循環亦釐清快取（即重用先前結果）何時成為政策選擇。重用探索結果或可減少重複工作，但團隊應決定資料新鮮度及能力撤回會如何影響該選擇。適當平衡取決於應用程式帶來的後果。
Anthropic 的工具搜尋展示更廣泛的架構轉變
AWS 正在處理一個超越雲端目錄管理的問題。Anthropic 的按需工具搜尋描述了延後提供工具定義，直至其變得相關為止。核心概念是避免將完整的能力庫放入模型的上下文，即模型在生成內容時可取得的資訊。
Anthropic 已公開的方法會將選定的定義標記為延後載入。Claude 其後可搜尋相關工具，並在需要時取得其定義。這有助理解 AWS 的方向，但不應將兩者視為可互換的產品。
共同的設計原則是選擇性揭露，而整合責任則仍然因應各系統而有所不同。
這個比較有助將底層架構選擇與供應商定位分開看待。團隊可以同意預先載入所有工具會造成浪費，同時仍傾向為最重要的工作流程建立明確連接。選擇性揭露並不代表必須讓每個應用程式決策都變成動態。
這個比較亦可避免誇大新穎性的說法。執行時期探索屬於管理日益龐大的能力庫這項更廣泛工作的其中一環。AWS 的例子提供了一種具體的企業模式，而非證明業界只是現在才發現這個問題。
對平台團隊而言，相關問題是目錄決策應歸屬於何處。有些應用程式需要一個由中央管治、涵蓋獨立維護能力的目錄。另一些應用程式主要需要避免既有工具庫壓倒模型可用的上下文。
這些需求有所重疊，但並不相同。較小的提示內容並不會自動提供審批工作流程。受管治的目錄亦不會自動決定某個模型或任務的最佳選擇策略。
支持明確連接的最有力論點亦值得公平聆聽。當工作流程具有穩定順序及有限的能力集合時，開發人員可以直接檢視預期的連接。執行時期檢索必須帶來明確效益，才足以合理化增加一個決策點。
假設的排程核對流程正可說明這種情況。若應用程式總是擷取記錄、比較記錄，並寫入已核准的報告，每次搜尋這些相同能力的價值可能不大。流程本身已表達業務需求。
通用助理面對的是不同情況。其請求可橫跨互不相關的任務，而可用能力可能屬於各自獨立變更的團隊。當維護完整而明確的清單會帶來持續協調工作時，執行時期選擇便更具說服力。
這提出一項實務評估原則：應以相同任務及變更情境比較架構。當中應包括日常執行、能力新增、故障及復原。一個有說服力的示範應展示動態選擇在哪些地方有幫助，而非假設彈性本身必然具價值。
買家亦不應只按目錄規模評估架構。更有意義的問題是，隨目錄變更時，有用的能力是否仍然可被發現並正確套用。即使能力清單令人印象深刻，若一般請求仍需手動路由，其價值也有限。
探索質素需要獨立的生產環境證據
最重要的不確定因素涉及示範以外的行為。AWS 的導覽展示了該循環，但未能證明特定企業目錄的表現。生產環境的主張應依據具代表性的評估，而非架構圖。
discovery API會傳回按相關性排序的相符中繼資料，並支援結構化篩選。這使候選集合成為可觀察的應用程式輸出。團隊可先檢視探索傳回甚麼，再調查模型之後採取了甚麼行動。
生產環境評估應衡量探索是否提供所需能力，包括不應使用任何能力的請求。
首先要區分看似合理與實際足夠的結果。帳單專員看來可能與訂單問題相關，但未必具備回答問題所需的送貨資訊。評估人員應識別完成工作所需的能力，而非接受任何描述相關的結果。
含糊的請求尤其值得注意。使用者要求「修正我的訂單」，可能是想更改地址、修正收費，或報告貨品損壞。安全的應用程式應在需要澄清時作出辨識，而不是把強烈的搜尋相符結果當作已確定的意圖。
負面案例同樣重要。有些請求不應建立任何連接，因為目錄沒有合適能力。另一些則應停止處理，原因是使用者沒有權限，或所要求的操作超出應用程式範圍。
目錄增長應成為明確的測試條件。團隊可以在新增重疊能力、修訂描述或淘汰服務後重複相同評估。這可揭示即使協調器的原始碼保持不變，日常維護變更會否令請求採用不同路由。
描述質素亦應受到評估，同時避免鼓勵宣傳式語言。發布者有動機讓其能力更容易被發現。審核者應偏向準確說明範圍及排除事項，而非聲稱某項服務可處理所有相鄰任務的描述。
探索與驗證的分離帶來有用的故障案例可供測試。相關能力可能使用了已過期的憑證、端點不可用，或回應格式不相容。應用程式應說明限制，而不是悄悄改用較不合適的操作。
復原同樣值得嚴格審視。重試資訊查詢與重試會變更業務記錄的請求有所不同。團隊應在容許自動復原再次發出操作前，確認該操作是否可以安全地重複執行。
營運證據應把請求、所選能力及最終結果連繫起來。否則，流暢的回答可能掩蓋查詢失敗、非預期的後備處理，或從未完成的操作。審核者需要有關執行狀況以及回應質素的證據。
評估失敗時亦涉及責任歸屬問題。負責方可能是能力發布者、目錄策展人，或應用程式團隊。及早界定這些責任，將使跨部門運作執行時期選擇更容易。
就 AWS Agent Registry 執行時期探索而言，可站得住腳的承諾是在既定界線內提供架構彈性。更佳準確度、更低營運開銷及更易維護，仍是每個部署都應自行佐證的成果。
留意遷移、目錄增長及獨立發布
眼前的觀察點很具體。AWS 的registry 遷移指南指出，專用的 agent-registry 命名空間於 2026 年 8 月 6 日推出。命名空間是跨介面及設定使用的服務識別碼。對預覽版 bedrock-agentcore registry 命名空間的支援將於 10 月 30 日結束。
該指南描述了影響服務端點、權限、用戶端、資源識別碼及相關設定的變更。指南指出，其他 AgentCore 服務不受此 registry 命名空間變更影響。因此，對現有預覽版使用者而言，遷移是短期營運上的關注事項。
下一步證據應展示遷移完成、目錄增長下穩定的探索，以及毋須不必要協調器變更的能力新增。
首先，留意預覽版使用者是否完成遷移並驗證其探索路徑。成功更新設定後，應有證據顯示預期的應用程式仍可尋找並呼叫已核准能力。這將增強對營運連續性的信心。
遷移失敗本身不會否定執行時期選擇。然而，這會揭示依賴持續變更的受管服務介面所帶來的維護要求。團隊應分辨服務遷移問題與搜尋或執行設計的缺點。
第二，留意是否有評估在保持請求集合不變的同時擴大目錄。有用的訊號是，即使重疊及含糊情況增加，系統仍持續發現必要能力。若只報告成功案例，核心的擴展問題便仍未有答案。
選擇表現惡化的證據，將削弱在沒有額外控制措施下廣泛部署的理據。這表示描述標準、目錄界線、篩選機制或評估方式需要修訂。目錄擴展應視為值得測試的行為變更。
第三，留意獨立團隊能否在毋須經常修改協調器的情況下發布相容能力。這是將連接移出建置流程所暗示的組織效益。最有力的證據應包括上線流程、驗證設定、責任歸屬及撤回機制，而非只包括發布本身。
如果新增能力一再需要在協調應用程式內作特別處理，該架構提供的獨立性便會少於圖表所顯示。若團隊能在維持可預測行為的同時新增能力，執行時期探索便帶來了可量度的發布協調改變。
這些訊號比對自主代理的廣泛預測更重要。它們將設計與可觀察的工程成果連結起來：遷移期間的連續性、增長期間可靠的選擇，以及能力變更時減少協調。
作為初步評估，請選擇一個能力擁有權已橫跨不同團隊的有限工作流程。在引入 AWS Agent Registry 執行時期探索前，先確立目前的發布依賴關係及故障行為。清楚列出具代表性的請求、預期能力及不可接受的操作。比較一般請求與含糊問題、缺失服務及拒絕存取。然後引入一項相容能力，並檢視發布、審批、驗證、探索及執行各環節實際有何改變。將發現與技術決策一併保留，讓日後維護人員理解其中界線。在擴大目錄前，請問自己：應用程式是否在仍然讓負責其行為的人可以理解的前提下，變得更容易擴展。
