KechuAI

Vercel Open Agents：一个"把 Agent 关在沙箱外"的云端编码 Agent 参考模板

Vercel
AI Agent
开源
沙箱
云原生
模板
2026/10/3
·

阅读时间: 大约 8 分钟

Vercel Open Agents：一个”把 Agent 关在沙箱外”的云端编码 Agent 参考模板

open-agents 仓库结构与元信息（GitHub 官方页面）：apps/web、packages、.agents/skills，MIT 协议

2026 年，“云端编码 Agent”从各家闭源产品（Devin、Claude in the cloud 等）里开始长出可自建的版本。Vercel Labs 放出的 open-agents（MIT 协议）就是这样一个东西：它不是一个让你注册即用的 SaaS，而是一个拿来 fork、再改成自己产品的参考应用。README 明确写着：“这个仓库是拿来 fork 和改造的，不要把它当黑盒。“截至笔者调研，仓库约 34 个 open issues、23 个 open PR，处于早期但迭代活跃。

一、它到底包含什么

Open Agents 把”从零做一个云端编码 Agent”所需的一整套件都打包好了：Web UI、Agent 运行时、沙箱编排、以及 GitHub 集成——也就是从”提一个 prompt”到”产出一个 PR”的完整链路。它的定位是参考应用（reference app），不是库、不是托管服务。

二、三层架构：Web → Agent workflow → Sandbox VM

Open Agents 自称是一个三层系统：

层职责官方实现
Web鉴权、会话、聊天、流式 UINext.js 应用（apps/web）
Agent workflow多步、可恢复、可取消的 Agent 执行Vercel Workflow SDK 驱动的 durable workflow
Sandbox VM真正的执行环境：文件系统、shell、git、dev server、预览端口Vercel 隔离沙箱，基于快照（snapshot）恢复

整篇文章最该被记住的一个设计判断，是 README 用整段强调的：

Agent 并不运行在 VM 里面。它运行在沙箱外面，通过 file read / edit / search / shell 这类工具去操作沙箱。

这个”分离”被作者称为项目的”the main point”，理由有四条：

  1. Agent 执行不被绑死在单个 HTTP 请求的生命周期里——聊天请求只是启动一个 workflow run，而不是在请求里同步跑完 Agent；
  2. 沙箱的生命周期可以独立休眠/恢复——空闲后 hibernate，需要时再唤醒；
  3. 模型/厂商选择与沙箱实现可以各自演进，互不牵制；
  4. VM 保持为一个”纯粹的执行环境”，而不是长成控制面。

三、能力清单（官方自述）

  • 聊天驱动的编码 Agent，内置 file / search / shell / task / skill / web 工具；
  • 基于 Workflow SDK 的 durable 多步执行，支持流式输出与取消；断线后重连可以接着已有的 workflow run 继续；
  • 隔离的 Vercel 沙箱，基于快照恢复；沙箱里 clone 仓库、切分支干活；
  • 成功后可选自动 commit、push、建 PR（注意：是 preference-driven，不是默认常开）；
  • 通过只读链接分享会话；
  • 可选的语音输入（接 ElevenLabs 转写）。

沙箱默认暴露 3000、5173、4321、8000 四个端口给预览，可配置一个 base snapshot，空闲后自动休眠。

四、口径偏差与落地门槛

把官方话术和实际依赖对照后，有几点必须说清楚：

  1. 它深度绑定 Vercel 平台：durable workflow 用的是 Vercel Workflow SDK，沙箱是 Vercel Sandboxes，鉴权/存储依赖 Postgres、Redis/KV。这不是一个”到处都能跑”的通用框架——脱离 Vercel，三层里至少两层要重写。
  2. “参考模板”意味着重活自己干：.env.example 一长串必填项——Postgres、Better Auth、Vercel OAuth、GitHub OAuth/App（含 private key 与 webhook secret）、可选 Redis/KV、可选 ElevenLabs。想真跑起来，工程量并不小。
  3. “Agent 在沙箱外”是架构选择，不是安全银弹：它换来生命周期解耦，但沙箱退化为”纯执行环境”，安全边界完全落在 Agent 工具层（允许它跑哪些 shell、读写哪些目录）上，需要你自己配好工具白名单。
  4. 自动提 PR 不是默认行为：官方特意强调 auto-commit/auto-PR 是用户偏好开关，避免你 fork 后误以为它会未经许可往主仓推东西——这点对企业落地很重要。

五、客观评价

优势：

  1. 架构判断清楚：把”控制面（workflow）“和”执行面（sandbox）“显式分离，是当前云端编码 Agent 里比较成熟的一种范式，拿来当教学样板很值；
  2. 开箱链条完整：从 chat UI、durable 执行、快照沙箱到 GitHub PR 全有，省去自己拼 Vercel 全家桶的胶水；
  3. MIT 协议：可自由 fork、商用、改造。

局限：

  1. 平台锁定：不是跨云框架，押注 Vercel；
  2. 部署门槛高：一堆外部依赖与 OAuth/GitHub App 配置，不适合”五分钟跑起来”；
  3. 早期项目：34 issues / 23 PR，API 与目录结构仍在变动（提交记录显示还在从 pnpm/oxlint 这类工具链迁移）；
  4. 它是模板不是产品：你 fork 之后的维护成本（跟着上游升级、改造成自己的产品）要自己承担。

六、适合谁用

  • 想在 Vercel 技术栈上自建云端编码 Agent / AI DevTool 的团队，直接拿它当起点比从零搭快；
  • 想学习”durable workflow + 快照沙箱”这种 Agent 运行时范式的工程师，README 的分层说明就是一份不错的架构笔记；
  • 不适合：想找一个注册即用的托管编码 Agent，或要求跨云/自托管完全不依赖 Vercel 的团队。

参考来源