MongoDB 博客：为何企业需要自建 AI 工具注册中心

MongoDB 博客发文讨论企业 AI 智能体规模化部署后的工具管理问题，主张每家企业都应建立自己的共享工具注册中心，而不是采用 npm、PyPI、Maven 这类公共包管理器。文章认为，这类基础设施应限定在企业内部，服务于自身团队、数据与政策，在行业尚处早期时扩大范围属于过早标准化。 文章把注册中心的价值归为两根支柱：降低协调成本与支撑风险管理。文中引用麦肯锡的说法称，多数大型组织中的智能体工具由各团队临时搭建，缺乏文档与治理，组织内其他团队无从知晓；结果是重复建设、安全审查遗漏未登记工具，出问题时也无人掌握全貌。文章类比软件行业的包管理器，认为防止重复与不一致是基础设施问题，而非纪律问题，并提到 Kong 于 2026 年 2 月推出企业级 MCP Registry 时也点出了手动配置 MCP、工具跨团队隔离、集成碎片化与组织可见性有限等问题。 安全数据方面，文章引用 Gravitee《The State of AI Agent Security 2026》调查：在已越过规划阶段的团队中，只有 14.4% 获得完整安全审批，88% 的组织当年发生过智能体相关安全事件，仅 22% 的组织把智能体当作独立身份对待。文章强调注册中心本身不提供安全，但让安全工作成为可能——安全团队无法审查自己发现不了的工具。 文章还讨论了默认放行的治理姿态，引用 AgilityFeat 的分析称非 deny-by-default 架构会放大风险与维护成本，并引用 Frontegg 的治理框架说明策略层需要把智能体动作映射到细粒度护栏，而这些护栏依赖注册中心提供的工具清单。 关于生产级工具目录，文章列出四项能力：发现、版本管理、认证元数据与访问控制。发现让团队先搜索再新建，并按功能域分层组织；版本管理用于回答智能体行为变化来自模型、工具提示词还是底层 API；认证状态（安全审批、API 契约校验、PII 处理检查）由注册中心呈现，实际审查仍在安全团队既有工具中完成；访问控制由策略层按智能体身份、团队、环境与动作类型执行，并从注册中心读取工具归属。文章最后称，不作为的代价是直接的：工具难以被找到，团队便不断重造，形成冗余与技术债。