退役一个智能体

这种不对称是结构性的，而它预言了你会发现什么。

CSA 那份《Autonomous but Not Controlled》调查（2026 年 4 月 21 日发布，418 位 IT 与安全从业者，自填）值得为一道缺口读一遍：52% 的人说自己有明确的创建或上线流程，68% 会做周期性权限复核，而有任何正式退役流程的只有 21%。报告把这个结果称为退役债（retirement debt）——智能体活过了它本该被用到的期限，还握着没人重新授权过的权限。

请把这个 21% 当成一个结构性预言，而不是一句训话。上线会发生，因为有人想要某样东西，并且会一路追着它。退役没有申请人：当初想要这个智能体的人已经走了，而会因它消失而受益的人并不知道它存在。这和压垮智能体凭据的权限复核的是同一个「缺少终止事件」的问题——但这里的后果不同，而且更糟。一份残留的凭据是一项风险。一批残留的产出则是一个无法回答的问题：半年后，当这个智能体的某个决定被质疑时，没人说得出哪些产出是它的、依据的是哪版政策、在哪个时间窗里。

拆除的顺序很要紧，而那个显而易见的顺序是错的。

本能是先吊销凭据，因为那是吓人的那部分。在一个正在运行的智能体上这么干，你会把一次干净的停止变成一起事故：每一个在途任务都开始认证失败、harness 重试、重试在四个层级上叠加，于是你收到一次传呼，外加每一个跑在半路上的任务都留下一个写了一半的副作用。这是重试放大，在一个你自己选的日子里到来。

# Decommission order. Each step is reversible until the last two.

1  close the ingress     schedules, cron, webhooks, queue
                         subscriptions, event subscriptions,
                         inbound surfaces (channel, inbox, API)

2  drain                 let in-flight tasks finish or abort
                         them deliberately; record which

3  cut the egress        tool catalog entries, outbound allow-list,
                         write scopes → read-only, then none

4  revoke                credentials, OAuth grants, service
                         accounts, signing keys, session tokens

5  mark the artifacts    provenance boundary + dates (STEP 4)

6  retire the record     registry entry → decommissioned, with
                         the evidence, not deleted

第 1 步是最常被漏掉的那一步，也是制造僵尸的那一步。一个没有凭据但排程还活着的智能体，照样会醒来、照样会失败、照样会传呼某个人，而且半年后在你的清册里照样显得还活着。把入口彻底列全——排程是显眼的，一个由已离职工程师当年注册过一次的 webhook 不是，而一个会自我续期的事件订阅会悄无声息地活得比你关掉的其他一切都久。按排程与按触发运行的智能体就是那份「该去哪些地方找」的清单。

注意第 6 步不是删除。抹掉清册条目，等于销毁了从智能体名字通向它的凭据、工具与产出的唯一索引——而那正是某个产出被质疑时你会需要的东西。

排空是一个关于副作用的决定，不是一次等待。

「让它跑完」对一个请求形态的服务没问题，对智能体则毫无意义——因为工作单位是一个多步任务，而它已经发生了一半。一个已经建好采购单、却还没发出确认的任务，正处在一个你的关停流程理解不了的状态里。

所以请按任务类别、在开始之前就定下来，并写下来：

• 跑完。用于「剩余步骤有界、且部分状态比完成状态更糟」的任务。这要求凭据在整个排空期间保持有效——这正是吊销排在第 4 步而不是第 1 步的原因。
• 中止并补偿。用于你能把已发生之事逆转回去的任务——修复智能体的副作用里那套补偿动作的机械装置。把补偿记下来，因为一次没记日志的逆转，和第二次出错是分不出来的。
• 中止并上交。用于你既逆转不了、也完成不了的任务。它们会变成某个人队列里的待办，附上链路。这类任务会比你预想的多，而它的数量正是「你的智能体到底有多可逆」的真实度量。

如果这个循环是事件溯源的，日志会准确告诉你每个任务停在哪里、已经做过什么——这是持久状态与可恢复性里描述的那份回报，也是为什么一次退役是个很好的「逼你搞清自己到底有没有它」的契机。如果不是，那你的排空就是在猜，而你该给那堆上交的任务留出预算。

没有开关的那一半：四类产出残留，以及你欠它们的那条边界。

上面的一切都是可枚举的。这一部分不是，而真正的责任就压在这里。一个跑了一年的智能体留下了四类在它停下之后仍在起作用的残留：

• 记录系统里的记录。被关掉的工单、被批准的发票、被设置的 CRM 字段、被写入的行。除非有什么东西给它们做了标记，它们如今与人工生成的记录是分不出来的——这正是披露与内容溯源的全部论证。如果它们在写入时没被标记，你没法事后补标——但你可以把时间窗和范围记下来。
• 别的智能体在读的记忆与上下文。它写进共享存储的那些事实，不会因为作者没了就不再被检索到。更糟的是，它们现在是无从归属的断言，没有作者可供质询——看子智能体继承了什么了解它们能传多远，看针对智能体记忆的删除了解移除实际要付多少代价。
• 派生数据。它填充过的索引、它生成过的向量、成为后续摘要来源的那些摘要。删掉这个智能体并不会让索引失效，而重建索引是一个项目——重建索引与向量迁移。
• 人们如今在依赖的文档。它起草的那份 runbook、某份演示里的那段分析、某人粘进 wiki 的那段政策摘要。这些已经完全离开了你的系统，而唯一可用的管控就是告诉人们。

这些你关不掉，所以交付物是一条溯源边界：一份带日期的说明，写清这个智能体产出了什么、在哪里、依据哪个模型与政策版本、从何时到何时。三个字段加一个范围。在退役那天写它很便宜，一年后重建它则不可能，而正是它把「我们觉得那是老那个智能体干的」变成一个答案——这是审计链里的证据标准，也是对一个已不存在之物所作决定履行可申诉性与申诉的前提条件。

在消费方找上你之前，先把它们找出来。

你干净地退役一个智能体所造成的那次故障，恰恰是没人建过模型的那一次——因为那条依赖从来没有被声明过。一个智能体的消费方是非正式地攒起来的：另一个读它输出的智能体、一块数字来自它写入的看板、一个每周期待一份文件的作业、一个每天早上从它的摘要开始的人。

用你推导清册的同一个办法推导这份名单——从智能体实际碰过什么出发，而不是从谁声明过什么出发。三条查询能覆盖大部分：过去 90 天里谁读过它写入的那些表；哪些智能体从它写入的记忆命名空间检索过；以及哪些工具调用链路把它列为上游。然后公布一个日期，而不是一个意向，并且在通知期内让这个智能体保持只读、而不是直接拉黑——一个能从既有状态作答的只读智能体，是比一个 404 温和得多的弃用，而这也正是你在模型弃用与迁移下会给出的同一份体面。

用一份记录和一次「复活测试」来收尾。

一次退役算做完了，是当有人能证明它发生过、并且没人能悄悄把它撤销。这是两条不同的性质，而多数团队两条都没拿到。

• 记录就是交付物。清册条目标记为已退役并带日期、第 4 步那条溯源边界、带吊销时间戳的已吊销授权清单、第 3 步那堆上交的任务，以及签字确认的那位具名负责人。当对象已经不存在、无从质询时，这就是问责与角色所指的东西。
• 测一测复活路径。试着把它开回来。如果翻一个功能开关就能让它带着活凭据回来，那你暂停了一个智能体，却告诉审计师你退役了一个。一次真正的退役要求重新签发某样东西——一份凭据、一项授权、一个清册条目——好让这次回归成为一个由某人授权的事件。
• 把它从工具目录里双向移除。它自己的工具要走，它在「别的智能体可能发现并调用它」的任何地方的条目也要走。一个过期的目录条目，正是一个已退役的智能体被某个从不知道它已经没了的东西重新调起来的方式——工具目录的生命周期。
• 留下留存义务要求的，刻意删掉其余的。链路与决策记录通常带着比智能体本身多活好几年的留存义务；工作状态通常不带。请在退役那天按留存与法律封存把哪是哪定下来，而不是让默认变成「永远全留在一个没人拥有的桶里」。