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 原生的终端体验。
并行工程不等于跨职能运营
Zed 的 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 日。