Render取消AI沙箱运行时长上限

Render 把付费工作区沙箱原先连续运行 30 天的上限取消了，直接对比的是原文所述 Vercel 单次沙箱会话 24 小时的限制。但这次发布更值得看的，是沙箱闲置后能否保留执行现场，以及长任务失败后能否接着跑。

对做 AI 编程、代码迁移和后台 Agent 的开发者，这些能力关系到任务恢复成本。不过，报道中的技术细节主要来自 Render 自述，凭证代理、私有网络和共享文件并发写入也各有未完成的部分。

没有运行时限，究竟解决了什么

先把两个概念分开：一个环境能存在多久，以及它恢复时能保留什么。

据原文，Render 此前对付费工作区设置了连续运行 30 天的限制，这次取消了该上限。Vercel 的单次沙箱会话则限制在 24 小时。代码库迁移、整套应用测试等任务如果持续数天，就可能碰到会话边界。

但保存代码和文件，还不等于保存执行现场。

报道描述，Vercel 的持久化沙箱可以重新启动，但运行中的进程需要重来；Render 则声称，沙箱闲置时会挂起，下一条命令到来时唤醒，并保留文件、内存和运行中的进程。对 Agent 来说，区别在于能否从中断位置继续工作，省去重新构建状态的步骤。

比「能跑多久」更关键的，是恢复后还剩下多少执行状态。

这里也要收住预期。原文没有交代挂起与唤醒的延迟、计费方式，以及网络连接恢复时的行为。「不限时」只说明取消了这项运行时长限制，不能据此推断资源免费，或所有外部连接都会原样续上。

沙箱能续跑，为什么还需要 Durable Workflows

沙箱保留执行现场，Durable Workflows 处理的则是另一个问题：进程崩溃后，业务流程怎么继续。

Render 的新工作流支持 Python 和 TypeScript，单个任务最长运行 24 小时。平台会在每一步完成后保存结果；进程崩溃时，工作流可以在新机器上利用已保存的结果恢复，跳过已经完成的步骤。

这里的 24 小时是工作流单个任务的限制，与沙箱取消连续运行时限是两回事。

把一次 Agent 作业拆成模型调用、代码处理、数据库写入等步骤，保存中间结果，就有机会减少失败后的重复执行。但平台保存结果，并不能自动消除所有重复副作用。

原文给出的例子很直接：支付已经成功，进程却在保存结果前崩溃。恢复后，系统可能再次执行支付。因此 Render 仍建议使用幂等键（idempotency keys），避免重复扣款或写入。

工作流能恢复进度，业务操作仍要自己处理幂等。

配套的 Shared Filesystems 则让沙箱和工作流任务访问同一份持久化文件，即使创建文件的计算实例已经关闭，文件仍然保留。Render 设想的是多个 Agent 读取同一仓库或数据集，各自写入自己的输出。

这个使用边界很关键：多个任务同时修改同一个文件时，锁和冲突解决机制仍在研究。现阶段不能把它当成已经解决协同编辑问题的共享目录。

Render 真正想卖的是整套后台运行环境

Render 创始人兼 CEO Anurag Goel 曾在 Stripe 担任工程师和风险负责人。他最初把 Render 定位为降低基础设施复杂度的 AWS 替代方案，如今把这套思路延伸到了 Agent。

他们的理由是，Agent 往往属于一个更大的产品：除了执行代码的沙箱，还需要持续在线的 API、数据库连接、后台 worker、cron jobs 和数据库。Render 希望把这些组件放在同一平台管理。

报道也涉及安全能力。凭证代理（credential brokering）会在请求离开沙箱时附加凭证，让密钥不进入沙箱内部。不过，该能力先向少量客户开放，原文称后续几周扩大范围；沙箱私有网络仍在开发中。

Beta 开发者已经可以使用出站控制，禁止沙箱全部外连，或只放行列出的域名。

Render 没把凭证代理包装成独有优势。Vercel 已通过 Connect 提供限定权限的凭证，Render 也承认这正在成为基础配置。

竞争性更强的说法出现在计算资源上。Render 批评 Vercel 的 fluid compute 不适合计算密集型后台任务，并引用单个函数最高 2 CPUs、4 GB RAM 的限制。原文特别澄清：这个上限针对 Vercel Functions，不能套到 Vercel 沙箱上。

至于「离开 Next.js 就在与平台较劲」，这是 OCMI CTO Cristian Herrera 的个案评价。Vercel 在报道发布前尚未给出回应，文章也没有提供同任务、同资源下的性能或费用对照。

我的判断

这次发布有价值的地方，是把执行状态、失败恢复和共享文件串在了一起。对于需要持续运行后台任务的 Agent 产品，统一管理 API、worker、数据库和沙箱，确实可能减少开发者拼接基础设施的工作。

但它是否更划算、更稳定，原文没有足够证据。Render 表示，新用户经常提到从 AWS 和 Vercel 迁出，原因包括复杂度与成本，却没有公布从 Vercel 迁来的客户数量。这属于厂商反馈，不能当作迁移趋势的数据证明。

常见替代做法，是把长任务放进队列和 worker，用数据库记录进度，再按需恢复任务。这种方式需要团队自己设计更多状态管理，但任务边界和重试逻辑也更容易显式控制。Render 的组合方案是否合适，取决于它替团队省下多少维护工作，以及未完成的能力是否恰好卡住业务。

如果只是短任务、可随时重建的执行环境，「不限时」未必值得优先考虑。对长任务，更该验证的是恢复行为、失败后的重复执行，以及共享文件的访问边界。

能拿来做什么

• 做跨天代码迁移或整库测试 Agent 时，把「保留文件」和「保留进程、内存」分别列为验证项，实际检查挂起后任务能从哪里继续。
• 用 TypeScript 编排长任务时，按可保存结果的业务步骤拆分流程，并确认单个任务能否落在 24 小时内。
• 对支付、数据库写入等有副作用的步骤设置幂等键，覆盖操作成功但结果尚未保存就崩溃的情况。
• 多 Agent 共用仓库或数据集时，先采用共同读取、分别输出的结构；需要同时修改同一文件时，单独设计冲突处理。