真正重要的数字不是活跃占比
关于 agent 集群的报告往往以活跃度统计的形式出现：标题会说，大多数 agent 处于休眠状态，但它们仍保留着凭据和打开的连接。活跃度数字是这句话里最不重要的部分。真正起作用的事实是权限的持续存在——凭据在任务结束后依然存活。
这一框架背后的报道值得直接阅读（一篇报道，以及另一篇）。两者都没有改变底层机制：一个数月未调用过工具的 agent，仍会向它曾被授予权限的每一个下游服务出示有效 token。
休眠是部署过程的产物，而非设计决策。从未被提升的原型。季节已过的季节性任务。供应商变更后被弃用的集成。因为控制台让重新部署比迁移更省事，于是以新名称重新部署、旧版本被取代的 agent。这些都不该持续存在。它们之所以持续存在，是因为流水线中没有任何环节强制进入终态。创建只是一个按钮；下线却是一个项目。
在资源边界——API 网关、数据库角色、SaaS 租户——一个持有有效 token 的空闲主体与活跃主体无法区分。token 有效，scope 存在，调用成功。只有生命周期记录才能区分二者，而在大多数集群中，这样的记录并不以任何机器可查询的形式存在。
为什么 agent 的腐化方式不同于服务账号
服务账号通常是一个凭据、一个 scope，由平台团队签发，按计划轮换。而 agent 的权限是复合体，每个元素都按各自的时钟运行：
- 模型提供商密钥，往往在多个 agent 之间共享，因此从不为任何单个 agent 轮换；
- 工具凭据——数据库密码、内部 API 密钥——在构建时配置，在部署时被遗忘；
- 下游 OAuth 授权，带有自己的过期和刷新行为，且常常存放在无人盘点的 token 存储中；
- 委托者的 scope，即 agent 代表人类行事，并继承该人类在授权时刻所能触及的一切。
由于这些凭据各自独立过期，复合体几乎从不作为一个整体失效。模型密钥轮换了，OAuth 授权静默刷新了，数据库密码却原封不动。agent 看起来维护良好。事实并非如此：它是一组处于不同腐化状态的凭据，没有任何单一视图能展示其并集。
第二个区别在于来源。agent 通常由平台职能之外的团队通过以低摩擦为设计目标的控制台创建。这对推广采用是正确的设计，对盘点却是错误的设计。主体数量的增长速度超过所有者数量，而这两条曲线之间的差距就是暴露面。
将回收作为计划性控制
把回收当作清理项目，注定它会反复出现。清理是有始有终的事件；它结束后的下一周，积压就会重新填满。控制必须是一个带有默认结果的计划性流程。
过期是默认结果。 按 agent 类别——交互式助手、计划任务、事件驱动响应器——定义不活跃阈值，并让该阈值成为自动暂停凭据的触发器，而不是让人去审查的工单。重新授权是显式行为；持续拥有权限才是需要理由的。阈值取值是各组织的策略决策；机制才是关键。
所有权和用途是前提条件。 没有具名所有者和明确用途，agent 不能被创建；两者不再成立时，也不能被重新授权。这是一个小规模 schema 变更，效果却很大：盘点变得自描述，孤立主体在构造上就会失败，而不是靠审计才发现。
凭据生命周期与进程生命周期解耦。 凭据应按自己的计划过期，无论 agent 是否在运行。把过期绑定到容器生命周期，意味着已停止的进程会无限期保留有效密钥——这正是休眠失效。每次调用签发短期 token，长期密钥保存在 agent 永远看不到的 broker 中，就能彻底消除持久化。
回收事件与 agent 操作进入同一条审计轨迹。 大多数审计日志记录主体做了什么。很少有日志记录权限何时被撤销、由哪个流程撤销、依据哪个策略版本。如果轨迹只显示使用情况，调查者就无法区分一个安静的 agent 和一个已被撤销的 agent——也无法证明撤销确实发生过。
一条最小的回收记录如下所示：
{
"principal_id": "agent:invoice-recon-v3",
"event": "credentials_revoked",
"reason": "inactivity_threshold_exceeded",
"last_successful_tool_call": "2025-01-14T09:22:07Z",
"grants_revoked": ["oauth:ledger.read", "db:recon_rw"],
"owner": "finance-ops",
"policy_version": "reclamation-v4",
"reauthorisation_path": "ticket:OPS-2214"
}
权衡是真实存在的，应当直说。激进的回收会破坏东西。季节性任务若无人重新授权，就会在当季失败；交给合作伙伴的原型会在演示中途停止；值班工程师会花一晚上重新签发授权。成本由人立即承担，收益则是一次不会发生的泄露，且不可见。正是这种不对称，使得回收若不自动化、不把失败做得响亮且修复成本低廉，就会逐渐衰减——一条几分钟就能完成的自助重新授权路径，而不是变更咨询委员会。
应当监测什么
真正重要的度量不是容器健康。
每个凭据的最后一次成功工具调用，而不是每个进程的最后心跳。运行中的容器可能什么都没做，却持有有效授权；已停止的容器可能持有同样的授权，却根本没有进程可供观察。凭据是风险单元，因此凭据也是度量单元。
将下游授权作为一等盘点项，每项都有自己的所有者和过期时间，并与持有它的 agent 关联。这是在不阅读四个系统并靠猜测的情况下，回答 agent 能触及什么的唯一方法。
对授权集合的漂移告警。 一个主体的权限发生了变化，却没有相应的变更记录，这要么是配置错误，要么是入侵，而没有记录就无法区分二者。对增量告警，而不是对绝对 scope 告警。
设计规则
每个 agent 主体都应能按需回答三个问题：谁拥有它，它能触及什么，它的权限何时失效。不是在 wiki 里，不是在由构建者维护的电子表格里——而是在签发凭据的系统中，能被审计其操作的同一套工具查询。
如果其中任何一个答案需要人从记忆、聊天记录或仓库搜索中重建，这个集群就承载着未声明的风险。休眠的 agent 不是这条规则的例外。它们正是这条规则存在的原因：一个停止行动的 agent 仍是主体，而没有生命周期的主体就是没有所有者的凭据。