Vercel 开源编程 Agent 会话恢复组件

把 Coding Agent 搬到云端，难点不只是让模型执行命令，还得处理函数超时、进程崩溃之后的续跑。Vercel 开源的 durable-harness，试图给现有 Agent 执行框架加上一层持久化记录，让新进程知道哪些调用已经完成、哪些还需要继续。

它适配 Pi、OpenCode、fx、Claude Code 和 Codex，已有框架无需修改。但「崩溃后能恢复」有明确边界：项目仍处于 0.0.x 实验阶段，没有公开性能基准，Claude Code 和 Codex 还依赖 Vercel Sandbox。

为什么保住工作目录，还不够恢复 Agent

原文指出，Pi、Claude Code 这类执行框架，最初面向本地长期运行的进程，会把会话状态保存在内存里。本地工作目录和历史记录在同一块磁盘上，恢复相对直接；搬到云端后，即便虚拟机挂了持久化磁盘，也不代表系统知道每次调用执行到了哪里。

文件还在，执行进度却可能丢了。

比如一次工具调用已经完成，但函数没来得及记录结果就退出，新进程究竟该重试，还是跳过？持久化工作目录回答不了这个问题。

durable-harness 的做法，是把会话放进 Workflow SDK 的 World。World 把存储、队列和流封装在同一个接口后面，底层使用 Vercel Workflow SDK 的执行机制。

每次模型或工具调用开始前，先记录执行意图；结束后，再记录结果。使用 Vercel Queues 时，每一轮执行由一条队列消息承载。函数中途退出，队列把任务交给新函数，新函数读取日志后继续。

它也会镜像执行框架自己的会话文件，包括 Claude Code 的 transcript、Codex 的 rollout，以及 OpenCode 的 event store。恢复所需的信息因此不只是一份聊天记录。

恢复时，哪些调用可以重跑

durable-harness 的关键，是用日志决定下一步该执行什么。

原文把恢复分成几种情况：

• 已经完成并记下结果的调用，直接读取日志，不再执行。按 Vercel 的说法，已完成的模型调用不会再次消耗 token、重复计费。
• 标记为 replay: 'safe' 的工具允许重试，例如查询类操作。
• 标记为 replay: 'never' 的工具不重复调用，例如退款。遇到结果不确定的情况，系统会告诉模型：这次操作可能已经发生。

第三种最容易被误读。「不再调用」不等于「已经确认成功」。如果外部操作完成了，但结果还没写回日志，系统仍可能不知道最终状态。

因此，标题里的「Crash-Proof」应理解为提供崩溃恢复机制，不能直接等同于所有外部操作都有恰好执行一次的保证。原文也没有交代，面对这种不确定状态，业务系统该怎样核验或补偿。

这些恢复能力均来自 Vercel 的自述。文章没有给出独立故障注入测试，也没有延迟、吞吐量基准。

工作区和部署位置，都有边界

模型选出的命令不会在函数自身的磁盘上运行。工作区有三种选择：

• virtual() 把文件放进会话日志，提供兼容 bash 的 shell，没有网络，约能容纳 500 个文件。
• virtual({ durable: false }) 把临时文件留在内存，每一轮结束后清空。
• sandbox() 为每个会话创建 Vercel Sandbox，/workspace 位于 Drive 上。

待办清单等带类型的 JSON 文档也可以保存在日志里，每份最多 64 KB。可见，日志适合记录会话和有限工作状态，不能直接当成无限容量的项目存储。

部署方面，Vercel World 配合 Vercel Functions 和 Vercel Queues，能在 Agent Runs 中查看会话追踪；本地 World 使用机器上的文件，无需配置；自托管可以使用 Postgres World，要求版本为 5.0.4 或更高，运行环境为 Node.js 22+。

切换到 Postgres 涉及两个环境变量：WORKFLOW_TARGET_WORLD 和 WORKFLOW_POSTGRES_URL。原文也转述 Vercel 博客列出了 MongoDB、Redis、Turso，但没有展开配置与能力差异。

这里还有一个硬限制：Pi、OpenCode 可以在函数内运行，Claude Code、Codex 则必须使用 Vercel Sandbox，连自托管也一样。自托管持久化后端，并不等于整个执行链路都能脱离 Vercel。

我的判断

这个方向解决了一个真实的工程问题：进程恢复，需要把调用结果、执行进度和工作区状态一起考虑。对已经围绕现有 Coding Agent 搭好流程的团队，适配层的吸引力，在于能保留原来的执行框架。

不过，文章没有给出接入成本、存储开销和故障恢复耗时的对照数据。它能证明方案思路，尚不足以证明生产表现。

原文列出的替代方案也不完全处于同一层：Temporal + OpenAI Agents SDK 是面向该 SDK 的持久执行封装，使用 Python，状态标为自 2026 年 3 月 23 日起 GA，表中列出的服务端许可证为 MIT；Inngest AgentKit 是 TypeScript 多 Agent 框架，采用 Apache-2.0；Cloudflare Agents SDK 基于 Durable Objects 和 Cloudflare Workflows，使用 TypeScript、MIT 许可证。三者是否直接封装 Claude Code、Codex，原文均未披露。

durable-harness 自身是 TypeScript npm 包，采用 Apache-2.0。如果需求是给现有执行框架补恢复能力，它值得评估；如果正在从头设计 Agent 编排，就不能只凭这张功能表选型。0.0.x 的实验 API 和 Sandbox 依赖，都应算进迁移成本。

能拿来做什么

• 给 Node.js 云端 Agent 增加恢复能力前，先盘点模型调用、工具调用和会话文件分别存在哪里，确认崩溃后能否还原执行进度。
• 为工具明确设置重放策略。查询类操作可以评估 replay: 'safe'；涉及外部状态变更的操作，要同时考虑 replay: 'never' 和结果核验流程。
• 根据任务选择工作区。少量、无网络的文件处理可以评估 virtual()；需要保留跨轮文件时，避免误用 virtual({ durable: false })。
• 试接 Claude Code 或 Codex 时，先验证 Vercel Sandbox 依赖是否符合部署要求，再用中途终止进程等场景检查恢复结果和重复调用情况。