Vercel Labs 开源 fx：Zig 写成的极简 coding agent，赌的是“agent 引擎”而非聊天窗口

10 月 22 日，多家科技媒体集中报道了 Vercel Labs 开源的 coding agent fx。如果你只看当天的新闻标题，很容易以为这是 Vercel 刚刚发布的新玩具——但仓库的时间戳说了另一个故事：vercel-labs/fx 创建于 2026 年 8 月 11 日，8 月就已经以实验性质公开，10 月 22 日只是它第一次被媒体大规模注意到。截至发稿，仓库拿下 3555 个 star、401 个 fork，许可证是 Apache-2.0，状态栏里明晃晃写着一行警告：Experimental. Use at your own risk.

把时间线捋清楚很重要，因为这篇文章要讲的恰恰是：fx 从一开始就不是"又一个 AI 聊天窗口"，而是 Vercel 往 agent 基础设施层埋的一颗棋子。

先说清楚：fx 不是 10 月 22 日"首次发布"的

仓库的公开记录显示，fx 从 8 月中旬起就一直在迭代，目前已有 14 个 release、21 个 tag，提交数超过 3400 次。10 月初的 0.0.11 版本拓宽了模型接入选择，10 月 4 日的 0.0.13 又加了针对部分 OpenAI 模型的 Ultrafast 模式。10 月 22 日的媒体报道，本质上是外界第一次认真打量这个已经跑了两个多月的项目。

这种"先做后说"的节奏很 Vercel Labs：不开发布会，不写宣言，把东西扔到 GitHub 上让代码自己说话。看懂了这一点，才能理解 fx 一系列反常识的设计选择。顺带一提，媒体报道里"10 月 22 日开源"的说法并不准确——准确的表述是"8 月实验性公开，10 月 22 日首次被主流科技媒体集中报道"，本文以下所有时间线都按这个口径。

fx 到底是什么：一个 Zig 写的单二进制 agent

README 的第一句话就把调子定死了："fx is a minimal coding agent CLI that still comes with batteries included."（一个极简但开箱即用的 coding agent 命令行工具。）技术选型上，它用 Zig 写成，编译成单个 native 二进制，没有任何 runtime 依赖——装完就能在笔记本、CI、agent 沙箱里跑，行为完全一致。macOS 和 Linux、x86_64 和 arm64 全覆盖，一条命令装完：

curl -fsSL https://fx.sh/setup.sh | bash

Zig 在这里不是噱头。README 里有个细节很能说明问题：CI 流水线里有一条硬性门槛——如果 fx help 或 fx status --json 这类基准命令在 Linux 上耗时超过 2 毫秒，PR 直接失败。Apple silicon 的稳定版还要满足固定的体积上限。把启动速度和体积写进 CI 红线，这在 AI coding agent 里是罕见的——大多数 agent 还在纠结上下文窗口和工具调用成功率，fx 先把自己做成了一个"像 ls 一样快"的存在。

最关键的设计：对话输出进 scrollback，不接管屏幕

这是 fx 全文最值得细品的一句话："Its output is closer to a Unix shell than an IDE, because the conversation prints into your terminal's scrollback instead of filling the screen."

翻译一下：当下几乎所有终端 coding agent（Claude Code、Codex CLI、OpenCode）都是全屏 TUI——一启动就接管整个终端，接管你的滚动、接管你的复制粘贴、接管你的 tmux 快捷键。fx 反其道而行：对话内容像普通命令的输出一样，直接打印进终端的 scrollback，你可以滚动、搜索、复制，就像对待 git log 的输出一样，tmux 的绑定和 copy mode 照常工作。

这不是审美偏好，是哲学分歧。全屏 TUI 的逻辑是"agent 是你的新 IDE"；scrollback 的逻辑是"agent 是你的新 shell 命令"。Unix 的传统智慧是：程序做好一件事，把输出变成文本，让管道去组合。fx 把自己定位成 Unix 工具箱里的一员，而不是一个要独占你注意力的应用。这种选择在 vibe coding 时代有深意——当 agent 越来越多地跑在 CI、跑在沙箱、跑在脚本里时，一个不抢屏幕、不污染终端状态、可被管道组合的 agent，比一个漂亮的全屏界面实用得多。

当然代价也明显：Hacker News 上的早期反馈里，就有人拿它跟 OpenCode 对比，结论是 fx "cool but not polished"（有意思，但不够精致）。Vercel 显然知道自己在放弃什么——它赌的是，agent 的未来不在"更好看的聊天框"，而在"更顺手的管道件"。

三个嵌入面：fx 真正的野心

README 里有一个专门的章节叫 "Embed and extend"（嵌入与扩展），这是理解 fx 的钥匙。Vercel 不想让你"打开 fx 开始聊天"，它想让你把 fx 嵌进你已有的东西里：

• fx ask——给脚本和 CI 用的"一句话任务"接口。fx ask "summarize the failing tests" 直接在 shell 里拿到答案，加 --json 输出结构化结果，| jq -r .final_output 就能进管道。对 coding agent 来说，这意味着 fx 可以被其他 agent 调用：文档里甚至专门写了"For coding agents"一节，教别的 agent 怎么用 fx ask、fx status --json、fx doctor --json 来检查环境。
• fx acp——通过 Agent Client Protocol 走 stdio 接编辑器。编辑器不用为 fx 写插件，只要会说 ACP，就能连上这个 agent 后端。
• libfx——把 agent 核心做成 JavaScript 库，形态是 native Node.js addon 加 WebAssembly 构建。createFxAgent() 让 JS 应用带着自己的 tools、MCP 客户端和 skills 跑起同一个 agent 核心，createFxTerminal() 则把 fx 终端嵌进去。仓库的 examples/ 里已经有 node-chat、browser-agent（WASM 跑在纯 HTML 表单后面）、nextjs-agent、nuxt-agent 四个可运行的例子。

看清楚这个布局：CLI 只是 fx 的三张脸之一，另外两张分别对着编辑器生态和 JS 应用生态。Vercel 还把 fx 放进了自家 AI SDK 的 harness 层，跟 Claude Code、Cline、Codex、Cursor、OpenCode、Pi 并列——定位是"共享接口后面的可选项之一"，而不是要替代谁。

这就是标题里"为什么 Vercel 不做又一个聊天窗口"的答案：Vercel 在做 agent 时代的引擎供应商。聊天窗口已经够多了，缺的是能被嵌进任何地方的、可被脚本调用的、不挑模型的 agent 核心。fx 就是 Vercel 对"agent 引擎应该长什么样"的一次开源下注。

模型选择：真开放，还是"Vercel 优先"？

README 列出的模型接入方式相当慷慨：登录 Vercel AI Gateway，或者用 ChatGPT / Grok 订阅登录，或者连任何 OpenAI-compatible 的 Chat Completions 端点（Ollama、OpenRouter 都在列）。纸面上这是 model-agnostic 的典范。

但 Hacker News 的早期用户不买账：有人实测发现，默认的配置流程会把推理引向 Vercel AI Gateway。有评论者一针见血：fx 是个"通往 Vercel AI 的入口"。这话不算冤枉——Vercel 毕竟是家要赚钱的公司，AI Gateway 是它的计费管道；但也不算实锤"假开放"，因为 Ollama 本地模型和 OpenRouter 确实能接，README 也写得明明白白。

我的判断是：把 fx 理解成"开放核心 + Vercel 优先的默认路径"。这和当年 Chrome 与 Google 搜索的关系类似——开源是真的，默认选项的商业倾斜也是真的。对 vibe coding 的实践者来说，关键问题只有一个：你的工作流里，fx 是可替换的零件，还是越用越离不开 Vercel 生态的入口？目前看，前者的证据更充分一些，但值得持续观察 Vercel 会不会在后续版本里让默认路径越来越"顺滑地"滑向自家网关。

权限三档：把安全做成显式选择

fx 的权限模型值得单独说，因为它比很多 agent 想得周到。默认是 auto 模式：改项目文件、跑测试这类常规操作直接执行不打扰；其他动作先过一个专门检查 prompt injection 和恶意行为的模型，有问题就拦住。想自己逐条审批就切 ask，想全关就切 full-access（文档明确警告：只有用户明确要求才用 --full-access）。

这个设计的聪明之处在于，它没有把安全做成"一刀切的开关"，而是做成了三档显式选择。auto 档那个"用模型来审查动作"的思路尤其有 vibe coding 时代的特色——用 AI 来管 AI 的行为边界。当然，审查模型本身的可靠性、误拦率，README 里没有数据，这部分只能等社区实测。

配套的还有 AGENTS.md 支持（支持嵌套目录的 AGENTS.md 和全局 ~/.fx/AGENTS.md）、skills（从 .fx/skills、~/.fx/skills 加载，还兼容 .claude/skills、.agents/skills，技能按需加载以省上下文）、MCP 服务器管理、subagents 委派，以及存在 ~/.fx/sessions/ 下的会话管理（上下文满了自动压缩旧轮次，但全文保留在磁盘上可查）。生态位的拼图是全的——fx 不是个 demo，是个认真想被长期用的工具。

为什么是 Zig？一次不跟风的技术选型

2026 年写一个 CLI agent，主流选择是 Go（OpenCode）、Rust 或者干脆 TypeScript 打包。Vercel 选了 Zig——一个连 1.0 都还没到的语言。构建只需要 Zig 0.17.0，一条 zig build 就出二进制，源码目录分得干干净净：src/core 放 agent 主循环、会话、配置、权限、MCP、skills，src/acp 放协议服务器，sdk/ 放 libfx，benchmarks/、tests/e2e 各就其位。

这个选择有两层含义。表层是工程性的：Zig 的 comptime 和显式内存管理天生适合"小而快"的目标，没有 GC 停顿，没有 runtime 包袱，交叉编译是语言级一等公民——macOS/Linux × x86_64/arm64 四个目标一次搞定。深层是信号性的：Vercel 在用技术选型声明 fx 的定位。选 TypeScript 意味着"我们是应用开发者顺手做的工具"；选 Zig 意味着"我们是来做系统级基础设施的"。一个连语言都不跟风的团队，大概率也不会跟风去做第 37 个聊天窗口。

当然风险也在这儿：Zig 生态的库、人才、长期稳定性都不如 Go/Rust。Vercel 敢赌，说明它对 fx 的投入是战略级的——没人会拿一个实验性小玩具去赌一门小众语言的全部工具链。

横向对比：fx 和 OpenCode、Claude Code 到底差在哪

HN 评论区出现频率最高的比较对象是 OpenCode。把两者并排放，差异几乎是镜像的：

• 交互哲学：OpenCode 是精致的全屏 TUI，fx 是裸的 scrollback。前者把终端变成 IDE，后者把 agent 变成 shell 命令。
• 语言与体积：OpenCode 是 TypeScript/Bun 系，fx 是 Zig 单二进制，启动速度和体积不在一个量级。
• 扩展方式：两者都支持 MCP 和 skills，但 fx 额外给了 ACP 协议接入和 libfx（Node addon + WASM）两条路，嵌入的颗粒度更细。
• 模型策略：OpenCode 主打"用你自己的 key，接任何模型"；fx 纸面同样开放，但默认路径明显向 Vercel AI Gateway 倾斜。

和 Claude Code 比，差异则是代际性的：Claude Code 是"Anthropic 亲儿子"，模型、工具、界面深度绑定，体验打磨到极致，但你基本跑不出 Anthropic 的轨道；fx 是"无主之地"，模型可换、界面可换、甚至整个 agent 核心都能被你嵌进自己的 JS 应用里。一个是精装修的样板间，一个是毛坯但水电全通的框架房。你要拎包入住还是自己装修，取决于你是谁。

对 vibe coding 的普通实践者，我的建议很直接：日常写代码，Claude Code/OpenCode 的体验目前仍然更顺；但如果你在搭自动化的编码流水线——CI 里跑 agent 修测试、定时任务里让 agent 整理文档、把 agent 嵌进自家产品的某个角落——fx 的 fx ask --json 和单二进制形态是目前最顺手的选项之一。工具选型没有银弹，只有场景适配。

Vercel 的拼图：Gateway、AI SDK、fx

把 fx 放回 Vercel 的整体版图里看，意图就更明显了。过去一年 Vercel 布了三层：AI Gateway（模型接入与计费层）、AI SDK（应用开发框架层，harness 里已经并列了 Claude Code、Cursor、OpenCode 等）、fx（agent 执行引擎层）。三层的关系是：Gateway 赚钱，AI SDK 锁开发者，fx 负责把"能干活的 agent"变成可嵌入、可分发的标准件。

这是一个典型的平台型打法：不跟应用层拼体验，而是去定义 agent 的"发动机"长什么样。如果足够多的编辑器、CI 系统、JS 应用最后都选择用 fx（或兼容 fx 的接口）来跑 agent，那么 Vercel 就掌握了 agent 时代的一个关键 choke point——而默认的模型路径又恰好经过自家的 Gateway。开源是真诚的，商业算盘也是清楚的，两者并不矛盾。

这也是为什么 HN 上那句"fx 是通往 Vercel AI 的入口"值得认真对待，但不必过度解读。入口本身是开放的，门后通向哪条路，README 写得明明白白，选择权在用户手里。真正要警惕的是未来：如果 fx 的生态做大了，Vercel 会不会收紧"开放核心"的边界？这是所有"开放核心 + 商业网关"模式的终极考验，答案要两三年后才揭晓。

一个小插曲：撞名了

fx 这个名字，终端老用户可能觉得眼熟——没错，早就有一个用 Go 写的终端 JSON 查看器也叫 fx，而且它占着 Homebrew 的 fx formula。GitHub 上已经有人开了 issue 讨论这个命名冲突，贡献者确认"打包和命令共存方案正在评估中"。这是个小事，但很能说明 Vercel Labs 的做事风格：名字先占了再说，冲突后面慢慢解。experimental 项目的典型气质。

实战视角：fx 现在能干什么，不能干什么

抛开战略叙事，落到今天（2026 年 10 月 23 日）这个时间点，fx 的可用性画像是这样的：

现在就能用的：fx ask 进 CI 是最成熟的场景——测试挂了，让 agent 读失败日志、定位、修、再跑一遍，全程 --json 输出给流水线消费；fx -c 的会话续跑适合长任务；skills 和 MCP 的兼容（能直接吃 .claude/skills）意味着 Claude Code 老用户迁移成本很低；浏览器里还有个免安装 demo 可以先玩五分钟再决定。

要谨慎的：experimental 不是免责声明，是现状描述。0.0.13 的 changelog 里明确写了破坏性变更——新版 libfx 的检查点旧版本恢复不了，嵌入使用的要读迁移指南（createFxAgent() 改名 createFxEngine() 就是一例）。权限 auto 档依赖"模型审查动作"防 prompt injection，但误拦率、覆盖率没有任何公开数据，处理不可信输入的场景先别上生产。命名冲突还没解决，Homebrew 用户装的时候注意别跟 JSON 查看器 fx 打架。

值得等的：WASM 构建还标着 experimental，但 browser-agent 的例子已经证明了"agent 跑在浏览器里"的可行性——这条路走通了，意味着以后任何网页都能内嵌一个能写代码的 agent，而不需要后端服务。ACP 生态如果真有更多编辑器接入，fx 就有机会成为"编辑器无关的 agent 后端"标准件。这两件事，任意一件落地，fx 的估值逻辑都会变。

观点：fx 是 vibe coding 基础设施层的一块拼图

把以上事实拼在一起，fx 的画像就很清晰了：

第一，它赌的是"agent 作为基础设施"而不是"agent 作为应用"。当所有人都在做更好用的聊天界面时，Vercel 做了个更快、更小、更能被嵌入的东西。单二进制、无 runtime、2 毫秒启动红线、scrollback 输出、--json 管道、ACP 协议、WASM 构建——每一项设计都在说同一句话：我不是来当你的 IDE 的，我是来当你的管道件的。

第二，scrollback 哲学是对"IDE-in-terminal"潮流的一次纠偏。过去一年，终端 agent 越来越像 IDE：全屏、面板、快捷键、状态栏，越来越重。fx 提醒我们，Unix 传统里还有另一条路：小而快、输出即文本、可被组合。在 agent 大量跑进 CI 和沙箱的 2026 年，这条路可能比看起来更有生命力。

第三，experimental 是认真的，不是谦辞。README 顶部的警告、0.0.13 的 changelog 里"新版 libfx 检查点不能被旧版本恢复"的破坏性变更、还在评估中的命名冲突——都说明这东西还在剧烈演化。现在把它用进生产管线还太早，但作为"agent 引擎应该长什么样"的参考实现，它已经值得每一个做 agent 基础设施的人读一遍源码（Zig 0.17.0 就能构建，目录结构在 README 里列得清清楚楚）。

最后说句大实话：fx 会不会成功，很大程度上不取决于 Vercel，而取决于有多少编辑器和 JS 应用愿意把 ACP/libfx 当作 agent 后端接进去。协议和库的战争，从来都是生态的战争。Vercel 把引擎开源了，方向盘交给了社区——这步棋走得漂亮，但棋局才刚刚开始。

对中文 vibe coding 社区来说，fx 还有一层额外的参考价值：它证明了 agent 产品的差异化不一定要做在模型和 prompt 上。当所有人都在卷 system prompt 的写法、卷工具调用的成功率时，Vercel 从输出形态（scrollback）、分发形态（单二进制）、集成形态（ACP/libfx）三个维度做了差异化，每一刀都切在"agent 作为基础设施"的命脉上。这种"换维度竞争"的思路，比 fx 本身更值得抄作业——无论你是想做 agent 产品，还是想把 agent 嵌进自己的业务里，先问一句：我的 agent 一定要是个聊天窗口吗？fx 的回答是：不一定，而且可能不应该是。

本文基于 GitHub 仓库 vercel-labs/fx 的 README 与公开提交记录（亲核于 2026-10-23），Hacker News 反馈与命名冲突进展引自 10 月 22 日的二手报道。仓库状态为 experimental，功能与 API 可能随时变更。