The following article originally appeared on Addy Osmani’s blog and is being reposted here with the author’s permission.以下文章最初发表于Addy Osmani的博客，经作者许可在此转载。
A long-running AI agent can keep making progress over hours, days, or weeks. It can do this across many context windows and sandboxes, recover from failure, leave structured artifacts behind, and resume where it left off.一个长期运行的AI智能体可以在数小时、数天或数周内持续取得进展。它可以在多个上下文窗口和沙盒中执行此操作，从故障中恢复，留下结构化工件，并在中断处继续。
For two years the dominant image of an “AI agent” has been a chat window with a clever loop in it. You type a goal; the agent calls some tools; you watch tokens stream by; you stop watching when the work runs out of patience or the context window fills up. That paradigm got us a long way, but it has a ceiling. The model forgets. It declares “task complete” when it isn’t. It reintroduces a bug it fixed nine turns ago. The whole thing is structured around a single sitting.两年来，“AI智能体”的主流形象一直是一个带有巧妙循环的聊天窗口。你输入一个目标；智能体调用一些工具；你看着令牌流经过；当工作失去耐心或上下文窗口填满时，你停止观看。这种范式让我们走了很远，但它有一个天花板。模型会遗忘。它会在任务未完成时宣布“任务完成”。它会重新引入它在九轮前修复的bug。整个结构围绕单次会话展开。
Long-running agents are what comes next. The idea is easy to state: an agent that keeps making forward progress on a goal across many sessions and many sandboxes, possibly many days or weeks, while leaving the workspace clean enough that the next session can pick up where the last one left off. The engineering is harder. You have to solve for persistence, recovery, and verification in a way that doesn’t just paper over the cracks. You have to build a state layer that lives outside the model’s context window, and you have to design the handoff between sessions so the agent doesn’t lose its mind when it wakes up and finds itself in a different sandbox with a different context window.长期运行的智能体是下一步。这个想法很容易表述：一个智能体，在多个会话和多个沙盒中持续朝着目标取得进展，可能持续数天或数周，同时保持工作空间足够整洁，以便下一个会话可以从上一个会话中断处继续。工程实现更难。你必须以不只是在裂缝上贴膏药的方式解决持久性、恢复和验证问题。你必须构建一个存在于模型上下文窗口之外的状态层，并且你必须设计会话之间的交接，以便智能体在醒来并发现自己处于具有不同上下文窗口的不同沙盒中时不会失去理智。
This post is my attempt to lay out what’s changed, who’s pushing on it, and how an engineer can use long-running agents today without writing the whole thing from scratch.这篇文章是我试图阐述发生了什么变化，谁在推动它，以及工程师如何在不从头开始编写整个系统的情况下，在今天使用长期运行的智能体。
What “long-running” actually means“长期运行”的实际含义
“Long-running” used to mean at least three different things in practice, and it helps to keep them separate.在实践中，“长期运行”过去至少指代三种不同的事物，将它们分开理解会有所帮助。
Long-horizon reasoning. The agent has to plan and execute over many dependent steps. This is mostly a model-quality story: coherence, planning, the ability to recover from a wrong turn 10 steps ago. METR has been tracking this with their time horizon metric, which estimates how long a task a frontier model can complete with 50% reliability. The headline finding is that the metric has been doubling roughly every seven months since 2019, and their TH1.1 update earlier this year doubled the count of eight-hour-plus tasks in the eval set. If that curve holds, frontier agents complete tasks at the day scale by 2028 and the year scale by 2034.长视野推理。智能体必须规划和执行许多依赖步骤。这主要是一个模型质量的故事：连贯性、规划、从10步前的错误转弯中恢复的能力。METR一直在用他们的时间跨度指标追踪这一点，该指标估计前沿模型能以50%可靠性完成多长的任务。主要发现是，自2019年以来，该指标大约每七个月翻一番，而他们今年早些时候的TH1.1更新将评估集中八小时以上任务的数量翻了一番。如果这条曲线保持下去，前沿智能体将在2028年之前完成以天为规模的任务，在2034年之前完成以年为规模的任务。
Long-running execution. The agent’s process runs for hours or days. Maybe it’s a coding job, maybe it’s a research sweep, maybe it’s a 24-7 monitoring service. The model might be invoked thousands of times across the run. This is mostly a harness story, and it’s the one this post is mostly about.长期运行执行。智能体的进程运行数小时或数天。可能是一个编码工作，可能是一个研究扫描，可能是一个24/7的监控服务。模型可能在运行过程中被调用数千次。这主要是一个框架的故事，也是这篇文章主要讨论的内容。
Persistent agency. The agent has an identity that outlives any single task. It accumulates memory, learns user preferences, and is always available. This is the Memory Bank flavor of long-running.持久化智能体。智能体拥有超越任何单个任务的身份。它积累记忆，学习用户偏好，并且始终可用。这是长期运行的Memory Bank风格。
In practice the three blur together. A real production agent does long-horizon reasoning inside a long-running execution backed by persistent agency. But the engineering problems are different in each, and so are the products that solve them.在实践中，这三者相互融合。一个真正的生产级智能体在由持久化智能体支持的长期运行执行中进行长视野推理。但每个方面的工程问题不同，解决它们的产品也不同。
Why this matters为什么这很重要
There are two reasons I believe this work matters a lot right now.我相信这项工作现在非常重要的两个原因。
The first is a phase change in what’s economically feasible to delegate. An agent that runs for 10 minutes can answer a question, summarize a doc, fix a small bug. An agent that runs for 10 hours can own an entire feature, finish a migration that was on the backlog for six quarters, or do the kind of overnight research sweep that used to require a junior analyst. One of Anthropic’s Claude Sonnet announcements put concrete numbers on this last fall: 30+ hours of autonomous coding in internal tests, including one run that produced an 11,000-line Slack-style app. That’s already past the threshold where the answer to “Should I delegate this?” is no longer obvious.首先是经济上可委托的任务发生了阶段性变化。运行10分钟的智能体可以回答问题、总结文档、修复小bug。运行10小时的智能体可以负责整个功能、完成积压了六个季度的迁移，或者进行过去需要初级分析师才能完成的通宵研究扫描。Anthropic去年秋天在Claude Sonnet的公告中给出了具体数字：内部测试中超过30小时的自主编码，包括一次生成了11,000行Slack风格应用程序的运行。这已经超过了“我应该委托这个吗？”答案不再显而易见的阈值。
The second is that persistence changes what the agent is. A stateless agent answers your question and disappears. A long-running one accumulates context: which competitor moved which way last week, which test flaked twice on Tuesday, what you usually mean by “the dashboard.” Anthropic’s Project Vend was the most public early demonstration of this. They had a Claude instance run an actual office vending business for a month, managing inventory, setting prices, talking to suppliers. It failed in informative ways, and the second phase ran much better, but the point wasn’t profitability. The point was watching what kinds of weird coherence problems show up when an agent has to maintain identity across weeks instead of turns.其次是持久性改变了智能体的本质。无状态智能体回答你的问题然后消失。长期运行的智能体积累上下文：上周哪个竞争对手采取了什么行动，周二哪个测试两次失败，你通常说的“仪表盘”是什么意思。Anthropic的Project Vend是最公开的早期演示。他们让一个Claude实例实际运营了一个月的办公室自动售货业务，管理库存、定价、与供应商沟通。它以信息丰富的方式失败了，第二阶段运行得好得多，但重点不是盈利能力。重点是观察当智能体需要跨周而不是跨轮次维持身份时，会出现哪些奇怪的连贯性问题。
Those are the same problems every team building production agents now hits.这些正是每个构建生产级智能体的团队现在都会遇到的问题。
The three walls every long-running agent hits每个长期运行智能体都会遇到的三个障碍
Three walls show up in basically every write-up I’ve read this year.今年我读过的几乎所有文章中都会出现三个障碍。
Finite context. Even a 1M-token window fills. And context rot, the steady degradation of model performance as the window gets full, kicks in well before the hard limit. A 24-hour run is not going to fit in any context window the field has on its roadmap. Something has to give.有限的上下文。即使是100万令牌的窗口也会填满。而且上下文腐烂，即随着窗口变满模型性能的稳定下降，在达到硬限制之前很久就会开始。24小时的运行无法适应该领域路线图上的任何上下文窗口。必须有所改变。
No persistent state. A new session starts blank. Anthropic’s framing in their scientific computing post is the cleanest version I’ve seen: “Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.” Without an explicit persistence story, every shift change is a productivity disaster.没有持久状态。新会话从空白开始。Anthropic在他们科学计算文章中的表述是我见过最清晰的：“想象一个由轮班工程师组成的软件项目，每个新工程师到达时对上一班发生的事情毫无记忆。”没有明确的持久性方案，每次换班都是一场生产力灾难。
No self-verification. Models reliably skew positive when they grade their own work. Asked “Are you done?” they answer “yes” more often than they should. Without a separate signal that the work meets a bar, you get the agent that ships at 30% complete with full confidence.没有自我验证。模型在评估自己工作时可靠地偏向积极。当被问到“完成了吗？”时，它们回答“是”的频率高于应有的水平。如果没有一个独立的信号表明工作达到了标准，你就会得到一个以完全信心交付30%完成度的智能体。
Long-running agent designs are mostly answers to these three problems. The major labs have converged on similar shapes of answer, but with very different surface area.长期运行智能体的设计主要是对这些三个问题的回答。主要实验室已经收敛到相似的答案形状，但具有非常不同的表面区域。
The Ralph loop: One of the simpler practitioner versions of long-running agentsRalph循环：长期运行智能体的一个较简单的实践者版本
The Ralph loop (sometimes called the Ralph Wiggum technique) is one of “simpler” practitioner version of long-running agents, popularized by Geoffrey Huntley and Ryan Carson. The reference implementation is literally a bash script that loops:Ralph循环（有时称为Ralph Wiggum技术）是长期运行智能体的一个“较简单”的实践者版本，由Geoffrey Huntley和Ryan Carson推广。参考实现实际上是一个循环的bash脚本：
- Pick the next unfinished task from a list (prd.json or equivalent).从列表（prd.json或等效文件）中选择下一个未完成的任务。
- Build a prompt with the task, the relevant context, and any persistent notes.用任务、相关上下文和任何持久化笔记构建提示。
- Call the agent.调用智能体。
- Run tests or other checks.运行测试或其他检查。
- Append what happened to progress.txt.将发生的情况追加到progress.txt。
- Update the task list (done, failed, blocked).更新任务列表（完成、失败、阻塞）。
- Go back to step 1.返回步骤1。
The reason it works is the same reason any of the harnesses below work: State lives outside the agent’s context. prd.json is the plan, progress.txt is the lab notes, and AGENTS.md is the rolling rulebook. The agent itself is amnesiac, but the filesystem isn’t. Each iteration starts fresh and reads enough state from disk to keep going. Carson’s Compound Product extends the idea by chaining multiple loops (an analysis loop that reads daily reports, a planning loop that emits a PRD, an execution loop that writes the code), which is roughly the open source version of the planner-generator-evaluator triad Anthropic landed on independently.它起作用的原因与下面任何框架相同：状态存在于智能体的上下文之外。prd.json是计划，progress.txt是实验笔记，AGENTS.md是滚动规则手册。智能体本身是健忘的，但文件系统不是。每次迭代都重新开始，并从磁盘读取足够的状态以继续。Carson的Compound Product通过链接多个循环（一个读取每日报告的分析循环，一个发出PRD的规划循环，一个编写代码的执行循环）扩展了这个想法，这大致是Anthropic独立得出的规划器-生成器-评估器三元组的开源版本。
I went deeper on all of this in “Self-Improving Coding Agents”: task list structure, progress files, QA gates, monitoring, the failure modes you’ll actually hit. The short version is that you can build a working long-running agent in an evening with a bash script and a JSON file. Most of what Google and Anthropic have productized is the work of making this pattern recoverable, secure, and observable at scale.我在《自我改进的编码智能体》中深入探讨了所有这些：任务列表结构、进度文件、QA门控、监控、你实际会遇到的失败模式。简而言之，你可以用一个bash脚本和一个JSON文件在一个晚上构建一个可工作的长期运行智能体。Google和Anthropic产品化的大部分工作都是使这种模式可恢复、安全且可大规模观察。
The big-lab stories below are different ways of paying for that production-readiness.下面的大型实验室故事是为这种生产就绪性买单的不同方式。
Anthropic: Harnesses, then the brain/hands/session splitAnthropic：框架，然后是大脑/手/会话分离
Anthropic has been the most public about the engineering. Two posts are worth reading end to end.Anthropic在工程方面最为公开。有两篇文章值得从头到尾阅读。
The first is “Effective Harnesses for Long-Running Agents,” which lays out a two-agent harness for autonomous full stack development. An initializer agent runs once at the start of a project to set up the environment, expand the prompt into a structured feature-list.json, and write an init.sh that future sessions will run on boot. A coding agent is then woken up over and over, each session asked to make incremental progress on one feature, run tests, leave a claude-progress.txt note, and commit. A test ratchet (“it is unacceptable to remove or edit tests because this could lead to missing or buggy functionality”) sits in the prompt to stop the very common failure of an agent deleting failing tests to “make them pass.” InfoQ’s writeup extends this into a planner, generator, and evaluator triad, on the same logic that separating generation from evaluation matters because models grade their own work too generously.第一篇是《长期运行智能体的有效框架》，它提出了一个用于自主全栈开发的双智能体框架。一个初始化智能体在项目开始时运行一次，以设置环境，将提示扩展为结构化的feature-list.json，并编写一个init.sh供未来会话在启动时运行。然后，一个编码智能体被反复唤醒，每个会话被要求对一个功能进行增量进展，运行测试，留下claude-progress.txt笔记，并提交。一个测试棘轮（“删除或编辑测试是不可接受的，因为这可能导致缺失或有bug的功能”）位于提示中，以阻止智能体删除失败测试以“使其通过”这一非常常见的失败。InfoQ的文章将其扩展为规划器、生成器和评估器三元组，基于相同的逻辑：分离生成和评估很重要，因为模型对自己工作的评价过于慷慨。
The second is “Scaling Managed Agents: Decoupling the Brain from the Hands,” the architectural post behind Claude Managed Agents (Anthropic’s hosted runtime, launched in early April). The argument is that an agent has three components that should be independently replaceable. The Brain is the model and the harness loop that calls it. The Hands are sandboxed, ephemeral execution environments where tools actually run. The Session is an append-only event log of every thought, tool call, and observation.第二篇是《扩展托管智能体：将大脑与手解耦》，这是Claude托管智能体（Anthropic的托管运行时，于4月初推出）背后的架构文章。其论点是智能体有三个应该独立可替换的组件。大脑是模型和调用它的框架循环。手是沙盒化的、短暂的执行环境，工具在其中实际运行。会话是一个仅追加的事件日志，记录每一个想法、工具调用和观察。
This sounds abstract, but it isn’t. Here’s Anthropic’s framing: “Every component in a harness encodes an assumption about what the model can’t do on its own.” When you couple them, an assumption that goes stale (e.g., the model used to need an explicit planner and now plans natively) means the whole system has to change at once. When you decouple them, the harness becomes stateless, sandboxes become cattle, not pets, and a brain crash doesn’t lose the run. A fresh container calls wake(sessionId) and reconstitutes the state from the log. They reported time-to-first-token dropped ~60% at p50 and over 90% at p95 just from being able to start inference before the sandbox is ready.这听起来抽象，但并非如此。以下是Anthropic的表述：“框架中的每个组件都编码了一个关于模型自身无法完成什么的假设。”当你将它们耦合时，一个过时的假设（例如，模型过去需要显式规划器，现在原生规划）意味着整个系统必须同时改变。当你解耦它们时，框架变得无状态，沙盒变得可替换而非宠物，大脑崩溃不会丢失运行。一个新的容器调用wake(sessionId)并从日志中重建状态。他们报告说，仅凭能够在沙盒准备好之前开始推理，首次令牌时间在p50下降了约60%，在p95下降了超过90%。
The session-as-event-log idea is the part most teams underappreciate. It is what makes a long-running agent recoverable. Without it, a container failure is a session failure and you’re debugging into a stale snapshot. With it, the agent’s memory is a queryable artifact that lives outside whatever process happens to be running at the moment.会话即事件日志的想法是大多数团队低估的部分。正是它使长期运行智能体可恢复。没有它，容器故障就是会话故障，你会在过时的快照中调试。有了它，智能体的记忆是一个可查询的工件，存在于任何碰巧正在运行的进程之外。
For the scientific computing crowd, Anthropic’s “long-running Claude” post reduces all of this to a simpler stack: CLAUDE.md as a living plan the agent edits as it learns, CHANGELOG.md as portable lab notes, tmux plus SLURM plus git as the execution and coordination layer, and the Ralph loop, a for loop that kicks the agent back into context whenever it claims completion and asks if it’s really done. Their flagship case study is a Boltzmann solver Claude Opus 4.6 built over a few days that reached subpercent agreement with a reference CLASS implementation. Months to years of researcher time, compressed.对于科学计算人群，Anthropic的“长期运行Claude”文章将所有这些简化为一个更简单的堆栈：CLAUDE.md作为智能体在学习时编辑的活计划，CHANGELOG.md作为便携式实验笔记，tmux加SLURM加git作为执行和协调层，以及Ralph循环，一个for循环，每当智能体声称完成并询问是否真的完成时，将其踢回上下文。他们的旗舰案例研究是一个Claude Opus 4.6在几天内构建的玻尔兹曼求解器，达到了与参考CLASS实现低于百分之一的一致性。数月到数年的研究人员时间被压缩了。
Same patterns across all three posts: an explicit plan file, an explicit progress file, structured handoffs between sessions, separate generation from evaluation, and a loop that refuses to let the agent stop early.所有三篇文章中的相同模式：一个显式计划文件，一个显式进度文件，会话之间的结构化交接，分离生成和评估，以及一个拒绝让智能体提前停止的循环。
Cursor: Planners, workers, judgesCursor：规划器、工作者、评判者
Cursor’s “Scaling Long-Running Autonomous Coding” is the other essential read this year. They walked into walls that Anthropic mostly papered over.Cursor的《扩展长期运行自主编码》是今年另一篇必读文章。他们遇到了Anthropic大多掩盖的障碍。
Their first attempt was a flat coordination model: equal-status agents writing to shared files with locks. It became a bottleneck and made the agents risk averse, churning rather than committing. Their second attempt swapped locks for optimistic concurrency control, which removed the bottleneck but didn’t fix the coordination problem. The third design is what’s running in production now and what they describe as solving most of the problem:他们的第一次尝试是一个扁平协调模型：同等地位的智能体使用锁写入共享文件。这成为了瓶颈，并使智能体变得风险规避，反复折腾而不是提交。他们的第二次尝试用乐观并发控制替换了锁，这消除了瓶颈，但没有解决协调问题。第三个设计是现在生产环境中运行的设计，他们描述为解决了大部分问题：
- Planners continuously explore the codebase and emit tasks. They can recursively spawn subplanners.规划器持续探索代码库并发出任务。它们可以递归地生成子规划器。
- Workers are focused executors. They don’t coordinate with each other and they don’t worry about the big picture.工作者是专注的执行者。它们不相互协调，也不担心大局。
- Judges decide when an iteration is finished and when to restart.评判者决定迭代何时完成以及何时重新开始。
Two things stand out from the post. One: “A surprising amount of the system’s behavior comes down to how we prompt the agents” more than the harness or the model. Two: Different models slot into different roles. Their reported finding is that a GPT model was better than Opus for extended autonomous work specifically because Opus tended to stop early and take shortcuts. Same task, different role, different model. The matching is becoming part of the design surface.文章中有两点突出。一：“系统行为的惊人数量归结于我们如何提示智能体”，而不是框架或模型。二：不同的模型适合不同的角色。他们报告发现，GPT模型在扩展自主工作方面比Opus更好，特别是因为Opus倾向于提前停止并走捷径。相同的任务，不同的角色，不同的模型。匹配正在成为设计表面的一部分。
This pairs with Composer 2 (their proprietary frontier coding model that ships in Cursor 3) and their background cloud agents: long-running tasks that run on Anysphere’s cloud infrastructure rather than your laptop. Eight-hour refactors and codebase-wide migrations survive a closed lid. You can start a task locally, hit run in cloud when you realize it’ll take 30 minutes, and reattach later from your phone. Each agent runs in an isolated Git worktree and merges back via PR. The handoff between local and remote is the part most teams haven’t figured out yet, and Cursor’s bet is that it has to be its own product surface.这与Composer 2（他们在Cursor 3中提供的专有前沿编码模型）和他们的后台云智能体配对：在Anysphere的云基础设施上运行的长任务，而不是你的笔记本电脑。八小时的重构和代码库范围的迁移在合上盖子后仍然存活。你可以在本地启动一个任务，当你意识到它将花费30分钟时在云中运行，然后稍后从手机重新连接。每个智能体在隔离的Git工作树中运行，并通过PR合并回来。本地和远程之间的交接是大多数团队尚未解决的部分，而Cursor的赌注是它必须成为自己的产品表面。
The shape ends up close to Anthropic’s: Roles are split, sessions are durable, judges sit beside the worker, and a long task runs in a cloud sandbox with Git as the coordination substrate.最终形状接近Anthropic：角色被拆分，会话是持久的，评判者与工作者并列，长任务在云沙盒中运行，以Git作为协调基础。
Google: Long-running agents on the Agent PlatformGoogle：Agent Platform上的长期运行智能体
Google’s announcement at Cloud Next ’26 folded Vertex AI into the Gemini Enterprise Agent Platform and turned long-running agents into a named product, with named SLAs.Google在Cloud Next '26上的公告将Vertex AI整合到Gemini Enterprise Agent Platform中，并将长期运行智能体变成了一个命名产品，具有命名的SLA。
The pieces that matter for this post:对于本文重要的部分：
- Agent Runtime supports agents that “run autonomously for days at a time” with sub-second cold starts and on-demand sandbox provisioning. The launch post’s example use case is a sales prospecting sequence that takes a week to play out, which is roughly the right shape for it.Agent Runtime支持“自主运行数天”的智能体，具有亚秒级冷启动和按需沙盒配置。发布文章中的示例用例是一个需要一周时间展开的销售勘探序列，这大致是合适的形状。
- Agent Sessions persist conversation and event history. You can pin them to a custom session ID that maps to your own CRM or DB record, so the agent’s state lives next to the business state instead of in a separate AI silo.Agent Sessions持久化对话和事件历史。你可以将它们固定到映射到你自己的CRM或数据库记录的自定义会话ID，这样智能体的状态就存在于业务状态旁边，而不是在单独的AI孤岛中。
- Agent Memory Bank is the persistent long-term memory layer, generally available as of Next ’26. It curates memories from sessions, scopes them to a user identity, and exposes a search API so the next agent invocation can pull what’s relevant. Payhawk reported that auto-submitting expenses through a Memory Bank-backed agent cut submission time by over 50%.Agent Memory Bank是持久化长期记忆层，自Next '26起普遍可用。它从会话中整理记忆，将其范围限定到用户身份，并公开一个搜索API，以便下一次智能体调用可以拉取相关内容。Payhawk报告说，通过Memory Bank支持的智能体自动提交费用，将提交时间减少了超过50%。
- Agent Sandbox handles hardened code execution.Agent Sandbox处理强化代码执行。
- Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, and Agent Simulation cover basically every operational concern you’d otherwise build by hand for a production fleet, including the cryptographic-identity-and-audit-log story enterprises actually need to ship.Agent-to-Agent Orchestration、Agent Registry、Agent Identity、Agent Gateway、Agent Observability和Agent Simulation涵盖了基本上所有你原本需要为生产集群手动构建的操作关注点，包括企业实际需要交付的加密身份和审计日志故事。
Architecturally this is the same brain/hands/session split Anthropic described, just productized at platform scale and bundled with ADK (the code-first dev kit) and Agent Studio (the visual one). If you’re building inside Google Cloud, you don’t have to design a session log or a memory store from scratch anymore. You wire an ADK agent into Memory Bank and Sessions, deploy onto Agent Runtime, and the persistence question is answered.在架构上，这与Anthropic描述的大脑/手/会话分离相同，只是在平台规模上产品化，并与ADK（代码优先的开发工具包）和Agent Studio（可视化工具）捆绑。如果你在Google Cloud内部构建，你不再需要从头设计会话日志或记忆存储。你将ADK智能体连接到Memory Bank和Sessions，部署到Agent Runtime上，持久性问题就解决了。
Notice how much this looks like the pattern Anthropic and Cursor describe, just unbundled into named services with SLAs. Three years ago you’d have built all of this yourself. Now you pick which version of “decoupled brain, hands, and session” you want to rent.注意这与Anthropic和Cursor描述的模式有多么相似，只是解耦成具有SLA的命名服务。三年前你会自己构建所有这些。现在你选择你想要租用的“解耦的大脑、手和会话”的哪个版本。
Five patterns for long-running agents in production生产环境中长期运行智能体的五种模式
Shubham Saboo and I wrote up five design patterns we’ve seen separate working long-running agents from demos. They aren’t Google-specific, but they map cleanly onto the primitives Agent Runtime now exposes, so it’s worth walking through them here in shortened form.Shubham Saboo和我撰写了五种设计模式，我们观察到这些模式将可工作的长期运行智能体与演示区分开来。它们不是Google特有的，但清晰地映射到Agent Runtime现在公开的原语上，因此值得在此以缩短形式进行介绍。
Checkpoint-and-resume. The most common multiday failure is context loss. An agent processes 200 documents over four hours, hits an error on document 201, and without a checkpoint you start from scratch. Treat the agent like a long-running server process: write intermediate state to disk, checkpoint every N units of work, recover from failures. The Agent Runtime sandbox gives you a persistent filesystem, but choosing the right checkpoint granularity (not every step, not only the end) is on you.检查点与恢复。最常见的多天故障是上下文丢失。一个智能体在四小时内处理200个文档，在第201个文档上遇到错误，如果没有检查点，你从头开始。将智能体视为长期运行的服务器进程：将中间状态写入磁盘，每N个工作单元设置检查点，从故障中恢复。Agent Runtime沙盒为你提供了一个持久化文件系统，但选择正确的检查点粒度（不是每一步，也不是仅最后）取决于你。
Delegated approval (human-in-the-loop). Most “human-in-the-loop” implementations are: serialize state to JSON, fire a webhook, hope someone responds. The state goes stale, the notification gets buried, the agent re-deserializes into a slightly different world. Long-running runtimes let the agent pause in place with full execution state intact: reasoning chain, working memory, tool history, pending action. Hours of human time pass, the agent consumes zero compute, and it resumes with subsecond latency. Mission Control is Google’s inbox for this. The pattern works regardless of vendor.委托审批（人在回路中）。大多数“人在回路中”的实现是：将状态序列化为JSON，触发webhook，希望有人响应。状态变得过时，通知被埋没，智能体反序列化到一个略有不同的世界。长期运行运行时允许智能体在原地暂停，保持完整的执行状态：推理链、工作记忆、工具历史、待处理操作。数小时的人类时间过去，智能体消耗零计算，并以亚秒级延迟恢复。Mission Control是Google为此提供的收件箱。这种模式无论供应商如何都有效。
Memory-layered context. A seven-day agent needs more than session state. Memory Bank handles long-term curated memory, Memory Profiles add low-latency lookups, and the failure mode you’ll hit in production is memory drift: The agent learns a procedural shortcut from a few atypical interactions and starts applying it broadly. Govern memory like you govern microservices. Agent Identity controls who can read and write which banks. Agent Registry tracks which version of which agent is running. Agent Gateway enforces policy on the wire. The auditing question stops being “What are my agents doing?” and becomes “What are my agents remembering, and how is that changing their behavior?”记忆分层上下文。一个运行七天的智能体需要的不仅仅是会话状态。Memory Bank处理长期策划的记忆，Memory Profiles添加低延迟查找，你在生产环境中会遇到的失败模式是记忆漂移：智能体从一些非典型交互中学习到程序性捷径，并开始广泛应用它。像治理微服务一样治理记忆。Agent Identity控制谁可以读写哪些银行。Agent Registry跟踪哪个版本的哪个智能体在运行。Agent Gateway在线上强制执行策略。审计问题不再是“我的智能体在做什么？”而是“我的智能体在记住什么，这如何改变它们的行为？”
Ambient processing. Not every long-running agent talks to a human. Some sit on a Pub/Sub stream or a BigQuery table and act on events as they arrive: content moderation, anomaly detection, inbox triage. The architectural decision worth making early is to not hardcode policy into the agent. Define it in the Gateway and the fleet picks up policy changes without redeploys. Ambient agents run unsupervised for long stretches, and the only sane way to update a hundred of them is to update the policy layer once.后台处理。并非每个长期运行智能体都与人类对话。有些坐在Pub/Sub流或BigQuery表上，在事件到达时采取行动：内容审核、异常检测、收件箱分类。值得尽早做出的架构决策是不将策略硬编码到智能体中。在Gateway中定义它，集群无需重新部署即可获取策略更改。后台智能体长时间无监督运行，更新一百个智能体的唯一理智方式是更新一次策略层。
Fleet orchestration. In real systems, you rarely have one agent. A coordinator delegates subtasks to specialists (a Lead Researcher Agent, a Scoring Agent, an Outreach Agent), each running independently for different durations. Each specialist gets its own Identity (so the Outreach Agent can’t read financial data meant for Scoring), its own policy enforcement, its own Registry entry. This is the same coordinator/worker shape distributed systems have used for decades. What’s new is that ADK handles it declaratively with graph-based workflows, and a bad deployment in one specialist doesn’t cascade to the others.集群编排。在真实系统中，你很少只有一个智能体。一个协调者将子任务委派给专家（首席研究员智能体、评分智能体、外联智能体），每个独立运行不同的持续时间。每个专家获得自己的身份（这样外联智能体无法读取为评分智能体准备的财务数据）、自己的策略执行、自己的Registry条目。这与分布式系统几十年来使用的协调者/工作者形状相同。新的是ADK通过基于图的工作流声明式地处理它，并且一个专家中的糟糕部署不会级联到其他专家。
The patterns compose. A compliance system might use checkpointing for document processing, delegated approval for review gates, memory layering for cross-session knowledge, and fleet orchestration to coordinate the specialists. The opening question is always the same: What’s the longest uninterrupted unit of work your agent needs to perform? Minutes, and you don’t need long-running agents. Hours or days, and these patterns are where to start. The full write-up with code samples covers each pattern in depth.这些模式可以组合。一个合规系统可能使用检查点进行文档处理，使用委托审批进行审查门控，使用记忆分层进行跨会话知识，以及使用集群编排来协调专家。起始问题总是相同的：你的智能体需要执行的最长不间断工作单元是什么？几分钟，你不需要长期运行智能体。几小时或几天，这些模式是开始的地方。带有代码示例的完整文章深入介绍了每种模式。
So how do you actually build one today?那么你今天如何实际构建一个？
This is the practical question, and it has a different answer depending on what you’re building.这是一个实际问题，根据你构建的内容有不同的答案。
You’re a developer who wants long-running coding work on your own repo. Just use Claude Code (or Antigravity, Cursor, or Codex). The harness is already there. Treat your AGENTS.md like a pilot’s checklist: short, every line earned by a real failure. Add hooks for typecheck and lint that surface failures back to the agent. Write a plan file before the agent starts. Use the Ralph loop when the agent claims it’s done and you don’t believe it. For multihour or overnight jobs, run in a worktree so a closed laptop doesn’t kill the run, and have it commit progress every meaningful unit of work. This is the path most people should take, and it’s where the most leverage is right now.你是一个开发者，想要在自己的仓库上进行长期编码工作。只需使用Claude Code（或Antigravity、Cursor或Codex）。框架已经存在。将你的AGENTS.md视为飞行员的检查清单：简短，每一行都由实际失败赢得。添加类型检查和lint的钩子，将失败反馈给智能体。在智能体开始之前编写一个计划文件。当智能体声称完成而你不相信时，使用Ralph循环。对于多小时或通宵工作，在工作树中运行，这样合上笔记本电脑不会杀死运行，并让它在每个有意义的工作单元提交进度。这是大多数人应该采取的路径，也是目前杠杆作用最大的地方。
You’re building a hosted agent product. Don’t build the runtime. Pick a managed one. The three real options today: Google’s Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, or roll something on top of ADK, the Claude Agent SDK, or Codex SDK and host it yourself. The trade-off is the usual one. Managed gets you the brain/hands/session split, observability, identity, and an audit trail out of the box. Self-hosted gets you control and the ability to use weird models for weird roles (Cursor’s pattern). For most teams, the right starting point is a managed runtime plus your own ADK or SDK code for the actual loop.你正在构建一个托管智能体产品。不要构建运行时。选择一个托管的。今天三个真正的选项：Google的Agent Platform（Agent Engine + Memory Bank + Sessions）、Claude托管智能体，或者在ADK、Claude Agent SDK或Codex SDK之上自行构建并托管。权衡是通常的那个。托管为你提供大脑/手/会话分离、可观察性、身份和开箱即用的审计跟踪。自托管为你提供控制权以及为奇怪角色使用奇怪模型的能力（Cursor的模式）。对于大多数团队，正确的起点是托管运行时加上你自己的ADK或SDK代码用于实际循环。
You’re doing something autonomous and operational (monitoring, research, ops). Memory Bank-style persistence is what you want, and it’s the part that doesn’t exist in Claude Code. ADK + Memory Bank + Cloud Run + Cloud Scheduler is the cleanest stack I’ve seen for “agent runs every N hours, accumulates state, alerts on a threshold.” This is also where Cursor’s planner/worker/judge split starts to matter more than it does for IDE coding, because the work is genuinely parallel and the failure modes are different.你正在做一些自主和操作性的工作（监控、研究、运维）。Memory Bank风格的持久性是你想要的，这是Claude Code中不存在的部分。ADK + Memory Bank + Cloud Run + Cloud Scheduler是我见过的用于“智能体每N小时运行一次，积累状态，在阈值时发出警报”的最干净堆栈。这也是Cursor的规划器/工作者/评判者分离开始比IDE编码更重要的时候，因为工作真正是并行的，失败模式也不同。
A few things matter regardless of which path you take.无论你选择哪条路径，有几件事都很重要。
Write down the done condition before the agent starts. This is the single highest-leverage move for long runs. The Anthropic harness post calls it the feature list; Cursor calls it the planner’s task spec. Either way, it’s an external file with explicit, testable completion criteria, and it exists so the agent can’t quietly redefine done midrun.在智能体开始之前写下完成条件。这是长期运行中单个杠杆作用最高的举措。Anthropic框架文章称之为功能列表；Cursor称之为规划器的任务规范。无论哪种方式，它都是一个外部文件，包含显式、可测试的完成标准，它的存在是为了防止智能体在运行中悄悄重新定义完成。
Separate the evaluator from the generator. Self-grading is the failure mode. A planner/worker/judge pipeline, or a generator/evaluator pair, is a real architectural pattern, not a stylistic preference. Even if it’s the same model in different roles with different prompts.将评估器与生成器分离。自我评分是失败模式。规划器/工作者/评判者管道，或生成器/评估器对，是一个真正的架构模式，而不是风格偏好。即使它是同一个模型在不同角色中使用不同提示。
Invest in the session log, not just the prompt. The append-only event log is what makes the agent recoverable, debuggable, and auditable. If you can’t reconstruct what the agent did in the last 24 hours from durable storage, what you have is a long-running shell script that happens to call an LLM, not a long-running agent.投资于会话日志，而不仅仅是提示。仅追加的事件日志是使智能体可恢复、可调试和可审计的关键。如果你无法从持久存储中重建智能体在过去24小时内做了什么，那么你拥有的只是一个碰巧调用LLM的长期运行shell脚本，而不是一个长期运行智能体。
Treat compaction and context resets as first class. Anthropic is explicit that summarization-as-compaction wasn’t enough for very long jobs; they had to do full context resets where the harness tears the session down and rebuilds it from a structured handoff file. It is essentially how humans onboard a new engineer.将压缩和上下文重置视为一等公民。Anthropic明确指出，对于非常长的任务，摘要作为压缩是不够的；他们必须进行完整的上下文重置，其中框架拆除会话并从结构化交接文件重建。这基本上是人类如何入职新工程师的方式。
There are some real limitations right now目前存在一些真正的限制
A few things are still genuinely unsolved.有几件事仍然真正未解决。
Cost. A 24-hour run with a frontier model and a few tools is not cheap. Without budgets, circuit breakers, and a hard cap on tool spend, an agent can quietly burn through a week’s API budget in an afternoon. This is solvable, but it’s an explicit step you have to take.成本。使用前沿模型和一些工具运行24小时并不便宜。没有预算、断路器和工具支出的硬上限，一个智能体可以在一个下午悄悄烧掉一周的API预算。这是可解决的，但这是一个你必须采取的明确步骤。
Security. A long-running agent with API keys, cloud access, and the ability to run shell commands has a much larger attack surface than a chat session. The brain/hands separation pattern matters here too: Credentials should be unreachable from the sandbox where model-generated code runs, which is one of the benefits Anthropic calls out for Managed Agents.安全。一个具有API密钥、云访问权限和运行shell命令能力的长期运行智能体比聊天会话具有更大的攻击面。大脑/手分离模式在这里也很重要：凭证应该无法从模型生成代码运行的沙盒中访问，这是Anthropic为托管智能体指出的好处之一。
Alignment drift. Over many context windows, agents drift. The original goal gets summarized, then resummarized, then loses fidelity. This is the part hooks and judges exist to defend against. It is also the most common reason “the agent went off and did something I didn’t ask for.”对齐漂移。在多个上下文窗口中，智能体会漂移。原始目标被总结，然后再次总结，然后失去保真度。这是钩子和评判者存在以防御的部分。这也是“智能体偏离并做了我没有要求的事情”的最常见原因。
Verification. Auditing 24 hours of autonomous activity is a real human-time problem. Observability and structured artifacts (PRs, commits, briefings, test runs) are how you make this tractable. Without them, you’re scrolling logs and you’ll miss what matters.验证。审计24小时的自主活动是一个真正的人类时间问题。可观察性和结构化工件（PR、提交、简报、测试运行）是你使其可处理的方式。没有它们，你就在滚动日志，你会错过重要的东西。
The human role. This is the one I keep coming back to. Defining work crisply enough that an agent can run for a day on it is harder than doing the work yourself. The skill that’s appreciating in value isn’t writing code. It’s writing specs that survive contact with an autonomous executor.人类角色。这是我不断回到的一点。足够清晰地定义工作以使智能体可以运行一天，比自己做工作更难。正在增值的技能不是编写代码。而是编写能够经受自主执行者接触的规范。
Where this is going未来的方向
Google, Anthropic, and Cursor have converged on roughly the same shape. Separate the model loop from the execution sandbox from the durable session log. Split planning from generation from evaluation. Bake in compaction, hooks, and context resets. Expose memory as a managed service that any agent invocation can query.Google、Anthropic和Cursor已经收敛到大致相同的形状。将模型循环与执行沙盒与持久会话日志分离。将规划与生成与评估分离。内置压缩、钩子和上下文重置。将记忆作为任何智能体调用都可以查询的托管服务公开。
Surface area is what differs. Google’s Agent Platform is the enterprise-stack version, with the identity and audit trail story baked in. The patterns underneath are the same. Claude Managed Agents is “Anthropic’s harness, hosted.” Cursor’s background agents are “long-running coding, pulled out of the IDE and into the cloud.”不同之处在于表面区域。Google的Agent Platform是企业堆栈版本，内置了身份和审计跟踪故事。底层的模式是相同的。Claude托管智能体是“Anthropic的框架，托管”。Cursor的后台智能体是“长期运行编码，从IDE中拉出并放入云中”。
The harder problems for the next year aren’t in any of those layers individually. They’re in the coordination above them. Many long-running agents on a shared codebase. Agents that read their own traces and patch their own harnesses. Harnesses that assemble tools and context just in time for a task instead of being preconfigured at startup. That’s where the agent stops looking like a smarter chat window and starts looking like a colleague who’s been on the project longer than you have.未来一年更难的问题不在这些层中的任何一个单独层中。它们在于它们之上的协调。共享代码库上的多个长期运行智能体。读取自己跟踪并修补自己框架的智能体。为任务即时组装工具和上下文而不是在启动时预配置的框架。那时智能体不再看起来像一个更聪明的聊天窗口，而开始看起来像一个比你参与项目时间更长的同事。
The model is still load-bearing. But the gap between a chat window and an agent you can leave running overnight is mostly in the state, sessions, and structured handoffs wrapped around it. That’s where I’d spend my learning time right now.模型仍然承担着负载。但聊天窗口和你可以让其运行过夜的智能体之间的差距主要在于围绕它的状态、会话和结构化交接。那是我现在会花学习时间的地方。
