代理退役：AI 代理生命周期中缺失的另一半

关键要点

• Gartner 预测到 2027 年，40% 的企业将因仅在部署后才发现的治理缺口而降级或退役自主 AI 代理 — 即使到达生产的代理也面临一年内 40% 的退役率，而大多数企业缺乏安全执行退役的生命周期基础设施（Gartner）。
• Gravitee 的 2026 年调查发现，企业代理队伍大约每季度翻一番，而仅约 20% 的团队单独标识代理身份 — 未退役的代理成为"暗物质"：无人能归属的凭证和行动者，包括服务账户已超出其用途的代理（Gravitee State of AI Agent Security 2026）。
• TrueFoundry 于 2026 年 8 月 8 日发布了首个全面的代理退役手册 — 六个步骤（清点、重定向、撤销、保留、墓碑、验证），每个步骤在跳过时都有对应的失败模式。关键洞察：退役的廉价性和可靠性与代理存活期间的治理程度成正比（TrueFoundry）。
• 88% 的 AI 代理项目从未到达生产，平均每次失败成本为 340,000 美元 — 在上线的 12% 中，Gartner 的 40% 退役率意味着生命周期挑战不仅是部署，还包括对到达生产后失败的代理进行受治理的退役（digitalapplied.com）。
• 设计教训反向延伸到配置阶段：每个代理在创建时都应考虑到退役 — 单独标识的身份、任务派生的权限范围、强制执行的预算、别名的依赖方、集中化的追踪记录。一个在创建时无法回答"我们如何关闭它？"的代理，已经让组织预先承诺要么进行考古式挖掘项目，要么永远不退役它。

Gartner 预测到 2027 年，40% 的企业将因仅在生产事故后才发现的治理缺口而降级或退役自主 AI 代理。这一预测发布在 2026 年 5 月 26 日的新闻稿中，指出了企业 AI 文献几乎未曾涉及的 lifecycle 问题：部署指南随处可见，退役指南极为罕见。结果就是 Gravitee 的 2026 年调查所称的"暗物质"——企业代理队伍大约每季度翻一番，而仅约五分之一的团队对代理身份进行单独标识。试点结束了但服务账户没有。工作流被更好的替代方案取代，而旧代理的密钥仍在运行。离职工程师的实验仍持有一个令牌。这些都是未退役的代理：不是惰性的攻击面，而是在无人再持有的目的下运行的自主权。

本文梳理了 TrueFoundry 于 2026 年 8 月 8 日发布的六步退役手册——清点、重定向、撤销、保留、墓碑、验证——并将其与 IdeaBosque 现有文章所涵盖的治理架构和部署生命周期联系起来。本文建立在设计中的 kill switch：代理治理架构的基础上，后者涵盖运行时强制执行；以及从试点到生产：五阶段代理部署手册的基础上，后者涵盖部署流程。这里我们聚焦于两篇文章都省略的阶段：当代理到达其有用生命的终点时会发生什么，以及为什么这个答案决定了代理从一开始是否曾经是可治理的。

为什么退役是生命周期的困难半程

配置阶段容易做好，因为其中一切都是现在时态且有动力的：团队需要代理，预算存在，检查清单会被遵循因为上线依赖于它们。退役则反转了所有这些条件，这就是它默默失败且经常失败的原因。动力消失了——团队已转向替代方案，试点的发起人已转到其他团队，没有人的 OKR 写着"关闭东西"。知识消失了——知道代理密钥在哪里的工程师已经离职，而代理本身不出现在任何清单中，因为它从未被单独标识。激励也被反转了——关闭某个东西有破坏某个人忘记的依赖关系的风险，而让它继续运行在今天看不到任何风险；因此，从局部来看，理性的做法总是让它继续运行。

结果是这个机制在无对抗中运行。当配置速度超过清单和退役速度时，身份和凭证即使在原始工作负载消失后仍然积累。代理特有的升级是：遗留物不是惰性的密钥而是运行中的自主权——一个未退役的代理在无人再持有的目的下继续行动、消费和触碰数据。Gravitee 的调查对 900 多名高管和技术从业者发现，85% 的组织没有 AI 代理行为的正式问责结构，仅 7.2% 能指出一个在代理行动时负责的具名个人。当一个无人记得持有任何东西的代理行为不端时，它无法被遏制，因为它无法被找到。

Gartner 的四级自主分类法在政策层面构建了这个问题：Level 4 代理"在定义的护栏内独立执行行动，人类审查异常、审计日志和聚合结果，而非单个决策。"当 Level 4 代理被退役时，护栏、审计日志和聚合结果都需要被处理——不仅仅是流程。Level 1 或 Level 2 代理（只读、人工执行）可以通过停止流程来退役。Level 4 代理不行。退役流程必须匹配自主级别，而大多数企业将 Level 1 的退役流程（停止流程）应用于 Level 4 代理（这些代理已经自主行动、写入数据并积累了数月的审计追踪）。这种不匹配是 Gartner 指出的根本原因："企业将 AI 代理治理视为二元的——要么完全锁定要么完全信任——而这正是失败的根本原因。"

六步退役手册，及其完成的生命周期的可视化：

六步手册

TrueFoundry 的手册将退役组织为六个步骤，每个步骤在跳过时都有对应的失败模式。步骤的顺序设计旨在防止典型的退役错误——在重定向之前撤销凭证而破坏生产，或删除带有审计义务的记录。

1. 清点

枚举代理持有和触及的一切：凭证（正式的和副本）、工具权限范围、预算项、计划触发器、它消费的队列、调用它的系统、引用它的仪表板。如果代理在受治理的平面上被单独标识，清点轻而易举；否则如同考古。跳过它是第 3 步破坏生产的方式——你撤销了一个凭证，结果发现它与另外三个工作流共享，而这些工作流以无人预料的方式失败了。

2. 重定向与排空

在撤销任何东西之前，冻结入口并转移依赖方。计划触发器被禁用以防止新工作开始。队列被排空或转移。活跃运行被检查点或允许完成。子代理被停止。调用方通过代理级别的服务别名、工作流注册表、网关路由或应用平台维护的任何间接层指向继任者。通过间接层调用的依赖方通过修改一个条目即可迁移；硬编码端点的依赖方则需要协调迁移。

一个注意事项由退役模式决定：重定向适用于计划内的替换，而被入侵或不安全的代理通常应失败即关闭——调用方收到错误，而非静默地继承错误假设的继任者。父文章中的 kill-switch 架构涵盖了使失败即关闭可靠的运行时强制执行；退役是同一遏制原则的永久版本。

3. 撤销

每个凭证被失效（撤销凭证即撤销其副本——它们是同一个凭证），权限范围被移除，身份被禁用，并且在代理拥有专用虚拟账户或可靠传播的标识符的情况下，其支出规则被强制归零，使进一步的模型调用无法通过网关。这些是事故手册中的遏制杠杆，被永久拉下。长时间运行代理模式文章描述了运行时熔断器如何在数秒内停止行为不端的代理；撤销是将同一原则应用于代理的整个身份，而不仅仅是单个工具调用。

失败模式：没人敢撤销其他十一个东西使用的密钥。共享凭证会无限期推迟退役——这就是为什么配置时的单独标识身份不是安全奢侈品而是退役前提条件。

4. 保留

删除本能会搞错的步骤。已退役代理的追踪记录、决策、护栏结果和评估历史通常带有比代理存活更久的审计和法律保留义务。退役意味着行动者不再行动，而不是它行动过的证据自动消失。保留什么以及保留多久，应遵循保留、隐私和删除策略，而非直觉。在受监管行业——EU AI Act 的第 50 条透明度义务自 2026 年 8 月 2 日起可执行——代理的决策记录可能需要在代理本身退役后保存数年。

5. 墓碑

在治理记录中将代理身份标记为已退役。在当今大多数系统中，这不是一个平台生命周期状态——它是组织治理系统维护的记录。墓碑条目应记录：代理何时退役、谁授权退役、什么继任者（如果有）替代了它，以及保留的记录存放在哪里。

知识转移是人人遗忘的步骤。已退役代理积累的配置——其提示词、权限范围、评估用例和从事件中衍生的护栏——是组织学习，应迁移到继任者，而非随部署消失。一个花了六个月学习哪些供应商目录字段不可靠的代理，应该将这些知识向前传递，否则继任者会重复同样的错误。

6. 验证

撤销之后，归因应显示已退役代理的成功流量为零。已撤销凭证的尝试应仅以认证失败的形式出现。不应有来自未记录的替代身份或绕过受治理路由的路径的调用。残留成功流量意味着撤销不完整或存在另一个凭证——而这一发现是手册最有价值的产出。

验证步骤是将"已退役"与"可能已退役"区分开来的关键。没有它，组织已经停止了代理但无法确认它保持停止状态。Gravitee 调查发现仅 7.2% 的组织能指定一名对代理行为负责的人，这意味着在大多数企业中，也没有人负责验证退役。

退役作为配置测试

手册中的每一步在代理的运营生命通过受治理层运行时都很廉价，而在它绕过治理层的比例上则很昂贵。当代理是注册主体且其权限范围、预算和流量都是平面记录时，清点是一次查询；而当其访问是粘贴在环境变量中的共享密钥时，它是一个取证项目。当依赖方通过间接层调用时，重定向是一个注册表条目；而当它们硬编码端点时，它是协调的多团队迁移。当身份被单独标识时，撤销是外科手术式的；而当凭证被共享时，它是附带损害。当追踪记录被集中记录时，保留更简单；而当证据分散在临时性的部署本地存储中时，它是脆弱的。

这产生了手册的反向结论：退役是对配置的测试。"我们如何关闭它？"这个问题——在上线日、第一个请求之前提出——用一句话审计了代理是否在受治理状态下诞生。单独标识的身份。任务派生的权限范围。强制执行的预算。别名的依赖方。集中化的追踪记录。一个在创建时能回答它的代理，在一个下午就能退役。一个在创建时不能回答它的代理，已经让组织预先承诺要么进行考古式挖掘项目，要么更可能永远不退役它——这意味着代理加入了暗物质行列，一个无人能归属的凭证和行动者，做着无人记得授权的工作。

五阶段部署手册涵盖了第一到第五阶段：流程考古、工具权限范围界定、可观测性基础设施、金丝雀影子模式和人工交接协议。退役是第六阶段——闭合生命周期的那个阶段。治理检查清单涵盖了部署前审查；退役审计（如下）是部署后的对应部分。

退役审计

两个问题，一个资产盘。

**回溯：**列出过去一年退役的代理。对于每个代理，你能出示已撤销的凭证、强制归零的预算规则、保留的追踪记录和墓碑记录吗？根本没有列表本身就是发现——这意味着组织一直在退役代理而没有记录自己这样做了，这与没有退役它们无法区分。

**前瞻：**对于你下一个上线的代理，在第一个请求之前以书面形式回答"我们如何关闭它？"。如果答案超过一段话，这个代理天生就无法退役。AI 代理治理检查清单是这个问题的部署前版本。退役审计是部署后版本——同一原则，生命周期的另一端。

对于一家通过 RFQ 代理运行 NetSuite、BigCommerce 和三个供应商目录的中端市场 B2B 公司，退役审计有具体的边界。代理拥有到 NetSuite 的 OAuth 令牌（权限范围限定为 SuiteQL 读取）、到 BigCommerce 的 API 密钥（权限范围限定为目录读取）和到三个供应商门户的凭证（不同的权限范围、不同的认证方式）。它有一个每四小时运行一次的计划触发器。它将报价写入销售团队监控的报价队列。它从两个其他工作流也读取的供应商目录缓存中读取。退役这个代理意味着：清点所有六组凭证、禁用计划触发器、排空报价队列、将两个下游目录缓存读取方重定向到继任者或人工回退、撤销所有六组凭证、根据公司七年审计策略保留报价决策日志、在治理记录中记录带有继任者归属的代理墓碑，并验证在接下来的 24 小时内没有以已退役代理身份出现的 NetSuite 或 BigCommerce API 调用。如果代理被单独标识，这是一个下午的操作。如果不是，它是一个数周的考古项目。

相关阅读

• 设计中的 kill switch：代理治理架构 — 涵盖运行时强制执行的父文章：身份门控访问、每工具熔断器、租户隔离、快速回滚，以及门控访问作为第四层强制执行。退役是同一遏制原则的永久版本。
• 从试点到生产：五阶段代理部署手册 — 本文以其第六阶段扩展的部署流程。88% 的生产失败框架和 340K 美元的平均失败成本是在部署前构建治理——包括退役准备——的 ROI 论据。
• AI 代理治理检查清单：生产代理的部署前审查 — 部署前审查。本文中的退役审计是部署后的对应部分：同一治理原则，生命周期的另一端。

代表性构建场景

一家通过 RFQ 报价代理运行 NetSuite、BigCommerce 和三个供应商目录的中端市场工业分销商，需要在用一个处理多币种定价的继任者替换后退役该代理。该代理已在生产中运行 14 个月。它持有到 NetSuite 的 OAuth 令牌、到 BigCommerce 的 API 密钥和到三个供应商门户的凭证。它在四小时触发器上运行并写入报价队列。退役只需一个下午，因为代理在配置时被单独标识：其身份、权限范围、预算和流量都位于一个治理平面上。六个步骤作为事务执行——一个主体被撤销、一个预算规则归零、一个注册表条目重定向、一个墓碑记录归档——而非在系统中搜寻每个粘贴密钥的位置。继任者继承了已退役代理的供应商可靠性护栏，因此它不会重复六个月的学习哪些目录字段不可靠。验证步骤确认在 24 小时内零残留流量。

请求一个范围限定的构建。

一周发现。你将获得系统清单、工作流地图和固定范围——无论你是否与我们合作构建。