fx:小巧、开放、原生的编码 agent
文章摘要
fx.sh 是 Vercel Labs 推出的编码 agent 的官方站点。页面本身内容极简,主体是一个可直接在浏览器里试用的交互式 demo,加上一行安装命令 curl -fsSL https://fx.sh/setup.sh | bash,以及 docs / cli / lib / try / source / install 六个入口。撰稿时版本为 v0.0.7,二进制体积 6.19 MiB,状态标注为 experimental(实验性),并明确警告「使用风险自负,我们会频繁做出改动」,采用 Apache-2.0 许可证。
网页上的 demo 本身就是一个技术展示:它跑的是用 Zig 工具链编译成 WebAssembly 的完整 fx CLI,网络请求委托给浏览器的 fetch,工作区由 just-bash 提供,SDK 的每个方面都可在文档中配置。这个 demo 需要浏览器支持 WebAssembly JSPI,例如 Safari 27+ 和 Chrome。demo 中默认的模型显示为 auto · kimi-k3。
fx 的自我定位是这样一句话:一个用 Zig 编写的编码 agent harness(承载框架)和 CLI,为研究用途以及作为更大系统的一部分被嵌入而优化。它在各个层面追求极简与性能——从系统提示词的设计,到工具集、功能集,再到 6.19 MiB 的二进制体积。对终端用户而言,它的 CLI 输出风格和形态定位是更接近 Unix shell,而不是一个笨重的「终端里的 IDE」式 TUI。它开源、模型无关,同时适用于本地推理和云端推理。
站点罗列的九项特性构成了它的完整卖点:
- 约 6MB 的小巧二进制——为即时安装、以及嵌入资源受限环境和 agent 沙箱而设计。
- 即时可用——fx 冷启动仅需 10 微秒,在接受用户输入之前不做任何不必要的工作或 I/O,因此非常适合程序化调用。
- Wasm 支持——由 Zig 工具链产出优化的 fx.wasm 构建,进一步减小体积,并让网络栈可插拔。
- 极小内存占用——fx 本身只贡献个位数 MB 的内存基线,因此可以在一台机器上塞进很多个实例。
- shell 式的 UI 与人机工学——默认保留滚动历史,输出极少,尽量少用复杂 TUI 或重绘。
- 上下文高效——极小的系统提示词和工具集,既省 token 成本,也带来最优的首 token 时间(TTFT)。
- 可嵌入、可扩展——核心很小,通过 skills、plugins、MCP 扩展,遵循 Unix 式的可扩展性哲学。
- 模型与供应商无关——设计上可配合本地模型、网关、直连供应商 API 或订阅使用。
- 站点底部标注了 changelog、source、docs 三个链接,署名 Vercel Labs。
需要说明的是,站点正文极简,以下的 HN 讨论包含了大量站点本身没有讲清楚的信息,特别是它当前实际上只支持通过 Vercel AI Gateway 登录这一关键限制。
HN 评论精华
这条帖子拿到 318 分、约 125 条评论。讨论的真实走向值得先说明:它很快脱离了 fx 本身,变成了一场关于「为什么现在每天都有新的编码 agent」的元讨论,以及围绕 Vercel 品牌、Zig 二进制体积、「agent 与 harness 到底是不是一回事」的三场支线辩论。评价整体偏怀疑,唯一被广泛认可的差异化点是「可嵌入 + 可编译成 Wasm」。
- SmashDan 提出了引爆全场的问题(他自称不在科技行业):能不能解释一下为什么有这么多新的编码 agent、为什么它们在 HN 上总被顶上来?「感觉每隔一天前十里就有一个新的。」
- jdub 的回答被公认为最好:当一项新技术或新能力登上舞台,在「发明到扩散」的故事里会有一个时点——新东西变得足够便宜、足够容易,让更广泛的开发者群体可以拿来实验,但还没人摸清最佳实践,更谈不上打磨成型的产品,或者围绕某个市场领导者固化。「于是你会看到一场怪异小项目的寒武纪大爆发。」最终其中之一大概会成为市场领导者,或至少成为默认选项。他举了历史上的对应例子:文本编辑器、窗口管理器、IRC 客户端、博客引擎(先静态、后动态、又回到静态)、Twitter 客户端,每个编程语言社区历史上都有奇怪的库/框架重复造轮子的聚集期。「有时这些项目带有成人礼的味道——就像每个绝地武士都要造自己的光剑,每个开发者都要造自己的……博客?以前是这个,现在不太是了。」
- chrysoprace 给出了术语层面的澄清,也是理解这条帖的关键:如今围绕编码 agent 的讨论正转向 harness(这大概是对 fx 更准确的描述)。「Agent」这个词承担了太多含义,已经变成一个笼统术语,用来描述模型 + harness + 工具 + 提示词 + 其他一堆东西的组合。harness 是被探索得越来越多的那一部分,因为很多人相信这里还能压榨出更好的模型表现。他还点出利益关系:这个项目来自提供模型服务的 Vercel,所以他们有充分动机提供一个 harness。
- eikenberry 提供了另一个角度:很多人写自己的 harness,是为了得到一个自己理解、能随意改动的工具,所以喜欢分享出来看看别人怎么做、从中学习;「作为一个社区,我们离就『好的 harness 长什么样』达成共识还很远,而在我看来,唯一能真正找到感觉的办法就是自己写一个。」selectnull 的版本更犀利:「因为我们正处在淘金热中,而最好卖的是铲子。」selcuka 指出另一个成因:每家模型厂商都会发布自己的、为自家模型优化的编码 agent。
- rsyring 做了最扎实的一件事——他把网站上列的差异化点逐条摘出来回应那些问「为什么」的人,并指出:「特别是『可嵌入到其他项目』这一点相当值得注意,至少不是我记得的、上过 HN 首页的其他项目会强调的。」
- rvz 是最尖锐的反对者,他的两个问题定下了怀疑派的调子:「1. 我们为什么需要又一个编码 agent?2. 这会不会又是一个 Vercel Labs 的垃圾项目,像他们其他项目一样被抛弃,毕竟这是超级实验性的?」他后来进一步说这些卖点「不过是些微不足道的实现细节」,是一个「品牌化的 me-too 编码 agent」。他还暗示 HN 存在刷票团伙,ricardobeat 引用社区准则回怼(准则明确要求不要发关于刷票、水军的猜测),并指出这条提交当时投票数才 50 出头。
- impulser_ 是最激烈的批评,也提出了唯一一条针对具体设计的技术批评:「抱歉,但这纯属垃圾。这东西有 26 个工具,每一个文件操作都有一个工具,还有一个用来读取工具输出的工具?他们管这叫极简……造这个的人显然对 harness 理解很少。以今天模型的能力,你应该用少得多的工具。启动时间和二进制体积毫无疑问是评价一个 harness 最没用的指标。」他推荐用 Pi。maherbeg 部分认同但给出解释:一部分原因大概是要在网页和没有终端的其他设备上支持这套接口;bitpush 反驳说这有点苛刻——据他所知你没法把 Pi 嵌进网页(wasm),光这一点对 fx 就是巨大优势。
- 二进制体积成了一条热闹的支线。kgeist 提出质疑:为什么一个 Zig 写的程序会有这么大?它本质上只是一个接受用户输入、准备上下文、发给 LLM、解析输出、调用工具、在终端里展示的循环;加上内建提示词和一些检查,他预期一个真正微小的原生 agent 顶多 200–300 KB。wyre 提供了数据:仓库大约 60 万行 Zig,去掉注释和空行约 50 万行;他自己实验写的小型 Zig agent 不到 800KB。usef- 给出了行业对照(引自 Simon Willison):最近开源的 grok harness 是 84 万行、codex 95 万行、pi 25 万行。klibertp 做了最细致的技术分析:他用 Zig 编译过一个完整的 Win32 GUI 计算器(用了跨平台 GUI 框架 Capy)只有 133KB,直接用 Win32 API 更是只有 93KB,而同样任务 Rust + Slint 产出 4.7MB 且还依赖多个非系统自带的共享库;结合另一位提到的 Nim 项目产出 1.6MB,他的第一猜测是这个 6MB 的 Zig 二进制根本没有针对体积优化,可能是 debug 构建。nathan-hello 提供了实测:他 clone 仓库、用 Zig 0.16 跑
zig build,二进制是 144MB,strip 后 44MB,「离 6MB 差得远,是我姿势不对吗?」nateb2022 给出答案:在 macOS(zig 0.16.0)上用 ReleaseSmall 优化编译,他得到 5.8M。tecoholic 的观察很有趣:「tiny」对不同背景的人意义完全不同,他也以为会在 1MB 以下,看到 6MB 很意外。nine_k 的对照是:典型的 Go 二进制会大 2–3 倍,典型的 Node 项目光代码就轻松超过 6 MiB,还不算运行时。pjmlp 的标准最怀旧:「对我来说 tiny 意味着能装进一张 1.44MB 高密度软盘。」irishcoffee 的一句「太大?真的吗?容我向你介绍 Electron」也收获不少赞同。 - 「agent 还是 harness」的语义辩论由 bodge5000 发起,是全帖思辨性最强的一支:它自称是 agent harness,但标语写的是「小巧、开放、原生的编码 agent」,这两个词该混用吗?他觉得 agent 应该是干活的那个东西,harness 是用户与 agent 交互的方式——我们以前有过描述这种关系的词:客户端与服务端、前端与后端。cramforce 给出了最简洁的定义:「Harness = agent 运行其上的软件,这就是普通软件,你可以像信任任何软件一样信任它。Agent = 跑在 harness 上的东西,它不可信,因为它由 LLM 驱动。」amdahl 换了个说法:harness 是一个「物」(代码/二进制),agent 是一个「过程」(该代码搭配特定 LLM/环境的一次实例化运行)——就像《GTA 6》的光盘 vs. 你正在被警察追的那一局;「实践中两者纠缠在一起、很难不混用,但『你问 agent 这个 harness 怎么工作』和反过来说,区别是清楚的。」bodge5000 继续追问光盘在这个类比里难道不该是模型吗,amdahl 又改进了一版:LLM 是玩家,被实例化为某一局游戏中的 agent;GTA 6 的虚拟世界其实是你的代码库/环境,追你的警察是 bug 和愤怒的客户;harness 提供的是让模型准确高效地理解和操作这个虚拟世界的能力。stellalo 的公式最短:harness + llm = agent。verdverm 推荐了 Scion(一位 Google 开发者做的、类 OpenClaw 平台,非公司支持)的三分法:model / harness(工具与配置)/ agent(活的、运行中的)。
- Vercel 绑定是最实际的批评焦点。konaraddi 问文档似乎暗示只能配 Vercel 的 AI Gateway、能不能换别的供应商。abhikul0:「本地推理?我看除了注册 Vercel 账号没有别的路,那算了。」elux101:「以 Vercel 作为唯一推理供应商,这个项目就没用了。」codethief 说他本来很兴奋,直到在 GitHub README 里看到「要开始使用,请用 fx login 登录 Vercel」。mellosouls 说需要信用卡(Vercel AI Gateway)且没有说清怎么避免被扣费,这是「一个大大的不」。miki21211 说他花了 5 分钟仍没搞明白怎么用自己的订阅/直连 API key 登录,「他们声称可以,但引导流程彻底坏了」。verdverm 的顾虑更结构性:「它有没有任何围绕 Vercel 基础设施协同设计的东西?NextJS 就是这么变质的,所以我大概再也不会碰 Vercel 的开源项目了。」fazxes(看起来是项目方)回复说「订阅支持(Codex、Grok)正在路上」。gip 则给了正面的实测反馈:试了一下,虽然没那么打磨也不算快,但很酷,GLM 5.2 即使用免费 Vercel 账号也完全免费——「商业上也说得通,fx 是把更多用户带到 Vercel AI 的入口。」vehemenz 的话最能代表另一类用户:「登录 Vercel?我都不知道 Vercel 是什么。能登录 Codex,却没有 Claude Code?无论这软件多好,它都不会被主流采纳。」
- 帖子里冒出了一批竞品自荐与推荐,实际构成了一份当下的极简 harness 清单:OleksandrC 自荐 hax(usehax.dev,C 编写,动态链接二进制仅 0.6MB,MIT 许可,无 wasm),并点出关键差异——fx 目前只支持 Vercel AI Gateway,而 hax 已支持多家供应商(OpenAI API、ChatGPT/Codex 订阅、Anthropic API、OpenRouter、OpenCode Zen/Go)并能开箱即用地对接本地 llama-server。有人问他会不会支持 Claude Pro/Max 订阅,他的回答是技术上很直接,但 Anthropic 似乎强烈反对用 Claude 订阅配合非 Claude Code 的工具,这样做甚至可能导致账号被封。miguel_martin 推荐 3code(Nim 编写,1.6MiB)。ryuuseijin 推荐 Maki(maki.sh,Rust 编写,启动和渲染极快,实现了省 token 技术,插件用 Lua 写);Imustaskforhelp 说他在 500MB 和 1GB 内存的小 VPS 上用 Maki,而 opencode 有时会 OOM;pynappo 说 Maki 遵守 XDG 规范(不像 pi),UI 灵敏,Lua API 有意做得接近 neovim。alexboehm 贴出了自己手写的 C 版本(唯一依赖是 libcurl),二进制约 40KB、内存占用远低于 fx,他说自己也曾试图让 agent 写这样一个工具,但没有 ratatui 这类框架时它们总是搞砸原始模式的粘贴/中断处理。JSR_FDED 则搬来了一个 9 行 Python 的极简 agent 循环作为终极对照。
- jauntywundrkind 给出了对当下 harness 潮流最有热情的一段观察:「小核心」模式突然变得非常流行,DeepSeek 的新 harness 就以此闻名;OpenCode 也在刻意把更多东西推进插件体系,他引用 Dax 的说法——opencode2 的架构变化是几乎一切都是内部插件,有 68 个之多,涵盖内建 agent、集成、配置加载等;另一个他觉得绝妙的设计是「OpenCode 是我第一次能在真实系统里说服自己用事件溯源的场合,发生的每件事都是一个事件,投影进 sqlite 库」。他的总结带着少见的乐观:「看到新的可塑软件内核涌现真有意思——agentic 软件自身在努力扩展它所提供的能动性。我们太久没有过建造通用系统的野心了,这种服务于用户之外更多对象的架构。」
- cmrdporcupine 提出了一个不少人共鸣的疑问:他最近一直在想,为什么编码 agent 的功能不干脆已经是我 shell 的一部分?作为现有 shell 的另一种交互模态,甚至可以做成 fish 或 nu-shell 的扩展。「不过请阻止我又开一个新项目。」rsyring 指出 Warp 最初就是在做这件事(重新想象终端并把 AI 变成其中一部分),但似乎没站稳,最后不得不把它做成一个平台。
- vhantz 引出了本帖最欢乐的支线:「我很好奇『curl 一个任意脚本管道给 bash』这种分发方式还能持续多久。」roywiggins 的回答是全帖最佳段子:「不会太久了。我们正在过渡到——让你的 LLM curl 一个任意的 markdown 文件,然后照着上面说的做。」wren6991 接力:「未来所有软件都将由一个未发布的模型突破其训练环境、用一个新颖的 RCE 向量安装到你机器上来分发。」cfiggers 下了个赌注:如果 40 年后(2066 年 8 月 18 日)这还不是通行做法,他给第一个引用这条评论来挑战他的人 1 美元。
- 少数正面评价也值得记录:Kim_Bruning 说「页面上的 demo 对我来说非常直观(至少如果你习惯 bash 的话)」;mparramon 说 UX 上相当极简,这看起来正是他们的差异化之一,「我挺喜欢的」;smy20011 说他本来想做一模一样的东西,「我只需要一个开关极快、又不吃掉半个 GB 内存的 agent」;messh 提供了体积为什么重要的具体理由:很多人说既然是调用云端 LLM,6MB 和 Claude Code 的 250MB 有什么区别,但他经常一次跑 50 到 100 个层级化的 agent,「650 和 25050 之间,是『能做』和『做不了』的区别」。pdp 的总结代表了中间派:「这可能听着刺耳,但在我看来这个项目唯一有意思的地方就是它是用 Zig 写的。其他一切基本相同,只是换了 Vercel 味。」——不过他紧接着补了一句:「话说回来,你刚说 GLM 5.2 免费?我得去看看。」
- 最后一条冷知识来自 parisiansam:这里有个命名冲突,他喜欢的那个 fx 是 JSON 查看器(GitHub 上 20.6k star)。NetOpWibby 则说他最佩服的是这个域名。