Buda vs Zed：Agent 原生編輯器，還是公司營運工作空間？
Zed 已不只是一款帶 AI 面板的高速程式碼編輯器。目前官方文件定義三條 Agent 路徑：原生 Zed Agent、透過 ACP 接入的 External Agent，以及承載原生 CLI/TUI 的 Terminal Thread。它還包括平行 Thread、Git worktree 隔離、內建工具、MCP、Skills、Instructions、工具權限、Checkpoint 與逐塊程式碼審核。
因此「編輯器 vs 工作流」的淺層比較已不準確。Zed 本身就是面向軟體開發的 Agent 工作環境：運行多個 Thread、使用不同 Agent、為每項任務保留獨立脈絡，並讓開發者不離開編輯器就能檢查變更。
Buda 的差異出現在這個中心之外。它是一套用於週期公司工作的雲端 Agent 工作空間，程式碼可能只是 Drive 檔案、網頁研究、客戶記錄、報告、草稿與營運決定中的一項來源。真正的採購問題是：團隊需要 Agent 原生的軟體開發環境，還是橫跨公司職能、由 Agent 與人共同使用的共享營運工作空間？
兩邊都組織 Agent，但真相來源不同
| 決策維度 | Zed | Buda |
|---|---|---|
| 主要真相來源 | 專案檔案、編輯器 Buffer、Thread、worktree、diff 與 Git | 共享 Drive 脈絡、Agent Session、產物、Owner、狀態與執行歷史 |
| Agent 路徑 | 原生 Zed Agent、ACP External Agent 與 Terminal Thread | 帶工作空間工具、Skills、自動化與 Channels 的專業長期 Agent |
| 平行工作 | 獨立 Thread、Project、Agent 與 Git worktree | 橫跨技術與業務職能的不同 Agent 角色與流程 |
| 審核 | Checkpoint、檔案列表、diff、逐塊接受/拒絕、工具權限 | 可審閱的簡報、草稿、報告、表格、CRM 更新、PR 說明與決策包 |
| 自然使用者 | 貼近程式碼工作的開發者或技術團隊 | 運行週期工作且需要明確交接的跨職能團隊 |
沒有哪一欄在所有方面都更廣。Zed 更深入編輯器和程式碼審核循環，Buda 給更廣的公司流程一個持續工作空間。
Zed 的真實 Agent 架構
Zed 原生 Agent 運行在 Agent Panel 與 Threads Sidebar，可搜尋和讀取專案、編輯檔案、執行終端命令、使用 MCP 工具、遵循 Skills 與 Instructions，並在 Zed Review 介面展示變更。Agent Profile 決定工具是否可用，Tool Permission 決定動作允許、拒絕或需要確認。
External Agent 是第二條路徑。Claude、Codex、OpenCode、Copilot、Cursor、Pi 等相容 ACP 的 Agent 可透過自己的程序與設定運行，Zed 提供 Thread 介面。認證、計費、模型選擇與原生指令可能仍由外部 Agent 管理。在 Zed 中選擇某 Agent，不代表所有設定與訂閱自動互通。
Terminal Thread 提供第三條路徑：Zed 組織 Thread，命令列工具仍管理自己的認證、模型、工具與設定。團隊可取得統一編輯器工作面，同時保留 Agent 原生終端體驗。
平行工程不等於跨職能營運
Threads Sidebar 可同時運行多個 Agent Thread 與 Terminal Thread，每個都有自己的脈絡和歷史。Worktree 隔離可能修改同一批檔案的任務。開發者可在一個 Thread 跑 Zed Agent，另一個跑 External Agent，再在第三個運行終端 Agent，最後按檔案或 hunk 審查程式碼。
這是有意義的編排，但中心仍是軟體 Project：Thread 屬於 Project，審核聚焦程式碼變化，worktree 隔離保護儲存庫狀態。
Buda 的平行工作按公司角色與交付物組織。研究 Agent 收集來源，內容 Agent 寫稿，工程 Agent 檢查儲存庫，營運 Agent 準備上線。共享物件不一定是一套程式庫，而是會被審核、並在個人 Session 結束後持續的產物與流程。
最清楚的差異是審核邊界
Zed 為開發者提供很強的本機審核面。Checkpoint 可恢復 Agent 編輯前的專案狀態，Review Changes 展示受影響檔案，單個 hunk 可接受或拒絕，Profile 與 Permission 控制工具與動作。
Buda 審核的是更廣的產物：銷售簡報、研究表格、內容草稿、週報、CRM 更新、PR 風險說明或發布清單。重要元資料是 Owner、來源、狀態，以及批准後的下一步。
Buda 批准不能取代 Zed 或儲存庫平台中的 Code Review；Zed 的 hunk Review 也不能批准客戶溝通或業務決定。流程跨越兩個邊界時，應同時保留兩種審核。
四個更容易判斷的場景
1. 開發者希望 AI 工作留在編輯器
優先選 Zed。原生 Agent、脈絡引用、專案工具、終端、Checkpoint、Review 介面、模型與 External Agent 選擇，都讓編碼循環靠近原始碼。
2. 團隊要平行運行多個 Coding Agent
Zed 仍是強候選。Thread 和 worktree 提供獨立脈絡與檔案系統隔離。應在真實儲存庫測試 branch 規範、Setup Hook、工具權限、模型憑據和 Review Owner。
3. 公司要跨部門使用同一個 Agent 工作空間
當流程涵蓋銷售研究、內容、支援、營運和工程，每個角色使用不同來源並產生不同待審產物時，Buda 更自然。
4. 發布必須離開編輯器
用 Zed 完成實作與 Code Review。只有發布還需跨職能證據、文件、溝通、Owner 與批准，而且資訊必須在開發者 Thread 外可見時，才加入 Buda。
External Agent 必須明確邊界
Zed External Agent 通常管理自己的 Runtime、認證、模型、原生工具與設定；Zed 透過 ACP 承載 Thread。Terminal Thread 又有另一條邊界：CLI 管理自己的環境與憑據。
不能假設 Zed 的 Agent Profile、Skills、MCP、權限規則或訂閱自動套用到每個 External 或 Terminal Agent。試點必須核對具體 Agent 路徑、憑據位置、可用工具和歷史保存位置。
Buda 的連接工具與外部系統同樣要核對權限、保留、計費和資料邊界。可見 UI 不等於這些責任自動共享。
Zed 與 Buda 一起使用
- Buda 保存 Issue 脈絡、客戶證據、驗收條件、發布限制與 Owner。
- 工程 Agent 或開發者在 Zed 選擇合適 Agent 路徑和隔離 worktree。
- 開發者審核 hunk、運行測試並生成 commit 或 PR。
- diff、測試、PR 與風險說明回到 Buda 發布產物。
- 文件、支援、營運或內容 Agent 準備各自交付物。
- 一位明確的人批准影響客戶或正式環境的動作。
只傳遞下一位審核人需要的證據。把每個 Zed Thread 全量複製到 Buda 會製造噪音；把業務決定都留在私有編輯器 Thread 中也會製造交接問題。
一個公平的試點
- 定義來源、目標儲存庫、worktree/branch policy、測試、產物與審核人。
- 使用團隊計畫採用的真實 Agent 路徑在 Zed 完成工程工作。
- 在編輯器中審核檔案變化與失敗。
- 若有跨職能交接，只把交接保存在 Buda。
- 衡量修正時間、脈絡連續性、審核清晰度、交接成本，以及另一位同事能否接手。
- 工作確實在程式碼結束時只用 Zed；只有更廣營運循環真實且反覆出現時才加入 Buda。
FAQ
Zed 只是一款帶聊天的程式碼編輯器嗎？
不是。目前文件涵蓋原生 Agent、ACP External Agent、Terminal Thread、平行 Thread、worktree、內建工具、MCP、Skills、Instructions、Profile、Permission、Checkpoint 與程式碼審核。
Buda 會取代 Zed 做軟體開發嗎？
不能籠統這樣說。Zed 專門面向以編輯器為中心的工程循環。Buda 在工作需要跨職能、來源、產物類型、Owner 和審核階段持續時才有價值。
Zed 能運行 Claude Code 或 Codex 嗎？
Zed 文件列出透過 ACP 接入的 Claude 與 Codex External Agent，也提供運行原生 CLI 的 Terminal Thread。External Agent 通常保留自己的認證、模型、訂閱與原生設定。
最終批准應屬於哪個產品？
應由負責的人與對應動作的真相系統負責。程式碼接受屬於工程審核路徑；客戶、財務、法務、安全與生產動作必須遵循組織明確的業務控制。
來源
核驗日期：2026 年 9 月 22 日。