内容
长期运行的AI智能体可以在数小时、数天甚至数周内持续取得进展。它能够在多个上下文窗口和沙箱环境中运行，从失败中恢复，留下结构化的工作成果，并在中断后从中断处继续执行。
两年来，"AI智能体"的主流形象一直是一个带有巧妙循环的聊天窗口。你输入一个目标，智能体调用一些工具，你看着token流过时观察结果，当工作失去耐心或上下文窗口填满时，你就停止观察。这种范式已经取得了很大进展，但也存在天花板。模型会遗忘，会在任务未完成时就宣布"任务完成"，甚至会重新引入九轮之前修复过的bug。整个流程都围绕单次会话构建。
长期运行的智能体就是下一步的发展方向。这个想法表述起来很简单：一个能够跨多个会话和多个沙箱持续朝着目标前进的智能体，可能持续数天或数周，同时保持工作空间足够清洁，以便下一个会话能够从中断处继续。但工程实现更具挑战性。你需要解决持久化、恢复和验证问题，而不仅仅是掩盖漏洞。你需要在模型上下文窗口之外建立一个状态层，并设计会话间的交接机制，确保智能体在醒来发现自己处于不同的沙箱环境且上下文窗口不同时不会精神崩溃。
本文是我尝试阐述变化内容、谁在推动这一发展，以及工程师如何在不从零开始编写全部代码的情况下，今天就能使用长期运行智能体的努力。
"长期运行"实际上意味着什么
在实践中，"长期运行"至少被用来表示三种不同的含义，最好将它们区分开来。
长时域推理。智能体必须在许多相互依赖的步骤中进行规划和执行。这主要是模型质量的问题：连贯性、规划能力，以及从十步之前的错误转向中恢复的能力。METR一直在通过他们的时间跨度指标来跟踪这一点，该指标估计前沿模型能以50%可靠性完成多长时间的任务。主要发现是，自2019年以来，该指标大约每七个月翻一番，他们今年早些时候发布的TH1.1更新将评估集中8小时以上任务的数量翻倍。如果这一趋势持续，到2028年前沿智能体将在天级尺度上完成任务，到2034年则在年级尺度上完成任务。
长期执行。智能体的进程持续运行数小时或数天。它可能是一个编码任务，可能是一次研究扫描，也可能是全天候监控服务。在此过程中，模型可能被调用数千次。这主要是框架的问题，也是本文主要关注的内容。
持久代理。智能体拥有超越单个任务的持久身份。它会积累记忆，学习用户偏好，并且始终可用。这是Memory Bank风格的长期运行。
在实践中，这三种概念相互交织。一个真实的生产级智能体会在长期执行中实现长时域推理，并由持久代理提供支持。但每个领域的工程问题各不相同，解决它们的产品也各不相同。
为什么这很重要
我认为这项工作现在非常重要有两个原因。
第一个原因是经济上可委托内容的阶段性转变。运行十分钟的智能体可以回答问题、总结文档或修复小bug。运行十小时的智能体可以负责整个功能，完成积压了六个季度的迁移任务，或者执行过去需要初级分析师整夜进行的研究扫描。Anthropic去年秋季的Claude Sonnet公告为这一点提供了具体数字：内部测试中30多个小时的自主编码，包括一次运行生成了11,000行Slack风格的应用程序。这已经超过了"是否应该委托此任务？"的答案不再显而易见的阈值。
第二个原因是持久性改变了智能体的本质。无状态智能体回答你的问题后就消失了。而长期运行的智能体会积累上下文：上周哪个竞争对手采取了什么行动，周二哪个测试两次失败，你通常所说的"仪表板"是什么意思。Anthropic的Project Vend是这方面最早的公开演示。他们让一个Claude实例实际运营办公室自动售货业务一个月，管理库存、设定价格并与供应商沟通。它以富有信息的方式失败了，第二阶段运行得更好，但重点不是盈利能力。重点是观察当智能体需要维持数周而非数轮的跨身份一致性时，会出现哪些奇怪的连贯性问题。
这些都是每个构建生产级智能体的团队都会遇到的问题。
每个长期运行智能体都会遇到的三个障碍
基本上我今年读到的每个帖子中都提到了三个障碍。
有限的上下文。即使是100万token的窗口也会填满。而且上下文退化——随着窗口填满，模型性能逐渐下降——在硬性限制之前就开始了。任何路线图上的上下文窗口都无法容纳24小时的运行。必须有所取舍。
没有持久状态。新会话从零开始。Anthropic在他们关于科学计算的帖子中的表述是我见过的最清晰的版本：*"想象一个由工程师组成的软件项目，他们轮流工作，每个新工程师到来时都不记得上一班发生了什么。"*如果没有明确的持久性方案，每次班次变更都会成为生产力灾难。
没有自我验证。模型在评估自己的工作时可靠地偏向正面。当被问及"你完成了吗？"时，它们比应该回答"是的"的次数更多。如果没有独立的信号表明工作达到了某个标准，你会得到一个以30%完成度自信发布结果的智能体。
长期运行智能体的设计主要是对这些三个问题的回应。主要实验室已经收敛到相似的解决方案形式，但表面面积却大不相同。
Ralph循环：长期运行智能体较简单的实践版本之一
Ralph循环(有时称为Ralph Wiggum技术)是"较简单"的实践版本长期运行智能体，由Geoffrey Huntley和Ryan Carson推广。参考实现实际上是一个bash脚本，循环执行以下步骤：
- 从列表中选择下一个未完成的任务(如prd.json或等效文件)
- 构建包含任务、相关上下文和任何持久笔记的提示
- 调用智能体
- 运行测试或其他检查
- 将发生的情况追加到progress.txt
- 更新任务列表(完成、失败、阻塞)
- 回到第一步
它之所以有效，是因为任何下面的框架都有效：状态存在于智能体上下文之外。prd.json是计划，progress.txt是实验记录，AGENTS.md是滚动规则手册。**智能体本身是失忆的，但文件系统不是。**每次迭代都是全新的，并从磁盘读取足够的状态来继续。Carson的Compound Product通过链式多个循环(读取每日报告的循环、输出PRD的规划循环、编写代码的执行循环)扩展了这一思想，这大致对应于Anthropic独立实现的规划器-生成器-评估器三元组。
我在自我改进智能体中深入探讨了所有这些内容：任务列表结构、进度文件、质量保证门、监控以及你实际会遇到的各种故障模式。简而言之，你可以在一个晚上用bash脚本和JSON文件构建一个工作的长期运行智能体。Google和Anthropic产品化的内容主要是使这种模式可恢复、安全且在规模上可观测的工作。
大型实验室的故事下面是支付这些生产就绪性的不同方式。
Anthropic：框架，然后是脑/手/会话分离
Anthropic在工程方面一直是最公开的。有两篇帖子值得从头到尾阅读。
第一篇是"长期运行智能体的有效框架"，它概述了一个用于自主全栈开发的两个智能体框架。初始化智能体在项目开始时运行一次，设置环境，将提示扩展为结构化的feature-list.json，并写入未来会话启动时将运行的init.sh。然后编码智能体会被反复唤醒，每个会话都被要求在一个功能上逐步推进，运行测试，留下claude-progress.txt笔记，并提交。提示中包含一个测试棘轮("删除或编辑测试是不可接受的，因为这可能导致功能缺失或出现错误")，以防止智能体删除失败的测试来"使其通过"这种常见失败。InfoQ的报道(https://www.infoq.com/news/2026/04/anthropic-three-agent-harness-ai/)将此扩展为规划器、生成器和评估器的三元组，其逻辑与将生成与评估分离很重要，因为模型对自己的工作评价过于慷慨。
第二篇是"扩展托管智能体：将大脑与双手解耦"，这是Claude托管智能体(Anthropic于四月初推出的托管运行时)背后的架构文章。论点是智能体有三个组件，应该可以独立替换。大脑是模型和调用它的框架循环。双手是沙箱化的临时执行环境，工具在这里实际运行。会话是每个思考、工具调用和观察的只追加事件日志。
这听起来很抽象，但其实不然。Anthropic的表述是："框架中的每个组件都编码了对模型自身无法做什么的假设。"当你耦合它们时，一个过时的假设(例如，模型过去需要显式规划器而现在能原生规划)意味着整个系统必须同时改变。当你解耦它们时，框架变得无状态，沙箱变成牛而不是宠物，大脑崩溃也不会丢失运行。一个新的容器调用wake(sessionId)并从日志中重建状态。他们报告说，仅仅通过能够在沙箱准备好之前就开始推理，首次token时间在第50百分位下降了约60%，在第95百分位下降了超过90%。
**会话作为事件日志的想法是大多数团队低估的部分。**正是这一点使得长期运行智能体可恢复。没有它，容器失败就是会话失败，你不得不调试一个过时的快照。有了它，智能体的记忆成为一个可查询的工件，它存在于当前运行的任何进程之外。
对于科学计算爱好者来说，Anthropic的长期运行Claude帖子将所有这些都简化为一个更简单的堆栈：CLAUDE.md作为智能体学习时编辑的活计划，CHANGELOG.md作为便携式实验记录，tmux加上SLURM再加上git作为执行和协调层，以及Ralph循环，这是一个for循环，每当智能体声称完成并询问它真的完成时就将智能体重新带入上下文。他们的标志性案例研究是在几天内构建的Boltzmann求解器Claude Opus 4.6，它与参考CLASS实现达到亚百分比的一致性。数月甚至数年的研究人员时间被压缩了。
三篇文章中的相同模式：显式计划文件、显式进度文件、会话间结构化交接、将生成与评估分离，以及一个拒绝让智能体过早停止的循环。
Cursor：规划者、工人、法官
Cursor的"扩展长期运行自主编码"是今年另一篇必读文章。他们遇到了Anthropic主要掩盖的障碍。
他们的第一次尝试是一个扁平的协调模型：平等地位的智能体用锁写入共享文件。这变成了瓶颈，使智能体变得风险厌恶，宁愿反复修改而不愿提交。他们的第二次尝试用乐观并发控制取代了锁，这消除了瓶颈但没有解决协调问题。现在的第三个设计是正在生产中运行的，他们描述为解决了大部分问题：
- 规划者持续探索代码库并发出任务。它们可以递归地生成子规划者。
- 工人是专注的执行者。它们不相互协调，也不关心大局。
- 法官决定何时迭代完成以及何时重启。
这篇文章中有两点特别突出。一是*"系统的行为很大程度上取决于我们如何提示智能体"，而不是框架或模型。二是不同的模型适合不同的角色。他们报告的发现是，GPT模型在延长自主工作*方面优于Opus，特别是因为Opus倾向于过早停止并走捷径。**相同任务，不同角色，不同模型。**这种匹配正成为设计表面的部分。
这与Composer 2(他们专有的前沿编码模型，随Cursor 3发布)以及他们的后台云智能体相配合：在Anysphere的云基础设施上运行的长期任务，而不是你的笔记本电脑。八小时的重构和整个代码库的迁移在合上盖子后仍然存活。你可以在本地开始任务，当你意识到需要30分钟时点击在云中运行，稍后再从手机重新连接。每个智能体在隔离的git工作树中运行，并通过PR合并。本地和远程之间的交接是大多数团队尚未解决的问题，Cursor的赌注是这必须是自己的产品表面。
最终形状与Anthropic的相似：角色被分割，会话是持久的，法官坐在工人旁边，一个长任务在带有git作为协调基石的云沙箱中运行。
Google：Agent Platform上的长期运行智能体
两周前，Google在Cloud Next '26上宣布将Vertex AI整合到Gemini企业智能体平台中，并将长期运行智能体作为一个命名产品推出，配有命名SLA。
对此文重要的组件：
- Agent Runtime支持"连续运行数天"的智能体，具有亚秒级冷启动和按需沙箱配置。发布文章中的用例是一个为期一周的销售线索开发序列，这正是合适的形状。
- Agent Sessions持久化对话和历史事件。你可以将其固定到自定义会话ID，映射到你自己的CRM或数据库记录，这样智能体的状态就与业务状态相邻，而不是存在于单独的AI孤岛中。
- Agent Memory Bank是持久的长时记忆层，自Next '26起一般可用。它从会话中整理记忆，将其限定到用户身份，并提供搜索API，以便下次智能体调用可以拉取相关内容。Payhawk报告称，通过Memory-Bank支持的智能体自动提交费用，提交时间减少了50%以上。
- Agent Sandbox处理加固的代码执行。
- Agent-to-Agent Orchestration、Agent Registry、Agent Identity、Agent Gateway、Agent Observability和Agent Simulation涵盖了生产级舰队通常需要手工构建的所有操作关注点，包括企业实际需要部署的加密身份和审计日志。
从架构上看，这与Anthropic描述的脑/手/会话分离相同，只是在平台规模上产品化，并与ADK(代码优先开发套件)和Agent Studio(可视化开发套件)捆绑在一起。如果你在Google Cloud内构建，你不再需要从零开始设计会话日志或内存存储。你将ADK智能体连接到Memory Bank和Sessions，部署到Agent Runtime，持久化问题就解决了。
注意这与Anthropic和Cursor描述的模式有多相似，只是被分解为带有SLA的命名服务。三年前你必须自己构建所有这些内容。现在你可以选择租用哪种版本的"解耦大脑、双手和会话"。
生产环境中长期运行智能体的五种模式
Shubham Saboo和我撰写了五种设计模式，这些模式让我们看到了从演示中分离出真正工作的长期运行智能体。它们不是Google特有的，但与Agent Runtime现在暴露的原语很好地对应，所以值得在这里简要介绍它们。
检查点和中止恢复。最常见的数天故障是上下文丢失。一个智能体在四小时内处理200个文档，在第201个文档上出错，如果没有检查点，你必须重新开始。将智能体视为长期运行的服务器进程：将中间状态写入磁盘，每N个工作单位检查一次点，从故障中恢复。Agent Runtime沙箱为你提供了持久文件系统，但选择合适的检查点粒度(不是每一步，也不是只在结束时)是你的责任。
委托审批(人机回圈)。大多数"人机回圈"的实现方式是：将状态序列化为JSON，触发webhook，希望有人响应。状态变得过时，通知被埋没，智能体重新反序列化到一个略有不同的世界。长期运行运行时允许智能体在原位置暂停，完整保留执行状态：推理链、工作记忆、工具历史、待处理操作。数小时的等待时间过去了，智能体消耗零计算资源，并以亚秒级延迟恢复。Mission Control是Google为此设计的收件箱。这种模式无论供应商如何都适用。
分层内存上下文。七天的智能体需要的不仅仅是会话状态。Memory Bank处理长期整理的记忆，Memory Profiles添加低延迟查找，你在生产中会遇到的故障模式是内存漂移：智能体从少数非典型交互中学到程序性捷径并开始广泛应用。像治理微服务一样治理内存。Agent Identity控制谁能读写哪些银行。Agent Registry跟踪哪个版本的哪个智能体正在运行。Agent Gateway强制执行策略。审计问题不再是"我的智能体在做什么？"而是"我的智能体记住了什么，以及这如何改变它们的行为？"
环境处理。并非所有长期运行智能体都与人类对话。有些位于Pub/Sub流或BigQuery表上，并在事件到达时采取行动：内容审核、异常检测、收件箱分类。值得早期做出的架构决策是不将策略硬编码到智能体中。在Gateway中定义它，整个舰队会在不重新部署的情况下获取策略更改。环境智能体长时间无人监督运行，更新它们的唯一合理方式是一次更新策略层。
舰队协调。在真实系统中，你很少只有一个智能体。协调员将子任务委派给专家(首席研究员智能体、评分智能体、外联智能体)，每个专家独立运行不同时长。每个专家都有自己的Identity(因此外联智能体不能读取评分智能体专用的财务数据)，有自己的策略执行和自己的Registry条目。这是分布式系统几十年来使用的协调员/工作者形状的相同模式。新的是ADK通过基于图的工作流以声明方式处理它，一个专家的糟糕部署不会级联到其他专家。
这些模式可以组合。合规系统可能使用检查点进行文档处理，委托审批进行审查门，内存分层进行跨会话知识，以及舰队协调来协调专家。基本问题总是相同的：*你的智能体需要执行的最长不间断工作单位是什么？*如果是几分钟，你不需要长期运行智能体。如果是几小时或几天，这些模式就是你应该开始的地方。完整的带代码示例的帖子详细介绍了每种模式。
那么你现在实际上如何构建一个呢？
这是一个实际问题，答案取决于你正在构建的内容。
你是一个想在自己的仓库上进行长期编码工作的开发者。只需使用Claude Code(或Antigravity、Cursor或Codex)。框架已经存在。将你的AGENTS.md视为飞行员检查单：简短，每一行都是真实失败的结果。添加类型检查和lint钩子，将失败反馈给智能体。在智能体开始前写一个计划文件。当智能体声称完成但你怀疑时，使用Ralph循环。对于多小时或过夜的工作，在worktree中运行，这样合上笔记本就不会杀死运行，并在每个有意义的工作单位提交进度。这是大多数人应该采取的道路，这也是目前最有杠杆作用的地方。
你正在构建托管智能体产品。不要构建运行时。选择一个托管的。今天真正的三个选项：Google的Agent Platform(Agent Engine + Memory Bank + Sessions)、Claude托管智能体，或者在ADK、Claude Agent SDK或Codex SDK之上构建并自行托管。权衡是通常的。托管提供给你开箱即用的脑/手/会话分离、可观测性、身份和审计跟踪。自建获得控制和为奇怪角色使用奇怪模型的能力(Cursor的模式)。对大多数团队来说，起点是托管运行时加上你自己的ADK或SDK代码来实现实际的循环。
你正在进行自主和运营工作(监控、研究、运维)。Memory Bank风格的持久性是你要找的，这在Claude Code中不存在。ADK + Memory Bank + Cloud Run + Cloud Scheduler是我见过的"智能体每N小时运行一次，积累状态，在阈值上报警"的最干净堆栈。这也是Cursor的规划者/工人/法官分割开始比IDE编码更重要的地方，因为工作确实是并行的，故障模式也不同。
无论你选择哪条路径，有几件事都很重要。
在智能体开始前写下完成条件。这是长期运行的最高杠杆移动。Anthropic框架文章称之为功能列表；Cursor称之为规划者的任务规范。无论如何，它是一个带有明确、可测试完成标准的外部文件，这样智能体就不能在运行中途悄悄地重新定义完成。
将评估者与生成者分离。自我评分是故障模式。规划者/工人/法官管道，或生成器/评估器配对，是一个真正的架构模式，而不仅仅是一种风格偏好。即使它是相同模型在不同角色中使用不同提示。
投资于会话日志，而不仅仅是提示。只追加事件日志是使智能体可恢复、可调试和可审计的原因。如果你不能从持久存储中重建智能体在过去24小时内所做的内容，你所拥有的只是一个碰巧调用LLM的长期运行shell脚本，而不是长期运行智能体。
将压缩和上下文重置视为头等大事。Anthropic明确表示，总结作为压缩对于非常长的作业不够；他们必须进行完整的上下文重置，其中框架拆除会话并从结构化交接文件重建它。这本质上就是人类如何为新工程师入职。
目前确实存在一些真正的限制
还有一些事情确实没有解决。
成本。使用前沿模型和几个工具的24小时运行并不便宜。没有预算、断路器和对工具支出的硬性限制，智能体可能在下午悄悄耗尽一周的API预算。这是可以解决的，但这是一个你必须采取的明确步骤。
安全性。具有API密钥、云访问和运行shell命令能力的长期运行智能体比聊天会话具有大得多的攻击面。脑/手分离模式在这里也很重要：凭据应该无法从模型生成的代码运行的沙箱中访问，这是Anthropic为托管智能体强调的好处之一。
对齐漂移。跨越多个上下文窗口，智能体会漂移。原始目标被总结，然后重新总结，然后失去保真度。这是钩子和法官存在来防御的部分。这也是"智能体去做了一些我没有要求的事情"的最常见原因。
验证。审计24小时的自主活动确实是一个人力问题。可观测性和结构化工件(PR、提交、简报、测试运行)是使这变得可行的方法。没有它们，你就是在滚动日志，你会错过重要的内容。
人类角色。这是我不断回归的一点。清晰地定义足够清楚的工作，让智能体可以运行一天，比你亲自做这项工作更难。价值正在上升的技能不是编写代码，而是编写能在自主执行器接触下存活的规范。
未来方向
Google、Anthropic和Cursor已经收敛到大致相同的形状。将模型循环与执行沙箱与持久会话日志分离。将规划与生成与评估分离。内置压缩、钩子和上下文重置。将内存作为可由任何智能体调用查询的托管服务暴露出来。
表面差异在于。Google的Agent Platform是企业级堆栈版本，内置了身份和审计跟踪。底层模式是相同的。Claude托管智能体是"Anthropic的框架，托管版"。Cursor的后台智能体是"长期运行编码，从IDE中提取到云端"。
未来一年的更困难问题不在于这些层中的任何一个单独，而在于它们之上的协调。共享代码库上的多个长期运行智能体。读取自己的跟踪并修补自己的框架的智能体。为任务即时组装工具和上下文的框架，而不是在启动时预配置。这就是智能体不再看起来像更聪明的聊天窗口，而是看起来像比你更了解项目的同事的时候。
模型仍然是承重墙。但在聊天窗口和你可以在夜间留下的智能体之间，差距主要在于围绕它的状态、会话和结构化交接。这就是我现在应该花时间学习的地方。