内容
开发者工作的中心正在发生转移。不是消失——而是转移。它正在远离单一窗口内持续、逐行的编辑，转向对能够规划、重写文件、运行测试并提出变更供审查的智能体进行监督。我们所熟悉的 IDE，可能不再是软件工作的主要工具，或者会发生深刻演化。
在许多开发者——包括我自己——已经每天都在使用的工具中： Conductor 、 Claude Code Web 、 GitHub Copilot Agent 、 Jules 、 Vibe KanBan ，甚至 cmux——同样的转变一再出现：控制平面（control plane）正在成为主要界面，而编辑器则变成其下方若干工具中的一个。
Cursor 刚刚发布了 Glass ——一个全新界面，明确就是为让“与智能体协作变得清晰、直观，并且由你掌控”而打造的。在这个界面里，智能体管理成为核心体验，而传统编辑器则变成你在需要更深入处理时才会调用的东西。开发者们的 反应 立刻就来了：
现在 Cursor 更像一个智能体编排器（Agent Orchestrator），而不是 IDE。并行管理多个智能体更容易了
但 Glass 只是一个更大趋势中的单一数据点。像 cmux 这样的终端 UI，也凸显出我们熟悉的这些界面正在如何演化，以更好地管理智能体工作流。
从编辑文件到驾驭工作流
历史上，IDE 一直围绕一个紧凑的内循环进行优化：打开文件 → 编辑 → 构建 → 调试 → 重复。“IDE 已死”这一说法的核心在于：一旦智能体能够自主执行其中大部分环节，这个循环就不再是生产力的主导单位。
新的循环看起来是这样的：明确意图 → 委派 → 观察 → 审查 diff → 合并。它与“带聊天窗口的自动补全”不同之处在于：具备工具调用能力的自主性，再加上专门设计出来、让这种自主性可被治理的界面。
你已经可以在很多高频使用的工具中看到这一点。Claude Code Web（或桌面版）和 Codex 允许开发者把定义明确的任务交给运行在隔离云环境中的智能体处理，并在浏览器中查看进度——不需要终端，也不需要本地配置。
GitHub Copilot 的 Agents 会独立规划并实现跨多个文件的变更、创建分支、运行测试，并最终生成一个 PR 供你审查；开发者的主要工作因此变成审查结果并继续迭代，而不是逐步指挥每一个步骤。
Conductor 采取了不同路径：它是一款桌面应用，可在隔离工作区中同时运行多个 Claude Code 智能体，并实时监控它们各自的进度。Google 的 Jules 则负责异步后台任务——你分配工作，它自行运行，完成后你再审查结果。
这些工具的共同点在于一种心智模型：工作单元是智能体，而不是文件。真正值得优化的界面，是帮助你指挥、监控和审查智能体的界面——而不是帮助你更快敲字的界面。
正在成形的编排层
只有当你去看这些工具中逐渐收敛的具体界面模式时，“IDE 被取代”的叙事才会真正显得有说服力。
将工作隔离作为一种基础能力。并行运行的智能体必须彼此不互相干扰。这个领域里几乎所有严肃的工具，最终都选择了 git worktree（或类似机制）作为答案。Conductor 会把每个智能体会话映射到各自独立的工作区。Vibe Kanban（上图所示）也为其看板驱动的智能体工作流采用了同样的做法。这个模式几乎无处不在，因为问题是真实存在的：没有隔离，并行智能体只会制造混乱。
将规划与任务状态作为首要 UI。像 Vibe Kanban 这样的工具，已经用“任务和状态”取代了“标签页和文件”，成为顶层心智模型。你创建任务卡片（一个落地页、一个后端服务、一项邮件集成），为每个任务分配一个智能体和模型，然后像管理一个轻量项目看板一样管理整个工作——只不过这个“团队”是在自主运行。这本质上是一个项目管理界面，只是恰好由智能体来执行实现。
后台智能体与异步优先设计。这个领域里一些最有意思的工具，甚至不试图让你在执行过程中始终保持在线。Cursor、Copilot 和 Antigravity 都支持后台智能体：它们运行时无需你在场——你定义意图，暂时离开，完成后再回来审查。Jules 也是类似的方式：指派任务，回来时看到 diff。其隐含承诺是：你的注意力太宝贵，不该浪费在盯着进度条上。这与 IDE 以实时、同步反馈为核心的循环有着显著区别。
对并行智能体的注意力管理。当许多智能体同时运行时，真正的瓶颈就变成了：此刻究竟哪一个需要你介入。这就是为什么 Conductor 会展示各个会话的实时进度，而 cmux 为终端窗格引入了通知环和未读标记。“智能体需要关注”正在成为开发环境中的一类一等事件——它需要被路由、被分诊，而不只是被顺手注意到。
将智能体嵌入软件生命周期。GitHub 的 Copilot 编码智能体是异步运行的，由控制层进行安全约束，并由 GitHub Actions 驱动——它连接的是代码实际交付的过程（issue → PR → CI → merge），而不只是代码被写出来的过程。
这些工具都没有宣称 IDE 已经过时——许多工具仍然与 IDE 互操作。但这些反复出现的模式（并行工作区、以 diff 为先的审查、任务状态、后台执行、生命周期集成），正是“IDE 已死”支持者所说的重心转移。
为什么开发者仍然会回到 IDE
对“IDE 已死”最有力的反驳是：IDE 依然把几个真正困难的问题压缩进了一个高保真反馈循环里：精确导航、本地推理、交互式调试，以及通过直接操作来理解系统的能力。
即便是最激进的编排工具，也都会保留一个手动编辑的逃生口。比如，你可以在线程中审查 diff、对变更发表评论，然后再在编辑器里打开结果进行手工调整。这其实是在承认：人工干预本来就是预期工作流的一部分。
智能体工具本身也揭示了目前能力边界所在。大型代码仓库中的跨文件重构，依然是软件工程智能体最棘手的挑战之一。而这恰恰是交互式代码导航和人类判断最重要的场景——你需要在脑中维持一个关于系统的心智模型，而智能体无法仅凭上下文将其完整重建。
让开发者仍然离不开 IDE 级别检查的失败模式，是智能体“几乎正确”。当某件事有 90% 是对的，却在细微处出了问题时，找出问题的成本往往比你自己从头写还高。对于高风险变更，IDE 依然是进行这类深入、精确检查的最佳工具。
新的成本：审查疲劳与治理开销
如果开发变成了“并行运行多个智能体”，那么工作流就会继承一些更像分布式系统管理、而不是文本编辑的问题——可观测性、权限、隔离和治理。
智能体工作流颠倒了劳动结构。你不再是去写，而是去审。这听上去像是一种改进，直到你在一天结束时面对来自 12 个并行智能体的 12 份 diff。审查疲劳是真实存在的，这也是为什么这个领域里最有思考深度的工具，会把重点放在注意力路由、结构化计划和以审查为先的关卡上，而不是默认推动完全自治。
随着智能体获得对更多工具、代码仓库和外部系统的访问权限，安全暴露面也随之扩大。当智能体能够浏览网页、查询数据库、写入文件系统并触发部署时，它们被允许做什么，就和它们能够做什么一样重要。
在可观测性与控制方面，集成到 IDE 中的智能体模式，已经在推动显式工具日志和审批关卡的出现。一旦智能体开始异步行动并触达 CI 流水线，治理问题就不再是可选项。
留下来的是什么：IDE、控制平面，还是两者并存
对当下格局一种清晰的解读是：“IDE 已死”这个说法，在“重心转移”这一方向判断上是对的，但若把它当作字面意义上的预言，则是错的。
这一观点最强的表述是：IDE 不再是主要工作空间，而变成若干从属工具之一——用于定向检查、调试和最终编辑；与此同时，规划、编排、审查和智能体管理则转移到仪表盘、问题追踪器、可观测性终端和云控制平面中。
“更大的 IDE”这种框架也同样站得住脚。新的“IDE”其实是一个系统：它提供多智能体编排、隔离工作区、权限与审计日志、以 diff 为先的审查、可靠的工具连接，以及注意力路由。文件编辑器依然还在，只是不再是正门。
IDE 并没有死。它只是被去中心化了。工作正在向外扩散——进入那些编排界面中，在那里，人类定义意图、把工作委派给并行运行的智能体，并把更多时间花在监督、审查和治理上，而不是敲代码。
IDE 对于正确性、理解能力，以及那些智能体仍然难以处理的复杂问题，依然至关重要。但它已不再是编程发生的唯一地点——而且对越来越多的人来说，它也不再是他们首先打开的地方。