代理注册表能告诉你存在什么，却无法说明你是否还能信任它。
一个涵盖存在性、适用性、可靠性及来源信息的四项问题框架，用于构建智能体能力注册系统，同时还提供一项可立即运行的简单最终验证测试。
想象一下，在一次常规运行中，一个代理通过名称查找某个工具，调用它，得到合理的响应后继续执行任务。这次运行成功了，而这恰恰令人担忧，因为团队中没有人对这一功能进行过审查。注册表和发现服务本应能够控制这类情况，然而仅仅一周之内，就有好几款产品和规范出现，都声称自己能承担这一控制功能。
这些产品并没有错，但加在一起也只能解决代理使用新功能前团队所需了解信息的一半。本文将这个问题分解为四个独立的问题，指出现有注册表能回答哪些问题，并为那些尚未解决的问题提供具体的检查方法以及简短的行动清单。
注册表层中出现了什么
以下内容为撰写本文时的公告信息；在依赖特定功能或版本号之前，请先查阅最新文档。
AWS Agent Registry
AWS上的Agent Registry现已全面可用。它可以被视作一个内置治理机制的私有目录，用于存储代理、MCP服务器、A2A代理卡片、技能以及各种自定义资源。其设计刻意将两个层面分开：管理人员在工作于治理层面，负责审批条目；使用者则查询发现层面，该层面仅展示已获批准的条目。每条记录会经历五个状态（草稿、待处理、已批准、已拒绝、已废弃）。EventBridge事件负责触发状态转换，而CloudTrail则用于记录审计日志。
随着全面上市，该平台还提供了代码化基础设施支持（CloudFormation、CDK和Terraform），可通过RAM在多个账户间共享资源，同时还能在整个组织范围内自动检测已在AgentCore上运行的代理程序。这一检测功能很容易被忽视，但其存在的原因是那些未被追踪的“影子”代理早已成为库存管理方面的重大难题。采用该技术的公司包括西南航空、百事公司、先正达、Amdocs和索尼，这表明采购方已不再局限于试点阶段的讨论。AWS在其机器学习博客上详细介绍了该设计。
代理资源发现（ARD）
与此同时，还有由多家厂商共同制定的规范正在填补这一空白。Agentic Resource Discovery由谷歌、微软和Hugging Face的开发者共同编写，采用Apache 2.0许可证发布，NVIDIA、Salesforce和Databricks也参与了贡献。The New Stack的相关报道将其描述为代理节点的DNS系统。该规范的接口设计得相当简洁，消息通过REST协议以JSON-LD格式传输。必须存在一个端点，即POST /search，查询时需要提供任务描述而非资源名称。浏览类端点则是可选的。该规范支持联合机制，企业可以将其内部目录保密，同时将查询转发给其信任的外部注册系统。截至本文撰写时，该规范的版本为0.91，其管理机制仍在完善中，W3C被认为是可能的归宿之一。
作为产品存在的持续审核机制
第三家推出的公司是一家初创企业AIR，它在两轮种子轮融资中筹集了5000万美元（第一轮由红杉资本领投，第二轮由Greenoaks领投）后才公开亮相。该公司的业务是检测代理商所使用的插件、技能及MCP服务器。他们提供的一个数据值得注意：目前他们评估的公开来源技能和插件中，约有27%会被过滤掉。
当有三家公司在短短几天内针对同一领域推出产品时，通常意味着业界已经就缺失的关键环节达成了共识。
为何发现功能并非MCP的职责
MCP从未宣称自己能够解决工具发现的问题。它只是规定了在智能体已经确定要使用哪个工具之后调用该工具的机制。A2A则用于处理彼此已相互了解的智能体之间的对话。在这两种情况下，定位并选择所需功能这一步骤都被视为早已完成。如需回顾这一区分，可参阅Model Context Protocol如何帮助智能体发现并调用工具。
变化在于规模。手动连接MCP服务器时，使用十几种工具就足够应对。但当有上千个服务器分散在不同的内部团队、SaaS提供商和云平台手中时，那些配置中仅限于硬编码列表的代理几乎算不上真正的代理，更像是会调用模型的固定脚本。发现机制使得这些功能集能够在运行时发生变化。但同样的特性也意味着没人对这些功能集进行过审计，而且很少有团队能充分考虑这种权衡带来的影响。
另一重压力来自智能体扩展的方式。研究人员分析了11个生产级编码框架的源代码，这些框架总计约400万行，涵盖了OpenHands、Gemini CLI、Codex CLI和Claude Code等工具（arXiv 2609.00006），发现采用SKILL.md格式定义的技能已在这些框架中取代了MCP：11个框架中有9个支持技能功能，8个支持MCP。因此，扩展速度最快的其实是那些包含智能体执行指令的Markdown文件。这类文件没有签名机制，也几乎没有版本控制，所以仅凭注册表中的条目很难预测其未来的功能表现。
注册表应回答的四个问题
每当某个代理准备使用它近期尚未具备的功能时，就需要四个独立的答案。这些问题的答案看似相似，但实际上属于不同的问题；将它们区分开来才能明确某个产品实际具备的功能与其被购买时所期望的功能之间的差异。
存在性：是否有能够实现此功能的产品？
是否存在可以处理该任务的功能，它又部署在何处？这就是ARD的POST /search功能要解决的问题，而AWS的发现机制在这方面表现优异。这个问题确实存在，从实际应用角度来看，它已经接近解决。
适用性：哪个候选产品最适合这项任务？
搜索会返回多个候选项，那么代理应选择哪一个呢？ARD的作者们自己也认为在此处DNS对比方法已不再适用：查询结果给出的是多个候选项而非唯一的权威地址，而且每项服务都会应用自身的信任与排序规则。对于一个尚处于发展阶段的规范来说，保留这种灵活性是合理的；但对于实际部署而言则不合理，因为排序机制正是攻击者最想介入的地方，就像搜索引擎污染或软件包注册表中的域名抢注行为一样。
现状：它目前已被批准了吗？
这正是 AWS 最强的优势所在：生命周期状态与事件相结合，能够提供结构清晰的答案，其成熟度远超这些系统中的其他方案。不过缺点是审批状态会过期。假设某条记录通过自动检测被识别出来，3月获得了批准，之后却被忽略。到了9月，发现系统仍会像它今天早上被管理员检查过一样自信地将其呈现出来。
来源信息：谁创建了它，有哪些变化？
谁开发了这项功能？自上次检查以来有哪些变化？它在运行时会加载什么内容？当前发布的版本中没有任何信息能回答这些问题，而这正是AIR获得资金支持的依据。他们的观点仍然成立，即审查必须持续进行，而非仅一次性完成。一个月前通过审核的技能，在依赖项更新或维护者账户被劫持后可能会变得具有恶意，但其目录条目却依然完全不变。学术研究也指向同一方向。关于基于技能的智能体基础的最新研究（arXiv 2608.29596）将其生命周期划分为九个阶段，并将公共注册表、市场平台以及对手置于架构的核心位置，而非将其视为事后才考虑的因素。
搜索问题与供应链问题
前两个问题与搜索相关，后两个则涉及供应链。该行业此前在浏览器扩展、容器基础镜像以及npm包方面也曾经历过类似情况。在每一种情况下，目录早在有人能够保证其中内容的质量之前就已存在，而安全事件也多发生在这一时期。
最近一次验证的测试
这项检查的设计规模较小，因为答案比框架本身更为重要。取你当前记录的代理功能列表——无论是正规的注册表还是简单的电子表格——然后选择其中任意一条记录。接着查找两个时间戳：
- 它是什么时候被批准的？
- 最近有人或自动任务对其源代码进行过比对是什么时候？
当这些时间戳一致时，你手中握着的其实是目录而非控制平面。前者记录的是过去的决策，后者反映的是当前的现实。计算两个日期之间的天数：这就是某人批准后又遗忘的功能在无人察觉的情况下可被随意修改的时间长度。鉴于大约四分之一的公开技能已无法通过基本审核，这一数字足以反映你实际面临的风险程度。
许多团队没有第二个时间戳可供显示。这种缺失才是真正的问题所在：问题不在于数值不良，而在于字段缺失。
本季度该做什么
实际可行的计划分为三部分，按所需投入精力从少到多排列。
- 采用注册表机制。资产清单确实是个严重问题，而未经监控的代理程序因其能自主运行，比未经监控的SaaS订阅服务更具危险性。已经在Bedrock平台上开发的团队应认真考虑AWS选项；那些需要联合管理及供应商中立性的团队则可能更倾向于ARD。
- 补充注册表所缺失的字段。为每个条目设置一个由自动化任务更新而非人工操作的最后验证时间戳。需提前确定何种情况会触发条目失效：到期、被隔离还是发出警报。无论采用哪种方式，都比目前常见的那种条目无限期保持有效的情况要好。
与这一方案相辅相成的是运行时控制层，它负责决定已发现的功能实际上能够执行什么操作；代理的权限、审批机制与风险等级涉及了这方面的内容。
关键要点
- 注册表及发现规范如今已能较好地回答“存在什么”以及“是否经过审批”这两个问题。