> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 长时运行智能体的5种设计模式
- URL: https://www.hubwiz.com/blog/5-design-patterns-for-long-running-agents/
- Published: 2026-05-03T12:14:10.000Z
- Updated: 2026-05-03T12:14:10.000Z
- Description: 一个长时间运行的 AI 代理可以在数小时、数天甚至数周内持续取得进展。它可以跨越多个上下文窗口和沙盒环境，从故障中恢复，留下结构化的工件，并从中断的地方继续。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

两年来，"AI 代理"的主导形象一直是一个里面装着聪明循环的聊天窗口。你输入目标，代理调用一些工具，你看着 token 流式输出，当工作耗尽耐心或上下文窗口填满时你停止观看。这个范式带我们走了很远，但它有天花板。模型会遗忘。它在任务还没完成时就宣称"任务完成"。它会重新引入九个回合前修复过的 bug。整个结构围绕单次会话而建。

![长时间运行的 AI 代理](https://www.hubwiz.com/blog/content/images/2026/05/long-running-agents.jpg)

长时间运行的代理是下一步。这个想法很简单：一个代理在许多会话和许多沙盒环境中，可能在许多天或许多周内，持续朝着目标前进，同时保持工作空间足够整洁，让下一个会话能从上一个会话停止的地方接手。工程上更难。你必须以一种不只是粉饰裂缝的方式解决持久性、恢复和验证问题。你必须构建一个存在于模型上下文窗口之外的状态层，你必须设计会话间的交接，这样代理在醒来发现自己处于不同沙盒、不同上下文窗口时不会发疯。

这篇文章是我尝试梳理发生了什么变化、谁在推动这些变化，以及工程师今天如何在不从零开始编写整个系统的情况下使用长时间运行的代理。

## 1、"长时间运行"到底意味着什么

"长时间运行"在实践中至少被用来表示三种不同的事情，区分它们是有帮助的。

**长时域推理。** 代理必须在许多相互依赖的步骤上规划和执行。这主要是一个模型质量的问题：连贯性、规划能力、从十步之前的错误转弯中恢复的能力。METR 一直在用他们的*时间范围*指标追踪这一点，该指标估算前沿模型能以 50% 的可靠性完成多长时间的任务。核心发现是该指标自 2019 年以来[大约每七个月翻一番](https://metr.org/time-horizons/?ref=hubwiz.com)，他们今年早些时候的 [TH1.1 更新](https://metr.org/blog/2026-1-29-time-horizon-1-1/?ref=hubwiz.com)将评估集中 8 小时以上任务的数量翻了一倍。**如果这个曲线保持下去，前沿代理将在 2028 年达到天级任务完成能力，2034 年达到年级任务完成能力。**

**长时间运行执行。** 代理的*进程*运行数小时或数天。可能是一个编码任务，可能是一个研究扫描，可能是一个 7×24 小时的监控服务。模型可能在运行过程中被调用数千次。这主要是一个\*框架（harness）\*的问题，也是本文主要讨论的内容。

**持久化代理。** 代理拥有超越任何单一任务的持久身份。它积累记忆、学习用户偏好，并且始终可用。这是 [Memory Bank](https://docs.cloud.google.com/agent-builder/agent-engine/memory-bank/overview?ref=hubwiz.com) 风格的长时间运行。

在实践中，这三者会模糊在一起。一个真正的生产级代理在长时间运行的执行中*利用*持久化代理进行*长时域推理*。但每种情况的工程问题不同，解决它们的产品也不同。

## 2、为什么这很重要

我相信这项工作现在很重要的原因有两个。

第一个是在经济上可以委托的事情发生了质变。一个运行十分钟的代理可以回答问题、总结文档、修复一个小 bug。一个运行十小时的代理可以负责整个功能、完成搁置了六个季度的迁移，或者做以前需要初级分析师做的通宵研究扫描。Anthropic 的 [Claude Sonnet 公告](https://www.anthropic.com/news/claude-sonnet-4-5?ref=hubwiz.com)之一在去年秋天给出了具体数字：内部测试中 30 多小时的自主编码，包括[一次运行](https://venturebeat.com/ai/anthropics-new-claude-can-code-for-30-hours-think-of-it-as-your-ai-coworker?ref=hubwiz.com)产生了一个 11,000 行的 Slack 风格应用。**这已经越过了"我是否应该委托这个？"的答案不再显而易见的阈值。**

第二个是持久性改变了代理*是什么*。一个无状态的代理回答你的问题然后消失。一个长时间运行的代理积累上下文：哪个竞争对手上周做了什么变动，哪个测试在周二连续失败了两次，你说的"那个仪表盘"通常指什么。Anthropic 的 [Project Vend](https://www.anthropic.com/research/project-vend-1?ref=hubwiz.com) 是这方面最早的公开展示。他们让一个 Claude 实例运行了一个真正的办公室自动售货业务一个月，管理库存、设定价格、与供应商沟通。它以有价值的方式失败了，而[第二阶段](https://www.anthropic.com/research/project-vend-2?ref=hubwiz.com)运行得好得多，但重点不是盈利能力。重点是观察当代理必须在数周而非数个回合中维持身份时，会出现什么样的奇怪的连贯性问题。

这些正是每个构建生产级代理的团队现在都会遇到的问题。

## 3、每个长时间运行代理都会遇到的三面墙

三面墙在我今年读过的几乎所有文章中都出现了。

**有限的上下文。** 即使是 1M token 的窗口也会被填满。而且[上下文腐烂](https://addyosmani.com/blog/agent-harness-engineering/?ref=hubwiz.com)——模型性能随窗口变满而持续退化——在硬性限制之前很久就会发生。一个 24 小时的运行不可能塞进该领域路线图上的任何上下文窗口。必须有某种妥协。

**没有持久化状态。** 新的会话从空白开始。Anthropic 在其[科学计算文章](https://www.anthropic.com/research/long-running-Claude?ref=hubwiz.com)中的表述是我见过的最清晰的版本：*"想象一个软件项目由轮班的工程师组成，每个新工程师到来时对上一个班次发生的事情毫无记忆。"* 没有明确的持久化方案，每次换班都是一场生产力灾难。

**没有自我验证。** 模型在给自己的工作打分时可靠地偏向积极。被问"你完成了吗？"它们回答"是"的频率比应该的高。没有独立的信号表明工作达到了标准，你就会得到一个以 30% 的完成度带着十足信心交付的代理。

长时间运行代理的设计主要就是这三个问题的答案。**各大实验室已经趋同于相似形状的答案，但表层差异很大。**

## 4、Ralph 循环

Ralph循环是长时间运行代理的一个较简单的实践者版本。

**Ralph 循环**（有时被称为 Ralph Wiggum 技术）是长时间运行代理的一种"较简单"的实践者版本，由 [Geoffrey Huntley](https://ghuntley.com/ralph/?ref=hubwiz.com) 和 [Ryan Carson](https://github.com/snarktank/ralph?ref=hubwiz.com) 推广。参考实现[字面意思就是一个 bash 脚本](https://ghuntley.com/ralph/?ref=hubwiz.com)，它循环执行：

1. 从列表（`prd.json` 或等效文件）中选取下一个未完成的任务。
2. 构建一个包含任务、相关上下文和任何持久化笔记的提示。
3. 调用代理。
4. 运行测试或其他检查。
5. 将发生的事情追加到 `progress.txt`。
6. 更新任务列表（完成、失败、阻塞）。
7. 回到步骤 1。

它有效的原因与下面任何框架有效的原因相同：状态存在于代理的上下文之外。`prd.json` 是计划，`progress.txt` 是实验笔记，`AGENTS.md` 是滚动更新的规则手册。**代理本身是健忘的，但文件系统不是。** 每次迭代从全新状态开始，从磁盘读取足够的状态来继续。Carson 的 [Compound Product](https://github.com/snarktank/compound-product?ref=hubwiz.com) 通过链接多个循环（一个读取每日报告的分析循环、一个发出 PRD 的规划循环、一个编写代码的执行循环）扩展了这个想法，这大致是 Anthropic 独立得出的规划器-生成器-评估器三联体的开源版本。

我在[《自我改进的代理》](https://addyosmani.com/blog/self-improving-agents/?ref=hubwiz.com)中更深入地讨论了所有这些：任务列表结构、进度文件、QA 关卡、监控、你实际会遇到的各种失败模式。简短的版本是你可以用一个 bash 脚本和一个 JSON 文件在一个晚上构建一个可工作的长时间运行代理。Google 和 Anthropic 产品化的大部分工作是让这个模式可恢复、安全且在大规模下可观测。

下面各大实验室的故事是支付这种生产就绪性的不同方式。

## 5、Anthropic：框架，然后是大脑/手/会话分离

Anthropic 在工程方面是最公开的。有两篇文章值得从头到尾阅读。

第一篇是[《长时间运行代理的有效框架》](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents?ref=hubwiz.com)，它提出了一个用于自主全栈开发的双代理框架。一个**初始化代理**在项目开始时运行一次，设置环境，将提示展开为结构化的 `feature-list.json`，并编写一个未来会话启动时将运行的 `init.sh`。然后**编码代理**被反复唤醒，每次会话被要求在一个功能上取得增量进展、运行测试、留下 `claude-progress.txt` 笔记并提交。一个测试棘轮（*"删除或编辑测试是不可接受的，因为这可能导致遗漏或有缺陷的功能"*）放在提示中，以阻止代理删除失败的测试来"让它们通过"这种非常常见的失败。[InfoQ 的报道](https://www.infoq.com/news/2026/04/anthropic-three-agent-harness-ai/?ref=hubwiz.com)将其扩展为规划器、生成器和评估器三联体，基于同样的逻辑：将生成与评估分离很重要，因为模型给自己的工作打分过于宽松。

第二篇是[《扩展托管代理：将大脑从手中分离》](https://www.anthropic.com/engineering/managed-agents?ref=hubwiz.com)，这是 [Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview?ref=hubwiz.com)（Anthropic 的托管运行时，于 4 月初发布）背后的架构文章。论点是代理有三个应该可以独立替换的组件。大脑（Brain）是模型和调用它的框架循环。手（Hands）是工具实际运行的沙盒化、临时执行环境。会话（Session）是每个思考、工具调用和观察的仅追加事件日志。

这听起来很抽象，但实际上不是。Anthropic 的表述：*"框架中的每个组件都编码了一个关于模型自身无法做什么的假设。"* 当你将它们耦合在一起时，一个过时的假设（例如，模型以前需要显式的规划器，现在可以原生规划了）意味着整个系统必须同时改变。当你将它们解耦时，框架变成无状态的，沙盒变成*牲畜而非宠物*，大脑崩溃不会丢失运行。一个新容器调用 `wake(sessionId)` 并从日志中重构状态。他们报告称[首 token 时间在 p50 降低了约 60%，p95 降低了 90% 以上](https://www.anthropic.com/engineering/managed-agents?ref=hubwiz.com)，仅仅是因为能够在沙盒就绪之前开始推理。

**会话作为事件日志这个想法是大多数团队最低估的部分。** 它是让长时间运行代理可恢复的关键。没有它，容器故障就是会话故障，你只能调试一个过时的快照。有了它，代理的记忆是一个可查询的工件，存在于当前运行的进程之外。

对于科学计算领域，Anthropic 的[长时间运行 Claude 文章](https://www.anthropic.com/research/long-running-Claude?ref=hubwiz.com)将所有这些简化为一个更简单的技术栈：`CLAUDE.md` 作为代理在学习过程中编辑的动态计划，`CHANGELOG.md` 作为可移植的实验笔记，`tmux` 加 `SLURM` 加 `git` 作为执行和协调层，以及 **Ralph 循环**，一个 `for` 循环，在代理声称完成时将其踢回上下文，问它*真的*完成了没有。他们的旗舰案例研究是 Claude Opus 4.6 在几天内构建的玻尔兹曼求解器，与参考的 CLASS 实现达到了亚百分比的一致性。数月到数年的研究人员时间，被压缩了。

三篇文章中出现了相同的模式：明确的计划文件、明确的进度文件、会话间的结构化交接、将生成与评估分离，以及一个拒绝让代理提前停止的循环。

## 6、Cursor：规划器、工作者、裁判

[Cursor 的"扩展长时间运行自主编码"](https://cursor.com/blog/scaling-agents?ref=hubwiz.com)是今年另一篇必读文章。他们遇到了 Anthropic 大多绕过了的墙壁。

他们的第一次尝试是扁平的协调模型：平等地位的代理通过锁写入共享文件。这变成了瓶颈，并让代理变得风险厌恶，反复修改而不是提交。第二次尝试用乐观并发控制替换了锁，消除了瓶颈但没有解决协调问题。第三个设计是现在生产中运行的，也是他们描述为解决了大部分问题的：

- **规划器（Planners）** 持续探索代码库并发出任务。它们可以递归地生成子规划器。
- **工作者（Workers）** 是专注的执行者。它们不相互协调，也不关心大局。
- **裁判（Judges）** 决定迭代何时完成以及何时重启。

文章中有两件事很突出。第一：*"系统行为的惊人数量归结为我们如何给代理写提示"*，比框架或模型更重要。第二：不同的模型适配不同的角色。他们报告的发现是，GPT 模型在*扩展自主工作*方面比 Opus 更好，具体是因为 Opus 倾向于提前停止和走捷径。**同样的任务，不同的角色，不同的模型。** 匹配正在成为设计界面的一部分。

这与 [Composer 2](https://cursor.com/blog/composer?ref=hubwiz.com)（他们在 [Cursor 3](https://cursor.com/changelog/2-0?ref=hubwiz.com) 中发布的专有前沿编码模型）及其**后台云代理**搭配：在 Anysphere 的云基础设施上运行的长时间运行任务，而不是你的笔记本电脑上。八小时的重构和全代码库的迁移在你合上盖子后仍然存活。你可以在本地开始一个任务，当意识到需要 30 分钟时点击*在云中运行*，之后从手机重新连接。每个代理在隔离的 git worktree 中运行，通过 PR 合并回去。本地和远程之间的交接是大多数团队尚未解决的部分，Cursor 的押注是它必须成为独立的产品界面。

最终形状接近 Anthropic 的：角色被拆分，会话是持久的，裁判坐在工作者旁边，长任务在带有 git 作为协调基底的云沙盒中运行。

## 7、Google：Agent Platform 上的长时间运行代理

Google 两周前在 [Cloud Next '26](https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform?ref=hubwiz.com) 上的公告将 Vertex AI 整合到了 **Gemini Enterprise Agent Platform** 中，并将长时间运行代理变成了一个命名产品，带有命名的 SLA。

对本文来说重要的部分：

- **Agent Runtime** 支持\*"自主运行数天"\*的代理，具有亚秒冷启动和按需沙盒配置。发布文章的示例用例是一个需要一周才能完成销售序列的销售潜在客户开发，这大致是正确的形状。
- **Agent Sessions** 持久化对话和事件历史。你可以将它们绑定到映射到你自己的 CRM 或数据库记录的自定义会话 ID，这样代理的状态就存在于业务状态旁边，而不是在一个单独的 AI 孤岛中。
- [**Agent Memory Bank**](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank?ref=hubwiz.com) 是持久的长期记忆层，在 Next '26 时已正式可用。它从会话中策划记忆，将其限定在用户身份范围内，并暴露搜索 API，以便下一次代理调用可以拉取相关内容。Payhawk 报告称，通过 Memory Bank 支持的代理自动提交费用，将提交时间减少了 50% 以上。
- **Agent Sandbox** 处理加固的代码执行。
- **Agent-to-Agent 编排**、**Agent Registry**、**Agent Identity**、**Agent Gateway**、**Agent Observability** 和 **Agent Simulation** 基本上覆盖了你在生产级代理群中需要手动构建的每个运维关注点，包括企业实际需要交付的加密身份和审计日志故事。

在架构上，这与 Anthropic 描述的大脑/手/会话分离相同，只是在平台规模上产品化了，并与 [ADK](https://google.github.io/adk-docs/?ref=hubwiz.com)（代码优先的开发工具包）和 Agent Studio（可视化版本）捆绑在一起。如果你在 Google Cloud 内部构建，你不再需要从头设计会话日志或记忆存储。你将 ADK 代理接入 Memory Bank 和 Sessions，部署到 Agent Runtime 上，持久化的问题就解决了。

注意这看起来多么像 Anthropic 和 Cursor 描述的模式，只是解绑成了带有 SLA 的命名服务。三年前你需要自己构建所有这些。**现在你选择要租用哪个版本的"解耦的大脑、手和会话"。**

## 8、生产中长时间运行代理的五种模式

Shubham Saboo 和我[总结了](https://x.com/GoogleCloudTech/status/2046989964077146490?ref=hubwiz.com)我们观察到的将可工作的长时间运行代理与演示区分开来的五种设计模式。它们不是 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 用基于图的工作流声明式地处理它，一个专家中的不良部署不会级联到其他专家。

这些模式可以组合。一个合规系统可能使用检查点处理文档处理，使用委托审批处理审核关卡，使用记忆分层处理跨会话知识，使用集群编排协调各专家。开篇问题总是一样的：*你的代理需要执行的最长不间断工作单元是什么？* 几分钟，你不需要长时间运行代理。几小时或几天，这些模式就是你的起点。[带有代码示例的完整文章](https://x.com/GoogleCloudTech/status/2046989964077146490?ref=hubwiz.com)深入讲解了每种模式。

## 9、那么你今天到底怎么构建一个？

这是一个实际问题，答案取决于你在构建什么。

**你是一个开发者，想要在自己的仓库上运行长时间编码工作。** 直接使用 [Claude Code](https://addyosmani.com/blog/agent-harness-engineering/?ref=hubwiz.com)（或 Antigravity、Cursor 或 Codex）。框架已经在那里了。把你的 `AGENTS.md` 当作飞行员的检查清单：简短，每一行都由真实失败换来。添加类型检查和 lint 的钩子，将失败反馈给代理。在代理开始之前写一个计划文件。当代理声称完成了而你不信时，使用 [Ralph 循环](https://addyosmani.com/blog/self-improving-agents/?ref=hubwiz.com)。对于多小时或通宵任务，在 worktree 中运行，这样合上笔记本电脑不会终止运行，并让它在每个有意义的工作单元提交进展。**这是大多数人应该走的路径，也是目前杠杆效应最大的地方。**

**你在构建一个托管的代理产品。** 不要自己构建运行时。选择一个托管的。今天真正的三个选择：[Google 的 Agent Platform](https://cloud.google.com/products/gemini-enterprise-agent-platform?ref=hubwiz.com)（Agent Engine + Memory Bank + Sessions）、[Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/overview?ref=hubwiz.com)，或者基于 [ADK](https://google.github.io/adk-docs/?ref=hubwiz.com)、[Claude Agent SDK](https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk?ref=hubwiz.com) 或 [Codex SDK](https://platform.openai.com/docs/codex?ref=hubwiz.com) 搭建并自己托管。权衡是通常的那个。托管的开箱即提供大脑/手/会话分离、可观测性、身份和审计追踪。自托管的给你控制权和为不同角色使用不同模型的能力（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 拉出来放到云端"。

明年的更难问题不在这些层中的任何一个单独层面。而在它们之上的协调。共享代码库上的许多长时间运行代理。读取自己的追踪并修补自己框架的代理。在任务时即时组装工具和上下文而非在启动时预配置的框架。那是代理不再看起来像一个更聪明的聊天窗口，而开始像一个比你更早加入项目的同事的地方。

模型仍然是承重的。但聊天窗口和一个你可以让它通宵运行的代理之间的差距，主要在于包裹在它周围的状态、会话和结构化交接。这是我现在会投入学习时间的地方。

---

原文链接：[Long-running Agents](https://addyosmani.com/blog/long-running-agents/?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处