开发者们正争相寻找能帮他们管理多个编码智能体的工具，并在这个过程中捣鼓出不少自己的实用工具。

史蒂夫·耶格（Steve Yegge）不是那种羞于启齿的人，所以当他想了解别人是如何管理 10 到 20 个（甚至更多）编码智能体时，他直接在 X 上发帖提问。具体来说，他在寻找一款 IDE，因为“我用的是 Emacs，我不希望你也遭这个罪。”

回复（已超过 600 条）提供了大量替代方案：Herdr、cmux、Conductor、Claude 和 Codex 桌面应用，以及各种各样令人印象深刻的自制软件。对于那些希望业界已经就“如何合理地与智能体协作”达成共识的人来说，显然我们还没有。这正是耶格发问的原因。

然而，这些回复中最有意思的信息，并不是开发者用的是哪款 IDE 或 IDE 替代品，而是他们为了让这些工具适应技术短板而添加的功能。这些功能包括：用于快速找到需要做决策的智能体的快捷方式、恢复早前对话的方法，以及解释某项任务在项目中处于什么位置的分组方式。换句话说，尽管我们如今已拥有惊人的智能来协助写代码，开发者仍然在为一个简单的任务而挣扎——自动记住自己曾要求 AI 做什么。

我们似乎把“生成工作”变得更简单了，却没有让“吸收和完成工作”变得更容易。

人人都在自建工作区切换器

马克·雅基斯（Mark Jaquith）使用带有自定义界面的 Herdr，以快速跳转到需要他关注的智能体。凯·巴克曼（Kai Backman）一直在开发一个键盘快捷键，把他带到“下一个最相关的需要采取行动的地方”。雅各布·沃伊特科（Jacob Voytko）构建了一个工作区切换器，把任务按里程碑分组，让他能跳转到对应的工单和拉取请求。他想要的是对工作进展状态的直观感受，而不是一份无结构的清单。另一位回复者巴兹尔（Basil）则做了一个管理器，帮他“找到我们做 x 的那次会话”。

当然，开发者一直都在定制自己的工具。光是 Emacs 用户就能提供大量证据。但同样，重点并不在于开发者在调整自己的工具，而在于他们为什么这么做。这些调整中有很大一部分，意在帮助开发者把自己的意图与同时发生在多个地方的工作协调一致。他们不是在要求更好的 AI：他们是在要求 AI 帮助他们表达自己的人性，可以说。

工作总会回流

设想一位开发者让一个智能体修 bug，让另一个调查性能问题，再让第三个更新依赖。在智能体工作期间，她可以做别的事——这正是大语言模型驱动的开发如此吸引人的原因，至少直到智能体返回之前是这样。

这些智能体所做的任何工作都不是与系统其余部分完全隔离的。想想看：bug 修复改变了别人可能依赖的行为。好吧……这个我们可以处理！但等一下，性能调查现在给出了三个选项，每个选项成本不同。嗯。稍等，我先处理这个……可依赖更新并不等人。它的测试通过了，但智能体还改写了配置文件。最好检查一下！

正如这个简单例子所示，在开发者能够就任何决策向前推进之前，她首先需要重新弄清楚：自己当初要求了什么、智能体发现了什么、以及还有哪些不确定之处。而且，增加更多智能体并不能解决问题，反而可能让问题更复杂。

智能体也许节省了数小时。太好了！但一份已完成会话的清单并不能告诉开发者从哪里开始。绿色的测试结果也无法回答“这个改动是否该进入应用”这个问题。

这就是为什么“正在运行的智能体数量”能告诉我们的信息少得可怜，即便它让我们感觉很酷。我是说，那些智能体到底在干什么？耶格帖子下的评论者提供了一些线索。例如，安东（Anton）描述了自己使用 30 个终端标签页的做法，每个项目一个活跃智能体，以避免彼此的工作重叠。杰里·库姆斯（Jerry Combs）说自己通常最多保持三个对话，智能体则按需管理自己的子智能体。即便是这三个对话，也已经够难跟上了。

两种做法都说得通。需求取决于工作能在多大程度上独立推进，以及过程中需要多少人类判断。拥有 20 个智能体的开发者，需要做的决策可能比只有 3 个的开发者更少。

格盖利·奥罗斯（Gergely Orosz）最近列出的几项观察值得放在一起考量：开发者在 IDE 中花费的时间减少、代码审查变成走过场、以及尽管 AI 承诺了生产力提升，人们却工作得更多。他的观察并不能证明智能体工具导致了过度工作或流于表面的审查，但确实值得我们追问：我们是不是正把精力转移到那些生产力叙事的盲区里？看着智能体产出一个改动是令人满足的，但花一下午去重构“为什么做了这六个改动”就不那么令人愉快了。

然而，如果这些改动要被人理解和维护，这项工作——无论多么不令人愉快——都是必要的。

教会工具“等待”

一些基础设施已经存在，可以缓解这些问题。例如，Herdr 会把智能体跟踪为“工作中”“已阻塞”或“空闲”状态，并把这些状态带入其标签页和工作区；cmux 提供通知功能，以及跳转到最近一条未读通知所在工作区的快捷键。这些都是有用的起点，但也恰恰凸显了还有多少工作要做。毕竟，最新的通知可能涉及最不重要的任务，而正在提问的智能体，完全有能力在开发者先忙完别的事情时耐心等待。

下一代的改进应当帮助开发者做出这些区分。一项任务应当保留其最初目的、相关决策，以及支撑其结果证据。当它需要人来介入时，它应当说明需要做什么决策，以及如果这个决策被推迟会发生什么。摘要会有帮助，但它必须能回溯到实际改动和测试结果。否则，我们只是让“在不理解工作的情况下批准工作”变得更容易了。

再说一次，最适合智能体 AI 的工具，将是那些把人类重新带回回路中、并提供做出决策所需信息的工具。

我想要这样一款工具：它能告诉我某项任务已可供审查，因为所要求的行为已经被验证，同时把一个没那么紧急的独立问题挡在我的视野之外。我还希望它能记住我昨天否决了某个方案，这样我就不必在今天提出的修复方案里再发现一次。至于这款工具是否自称 IDE，似乎次要。谷歌把 Antigravity 2.0 作为一款独立的智能体应用推出，并没有做成 IDE，同时建议开发者将它与自己惯用的 IDE 配合使用。换句话说，编辑器仍然有自己的职责，即便它不再是每项任务的起点。

2022 年，我曾撰文谈过云的便利性，以及人们容易误解开发者对工具的期望。他们有工作要做，希望做这件事的阻碍更少。我们应当以同样的标准来衡量智能体开发的全过程，包括“回到这项任务”所付出的努力。

这并不意味着可以把所有责任都推给 AI 及其工具。团队也有自己的角色。如果每项任务都是紧急的，工具就无从优先排序。如果没有人定义什么算“完成”，工具只能报告“某个智能体停了”。在这些事情上达成共识、并限制需要同时由人做决策的工作量，其价值要超过再加一个状态徽章。

耶格的读者们已经在一点一点构建这个未来——一个快捷键、一个自制工作区地构建。厂商的机会在于，让这种便利人人可用，而无需每个人都去维护一个副业项目。给开发者更多可以放心抛在身后的工作，以及更少需要一直记在脑子里的对话。