目錄
過去兩年，AI Agent 的討論大多集中在怎麼把東西接起來，MCP Server、Tools、Skills、Agent Framework 一個接一個出現，先把流程跑起來通常比後面的管理問題更急。等同一家公司裡開始出現幾十個、幾百個 Agent 之後，麻煩也跟著換了一批：某個功能是不是早就有人做過、現在這個 Agent 到底誰負責、哪些工具已經沒人在維護，以及一個看起來能用的 MCP Server 到底有沒有通過內部審查。
2026 年 8 月 31 日，AWS Agent Registry 正式進入 General Availability。它不負責讓模型推理更強，也不是另一套 Agent Builder，而是一個集中式的目錄與 Discovery Layer，把組織裡的 Agents、MCP Servers、Agent Skills 與其他自訂資源整理成可以搜尋、審核與管理的 Registry。AWS 自己對問題的描述也很直接：Agent 系統從少數 Tools 長到數百個之後，真正的瓶頸開始變成「Finding what already exists and trusting what you find」。
這類產品看起來沒有新模型發表那麼熱鬧，卻很能反映 Agent 進入正式工作環境後會遇到什麼問題。能不能接 MCP 已經不是唯一難題，接完之後有哪些東西、誰在使用、哪個版本還有效，以及什麼資源可以被其他 Agent 找到，開始變成另一層工作。
對只有幾個 Automation 的工作室來說，AWS Agent Registry 當然太重，但背後的邏輯其實很早就會出現。Agent 數量還只有三個、五個時沒有整理，看起來完全沒差；等工具換過幾輪、OAuth 權限愈接愈多，半年後最先忘掉的通常不是 Prompt，而是哪一個流程現在到底還有沒有在跑。
AWS Agent Registry從Preview到GA，解決的是什麼問題？
AWS Agent Registry 在 2026 年 4 月 9 日先以 Preview 推出，8 月 31 日正式 GA，中間大約 4 個月又 3 週。Preview 時就已經具備核心功能，包括集中登錄、Semantic＋Keyword Search、Approval Workflow、URL-based Discovery、MCP Endpoint 與 CloudTrail 整合；GA 則補上 Infrastructure as Code、Tags、AWS RAM 跨帳號分享、AgentCore 資源自動偵測，以及 Amazon Quick、Kiro 等更多使用入口。
這個時間線比「AWS 很快就把一個 Preview 產品轉正」更值得看的，是 Preview 和 GA 之間新增的能力幾乎都在處理企業真正部署後才會遇到的問題：怎麼跨 Account 共用、怎麼用 IaC 管理、怎麼分類與成本歸屬、怎麼把沒有主動登錄的 Agent 找出來。
也就是說，Registry 的問題從第一天就不是「Agent 做不做得出來」，而是做出來之後有沒有一份可靠的 Inventory。
企業大量導入AI Agent後，最常遇到哪三個管理問題？
AWS 在 GA 文章裡把問題整理得很簡單。第一個是沒有集中 Inventory，不知道組織裡到底有哪些 Agent、Tools 與 Skills，也不知道 Owner 是誰；第二個是缺乏跨團隊 Discovery，同一項能力明明已經存在，其他團隊找不到，只好再做一次；第三個則是 Governance 與 Audit Trail 不完整，碰到安全審查、版本問題或故障時，很難快速追到是哪一個資源、哪個版本與哪個 Owner。
這三個問題最後會一起變成技術債。重複 Agent 不只是浪費第一次開發時間，後面還會各自產生 Authentication、Monitoring、Prompt、Tool Schema 與維護成本；如果其中一套早就沒人負責，卻還留在工作環境裡，風險又會再多一層。
AWS Agent Registry有哪些功能？搜尋、審核與MCP一次看
Registry可以登錄哪些東西？
AWS Agent Registry 目前正式的頂層 recordType 有四種：AGENT、MCP、SKILL 與 CUSTOM。Agent Record 可以使用 A2A Agent Card 描述 Agent 與 Skills；MCP Record 保存 MCP Server 定義，並可以一起收錄該 Server 提供的 Tool Definitions；Skill 則可以保存 Agent Skill Definition；其他組織自己想管理的內容，可以用 Custom JSON Metadata 處理。
所以「Agent、Tool、Skill、MCP Server 都可以放進 Registry」作為產品概念沒有問題，但技術上 Tool 並不是第五種獨立 Record Type，而是通常收在 MCP Server Record 的 Tool Definitions 裡。這個差別在真的用 API、CLI 或 IaC 建 Registry 時就會碰到。
除了手動建立 Record，Registry 也能指向現有的 MCP 或 A2A Endpoint，再從線上 Endpoint 抓取 Server Definition、Tool Schema 與 Capability Metadata。之後來源有變動時也可以重新 Sync，不必每一次都手動重寫 Catalog Entry。
Semantic Search和Keyword Search會一起跑
Registry 的搜尋不是只有名稱比對。SearchDiscoverableRegistryRecords 會同時執行 Semantic Search 與 Keyword Search，再把結果合併排序，所以可以搜尋精確名稱，也可以直接用自然語言描述需求，例如「找一個可以處理 Ticket Routing 的工具」。MCP Server 裡的 Tool Name、Description、Input Parameter 與 Capability Summary 也會進入 Semantic Matching。
這件事在 Agent 數量增加之後比想像中重要。如果所有人都必須先知道某個工具叫什麼才能找到它，那其實只是一張比較漂亮的 Excel；真正的 Discovery 必須容許使用者只知道「現在需要做什麼」，還不知道公司內部已經有人把那個能力取成什麼名字。
Approval是可設定的，但只有Approved Records會進入Discovery
原稿寫成「紀錄需要管理員核准才會被搜尋」，方向接近，但要再精確一點。Registry 可以設定 Manual Approval，也可以使用 auto_approve；真正固定的是 Discovery Plane 只會讓最新 Revision 狀態為 APPROVED 的 Record 被一般 Search、Browse 與 MCP Discovery 找到，Draft、Pending Approval、Rejected、Deprecated 都不會出現在正常的 Consumer Search 裡。
Record 一旦更新，也會重新回到 Draft，再走一次原本設定的 Lifecycle。這比單純「登記之後永久有效」更合理，因為 Tool Version、Endpoint 或能力變了之後，舊 Approval 不一定還適用。
CloudTrail有稽核能力，但不是所有事件都預設完整保存
AWS Agent Registry 和 CloudTrail 有正式整合。Registry 的 Create、Update 等 Management Events 會預設進 CloudTrail Event History，保留 90 天；如果還要記錄 Discovery 等 Data Events，則需要另外建立或修改 Trail，再加入 Agent Registry 的 Data Event Selector。
因此，比較準確的說法不是「所有 Registry 存取天生全部完整寫進 CloudTrail」，而是 Registry 支援完整的 CloudTrail Audit 架構，Management Events 預設可追蹤，Data Events 則要依需求另外啟用。
Registry本身也提供MCP Endpoint
這是 Agent Registry 最有意思的一層。每一個 Registry 都能提供 MCP-compatible Endpoint，MCP Client 可以直接呼叫 search_discoverable_registry_records、list_discoverable_registry_records 與 batch_get_discoverable_registry_record。所以 Registry 不只給管理員在 Console 裡查，IDE 或 Agent 本身也可以把它當成 Discovery Tool，先找出有哪些已核准資源，再決定後面該接哪一個 Tool 或 Agent。
AWS GA 文章甚至直接把 Consumers 定義成 Developers、Business Users 或 Autonomous Agents。也就是說，「Agent 自己查 Registry 找工具」不是延伸想像，而是產品明確支援的使用方式。
但 Registry 回傳 Endpoint 與 Authentication Information，不代表搜尋者自動取得底層工具權限。後續真正呼叫 Agent 或 MCP Server，仍然要依各資源自己的 Onboarding 與 Credentials 完成授權。
GA版比Preview多了哪些企業管理能力？
GA 之後，Registry 可以透過 AWS CloudFormation、Terraform 與 AWS CDK 以 Infrastructure as Code 建立與管理，不需要把 Registry 設定只留在 Console；Registries 和 Records 也能加 Tags，用於組織、Cost Allocation 與 Access Control。
AWS RAM 則讓 Registry 能跨 AWS Accounts 分享，企業可以建立 Organization-wide Registry，而不是每個 Account 各自維護一份互相看不到的 Catalog。另外，GA 也增加對整個 AWS Organization 裡 AgentCore Runtime 與 AgentCore Gateway 資源的 Auto-detection，新部署的 Agent 或 MCP Endpoint 可以先被發現成 Draft Record，再進入 Review／Approval 流程。
這一段要特別注意現在與 roadmap 的界線。目前 GA 可以自動偵測的是 AgentCore Runtime 與 AgentCore Gateway；AWS GA Blog 提到未來還想擴大到 EC2、EKS、ECS 等其他環境，甚至透過 Federation 看見非 AWS 資源，但這些屬於後續方向，不能寫成現在已經全面支援。
使用入口也變多。Registry Resources 現在可以從 Amazon Bedrock AgentCore、Amazon Quick 和 Kiro 發現；Quick 甚至可以直接搜尋組織 Registry 裡已核准的 Agent 與 MCP Server，再啟用給 Chat、Agents、Apps、Flows 或 Deep Research 使用。
AI Agent為什麼開始需要Registry？
MCP 普及之後，一個外部工具要接進 Agent 的方式比過去統一很多，REST API、資料庫或內部服務可以透過 MCP Server 包成模型能理解的 Tools。這確實降低了 Integration Friction，但不能直接寫成「接入成本幾乎變成零」，因為 Authentication、Permission、Schema、Deployment、Observability 與 Runtime Maintenance 都還在。
真正變化是接入變容易之後，建立 Tool 的門檻下降了，組織裡更容易同時存在大量類似能力。如果沒有一個地方可以先搜尋，很自然就會出現 Shadow Agents、重複 MCP Servers 與沒人知道誰在維護的 Tools。AWS 自己也把「Teams build in isolation」與「rebuild what already exists」列成 Registry 要處理的核心問題。
這個發展其實和過去軟體工程很像。Package 數量增加後需要 Package Registry，Container Image 多了需要 Image Registry，API 數量大之後會需要 Catalog、Gateway 與 Governance。Agent 和 MCP Tool 開始進入正式環境之後，再多一個 Registry 並不奇怪，只是輪到 AI 工具進入同樣的資產管理階段。
同一天AWS還在談Observability與Multi-tenant Isolation，代表什麼？
8 月 31 日 AWS Machine Learning Blog 同時出現多篇和 Production Agentic Systems 有關的文章，包括可觀測的 Agentic Retrieval，以及在 Managed Bedrock Knowledge Base 上建立 Multi-tenant Data Isolation；另外也有把 AgentCore Runtime 上的 MCP Server 接進 Amazon Quick 的實作。
這些文章放在同一天確實很容易看到一個共同主題：Agent 做得出來之後，接下來開始處理 Retrieval 能不能追蹤、不同 Tenant 資料會不會混在一起，以及既有 Tool 能不能重複利用。不過，這是從 AWS 同期內容整理出的產品觀察，不需要寫成 AWS 官方宣布「Agent 時代已經從建置進入收拾期」。
比較穩妥的說法是，2026 年的 Agent 基礎設施已經明顯增加治理、可觀測性、隔離與 Discovery 這類 Production Concern。
AWS拿下Forrester AI Infrastructure Leader，和Agent Registry有直接關係嗎？
8 月 31 日，AWS 也宣布自己在《The Forrester Wave: AI Infrastructure Solutions, Q4 2025》13 家供應商評比中被列為 Leader，並在 Strategy Category 得到最高分。
這可以當成 AWS 同期強調 AI Infrastructure 的背景，但不能直接拿來證明「Agent Registry 讓 AWS 成為 Leader」，因為該 Forrester 評估範圍更廣，包含 Training、Fine-tuning、Inference Infrastructure 與整體策略，而且評比期本身也是 Q4 2025，早於 Agent Registry 2026 年公開 Preview。
同樣地，「模型能力會愈來愈同質化，所以治理才是雲端廠商真正護城河」比較適合當市場推論，不是這幾篇 AWS 文件能直接證明的結論。現在能確定的是，雲端平台的競爭早就不只模型本身，Agent Runtime、Identity、Gateway、Evaluation、Registry、Observability 與 Governance 都已經成為產品的一部分。
AWS Agent Registry導入前，要注意哪兩個治理風險？
Registry的Metadata本身也可能暴露內部架構
AWS 自己在 Enterprise Considerations 裡特別提醒，不應該讓「可以搜尋 Resource」與「可以登錄新 Resource」使用完全相同的 Permission。Tool Metadata 可能包含 Internal Endpoint 或 Architecture Details，這些資訊對攻擊者本身就有價值，因此需要評估哪些 Metadata 可以放進廣泛可搜尋的 Registry、哪些應該留在更緊的 Access Boundary。AWS 也建議 Audit 誰正在查 Registry，以及查詢頻率。
所以建立 Registry 並不是把全部架構資訊集中起來、再讓全公司任意搜尋。Catalog 本身也需要 Data Classification 與 IAM Boundary。
被收錄不等於安全，也不等於已完成Security Review
另一個需要特別修正的地方，是 AWS Agent Registry 目前沒有內建完成所有 Security Scan、Duplicate Detection 和 Compliance Assessment。
AWS 現在提供 Record Lifecycle、Approval States、EventBridge Hooks 與 Approval API，讓企業把自己的審核流程接進來。AWS 在 GA Blog 給的最低建議是：發布前先檢查是否已存在類似資源、替 Agent／Tool／Skill 做 Security Scan，最後再由真人 Approver 確認 Metadata 是否完整、Description 對非原開發團隊的人是否看得懂，以及這項資源到底該不該進 Registry。簡單的 CI/CD Checklist 或 Slack Approval Flow 一開始就可以使用。
Security／Vulnerability Assessments、Compliance Evaluations 與 De-duplication Analysis 未來會更直接出現在 Approval Workflow 裡，但 AWS 把這些明確寫在 What's next，目前仍屬 Roadmap。
所以「Approved」真正代表的是通過組織自己設定的 Approval Bar，不是 AWS 已替這個 Agent 做完全面安全認證。
企業真的需要Agent Registry之前，可以先做哪些事？
第一步通常不是立刻採購 Registry，而是先知道目前已經有什麼。Agent、Automation、MCP Server、Skill 與重要 Integration 可以先列成一份 Inventory，至少記名稱、用途、Owner、目前環境、存取哪些資料、是否具有 Write Permission、最後一次驗證日期與目前狀態。只有這張表做完，通常就能先找出一批重複或沒人維護的東西。
第二步是建立很薄的發布門檻。工具第一次準備給其他人使用時，確認有沒有同類能力、Authentication 和 Permission 是否合理、誰負責維護，以及出問題時能不能停掉。團隊還小時不需要設計十層 Approval，一張 Checklist 加一名 Reviewer 已經比完全沒有治理好很多。
第三步則是把 Lifecycle 補完整。Agent 建出來不應該只有「存在」一種狀態，可以至少分成 Draft、Active、Deprecated 或 Retired，並留下 Replacement Link。AWS Agent Registry 本身也採取類似 Lifecycle，Approved Record 後續如果不再需要，可以被 Curator 標成 Deprecated。
個人創作者或小型工作室需要AWS Agent Registry嗎？
大多數情況不需要。如果手上只有幾個 Agent 和 Automation，為了管理它們另外建 AWS Registry 只會讓系統更複雜。但 Registry 想解決的幾個問題，在小規模環境一樣很快會出現：流程名字記不得、OAuth 授權留了一堆、同一件事情做過兩個版本、不知道哪一個還在跑，以及某個 Automation 壞掉後才發現原本的 Tool 已經停用幾個月。
比較簡單的方式，是在現有知識工具裡留一張「Automation／Agent Registry」：
| 欄位 | 建議記錄 |
| 名稱 | Agent、Automation或MCP名稱 |
| 用途 | 一句話說明實際解決什麼 |
| Owner | 目前由誰維護 |
| Trigger | 手動、排程、Webhook或其他條件 |
| Tools／Connections | Gmail、Notion、Drive、Slack、GitHub等 |
| Access | Read-only／Write／Delete／Send等 |
| 成本 | 月費、Tokens、Credits或API成本 |
| Status | Draft／Active／Deprecated |
| 最後確認日期 | 最近一次真的跑成功的日期 |
| Replacement | 已停用時由哪個新流程取代 |
真正有用的不是把表格做得很漂亮，而是半年後看到一個陌生的 Integration 時，不需要先翻聊天紀錄確認它到底是什麼。
如果只有三個 Automation，這張表可能一個月都不會打開；等到接過十幾個 Tools、換過幾輪 Agent、OAuth 頁面已經列出一長串授權時，它的價值才會突然變得很明顯。
AWS Agent Registry真正透露的，是Agent開始進入資產管理階段
AWS Agent Registry 不會讓任何 Agent 回答得更準，也不會自動把一個不安全的 MCP Server變安全。它處理的是另一個很務實的問題：當 Agent、Tools 和 Skills 已經多到很難靠記憶管理時，需要有一個地方知道哪些東西存在、哪一些已經通過目前的使用門檻，以及負責的人到底是誰。
AWS 現在甚至讓 Agent 本身透過 MCP 搜尋 Registry，代表這個 Catalog 不只是給 IT 管理員看的資產清單，而可能直接成為 Agent Discovery 的一部分。
不過，Registry 本身並沒有替治理工作全部收尾。Security Scan、Duplicate Analysis、細粒度 Discovery Policy 與更多 Observability 能力，有些仍需要企業自行建，有些則還在 AWS Roadmap。這反而更貼近目前 Agent 生態的真實狀況：建 Agent 的工具已經很多，怎麼讓這些東西長期保持可找到、可理解、有人維護，還在補課。
對小型團隊來說，這個問題不需要等到有一千個 Agent 才開始處理。等到「這個流程現在到底還有沒有在跑」已經回答不出來時，其實就已經到了該留一份 Registry 的時候。
常見FAQs
AWS Agent Registry 是 AWS 在 Amazon Bedrock AgentCore 生態裡提供的集中式 Agent 目錄，用來登錄與管理組織內的 Agents、MCP Servers、Agent Skills 與其他自訂資源。它本身不負責建立 Agent，也不會讓模型能力變強，主要解決的是資源發現、重複建置、Owner 不明、版本管理與治理問題。Registry 支援 Keyword Search 與 Semantic Search，因此即使不知道工具的精確名稱，也能用自然語言描述需求來搜尋。
AWS Agent Registry 在 2026 年 4 月 9 日先以 Preview 推出，並於 2026 年 8 月 31 日正式 General Availability。GA 版本增加 Infrastructure as Code、Tags、AWS RAM 跨帳號分享，以及 AgentCore Runtime／Gateway 資源自動偵測等企業管理能力。Preview 到 GA 約四個月又三週，不是不到四個月。
因為問題正在從「能不能做出 Agent」轉成「Agent 做多之後怎麼管理」。當不同團隊可以快速建立 Agent、MCP Server 與 Skills，重複建置、Shadow Agent、Owner 不明、停用工具仍被沿用等問題就會逐漸出現。Registry 的價值不是增加 AI 能力，而是讓已有能力變得可找到、可理解、可管理，也比較容易知道哪些資源應該繼續維護、哪些已經可以下架。
不代表。Registry 解決的是 Discovery 與 Governance，不會自動替 Resource 保證品質。實際使用前仍應確認 Owner、版本、Authentication、Permission Scope、是否仍在維護，以及組織自己的 Security／Compliance Review 是否完成。尤其 Registry Metadata 本身可能包含 Endpoint 或架構資訊，因此「誰可以搜尋」與「誰可以建立或修改 Record」也應該分開設計權限。
多數情況不需要直接導入 AWS Agent Registry，但很值得採用同一套管理邏輯。如果手上已經有多個 Agent、Automation、MCP Server 或 OAuth Integration，可以先建立一份簡單的 Registry，至少記錄名稱、用途、Owner、Trigger、Tools／Connections、Read／Write 權限、成本、Status 與最後確認可用日期。真正需要整理的時間點通常不是 Agent 到一千個，而是已經開始回答不出「這個流程現在還有沒有在跑」。
Registry 已整合 AWS CloudTrail，但需要分 Management Events 與 Data Events 看。建立、更新等 Management Operations 會出現在 CloudTrail Event History；如果還希望記錄 Discovery、Search 等 Data Events，則需要另外建立或調整 Trail 並啟用對應的 Data Event Selector。因此不能簡化成「所有 Registry 行為預設都完整保存」，而是 AWS 已提供可以做到完整稽核的基礎。
支援。GA 版本加入 AWS Resource Access Manager，也就是 AWS RAM，可以把 Registry 分享給其他 AWS Accounts，企業因此能建立比較集中式的 Organization Registry，而不是要求每個 Account 都維護一份互相看不到的目錄。Registry 與 Records 也可以加入 Tags，用來做分類、成本分攤或搭配 Access Control。
MCP 解決的是「AI 怎麼用一致方式連接外部 Tools」，Agent Registry 解決的則是「當 MCP Servers 和 Agents 數量變多後，怎麼知道有哪些東西存在、哪些已經核准、由誰維護」。Registry 可以保存 MCP Server Definition 與 Tool Metadata，也能直接從既有 MCP Endpoint 同步相關資訊；Registry 自己同時又提供 MCP Endpoint，因此 MCP Client 可以反過來利用它搜尋組織內已核准的資源。兩者不是替代關係，而是不同層次的基礎設施。
可以。Agent Registry 本身提供 MCP-compatible Endpoint，MCP Client 可以搜尋、列出與讀取已核准的 Registry Records，因此除了開發者可以從 IDE 或其他工具搜尋 Registry，Agent 本身也可以把 Registry 當成 Discovery Layer，先查詢有哪些可用 Agent、MCP Server 或 Skill，再決定後續要使用哪一項資源。不過，能在 Registry 裡找到某個 Tool，不代表 Agent 自動取得底層系統權限，真正執行時仍然需要符合該服務自己的 Authentication 與 Access Control。
目前不能這樣理解。AWS Agent Registry 已提供 Approval Workflow、Record Lifecycle、EventBridge Hooks 與相關 API，企業可以把 Security Scan、Duplicate Check、Compliance Review 與人工審核接進自己的發布流程，但完整的 Automated Security Assessment 與 De-duplication Analysis 並不是目前 GA 已全部內建完成的能力。AWS 已把部分更自動化的 Security／Compliance／Dedup Signals 列入後續發展方向，因此 APPROVED 代表通過組織設定的審核門檻，不代表 AWS 已替該 Agent 做完全面安全認證。
不一定。Registry 可以採用 Manual Approval，也可以設定 Auto-approve。真正固定的規則是，一般 Discovery Plane 只會讓目前狀態為 APPROVED 的最新 Record Revision 被搜尋與發現；Draft、Pending Approval、Rejected 或 Deprecated 的紀錄不會出現在一般 Consumer Search 裡。Record 後續被修改時，也會重新進入 Lifecycle，而不是一次核准後永久維持相同狀態。
目前正式支援的頂層 Record Type 有四種：AGENT、MCP、SKILL 與 CUSTOM。其中 MCP Server 提供的 Tools 會放在 MCP Record 的 Tool Definitions 裡，因此雖然實際使用上可以搜尋與管理 MCP Tools，但 Tool 並不是獨立的第五種 Record Type。其他不符合前三種類型、但企業仍希望納入治理的資源，可以用 Custom Metadata 保存。