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 配置吗？
这些来源没有证明自动导入或直接兼容。应明确交接已批准产物、来源和指令。
第一轮选型测试什么？
先判断瓶颈是编程环境配置，还是业务角色反复接手和审核产物，再测试对应路径。