本文整理自 Addy Osmani 的文章：Long-Running Agents，结合个人理解做了重写与精简，原文链接附在文末。
过去一年里，“Agent” 这个词的语义已经悄悄变了。从最初聊天窗口里那种几轮就结束的对话，逐渐演变成可以连续跑几个小时、甚至跨天跨周完成一整个功能的"长时运行 Agent"（Long-Running Agents）。
它不再是"模型 + 一个 Prompt"，而是一整套围绕状态、会话、交接搭建起来的系统工程。
本文梳理这套系统的核心思路：长时运行到底意味着什么、它必然会撞上的三堵墙、几家头部厂商各自的解法，以及五种已经在生产环境验证过的模式。
一、什么叫"长时运行"
长时运行不是单纯的"跑得久"，它至少有三个维度：
- 长链路推理（Long-horizon reasoning）：能在一连串相互依赖的步骤里持续规划。研究显示，模型可处理任务的复杂度大约每 7 个月翻一倍。
- 长时执行（Long-running execution）：进程持续数小时甚至数天，期间发生几千次模型调用。
- 持续在场（Persistent agency）：Agent 拥有稳定身份、持续累积记忆，随时可被唤起。
Anthropic 已经展示过 Claude Sonnet 自主编程超过 30 小时的案例——这不再是 demo，而是工程问题。
二、为什么这件事突然重要
两个原因：
第一，经济性临界点已过。 当 Agent 能连续工作 10 小时以上，它就有可能独立完成一个完整功能，而不只是写一个函数。人力对比关系开始变化。
第二，状态会自我累积。 当 Agent 保留住"上周竞品改了什么"“这个仓库的历史决策是怎么演化的"这些上下文，它的连贯性会从"工具"跨到"协作者”。
三、绕不开的三堵墙
任何长时 Agent 在工程化路上都会撞到三堵墙：
墙 1：上下文有限
哪怕是 1M token 的窗口，也会被填满。更糟的是 context rot——在还没撞到上限之前，注意力质量已经先下降。
墙 2：没有持久状态
每次新会话都从空白开始。这就像换班的工程师没有交接文档，只能重新摸一遍代码。
墙 3：自我验证不可靠
模型倾向于"过度报告完成"——它会说"已修复"，但实际上没跑通测试。没有外部验证信号，长时运行就是慢性自杀。
四、几种主流解法
1. Ralph Loop：最朴素的工程派
由 Geoffrey Huntley 与 Ryan Carson 推广的一种 bash 风格做法：
- 用
prd.json维护任务列表 - 用
progress.txt追加写入进度 - 循环调用 Agent，每次注入必要上下文
- 每轮跑校验脚本
- 更新任务状态
核心理念一句话：让状态活在 Agent 上下文之外，用文件系统做持久层。
2. Anthropic：脚手架与"脑/手/会话"分离
Anthropic 的实践有两个关键模式。
脚手架（Harnesses）设计：
- 初始化 Agent 负责环境搭建、规划、生成功能列表
- 编码 Agent 增量推进每个功能
- “测试棘轮（test ratchet）“防止模型为了通过而删测试
- Planner / Generator / Evaluator 解耦
脑 / 手 / 会话三分：
- 脑（Brain）：模型 + 调度循环，可被替换
- 手（Hands）：临时性的沙箱执行环境
- 会话（Session）：只追加（append-only）的事件日志，可恢复、可调试
把会话当成事件日志后，他们 p50 首字延迟改善 60%，p95 改善 90% 以上。
3. Cursor：让模型与角色匹配
Cursor 用的是三层架构：
- Planner：探索代码库、产出任务、必要时派生子 Planner
- Worker：纯执行者，不背协调负担
- Judge：决定是否结束、是否需要重启
一个有意思的发现：不同模型适合不同角色。GPT 在长时间自主任务里更耐久；Opus 倾向于过早收尾。
4. Google：企业级 Agent Platform
Google 把整套基础设施做成产品：
- Agent Runtime：亚秒级冷启、按需沙箱
- Agent Sessions：会话可绑定到自定义 ID
- Memory Bank：长期记忆 + 检索 API
- Agent Identity：加密身份与审计
- Agent Gateway：策略层
五、生产环境的五种模式
- Checkpoint-and-resume：每隔 N 个单位写检查点，挂掉能恢复。
- Delegated approval：暂停等审批时不占用算力——状态完整保留几小时不烧钱。
- Memory-layered context：把记忆当微服务管，谨防 memory drift（记忆漂移）。
- Ambient processing：事件驱动，挂在流/表上，用策略层兜底。
- Fleet orchestration：协调者把任务派给具备独立身份与权限的专家 Agent。
六、根据场景选路径
| 场景 | 推荐方式 | 关键栈 |
|---|---|---|
| 个人开发者 + 本地仓库 | Claude Code / Cursor | AGENTS.md、计划文件、Ralph Loop |
| 托管型 Agent 产品 | 托管 Runtime | Agent Platform 或 Claude Managed Agents + ADK |
| 自主运维型 | 持久记忆 + 调度 | ADK + Memory Bank + Cloud Run + Scheduler |
七、关键工程实践
- 先写"完成条件"再启动 Agent——没有 done-condition 等于没有终点。
- 生成与评估必须解耦，这是架构问题，不是风格问题。
- 会话日志比 Prompt 工程更值得投入。
- 把上下文重置和压缩当一等公民对待，不要假装它不会发生。
八、目前还没解决的问题
- 成本：24 小时跑下来很贵，必须有预算与熔断机制。
- 安全：攻击面变大；脑/手分离能缓解但不能根治。
- 对齐漂移：每轮摘要都会损失一点目标信息。
- 可验证性：审计 24 小时的活动需要结构化产物，否则人根本看不过来。
- 人的角色：“把工作描述清楚到能交给 Agent 自主跑"本身比直接做还难。
九、未来方向
不同厂商的架构正在收敛到一个共同形状：模型循环 + 沙箱 + 会话日志 + 记忆服务。差异主要发生在表层 API 和协调层。
接下来值得关注：
- 多 Agent 协调
- 可自我修补的 Harness
- 即时拼装的工具集（just-in-time tool assembly）
写在最后
引用原文一句很到位的话来收尾：
聊天窗口和"可以让它跑通宵的 Agent"之间的差距，几乎全部在于围绕它构建的状态、会话和结构化交接。
模型的能力边界确实在向上走，但真正决定一个 Agent 能不能"长时间靠谱”，是它周围那一圈不性感的工程基础设施。这正是当下最值得投入精力的方向。
参考资料：