深度解析 Vercel Open Agents：三层分离架构如何让 AI 编码进入“后台运行“时代

文章目录

- [一、Open Agents 是什么？](#一、Open Agents 是什么？)
- 二、三层架构：逐层拆解
- - [2.1 Web 层：不只是聊天界面](#2.1 Web 层：不只是聊天界面)
  - [2.2 Agent 层：持久化工作流是灵魂](#2.2 Agent 层：持久化工作流是灵魂)
  - [2.3 Sandbox 层：隔离执行环境](#2.3 Sandbox 层：隔离执行环境)
- [三、架构点睛：Agent 与 Sandbox 的解耦](#三、架构点睛：Agent 与 Sandbox 的解耦)
- - [传统做法：Agent 内嵌在 VM 中](#传统做法：Agent 内嵌在 VM 中)
  - [Open Agents 的做法：Agent 在外部，通过工具操作沙箱](#Open Agents 的做法：Agent 在外部，通过工具操作沙箱)
- 四、从参考实现到生产落地
- - 部署依赖
  - 密钥生成
  - [GitHub 集成的关键配置](#GitHub 集成的关键配置)
- 五、为什么这件事值得关注？
- - [5.1 编码 Agent 正在从"工具"变为"基础设施"](#5.1 编码 Agent 正在从"工具"变为"基础设施")
  - [5.2 大厂已经在自建了](#5.2 大厂已经在自建了)
  - [5.3 对普通开发者的实际意义](#5.3 对普通开发者的实际意义)
- 六、总结

你有没有想过，能不能给 AI 下一道需求，然后关掉电脑去睡觉，第二天早上醒来，PR 已经提好了？Vercel 开源的 Open Agents，正是为了解决这个"科幻级"需求而生。

一、Open Agents 是什么？

2026 年 4 月，Vercel Labs 正式开源了 Open Agents （仓库：vercel-labs/open-agents）------一个云端 AI 编码智能体的参考实现。

说人话就是：你 fork 它、部署到 Vercel，就拥有了一个 24 小时在线的 AI 编程助手。整个过程不需要你的电脑开着，你可以用手机下发任务，Agent 在云端自动克隆仓库、读代码、改文件、跑测试、提 PR。

这和我们熟悉的 Claude Code、Cursor、Copilot 有本质区别。那些工具是本地运行、请求绑定 的------你的电脑开着，AI 才能干活；请求结束，上下文就得靠对话历史勉强维持。Open Agents 走的是云端运行、持久化执行路线。

Vercel CEO Guillermo Rauch 在发布帖中透露了一个有意思的信息：Stripe（内部称 Minions）、Ramp（Inspect）、Spotify（Honk）、Block（Goose）等大厂，早已各自搭建了类似的内部 AI 编程平台。他判断，未来软件公司的竞争优势，将从"写了什么代码"转变为"怎么生产代码"。

换言之，Open Agents 不只是一个工具，而是 Vercel 在押注的方向：云端 Agent 基础设施。

二、三层架构：逐层拆解

Open Agents 的架构非常清晰，自上而下分为三层。我画了张图帮助理解：

2.1 Web 层：不只是聊天界面

Web 层基于 Next.js 构建，负责用户交互的完整闭环：

流式输出：Agent 一边思考、一边展示中间结果。不是等 5 分钟才看到最终答案，而是实时看到它的推理过程和工具调用链。
会话管理：每次对话是一个独立 Session，支持断线重连。你关了浏览器，再打开还能接着看进度。
身份认证 ：通过 Vercel OAuth 实现，生成的会话支持只读链接分享------同事能看到完整对话历史和代码改动，但不能操作。
语音输入：集成了 ElevenLabs 的转录服务，懒得打字可以直接说需求。

这一层看似简单，但在"后台运行"场景下，聊天 UI 的职责变了------它不再是实时打字对话，而更像是一个任务管理中心。

2.2 Agent 层：持久化工作流是灵魂

这是整个系统最核心的一层。Agent 不是随着 HTTP 请求起灭的，而是作为持久化工作流（基于 Vercel Workflow SDK）运行。

具体来说：

多步执行 。Agent 可以执行一连串操作------"先搜索所有包含 console.log 的文件，再逐个替换为 logger.info，然后跑一次 lint，最后提交"。每一步的结果都会被持久化，失败时能看到具体卡在哪一步，修复后继续，不用从头来。

状态持久化。这不是把对话历史塞进 prompt 那种"伪持久化"，而是真正的状态机。Agent 的工作流状态存储在 PostgreSQL 中，断电、断网、服务器重启，都能恢复。

流式输出。Agent 层实时向上层推送执行状态，Web 层负责渲染。任务取消也是在这一层处理的------如果发现 Agent 走偏了，随时可以喊停。

工具集。Agent 通过以下工具与外界交互：

工具	能力
文件操作	读、写、编辑沙箱中的文件
代码搜索	在项目中搜索特定模式
Shell 命令	执行任意命令（受沙箱隔离）
任务管理	管理多步骤任务的调度
技能调用	调用预定义的专业技能

2.3 Sandbox 层：隔离执行环境

Sandbox 是一个隔离的虚拟机，里面配备了完整的开发环境：

文件系统（Agent 改动的代码在这里落地）
Shell 执行能力
Git（支持 clone、branch、commit）
开发服务器（暴露端口 3000、5173、4321、8000，可以跑 dev server 看效果）

最关键的能力是快照机制（Snapshot）。沙箱可以基于快照快速启动，不活跃时自动休眠，恢复时从快照还原。这解决了两个实际痛点：一是多会话并行时，不用为每个会话一直开着 VM 烧钱；二是上下文切换时秒级恢复，不用每次从头初始化环境。

三、架构点睛：Agent 与 Sandbox 的解耦

如果说三层架构是骨架，那 Agent 与 Sandbox 的分离就是这套设计的神来之笔。

传统做法：Agent 内嵌在 VM 中

在多数编码 Agent 的实现里，Agent 进程直接在沙箱虚拟机内部运行。代码执行、工具调用、推理决策，全在同一个环境里。

这种模式的问题是：

Agent 生命周期和沙箱强绑定------沙箱一关，Agent 的状态全丢；
沙箱不能独立休眠------因为 Agent 在里面跑着，休眠等于杀掉 Agent；
架构刚性------想换沙箱实现、想升级 Agent 逻辑，牵一发动全身。

Open Agents 的做法：Agent 在外部，通过工具操作沙箱

Agent 运行在 Vercel 的 Workflow 环境中（沙箱外部），通过一组标准化的工具（文件操作、代码搜索、Shell 命令）与沙箱交互。

这不是简单的"远程调用"------而是把 Agent 的控制面和执行面彻底拆开：

维度	Agent 内嵌模式	Open Agents 解耦模式
生命周期	绑定	独立演进
沙箱休眠	不可能	快照→休眠→恢复
升级灵活性	捆绑升级	各自独立迭代
跨请求持久化	不自然	原生支持
安全性	Agent 可直接操作 VM	工具调用形成安全边界

大家可以品品这个设计选择。它解决的其实是一个工程上的老问题：长时间运行的任务，到底该绑在什么生命周期上？

HTTP 请求太短了（几秒到几十秒）。一个完整的编码任务可能需要几分钟甚至几小时------搜索代码库、理解架构、修改多个文件、跑测试、迭代修复。把这种任务绑在 HTTP 请求上，就像让马拉松选手在百米跑道上往返跑，技术上能做，但处处别扭。

Vercel 的解法是：任务的生命周期应该独立于任何一次请求。Agent 工作流是持久化运行的，前端只是它的观察窗口和指令输入口。你关掉浏览器，工作流继续跑。你第二天重新打开，通过会话 ID 重新连接到它的流。

这种设计还有一个不那么明显的好处：沙箱保持纯粹。沙箱只是一个执行环境，不承担任何控制逻辑。这意味着沙箱实现可以随意替换------今天用 Vercel Sandbox，明天可以换成 Cloudflare Sandboxes（Cloudflare 刚 GA 了类似方案），甚至自建 K8s Pod。Agent 层完全无感。

四、从参考实现到生产落地

Open Agents 的定位是"参考实现，而非成品项目"（官方原话）。这意味着你可以直接 fork 回去改，当成自己项目的骨架。

部署依赖

生产部署需要以下几块基础设施：

组件	用途	必需/可选
PostgreSQL	状态管理、OAuth 认证	必需
Vercel OAuth App	用户登录	必需
GitHub App	仓库访问、自动 PR	可选（但功能减半）
Redis / KV	数据缓存	可选
ElevenLabs	语音输入	可选

密钥生成

两个核心密钥：

bash 复制代码

# JWE_SECRET：用于加密会话
openssl rand -base64 32 | tr '+/' '-_' | tr -d '=\n'

# ENCRYPTION_KEY：用于加密敏感信息
openssl rand -hex 32

GitHub 集成的关键配置

如果要启用代码操作能力（这基本是核心卖点），需要创建 GitHub App 并配置：

Callback URL: https://YOUR_DOMAIN/api/github/app/callback
启用 "Request user authorization (OAuth) during installation"
配置 Webhook Secret

部署完成后，Agent 就能自动完成：克隆仓库 → 创建分支 → 提交代码 → 推送 → 提 PR 的完整链路。

说个题外话：Vercel 这一手开源商业化玩得很聪明。你 fork 了 Open Agents，就得用 Vercel 的 Workflow SDK、Sandbox、Postgres、部署平台。这是典型的"开源模板 → 引流付费基础设施"策略。对独立开发者来说，这个思路本身也值得学习------做一个开源的最佳实践模板，把你的付费服务嵌进去。

五、为什么这件事值得关注？

5.1 编码 Agent 正在从"工具"变为"基础设施"

Cursor、Copilot 是工具。你打开 IDE，AI 补全代码，交互结束。

Open Agents 代表的是一类新东西：持续运行的、自主操作代码仓库的 AI 系统。它不是一个在你打字时弹提示的助手，而是一个在你睡觉时默默干活的"同事"。

这个范式的核心变化在于：

从"请求-响应"到"任务-执行"。传统编码工具是同步的、请求驱动的；Open Agents 是异步的、任务驱动的。这个差异在工程上意味着完全不同的架构选择------工作流引擎、状态持久化、沙箱生命周期管理，都变成了必选项。

5.2 大厂已经在自建了

前面提到，Stripe、Spotify、Ramp、Block 都在内部搭建了类似系统。这说明了什么？

大厂的代码库规模和组织复杂度，让"通用编码 Agent"很难直接适配。他们需要的是能理解内部规范、对接内部工具链、在私有仓库上运行的 Agent。Open Agents 开源的时机恰好------它给那些想自建但不知道从何下手的团队，提供了一个高质量的起点。

5.3 对普通开发者的实际意义

说点实在的。对大多数开发者来说，现在去部署一个 Open Agents 可能还太早------它还是一个需要二次开发的模板，不是开箱即用的产品。

但它的架构设计，对任何在做 AI 应用的人都有参考价值：

持久化工作流怎么设计
沙箱隔离怎么做
Agent 工具调用的边界怎么划
长时间运行任务的状态管理和错误恢复

这些是 AI Agent 开发的通用问题。Open Agents 给出了一套经过大厂验证的参考答案。

六、总结

Open Agents 的核心贡献，不在于它"能做什么"------AI 自动改代码、提 PR 这些事，其他工具也能做。它的价值在于展示了怎么做：

三层架构清晰分离了交互、决策和执行
Agent 与 Sandbox 解耦让长时间任务成为可能
持久化工作流取代请求绑定执行
开源模板降低了大厂才玩得起的 Agent 基础设施的门槛

Vercel 用这个项目押注了一个方向：AI 编程的下一个阶段，不是更好的代码补全，而是让 Agent 成为持续运行的软件生产单元。

如果你正在做 AI Agent 相关的产品或研究，这个项目的源码和架构设计，值得花一个下午认真读一遍。

项目地址： https://github.com/vercel-labs/open-agents

参考来源：InfoQ、Vercel 官方博客、GitHub vercel-labs/open-agents

如果你对 AI Agent 的架构设计有更多想法，欢迎在评论区交流。你觉得 Agent 与 Sandbox 解耦是正确方向，还是反而限制了 Agent 的能力边界？