凭证残留：你已停用的智能体仍处于生产环境登录状态

在你关停（sunset）一个智能体（agent）六个月后，一名安全审计员在团队的 Slack 上发消息问：“为什么这个 OAuth 应用仍然拥有公司 Google Workspace 的读取权限？”没人认得这个应用名称。有人 grep 了代码库——没有匹配项。有人检查了部署清单——也没有匹配项。最终，一位前任产品经理（PM）想了起来：那是会议摘要原型，一个在第三季度被砍掉的产品。面向用户的界面早已被删除。但 OAuth 授权、BigQuery 中的服务账号、Pinecone 索引、Slack 告警路由、Datadog 仪表盘、Splunk 保存的搜索、充满客户转录文本的评估数据集——所有这一切依然存在，依然已授权，也依然在计费。

这就是凭证残留问题，它是智能体时代最主要的运营失效。你发布的每一个智能体都会在各供应商、内部服务和数据系统中创建出一圈资源。当你通过删除代码来退役一个智能体时，你移除的可能仅占其创建内容的五分之一。剩下的部分作为“幽灵基础设施”留在生产环境中，无人认领、无人负责，而且最危险的是，它们依然持有凭证。

规模问题让情况变得比听起来更糟。目前的行业遥测数据显示，在普通企业中，非人类身份与人类身份的比例大约为 50:1，而在顶尖企业中则超过 140:1。每一个退役的智能体留下的不仅仅是一个凭证，而是一个委托链——OAuth 应用与服务账号通信，服务账号持有向量数据库的密钥，而该数据库被推理代理读取，后者又写入日志流水线。仅仅牵动其中一根线并不能让其他线索消失。每一处都是一笔隐形的负债。

代码移除并不等同于退役

退役某个功能的默认心理模型是 git revert。这种模型在结构上与智能体是不兼容的。

通过回滚 PR 来退役的 Web 功能会移除路由、处理器、迁移脚本和测试。该功能的足迹完全在仓库内部。而以同样方式退役的智能体则会移除提示词、工具定义、编排循环和 API 客户端。但该功能的足迹大部分都在仓库 之外：在供应商控制台、IAM 策略、云资源目录以及开发者从未打开过的可观测性工具中。

由于智能体具有“创造性”，这种不对称性会不断叠加。Web 功能在部署时通过声明式的基础设施即代码（IaC）配置资源。而智能体则在运行时配置资源——当它第一次需要向量索引时，当开发者第一次接入一个新的 MCP 服务器时，或者当有人为了“调试这个回归问题”而将生产环境的转录文本快照存入评估集时。这些都不在 Terraform 中。它们都不会被 Terraform apply 拆除。

结果就是，通过代码回滚完成的智能体退役，只移除了智能体资源的调用端，而没有触及资源本身。撤销（Revocation）只是终止一个活跃的令牌；而退役（Deprovisioning）则会移除底层的身份、凭证以及它所持有的任何委托范围链。大多数“智能体退役”冲刺只做了第一步，却跳过了第二步。

你梦寐以求的清单

团队跳过第二步的原因并不是因为懒惰，而是因为他们无法枚举出需要撤销的内容。当一个智能体发布到第三个版本时，它涉及的资源通常如下：

• OAuth 和 SSO：在供应商（Google、Slack、Notion、Salesforce）处注册的应用，其一个或多个刷新令牌存储在你的机密管理器（secret manager）中，授予了原始原型所需但从未收紧的权限范围。
• 云身份：一个或多个服务账号或 IAM 角色，附带已关联的策略、已签发的密钥以及工作负载身份联邦（workload identity federation）绑定。
• 数据系统：仓库角色、向量索引凭证、队列订阅、带有命名智能体角色的存储桶策略的 S3 前缀。
• 供应商账号：具有预算、API 密钥、启用了日志记录并注册了自定义评估的 Anthropic 或 OpenAI 工作区项目。
• MCP 与工具注册表：内部 MCP 网关中的服务器条目、智能体注册表中的工具注册，以及智能体调用的每个工具的范围令牌。
• 评估与遥测：快照到评估存储桶中的生产环境转录文本、评估运行历史、固定到特定追踪查询的仪表盘、路由到频道的告警。
• 功能开关（Feature gating）：实验平台中一个没人记得其状态的标志位，有时这甚至是保护用户免受半删除代码路径影响的唯一屏障。

如果退役手册将“删除代码”列为第一步，那么它永远无法触及上述内容的一半。而一份以“生成清单”为起始的手册则会揭示出一项不可能完成的任务——这项任务团队已经悄悄逃避了两个季度。

纪律始于上线，而非退役

唯一可持续的解决方案是：在资源创建的那一刻，为智能体配置的每个资源都打上一个稳定的智能体 ID 标签，从而使清单的生成变得廉价。这是将停用工作从“考古工程”转变为“标签查询”的架构前提。

具体来说：每个云资源都有 agent-id=<id>，每个 OAuth 应用在客户端名称或元数据中包含智能体 ID，每个向量索引在其命名空间中使用智能体 ID，每个 API 密钥都在以智能体命名的项目中创建，每个仪表盘和告警在其标签或保存的搜索名称中包含智能体 ID，每个评估数据集在其清单中包含智能体 ID。这种约定必须在资源 创建 的地方强制执行——在 IaC 模块中、在配置脚本中、在注册助手程序中——而不是作为事后的审计。

基于标签的生命周期管理是云成本管理的标准规范；同样的原始手段也能解决智能体残留问题。在退役期间，没有标签的资源被视为不存在，这意味着没有标签的资源也是一种违规行为，应该在配置阶段的评审中就被拦截。

那种注定失败的做法是：“我们将从现在开始为新标签添加智能体 ID。”团队添加了标签，发布了三个使用该标签的新智能体，一年后当其中一个智能体退役时，手册对该智能体有效，但对那打从未打过标签的老旧智能体却毫无办法。退役是你上线时建立的纪律的最后防线。如果你没有建立这种纪律，那么防线就只能是周末在各个供应商控制台中进行的一场 grep 苦战。

评估数据集是受监管的数据

由生产环境对话记录构建的评估数据集值得特别关注，因为它是最容易演变成合规事件而非安全事件的留存类别。

当时的操作流程看起来并无大碍：一个回归缺陷混入了生产环境；工程师想要重现它；于是他们将几百条真实的生产对话快照保存到 JSONL 文件中，并将其存入 evals 文件夹。六个月后，该 JSONL 文件中包含了用户的个人身份信息（PII），而这些用户在此期间已经根据 GDPR 或类似法律行使了删除权。删除请求在生产数据库中得到了执行，但评估快照并不在删除流程中，因为没人告诉隐私团队它的存在。

“删除权”义务要求从生产数据库、备份、分析流水线，以及训练和评估数据集中移除用户数据。源自生产对话记录的评估快照是一种受监管的数据资产，工程师团队在创建快照时并未意识到他们承担了相应的保留义务。

因此，评估数据集的停用指南不能简单地设为“删除数据集”。它必须遵循以下两条路径之一：删除并保留删除内容和时间的记录；或者将其移动到长期保留层，并由明确的负责人负责对接删除请求工作流。默认的“因为存储便宜就把它留在 bucket 里”的做法，正是导致审计异常的根源。

停用检查清单

上述所有内容最终落实为一个明确、可执行的清单，并与 Agent 的清单（manifest）关联。在实践中行之有效的形式如下：

• 身份：撤销 OAuth 刷新令牌；删除在供应商处注册的 OAuth 应用；删除服务账号和 IAM 角色；移除工作负载身份绑定；将 Agent 用户从任何内部 IAM 组中移除。
• 提供商：撤销 API 密钥；关闭提供商的工作区项目（或将其预算归零并重命名为 RETIRED-<id>）；禁用日志导出。
• 数据：删除向量索引；撤销数据仓库角色权限；移除队列订阅；删除或归档具有明确保留期限的 S3 前缀；移除引用 Agent 角色的 bucket 策略。
• 工具与 MCP：从 MCP 注册表中移除服务器条目；撤销针对单个工具的令牌；从 Agent 注册表中移除工具注册。
• 评估与遥测：审查评估数据集的 PII 保留义务，并删除或转移所有权；归档或删除仪表盘和保存的搜索；删除告警或转移路由；如果保留政策有要求，则导出追踪（trace）数据。
• 功能开关：在确认代码中不再有引用后，从实验平台移除该标志（flag）；从配置中移除该标志。
• 记录：在审计日志中写入停用记录，注明 Agent ID、移除的资源、保留的资源及原因，以及签字批准的人员。

清单是枯燥的，但这正是重点。有趣的工作在于架构决策：在创建资源时就标记 Agent ID，这能将上述清单从一项调查任务转变为一个遍历标签查询的脚本。

组织必须意识到的问题

最深层的理解是组织层面的觉醒：Agent 不是一个功能（feature），而是一个分布在供应商、内部服务和数据系统中的已配置资源网络。如果一个团队的停用指南仅仅是“git revert 该功能”，那么他们并没有真正停用 Agent。他们只是去掉了面向用户的界面，却把后端身份、数据和遥测的残余留给了别人去处理。

严肃对待这一问题会衍生出两个角色。第一个是每个 Agent 的登记负责人——一个具体的个人，而非一个团队，负责从配置到停用的全生命周期。如果没有这个角色，Agent 的资源将比任何组织架构调整活得都久，并成为真正的“孤儿”资源。第二个是安全或平台部门内部的非人类身份所有者，他们可以审计所有 Agent 的清单，在配置阶段强制执行标签规范，并运行定期的发现扫描，以捕获那些漏掉的资源。

这两个角色都不显赫，但都是核心支撑。负责这些岗位的团队在第一年往往会忙于清理那些在规范建立之前停用的 Agent 所留下的痕迹，最终他们会获得一份值得信赖的清单和一个能在几分钟内运行完毕的停用脚本。而不设立这些岗位的团队，则会花同样长的时间向审计员解释，为什么他们的 Google Workspace 租户中会有一个名为 meeting-summarizer-v2-prod 的 OAuth 应用，以及是哪位早已离职的工程师注册了它。

展望未来，这件事很简单：假设你今天交付的每一个 Agent 都会在两年内停用。停用往往发生在一个每个人都忙于下一个项目的冲刺阶段。在这种干扰下，唯一能奏效的机制是：Agent 的资源可以通过标签查询进行枚举，并通过脚本移除。在你交付第二个 Agent 之前就建立这套机制。当你交付五个 Agent 之后，补课的成本将远远超过从一开始就做对的成本。