别再同时开一堆 AI 编程助手了,真正缺的是一个“调度台”

阅读全文预计耗时 8 分钟。

几秒钟速读版

这篇讲什么

这次看的项目是vilmire/adhdev，也叫 ADHDev Self-Hosted。

它不是一个新的大模型，也不是要替代 Cursor、Claude Code、Codex 或 Hermes Agent。

它解决的是另一个更现实的问题：

当 AI 编程助手开始变成长期后台工人，谁来告诉你哪个还在跑，哪个卡住了，哪个在等你批准，哪个已经完成了？

ADHDev 给出的答案是：做一个本地控制台。

为什么要看

以前你只开一个 AI 助手，问题不大。

现在不一样了。

一个项目里，你可能同时开 Cursor、Claude Code、Codex CLI、Hermes Agent。一个在改前端，一个在跑测试，一个在查 bug，一个在等危险命令确认。

真正烦人的不是“AI 不够聪明”。

而是你不知道现场发生了什么。

ADHDev 盯的就是这个新痛点。

你能记住什么

ADHDev 是一个自托管的 AI 编程 Agent 会话控制平面。
它的目标不是替代底层 IDE 或 Agent，而是给它们一个统一控制面。
Standalone 模式本地运行，有 daemon、Web dashboard 和 session-host，不需要云账号。
README 明确列出已测试方向：Cursor、Google Antigravity、VS Code、Kiro，以及 Codex、Claude Code、Hermes Agent 等 CLI/扩展场景。
它也有边界：很多 provider/adapters 还在实验或未完全验证，不能当成所有工具都稳定支持。
安全上要注意，默认 localhost-only；如果用 --host 暴露到局域网，最好加 token 或 dashboard password。

适合谁

适合已经开始用多个 AI 编程工具的人。

尤其适合这类开发者：一个任务交给 Codex，一个任务交给 Claude Code，一个任务交给 Hermes，自己还想从一个页面看状态、接管、批准、恢复历史。

不适合谁

如果你只偶尔问 ChatGPT 几句，或者只在 Cursor 里开一个对话，ADHDev 暂时不是刚需。

它解决的是“多 Agent 管理”问题，不是“让 AI 变聪明”问题。

完整正文版

我先说判断：AI 编程工具再往下走，最先爆出来的问题，可能不是模型能力，而是现场管理。

这句话一点不玄。

过去你用 AI 写代码，像找一个临时外包。

打开一个聊天框，丢一个需求，等它回。

现在变了。

AI coding agent 正在变成后台工人。它会跑很久，会改文件，会开终端，会等你批准命令，会中途卡住，也会在你切去干别的事时继续推进任务。

一个还好。

五个一起跑，你就开始头疼。

哪个还在生成？

哪个等我点 approve？

哪个已经跑完测试？

哪个卡死在终端里？

哪个历史还能接着打开？

这就是 ADHDev 这个项目切进去的位置。

ADHDev 到底是什么

ADHDev 的完整定位是 Agent Dashboard Hub。

仓库 README 写得很直接：ADHDev Self-Hosted 是一个 self-hosted control plane for AI coding agent sessions。

翻成人话：它是一个本地运行的 AI 编程 Agent 会话控制台。

它不写代码。

它也不想替代 Cursor、Claude Code、Codex、Hermes Agent。

它做的是一层控制面：让你从一个本地 dashboard 里看见这些 Agent 的状态，检查聊天和终端现场，批准或打断任务，重新打开历史，再给下一条指令。

这点很关键。

很多人一看到 AI 项目，就先问：“它比 Claude 强吗？比 Cursor 强吗？”

ADHDev 不是这个赛道。

它的假设是：底层 Agent 会越来越多，越来越能干，越来越适合长时间跑在后台。

一旦这个假设成立，控制台就会变得重要。

你不缺工人。

你缺一个能看现场、派活、接管、止损的调度台。

它为什么值得写

因为这个痛点很新。

以前的软件开发工具，大多围绕“人操作机器”设计。

你打开 IDE，你敲命令，你点按钮，你看日志。

AI Agent 起来以后，工作方式变了。

它会自己启动流程，自己读仓库，自己运行测试，自己尝试修 bug。

但它仍然会在几个地方卡住：

需要你批准危险命令。

需要你判断改动方向对不对。

需要你看它是不是跑偏。

需要你在它完成后接下一棒。

于是开发者的角色开始变化。

你不再只是写代码的人。

你更像一个带着多个 AI 工人的现场负责人。

这时候，单个聊天框就不够用了。

你需要一个页面告诉你：谁在忙，谁在等，谁完工，谁出问题。

ADHDev 的 README 里有一句话很准：see which session is still running, waiting for approval, finished, stuck, or ready for the next instruction。

这就是产品价值。

不是炫技，是减轻“后台黑箱感”。

它怎么跑起来

ADHDev 的 self-hosted 路线很清楚。

推荐安装方式是：

npm install -g adhdev adhdev standalone

然后打开：

http://localhost:3847

也可以直接装 standalone 包：

npm install -g @adhdev/daemon-standalone adhdev-standalone

这条路径的重点是：本地运行。

Standalone 模式会在你的机器上跑一个 local daemon，并带一个内嵌 Web dashboard。

README 明确说，standalone path 不需要 cloud account 或 hosted control plane。

这对开发者很重要。

因为 AI 编程会话里可能有代码、日志、命令、路径、环境信息。能本地跑，天然比“所有状态先丢云上”更容易让人接受。

当然，本地不等于随便裸奔。

默认情况下，ADHDev 是 localhost-only。

如果你加 --host，它会绑定到 0.0.0.0，同一个局域网里的设备也能访问。

这个能力很方便，但也要上锁。

项目文档也提醒了：如果 --host 没配 token，也没设置 dashboard password，dashboard 会给出局域网暴露警告。

这不是小事。

一个能看 Agent 会话、发命令、控制运行时的 dashboard，不能随便暴露给同网段所有人。

它的架构重点

ADHDev Self-Hosted 主要围绕三层：

第一层是 daemon-standalone。

它负责本地 HTTP/WebSocket server，也负责把 Web UI serve 出来。

第二层是 daemon-core。

它是共享引擎，处理 IDE、CLI、extension、ACP integrations，做命令路由、provider 状态和 session/runtime state。

第三层是 session-host-daemon，也就是 adhdev-sessiond。

这一层负责长期 PTY runtimes。

为什么这个设计重要？

因为 CLI Agent 经常跑很久。

如果主 daemon 重启，任务不应该轻易丢掉。

session-host 把 PTY ownership 从主 daemon 里拆出来，可以让 CLI session 在 daemon 重启后重新连接。

这就很像工地现场的电源和指挥室分开。

指挥室刷新了，工人不一定要停工。

这类设计，说明 ADHDev 不是只做一个漂亮前端壳子。它确实在处理长时间运行、状态恢复、终端复用这些 Agent 工程问题。

它支持哪些东西

README 里把“Currently Working / Tested”放得很靠前。

当前明确写出来的 IDE 有：Cursor、Google Antigravity、VS Code、Kiro。

IDE extension integrations 里写了：Codex、Claude Code。

CLI agents 里写了：Hermes Agent、Codex CLI、Claude Code CLI。

这组名单很有意思。

它基本覆盖了现在 AI 编程工具里最常见的几类入口：IDE、插件、命令行 Agent。

但这里有一个坑必须说清楚。

README 也强调：ADHDev ships a broad built-in inventory of IDE, extension, CLI, and ACP integrations, including 35 ACP adapters。

但 built-in 不等于 verified。

内置只是说明库存里有适配器。

验证过，才说明可以当作明确支持。

很多 provider 和 adapters 仍然 incomplete、experimental，或者还没有足够验证证据。

所以写 ADHDev，不能吹成“所有 AI Agent 一键接入”。

更准确的说法是：它已经在几个主流 IDE、扩展和 CLI Agent 上做了测试，并且正在把更多 provider 纳入控制台库存。

这比乱吹更可信。

我对这类项目最看重的地方，恰恰是它敢把“支持边界”写出来。

因为 Agent 工具链最怕半支持。

看起来能接，真用起来状态不同步、审批丢失、终端失联、历史打不开，这些都会让人崩。

把 verified 和 inventory 分开，是成熟产品意识。

它开放了什么 API

ADHDev Standalone 不是只有网页。

它还暴露本地 API。

README 和 openapi.yml 里能看到这些端点：

GET /api/v1/status POST /api/v1/command GET /api/v1/runtime/:sessionId/snapshot GET /api/v1/runtime/:sessionId/events GET /api/v1/mux/:workspace/state GET /api/v1/mux/:workspace/socket-info POST /api/v1/mux/:workspace/control GET /api/v1/mux/:workspace/events ws://localhost:3847/ws

这意味着什么？

如果你只是普通用户，网页 dashboard 就够了。

如果你是自动化玩家，这个本地 API 就很关键。

你可以把 ADHDev 当成本机 Agent 状态中心：查状态、发命令、看 runtime snapshot、接事件流。

以后很多开发工作流，可能会变成这样：

AI Agent 负责执行。

ADHDev 负责汇总状态和控制。

外部脚本、MCP 或自动化系统通过 API 读取现场，再决定下一步。

这就从“人盯屏幕”变成“系统盯系统”。

它不是万能控制塔

ADHDev 目前还是一个快速迭代中的项目。

本地 package.json 里版本是 0.9.82-rc.72，license 是 AGPL-3.0。

仓库是 TypeScript monorepo，我本地核验到 13 个 workspace package，包括 daemon-standalone、daemon-core、web-core、web-standalone、session-host-daemon、terminal-mux、mcp-server 等。

GitHub 页面显示 1,232 次 commits。

这些信息说明它不是玩具 demo。

但它也不是“闭眼上生产”的成熟平台。

README 里还有一个 Windows 注意事项：Windows + Node.js 24+ 目前在正常 startup/install path 上被阻塞，建议用 Node.js 22.x，或者走文档里的 PowerShell installer。

self-hosted setup 文档也提示：当前公开 install-tested paths 是 macOS 和 Windows，Linux standalone 可能能跑，但还没验证到足够写成正式支持路径。

这类边界必须看清。

尤其是你准备让它接管多个 AI coding sessions 的时候，别一上来就把所有关键项目都挂上去。

先从一个低风险仓库试。

看它如何识别 session、如何显示 terminal、如何处理 approval、如何恢复历史。

跑顺了，再扩大使用范围。

和 Hermes、Claude Code、Codex 的关系

ADHDev 最容易被误解成“又一个 Agent”。

但它不是。

Hermes Agent、Codex CLI、Claude Code CLI 更像具体干活的人。

ADHDev 更像调度台。

你可以让 Codex 去改一个 bug，让 Claude Code 做一个重构，让 Hermes Agent 跑一个自动化任务。

然后你从 ADHDev 看它们的状态：谁在运行，谁需要确认，谁已经完成，谁应该被中断。

所以它不和这些工具抢位置。

它站在这些工具上面一层。

底层 Agent 越多，它的价值越明显。

如果未来开发者只用一个 AI 助手，ADHDev 的意义有限。

如果未来开发者同时使用多个模型、多个 IDE、多个 CLI Agent、多个工作区，它就会变成非常自然的需求。

我的判断

ADHDev 这个项目给我的最大信号是：AI 编程正在从“单人聊天”进入“多工人调度”。

以前的问题是：AI 能不能写代码？

现在的问题正在变成：AI 在哪？跑到哪一步？有没有等我？有没有卡住？我能不能安全接管？

这就是控制平面的价值。

我不认为每个普通用户都需要立刻安装 ADHDev。

但如果你已经在用 Cursor、Claude Code、Codex、Hermes 这类工具，而且经常并行开多个任务，那它切中的问题很真实。

尤其是长期后台任务越来越多以后，开发者会越来越需要三个东西：

看得见状态。

控得住权限。

接得回现场。

ADHDev 就是在做这三件事。

它还没到“所有人必装”的阶段。

但它代表的方向很确定：

AI Agent 不只需要更强的大脑。

它还需要一个可靠的驾驶舱。

收藏版清单

如果你只想快速判断 ADHDev 值不值得研究，看这几条：

你是否同时使用多个 AI 编程助手？
你是否经常不知道某个 Agent 跑到哪一步？
你是否遇到过后台任务卡住、等待审批、历史不好恢复？
你是否希望从一个 dashboard 看聊天、终端和 session 状态？
你是否能接受 self-hosted、本地 daemon、Node/npm 这一套安装方式？
你是否愿意认真配置 token/password，而不是把控制台裸露到局域网？

如果前四条都是“是”，ADHDev 可以研究。

如果你只是偶尔问 AI 几句，先不用急。

链接放这：https://github.com/vilmire/adhdev

下一步建议

想试的话，先别接重要项目。

建议顺序是：

第一步，本地安装 standalone。

第二步，只接一个低风险测试仓库。

第三步，测试一个 CLI Agent 的启动、状态显示、终端查看、approval、恢复历史。

第四步，再接 Cursor、Claude Code、Codex、Hermes 这类你真实在用的工具。

第五步，如果要开 --host 给局域网设备访问，先配 token 或 dashboard password。

不要反过来。

别先把它暴露出去，再想安全。

Agent 控制台和普通网页不一样，它连着的是你的开发现场。