Zed 推出并行 agents:代码编辑器的＂主战场＂正在转移

4月22日，Zed 宣布推出 Parallel Agents 功能。

简单说就是：你可以在 Zed 里同时运行多个 AI agent，分别在不同的 Git Worktree 上工作，最后把结果合并回来。Zed 官方说这是”最接近真正并行编程的 AI 编辑体验”。

这个功能本身不复杂，但 HN 上 137 条评论揭示了一个更深的问题：没有人真的知道，多个 AI agent 同时工作，到底该怎么协作。

Zed 的解题思路：Worktree 就是隔离边界

Zed 的并行 agent 本质上是基于 Git Worktree 的文件系统隔离。

每个 agent 在自己的 Git Worktree 里工作——代码副本完全独立，不会互相覆盖。Zed 在这个基础上做了一层 UI 和 agent 调度的封装，让你可以同时启动多个 agent，监控它们的工作状态，在不同线程之间切换。

这是工程上最直觉的解法：物理隔离文件，逻辑上并行。

支持者说这就是未来。用户在 Zed 博客下留言：

“这就是我从 Cursor 切换到 Zed 的原因——从单线程 agent 开发到并行 agent 开发，差异巨大。”

Zed 的 CTO Max Brunsfeld 也亲自下场解释：

“新布局里，项目面板和 Git 面板移到了右边，agent 面板放在左边——你可以同时看到 agent 工作和代码结构。”

Conductor（一家专注多 agent 协作的工具）创始人 Charlieholtz 也来捧场：

“我们正在加入更多 agent 支持，Copilot 和 OpenCode 是最热门的请求。”

137 条评论里，真正的问题只有一个

HN 用户ArielTM说出了核心矛盾：

“Worktree 的问题是最好解决的那一半。真正的难题是语义层面的协作。Agent A 把一个类型重命名为 X，Agent B 在另一个 Worktree 里把它重命名为 Y——两边都没做错，但合并之后代码是混乱的。”

“你需要要么有一个共享决策日志，让所有 agent 开始工作前都读一遍；要么有一个编排器，把任务拆分到足够窄，窄到不会有任何碰撞。”

“Zed 解决的是文件系统层面的并行。真正的协作难题在语义层面——而那才是节省时间的关键所在。”

这几乎是整个并行 agent 赛道被忽视的核心问题。

所有工具（Zed、Conductor、Ouijit、Worktrunk）都在解决”文件隔离”的问题，但没有人真正解决”架构决策一致性”的问题。

辩论的另一面：有人根本不想要并行

HN 上有大量开发者明确表示”我不需要并行 agents”。

VortexLain：

“我有意避开并行 agent。它会产生太多认知负担——而且有时候 agent 在工作过程中需要人类引导到正确的架构方向。”

aszen：

“Review 的难度也更大。多任务反而会杀死效率。我现在的方式是一次只做一个变更，直到能完全有信心合并。”

kippinsula分享了一个真实失败案例：

“我们试了一个 sprint 的并行 agent——真正的障碍不是 Worktree 的设置，而是测试数据隔离。共享迁移被多个 agent 同时修改，3个 agent 同时碰它，最后没人知道是哪个搞坏了什么。我们现在只用单 agent，然后去散步。”

这个体验很有代表性：并行 agent 的理论效率和实际体验之间，有一道很宽的沟。

一场关于”编辑器应该是什么”的隐性辩论

这个 HN 帖子里有大量评论，表面在说”并行 agents”，背后其实在争论一个更根本的问题：AI 时代，代码编辑器应该是什么？

“编辑器优先”派：

“我还是更喜欢 Zed，因为它首先是一个出色的编辑器，其次才涉及 AI。你可以关掉所有 AI 功能，只用一个极快的编辑器。”

“我不需要 agent 面板出现在默认布局里。文件树消失了，每次要找半天才知道怎么加回来。”

“如果我想要一个 AI 工具，我会用专门的 agent 产品。编辑器就该做好编辑器的事。”

“AI 优先”派：

“zed 的并行 agents 功能比其他方案更符合直觉。”

“AI 和 agent 工具是这个 VC 背书的公司唯一能赚钱的方向。没人会为一个编辑器付钱，这是现实。”

“Zed 是唯一一个真正在认真解决 AI 编程工作流问题的编辑器。VS Code 的 Copilot 只是往旧架构上打补丁。”

这两派的分歧，本质上是工具定位的根本差异——编辑器是人的工具，还是 AI 的工具？

还有一个被忽视的成本：Token 消耗

HN 用户phito提出了一个被大多数讨论忽略的点：

“你这样做其实在浪费大量 token。现在你没意识到是因为它们被大量补贴——但等你必须支付真实成本的时候，你才会明白好的编排和 memory 文件的价值。”

这个观点在评论里引发了一轮争议。有人反驳说成本会持续下降，有人说 VC 补贴不会永远存在。

但没有人给出具体数字。

这本身就是一个信号：Token 成本问题还没有真正被认真对待。

一个有意思的竞争生态正在形成

HN 评论里提到了不少相关工具，可以勾勒出这个赛道的现状：

• Conductor
  
  ：最早做多 agent 协作的工具，基于 Git Worktree，支持 Claude/Codex。有用户说遇到了文件描述符泄漏 bug 导致每天要重启两次。
• Ouijit
  
  ：支持 VM 隔离的 Worktree 管理工具，”给你一个 shell，你可以用任何工具”
• Worktrunk
  
  ：自称为”最流行的 Worktree 管理器”
• JJ（Julia）
  
  ：有用户用 JJ workspaces 做多 agent 工作流，”独立于具体 agent，你可以在里面跑 Codex、Claude 或任何模型”

这个领域的竞争还处于非常早期，每家的解决方案都有明显的局限性。

独立思考：并行 agent 的真正障碍不是技术

回顾所有 HN 评论，有一个核心矛盾反复出现：

我们不知道多个 AI 在同一个代码库里工作时，应该如何做决策。

文件系统隔离解决了”写文件”的问题。但代码库不只是文件——它是架构、约定、命名空间、一组相互引用的决策。多个 agent 如果没有共享的”决策日志”，它们各自做出的决策会互相冲突。

这不是 Zed 一个产品的问题，这是整个行业都没有认真回答的基础问题。

OpenClaw 的多 agent 设计选择是隔离优先——不同 agent 做不同角色的任务，而不是在同一件事上并行。Manus 的 Wide Research 是结果聚合——并行执行，最后汇总。

这两种范式都回避了同一个问题：如果并行 agent 之间产生了冲突，谁来仲裁？

Zed 的方案是”用 Worktree 物理隔离来规避冲突”——这是目前最诚实的解法。它承认了冲突无法自动解决，所以选择不让 agent 们碰同一份代码。

但这意味着并行 agent 的适用范围，被严格限制在相互独立的工作单元上。一旦需要跨模块协调，并行就变成了新的问题来源。

怎么判断自己是否需要并行 agent？

根据 HN 上的真实反馈，有一个简单的判断标准：

如果你的任务可以被严格拆分到互不影响的模块，并行 agent 可以显著提速。

如果你的任务需要跨模块的架构决策，并行 agent 会制造新的问题。

大多数真实项目属于后者。

资料来源：

• Hacker News: “Parallel agents in Zed” (2026/04/22, 247 points, 137 comments)
• Zed 官方博客：Parallel agents
• Conductor 官网
• Ouijit GitHub

如果这篇文章对你有启发，转发是对我最大的支持。