Open Agents：让编码 Agent 在云端「一直跑着」，你的笔记本可以合盖

图：Open Agents 项目封面（来自项目官方站点 open-agents.dev）

一、一个具体的场景

你让 Agent 改一个跨 8 个文件的 bug。它要装依赖、跑测试、失败后读报错、改代码、再跑一遍——整个过程 15 分钟。这 15 分钟里，你的笔记本必须开着、不能休眠、网络不能断，你也不能关掉那个终端窗口。

更糟的是：你起身倒了杯水，回来发现终端被关了，Agent 的上下文全丢。

Vercel Labs 开源的 Open Agents 就是来解决这个问题的：把 Agent 从「一次 HTTP 请求」变成「云端一个持续运行的任务」。

二、它是什么

官方定位："An open-source reference app for building and running background coding agents on Vercel."

关键在于 "reference app" —— 它的定位不是产品，而是参考实现。README 明确写着「The repo is meant to be forked and adapted, not treated as a black box.」

它包含四块东西：Web UI、Agent 运行时、沙箱编排、以及打通 GitHub 的集成。技术上建立在 Vercel 的 AI SDK、Gateway、Sandbox 和 Workflow SDK 之上。

三层架构

Web → Agent workflow → Sandbox VM

• Web 层：认证、会话、聊天、流式 UI
• Agent 层：作为 Vercel 上的持久化 workflow 运行
• Sandbox 层：文件系统、shell、git、dev server、预览端口

三、一个类比：从「实习生坐在你旁边」到「实习生在远程办公」

传统编码 Agent 像实习生坐在你工位上干活——你得在办公室，他才能干活，他离开工位活就停了。Open Agents 是把实习生送去远程：他有自己的工位（沙箱）、有自己的工牌（GitHub App）、按点打卡（workflow run），你只需要偶尔看他提交的 PR。

这个转变带来的是三个直接好处：不占用你的本地资源、任务不随终端关闭而中断、结果以 PR 形式沉淀而非聊天记录。

四、核心设计：Agent 不是沙箱

这是整个项目最值得强调的架构决策，README 单独用一段讲："the agent is not the sandbox"。

Agent 不在 VM 里运行，它跑在沙箱之外，通过文件读取、编辑、搜索、shell 命令这些工具与沙箱交互。这个分离带来的结果是：

• Agent 执行不绑定在单次请求生命周期上
• 沙箱生命周期可以独立休眠与恢复
• 模型/供应商选择与沙箱实现可以各自演进
• VM 保持为「纯执行环境」，而不是控制平面

五、核心功能

• 带文件、搜索、shell、任务、技能、网页工具的聊天式编码 Agent
• 基于 Workflow SDK 的持久化多步执行，支持流式输出与取消
• 隔离的 Vercel 沙箱，基于快照（snapshot）恢复
• 沙箱内仓库克隆与分支操作
• 成功后可选自动 commit、push、创建 PR
• 通过只读链接共享会话
• 可选的 ElevenLabs 语音输入转写

运行时细节值得留意：聊天请求会启动一个 workflow run 而不是内联执行 Agent；每个 Agent 回合可以横跨多个持久化 workflow 步骤；运行中的任务可以重新连接流来恢复。沙箱暴露 3000、5173、4321、8000 四个端口，可在不活动后自动休眠。

自动 commit 和自动 PR 是偏好驱动而非始终开启——这点很重要，默认不越权。

六、上手门槛

最快路径：一键部署到 Vercel

README 顶部就是 Vercel 部署按钮，带完整的环境变量预填清单（Neon Postgres 自动配置、Better Auth secret、Vercel OAuth 与 GitHub App 凭据）。

步骤是标准的：Fork 仓库 → 导入 Vercel → 生成 BETTER_AUTH_SECRET（openssl rand -base64 32）→ 填 POSTGRES_URL → 部署一次拿到稳定生产 URL → 创建 Vercel OAuth App（回调 https://YOUR_DOMAIN/api/auth/callback/vercel）→ 需要完整 GitHub 流程就创建 GitHub App（回调 /api/auth/callback/github，Setup URL /api/github/app/callback）→ 填环境变量重新部署。

本地开发

corepack enable
pnpm install
cp apps/web/.env.example apps/web/.env
pnpm web

如果已链接 Vercel 项目，可以用 vc env pull 拉取环境变量。

环境变量

最低要求只有两个：POSTGRES_URL 和 BETTER_AUTH_SECRET。GitHub 相关功能需要 Client ID/Secret、GITHUB_APP_PRIVATE_KEY、GITHUB_WEBHOOK_SECRET。可选的有 REDIS_URL/KV_URL（技能元数据缓存，不配则退化为内存缓存）、OPEN_AGENTS_RESOURCE_PROFILE=hobby（Hobby 套餐兼容的默认资源规格）、VERCEL_SANDBOX_BASE_SNAPSHOT_ID（沙箱基础快照）、ELEVENLABS_API_KEY（语音）。

硬件

本地跑 Web 层不需要 GPU（推理走 AI SDK 网关）。真正的算力开销在云端沙箱，按 Vercel Sandbox 计费。

七、争议与局限

强绑定 Vercel 技术栈。 Workflow SDK、Sandbox、Gateway、AI SDK 全是 Vercel 生态。虽然代码开源可 fork，但换到 AWS/GCP 意味着重写执行引擎——这是「reference app」的代价。

配置繁琐。 Vercel OAuth App + GitHub App + 多轮「填环境变量→重新部署」，完整走通要 10 步以上。GitHub App 还要处理公开化设置才能让组织安装顺畅。

GitHub App 权限需要审视。 自动 commit/push/PR 意味着这个 App 对仓库有写权限。公网可访问的 SaaS 部署配上可写权限的 GitHub App，配置不当风险不小。

沙箱端口是固定的。 只暴露 3000/5173/4321/8000 四个端口，复杂应用可能不够用。

成本不可预测。 长任务 + 沙箱不自动休眠时，Vercel Sandbox 的账单会随运行时长线性增长。

Beta 状态。 官方仓库显示 fork 700+、open issues 57，API 仍在演进。

八、行业意义

Open Agents 精准命中了 2026 年 AI 编码的一个真实痛点：Agent 任务时长正在超过人类注意力时长。一个需要跑测试、改代码、再验证的 Agent 任务动辄十几分钟，如果绑定在本地会话里，失败成本极高。

它代表的架构趋势是「Agent 从同步请求变成持久化任务」——这与 Temporal、Inngest 这类工作流编排的思路一致，也和 Vercel 自己的 Workflow SDK 主张一致。这个转变一旦完成，Agent 就不再是「你打开终端才有」的工具，而是「你提交需求然后去开会」的基础设施。

作为参考实现，它的价值在于把这件事的完整形态摊开给你看：三层架构（Web/Agent/Sandbox）、Agent 与沙箱解耦、快照恢复、GitHub App 闭环、只读会话分享——每一块都可以直接抄。

MIT 协议、可 fork、文档写到了「10 步部署 + 完整环境变量清单 + 每条变量的用途说明」这个粒度，是目前开源「后台编码 Agent」方向最完整的样板之一。

对团队的现实价值：把编码 Agent 从「个人工具」变成「团队可提交、可审阅的流程」——结果以 PR 沉淀，而不是躺在某个人的终端里。