智能体安排的无人继承的周期性任务

用户输入：“每周二提醒我检查那个集成。”Agent 创建了一个 cron 条目，返回礼貌的确认，随后会话关闭。六个月后，用户调换了团队。该集成在上个季度已被弃用。Cron 仍在运行，调用着在 4 月份轮换过的 API 密钥，发送到在 5 月份归档的 Slack 频道，费用计入无人查看的项目预算。Agent 完全按照要求执行了操作。出问题的是那个“要求”，它随着时间的流逝变得不再适用。

这不是某个特定 Agent 的 bug。它是这类事物的共性。当我们赋予 Agent 调度持久副作用的能力时——如 cron 任务、Webhook、轮询循环、工作流触发器、日历邀请、定期查询——我们就创建了一类生来就没有生命周期的基础设施。“创建”原语显眼且容易，“删除”原语、“审计”原语、“继承”原语——它们并不具有同等的地位，因此未被使用。

除非你主动去寻找，否则代价是隐形的，而此时恰恰没有人会去寻找。

创建很容易，继承不可能​

传统基础设施拥有权属轨迹，因为它是由具有经理、团队、Slack 账号和 PagerDuty 轮值的人员创建的。生产环境服务器上的 cron 条目是由参加每日站会的人添加的。当那个人离开时，至少存在一个监管链：他们的经理继承他们的工单，他们的队友继承他们的轮值，最终有人会注意到那个孤儿任务，因为它会出现在他们的 grep 搜索结果中。

Agent 创建的基础设施完全不具备这些。Agent 不在团队中。Agent 不参加站会。在调度任务创建后的几秒钟内，Agent 的会话就结束了，而且 Agent 不记得自己创建过它。唯一的权属线索是提出请求的用户——而这条线索本身就非常脆弱。用户没有编写 cron 文件。用户没有命名工作流。用户通常不记得自己提出过要求，即便记得，他们也没有清单可以查阅。

行业中关于“非人类身份”这一密切相关类别的统计数据令人深思。只有 20% 的组织拥有正式的 API 密钥离职清理流程。91% 的前员工令牌在离职后仍然有效。平均每个企业环境包含超过 800 个存在风险的 AI Agent，而只有 15% 的组织报告拥有近乎完整的 Agent 所有权。现在想象一下，Agent 本身正在启动定期任务，而这些任务完全没有继承底层 Agent 身份已经无法维持的审计框架。这种不对称性在不断叠加。

安全社区确定的术语是“僵尸 Agent”——指在其所有者或用途消失后仍然存在的身份，它们保留了有效的凭据，且行为表现得像正常流量。僵尸 Agent 创建的任务在操作层面与之类似：在存在的理由消失后依然存续的调度任务，向已经发生变更的基础设施发送有效的请求。

失败模式是悄无声息的​

孤儿定期任务的失败方式不会触发任何人的报警：

• 调度任务发送到不再存在的 Slack 频道。Slack 返回 404。Agent 记录了没人阅读的错误日志。任务在下一个时间间隔重试。
• 调度任务针对已轮换的 API 密钥触发。记录了 401 响应。没有人会去分拣无人认领的任务产生的日志。
• 调度任务成功触发，发往一个已被停用的账户名下的收件箱。邮件退信。退信发送到 SMTP 发件人地址，即 Agent 的服务账户，没有人类阅读它。
• 调度任务成功触发，并将结果写入一个仍然存在但已被改作他用的目的地——用户过去查看的仪表板现在是另一个团队的指标仪表板。该信号正在悄悄地污染别人的视图。
• 调度任务成功触发，并在每个时间间隔消耗付费算力。账单寄往财务团队在 12 个月前标记为“未分配开销”的成本中心。由于没人认领，也就没人会动这笔未分配开销。

这些失败都不够响亮，不足以触发调查。它们的失败足够安静，以至于不断累积。任务队列在扩大，不是因为单个任务有错，而是因为删除任何单个任务都不是任何人的职责。

为什么这种不对称性是结构性的，而非偶然​

人们很容易将其视为 UX 失败——“Agent 就应该在创建时询问用户关于清理的问题”。这在边际上有帮助，但在系统层面会失败，原因有三。

第一，要求执行定期任务的用户，从本质上讲，对该任务未来的相关性是持乐观态度的。认为某件事值得每周做一次的人，通常不会预先承诺其过期日期。在创建时询问“这应该在什么时候停止？”，得到的答案会是“我不知道，让它运行就行”。这个答案在结构上是错误的，但在对话中是礼貌的，而 Agent 会接受它。

第二，用户与任务的关系，以及任务与基础设施的关系，被 Agent 解耦了。在 Agent 出现之前的世界里，当用户想要一个定期的 Slack 通知时，他们必须弄清楚如何设置，这意味着他们必须学习系统，这意味着他们最终对所创建的内容及其所在位置建立了一个心理模型。当 Agent 为他们完成这一切时，用户拥有的是一个请求和一个确认，而不是一个系统。他们无法审计自己在心理上无法定位的东西。

第三，Agent 的激励梯度偏向于创建。每一个 Agent 基准测试、每一个演示、每一个产品发布都在庆祝“采取行动的 Agent”。没有人为“六个月后删除自己陈旧输出的 Agent”运行基准测试。如果构建一个以“创建动作”评分的系统，你最终会得到一个本质上不断产生负债的发射器。