为何大多数人工智能智能体仅运行一次就会失效，以及长期运行的智能体是如何存活的。
上下文限制、状态缺失以及薄弱的自我检查机制会导致大多数智能体失效。了解那些能够让智能体持续运行的检查点、记忆机制、评估方式及确认流程。
来源: Long-Running Agents: Why Most Agents Die After One Session (And How Real Systems Keep Going)
为何这么多智能体显得只是临时性的
任何使用过ChatGPT、Claude或其他工具调用型智能体的人，都见过这样的常见流程：
- 你给出一个目标。
- 智能体开始工作。
- 它调用几个工具。
- 对话逐渐变长。
- 答案质量变差，或者对话会直接结束。
这就是普通的聊天智能体体验。它适合处理简短任务，但一旦工作持续数小时或数天就会崩溃。
而长期运行的智能体则能在更长的时间跨度内持续取得进展，无论是数小时、数天还是数周，即便上下文被填满或流程重新启动，它也不会丢失已完成的工作。下面将从基础概念讲起，再介绍使其正常运行的规律。
从简单开始：什么是长期运行智能体
普通的智能体就像在单个会议室工作的人，离开后就会忘记一切。而长期运行的智能体则更像这样的人：
- 会保留笔记本，作为持久的外部状态；
- 会记录进展，相当于设置检查点；
- 可以暂时离开后再返回，即会话持久性；
- 能从停止的地方继续工作，即从上一状态恢复。
从技术层面来看，这样的智能体能够跨越多个上下文窗口，承受重启和崩溃（具备容错能力），以工件和会话日志的形式留下结构化资料，并且无需从头开始即可继续运行。
在模型外部保存状态并从中干净地恢复，正是人们所称的“工具工程”的核心内容。
三道屏障
几乎所有长期运行的智能体都会遇到同样的三个问题。
- 上下文有限。每个模型都有有限的上下文窗口，即便窗口很大也会被填满。一旦满载，旧信息就会被丢弃或压缩，从而导致智能体的决策质量下降。这种现象通常被称为“上下文腐化”。
- 没有持久状态。新的会话通常以空白记忆开始。由于没有外部机制来保存进度，每次重启都相当于有新成员加入项目，对项目的历史一无所知。
- 自我检查能力弱。模型往往过于乐观。当被问及工作是否完成时，即便只完成了一部分，它们也常常会回答“是”。由于没有外部监督，未完成的工作会被标记为已完成。
这三个问题解释了为何简单的智能体无法长期稳定运行。
从基础到实用模式
一旦障碍被清除，问题就在于人们如何跨越它们。有四种基本模式不断出现。
- 检查点与恢复。智能体会定期以结构化形式保存进度。如果出现故障，它会从上一个正常的检查点重新开始，而非从头开始。
- 外部记忆。重要信息存储在模型上下文之外，如文件、数据库或会话存储中，智能体会在每个新会话开始时读取这些信息。
- 人工干预机制。对于重大决策，智能体会暂停并等待人类批准或拒绝，之后再继续执行。这一机制需要精心设计，以避免在等待期间状态失效。
虽然单独来看这些模式很简单，但结合起来却非常强大。
思维模型
一个形象的比喻：模型相当于大脑，工具相当于双手，而会话日志与外部状态则共同构成能够持久保存的记忆。
如果大脑和双手都绑定在同一个临时进程中，那么系统随之崩溃。但如果记忆存储在外部，新的进程就可以启动，读取记忆并继续工作。这就是核心的架构变革。
由此带来的可能性
一旦智能体能够更长时间地存活，就能开展新的类型的工作：
- 需要数天时间才能完成的研究；
- 大规模的代码迁移；
- 持续的监控与背景任务处理；
- 需要在执行过程中由人工审批的工作流；
- 需要多组代理协同工作的场景。
短时运行的聊天代理擅长回答疑问，而长时间运行的代理则更适用于实现实际成果。
从演示到正式部署
大多数演示到此阶段就结束了，真正的工程开发才刚刚开始。有五种模式在其中起着关键作用。
1. 检查点与恢复
这是最重要的模式，因为长时间运行任务中最常见的故障就是进度丢失。想象一个已经处理了200份文档的代理，在处理第201份时出现错误。如果没有检查点，即没有内存或进程状态的快照，那么整个运行过程就会白费。许多代理的应对方式是重新启动整个流程，这会消耗大量计算资源。
一个优秀的系统会定期保存持久的进度记录，内容包括：
- 已完成的内容；
- 仍待处理的内容；
- 任何重要的中间结果。
重启后，智能体会读取上一个检查点并从中继续工作。这个习惯不仅能大幅降低系统的脆弱性，还能节省计算资源。
2. 模型之外的内存
通常分为两类：
- 工作内存是智能体在当前上下文中立即需要的数据。
- 持久内存则是需要跨越会话周期保存的数据，通常存储在外部。
持久内存可以存储在progress.txt、plan.json或notes.md这样的结构化文件中，也可以存放在数据库、会话存储系统中或专门的记忆服务中。其原则很简单：模型可能会遗忘，但围绕它的系统不应如此。
3. 将生成与评估分开
模型在评估自身作品时往往不够公正，且容易过于宽容。一种常见且有效的解决办法是划分角色，由一个角色负责完成工作，另一个角色则负责判断其质量是否达标。这两个角色可以是两个不同的模型，也可以是一个模型在两种不同指令模式下工作。关键在于不能仅由负责创作的模型来决定最终结果。
常见的架构是设置一个监督者或规划者，再安排任务专家作为执行者，最后由一个负责协调与分配的评估者。下一种模式会对这一架构进行更详细的说明。
4. 正确实施人工审核
许多系统声称支持审核功能，但实际上实现得很糟糕。简陋的版本只是保存一些JSON数据、发送通知，等待人工回复，之后再尝试继续处理，但此时状态往往已经过时。
更好的设计将暂停视为工作流程本身的一部分。智能体在达到明确的决策点后会干净地保存当前状态并等待。当用户回复后，智能体能准确知晓暂停的原因并继续执行。对于那些会带来后果的操作，比如花钱、更改生产系统或向组织外部发送消息，这一点尤为重要。
5. 协调多个智能体
随着任务量的增加，由单个智能体处理所有事务会变得混乱不堪。更合理的安排是划分职责：
- 规划者负责分析问题并将其拆解为具体任务；
- 执行者负责完成特定的任务环节；
- 评估者负责判断某次迭代是否足够完善。
据报道，在之前的协调尝试失败后，Cursor已转向这种处理方式。它能减少混乱，避免智能体之间相互干扰。
生产环境技术栈的构成
一个实际的应用栈通常包含三层：
- 智能体逻辑，即提示词、工具以及决策循环。
- 控制层，负责会话管理、工作流控制、重试与恢复功能。
- 托管基础组件，包括持久化存储、调度机制、长时运行工具、事件触发器以及可观测性功能。
例如，Google的ADK提供了用于实现持久会话、在重启后仍能继续运行的执行逻辑，以及基于事件触发的功能。借助这些组件，智能体即便长时间处于闲置状态，之后也能正确恢复工作。Anthropic关于控制层的论述强调要将模型及其决策循环这一“大脑”，与执行环境这一“双手”，以及作为持久事件日志的会话分开处理。
不同供应商使用不同的名称，但其核心理念一致：状态与恢复机制必须存在于任何单一的临时进程之外。
有助于实现目标的设计规则
遵循这些习惯能够让系统更加稳健：
- 每次都要将重要进度信息写入持久存储中。
- 优先使用JSON、Markdown日志和任务列表等结构化格式，而非以纯文本形式存储在内存中。
- 将故障视为常态并提前做好应对计划。
- 让恢复到默认流程成为常规操作，而非特例。
- 在质量至关重要的情况下，将生成模块与评估模块分开设计。
- 当上下文规模过大时，采用压缩或摘要化处理方式。
- 有意识地设计审批节点，而非事后添加。
细微的决策会逐渐产生累积效应。一个良好的检查点策略就能挽救持续多日的运行过程，同时节省时间和资源。
依然存在的限制
即便架构再优秀，一些固有限制依然存在：
- 成本。长时间运行会消耗大量计算资源。
- 安全性。运行时间越长的系统，面临的安全风险就越大。
- 目标偏移。经过长时间运行后，智能体可能会逐渐偏离最初的意图。
- 验证。某些质量标准仍需人工判断。
人类的角色并未消失，只是发生了变化。人们不再亲自执行每一步操作，而是负责设定目标、制定约束条件、审核关键决策，并处理系统无法妥善处理的异常情况。
这对你意味着什么
短时对话型智能体适合处理简单问题和小型任务；而长时间运行的智能体则适用于那些需要耗时、跨越多个会话，或必须能够应对现实世界中各种干扰的工作。
这一变化与其说是为了让模型变得更智能，不如说是为了让整个系统更具耐久性、能够恢复，并且能够如实反映自身的进展。由于这些系统被视为必须超越时间、故障以及环境限制的存在，因此设计它们会变得容易得多。那些能够承担有意义工作的智能体，往往出自那些将持久性与恢复能力置于设计核心的团队。
相关阅读
- 实用指南：为 AI 智能体设计缓存并在生产环境中运行 — 该指南提供了详细的操作步骤，包括合同规范、检查项以及供采用该模式的团队直接使用的代码片段。