两年来“AI 代理的主导形象一直是一个里面装着聪明循环的聊天窗口。你输入目标代理调用一些工具你看着 token 流式输出当工作耗尽耐心或上下文窗口填满时你停止观看。这个范式带我们走了很远但它有天花板。模型会遗忘。它在任务还没完成时就宣称任务完成”。它会重新引入九个回合前修复过的 bug。整个结构围绕单次会话而建。长时间运行的代理是下一步。这个想法很简单一个代理在许多会话和许多沙盒环境中可能在许多天或许多周内持续朝着目标前进同时保持工作空间足够整洁让下一个会话能从上一个会话停止的地方接手。工程上更难。你必须以一种不只是粉饰裂缝的方式解决持久性、恢复和验证问题。你必须构建一个存在于模型上下文窗口之外的状态层你必须设计会话间的交接这样代理在醒来发现自己处于不同沙盒、不同上下文窗口时不会发疯。这篇文章是我尝试梳理发生了什么变化、谁在推动这些变化以及工程师今天如何在不从零开始编写整个系统的情况下使用长时间运行的代理。1、长时间运行到底意味着什么长时间运行在实践中至少被用来表示三种不同的事情区分它们是有帮助的。长时域推理。代理必须在许多相互依赖的步骤上规划和执行。这主要是一个模型质量的问题连贯性、规划能力、从十步之前的错误转弯中恢复的能力。METR 一直在用他们的时间范围指标追踪这一点该指标估算前沿模型能以 50% 的可靠性完成多长时间的任务。核心发现是该指标自 2019 年以来大约每七个月翻一番他们今年早些时候的 TH1.1 更新将评估集中 8 小时以上任务的数量翻了一倍。如果这个曲线保持下去前沿代理将在 2028 年达到天级任务完成能力2034 年达到年级任务完成能力。长时间运行执行。代理的进程运行数小时或数天。可能是一个编码任务可能是一个研究扫描可能是一个 7×24 小时的监控服务。模型可能在运行过程中被调用数千次。这主要是一个*框架harness*的问题也是本文主要讨论的内容。持久化代理。代理拥有超越任何单一任务的持久身份。它积累记忆、学习用户偏好并且始终可用。这是 Memory Bank 风格的长时间运行。在实践中这三者会模糊在一起。一个真正的生产级代理在长时间运行的执行中利用持久化代理进行长时域推理。但每种情况的工程问题不同解决它们的产品也不同。2、为什么这很重要我相信这项工作现在很重要的原因有两个。第一个是在经济上可以委托的事情发生了质变。一个运行十分钟的代理可以回答问题、总结文档、修复一个小 bug。一个运行十小时的代理可以负责整个功能、完成搁置了六个季度的迁移或者做以前需要初级分析师做的通宵研究扫描。Anthropic 的 Claude Sonnet 公告之一在去年秋天给出了具体数字内部测试中 30 多小时的自主编码包括一次运行产生了一个 11,000 行的 Slack 风格应用。这已经越过了我是否应该委托这个的答案不再显而易见的阈值。第二个是持久性改变了代理是什么。一个无状态的代理回答你的问题然后消失。一个长时间运行的代理积累上下文哪个竞争对手上周做了什么变动哪个测试在周二连续失败了两次你说的那个仪表盘通常指什么。Anthropic 的 Project Vend 是这方面最早的公开展示。他们让一个 Claude 实例运行了一个真正的办公室自动售货业务一个月管理库存、设定价格、与供应商沟通。它以有价值的方式失败了而第二阶段运行得好得多但重点不是盈利能力。重点是观察当代理必须在数周而非数个回合中维持身份时会出现什么样的奇怪的连贯性问题。这些正是每个构建生产级代理的团队现在都会遇到的问题。3、每个长时间运行代理都会遇到的三面墙三面墙在我今年读过的几乎所有文章中都出现了。有限的上下文。即使是 1M token 的窗口也会被填满。而且上下文腐烂——模型性能随窗口变满而持续退化——在硬性限制之前很久就会发生。一个 24 小时的运行不可能塞进该领域路线图上的任何上下文窗口。必须有某种妥协。没有持久化状态。新的会话从空白开始。Anthropic 在其科学计算文章中的表述是我见过的最清晰的版本“想象一个软件项目由轮班的工程师组成每个新工程师到来时对上一个班次发生的事情毫无记忆。”没有明确的持久化方案每次换班都是一场生产力灾难。没有自我验证。模型在给自己的工作打分时可靠地偏向积极。被问你完成了吗它们回答是的频率比应该的高。没有独立的信号表明工作达到了标准你就会得到一个以 30% 的完成度带着十足信心交付的代理。长时间运行代理的设计主要就是这三个问题的答案。各大实验室已经趋同于相似形状的答案但表层差异很大。4、Ralph 循环Ralph循环是长时间运行代理的一个较简单的实践者版本。Ralph 循环有时被称为 Ralph Wiggum 技术是长时间运行代理的一种较简单的实践者版本由 Geoffrey Huntley 和 Ryan Carson 推广。参考实现字面意思就是一个 bash 脚本它循环执行从列表prd.json或等效文件中选取下一个未完成的任务。构建一个包含任务、相关上下文和任何持久化笔记的提示。调用代理。运行测试或其他检查。将发生的事情追加到progress.txt。更新任务列表完成、失败、阻塞。回到步骤 1。它有效的原因与下面任何框架有效的原因相同状态存在于代理的上下文之外。prd.json是计划progress.txt是实验笔记AGENTS.md是滚动更新的规则手册。代理本身是健忘的但文件系统不是。每次迭代从全新状态开始从磁盘读取足够的状态来继续。Carson 的 Compound Product 通过链接多个循环一个读取每日报告的分析循环、一个发出 PRD 的规划循环、一个编写代码的执行循环扩展了这个想法这大致是 Anthropic 独立得出的规划器-生成器-评估器三联体的开源版本。我在《自我改进的代理》中更深入地讨论了所有这些任务列表结构、进度文件、QA 关卡、监控、你实际会遇到的各种失败模式。简短的版本是你可以用一个 bash 脚本和一个 JSON 文件在一个晚上构建一个可工作的长时间运行代理。Google 和 Anthropic 产品化的大部分工作是让这个模式可恢复、安全且在大规模下可观测。下面各大实验室的故事是支付这种生产就绪性的不同方式。5、Anthropic框架然后是大脑/手/会话分离Anthropic 在工程方面是最公开的。有两篇文章值得从头到尾阅读。第一篇是《长时间运行代理的有效框架》它提出了一个用于自主全栈开发的双代理框架。一个初始化代理在项目开始时运行一次设置环境将提示展开为结构化的feature-list.json并编写一个未来会话启动时将运行的init.sh。然后编码代理被反复唤醒每次会话被要求在一个功能上取得增量进展、运行测试、留下claude-progress.txt笔记并提交。一个测试棘轮“删除或编辑测试是不可接受的因为这可能导致遗漏或有缺陷的功能”放在提示中以阻止代理删除失败的测试来让它们通过这种非常常见的失败。InfoQ 的报道将其扩展为规划器、生成器和评估器三联体基于同样的逻辑将生成与评估分离很重要因为模型给自己的工作打分过于宽松。第二篇是《扩展托管代理将大脑从手中分离》这是 Claude Managed AgentsAnthropic 的托管运行时于 4 月初发布背后的架构文章。论点是代理有三个应该可以独立替换的组件。大脑Brain是模型和调用它的框架循环。手Hands是工具实际运行的沙盒化、临时执行环境。会话Session是每个思考、工具调用和观察的仅追加事件日志。这听起来很抽象但实际上不是。Anthropic 的表述“框架中的每个组件都编码了一个关于模型自身无法做什么的假设。”当你将它们耦合在一起时一个过时的假设例如模型以前需要显式的规划器现在可以原生规划了意味着整个系统必须同时改变。当你将它们解耦时框架变成无状态的沙盒变成牲畜而非宠物大脑崩溃不会丢失运行。一个新容器调用wake(sessionId)并从日志中重构状态。他们报告称首 token 时间在 p50 降低了约 60%p95 降低了 90% 以上仅仅是因为能够在沙盒就绪之前开始推理。会话作为事件日志这个想法是大多数团队最低估的部分。它是让长时间运行代理可恢复的关键。没有它容器故障就是会话故障你只能调试一个过时的快照。有了它代理的记忆是一个可查询的工件存在于当前运行的进程之外。对于科学计算领域Anthropic 的长时间运行 Claude 文章将所有这些简化为一个更简单的技术栈CLAUDE.md作为代理在学习过程中编辑的动态计划CHANGELOG.md作为可移植的实验笔记tmux加SLURM加git作为执行和协调层以及Ralph 循环一个for循环在代理声称完成时将其踢回上下文问它真的完成了没有。他们的旗舰案例研究是 Claude Opus 4.6 在几天内构建的玻尔兹曼求解器与参考的 CLASS 实现达到了亚百分比的一致性。数月到数年的研究人员时间被压缩了。三篇文章中出现了相同的模式明确的计划文件、明确的进度文件、会话间的结构化交接、将生成与评估分离以及一个拒绝让代理提前停止的循环。6、Cursor规划器、工作者、裁判Cursor 的扩展长时间运行自主编码是今年另一篇必读文章。他们遇到了 Anthropic 大多绕过了的墙壁。他们的第一次尝试是扁平的协调模型平等地位的代理通过锁写入共享文件。这变成了瓶颈并让代理变得风险厌恶反复修改而不是提交。第二次尝试用乐观并发控制替换了锁消除了瓶颈但没有解决协调问题。第三个设计是现在生产中运行的也是他们描述为解决了大部分问题的规划器Planners持续探索代码库并发出任务。它们可以递归地生成子规划器。工作者Workers是专注的执行者。它们不相互协调也不关心大局。裁判Judges决定迭代何时完成以及何时重启。文章中有两件事很突出。第一“系统行为的惊人数量归结为我们如何给代理写提示”比框架或模型更重要。第二不同的模型适配不同的角色。他们报告的发现是GPT 模型在扩展自主工作方面比 Opus 更好具体是因为 Opus 倾向于提前停止和走捷径。同样的任务不同的角色不同的模型。匹配正在成为设计界面的一部分。这与 Composer 2他们在 Cursor 3 中发布的专有前沿编码模型及其后台云代理搭配在 Anysphere 的云基础设施上运行的长时间运行任务而不是你的笔记本电脑上。八小时的重构和全代码库的迁移在你合上盖子后仍然存活。你可以在本地开始一个任务当意识到需要 30 分钟时点击在云中运行之后从手机重新连接。每个代理在隔离的 git worktree 中运行通过 PR 合并回去。本地和远程之间的交接是大多数团队尚未解决的部分Cursor 的押注是它必须成为独立的产品界面。最终形状接近 Anthropic 的角色被拆分会话是持久的裁判坐在工作者旁边长任务在带有 git 作为协调基底的云沙盒中运行。7、GoogleAgent Platform 上的长时间运行代理Google 两周前在 Cloud Next 26 上的公告将 Vertex AI 整合到了Gemini Enterprise Agent Platform中并将长时间运行代理变成了一个命名产品带有命名的 SLA。对本文来说重要的部分Agent Runtime支持*“自主运行数天”*的代理具有亚秒冷启动和按需沙盒配置。发布文章的示例用例是一个需要一周才能完成销售序列的销售潜在客户开发这大致是正确的形状。Agent Sessions持久化对话和事件历史。你可以将它们绑定到映射到你自己的 CRM 或数据库记录的自定义会话 ID这样代理的状态就存在于业务状态旁边而不是在一个单独的 AI 孤岛中。Agent Memory Bank是持久的长期记忆层在 Next 26 时已正式可用。它从会话中策划记忆将其限定在用户身份范围内并暴露搜索 API以便下一次代理调用可以拉取相关内容。Payhawk 报告称通过 Memory Bank 支持的代理自动提交费用将提交时间减少了 50% 以上。Agent Sandbox处理加固的代码执行。Agent-to-Agent 编排、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 的命名服务。三年前你需要自己构建所有这些。现在你选择要租用哪个版本的解耦的大脑、手和会话。8、生产中长时间运行代理的五种模式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 用基于图的工作流声明式地处理它一个专家中的不良部署不会级联到其他专家。这些模式可以组合。一个合规系统可能使用检查点处理文档处理使用委托审批处理审核关卡使用记忆分层处理跨会话知识使用集群编排协调各专家。开篇问题总是一样的你的代理需要执行的最长不间断工作单元是什么几分钟你不需要长时间运行代理。几小时或几天这些模式就是你的起点。带有代码示例的完整文章深入讲解了每种模式。9、那么你今天到底怎么构建一个这是一个实际问题答案取决于你在构建什么。你是一个开发者想要在自己的仓库上运行长时间编码工作。直接使用 Claude Code或 Antigravity、Cursor 或 Codex。框架已经在那里了。把你的AGENTS.md当作飞行员的检查清单简短每一行都由真实失败换来。添加类型检查和 lint 的钩子将失败反馈给代理。在代理开始之前写一个计划文件。当代理声称完成了而你不信时使用 Ralph 循环。对于多小时或通宵任务在 worktree 中运行这样合上笔记本电脑不会终止运行并让它在每个有意义的工作单元提交进展。这是大多数人应该走的路径也是目前杠杆效应最大的地方。你在构建一个托管的代理产品。不要自己构建运行时。选择一个托管的。今天真正的三个选择Google 的 Agent PlatformAgent Engine Memory Bank Sessions、Claude Managed Agents或者基于 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 明确表示将摘要作为压缩对于非常长的任务是不够的他们不得不进行完整的上下文重置框架拆除会话并从结构化交接文件中重建。这本质上就是人类如何让新工程师入职的。10、目前的一些真实限制有一些事情仍然是真正未解决的。成本。使用前沿模型和几个工具的 24 小时运行并不便宜。没有预算、熔断器和对工具支出的硬性上限代理可以在一个下午悄悄烧掉一周的 API 预算。这是可解决的但这是你必须明确采取的步骤。安全。一个拥有 API 密钥、云访问权限和运行 shell 命令能力的长时间运行代理比聊天会话有更大的攻击面。大脑/手分离模式在这里也很重要凭据应该从运行模型生成代码的沙盒中不可达这是 Anthropic 为 Managed Agents 强调的好处之一。对齐漂移。在许多上下文窗口中代理会漂移。原始目标被摘要然后被再次摘要然后失去保真度。这是钩子和裁判存在来防御的问题。这也是代理跑去做了我没要求的事情的最常见原因。验证。审计 24 小时的自主活动是一个真正的人类时间问题。可观测性和结构化工件PR、提交、简报、测试运行是你让这变得可管理的方式。没有它们你在滚动日志而且会错过重要的东西。人类角色。这是我一直在思考的问题。足够清晰地定义工作让代理能运行一天比自己动手做更难。正在升值的技能不是写代码。而是编写能在自主执行器面前存活下来的规格说明。11、发展方向Google、Anthropic 和 Cursor 已经趋同于大致相同的形状。将模型循环与执行沙盒与持久会话日志分离。将规划与生成与评估分离。内置压缩、钩子和上下文重置。将记忆暴露为任何代理调用都可以查询的托管服务。表层差异是不同的。Google 的 Agent Platform 是企业栈版本内置身份和审计追踪故事。底层模式相同。Claude Managed Agents 是Anthropic 的框架托管版。Cursor 的后台代理是长时间运行编码从 IDE 拉出来放到云端。明年的更难问题不在这些层中的任何一个单独层面。而在它们之上的协调。共享代码库上的许多长时间运行代理。读取自己的追踪并修补自己框架的代理。在任务时即时组装工具和上下文而非在启动时预配置的框架。那是代理不再看起来像一个更聪明的聊天窗口而开始像一个比你更早加入项目的同事的地方。模型仍然是承重的。但聊天窗口和一个你可以让它通宵运行的代理之间的差距主要在于包裹在它周围的状态、会话和结构化交接。这是我现在会投入学习时间的地方。原文链接长时运行智能体的5种设计模式 - 汇智网