Libghostty 正在成為 agent 工作流的終端底座

Libghostty 正在成為終端機與 AI agent 工作空間的共同底層。

我認為，Libghostty 已經不只是終端機引擎，而是新一代原生應用、網頁終端與 AI agent 工作區的基礎層；這不是概念炒作，而是生態已經長出來的結果。awesome-libghostty 已列出 Rust、Swift、Go、Dart、.NET、Node、Python、Elixir、Zig 等多種綁定，且同時出現 macOS、Linux、Android、iOS、瀏覽器與編輯器內嵌終端案例，這種橫跨語言與平台的擴散，通常只會發生在真正被當成底層基建的技術上。

第一個論點

第一個證據是「採用面夠廣」。一個核心庫若只是好玩，通常只會在單一語言社群裡被包裝成 wrapper；但 libghostty 的綁定清單已經跨到至少 11 種語言，從 Rust 到 MoonBit 都有人做，這代表需求不是零星個案，而是各自都想把同一個渲染核心塞進自己的產品裡。

更關鍵的是，這些專案不是同質化複製。你可以看到原生 macOS 終端、Linux SSH 工具、iOS 連線客戶端、瀏覽器終端與筆記本中的嵌入式 pane 同時存在。這說明 libghostty 吃到的不是單一 OS 的紅利，而是「終端能力要被嵌入到更多工作流」這個更大的需求。

第二個論點

第二個證據是 AI agent 工作流正在把終端變成操作介面，而不是純輸入輸出視窗。像 Supacode、taskers、Forge、AiyuTerm、Factory Floor 這類專案，重點都不是做一個更漂亮的 shell，而是讓多個 coding agent 並行跑、保留長時間 session、顯示每個 agent 的狀態，這已經是新的產品類別。

這類工作流對底層要求很苛刻。它需要分割視窗、持久狀態、SSH、類 tmux 的控制、worktree 感知，以及快速可視化回饋。以往這些能力要自己拼，成本高、錯誤多；現在若有一個庫能直接承接這些需求，就不只是「能顯示字」，而是在定義 agent 時代的操作層。這也是為什麼 libghostty 會被反覆選中。

反方可能怎麼說

最強的反方論點很直接：awesome list 不等於真實採用。GitHub 清單常常放大熱度，很多專案只是早期試驗，最後不是停更，就是停留在 demo。從這個角度看，libghostty 的生態繁榮，可能只是開發者好奇心旺盛，而不是市場已經下注。

這個質疑成立，尤其如果你只看 star 或 README，確實容易高估成熟度。但它忽略了一個更硬的訊號：不同團隊在不同平台上，卻反覆選擇同一個終端核心，原因不是潮流，而是它已經替他們省掉最難重寫的部分。就算一部分專案最後失敗，這種跨語言、跨場景的集中度，仍然足以證明 libghostty 已經站上共享基礎層的位置。

你能做什麼

如果你是工程師，把 libghostty 當成終端渲染、內嵌 shell、agent workspace 的預設選項，而不是實驗性依賴；如果你是 PM 或創辦人，別再從「做一個新終端」出發，而是從「誰需要同時管理多個 agent、長 session、worktree 與遠端連線」出發。真正的機會不在重造 terminal，而在 terminal 之上搶下工作流層。