為什麼市面上的 coding agent 多數跑在 Node.js 上：答案不在 AI，在「等待」

翻一下目前幾套主流 coding agent 的技術組成就會發現一個規律。2026 年 9 月 10 日一篇在掘金上的技術討論整理了這份名單：Kimi Code CLI 是 TypeScript 加 Node.js，DeepSeek Harness 同樣是 TypeScript 加 Node.js，Gemini CLI 與 Qwen Code 也主要跑在 Node.js 上，終端介面用的是 React 與 Ink 那一套。Claude Code 稍微不同，仍是 TypeScript，但執行環境換成了 Bun；OpenCode 走類似路線，終端層改用 SolidJS 和 OpenTUI。再往另一頭看，Codex CLI 的核心如今是 Rust，Aider 一直是 Python。所以嚴格說，coding agent 並非全是 Node.js 寫的，但 TypeScript 生態的佔比確實高得反常。

這件事乍看有點奇怪。AI 相關的東西，向來是 Python 的天下：模型訓練是 Python，RAG 是 Python，各種 agent framework 也有一大堆 Python 專案。為什麼到了真正安裝在開發者電腦上、每天實際幹活的 coding agent，反而經常看到 Node.js？這篇科普把機制拆開講。

Agent 本地真正忙的，不是算模型

先想一個典型場景。你對 agent 說：幫我看看為什麼登入介面偶爾回傳 500，修掉之後把測試也補上。

模型當然要參與，但本地 agent 要做的事遠比呼叫一次模型多。它可能先掃專案目錄，搜尋登入相關程式碼，再打開幾個檔案。模型判斷可能是資料庫查詢的問題，於是 agent 修改程式碼，接著執行測試。測試失敗後，它還要讀取終端輸出，把錯誤訊息交回給模型。模型重新判斷之後，也許又讓它看另一個檔案，或執行一條 Git 指令。

所以一次 coding agent 任務，實際上是在不停循環：讀檔案、寫檔案、搜程式碼、請求模型、執行指令、接收輸出、再請求模型。這些工作裡，絕大多數都不是計算密集型任務，而是在等待。等磁碟、等網路、等模型回應、等測試跑完、等一個外部程序回傳結果。

用日常一點的比喻：agent 比較像一個在廚房裡同時顧三口鍋的廚師，水滾了關火、烤箱響了開箱、旁邊還在切菜。它的工作不是一口氣從頭算到尾，而是「某個結果回來了，就推進一點；又有新輸出了，再處理一點」。

Node.js 擅長的，剛好就是這種到處都在等的程式

Node.js 最經典的特色是非同步 I/O。在一般後端服務裡，這個特色常用來處理大量網路請求；放到 coding agent 裡同樣合用，只是等待的對象變了。

Agent 發出模型請求之後，可以繼續處理其他事件。測試程序跑起來後，可以一邊接收 stdout 與 stderr，一邊更新終端介面。使用者突然按 Ctrl+C，也得立刻處理取消。如果有多個工具同時工作，agent 還可能同時等待好幾個不同的結果。

Node.js 的事件循環、Promise、Stream、檔案系統 API、子程序 API，本來就是為這類事件驅動的程式設計的。這是兩者合拍的第一個原因。寫過瀏覽器前端的人對這套心智模型一點都不陌生，工程團隊把 agent 當成一種「終端機上的互動式應用」來開發，門檻自然低。

Agent 不需要自己實作 Git 和測試工具

還有一個容易忽略的地方：coding agent 會執行很多開發工具，但它自己不需要實作這些工具。

例如跑 pnpm test，真正執行測試的是 Vitest、Jest 或其他測試框架，agent 只負責把這個程序啟動起來、接收輸出、看退出碼是不是 0。執行 git diff 也一樣，Git 自己完成計算，agent 只負責呼叫並讀取結果。Node.js 做這些事非常順手，因為它本身就有完整的子程序能力，child_process 模組拿來啟動外部工具、串流輸出，都是幾行程式碼的事。

更現實的一層是生態貼合度。coding agent 的使用者是開發者，而前端與全端開發者的工具鏈，從 npm、pnpm 到各種套件管理與腳本，本來就長在 JavaScript 生態上。agent 要讀懂 package.json、要解析專案結構、要和這套工具鏈無縫接軌，用同一套語言與執行環境來寫，省下的力氣相當可觀。

Bun 與 Rust 的出現，說明重點是「等待模型」而非語言本身

名單裡的變化也值得注意。Claude Code 與 OpenCode 選擇 Bun，看中的是更快的啟動速度與更好的 TypeScript 支援，但程式語言與開發體驗仍是同一套。Codex CLI 把核心換成 Rust，則是另一種取捨：當工具需要極致效能與穩定的資源佔用時，系統語言有它的位置。Aider 留在 Python，方便直接喫 AI 生態的各種套件。

這些分歧說明，「TypeScript 加 Node.js」不是唯一解，而是目前性價比很高的一條路：團隊找得到大量熟悉這套生態的工程師、非同步模型天然貼合 agent 的工作形態、終端介面有現成的 React 與 Ink 可以組裝。

這也與我們先前分析過的GPT-6 上線後模型選單變長、工作分配變難的趨勢相互呼應：當模型端選項愈來愈多、agent 要同時管理多個請求與多種工具時，執行環境的並發與協調能力就愈重要。而在 agent 數量本身開始爆炸的另一端，像Casbin Gateway 這類把多個編程 agent 收進同一個面板的管理工具出現，同樣反映了協調與等待，正在成為這個品類的核心工程問題。

所以呢：對開發者的實際意義

對一般開發者來說，這個現象的啟示有幾個層面。第一，判斷一套 coding agent 的優劣，語言選擇本身不是重點，重要的是它怎麼處理非同步任務、取消、以及外部程序的輸出串流，這些才是日常使用體驗的來源。第二，如果團隊想自己組裝或客製化 agent，TypeScript 生態目前是零件最齊全的五金行，從終端 UI 到子程序管理都有現成方案。第三，這個格局不是固定的，Bun 的竄起與 Rust 核心的出現都顯示，當需求從「快速做出產品」移向「穩定與效能」，技術選擇會跟著移動。

說到底，coding agent 之所以像個 Node.js 專案，是因為它本質上更像一個開發工具，而不是一個 AI 專案。AI 在雲端，等待在本地，而 Node.js 這類環境，剛好就是為「等很多事、同時處理很多事」而生的。