很多人理解长运行 Agent会先想到一个画面让 Agent 一直跑。跑几个小时、跑一整晚、跑几天。直到任务完成。这个理解太粗。长运行的关键不是“多跑一会儿”。而是任务一旦跨越多个上下文窗口、多个工具调用、多个验证周期系统还能不能保持目标、状态和质量。真正难的是上下文会断。 目标会漂。 成本会爆。如果这三个问题没有设计长运行 Agent 很容易从自动化助手变成自动化事故源。一、长运行不是长上下文长上下文可以缓解一部分问题。但它不等于长运行。长上下文回答的是一次推理能看多少信息长运行回答的是一个目标跨越多轮、多会话、多次失败后系统如何继续这是两个不同问题。一个任务跑得越久越不能只依赖上下文窗口。原因很简单窗口会满、会压缩、会重启、会断线、会换模型。会换执行环境、会遇到工具失败、会需要人工插入决策。所以长运行 Agent 必须有外部状态不是可选项是基本条件。二、问题一context driftContext drift 指的是Agent 运行一段时间后上下文里的信息和真实任务状态开始偏离。常见表现是重复做已经完成的事 忘记早期约束 相信旧工具输出 把中间假设当事实 压缩后丢失关键决策 引用过期文件上下文不是越多越好。越长的任务越需要区分四类信息。事实外部世界当前状态 决策已经做过的选择 进度完成了什么剩下什么 证据为什么认为完成或失败如果这些信息只藏在聊天历史里迟早会丢。更可靠的做法是把它们写到状态文件或数据库。比如progress.md decisions.md open-issues.md verification.md budget.mdAnthropic 在长运行 Agent 经验里强调类似模式用进度文件承接跨会话记忆让新一轮执行能知道之前发生了什么。这不是文档洁癖这是恢复机制。三、问题二goal driftGoal drift 指的是Agent 还在努力但努力方向已经偏离原目标。这比普通失败更危险。因为它看起来很勤奋。比如用户目标是修复支付失败的 regression。Agent 跑着跑着开始顺手重构支付模块 顺手升级依赖 顺手改日志系统 顺手优化 UI 文案每一步看起来都有理由但整体已经偏了。长运行任务必须把 Goal 写成可检查对象。至少包含原始目标 成功标准 明确不做什么 允许修改范围 验证方式 升级人工条件每轮循环都要问当前动作是否仍服务原目标 是否扩大了范围 是否引入新目标 是否需要人类确认这就是 goal check。没有 goal checkAgent 很容易变成“自主发挥”。四、问题三cost driftCost drift 指的是任务还没明显失败但 token、工具调用、时间和外部 API 成本持续上升。常见原因包括反复读取大文件 反复跑完整测试 重复检索相同资料 工具输出直接塞回上下文 多 Agent 互相重复工作 验证失败但没有停止条件成本漂移最麻烦的是它通常不是一个瞬间错误。它是慢慢发生的。所以必须给 loop 设计预算。预算不是只看钱。至少包括最大轮数 最大 token 最大工具调用次数 最大运行时间 最大重试次数 最大外部 API 调用 最大人工等待时间一旦接近预算Agent 不应该继续硬跑。它应该生成状态报告。说明已经做了什么 验证到哪里 剩余问题是什么 为什么需要继续 继续预计成本是多少 是否需要人工决策预算不是限制能力预算是防止循环失控。五、一个可恢复的长运行结构长运行 Agent 不应该从一句 prompt 开始。更稳的结构是五段。5.1. Initializer先初始化任务。读取目标、约束、仓库或资料。生成任务状态。比如goal.md progress.md feature-list.md verification.md budget.mdInitializer 的职责不是完成任务而是把任务变成可执行、可恢复的结构。5.2 Worker LoopWorker 每轮只做有限动作。选择一个子任务 读取必要上下文 调用工具 更新进度 运行验证 记录结果重点是“一次只推进一块”不要让 Agent 同时展开太多战线。5.3 VerifierVerifier 独立检查结果可以是测试可以是 schema可以是 reviewer agent。可以是人工。关键是不要只相信 Worker 自己说完成。5.4. Checkpoint每完成一个阶段保存 checkpoint。Checkpoint 至少包括当前代码或内容状态 已通过验证 未解决问题 可回滚点 下一步建议如果后面走偏可以回到这里。5.5 Recovery失败后按类型处理。工具失败 - retry / fallback 验证失败 - rollback / narrow scope 目标不清 - pause / ask human 预算超限 - report / request approval 状态污染 - reload from checkpoint这才是长运行 Agent 的真实工程不是“跑久一点”。而是“断了还能接错了能回偏了能拉回来”。六、多日任务怎么恢复多日任务最怕新会话不知道旧会话做了什么。所以恢复入口必须非常清楚。一个新会话启动时不应该先读完整聊天记录。应该先读恢复文件。1. goal.md 2. progress.md 3. decisions.md 4. open-issues.md 5. verification.md 6. budget.md然后执行一个恢复检查。当前目标是否仍有效 上次完成到哪里 哪些结论已验证 哪些结论只是猜测 哪些文件或外部状态可能已变化 下一步是否仍然合理只有恢复检查通过才继续执行。否则先修状态不要在错误状态上继续自动化。七、长运行 Agent 的失败模式可以把常见失败分成五类。第一重复。Agent 不知道自己已经做过什么。解决办法是 progress file 和 artifact index。第二扩张。Agent 把任务越做越大。解决办法是 scope boundary 和 goal check。第三污染。错误工具输出、旧假设或无关资料进入上下文。解决办法是 context isolation 和 verification gate。第四沉没成本。Agent 已经跑了很久所以继续跑更久。解决办法是 budget gate 和 escalation。第五不可复盘。最终结果看起来完成但没人知道怎么来的。解决办法是 trace、state files 和 checkpoint。八、实战 Checklist让 Agent 跑长任务前先检查这十五项。1. Goal 是否写入独立文件 2. 成功标准是否可验证 3. 是否明确不做什么 4. 是否有 progress file 5. 是否有 decisions file 6. 是否有 open issues file 7. 是否有 verification file 8. 是否有 budget file 9. 每轮是否只推进有限范围 10. 是否有独立 verifier 11. 是否有 checkpoint 12. 失败是否能分类处理 13. 超预算是否会停止 14. 新会话是否能恢复 15. 人类能否复盘全过程如果这些都没有不要把任务叫“长运行 Agent”。那只是一个跑得比较久的聊天会话。九、最后长运行 Agent 的本质不是更长的上下文而是更强的外部结构。状态文件 目标检查 验证器 预算门 检查点 恢复机制 人工升级Agent 越自治外部结构越重要。因为模型会忘、工具会失败、目标会变化、环境会变化、成本会累计。长运行系统的可靠性来自这些变化被看见、记录、验证和恢复。下一篇我们讲另一个容易被过度神化的主题多 Agent 与 Handoff。Loop 不是越多越好。Agent 也不是越多越强。参考资料Anthropic: Effective Harnesses for Long-Running AgentsAnthropic: Long-running Claude for Scientific ComputingAnthropic: Harness Design for Long-Running Application DevelopmentOpenAI Agents SDK: RunState, sessions and human-in-the-loopanthropics/cwc-long-running-agents参考文献长运行 Agent 的工程问题上下文会断目标会漂成本会爆