当企业上线第二批、第三批智能体时，安全团队往往会问出一个看似简单的问题：生产环境里现在到底有哪些智能体在运行？如果没人能给出完整名单，问题就不在模型能力，而在于缺少一类基础记录：智能体注册表。
注册表的价值不在于“登记”，而在于把治理动作挂到具体对象上。它首先是资产可见性工具，让企业说得清智能体的数量、归属和状态；其次是责任追溯依据，任何一个智能体出问题，都能找到对应的业务负责人；再次是变更审计的入口，模型切换、提示词调整、工具接口变更都能对应到具体版本。没有这层索引，权限管理、评测和成本核算都会落空，因为不知道对象是谁。
构成：六类字段撑起可治理的最小单元
从实践看，注册表至少要覆盖六类信息：唯一负责人、版本号、接入系统清单、权限清单、评测结果和变更记录。这六项并非并列的表格字段，彼此之间存在引用关系：权限清单决定智能体能调用哪些工具，评测结果对应某个版本，变更记录则把版本、权限和评测串联起来。缺少任何一项，注册表都会退化成静态台账。
需要强调的是，注册表不应由项目团队各自维护。一旦各团队用自己的文档记录，字段口径很快分化，跨场景比对和审计就无从谈起。它更适合作为平台层公共设施的一部分，与工具网关、知识治理、评测流水线并列，由平台团队统一承载，业务团队负责填充和更新。
判断注册表是否真正可用
衡量标准很直接：故障发生时，能否快速定位到具体智能体、具体工具调用和具体版本；权限发生变更时，能否看到谁批准、何时生效、影响哪些场景；新场景复用时，能否直接查到已有的接入方式和评测基线。如果这些动作仍需临时找人问、翻聊天记录，注册表就还停留在“有表格”的阶段。
规模化之前先建注册表，看似增加了一道工序，实际是在减少后续反复排查的成本。智能体数量越多，这张索引越难补建。