应对工具泛滥：AI工具注册中心的必要性

标题：应对工具蔓延：AI工具注册表的必要性

原文链接：https://www.mongodb.com/company/blog/technical/fighting-tool-sprawl-case-for-ai-tool-registries

发布时间：2026-05-11T00:00:00.000Z

随着企业级AI智能体的规模化应用，缺乏集中化的组织级工具基础设施正在产生持续累积的成本。当实施策略围绕部署速度进行优化时，企业将面临多重风险叠加：重复的工程投入、安全暴露和运营不透明。

每家企业都需要建立自己的共享工具注册表，这个注册表应当反映其特定的监管环境、安全策略和运营规范。需要明确的是，这里讨论的并非公共包管理器（如npm、PyPI或Maven）。每家企业需要的基础设施都是内部性质的，其范围应限定在自有团队、自有数据、自有策略和自有领域内。在这个快速发展的新兴领域，试图将范围扩展到单个组织之外将导致不成熟的标准化。

共享企业工具注册表不是优化项或锦上添花的功能。当智能体部署规模超越早期实验阶段时，它就成为必不可少的基础设施。其必要性建立在两大支柱上：降低协调成本与实现风险管理，这对使用智能体的开发人员和智能体自身都至关重要。

AI智能体依赖的工具需要实现数据检索、记录写入、工作流触发和外部API调用等功能。根据麦肯锡的报告，在大多数大型组织中，这些工具由各个团队以临时方式构建：缺乏文档记录、缺乏统一管理、对其他团队不可见。这种模式对大多数技术管理者来说都很熟悉，而由此产生的碎片化问题随着每个新智能体的部署不断加剧。团队重复构建已存在的功能，安全审查漏检未注册的工具，当出现故障时，没有人能完整掌握运行中的组件及其运行原因。

基础设施层面的协调失灵

软件行业早在数十年前就通过包管理器解决了类似问题。集中式注册表为团队提供了发现、依赖和管理共享代码的途径。经验很明确：防止重复和不一致是基础设施要解决的问题，而非纪律问题。

智能体时代在新领域呈现了相同的问题。当Kong于2026年2月推出其企业级MCP注册表时，他们明确指出了手动MCP配置、跨团队硬编码和管理工具隔离、碎片化集成以及有限的组织可见性等问题。

碎片化的工具开发并非工程实践不当的结果，而是让团队在应用层解决基础设施问题的必然结局。

可见性缺失问题

Gravitee发布的《2026年AI智能体安全现状》调查报告量化了智能体工具对负责安全的人员不可见时产生的后果。调查发现，在超越规划阶段的智能体团队中，仅14.4%获得完全的安全审批，而88%的组织今年都遭遇过与智能体相关的安全事件。共享API密钥等不良做法普遍存在，仅22%的组织将智能体视为独立身份。这种治理缺口将智能体从生产力助推器转变为高速负债，它们能在人工干预前执行未授权操作或泄露敏感数据。

现状很清楚：应用速度超越了治理速度，在追求速度的竞赛中，历史教训正在重演。大多数已部署的智能体（及其支持的MCP服务器）在没有任何安全审批的情况下运行。这主要不是资源不足导致的问题，也不是单靠注册表就能解决的。安全团队无法审查他们发现不了的资源，而没有注册表时，发现过程只能依靠手动操作，且不完整、信息滞后。注册表本身不会让工具变得安全，而是通过确保工具不是作为临时性、临时拼凑的垫片存在，而是作为可被审计和策略管理的清单化资产，从而使安全工作成为可能。

此时值得重新审视公共包管理器。这些注册表未能消除诸多安全问题，例如域名仿冒、恶意软件包和依赖混淆，这清楚地表明单纯集中化并非安全解决方案。但它们也证明了反向逻辑：注册表是安全的前提条件。这些生态系统中针对安全漏洞的众多社区响应，展现了集中化带来的协调力量。集中化不能保证安全，但去中心化将丧失协调安全的能力。

治理需要共享上下文

大多数智能体部署的默认策略是许可制：工具默认可用，除非被明确阻止。AgilityFeat对企业AI防护栏的分析指出了这种模式带来的结构性风险，因为非默认拒绝的架构会增加风险并产生维护成本。

默认允许的策略在数十个独立智能体部署中复制，使得攻击面随着采用规模同步扩大。要扭转这种局面需要建立协调点——一个跨整个组织的共享上下文环境。注册表本身并非治理层，但它为治理提供了基础。当每个智能体可使用的工具都登记了归属权、版本和审查状态时，治理层才有了具体的执行依据。缺乏这种上下文，每个使用团队就不得不重新制定策略，一致性也就无从谈起。

Frontegg的AI智能体治理框架从操作层面描绘了策略层的形态：将智能体行为映射到明确、细粒度的防护栏，这些防护栏定义了任何智能体可尝试或执行的操作边界。虽然防护栏存在于注册表之外，但它们依赖注册表而存在。如果某个防护栏引用了安全团队闻所未闻的工具，这样的防护规则根本无从制定。

生产级工具目录的必要条件

成熟的企业工具注册表具备两大核心功能——发现与版本管理，并作为另外两项功能的基础：认证元数据和访问控制。可以将其视为专为智能体时代构建的内部开发者门户（IDP），它解决了当年IDP为服务团队解决的协调问题，只是层级更高。

发现功能让任何构建智能体的团队在编写新工具前都能搜索现有工具。通过集中管理归属权元数据、版本历史和使用指标，重复建设得以减少——不是通过强制规定，而是通过降低使用门槛。精心设计的目录远不止平面列表：工具应按功能域进行层级分组，让人工和智能体都能快速找到相关能力。

版本管理填补了发现和访问控制均未解决的空白：当智能体行为发生变化时，如何追溯变更根源？具备版本追踪功能的工具注册表让企业能够清晰解答这个问题。是模型变更？工具提示更新？还是底层API变动？缺乏完善的版本管理，寻找答案就会从简单的差异对比变成耗时的人工调查。

认证状态（包括安全审批、API合约验证、个人身份信息处理检查等）是注册表呈现的元数据，而非注册表本身执行的边界。实际审查工作通过安全组织的现有工具完成。注册表的贡献在于让审查结果在团队决定是否采用工具时立即可见，确保审查工作真正影响决策过程。

访问控制的运作方式如出一辙。策略层根据智能体身份、团队、环境和操作类型执行授权规则，通过读取注册表了解现有工具及其归属情况。注册表的集中化管理使得访问控制能够统一实施，而非迫使每个团队自行定制方案。

当每个团队都维护自己孤立的工具栈时，这些目标都无法实现。平台团队早已理解IDP存在的意义，这种范式在智能体环境中的价值并无二致。

不作为的复合成本

不作为的代价是直接的，不仅限于运营和安全层面。如果没有可搜索、组织有序的工具目录，团队将持续重复造轮子，因为生成新工具比寻找现有工具更省事。重复建设意味着冗余和技术债。通过使工具可发现、可复用，注册表将冗余投入转化为实际工作产能。

对平台工程团队而言，发展轨迹非常清晰。智能体采用率正在上升，工具重复建设随之增加，小规模时有效的临时方案随着智能体和工具数量增长将难以为继。Gravitee调查中记录的安全风险若不进行结构性干预，只会扩大而非缩小。

现在建设集中式工具基础设施的组织将能快速接入新智能体，保持统一治理，并在出现问题时及时审计。那些拖延的组织将艰难地重新领悟平台团队十年前获得的教训：协调问题不会在应用层自动解决，只会在那里不断加剧。

###### 后续步骤

工具注册表是更广泛基础设施问题中的一个层面。请关注《设计智能体平台》系列文章，深入了解记忆、编排、状态和可观测性等架构设计——这些正是与工具注册表协同运行的组件。