Vercel推出durable-harness：让AI Agent持久运行数月的工程方案

AI 编程 Agent 的落地一直卡在一个尴尬的环节：模型能力已经不弱，但任务一长就崩。网络抖动、进程重启、上下文超时，任何一个环节出错，辛苦跑了几十分钟的 Agent 就前功尽弃。Vercel 最新发布的 durable-harness，瞄准的正是这个工程痛点。

durable-harness 解决了什么问题

根据 Vercel 官方推文的描述，durable-harness 的核心能力是让 Agent 在失败后自动恢复工作，并且可以持续运行"数小时、数天甚至数月"。这个表述背后对应的是 AI Agent 领域一个长期被低估的基础设施问题：持久性（durability）。

传统做法下，Agent 的执行状态绑定在单次进程生命周期内。一旦进程崩溃或部署更新，正在进行的任务就会丢失。durable-harness 的思路是把执行状态从进程里剥离出来，交由底层运行时管理，从而在故障发生后能够从断点继续，而不是从头再来。

推文中没有披露具体的技术实现细节，例如状态如何持久化、恢复粒度是步骤级还是工具调用级。但"run for hours, days, or months"这一表述暗示其设计目标已经超出了单次对话的范畴，指向长时间运行的自主 Agent 场景。

持久性执行（Durable Execution） 是一个源自工作流引擎领域的工程模式，其代表实现包括 Temporal、Azure Durable Functions、Restate 等。它的核心思想是：把业务逻辑的执行状态（当前进行到哪一步、中间结果是什么）以可重放的方式记录下来，由运行时负责在崩溃后恢复。实现上通常依赖事件溯源（event sourcing）——每一步操作先写入持久日志，恢复时重放日志重建内存状态；配合确定性重放约束，即业务代码不能依赖随机数、系统时间等非确定因素，否则重放会得到不同结果。这一模式对 AI Agent 尤其契合，因为 Agent 的一次任务本身就是一串有依赖关系的工具调用序列，天然适合按步骤检查点化。

支持的 Harness 生态

durable-harness 宣称兼容多种主流编码 Agent 运行时，包括 Pi、OpenCode、Codex、Claude Code、eve、fx，以及用户自建的 harness。

这份名单值得注意的地方在于它的开放性。Codex（OpenAI）和 Claude Code（Anthropic）分属不同厂商，OpenCode 则是社区驱动的开源项目。Vercel 将它们统一纳入同一个持久化层，意味着 durable-harness 定位的不是某个特定 Agent 的配套工具，而是想做成一层通用的执行基础设施。

对开发者而言，这降低了迁移成本：已有的 Agent 工作流不必推倒重来，只需接入持久化层就能获得故障恢复能力。不过，不同 harness 的 API 抽象和状态模型差异不小，实际兼容深度还需要验证。

Harness 一词在 Agent 语境下指包裹大模型的执行外壳，负责提示词组装、工具调用解析、循环控制、上下文裁剪等。它与模型本身是解耦的：同一个 Claude 或 GPT 模型，可以被 Claude Code、OpenCode 等不同 harness 驱动出不同行为。正因为 harness 掌握着 Agent 的完整控制流，持久化层要接管故障恢复，就必须嵌入到 harness 的循环边界上，在每轮模型调用和工具执行前后打检查点。这也是 durable-harness 必须逐一适配多个 harness 的原因——各家的状态模型和循环结构不同，无法靠统一接口一劳永逸。

为什么持久性对 AI 编程 Agent 很关键

编码 Agent 的任务天然是长链条的。一次重构可能涉及几十个文件的读写、多轮测试运行和依赖安装，中间任何一步失败都会导致整个任务回退。在缺乏持久化的环境里，开发者只能反复重启任务，既浪费 token 也浪费时间。

更现实的场景是异步任务。如果 Agent 需要运行数小时甚至数天（例如持续监控代码库、批量迁移、长时间的后台任务），要求用户保持连接或进程常驻是不现实的。持久化执行让"提交任务后离开"成为可能，这是 Agent 从演示走向生产的关键一步。

Vercel 作为部署平台切入这一层，逻辑上也说得通：它本身提供函数计算和运行时环境，把持久化能力打包成 harness 层，可以直接承接平台上运行的 Agent 负载。

Agent 的上下文窗口与任务时长之间存在结构性矛盾。模型单次可处理的上下文有限，长任务必须依靠压缩、摘要或外部记忆来跨越多个上下文窗口。而进程重启会让这些内存态的上下文管理策略全部失效。持久化执行在某种意义上提供了"外置的连续性"：不仅恢复任务进度，还可能恢复关键的中间状态（如已修改的文件清单、已通过的测试结果），从而避免 Agent 在恢复后重复探索、重复消耗 token。这也解释了为什么"运行数月"不只是可靠性指标，同时是成本指标。

当前信息的局限

提一嘴，目前公开的信息仅有 Vercel 的一条发布推文。关于 durable-harness 的定价、技术文档、状态序列化机制、与各 harness 的集成方式、以及"months"级运行在资源消耗上的实际表现，均未披露。推文中附带的链接指向官方页面，建议有实际需求的团队直接查阅原始文档并做小规模验证。

对于正在构建长时运行 Agent 的团队，durable-harness 提供了一个值得关注的选项，尤其适合已经部署在 Vercel 上的项目。但"自动恢复"的实际可靠性，通常要在真实故障场景下才能检验。

小结

durable-harness 切中的是 AI Agent 从短任务演示走向长时生产运行的工程缺口。多 harness 兼容和故障自动恢复是它的两个核心卖点，落地效果则有待技术文档和实际使用反馈来验证。