2026 年 4 月 29 日,经过五年开发的 Zed 1.0 正式发布。如果只看版本号,它只是从 0.x 跨越到了 1.0;但如果看它在这一年里围绕 AI 重新组织的整套架构,会发现文本编辑器正在被重新定义成一种新的东西——不是写代码的工具,而是 Agent 的入口界面。Zed 团队在官方博客《On Programming with Agents》和产品页面上反复强调这个判断:未来的开发流程,不
2026 年 4 月 29 日,经过五年开发的 Zed 1.0 正式发布。如果只看版本号,它只是从 0.x 跨越到了 1.0;但如果看它在这一年里围绕 AI 重新组织的整套架构,会发现文本编辑器正在被重新定义成一种新的东西——不是写代码的工具,而是 Agent 的入口界面。Zed 团队在官方博客《On Programming with Agents》和产品页面上反复强调这个判断:未来的开发流程,不是人类在编辑器里写代码让 AI 帮忙补全,而是人类在编辑器里指挥 Agent 去完成整段工作。
支撑这个判断的关键产品是 Agent Panel。它不是一个聊天气泡,也不是一个补全提示,而是一个完整占据 Zed 右侧栏的面板,负责承载多线程、可观测、可恢复的 AI 工作流。在 Agent Panel 里,你可以同时跑多个 Agent 线程,每个线程有独立的上下文窗口和对话历史;你可以让 Agent 在 Git worktree 里独立工作,避免两个线程改同一份文件的冲突;你可以在 Agent 写入每一个改动前看到一个 checkpoint,需要时一键回滚到改动之前的状态。这些设计传达的信号很明确:Agent 不是一次性消费品,而是有状态的、有生命周期的、需要被管理的对象,编辑器只是它的工作台。
一、从"补全提示"到"工作流容器"——编辑器的角色重构
过去十年编辑器演化的主线是"如何更快地帮人类打字",从语法高亮、跳转定义、智能补全到 AI inline suggestion,每一步都在缩短从想法到字符的距离。但 Agent 时代真正改变的,是动作的主体。Zed 团队在官方文档里写得很直白:Agent Panel 是"where you interact with AI agents that can read, write, and run code in your project"——不是聊天框,是 Agent 工作的地方。
这一定位的转变带来了三个具体的产品决策。第一,Agent Panel 必须支持多线程,因为一个真正在做事的 Agent 不会等你和它一来一回,你会同时让一个 Agent 修 bug、另一个 Agent 写测试、第三个 Agent 重构老代码,Threads Sidebar 让这些并行工作流可视化、可切换。第二,Agent Panel 必须支持 worktree 隔离,任何可能被两个 Agent 同时触碰的文件都被强制物理隔离到不同 Git worktree,这是从分布式系统借鉴过来的并发控制思路。第三,Agent Panel 必须有 checkpoint 和 review 机制,Agent 每写一次文件就生成一个回滚点,Review Changes 视图把所有改动以 unified diff 形式展示,人类可以选择接受或拒绝每一个 hunk,这套流程借鉴的是代码评审而不是聊天审查。
二、ACP:Agent Client Protocol——把"谁当 Agent"变成可替换件
如果说 Agent Panel 是编辑器内部的工作流容器,那么 Agent Client Protocol(ACP)则是 Zed 给整个行业提出的更大野心。ACP 是一个标准化的协议,让任何编辑器都能和任何 Agent 通信,反过来也意味着任何 Agent 都能嵌入到任何编辑器。Zed 1.0 直接通过 ACP 接入了 Claude Agent、Codex、OpenCode 这三类外部 Agent,加上 Zed 自带的 Zed Agent,默认就有四种 Agent 可供切换,而且协议本身是开源的,任何编辑器厂商都可以实现。
ACP 的提出反映了一个判断:Agent 厂商和编辑器厂商之间的战争,赢家不会是其中一方。Cursor、Windsurf 这类把 AI 内置到编辑器里的产品,在 Agent 能力快速迭代的当下会被反复卡在"想换底层模型就得改编辑器"的窘境;反过来,Claude Code、Codex 这类独立 Agent 又很难把代码编辑体验做到原生编辑器的水平。Zed 的解法是用 ACP 把两侧解耦,让 Agent 专注 Agent,编辑器专注编辑器,中间由一份开源协议翻译意图。这个思路和当年 LSP(Language Server Protocol)把语法高亮、跳转定义等语言智能从编辑器里拆出去的历史非常像——LSP 让一个 VS Code 之外的编辑器也能瞬间获得上百种语言的智能,ACP 试图让任何一个编辑器都能瞬间接入所有主流 Agent。
三、Zeta 模型与原生渲染:为什么"快"突然又重要了
Agent 化最容易让人忽视的一个产品维度是性能,但 Zed 团队把它放在了最显眼的位置。原因很直接:Agent 不再像补全那样等你打完字才动,而是自己在后台疯狂地读写文件、跑命令、调用工具。如果编辑器的渲染跟不上,用户看到的就是一个延迟几秒才更新的界面,所有"实时跟随 Agent"的体验都会塌掉。Zed 用 Rust + GPUI 把渲染做到了原生 120fps,官方说法是"when your agent edits 50 files, you see every change as it happens",这不是修辞而是工程硬指标。
性能基础设施之上,Zed 还发布了自己的开源模型 Zeta,定位是编辑预测(edit prediction)而非通用对话。Zeta 关注的是"你接下来要改哪一行"这个极窄问题,在开发者真实改动的数据上训练,目标是让 Agent 在工作流中的每一步都更顺滑。这条产品线和 ACP、Agent Panel 一起构成了 Zed 的完整布局:底层有原生渲染保证视觉跟得上 Agent 节奏,中间有 Agent Panel 承载工作流,上层有 ACP 接入任意 Agent 模型,横向有 Zeta 补足编辑预测的最后一公里。
四、范式转移的真正含义:编辑器变成 Agent 的"运行时刻"
把 Zed 这套架构放到更大的地图上看,可以看出它不只是"另一个 AI 编辑器",而是在押一个具体的范式:未来的代码编辑工具,核心能力不是"如何输入文本",而是"如何运行 Agent"。传统 IDE 把语法树、调试器、版本控制、构建系统集成在一起,目的是让人能高效地写代码;Agentic IDE 把工作流管理、并行隔离、变更审查、可观测性集成在一起,目的是让人能高效地"派遣、检查、纠偏 Agent 的工作"。
这个范式转移对开发团队的实际意义有三条。第一,选型时不再只问"编辑器支不支持 Copilot",而是问"它支不支持自定义 Agent 配置、并行线程、worktree 隔离、checkpoint 回滚、可审计日志"。第二,工作方式从"打开 IDE 开始写代码"变成"打开 IDE 派出 Agent,然后实时跟进、随时接管",心态上要接受 Agent 是工作伙伴而不是工具。第三,代码评审的对象从纯人类同事扩展到 AI Agent 的产出,review checklist 里要加一条"Agent 是否在合理范围内做了这件事,有没有越权调用工具,有没有在不该写日志的地方写了敏感信息"。
而对 Agent 厂商来说,Zed 的动作释放了一个清晰信号:谁能把自己的 Agent 包装成符合 ACP 协议的标准化服务,谁就能进入所有实现 ACP 的编辑器,而不是只能在自家产品里和编辑器厂商捆绑竞争。这种生态级的协议战,最终的胜出者往往不是某个具体 Agent 产品,而是协议本身——就像 LSP 让 VS Code、Neovim、Emacs 都获得了同样的语言智能,ACP 也会让主流编辑器和主流 Agent 之间形成松耦合的标准化市场。
五、对自研 Agent 平台的启示
Zed 给自研 Agent 平台团队的启示不在技术栈,而在产品形态。当你给业务部门交付一个"AI 智能体"时,不要只交付一个对话窗口。真正能落地的形态,是把它包装成一个可观测、可管理、可回滚的工作台——人类可以同时派多个 Agent 去做不同的事,可以随时介入某一个 Agent 的工作,可以一眼看出 Agent 这一轮动了哪些文件、做了哪些决定。这才是 Agent 时代用户真正需要的产品界面,也是文本编辑器正在被重新定义的根本原因。
落到具体的工程实践上,至少有三件事值得立刻开始做。第一,给你的 Agent 加上 checkpoint 机制,每一次工具调用都留下回滚点,而不是把所有改动一股脑推给用户。第二,让你的 Agent 支持 worktree 级别的隔离,而不是所有任务共享同一份工作树,这是并行多 Agent 的最低要求。第三,把 Agent 的工具调用日志设计成可审计、可导出的结构,而不是只输出在终端里被刷走的几行文字。这些能力单独看都不复杂,但组合起来就是 Agentic 编辑器的真正门槛,也是从"演示 Demo"走向"日常依赖"的必经之路。