從全螢幕終端機轉向可組合的引擎
過去兩年，終端機裡的編碼代理（coding agent，指能自行讀取程式碼、呼叫工具、修改檔案並執行指令的模型驅動程式）大致形成一種介面慣例：開啟全螢幕介面、佔住整個終端機視窗、用固定面板呈現對話與工具呼叫結果。這種設計對人手操作很直覺，卻也把代理綁在「人坐在終端機前」的情境裡。當團隊想把代理接進腳本、CI 流程或其他應用程式時，往往得繞過這層介面。Vercel Labs 在 2026 年 8 月公布、並於 10 月以開源形式釋出的 fx，正是針對這個落差提出的實驗性專案；Vercel 本身是 Next.js 框架與其網站建置部署平台背後的公司，Vercel Labs 則是其內部的實驗團隊。InfoQ 的 Daniel Curtis 在 10 月 22 日的報導中指出，fx 是一套以 Zig 撰寫的編碼代理與命令列工具，設計目標是「被腳本化或被嵌入」，而不是成為另一個全螢幕終端機應用。
以 Zig 換取的小體積與啟動速度
依 Vercel 公布的數字，fx 以單一原生二進位檔形式釋出，大小約 6.3 MiB，記憶體基準線落在個位數 MB，冷啟動時間約 10 微秒。這些數據由 Vercel 自行提供，報導也註明未經第三方獨立驗證，因此適合當作量級參考，而非精確基準。真正值得注意的是取捨背後的邏輯：專案選擇 Zig 這門語言。Zig 是一種主打明確記憶體控制、可編譯出精簡原生執行檔、並能與 C 生態互通的小型系統程式語言，用它來換取啟動成本極低的執行檔，對「每次工具呼叫、每個管線階段都重新啟動一次程式」的場景格外有意義。在這種使用模式下，啟動延遲與常駐記憶體往往比模型能力更早成為瓶頸。
同一顆引擎的三種接法
fx 在互動模式下的行為與多數代理不同：它不接管終端機畫面，而是把對話直接寫進終端機的一般回捲緩衝區（scrollback），也就是使用者平常往上捲動就能看到的歷史輸出。這麼做的好處是與既有 shell 工作流不衝突，輸出可被複製、可被既有工具擷取，代理看起來更像一個普通的命令列程式。同一個引擎同時以兩種形式對外：命令列工具與函式庫。自動化場景可要求結構化輸出，例如以 fx ask --json "summarise the failing tests" 取得可直接解析的回應，讓腳本或 CI 工作判斷結果；編輯器則可透過 Agent Client Protocol（ACP，一套讓編輯器與代理交換訊息、工具呼叫與工作階段狀態的協定）以 fx acp 附掛上來。libfx 則把引擎暴露給 JavaScript，並提供 WebAssembly 建置。WebAssembly 是一種可在瀏覽器與多種執行環境中執行的低階位元碼格式，意味著代理能力可以被放進網頁或跨平台環境，而不必假設使用者已安裝終端機工具。
模型路由的爭議與命名衝突
專案釋出後在 Hacker News 上的討論集中在兩個問題。其一是「與模型無關」的說法：部分首次使用者回報，設定流程似乎把推論導向 Vercel AI Gateway，因而質疑代理是否真能自由替換後端模型；也有人拿 OpenCode 較成熟的終端機體驗作對照，問 fx 的差異化在哪裡。另一派看法則認為，fx 對 Vercel 的商業意義在於成為進入 Vercel AI 的入口。這些質疑後續獲得一定程度的回應：0.0.11 版加入具名的 OpenAI 相容連線設定，可指向本機伺服器與其他閘道，README 也列出 Vercel AI Gateway、ChatGPT 與 Grok 訂閱，以及 Ollama、OpenRouter 等端點。在生態定位上，Vercel 把 fx 放進自家 AI SDK 的 harness 層，與 Claude Code、Cline、Codex、Cursor、OpenCode、Pi 並列，作為共用介面後面的其中一個選項。這種排列透露一種態度：編碼代理逐漸被視為可替換的元件，而非各自為政的產品。
另一個更實務的問題是命名。GitHub 上有人指出 fx 與長期存在的終端機 JSON 檢視器 fx 撞名，後者已佔用 Homebrew 的 fx formula；有貢獻者回應表示封裝方式與指令共存問題正在檢視。對想嘗試的人來說，安裝路徑與指令衝突往往比功能更早成為門檻。
0.0.x 階段的速度與相容性代價
Vercel 明確把 fx 標示為實驗性專案。10 月 4 日釋出的 0.0.13 版為支援的 OpenAI 模型加入 Ultrafast 模式，加快啟動與 shell 呼叫，但同時警告新寫入的 libfx checkpoint 無法由舊版本還原。命令列使用者可透過 fx upgrade 升級，並應先讀 changelog；嵌入式使用者則需查閱 libfx 遷移指南，其中說明早期文件裡的 createFxAgent() 在現行版本對應到 createFxEngine()。這種函式更名與存檔格式不相容，是 pre-1.0 階段的常態，但也意味著把它放進產品前，得先接受升級成本。專案倉庫已文件化 CLI、skills、MCP（Model Context Protocol，讓模型以標準化方式取得外部工具與資料的協定）、權限與 SDK，並提供無需安裝的瀏覽器示範，讓人在不下載二進位檔的情況下先看終端機風格的互動樣貌。
把編碼代理當成基礎設施的一部分
放回產業脈絡看，fx 反映的是一種正在成形的做法：編碼代理不再只是「一個給你聊天與改程式的視窗」，而是像編譯器或 linter 一樣，被視為可被呼叫、可被組合、可被嵌入流程的基礎設施。這個方向對 CI、批次重構、編輯器整合與多代理協作特別有意義，因為這些場景要的是可預期的輸入輸出與低啟動成本，而不是漂亮的面板。
限制同樣清楚。專案仍在 0.0.x，API 與存檔格式會變動；效能數字來自廠商自述；模型路由與供應商中立性仍需時間驗證；與既有工具的命名衝突尚未解決；六點三 MiB 的體積與微秒級啟動，是否真能轉化為實際工作流的順暢度，也取決於模型延遲這個更難壓縮的變數。對評估者而言，較合理的期待是把它當成觀察「代理如何被基礎設施化」的樣本，而不是立刻取代現有工作流的核心工具。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。