2026年4月的第2周，AWS在同一天连续发布了3个看似独立、实则高度关联的产品更新：AgentCore中的Agent Registry预览版、Marketplace Discovery API、以及Bedrock AgentCore BrowserLiveView组件。如果你只看新闻标题，这不过是又一轮AWS re:Invent之后的产品迭代。但如果你把这3个发布拼在一起看，一个清晰的战略图景浮现出来——AWS正在以MCP开放标准为入口，构建一个从Agent发现、注册、治理、运行到商业化交易的完整闭环。

这不是一个单点产品发布。这是AWS对AI Agent生态控制权的系统性宣示。

问题在于：MCP（Model Context Protocol）本身是Anthropic推动的开放互操作协议，其设计初衷是打破AI Agent与工具之间的壁垒。当一个开放标准的发现层、治理层和运行层被全部拉入某家云厂商的产品栈中时，”开放”这个词还剩下多少含金量？

一、事件全景：AWS的”应用商店时刻”降临

Agent Registry：给AI Agent装上”户籍系统”

2026年4月，AWS宣布在Amazon Bedrock AgentCore中推出Agent Registry预览版，覆盖5个AWS区域（来源：AWS官方公告, 2026-04-10）。这不是一个简单的目录服务。Agent Registry提供的是一套企业级AI Agent治理基础设施，其核心能力包括：

私有治理目录（Private Governance Catalog）：企业可以在内部建立一个集中式的Agent、工具和MCP Server注册中心。每个注册条目包含结构化的元数据——功能描述、权限要求、所有者信息、版本历史。这本质上是给企业内部野蛮生长的AI Agent生态装上了”工商登记”。

URL-based Discovery：Agent Registry支持通过URL自动抓取MCP Server的元数据。开发者只需提供一个MCP Server的端点地址，Registry就能自动拉取其能力描述、工具列表和调用规范。这大幅降低了注册门槛，但也意味着AWS正在成为MCP生态的”默认黄页”。

语义搜索（Semantic Search）：注册的Agent和工具不仅支持关键词检索，还支持基于自然语言的语义搜索。一个产品经理可以用”帮我找一个能查询Salesforce客户数据的Agent”这样的自然语言来发现可用工具。

管理员审批工作流（Approval Workflow）：企业管理员可以设定审批流程，新注册的Agent或MCP Server必须经过审核才能被其他团队发现和调用。这直击企业IT治理中”影子AI”（Shadow AI）的痛点。

IAM与OAuth双重认证：Agent Registry深度集成AWS IAM（Identity and Access Management），同时支持OAuth标准。这意味着每个Agent的调用权限、数据访问范围都可以通过AWS原生的身份体系进行精细化控制。

CloudTrail审计追踪：所有注册、发现、调用行为都会被记录到AWS CloudTrail中，形成完整的审计链。对于金融、医疗等强监管行业，这是合规的硬性要求。

Agent Registry自身可作为MCP Server：这是一个极其精妙的设计——Agent Registry本身也暴露为一个MCP Server，可以被IDE（如VS Code中的Copilot、Cursor等）直接查询调用。开发者在IDE中输入自然语言查询，就能发现企业内部已注册的所有Agent和工具。

Marketplace Discovery API：从技术目录到商业交易

同日发布的AWS Marketplace Discovery API（来源：AWS官方公告, 2026-04-10）允许企业将AWS Marketplace中的SaaS产品、AI Agent、工具的目录数据通过API嵌入到内部门户、采购系统和开发者工具中。

表面上看，这是一个面向ISV（独立软件供应商）和企业采购部门的工具。但将它与Agent Registry放在一起看，逻辑链条就清晰了：Agent Registry负责企业内部的Agent发现和治理，Marketplace Discovery API负责将外部可采购的Agent和工具引入企业视野。两者打通后，AWS构建的是一个”从发现到采购到治理到运行”的完整商业闭环。

Agent不再只是技术资产，而是可交易的商业资产。AWS正在为AI Agent生态建立”应用商店”的基础设施。

BrowserLiveView：运行时可观测性的最后一块拼图

同期发布的Amazon Bedrock AgentCore BrowserLiveView组件（来源：AWS官方博客, 2026-04-10）允许开发者在React应用中嵌入一个实时的AI浏览器Agent视图。用户可以实时观看AI Agent在浏览器中的操作过程——点击了哪个按钮、填写了哪个表单、导航到了哪个页面。

这不仅仅是一个UI组件。它补全了Agent生命周期管理的最后一环：运行时可观测性。当Agent Registry负责”谁在哪里、能做什么”，BrowserLiveView则负责”它正在做什么、做得对不对”。

把这3个发布拼在一起：Agent Registry（发现+注册+治理）+ Marketplace Discovery API（商业化+采购）+ BrowserLiveView（运行时可观测性）= 一个完整的AI Agent生命周期管理平台。

这不是巧合。这是系统性的产品布局。

二、企业AI治理的真空与刚需

“影子AI”危机：企业内部Agent的野蛮生长

要理解Agent Registry为什么重要，首先要理解它解决的问题有多严重。

2025年下半年以来，企业内部AI Agent的部署呈现爆发式增长。Gartner在2025年10月发布的调查报告显示，超过55%的受访企业已在至少3个业务部门部署了AI Agent，但其中仅有18%建立了集中式的Agent治理机制（来源: Gartner, “AI Agent Governance Survey”, 2025-10-15）。从客服自动化到代码生成，从数据分析到文档处理，各个业务部门都在独立构建或采购AI Agent。但这种增长几乎是无序的：

重复建设：同一家企业的3个不同部门可能各自构建了功能高度重叠的”客户数据查询Agent”，每个都连接了不同的数据源，使用不同的认证方式，产生不同格式的输出。没有人知道企业内部到底有多少个Agent在运行。

权限混乱：一个市场部门构建的Agent可能被授予了访问财务数据库的权限，而这个授权过程既没有经过IT部门审批，也没有留下审计记录。在强监管行业，这是合规灾难。McKinsey在2026年初的一份报告中指出，企业AI相关的合规事件中，约40%与未经授权的数据访问有关（来源: McKinsey, “The State of AI Risk Management”, 2026-02）。

缺乏发现机制：一个新加入的工程师想找一个能调用内部CRM系统的工具，他不知道这样的工具是否已经存在、由谁维护、如何调用。最终他会自己再建一个，加剧了重复建设的恶性循环。

版本管理缺失：Agent A依赖MCP Server B的v1.2版本，但B的维护者在没有通知的情况下升级到了v2.0并引入了破坏性变更。Agent A在生产环境中突然失效，而排查问题需要数小时甚至数天。

这些问题并不新鲜。它们是企业IT治理领域反复出现的经典挑战——只是这次的主角从微服务换成了AI Agent。

历史镜像：从API Gateway到Service Mesh到Agent Registry

回顾企业基础设施的演进史，Agent Registry的出现几乎是一种历史必然。

2010年代初期：API Gateway的崛起。当企业内部的微服务数量从几十个增长到几百个时，API管理成为刚需。Apigee（后被Google收购）、Kong、AWS API Gateway等产品应运而生，提供API的注册、发现、认证、限流和监控。它们本质上是给微服务生态装上了”交通管理系统”。

2010年代中后期：Service Mesh的兴起。当微服务之间的通信复杂度进一步上升时，Istio、Linkerd等Service Mesh产品出现，将服务间通信的安全、可观测性和流量管理下沉到基础设施层。

2026年：Agent Registry。当企业内部的AI Agent数量从几个增长到几十个、几百个时，Agent的注册、发现、认证、审批和审计成为刚需。Agent Registry就是AI Agent时代的API Gateway + Service Registry。

这个类比揭示了一个关键洞察：Agent Registry不是一个”nice-to-have”的管理工具，而是AI Agent基础设施走向生产级成熟的必经之路。 正如没有API Gateway的微服务架构无法在企业中规模化部署，没有Agent Registry的AI Agent生态同样无法满足企业级的治理要求。

竞品格局：AWS并非在真空中行动

AWS敏锐地捕捉到了这个时间窗口，但它并非完全没有竞争对手。

Google Cloud方面，Vertex AI Agent Engine已经提供了Agent的构建、部署和编排能力，并在2025年底引入了Agent-to-Agent（A2A）协议支持。但截至2026年4月，Vertex AI Agent Engine的重心仍在Agent运行时编排，而非集中式的注册与治理。Google Cloud尚未推出功能对等的企业级Agent Registry产品，其Agent管理能力更多嵌入在Vertex AI的工作流编排层中，缺少独立的私有治理目录和审批工作流（来源: Google Cloud Vertex AI文档, 2026-03）。

Microsoft Azure方面，Azure AI Foundry（原Azure AI Studio）在2025年已支持MCP协议集成，允许开发者在Foundry中调用MCP Server。2026年3月，Microsoft宣布在Copilot Studio中增强了Agent管理功能，包括Agent的版本控制和基本的发现能力。但Azure的方案更偏向于Copilot生态内部的Agent管理，而非跨框架、跨运行时的通用Agent Registry（来源: Microsoft Azure AI Foundry文档, 2026-03）。

综合判断：AWS Agent Registry在产品完整度上——特别是私有治理目录、审批工作流、CloudTrail审计链的组合——确实领先于Google Cloud和Azure的现有方案。但将这种领先量化为”6-12个月”需要谨慎：Google和Microsoft都有快速跟进的能力和动机，且两家公司在各自的AI Agent生态中已有部分治理能力的积累。更准确的说法是，AWS在”企业级Agent治理的产品化”这个细分赛道上取得了显著的先发优势，但竞争窗口远未关闭。

技术细节中的魔鬼

Agent Registry的几个技术设计选择值得深入分析：

URL-based Discovery的双刃剑。通过URL自动抓取MCP Server元数据，这极大降低了注册门槛——开发者不需要手动填写繁琐的注册表单，只需提供一个端点地址。但这也意味着Agent Registry需要能够解析和理解MCP协议的元数据格式。如果未来MCP协议的元数据规范发生变更，AWS需要同步更新，这创造了一种微妙的依赖关系：AWS既是MCP生态的参与者，也是其基础设施的提供者。

语义搜索的底层依赖。Agent Registry的语义搜索功能显然依赖于某种嵌入模型（embedding model）来理解自然语言查询并匹配Agent能力描述。虽然AWS官方公告未明确说明使用的具体模型，但可以合理推断它运行在AWS Bedrock之上。这意味着Agent Registry的核心功能——发现——本身就依赖于AWS的AI基础设施。

CloudTrail集成的锁定效应。将所有Agent调用行为记录到CloudTrail中，对企业合规团队来说是巨大的价值。但CloudTrail是AWS的原生服务，其日志格式、查询方式和告警机制都深度嵌入AWS生态。一旦企业的合规审计流程建立在CloudTrail之上，迁移成本将极其高昂。

三、MCP开放标准正在被”温柔收编”

MCP的初心与现实

MCP（Model Context Protocol）由Anthropic在2024年11月推动发起，其设计初衷是建立一个开放的、标准化的协议，让AI Agent能够以统一的方式发现和调用外部工具。MCP的愿景类似于HTTP之于Web——一个所有人都可以使用、不被任何单一厂商控制的通信协议。

MCP协议目前的治理状态值得细究。协议规范托管在GitHub上的modelcontextprotocol组织下，采用开放的RFC（Request for Comments）流程接受社区提案。截至2026年4月，MCP规范的主要贡献者仍以Anthropic员工为主，但已有来自Shopify、Stripe、Cloudflare等公司的开发者参与了工具规范和传输层协议的讨论。Anthropic在2025年初将MCP定位为”社区驱动的开放标准”，但尚未将协议治理权移交给任何独立的标准化组织或基金会（来源: MCP GitHub仓库, modelcontextprotocol/specification）。

MCP的核心价值主张包括：

  1. 互操作性：任何AI Agent都可以调用任何MCP Server，不受厂商限制
  2. 标准化：工具的能力描述、调用接口和认证方式遵循统一规范
  3. 去中心化：不存在一个中央注册中心，MCP Server可以分布在任何地方

然而，AWS Agent Registry的出现正在微妙地改变这个叙事。

“拥抱、扩展、收编”的新变体

AWS Agent Registry对MCP的态度可以用3个层次来描述：

第一层：拥抱（Embrace）。Agent Registry原生支持MCP Server的注册和发现。开发者可以将任何MCP Server注册到Agent Registry中，Registry会自动抓取其元数据。AWS甚至将Agent Registry自身也暴露为一个MCP Server，允许IDE和其他工具通过MCP协议来查询Registry。这看起来是对MCP开放标准的全力拥抱。

第二层：扩展（Extend）。但Agent Registry在MCP协议之上添加了大量AWS原生的治理能力：IAM认证、审批工作流、CloudTrail审计、语义搜索。这些能力超出了MCP协议本身的范畴，但对企业用户来说又是刚需。问题在于，这些扩展能力全部依赖AWS的原生服务，无法在其他云平台上复制。

第三层：收编（Contain）。当企业将MCP Server注册到AWS Agent Registry中，并基于IAM进行权限管理、基于CloudTrail进行审计、基于审批工作流进行治理时，MCP的”去中心化”承诺实际上已经被架空。MCP Server本身可能运行在任何地方，但它的发现、认证和治理都被拉入了AWS的生态闭环中。

这不是经典的Microsoft式”拥抱、扩展、消灭”（Embrace, Extend, Extinguish）——AWS并没有试图消灭MCP协议本身。相反，AWS需要MCP协议继续存在并繁荣，因为MCP协议越成功，注册到Agent Registry中的MCP Server就越多，Agent Registry的网络效应就越强。

AWS消灭的不是MCP协议，而是MCP”去中心化发现”的可能性。

反事实分析：如果Google Cloud和Azure各建围墙

⚠️ 以下为假设场景推演，并非已发生的事实。 其目的是通过反事实分析揭示当前趋势的潜在后果。

假设以下场景在2026年下半年发生：

  • Google Cloud在Vertex AI中推出自己的Agent Registry，支持MCP Server注册，但使用Google IAM进行认证，使用Cloud Audit Logs进行审计
  • Microsoft Azure在Azure AI Foundry中推出自己的Agent Registry，支持MCP Server注册，但使用Azure AD（Entra ID）进行认证，使用Azure Monitor进行审计

在这种情况下，同一个MCP Server如果要被3家云厂商的客户发现和使用，需要分别在3个Agent Registry中注册，并适配3套不同的认证和审计体系。MCP协议层面的互操作性仍然存在——Agent调用MCP Server的方式是统一的——但发现层和治理层已经完全碎片化。

这就像HTTP协议本身是开放的，但如果每个国家都要求网站在本国的”网站注册中心”注册才能被本国用户访问，HTTP的”开放互联”就名存实亡了。

这一假设场景并非空穴来风。 云计算行业在容器编排（Kubernetes vs. Docker Swarm vs. Mesos）、Serverless（Lambda vs. Cloud Functions vs. Azure Functions）等领域都经历过类似的碎片化阶段。Agent Registry作为新兴品类，面临同样的碎片化风险。

Kubernetes的CNCF模式：一个值得对比的先例

要理解MCP生态面临的治理挑战，Kubernetes的历史提供了一个极具参考价值的对照。

Kubernetes最初由Google开发并开源。2015年，Google将Kubernetes捐赠给了新成立的CNCF（Cloud Native Computing Foundation），由Linux Foundation托管。CNCF的治理模式确保了几个关键原则：

  1. 中立性：没有任何单一云厂商能够控制Kubernetes的发展方向
  2. 一致性认证：CNCF推出了Certified Kubernetes Conformance Program，确保不同厂商的Kubernetes发行版之间的兼容性
  3. 生态互操作：围绕Kubernetes的工具（Helm、Prometheus、Envoy等）形成了一个厂商中立的生态

正是因为CNCF的存在，Kubernetes才避免了被任何单一云厂商”收编”的命运。AWS的EKS、Google的GKE、Azure的AKS虽然各有差异，但核心API是兼容的，工作负载可以跨云迁移。

MCP协议目前缺少一个类似CNCF的中立治理机构。Anthropic作为MCP的发起者，虽然将其定位为开放标准，但Anthropic本身是一家商业公司，与AWS有深度的商业合作关系——AWS在2023年9月宣布向Anthropic投资最高40亿美元，是Anthropic最大的云基础设施合作伙伴（来源: AWS官方公告, 2023-09-25）。这种关系使得MCP的”中立性”从一开始就面临质疑。

MCP需要自己的”CNCF时刻”——一个将协议治理权从单一商业实体转移到中立基金会的关键节点。 如果这个时刻不到来，MCP的命运很可能是成为各家云厂商内部的”方言”：语法相同，但语境各异。

四、Marketplace Discovery API揭示的商业化野心

从技术目录到交易平台

AWS Marketplace Discovery API（来源：AWS官方公告, 2026-04-10）的发布时间点绝非偶然。它与Agent Registry的组合，揭示了AWS更深层的商业化意图。

Marketplace Discovery API允许企业通过API将AWS Marketplace中的产品目录数据嵌入到内部系统中。这意味着：

  • 企业的采购系统可以直接搜索和浏览AWS Marketplace中的AI Agent和工具
  • 企业的开发者门户可以展示可用的第三方MCP Server及其定价
  • 企业的IT治理平台可以将外部Agent的采购与内部Agent Registry的注册流程打通

将Agent Registry（内部治理）与Marketplace Discovery API（外部采购）连接起来，AWS构建的是一个双边市场：

  • 供给侧：ISV和AI Agent开发者将产品发布到AWS Marketplace
  • 需求侧：企业通过Agent Registry发现内部Agent，通过Marketplace Discovery API发现外部Agent
  • 交易层：AWS Marketplace处理计费、订阅和合同管理
  • 治理层：Agent Registry处理权限、审批和审计

这是一个典型的平台经济模型。AWS不仅从基础设施层（EC2、Bedrock）获取收入，还从Agent的交易层抽取佣金。AI Agent从技术资产变成了可交易的商业资产，而AWS是这个交易市场的运营者。

“应用商店”类比的局限与超越

将Agent Registry + Marketplace比作”应用商店”是直觉上最容易理解的类比，但这个类比既有准确的部分，也有需要修正的部分。

准确之处：

  • 集中式的发现和分发机制
  • 平台运营者制定准入规则和审核标准
  • 交易佣金模式

超越之处：

  • 传统应用商店中的App是独立运行的，而Agent之间可以相互调用、组合和编排。Agent Registry不仅是一个目录，更是一个”Agent互联网”的路由层
  • 传统应用商店的治理主要是上架审核，而Agent Registry的治理贯穿整个生命周期——从注册、发现、调用到退役
  • 传统应用商店的用户是个人消费者，而Agent Registry的用户是企业。企业的采购决策涉及合规、安全、成本等多维度考量，远比个人消费者复杂

这意味着Agent Registry的商业潜力可能远超传统应用商店。 如果每个企业都需要一个Agent Registry来管理内部和外部的AI Agent，而AWS的Agent Registry成为事实标准，那么AWS就控制了AI Agent经济的”交易所”。

BrowserLiveView：信任基础设施的补全

BrowserLiveView组件（来源：AWS官方博客, 2026-04-10）在这个商业化图景中扮演着一个容易被忽视但至关重要的角色：建立信任。

AI Agent在企业环境中面临的最大障碍不是技术能力，而是信任。当一个AI Agent代表企业在浏览器中执行操作——填写表单、提交订单、处理敏感数据——企业需要能够实时监控和验证Agent的行为。BrowserLiveView通过在React应用中嵌入实时的Agent操作视图，让人类监督者能够”看到”Agent在做什么。

这对于Agent的商业化至关重要。一个企业采购AI Agent时，如果无法观测和审计Agent的运行时行为，采购决策就无法通过合规审查。BrowserLiveView + CloudTrail审计链 = 完整的可观测性和可审计性，这是企业大规模采购AI Agent的前提条件。

五、大多数人没看到的：控制权博弈的3个隐藏维度

隐藏维度1：Agent发现层的网络效应

Agent Registry最危险的锁定机制不是IAM或CloudTrail，而是网络效应。

当一个企业将100个Agent和MCP Server注册到AWS Agent Registry中时，这个Registry就成为了该企业AI Agent生态的”真相来源”（source of truth）。新的Agent开发者会首先查询Registry来发现可复用的工具，新的业务团队会通过Registry来找到满足需求的Agent。Registry中注册的Agent越多，它的发现价值就越大，就有越多的Agent被注册进来。

这种网络效应一旦形成，迁移成本就不仅仅是技术层面的（重新配置认证和审计），而是组织层面的（重建整个发现和治理流程）。这比迁移一个数据库或一个计算集群要困难得多。

隐藏维度2：语义搜索作为隐性锁定

Agent Registry的语义搜索功能看似是一个便利特性，但它创造了一种隐性的锁定机制。

当企业用户习惯了用自然语言在Agent Registry中搜索工具——”找一个能分析S3中CSV文件的Agent”——他们的搜索习惯、查询模式和工作流都会围绕Agent Registry的语义理解能力来建立。不同的语义搜索引擎对同一查询的理解和排序可能截然不同。如果企业迁移到另一个Agent Registry，用户可能发现同样的查询返回了完全不同的结果，导致工作效率下降。

这类似于从Google搜索切换到Bing搜索——技术上完全可行，但用户体验的差异会造成巨大的切换阻力。

隐藏维度3：审计数据的不可迁移性

CloudTrail中积累的Agent调用审计日志，随着时间推移会成为企业合规体系的核心资产。监管机构在审查时会要求企业提供完整的AI Agent操作历史。这些历史数据存储在CloudTrail中，使用CloudTrail的格式和查询语言。

即使企业决定将Agent Registry迁移到另一个平台，历史审计数据仍然锁定在CloudTrail中。企业需要同时维护旧的CloudTrail数据和新平台的审计系统，这种双轨运行的成本和复杂度会成为迁移的巨大阻碍。

这3个隐藏维度共同构成了一个”温水煮青蛙”式的锁定策略：每一步看起来都是合理的、有价值的，但累积效应是深度的平台依赖。

六、对立视角：为AWS辩护

在批评AWS的”收编”策略之前，有必要认真审视支持AWS做法的论据。

论据1：开放标准不解决治理问题

MCP协议解决的是互操作性问题，但它从未声称要解决治理问题。一个开放协议不需要——也不应该——内置认证、审批和审计机制。这些是平台层面的关注点，由具体的实现者来提供。

AWS Agent Registry在MCP协议之上构建治理层，这不是”收编”，而是”补全”。就像Kubernetes本身不提供日志管理，你需要ELK Stack或Datadog来补全可观测性一样。

论据2：企业需要的是解决方案，不是标准

对于一个正在为AI Agent治理焦头烂额的企业CTO来说，”MCP的去中心化发现机制”是一个学术概念，而”Agent Registry + IAM + CloudTrail”是一个可以在下周一部署的解决方案。企业的IT预算不会等待一个理想化的跨云Agent Registry标准被制定出来。

AWS提供的是一个可用的、集成的、有SLA保障的产品。如果这个产品恰好深度绑定AWS生态，那是因为深度集成本身就是产品价值的一部分。

论据3：竞争会自然产生互操作性

如果Agent Registry成为一个足够重要的品类，Google Cloud和Azure一定会推出竞品。市场竞争会自然推动互操作性标准的形成——就像不同云厂商的Kubernetes发行版最终都通过CNCF认证一样。

论据4：Anthropic自身的角色也需要审视

批评AWS”收编”MCP的声音，往往忽略了一个事实：MCP的发起者Anthropic本身也是一家以盈利为目标的商业公司。Anthropic推动MCP的动机之一，是让更多工具和数据源能够以标准化方式接入Claude等模型，从而增强Anthropic产品的竞争力。将MCP描述为纯粹的”公共利益”项目，本身就是一种过度简化。AWS在MCP之上构建商业产品，与Anthropic通过MCP增强自身产品竞争力，在商业逻辑上并无本质区别。

我的判断：论据有效但不充分

以上论据都有合理之处，但它们忽略了一个关键的时间维度问题。

Kubernetes之所以能够保持跨云互操作性，是因为Google在Kubernetes还处于早期阶段时就将其捐赠给了CNCF。如果Google等到Kubernetes在GKE上已经形成深度锁定后再”开放”，结果会完全不同。

MCP协议目前正处于早期阶段。如果在这个阶段，各家云厂商就各自建立不互通的Agent Registry，网络效应一旦形成，后续的互操作性标准制定将面临巨大的既得利益阻力。

时间窗口正在关闭。MCP生态需要在Agent Registry品类成熟之前，而非之后，建立跨云的互操作性标准。

七、战略推演：3种可能的未来

以下场景推演基于云计算行业历史上类似标准之争的结果模式——特别是容器编排（Kubernetes vs. 竞品）、IaaS API标准化（OpenStack vs. 公有云）、以及Serverless框架碎片化的历史经验。概率为定性判断，反映的是相对可能性排序而非精确预测。

场景1：AWS主导的事实标准（可能性：最高）

AWS Agent Registry凭借先发优势和产品完整度，成为企业AI Agent治理的事实标准。Google Cloud和Azure推出竞品，但市场份额远不及AWS。MCP协议在技术层面保持开放，但在治理层面被AWS实质性控制。

历史参照：AWS Lambda在Serverless领域的主导地位。尽管Google Cloud Functions和Azure Functions都是有力竞品，Lambda凭借先发优势和生态集成度长期保持市场领先。

这个场景下的赢家：AWS、已经深度使用AWS的企业。 这个场景下的输家：多云策略的企业、MCP生态的独立开发者。

场景2：CNCF模式的重演（可能性：中等偏低）

行业意识到Agent Registry互操作性的重要性，推动成立一个中立的治理机构（可能在Linux Foundation或类似组织下），制定跨云的Agent Registry互操作性标准。各家云厂商的Agent Registry产品需要通过一致性认证。

这个场景需要一个关键催化剂：一个足够有影响力的企业联盟站出来要求互操作性。可能的推动者包括大型金融机构、政府机构或欧盟监管机构（欧盟AI法案对AI系统的互操作性和可审计性已有明确要求）。

历史参照：Kubernetes的CNCF治理模式。但需要注意，Kubernetes的中立化发生在品类成熟之前，而Agent Registry的中立化窗口可能更短。

场景3：碎片化僵局（可能性：中等）

3家主要云厂商各自推出不互通的Agent Registry，企业被迫在多云环境中维护多套Agent治理体系。MCP协议的”开放互操作”承诺在实践中大打折扣。最终，一些企业选择自建Agent Registry（基于开源方案），以避免云厂商锁定。

历史参照：OpenStack试图建立开放的IaaS标准，但最终未能阻止AWS、Azure、GCP各自建立封闭的API体系。

这个场景对整个AI Agent生态的发展速度是最不利的，但在云计算行业的历史中，碎片化僵局并不罕见。

八、So What：对不同角色的行动建议

对企业CTO/CIO

AWS Agent Registry解决的是真实的痛点，如果你的企业已经深度使用AWS，现在就可以开始评估Agent Registry的预览版。但在做出全面部署决策之前，请确保你的架构团队评估了以下问题：

  1. 你的Agent元数据是否可以导出为标准格式（而非仅存在于Agent Registry中）？
  2. 你的审计数据是否有独立于CloudTrail的备份方案？
  3. 你的Agent发现和治理流程是否可以在不依赖Agent Registry的情况下降级运行？

如果以上3个问题的答案都是”否”，你正在走向深度锁定。

对AI Agent开发者/ISV

如果你正在构建AI Agent或MCP Server，注册到AWS Agent Registry是获取企业客户的有效渠道。但请同时关注：

  1. 确保你的MCP Server符合标准的MCP协议规范，而非仅适配Agent Registry的扩展特性
  2. 关注Google Cloud和Azure是否推出类似的Agent Registry，并预留多平台注册的能力
  3. 参与MCP协议的社区讨论，推动Agent发现和治理层面的标准化

对MCP协议社区

现在是推动MCP治理机制改革的关键时刻。具体建议：

  1. 在MCP协议规范中增加Agent Registry互操作性的标准定义——Agent的元数据格式、发现API、认证机制应该有跨平台的标准
  2. 推动成立一个中立的MCP治理委员会，邀请主要云厂商、AI公司和企业用户代表参与。当前以Anthropic员工为主的贡献者结构需要尽快多元化
  3. 建立MCP Agent Registry一致性认证程序，确保不同厂商的Agent Registry产品之间的基本互操作性

对投资者

Agent Registry是AI基础设施栈中一个新兴的、高价值的品类。作为历史参照，API管理平台Apigee在2016年被Google以6.25亿美元收购，而当时API经济的规模远小于今天的AI Agent生态。据IDC在2026年3月发布的预测，全球AI Agent相关基础设施市场（含开发、部署、治理工具）预计在2028年达到280亿美元规模（来源: IDC, “Worldwide AI Agent Infrastructure Forecast”, 2026-03）。Agent Registry作为治理层的核心组件，有望在其中占据可观份额。关注以下信号：

  1. AWS Agent Registry从预览版到GA（General Availability）的时间线
  2. Google Cloud和Azure的竞品发布时间
  3. 是否有独立的Agent Registry创业公司获得融资
  4. 大型企业客户对Agent Registry的实际采用情况

九、结论：开放标准的命运不应在产品发布会上被改写

AWS Agent Registry是2026年AI基础设施领域最重要的产品发布之一。它精准地识别了企业AI Agent治理的真空，并提供了一个完整的、可立即使用的解决方案。从产品角度看，它是优秀的。

但从生态角度看，它代表了一种危险的趋势：开放标准的价值正在被云厂商的产品化策略所侵蚀。MCP协议的互操作性承诺，如果仅存在于协议层面而缺失于治理层面，就像一部宪法只有条文而没有司法体系——美好但无力。

AWS没有做错任何事。它在一个没有标准的领域提供了产品。问题在于，如果行业不尽快建立Agent Registry的互操作性标准，AWS的产品就会成为事实标准。而事实标准一旦形成，再推动开放标准就会面临指数级增长的阻力。

MCP生态的健康发展，需要在Agent Registry品类成熟之前回答一个根本性的问题：谁来定义AI Agent治理的互操作性标准？是云厂商的产品团队，还是一个中立的、多方参与的治理机构？

这个问题的答案，将决定AI Agent经济是走向一个开放的、互联的生态，还是重蹈移动互联网时代iOS和Android各建围墙的覆辙。

开放标准的命运，不应在云厂商的产品发布会上被悄然改写。

参考资料

  1. AWS Agent Registry in AgentCore (Preview) — AWS, 2026-04-10
  2. Embed a live AI browser agent in your React app with Amazon Bedrock AgentCore — AWS Machine Learning Blog, 2026-04-10
  3. AWS Marketplace Discovery API — AWS, 2026-04-10
  4. Amazon and Anthropic Deepen Partnership — About Amazon, 2023-09-25
  5. MCP Protocol Specification — MCP GitHub Organization
  6. 来源: Gartner, “AI Agent Governance Survey”, 2025-10-15
  7. 来源: McKinsey, “The State of AI Risk Management”, 2026-02
  8. 来源: IDC, “Worldwide AI Agent Infrastructure Forecast”, 2026-03

主题分类：平台生态