别让 Agent 活得太久, 从会话寿命到可恢复工作流的设计

发表于2026-08-28|更新于2026-09-07|视界AI研究

|浏览量:

凌晨一点，一个帮你处理日程的 Agent 还记得三月那句「这周感冒，别排早会」。它也还握着邮箱、日历和文档的读写权限。你觉得这是贴心，还是一颗慢慢变大的定时炸弹？

我读到 Tomasz Tunguz 这篇讨论 Agent 寿命的文章时，最有感的不是「24 小时重置」这个数字，而是一个常被产品演示掩盖的问题。我们太习惯把连续对话当成智能，把不退出当成忠诚。可一个越活越久的 Agent，往往不是越来越懂你，而是在积累越来越多过期假设、模糊指令和不该继续拥有的权限。

这不是让大家回到一次一问一答的聊天机器人。

恰好相反，想让 Agent 真正能干活，就得把「活得久」这件事拆开。

今天的 AI HOT 候选里，有 Claude 记忆打通聊天与 Cowork、Warp 用 Skills 做自我改进循环、OpenAI 把 Agent 推进更多工作场景。它们指向的是同一件事，Agent 开始从一个模型调用，变成带状态、能操作、会留下痕迹的系统。系统一旦有状态，就得有生命周期设计。没有这个设计，记忆会腐烂，权限会漂移，出错后也很难把现场复原。

我自己的判断很明确。不要给 Agent 一个「永久会话」。该长期保存的是经过筛选的状态，不是聊天记录本身。

一个永不下线的 Agent，到底哪里不对

长会话最诱人的地方，是它看起来省事。

你不用再解释项目背景，不用重复偏好，不用告诉它昨天做到哪一步。对于写作助手、研发 Copilot、运营 Agent，这种连续性确实很有价值。反过来想想看，如果每次打开 IDE 都得重新说明仓库结构、测试命令和代码风格，谁受得了。

问题在于，连续性有两种，很多系统把它们混成了一种。

一种是可验证的长期知识，比如团队使用 Java 21、服务通过 Spring Boot 3.x 部署、某个接口的幂等键规则、用户偏好把会议压缩到 30 分钟。这些信息有来源，能编辑，有效期也能被管理。

另一种只是当时对话留下的残渣，比如「这周先别动支付模块」「把语气改得更激进一点」「临时跳过安全扫描」。它们依附于具体任务和情境，过了那个时间点，价值会快速归零，甚至反过来伤人。

Tunguz 在原文里举了一个很直观的例子。三月让 Agent 因为感冒取消早会，到十一月它仍然躲开上午时段。人类会把这当成荒唐的误会，模型却只是在忠实延续一段没有被撤销的上下文。

这类问题不需要模型幻觉才会发生。

它只需要你的系统把旧信息持续塞回 prompt。

更麻烦的是安全问题。长寿 Agent 往往带着越来越多工具权限运行。早期它能读日历，后来为了完成一个流程又加了邮箱、云盘、代码仓库和浏览器登录态。权限是叠上去的，任务结束后却很少有人认真减回去。一次恶意邮件、一个带提示注入的文档，或者一段被误存成偏好的指令，都可能在数周后才被重新激活。

很多团队会说，模型上下文够长，问题就解决了。这话听着很顺，但我不太认同。上下文窗口变大，解决的是能不能装下，不是哪些内容还值得相信。一个 1M token 的房间，能塞进更多旧家具，也能塞进更多垃圾。

原文引用的研究把这种现象称作 context rot。输入越来越长，模型对信息的利用质量可能下降。另一个更工程化的风险是 compaction。系统为了省 token 把早期对话压成摘要，顺手把原本关键的约束、例外和边界压没了。Tunguz 引用的一篇 2026 年论文报告，安全约束在压缩过程中会在 30% 到 59% 的情形里丢失。

这个数字需要放在论文的具体实验设定里看，不能直接当成所有 Agent 的事故率。但方向已经很清楚，压缩不是记忆管理，它只是上下文的垃圾压缩机。

不要问它能记多久，要问状态该放在哪里

做 Agent 时，我更愿意把状态分成四层。这个划分不花哨，却能把很多「记忆功能」的争论落到工程决策上。

第一层, 请求上下文

它只服务一轮任务。

用户这次的问题、当前文件片段、一次工具调用的结果、暂存的思考草稿，都属于这里。任务完成就应释放，最多保留一个短 TTL 方便重试。它不该进入用户画像，更不该成为下次执行的系统指令。

例如一个 LangGraph 节点去查订单状态，输入包括订单号、当前操作者、查询时间和一次性授权。节点把结果交给下游，再结束。没有任何理由让这个查询 Agent 下周还记得订单号。

第二层, 工作会话状态

它服务一个明确的任务窗口，比如一次代码修复、一份报告、一整天的个人助理协作。

这里允许保留计划、子任务状态、已经读取的资料索引和中间产物，但必须有到期时间和终止条件。Tunguz 的建议是把日常协调 Agent 限制在 24 小时内，把单一用途子 Agent 限制到约 30 秒。这不是放之四海皆准的数字，却是一个很好的反问，为什么你的 Agent 必须永远不退出？

对研发场景，我通常会让会话寿命跟任务绑定，而不是跟自然日死绑。一次 PR 修复可以活到 CI 结果回来，一次数据排障可以活到告警关闭。超时后不是静默续命，而是产出 checkpoint，交给新的执行会话恢复。

这样做有点像 Kubernetes 的 Job，而不是一个永远不重启的 Pod。后者刚开始很省心，跑久了你会发现配置、缓存和临时文件已经没人敢碰。

第三层, 持久记忆

这一层保存的不是对话，而是被批准的事实。

用户偏好、项目约定、稳定的系统边界、已验证的排障结论，都可以进入这里。每条记忆至少应有来源、写入时间、适用范围、置信度和复审时间。没有这些字段的「长期记忆」，大概率只是一个不可审计的 Markdown 垃圾场。

以 Channing 这类同时做 Java/Spring 工程、LangGraph 和个人 Agent 系统的使用场景为例，下面两句话看着都像记忆，待遇却完全不同。

「项目默认使用 Java 21 与 Spring Boot 3.x」可以持久化，它有明确适用范围
「今天先别改支付模块」应该跟随当前任务到期，不应写进长期偏好

一条持久记忆最重要的能力不是被模型读到，而是被人和程序撤销。能查看、能编辑、能删除、能追溯来源，比「模型似乎记得」可靠得多。

第四层, 外部事实与业务状态

订单、日历、工单、Git commit、数据库记录，不是记忆。

这点特别容易被忽略。Agent 说「我记得这个需求已完成」，远不如它去查一次 Jira 状态或 CI 结果。业务真相要放在业务系统里，Agent 只保存定位它的键和必要摘要。把数据库状态塞进对话记忆，最终会得到一份既不实时、也没有事务保证的影子数据库。

如果一项信息能通过 API 查询到，优先查询。

不要让模型替系统当账本。

24 小时重置，并不是一刀切的万能答案

这里需要替长期运行 Agent 说句公道话。不是所有任务都适合 30 秒后消失。

发布流水线、长时间的数据分析、持续监控、复杂的多 Agent 编排，确实需要跨步骤甚至跨天运行。把它们粗暴重置，只会让系统反复丢掉进度，成本更高，错误也更多。

但长期任务需要的是可恢复，不是永生。

两者只差几个字，架构完全不同。永生会话依赖一条不断膨胀的对话链，恢复则依赖结构化 checkpoint。前者出问题时，你只能翻聊天记录猜它为什么这么做。后者可以明确看到任务版本、输入快照、已执行动作、剩余步骤、工具授权和失败原因。

这也是 Java 服务里成熟的工作流引擎早就教会我们的事。不要把流程状态藏在某个 JVM 的内存里。服务重启、实例漂移、消息重复投递都会发生。你要用数据库、事件日志、幂等键和状态机让流程能接着跑。

Agent 系统也该接受同一套纪律。

一个实用的任务状态可以长这样。

{
  "taskId": "release-20260828-001",
  "goal": "发布一篇通过校验的技术文章",
  "status": "waiting_for_ci",
  "checkpoint": "draft_uploaded",
  "artifacts": ["post_path", "commit_sha"],
  "grants": ["repo:chen-blog:write"],
  "expiresAt": "2026-08-29T15:00:00+08:00",
  "resumePolicy": "require_fresh_context"
}

这里的重点不在 JSON 长什么样，而在几个原则。

任务状态和模型对话分开存。模型可以换，任务不能丢。

授权要有作用域和过期时间。一个只负责生成草稿的子 Agent，不该继承生产发布权限。

恢复时重新加载最小必要上下文。不要把昨天两万 token 的闲聊原样塞回去，应该读取 checkpoint、当前仓库状态和仍然有效的长期规则。

每次外部写操作都要留下可验证回执。比如 commit SHA、工单 ID、文件 hash、HTTP 状态码。否则 Agent 的「我已经做完」只是一句口头承诺。

一个更稳的 Agent 编排，不靠超长 prompt

如果你正在用 LangGraph 或 Spring AI 搭建 Agent，我建议从一个很朴素的编排开始。

协调 Agent 只负责理解目标、拆任务、读取经过批准的长期记忆，以及决定是否需要人类确认。它不直接拥有所有工具。它的寿命可以是一次工作窗口，比如 8 小时，或直到某个流程完成。

执行 Agent 按能力拆开。代码检索 Agent 只读仓库，数据库查询 Agent 只读指定视图，发布 Agent 只在拿到明确 artifact 后拥有一次写入权限。每个执行 Agent 完成一个原子动作就返回结构化结果，然后退出。

记忆整理 Agent 是最后才出现的角色。它不应该自动把所有对话归档，而是从当天事件里提出候选记忆，例如「用户连续三次要求报告结论先行」。候选通过规则校验或人工确认后，才写入持久层。敏感数据、临时情绪、一次性指令默认丢弃。

这个流程不性感，也不像发布会上的全能 Agent。

但它能被排查。

可以把它画成一条很短的链路。

目标输入
  -> 协调 Agent 读取已批准记忆
  -> 短命执行 Agent 调工具
  -> 结构化回执写入 checkpoint
  -> 审批或规则引擎决定下一步
  -> 会话结束时生成记忆候选
  -> 持久化经过筛选的事实

其中最容易被省掉的一步是「记忆候选」。很多产品直接让主 Agent 自己决定该记住什么。我理解这种设计的吸引力，体验顺滑，用户也少点一次确认。但在高权限场景里，这等于让执行者兼任档案管理员和权限管理员。短期看少了流程，长期看很难解释一条记忆为什么存在。

Warp 最近分享的自我改进 Agent 做法也给了一个不错的侧面。它们把基础 Skills 和改进 Skills 作为文件，把人类反馈转化成可复用的改进。文件不是天然更安全，但相较于把规则埋进无限延长的聊天线程，它至少更可读、更能版本管理，也更容易 code review。

规则应当能被 diff。

这句话听起来很工程师，但对 Agent 来说，它可能比「更聪明的记忆」更重要。

三个常见误区，做久了都会疼

把聊天摘要当作知识库

摘要能节省 token，却不等于知识。它通常没有出处，也缺少冲突处理。更糟的是，摘要会把不确定的判断改写成肯定句。原始对话里可能是「我猜这个接口支持幂等」，压缩后很容易变成「该接口支持幂等」。下一轮 Agent 再把它当事实调用，就开始了错误的自我强化。

解决办法不是禁止摘要，而是给摘要标记用途。检索提示可以用摘要，行为约束和业务事实必须回到可验证来源。

给 Coordinator 开全量工具权限

协调 Agent 最容易被做成超级管理员，因为它什么都要调度。但真正需要执行邮箱发送、生产发布、删除数据的，往往是具体子任务。让 Coordinator 直接持有所有凭据，等于把一次 prompt injection 的爆炸半径放大到整个系统。

更好的做法是 capability token。协调 Agent 申请「为这个任务、在这段时间、对这个资源」的能力，执行节点在运行时取得短期授权。用 Spring Security 做过 OAuth2 Resource Server 的人，对这个思路不会陌生。身份、权限、资源范围和过期时间，本来就不该糊成一个布尔开关。