Buda vs Crush：終端誰維護，團隊產物誰驗收？
Crush 是 Charm 的終端程式設計 Agent。當前 README 明確支援保留上下文切換模型、專案會話、LSP 和 MCP。尋找 Crush 替代方案時，這些能力應該認真比較，不能先把它寫成“沒有上下文、沒有工具”的簡單終端。
Buda 對應的採購問題是：當工作從倉庫走向客服、內容和運營，誰維護執行環境，誰接管資料，誰驗收產物？這不是程式碼生成能力排名，而是團隊責任的分配。
先列出你願意自己維護的配置
Crush 可以連線多種提供方和相容 API，也支援本地模型配置。模型選擇器允許在會話中切換模型並保留上下文，LSP 提供程式碼語義，MCP 透過 stdio、HTTP、SSE 擴充套件工具。若團隊的優勢就在於熟悉這些組合，配置自由本身就是保留 Crush 的理由。
當前 README 使用基於 shell 的 crushrc 配置，區分專案和全域性位置，並提醒配置屬於可信程式碼。開啟陌生倉庫前應檢查配置、憑據展開和工具許可權。把個人配置複製給同事，不等於獲得一套已經安全稽核的團隊環境。
共享後端確實有連續性，也有執行責任
Crush 描述了共享 backend：客戶端按工作目錄進入同一 workspace，共享會話、訊息、許可權佇列、LSP 和 MCP 狀態。新啟動預設建立新會話，需要透過會話管理器選擇舊會話。這些是明確的連續效能力。
團隊試用時要驗證誰執行後端、誰能連線、誰固定配置。README 說明首個客戶端決定 yolo、debug 等程序級標誌。與其籠統說“它不能協作”，不如檢查這種按目錄組織的共享模式能否對應團隊角色和許可權邊界。
跟著一份產物走出倉庫
假設一個程式碼變更已經批准，還需要客戶說明、支援排查清單和內部培訓材料。三份產物都用到 diff，卻有不同稽核人和資料。工程師可以呼叫工具生成它們，但不一定應該長期維護每個部門的全部上下文。
Buda 為每個 Agent 提供持久雲電腦，並在工作區展示檔案、終端、瀏覽器和 Git。業務角色可以保留自己的任務材料與稽核記錄。這不證明與 Crush 已有內建整合。交接時仍需明確輸出已批准 diff、限制、來源，以及下一位 Agent 的驗收清單。
維護成本與稽核成本分別測試
終端路徑先記錄 provider、模型、LSP、MCP 身份驗證、配置審查和許可權行為，再用小型程式設計任務檢查 diff 與測試。託管工作區路徑檢查檔案保留、任務連續性、執行可見性，以及業務稽核人能否找到草稿和依據。
不要僅比較 token 單價。提供方費用、訂閱、機器執行、配置時間和返工屬於不同成本層。本文不承諾哪邊更便宜，也不宣稱功能等價；兩條試點應對應你真正要解決的積壓。
配置是優勢時，不必急著替換終端
已維護好模型和工具環境的工程師，不必為了介面統一丟掉現有組合。倉庫工作可以繼續留在終端，重複業務產物則單獨測試工作區。不要為了展示順暢就擴大許可權。
Buda 試點可以從一項已批准工程變更開始，要求業務 Agent 輸出帶來源的客戶說明、未決問題和稽核清單。流程重複時，在 Buda AI 的 Marketplace 搜尋並安裝合適的 Skill。衡量的是有負責人能驗收的交付，而不是兩套系統“已經自動相容”的說法。
常見問題
Crush 支援 MCP 和切換模型嗎？
支援，README 列出了 MCP 傳輸方式和保留上下文切換模型，不能把它們寫成缺失功能。
Crush 能共享工作區嗎？
共享後端按工作目錄組織客戶端與狀態，需要驗證訪問和配置責任，不能假設完全沒有共享，也不能推定團隊治理已經開箱即用。
Buda 會自動匯入 Crush 配置嗎？
這些來源沒有證明自動匯入或直接相容。應明確交接已批准產物、來源和指令。
第一輪選型測試什麼？
先判斷瓶頸是程式設計環境配置，還是業務角色反覆接手和稽核產物，再測試對應路徑。