编码智能体真正进入日常开发后，最脆弱的一环往往不是模型能力，而是会话的连续性。Vercel 开源的 durable-harness，正是冲着这个问题来的。
发生了什么
Vercel 发布并开源了名为 durable-harness 的包。它的核心机制是记录每一次模型调用和工具调用，从而让智能体会话在崩溃、超时或重新部署之后能够恢复。官方点名的兼容对象包括 Pi、OpenCode、Claude Code 和 Codex，运行环境覆盖 Vercel 平台、Postgres 以及本地笔记本。
换句话说，它并不试图做一个新的编码智能体，而是给现有智能体加一层“可恢复”的运行时记录。
为什么重要
编码智能体的工作方式决定了它对中断极其敏感。一次任务往往包含多轮模型推理、文件读写、命令执行和测试运行，状态散落在上下文窗口、临时文件和进程内存里。一旦进程挂掉、请求超时，或部署环境发生滚动更新，前面的工作就可能全部作废，用户只能从头再来。
这类问题在演示里不明显，在生产里却很致命。长时间运行的智能体任务越复杂，中断的代价越高。durable-harness 的思路是把“调用日志”变成可重放的持久状态，让恢复成为默认能力，而不是每个团队各自造轮子。对已经在 Vercel 上部署应用的团队来说，把智能体会话与平台的重部署机制对齐，也减少了运维层面的摩擦。
影响与看点
对开发者而言，最直接的价值是降低长任务的失败成本：崩溃不再等于重来，超时也不再意味着上下文全部丢失。对工具生态而言，同时支持 Claude Code、Codex、OpenCode 等多个客户端，说明它想做的是一层通用基础设施，而非绑定单一厂商。
值得关注的点有三处。其一，记录粒度与恢复语义：记录到什么程度、恢复时如何保证工具调用不重复执行，决定了它能否用于真实的生产任务。其二，存储后端的选择：Postgres 与本地并存，意味着从个人开发到团队部署都有路径，但持久化的成本和清理策略需要实践检验。其三，它与平台部署模型的耦合程度，会影响非 Vercel 用户的采用意愿。
一个独立判断：智能体的竞争正在从“模型多聪明”转向“任务多可靠”。可恢复性这类看似不起眼的工程能力，可能比再提升几个点的基准分数更能决定编码智能体能否真正进入团队工作流。
