開源 agentic IDE 之戰：Emdash vs gstack vs Cursor

2026 年嘅 agentic IDE 戰場，表面上係 Cursor 嘅天下，實際上場仗根本未打完——因為贏嘅唔係最好嘅產品，而係最低阻力嘅入口。Cursor 嘅成功唔係佢嘅 agent 最聰明，而係佢將 AI 塞入一個開發者已經用慣嘅界面，令 adoption barrier 低到幾乎不存在。但呢個恰恰係佢嘅天花板：當你嘅設計哲學係「唔好嚇親用戶」，你就注定做唔到真正顛覆性嘅 agentic workflow。而 Emdash 同 gstack 分別用兩種完全相反嘅方式，緊迫呢個天花板嘅極限。

Cursor：舒適區嘅詛咒

Cursor 揀咗一條最安全亦最聰明嘅路：fork VS Code，保留成個編輯器生態圈，然後喺上面疊加 AI 功能。呢個決定令佢哋快速累積用戶，但同時注定 architecture 永遠被 VS Code 嘅 fundamental assumptions 綁死。VS Code 由底層到 API 都係為咗「人逐行寫 code」而設計嘅——檔案樹、編輯器 model、extension system、甚至 LSP 嘅 request-response 模型，全部假設操作主體係一個人類開發者。將 AI agent 嵌入呢個框架，就好似將噴射引擎裝落一架馬車：行到、快咗，但底盤承受唔到真正嘅 agentic 工作負載。

Cursor 嘅 Tab completion 同 inline editing 係出色嘅 UX 創新，佢哋識得喺開發者唔 interrupt 嘅前提下提供建議。但呢啲都係 pattern completion，唔係真正嘅 agentic reasoning。當你要 agent 做跨檔案重構、多步驟 task、或者理解成個 codebase 嘅 architecture 時，Cursor 嘅 agent mode 就開始露出破綻：context window 管理被動、tool call 嘅 scope 太細、多步驟 execution 容易迷失方向。呢啲唔係 bug，而係「將 agent 當做 editor feature」呢個 design philosophy 嘅必然產物。Cursor 喺 product 層面做得好出色，但佢哋嘅 ceiling 由呢個 fundamental choice 決定咗。

Emdash：agent-native 嘅代價

Emdash 行嘅係完全相反嘅路。Zingg 由零開始 build 一個真正 agent-native 嘅編輯器，唔 fork VS Code、唔妥協、唔兼容 legacy。Emdash 嘅核心假設好激進：code 唔再係由 developer 逐行輸入嘅產物，而係 developer 同 agent 之間對話嘅結果。Editor 嘅 primary interface 唔再係文字編輯區，而係一個 conversation panel。檔案系統、project tree、甚至 syntax highlighting 都變成 secondary。

呢個 vision 令人興奮，因為佢徹底擺脫咗「editor 係乜嘢」嘅前設。但代價亦好具體：冇 VS Code 生態圈，意味住冇 extension marketplace、冇成熟嘅 debugger、冇 ESLint/Prettier 直接整合。Emdash 嘅妥協係用 AI 嚟 compensate 呢啲缺失——例如用 AI code navigation 代替 symbol search，用 agent 自動修 formatting 代替 linting——但呢個 loop 有時會 self-reinforce 錯誤：當 AI 犯錯時，你冇傳統 tooling 做 cross-check，而 agent 又唔識得自己 detect 自己嘅錯誤。

Emdash 嘅設計哲學係「agent 行先，人跟隨」。呢個方向對 power user 同早期 adopter 嚟講好吸引，但對 mainstream developer 嚟講學習曲線太斜。某程度上，Emdash 嘅問題唔係技術問題，而係 timing 問題——agent 仲未 reliable 到可以完全取代傳統 tooling。但佢嘅方向係正確嘅：真正嘅 agentic IDE 唔可能由 VS Code fork 出來。

gstack：Unix 哲學嘅 agentic 實踐

gstack 代表嘅係第三條路——唔整一個 monolithic IDE，而係提供一組可以獨立使用嘅 agentic coding components。呢個 approach 嘅設計哲學直接繼承自 Unix：每個 tool 做好一件事，然後透過 pipe 組合。gstack 嘅 entries 包括 scout（codebase exploration agent）、agentic-coding（核心 coding agent），再加其他 modular tools。每個 component 可以獨立用，亦可以黐埋一齊。

呢個 modular design 嘅好處係 flexibility：你可以只用 scout 嚟做 code review batch job，或者將 agentic-coding 嵌落你現有嘅 Neovim/VS Code workflow。唔似得 Cursor 要你搬入去佢個 ecosystem，亦唔似得 Emdash 要你接受佢嘅全新 paradigm。gstack 俾你揀幾多 agentic capability 你想引入，同埋想喺邊個 layer 引入。

但 modular 嘅代價係 fragmentation。User experience 唔及 Cursor 咁 seamless，setup 門檻高啲，documentation 要覆蓋多個 component 嘅組合方式。gstack 嘅 target audience 係 infrastructure-aware 嘅 developer，唔係 download 完就用到嘅 mainstream user。呢個 tradeoff 喺早期係正確嘅——先 capture 最 demanding 嘅 users，再慢慢向下滲透——但要 mainstreaming 之前需要解決 UX 裂縫。

AgentOS 應該點行？

AgentOS 嘅 scout 同 agentic-coding entries 已經 show 咗方向：唔 bet 任何一個極端，而係揀一個 layered approach。底層用 gstack 嘅 modular components 做 infrastructure，上層透過 scout 提供 codebase understanding，agentic-coding 負責 execution。呢個設計哲學嘅核心 insight 係：agentic IDE 唔需要 reinvent the wheel，但亦唔可以俾 legacy architecture 綁死。

具體嚟講，scout 應該做個「agentic 入口點」——比 Cursor 嘅 project-level agent 更 deep 嘅 codebase understanding，但唔需要 Emdash 咁樣推翻成個 editor。Agentic-coding 則應該專注喺 execution layer：多步驟 task planning、cross-file refactoring、context window 嘅 intelligent management。呢兩個 entries 可以獨立用，亦可以黐埋一齊用——呢個 flexibility 就係 gstack philosophy 嘅實踐。

對香港嘅創業者同獨立開發者嚟講，我嘅建議係：唔好盲目跟 Cursor，因為佢嘅封閉生態最終會變成 vendor lock-in；亦唔好 rush 去 Emdash，因為 agent-native 嘅 vision 仲未成熟。而係 modular 地引入 agentic capability：先用 scout 做 codebase discovery 同 architecture understanding，再逐步用 agentic-coding 代替 repetitive coding tasks。AgentOS 嘅方向係正確嘅，但要贏呢場仗唔需要最快，而需要最 sustainable。