AWS Agent Registry：AI Agent 治理的「App Store 时刻」

2007 年，苹果推出 App Store，解决了一个看似简单的问题：「用户如何发现和安装 iPhone 上的应用？」

这个解决方案的副产品，是它建立了一套完整的软件分发权力结构：苹果控制哪些 App 可以上架（审批机制）、如何被发现（搜索算法和推荐）、遵守什么规则（开发者政策）。这套结构，影响了此后 20 年的移动软件生态。

2026 年 4 月 17 日，AWS 发布了 Amazon Bedrock AgentCore Agent Registry 的公开预览版。

这是一个集中式目录，用于发现、共享和治理企业内部的 AI Agent、工具和 MCP 服务器。支持跨云和本地部署的 Agent 索引，提供混合关键词+语义搜索，以及审批工作流（草稿→待审批→已发布）。目前在 5 个 AWS 区域可用，可作为 MCP 服务器供 Kiro、Claude Code 等 AI 开发工具直接查询。

读到这里，你可能会想：这是 AWS 的另一个云服务新功能，与我何干？

但如果你关注企业 AI 治理的演进，你会看到：这可能是 AI Agent 生态从「混乱扩张」进入「受控治理」的关键转折点——一个「企业 AI App Store 时刻」。

问题背景：企业 AI Agent 的「治理真空」

在理解 Agent Registry 的意义之前，需要先理解它试图解决的问题。

Salesforce 2026 年报告显示，企业目前平均使用 12 个 AI Agent，且预计两年内增长 67%。其中，约 50% 的 Agent 在孤立运行，没有与其他系统集成，也没有集中的监控和治理。

从我们的另一篇文章（《企业平均 12 个 AI Agent，但 50% 在孤立运行》）里了解到这个治理危机的规模。现在，Agent Registry 是第一个专门针对这个问题的基础设施层解决方案。

问题的具体表现：

「哪些 Agent 在跑？」
企业 IT 部门不知道当前有多少 AI Agent 在生产环境运行。一个部门用了 Cursor Agent 做代码审查，另一个部门用了 Salesforce Agentforce 处理客户询问，第三个部门自己写了一个基于 Claude API 的数据分析 Agent——IT 部门没有一个统一的视图来看这些。

「谁批准这些 Agent 使用的？」
AI Agent 可能访问企业的核心数据系统（CRM、ERP、财务系统）、对外发邮件、执行代码。这些操作的授权，在大多数企业是碎片化的：某个部门的技术负责人自己拍板用了某个 Agent，没有通过 IT 安全审查，没有合规部门的知情。

「这个 Agent 在做什么？」
AI Agent 的行为比传统软件更难预测。一个 Agent 在完成主任务的同时，可能访问了什么数据、调用了什么外部 API、留下了什么日志——在没有集中治理的情况下，这些都是黑盒。

「能不能复用这个好用的 Agent？」
A 部门花了 3 个月开发了一个效果很好的客户服务 Agent，B 部门面临相同的需求，却不知道 A 已经做过，开始重新建轮子。知识孤岛导致的重复建设，是企业 AI 效率损失的重要来源。

Agent Registry 试图用一个集中式目录，同时解决这四个问题。

Agent Registry 的核心能力：不只是「目录」

AWS 把 Agent Registry 定位为「目录」，但它的功能远超一个简单的列表。

发现与搜索：支持混合模式——关键词搜索（「找一个处理采购申请的 Agent」）+ 语义搜索（「找一个可以理解合同条款并提取关键信息的工具」）。语义搜索是关键，因为 AI Agent 的能力往往难以用精确关键词描述，需要语义理解来匹配「我的需求」和「现有 Agent 的能力」。

生命周期管理：草稿→待审批→已发布的三段式工作流。开发者提交 Agent 后，需要经过 IT 安全/合规团队的审批才能进入「已发布」状态。这个审批流程，是企业 AI 治理的核心节点——在这里，安全团队可以检查 Agent 的权限声明（它声称需要访问什么数据？为什么？）、合规团队可以验证 Agent 的行为是否符合公司政策。

跨云和本地索引：不只是 AWS 托管的 Agent，也可以索引在其他云上（Azure、GCP）运行的 Agent，或者在企业内部数据中心运行的 Agent。这解决了大型企业「多云战略」下的 Agent 分散问题——一张图，看全部。

MCP 服务器支持：Agent Registry 本身可以作为一个 MCP 服务器被调用，这意味着 AI 开发工具（Kiro、Claude Code）可以直接查询 Agent Registry，在编写代码时「自动发现」企业内部可用的 Agent 和工具。这将 Agent Registry 从「人用的目录」扩展到「Agent 用的目录」——一个 AI 可以调用另一个 AI 之前，先查 Registry 找到它。

「App Store 时刻」的深层含义

为什么说这是「企业 AI 的 App Store 时刻」？

2007 年 App Store 之前，iPhone 的应用生态是混乱的：开发者各自分发，用户自己到处找，苹果无法对应用质量和安全性负责。App Store 的出现，不只是「建了一个商店」，而是建立了一套权力结构：谁有权发布应用、谁有权下架应用、什么是可接受的应用行为。

Agent Registry 正在为企业内部的 AI Agent 生态做类似的事：

权力结构：IT 部门/安全团队成为 Agent 的「守门人」。一个 AI Agent 在获得 IT 审批前，处于「草稿」状态，无法被企业内其他系统调用。这是 IT 治理对 AI 时代的一次「接管」。

标准化接口：Agent 必须以结构化方式声明自己的能力、权限需求、调用协议。这个声明，是审批流程的基础，也是其他系统自动发现和调用这个 Agent 的前提。

责任归属：当一个经过 Registry 审批和发布的 Agent 出现问题（数据泄露、错误操作），责任链条是清晰的：谁提交了这个 Agent（开发者/部门）、谁审批了（IT/安全）、谁在用（调用方部门）。这种清晰的责任归属，是企业合规的基础。

如果 Agent Registry 被广泛采用，它将成为企业 AI 生态的「接入点」——任何 AI Agent 进入企业生产环境的必经节点。控制了这个节点，AWS 就控制了企业 AI 治理基础设施的核心。

但这个类比有一个重要的边界值得说明：App Store 的权力来自「控制分发」——没有苹果的审批，应用就无法到达 iOS 用户。Agent Registry 的权力来自「控制审批流程」，但这个流程是企业内部的，不是 AWS 强制的。企业可以选择不用 AWS 的 Agent Registry，而是自建内部工具。AWS 的真实护城河，不在于「成为唯一的 Agent Registry」，而在于「成为企业 IT 团队首选的 Agent Registry 平台」——这是需要通过集成深度、易用性和生态合作伙伴来赢得的市场，而不是靠技术锁定。

竞争格局：AWS 为什么要在这个时机推出

AWS 不是在真空中推出 Agent Registry。这是一个竞争导向的时机选择。

微软的 Azure AI Catalog：微软在 Azure AI Foundry 里有 AI 模型目录，但针对 AI Agent 生命周期管理的工具相对薄弱——它可以帮你「选模型」，但没有「AI Agent 注册→审批→发布→监控」的完整管理工作流。微软的重心在通过 Copilot 直接面向终端用户，而不是帮助 IT 部门治理企业内部的自建 Agent。

Salesforce Agentforce 的封闭生态：Salesforce 的 Agentforce 提供了完整的企业级 AI Agent 能力，在 CRM 生态内是功能成熟的解决方案。但它的设计是封闭的——只能管理 Salesforce 平台上的 Agent，不支持跨云或本地部署的 Agent 索引。对于有多系统环境的大型企业，Agentforce 无法提供全局视图。

Google Cloud 的 Vertex AI Agent Builder：Google 专注于「帮开发者快速构建 AI Agent」，在创建工具方面成熟，但治理和生命周期管理不是其主打方向——搜索「Vertex AI Agent governance」的文档，能找到的工具远少于「如何创建 Agent」的指南。

差异化定位：AWS Agent Registry 是这三家中第一个专门为「管理已有 Agent」（而非「创建新 Agent」）设计的企业级工具。创建是一次性的，管理是持续的——AWS 选择了这个更难但更有长期价值的方向。

实际使用场景：从抽象到具体

以一家 500 人的金融服务公司为例，Agent Registry 如何改变日常运营：

场景 1：新 Agent 上线
风控部门开发了一个 AI Agent，用于自动分析贷款申请文件并生成初步风险评分。开发完成后，提交到 Agent Registry，声明所需权限（访问贷款申请数据库、只读权限）。IT 安全团队在 Registry 界面审查权限声明，合规团队确认符合金融监管要求（GDPR、GLBA 等），审批通过后 Agent 状态变为「已发布」，其他系统可以调用。

场景 2：跨部门复用
信贷部门在 Agent Registry 中搜索「文档提取和结构化」相关 Agent，发现风控部门 6 个月前已经发布了一个成熟的文档处理 Agent，且经过安全审批。信贷部门直接复用，节省了重新开发的 2 个月工作量。

场景 3：安全事件响应
某个 Agent 被发现访问了超出声明权限的数据（异常行为告警）。IT 安全团队通过 Agent Registry 找到这个 Agent 的提交记录，确认提交者、审批人和调用方，在几分钟内完成责任归属，并将 Agent 状态切换回「草稿」（下线）。整个响应过程有完整的审计日志。

这三个场景，描述的是一个「AI Agent 治理已经成熟」的企业环境。Agent Registry 是实现这个环境的关键基础设施。

下一个阶段：「AI Agent 合规认证」行业的诞生

当 Agent Registry 成为企业 AI 治理的标准节点，一个新的行业机会随之出现：AI Agent 合规认证。

类比：当 App Store 推出后，出现了专门帮助开发者通过 App Store 审核的服务公司；当银行要部署第三方软件需要通过合规审查时，出现了专门做「银行级安全认证」的 SaaS 公司（如 OneTrust、BitSight）。

AI Agent 的合规认证，会是类似的市场：

谁需要认证服务：开发 AI Agent 并希望将其销售给大型企业的 ISV（独立软件供应商）和 AI 初创公司——他们需要证明自己的 Agent 符合企业的安全标准，才能更容易通过企业 IT 的审批流程。

认证内容：Agent 的权限边界测试（它真的只访问了声明的数据吗？）、越权行为检测（在什么条件下 Agent 会超出预期行为范围？）、合规协议符合性（GDPR、HIPAA、SOC 2 等）、审计日志完整性。

市场规模：如果 Agent Registry 在企业中广泛部署，进入「发布」状态的 Agent 数量可能在未来 3 年内达到数百万个。每个 Agent 在发布前都可能需要某种形式的合规验证，这是一个不小的市场。

AWS 推出 Agent Registry，是这个生态的地基。认证服务、治理工具、监控平台，将在这个地基上建立起来。

结语：治理是创新的下一阶段

每一次重大技术创新的「爆发期」之后，都会跟随一个「治理期」。

互联网爆发后，有 GDPR、CCPA、网络安全法规；移动 App 爆发后，有 App Store 审核机制、隐私权限框架；云计算爆发后，有 IAM（身份和访问管理）、合规认证（SOC 2、ISO 27001）。

AI Agent 正在经历「爆发期」（2024-2026 年：企业平均 12 个 Agent，两年内预计增长到 20 个）。「治理期」已经开始出现第一批工具——AWS Agent Registry 是其中最早的企业级基础设施层产品之一。

治理，有时被误读为「创新的阻力」。但历史上，每一次治理工具的成熟，反而加速了技术的大规模企业采用——因为治理降低了「不确定性」，而降低不确定性是企业采购的前提。

App Store 让企业 IT 更放心地允许员工使用第三方应用；IAM 让企业 IT 更放心地把工作负载迁移到云；Agent Registry，可能让企业 IT 更放心地批准更多 AI Agent 进入生产环境。

这不是 AI 创新的终点，而是它从「先驱者试验」走向「大规模企业主流」的必经节点。

MCP（模型上下文协议）与 Agent Registry 的深度协同

理解 Agent Registry 的技术意义，还需要理解它与 MCP（Model Context Protocol，模型上下文协议）的关系。

MCP 是 Anthropic 发起、被 AI 行业广泛接受的开放协议标准，定义了 AI 模型如何与工具、数据源和其他系统进行标准化交互。简单说，MCP 是「AI 与世界连接的接口标准」。

Agent Registry 支持作为 MCP 服务器运行，意味着：

开发者可以在 IDE 中直接查询 Registry：当 Claude Code 或 Kiro 的用户在编写代码时，他们的 AI 编码助手可以直接查询 Agent Registry，自动发现「公司里有没有现成的 Agent 可以处理这个任务」，而不是让开发者手动去 Wiki 或文档里搜索。这将 Agent 的「可发现性」直接集成进了开发者的工作流。
AI 调用 AI 的基础设施：随着「AI Agent 编排」（多个 AI Agent 协作完成复杂任务）成为企业 AI 的重要使用模式，Agent Registry 变成了「Agent 间协作的电话簿」。一个编排级 Agent 在规划任务时，可以查询 Registry 找到有相关能力的子 Agent，而不是硬编码调用关系。这让企业内的 AI Agent 生态具备动态可扩展性。
跨团队知识共享的技术实现：不同团队开发的 Agent，通过 Registry 的结构化描述（能力声明、接口规范、使用示例），变成其他团队可以理解和复用的「资产」，而不是只有原始开发团队才懂的「黑盒」。

MCP + Agent Registry 的组合，是企业 AI 生态从「各自为政」走向「有序协作」的技术基础。

对 AI 安全团队的实际价值

最后，从安全团队的视角理解 Agent Registry 的意义，因为这是决定 Agent Registry 能否被大型企业真正采用的关键群体。

企业安全团队面对 AI Agent 的核心担忧是什么？

担忧 1：不知道有哪些 Agent 在运行
安全团队无法保护他们不知道存在的东西。Agent Registry 的「全库存视图」，让安全团队第一次可以系统性地了解企业内部 AI Agent 的全景，而不是被动地等待安全事件报告「又发现一个没有审批的 Agent」。

担忧 2：Agent 的权限边界不清晰
传统软件的权限由 IAM 策略精确控制；AI Agent 的「动作」往往模糊——「帮我发送一封跟进邮件」可能涉及访问联系人数据库、起草邮件、调用邮件发送 API，但这一系列动作是否都被明确授权，经常是不清楚的。Agent Registry 要求 Agent 提交时声明「我会访问什么系统、做什么操作」，让安全团队可以在审批阶段评估这些权限是否合理，而不是事后补课。

担忧 3：Agent 行为的审计和回溯
当一个 AI Agent 产生了一个错误的操作（发送了不该发的邮件、修改了不该修改的数据），安全团队需要能够「复盘」这个 Agent 做了什么、为什么这么做、是否符合批准时的预期。Agent Registry 的审批记录和版本历史，是这个回溯的起点。

这三个担忧，Agent Registry 都给出了具体的技术回应。这也是为什么，当 AWS 在企业销售中演示 Agent Registry 时，第一个被打动的群体往往不是 AI 开发者，而是 CISO（首席信息安全官）和合规负责人。

对 AI 创新速度的悖论式加速：听起来「安全审批」会减慢 AI Agent 的部署。但实际上，「有治理的加速」往往比「无治理的扩张」走得更远更快。当 IT 安全团队对 AI Agent 缺乏控制手段时，他们的应对往往是「全面禁止不经审批的 AI 工具」——这才是真正的减速。Agent Registry 给了安全团队控制的手段，反而使他们更愿意放行更多的 AI Agent 进入生产环境。这是治理工具对创新速度的悖论式贡献。

更具体地说：在那些既没有「全面禁止 AI 工具」又没有「系统性 AI 治理」的企业里，会出现一种「影子 AI」现象——工程师和产品团队在 IT 部门不知情的情况下使用各种 AI Agent，形成事实上的治理真空。这种真空不是「自由创新」，而是潜在的安全事故和合规风险的累积。每一次「影子 AI」导致的数据泄露或违规操作，都会触发更严格的限制措施，最终反而减慢整体 AI 采用速度。Agent Registry 提供了一个出口：既允许创新（有人可以提交新 Agent），又维护治理（有人审批）。这是「有序创新」比「无序创新」走得更远的基础设施保障。

从「应该谨慎」到「有了工具可以谨慎地加速」，这个心理转变，是企业 AI 大规模采用的最后一道心理障碍。Agent Registry，可能是开启这扇门的那把钥匙。

当 AWS 在 5 个区域同时上线 Agent Registry 公开预览，当 Spring AI AgentCore SDK 同期 GA 发布，当更多 AI 开发工具支持 MCP 协议——这些不是孤立的产品更新，而是企业 AI 治理基础设施系统性成熟的标志。

「AI Agent 的 App Store 时刻」，正在悄悄到来。

短期展望：Agent Registry 能否成为行业标准

一个关键问题：Agent Registry 会成为企业 AI 治理的行业标准，还是只是 AWS 生态的内部工具？

历史上，类似的治理基础设施往往经历这样的演变路径：单一厂商推出→行业标准化→多厂商互操作。IAM 从 AWS 的私有实现，演变成 SAML、OAuth 等开放标准，最终实现了跨云的身份管理互操作。容器编排从 Docker Swarm 和 Mesos 的私有竞争，演变成 Kubernetes 成为事实标准。

Agent Registry 的开放标准化，可能走以下路径：

第一阶段（当前）：AWS 在 5 个区域发布公开预览，构建先发优势，吸引企业用户和 ISV 合作伙伴在 AWS 平台上管理 Agent。

第二阶段（6-12 个月）：Azure、Google Cloud 推出类似的 Agent Registry 功能。此时 MCP 协议的开放性成为关键——如果 AWS 的 Agent Registry 与其他云的 Registry 互操作性差，大型企业（多云策略）会要求开放接口。

第三阶段（1-2 年）：行业联盟（如 OpenTelemetry 在可观测性领域做的事）推动 Agent Registry 接口标准化，形成跨云可移植的 Agent 元数据格式。

如果这个演变路径成立，AWS 目前做的，不只是一个产品，而是一个标准制定的先手。谁先定义了「AI Agent 注册和治理」的接口形式，谁就在这个未来标准的制定中拥有更大的话语权。这是 AWS 推出 Agent Registry 的战略深意之一——不只是卖云服务，而是参与定义 AI Agent 时代的基础设施标准。

在这个视角下，Agent Registry 不是 AWS 云服务的一个新功能，而是 AWS 在「AI 基础设施标准战争」中的一次战略落子。这颗棋子现在看起来很小，但如果未来几年企业 AI Agent 治理成为必须，它的位置会变得非常关键。

这，才是 AWS Agent Registry 公开预览发布的真实分量。

当你下次听到「又一个云服务新功能」的时候，不妨多问一句：这个功能解决的，是技术问题还是治理问题？是点状优化还是生态基础设施？是三个月后会被忘记的更新，还是 10 年后被教科书引用的「关键节点」？

Agent Registry，更像是后者。AI Agent 的时代，治理基础设施刚刚起步，而起步往往比预想的更安静、更低调、更重要。

一个 App Store 的诞生，改变了软件分发的权力结构，影响了随后 20 年的移动互联网。一个 Agent Registry 的出现，可能同样在悄悄改变 AI Agent 的权力结构，书写属于这个时代的新章节。

参考资料

InfoQ — “AWS Releases Amazon Bedrock AgentCore Agent Registry in Public Preview” (2026-04-17) https://www.infoq.com/news/2026/04/aws-agent-registry-preview/
AWS 官方公告 — Amazon Bedrock AgentCore Agent Registry (2026-04-17)
Salesforce 2026 Connectivity Report — 企业 AI Agent 使用数据
AWS Spring AI AgentCore SDK GA 公告 (2026-04-14) https://aws.amazon.com/blogs/machine-learning/spring-ai-sdk-for-amazon-bedrock-agentcore-is-now-generally-available/