AWS把1000个AI代理塞进一个目录，企业却担心另一件事

企业部署AI代理的数量正在以指数级增长。AWS内部数据显示，头部客户平均管理着超过300个活跃代理，部分金融和制造企业已突破四位数。但平台团队面临的困境不是"不够多"，而是"找不到"——谁建了什么、能不能用、安不安全，全靠微信群问。

代理泛滥比没有代理更麻烦

AWS Bedrock产品负责人Swami Sivasubramanian在re:Invent上提过一组数字：某零售巨头在6个月内自发涌现了147个"影子代理"，分布在7个不同部门，功能重叠率高达34%。

这不是技术债，是组织债。代理不像传统API有固定文档，它们会自己调用工具、改写提示词、甚至和其他代理组队干活。一个客服代理今天用的退货政策，明天可能就过时了，但没人通知它。

AWS这次推出的Agent Registry，表面看是个"企业级目录"，实际要解决的是三个失控现场：看不见（不知道组织里有多少代理）、管不住（谁都能发布，没有审批流）、造轮子（同一功能被重建了八遍）。

Agent Registry的底层设计：不做围墙，做索引

Registry的核心架构很有意思——它不强制代理必须跑在AWS上。

你可以把Azure OpenAI做的代理、本地部署的Llama模型、甚至竞争对手Google Cloud的Agent Engine产物，全部登记进来。Registry只存元数据：谁建的、用什么协议（MCP或A2A）、暴露哪些能力、怎么调用。

这种"agnostic"（无关平台）的姿态，在AWS历史上并不常见。通常它们更擅长把客户往自家服务里引。但代理时代的逻辑变了：企业不会把所有鸡蛋放一个云厂商篮子里，强行统一只会逼用户自建一套影子系统。

Registry支持两种录入方式。手工模式：通过控制台或API填写代理描述、所有权、合规状态、使用文档。自动模式：指向一个MCP（Model Context Protocol，模型上下文协议）或A2A（Agent-to-Agent，代理间通信协议）端点，系统自动拉取详情。

AWS工程师在预览文档里写了一句很实在的话：「Your registry can reflect your full agent landscape from day one, not only the pieces that happen to run on AWS。」（你的Registry从第一天起就能反映完整的代理版图，而不只是碰巧跑在AWS上的那些。）

治理功能：比发现更难的是"敢用"

发现代理只是第一步。企业真正头疼的是：这个代理能访问哪些数据？有没有通过安全审计？谁对它的行为负责？

Registry内置了发布审批流。平台团队可以配置规则：只有标记为"生产就绪"的代理才能被全组织可见，实验性项目仅限小范围测试。每个代理记录包含完整的血缘信息——调用链路上游是谁、下游连了哪些工具、最近什么时候更新过。

更关键的是运行时监控。Registry和AgentCore的观测能力打通，能看到哪些代理正在被调用、响应延迟多少、错误率曲线。一个代理如果连续一周零调用，系统会标记为"待退役"候选。

AWS还埋了一个容易被忽略的设计：Registry本身暴露为MCP服务器。这意味着任何兼容MCP的客户端——比如Anthropic的Claude Code、新发布的Kiro IDE——都能直接查询企业代理目录。开发者不用离开自己熟悉的工具链，就能发现组织内可复用的能力。

OAuth集成支持自定义身份提供商，这对有成熟IAM（身份与访问管理）体系的大客户是刚需。你可以用现有的SSO（单点登录）系统控制谁能发布代理、谁能订阅使用，不用另起一套权限孤岛。

标准之争：MCP和A2A的微妙站位

Registry的协议支持列表里，MCP和A2A并列出现。这背后是一场正在进行的行业标准卡位战。

MCP由Anthropic主导，设计初衷是"模型如何安全地调用外部工具"。它定义了一套声明式接口，让LLM知道有哪些工具可用、参数什么格式、返回什么结构。A2A则是Google今年3月才开源的协议，瞄准"代理与代理之间怎么对话"——更像企业级的B2B协作规范，包含身份认证、任务协商、长期会话管理。

AWS的选择是两边都支持，但不站队。Registry的元数据模型足够灵活，可以容纳两种协议描述，甚至预留了自定义schema的扩展点。

这种骑墙策略有商业考量。Anthropic是AWS Bedrock的核心模型供应商之一，Claude系列托管在AWS上；Google Cloud则是直接竞争对手，但A2A已经获得Salesforce、SAP、LangChain等厂商背书。过早押注任何一方都可能得罪另一边。

不过技术细节透露了真实倾向：Registry的自动发现功能，对MCP端点的支持更成熟。指向一个MCP服务器URL，系统能解析工具列表、参数schema、示例调用。A2A端点目前需要更多手工配置。这种差异可能随预览版迭代缩小，也可能反映了AWS内部的技术优先级。

AgentCore的全盘棋：从单点工具到操作系统

Registry不是孤立产品，它是AgentCore的组件之一。要理解AWS的野心，得看完整版图。

AgentCore今年早些时候发布，定位是"构建、连接、优化大规模代理的平台"。三个关键词：任何模型（OpenAI、Anthropic、Meta、自研都支持）、任何框架（LangChain、LlamaIndex、原生代码均可）、任何架构（单体代理、多代理协作、人机回环）。

Registry解决的是"建完之后怎么办"。与之配套的还有：Agent Builder（可视化编排代理）、Multi-Agent Orchestrator（多代理协作调度）、Observability（全链路追踪）。这套组合拳的目标很明确——让AWS成为企业代理基础设施的默认选择，就像EC2之于虚拟机、S3之于对象存储。

但竞争对手没闲着。Microsoft的Copilot Studio正在整合Azure AI Agent Service，强调和Microsoft 365生态的打通。Google的Agent Engine走深度集成路线，Vertex AI上的代理能直接调用BigQuery、Cloud Storage等企业数据资产。开源阵营，LangGraph和CrewAI在开发者社区势头很猛，灵活性是最大卖点。

AWS的差异化赌注是"中立性"。不绑定特定模型、不预设框架、不假设部署位置。这种开放姿态对有多云战略的大型企业有吸引力，但也意味着集成复杂度更高——客户得自己把碎片拼成完整工作流。

预览版文档里有个细节：Registry目前对单个代理的元数据大小限制为1MB，对复杂代理（携带大量示例、详细提示词、多版本历史）可能不够用。AWS表示会根据反馈调整，但现阶段需要用户做取舍。

另一个未解问题是版本管理。代理和软件不同，行为可能随底层模型更新而漂移。Registry记录了"发布时间"，但没有原生的"行为版本"概念。一个基于Claude 3.5 Sonnet构建的代理，在模型升级到3.5 Sonnet v2后，输出稳定性如何保障？目前看来，这需要组织自己建立测试和回滚机制。

企业客户最迫切的反馈是什么？AWS产品团队没有公布预览版用户名单，但技术文档里回应了几个高频需求：与ServiceNow等ITSM平台的集成（让代理变更走正式工单流）、成本分摊标签（按部门/项目追踪代理运行开销）、合规报告导出（满足SOX、GDPR审计要求）。这些功能的时间表尚未公开。

Registry的定价策略也还在迷雾中。预览版免费，但正式版会按什么维度收费？存储的元数据量、API调用次数、还是代理数量？AWS历史上有过多种尝试——CloudWatch按日志量、EventBridge按事件数、Config按配置项。代理Registry的计费模型，将直接影响企业采用策略。

一个可能的参照是AWS Service Catalog，它解决的是类似问题（企业级服务目录），按API调用和存储收费，价格区间对企业级客户可忽略。但代理Registry的调用频率可能高一个数量级——每个代理启动时都可能查询Registry发现可用工具，实时计费模式需要精心设计。

技术社区的反应分化明显。平台工程师群体普遍认可Registry的概念——"终于不用维护那个该死的Confluence页面了"。但一线开发者有人吐槽：又多了一个需要申请权限的系统，发布代理的摩擦成本不降反升。

这种张力正是治理与敏捷的经典矛盾。Registry的设计试图平衡两者：审批流可配置为自动通过（对实验环境），也可设置为多级会签（对生产系统）。但组织政治往往比技术设计更难标准化——谁有权定义"生产就绪"的标准？安全团队和工程团队的拉锯，Registry解决不了。

更深层的问题是代理的"可组合性"承诺能否兑现。Registry让发现代理变容易了，但"复用"代理比复用代码库复杂得多。一个客服代理依赖的退货政策API，在另一个业务线可能完全不同；一个数据分析代理用的SQL方言，在Snowflake和Redshift之间有微妙差异。

AWS的应对是引入"Agent Skill"（代理技能）作为复用单元——比完整代理更细粒度，类似函数库的概念。但Skill的抽象边界怎么划、版本怎么管、依赖怎么解，文档里语焉不详。预览版的真实测试，将暴露这些设计在复杂场景下的成色。

对比开源替代方案，Registry的锁定风险是讨论焦点。LangChain的LangSmith、LlamaIndex的LlamaCloud都提供类似的代理管理能力，但深度绑定各自框架。Registry的优势是框架无关，代价是功能深度可能不如专用方案。企业需要评估：代理栈的统一治理，值不值得牺牲部分最佳实践？

行业分析师的视角更宏观。Gartner将"AI Agent Governance"列为2025年十大战略技术趋势之一，预测到2027年，60%的企业将因代理管理不善而遭遇重大合规事件。Registry的推出时机，踩准了这个焦虑窗口。

但技术本身不是解药。AWS解决方案架构师在一场内部培训中坦言：「我们见过太多客户，买了全套工具，但代理还是各自为政。Registry是基础设施，组织变革才是瓶颈。」（We've seen too many customers buy the full toolkit, yet agents still operate in silos. Registry is infrastructure; organizational change is the bottleneck.）

这种诚实很少出现在官方宣传中。它指向一个 uncomfortable truth：代理治理的难点不在技术栈，而在权责划分。当一个客服代理自动批准了超额退款，谁担责？客服部门、建代理的AI团队、还是审批代理上线的平台组？Registry能记录血缘，但判定责任需要组织流程。

预览版的局限也值得正视。跨区域部署的企业需要注意：Registry目前仅在us-east-1、us-west-2、eu-west-1等少数区域可用，全球统一目录需要额外同步机制。与AWS Organizations的集成处于早期阶段，多账号架构下的权限继承规则还在打磨。

性能基准同样缺失。Registry的查询延迟、并发承载能力、索引更新时效，这些生产环境关键指标尚未公开。一个数千代理规模的企业，Registry会不会成为新的单点瓶颈？AWS的回应是"预览版不承诺SLA，正式版会有详细规格"。

生态系统的反应正在形成。MCP社区对Registry的MCP服务器模式表示欢迎，认为这降低了企业采用门槛。但也有声音担忧：AWS会不会通过Registry收集代理使用数据，反哺自家模型训练？隐私条款中的数据使用范围，需要法务仔细审视。

A2A阵营的态度更微妙。Google Cloud工程师在社交媒体上的评论被解读为"谨慎乐观"——乐见协议获得大厂支持，忧的是AWS implementation（实现）是否与Google的reference design（参考设计）完全兼容。协议层面的细微差异，可能导致跨云代理协作时的行为不一致。

开发者工具的整合进展不一。Claude Code的MCP支持已经可用，Cursor、Windsurf等热门IDE的适配还在社区驱动阶段。Registry的价值很大程度上取决于开发者是否愿意在日常工作流中查询它，而不是直接问同事或翻GitHub。

企业采购决策的考量维度比技术特性更复杂。现有AWS承诺消费（ECP）的客户，Registry作为Bedrock组件可能纳入现有合同，降低采购摩擦。但独立评估时，需要对比Microsoft Copilot Studio的代理管理、ServiceNow的AI Agent Fabric、甚至Palantir的AIP等垂直方案。没有放之四海的最佳选择，只有组织现状的局部最优。

Registry的长期演进方向，可以从AWS的产品路线图碎片中拼凑。多模态代理支持（处理图像、音频、视频的代理元数据）、实时协作编辑（多人同时修改代理配置）、智能推荐（基于使用模式建议相关代理），这些功能在内部演示中出现过，但预览版尚未开放。

更激进的设想是Registry成为跨企业的代理市场。AWS Marketplace已经有算法和模型交易，代理作为更完整的解决方案单元，理论上可以上架销售。但这涉及复杂的责任界定和SLA承诺，短期内更可能是"私有目录"模式——企业间双边协议，而非公开集市。

技术债务的隐喻需要更新。传统软件债是代码层面的，代理债是行为层面的。一个代理今天能正确处理退货，明天可能因为上游政策API变更而开始胡说八道。Registry的元数据记录了"设计时"状态，但"运行时"的漂移监控，需要配合AgentCore的观测能力才能闭环。

组织采纳的典型路径正在浮现。先锋团队通常是平台工程或AI Center of Excellence，他们用Registry建立治理基线；然后推广到业务部门的"公民开发者"，通过模板和审批流降低门槛；最后连接企业架构审查，将代理纳入正式的IT资产管理体系。全程可能需要12-18个月，与AWS的预览到正式版周期大致重合。

一个未被充分讨论的维度是代理的"社交"特性。人类员工有组织架构、汇报关系、绩效评估，代理目前还是技术资产。但当一个代理被数十人依赖、年处理百万级交互时，它的"组织身份"是否需要更正式的界定？Registry的"所有权"字段是起点，但远未触及深层问题。

对比数据库治理的演进或许有启发。二十年前，DBA（数据库管理员）是稀缺角色；后来数据治理平台出现，将权限、血缘、质量规则自动化；现在Data Mesh架构下，领域团队自治成为主流。代理治理可能走类似路径：从集中管控，到平台赋能，最终走向联邦制。

Registry的设计预留了这种演进空间。它的权限模型支持细粒度控制，既可以是中央平台团队全权管理，也可以是各业务线自主发布、仅受合规规则约束。这种灵活性是AWS的架构传统，也是客户需要自行填补的决策空白。

培训和支持体系的成熟度将是 adoption（采用）的关键变量。AWS的文档质量一贯较高，但代理治理是新兴领域，最佳实践尚未沉淀。客户成功团队能否提供行业针对性的治理模板，而不是通用技术文档，将区分试点项目和规模化部署。

竞争对手的回应已经在路上。Microsoft Build 2025预计将公布Azure AI Agent Service的目录功能，深度整合Entra ID权限体系。Google Cloud Next可能会有Agent Engine的企业治理更新。Registry的先发优势窗口期，可能只有6-12个月。

最终，Registry的价值不在于技术本身有多精巧，而在于它能否成为企业代理战略的"共识层"。当不同团队争论该自建还是复用、该用LangChain还是原生SDK、该托管在AWS还是多云时，Registry提供了一个中立的参照系——至少，我们知道有什么。

这种"知道"是治理的前提，也是创新的约束。太松则混乱，太紧则窒息。AWS把调谐旋钮交给了客户，但旋钮该转到哪档，每个组织得自己摸索。

Agent Registry的预览版申请已经开放，首批用户反馈预计在未来90天内陆续公开。一个值得追踪的指标是：登记代理的中位复用次数——如果大多数代理只被创建者自己使用，Registry就退化为昂贵的清单工具；如果跨团队复用率达到显著比例，它才真正改变了代理经济的成本结构。

你的组织现在有多少AI代理？有多少能被你同事发现和使用？这个问题，可能比Registry的任何功能特性都更能预测它的实际价值。