Vercel 最出名的身份，是 Next.js 背后的公司和前端部署平台。但它在 GitHub 上还有一组规模不小、仍在更新的开源项目。
旗下两个 GitHub 组织里，星标过万的仓库有 16 个（2026 年 8 月 16 日 GitHub 数据）。Next.js、SWR、Turborepo 等是 AI 时代之前积累的 Web 底座；AI SDK、agent-browser、agent-skills、skills、json-render 这 5 个 AI 原生项目也已经过万星。
表中主要仓库的星标合计约 37 万。社区活跃，它们几乎都在一周内有过代码推送。
这些项目覆盖了 Web AI 应用开发的多个环节：框架、模型接入、界面渲染、Agent 工具和能力分发。Vercel 还在其中几层定义了兼容接口和适配器边界，让第三方实现能够接进来。
一家商业公司为什么要做这件事，这些项目对开发者和 AI 生态又意味着什么？
先看版图：万星项目不止一个
以下是 Vercel 两个 GitHub 组织下的主要项目（星标和更新状态抓取于 2026 年 8 月 16 日）：
| 项目 | 星标 | 类型 | 定位 |
|---|---|---|---|
| Next.js | 14.2 万 | Web 底座 | React 全栈框架，多款 AI 产品使用的前端框架 |
| agent-browser | 4.1 万 | AI 原生 | 面向 AI Agent 的浏览器自动化 CLI |
| SWR | 3.2 万 | Web 底座 | React 数据请求库 |
| Turborepo | 3.1 万 | Web 底座 | JS/TS monorepo 构建系统 |
| agent-skills | 3.0 万 | AI 原生 | Vercel 官方 Agent Skills 集合 |
| skills | 2.9 万 | AI 原生 | Agent Skills 的发现、安装和管理工具 |
| AI SDK | 2.6 万 | AI 原生 | TypeScript AI 应用工具包 |
| json-render | 1.6 万 | AI 原生 | 生成式 UI 框架 |
| portless | 1.0 万 | 开发辅助 | 用命名 URL 替代端口号，服务本地开发 |
| streamdown | 5500 | AI 原生 | AI 流式 Markdown 渲染 |
| just-bash | 4100 | AI 原生 | 面向 Agent 的 Bash 执行环境 |
vercel 组织以正式维护项目为主，vercel-labs 以实验和探索项目为主，但这不是严格的成熟度分界。
两个组织的万星仓库里还包括 Hyper 终端、pkg 打包工具、satori 等老牌项目。pkg 目前已经归档，所以累计星标也包含历史影响。
星标不等于生产采用，近期推送也只能说明有维护动作。要判断社区活跃度，还需要贡献者数量、issue 和 PR 的处理情况、下载量的时间变化。目前能确认的是：这些项目累计获得较高关注，近期仍有维护动作。
数量之外，这些项目已经有了结构：它们大致沿着 AI 应用的开发路径排开。
这套版图覆盖了 Web AI 开发的多个环节
把上面的项目按开发流程重新排一遍：
第一步，起一个应用。 Next.js 提供框架，Turborepo 管工程，SWR 管数据请求。这一层在 AI 时代之前就存在，是 Vercel 的老底子。
Rauch 在 Series F 文章里提到，Grok、Claude、Cursor 这些头部 AI 产品的前端在用 Next.js。这是公司自述，不作为独立采用数据。
第二步，接入模型。 AI SDK 把不同模型供应商的调用统一成一套 TypeScript 接口：文本生成、结构化输出、工具调用、流式响应，再加上 React、Svelte、Vue 都能用的聊天 UI hooks。ToolLoopAgent 和 HarnessAgent 进一步把 Agent 循环和既有 Agent harness 纳入同一套抽象。
第三步，把输出变成界面。 streamdown 处理流式 Markdown 渲染，json-render 探索用受约束的数据结构生成界面，AI Elements 提供 AI 场景的界面组件。
第四步，给 Agent 装上手脚。 agent-browser 让 Agent 操作浏览器，just-bash 提供命令执行环境，mcp-handler 帮 Web 框架接入 MCP，github-tools、slack-tools 把外部系统封装成工具。
第五步，分发和打包能力。 skills CLI 负责发现和安装 Skill，agent-skills 是官方集合，skills.sh 是公开入口。
2026 年 8 月公开的 Agent Plugins 1.0，又为 Agent Skills 和 MCP Server 定义了统一打包层。兼容客户端可以从同一个插件包中发现和加载自己支持的组件，搜索、安装、权限和具体功能仍由各客户端或分发渠道决定。
从起项目到分发 Agent 能力，多个环节都有公开代码项目或明确开源的工具。旧 Web 底座和新 AI 工具接在了一起，覆盖范围比单个 SDK 更宽。具体项目能否自由修改、再分发，仍要看各自许可证。
项目之间靠什么连接
流程覆盖只是第一层。更关键的是，Vercel 在不同层使用了相似的扩展方式。
模型层，AI SDK 用版本化的 Language Model Specification 定义 Provider 兼容接口。第三方可以实现自己的 Provider，再申请进入 Community Providers 文档。
AI SDK Tools Registry 收录搜索、浏览器、代码执行、安全等现成工具，也接受第三方提交。
渠道层，Chat SDK 把 Slack、Teams、Discord、GitHub 等平台的差异放进 Adapter，核心 Agent 逻辑可以保持不变。它的 Adapter Directory 把实现分成官方、厂商官方和社区三类。
持久执行层也有相似设计。Workflow SDK 用 Worlds 把事件日志、计算和队列封装成可替换的运行时。Vercel 提供托管实现，也维护 Postgres 参考实现，社区还可以继续做其他适配。
这些机制并不完全相同，但能看到相似的扩展思路：先划出兼容接口或 Adapter 边界，允许官方和第三方实现接入，部分层再提供目录、提交或分发入口。
这些接口大多仍由 Vercel 自己维护，不等于多厂商共同治理的行业标准；Workflow Worlds 也还没有独立的公开目录。但这种设计给第三方留下了接入位置，也让兼容实现更容易被开发者找到。
eve 开始把这些零件收进一套项目结构。它提出“一个 Agent 就是一个目录”：模型写在 agent.ts，instructions 和 skills 放在 Markdown，tools、subagents、channels、connections、schedules、evals 各有自己的位置。
它还在公测，更像 Vercel 对完整 Agent 应用结构的一次提案，不是已经形成的跨厂商标准。
商业公司为什么免费送这么多
这些开源投入并非脱离商业产品独立存在。
模型接入旁边有 AI Gateway，持久执行旁边有 Vercel Workflows，不可信代码运行旁边有 Sandbox。
Agent 要访问 Slack、GitHub、Salesforce 等外部系统，Vercel Connect 可以在运行时签发短期凭证。安装受支持的 Marketplace Integration 后，Vercel Agent 还能加载供应商提供的 MCP 工具，由平台处理认证和配置。
这些产品不是一条强制经过的封闭通道。AI SDK 可以显式连接模型供应商，Workflow SDK 可以使用其他 World，Chat SDK 也不要求必须通过 Connect。
不过，当接口、目录、部署和商业服务彼此靠得很近，可能会减少开发者继续接入 Vercel 商业产品的摩擦。开源项目和文档降低了部分进入门槛，商业产品则承接模型路由、持久运行、隔离执行、鉴权和配置。
Rauch 在 Series F 文章中把开源称为“一个强大的飞轮”（a powerful flywheel）。这是一种相邻关系，不代表每一个开源用户都会转成付费客户。
只要许可证允许，开发者仍然可以在不购买 Vercel 云服务的情况下使用、研究和修改这些项目。这是它们的公共价值。采用时还要继续看哪些能力可以替换、迁移要付出多少工程成本，以及关键接口由谁决定。
总结
Vercel 已经在现有底座之上，铺出了一条清晰的 Web AI 应用开发路径：接入模型、组织界面、给 Agent 配置工具、连接外部系统、执行持久任务，再把能力打包和分发出去。通过开源项目、兼容接口、示例和文档，这些工程经验也变成了可以学习、修改和继续开发的公共资源。
**对正在学习和开发 AI 应用的人来说，这套开源版图既提供了可直接使用的工具，也提供了理解 AI 应用怎样落地的基础。**它还不是整个 AI 技术栈的底层标准，但已经成为 Web AI 应用开发值得参考的起点之一。
