智能体清单与登记册

自主申报的清单会失败，原因有三条是结构性的，而不是一条文化上的。

惯常的诊断是"工程师不填表"。这话没错，但它是三个失败里最无趣的一个——因为另外两个，即便所有人都乖乖填表也照样存在。

• 登记只发生一次，而系统每周都在变。三月登记时它有两个工具、一个覆盖帮助中心的检索索引；到了七月，它有九个工具、一个数据库写入权限，还换了模型。表格里那一行对一个已经不存在的系统描述得很准确，而流程里没有任何环节会察觉。
• 真正值得关注的智能体，从来就不是"项目"。承载真实风险的，往往是那些没人把它当作 AI 立项的东西：某人接到厂商 API 上的一个脚本、业务团队在某个 SaaS 里打开的一项自动化、一个靠一个个 PR 长出工具的内部助手。它们谁也没有经过掌管登记册的那张办公桌。
• "智能体"没有公认的边界，于是"有多少个"变成了一场定义之争。提示词模板算智能体吗？只有一次模型调用的工作流呢？运行时派生的子智能体呢？各团队答案不同，而一份记录单元本身有争议的清单，无法与任何东西对账。STEP 3 解决这个问题，而正是这个解法让其余部分得以成立。

从智能体三样绕不开的东西里把它推导出来。

一个在生产里跑的智能体必须有凭据、必须有通往模型的网络路径、必须花钱。这三者你本来就在运营，每一个都不用谁自愿申报就会留下记录，而三者合起来的完整度远胜任何问卷。

• 凭据签发。每个智能体都握着某个东西的令牌——模型厂商、数据库、内部 API。如果凭据是集中签发且短期有效的，那份签发日志就是总体，而它签发给的那个身份就是天然主键。这正是受限凭据与智能体身份在治理上的回报，也是它们值得先建的理由。
• 网关。如果模型调用都走代理，那么无论有没有人登记过，每一个调用方都会带着模型、用量与时间区间出现在它的日志里。一个为控成本而部署的网关，最终成了全组织覆盖率最高的发现工具。
• 账单。厂商发票与云成本分摊能浮出那些躲开了另外两道控制的负载——一个团队拿自己的 API key 刷公司卡，对你的网关不可见，对财务却可见。归属不明的支出，就是发现队列。
• 然后对账，并把每一处不一致都当成一条发现。凭据日志里有身份、登记册里没有条目，那是影子智能体。登记册里有条目、九十天没有流量，那要么是"已下线但凭据还在"，要么更糟——一个没人记得、却还握着令牌的系统。这两者都比任何问卷的回收结果更可采取行动。

记录单元不是"一个智能体"，而是那份授权。

这一步决定了登记册究竟有用还是只是仪式。"客服智能体"是一个产品名字，不是一个你能评估的对象——因为顶着这个名字的两次部署，可能在监管者或事故响应人员会问到的每一项上都不一样。

• 记录那个元组，而不是那个名字：智能体身份、它持有的工具授权、这些工具触达的数据范围、为它服务的模型与版本、自治层级（建议、经批准后行动、自行行动），以及部署环境。这六个字段才是会变的东西，也才是下游每一个问题真正问的东西。
• 给元组做版本，并保留历史。事故或审计时到来的问题从来不是"它能干什么"，而是"5 月 14 日那天它干了什么"。一份只保存当前状态的登记册答不上来，而八个月后从部署日志里重建答案，正是严重事件报告记录过的那种昂贵失败。
• 让子智能体继承，而不是繁殖。一个在运行时派生工作者的主管，不产生五十条登记条目；它产生一条，其授权覆盖工作者可能持有的范围。把拓扑记下来，并记下"委派不得超出父级授权"——这既是记账要求，更是设计要求。
• 每一条都要有一个具名的责任人，一个活人。不是团队别名。"必须有一个具体的人可被问责"正是问责与归属的全部内容；而一条没有责任人的条目，就是那个在团队重组两年之后还揣着凭据在跑的东西。
• 登记时分级，变更时重分级。风险等级、是否涉及个人数据、输出是否会抵达公司之外的人。这些字段一开始定一次，然后恰恰在智能体变得有意思的时候开始腐烂——所以要把重分级绑定到元组的变更上，而不是绑定到年度评审上。

让登记册承重：没有条目，就没有凭据。

一份只做观察的登记册必然漂移，因为没有任何东西依赖它是对的。而一份坐在签发路径上的登记册漂移不了，因为不在其中的智能体根本跑不起来。

• 登记变成一道部署时的关卡。凭据代理拒绝为没有登记条目、没有责任人、或元组与所请求授权不匹配的身份签发令牌。这只是一次集成，却把整件事从"文档"变成了"控制"。
• 登记 ID 随轨迹流动。每次运行都带着它，于是成本、评测、事故与审计记录全都能按同一个键关联。没有这一点，登记册是一座孤岛；有了它，"把这个智能体五月的每一次运行连同结果都给我列出来"就是一次查询，而不是一个项目——这正是追踪与可观测性一路铺垫的方向。
• 改元组是一次变更申请，不是一次编辑。加一个工具、放宽一个数据范围，要走与代码相同的评审，跑在发布与版本管理那套机制上。它防住的失败模式是：某个智能体在周五那次部署里拿到了数据库写权限，而评估档案上它还是只读的。
• 合规产物由登记册生成，不要另外维护。证据包、风险分级清单、处理活动记录——每一份都该是同一份数据的一次渲染。两份手工维护的名单必然互相矛盾，而你拿给审计员看的那份，一定是过期的那份。
• 当心登记册自己变成瓶颈。如果登记要花一周，团队就会绕道，于是你回到了影子智能体，还外加一套流程。做法是：首次申请凭据时自动登记，最低风险等级之上的再事后评审——把摩擦留在风险所在之处，这正是不僵死的治理所主张的平衡。

第三方智能体也在范围内，而且它们是难的那一半。

最可能不在你登记册上的智能体，恰恰是那些不是你造的。它们经由采购进来，经由你早已拥有的软件里的一个功能开关进来，并且越来越多地经由某位工程师装上的一个插件进来。

• 厂商功能不经采购决策就变成了智能体。一款 SaaS 产品发布了一个助手，它读你的数据、在你的数据上采取行动；没有人买过 AI 系统，于是没有人登记过 AI 系统。把厂商清单捋一遍，专找那些"被启用"而非"被采购"的能力——这一遍捋下来找到的智能体，稳定地多于内部问卷。
• 装上一个插件，就是一次授权。一个既携带指令、又携带已配置工具服务端的捆绑包，会以安装者的凭据扩大智能体能读到、能触达的范围。把安装登记为元组的一次变更，并在它落地之前读一读智能体供应链安全该查些什么。
• 把你无法查验的部分记下来，并明确标注。对一个第三方智能体，你不会有模型版本，也不会有工具清单。那就登记你确实掌控的部分——它触达的数据、它能采取的行动、合同与责任人——并把未知项显式标出。一处诚实的空白是可治理的，一行空白不是。尽调该问什么，见第三方模型与厂商风险。
• 下游的部署方也需要从你这里拿到同样的事实。如果你交付的智能体由别人运营，那么披露义务与使用说明都要从登记册取数——这也正是那些字段必须结构化、而不能是散文的原因。

把它运营起来：定期对账，并让"下线"成为某个人的职责。

清单的衰变有固定方向——它只增不减。条目在上线时被加进去，几乎从不被删掉，于是两年之内，登记册描述的机队会明显大于真正在跑的那支，而它的可信度也就一并没了。

• 每周自动对账，并上报差额。凭据身份减登记条目、登记条目减观测到的流量、支出减已归属的智能体。三个数字，看趋势。第一个数字上升是影子部署；第二个上升是死条目还握着活凭据。
• 下线是所有人都会跳过的那一步。退役一个智能体，意味着吊销它的凭据、关掉它的出站放行、按保留与法律保全处理它轨迹上的保留义务，并给条目标注关闭日期。一个靠"把界面入口撤了"来关停、却仍持有有效令牌的智能体，不叫已下线。
• 对授权扩张告警，而不是对新增登记告警。新智能体自然会得到关注。危险的事件是一个既有的、早已获批的智能体拿到了新工具或更宽的数据范围——风险分级正是在那一刻悄悄变错的；而一旦元组成为记录单元，这条告警很便宜。
• 演练一次查询。每季度挑一个智能体加一个日期，计时看要多久才能拿出它在那天的确切配置、它的责任人以及它的运行记录。这项练习与事故或监管会强加给你的完全是同一件事，而第一次尝试总是比谁预想的都慢。
• 把数字公布出去。一个管理层每月都会看到的数字——生产中的智能体，按风险等级、带责任人——对准确性的作用胜过任何政策，因为它让登记册变成一件人们会被问到的事，而不是一件人们要去填的表。

相关：智能体身份——本页赖以立足的主键；审计轨迹与来源——登记 ID 关联到的东西；面向智能体的欧盟 AI 法案与 面向智能体的 NIST AI RMF——本页供养的那些义务；以及策略执行——如何把登记条目变成运行时控制。