dev-3.0：给一个人同时指挥多路 coding agent 的任务塔台
AI coding agent 变强之后，一个新的问题开始冒出来：你不再只是在一个编辑器里写代码，而是在几个终端、几个 branch、几个 worktree 之间盯进度。一个 Claude Code 在改 UI，一个 Codex 在补测试，一个 Gemini CLI 在查文档，另一个 shell agent 正在做 review。真正拖慢人的不一定是模型能力，而是你很难一眼看清每个 agent 在哪、改了什么、有没有卡住。
今天想记录的 h0x91b/dev-3.0 就是冲着这个摩擦来的。它把自己定位成 “Mission control for the One Person Studio”：不是 IDE，也不是团队项目管理 SaaS，而是给个人开发者同时运行多路 AI coding agent 的工作台。每个任务都有自己的 Kanban 卡片、git worktree、tmux session 和终端入口；你负责拆任务、看状态、切换焦点，agent 负责在隔离环境里动代码。
按 GitHub repository page、README、Releases、LICENSE、package.json、agent-support-matrix.md 和公开 git history 在 2026-07-29 能核验的信息，h0x91b/dev-3.0 当前有 230 stars、23 forks。GitHub 页面嵌入数据给出的仓库创建时间是 2026-02-18 12:21:07 UTC。候选发现时 GitHub 数据显示 latest push 为 2026-07-29 09:14:33 UTC；当前默认分支 main 的 HEAD 是 0e7d41e，提交时间 2026-07-29 09:14:31 UTC。主要语言为 TypeScript，许可证为 Apache-2.0。最新 GitHub Release 是 v1.40.0，发布时间 2026-07-24 18:05:53 UTC；根 package.json 版本也是 1.40.0，技术栈里可以看到 Bun、Electrobun、Vite、React 和 Tailwind。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | h0x91b/dev-3.0 |
| 定位 | 个人开发者的多 AI coding agent 工作台 |
| Stars | 230 |
| Forks | 23 |
| 主要语言 | TypeScript |
| 许可证 | Apache-2.0 |
| GitHub 创建时间 | 2026-02-18 12:21:07 UTC |
| 最新 push | 2026-07-29 09:14:33 UTC |
| 当前默认分支提交 | 0e7d41e，2026-07-29 09:14:31 UTC |
| 最新 GitHub Release | v1.40.0，2026-07-24 18:05:53 UTC |
| 版本 | 1.40.0 |
| 关键词 | Kanban、git worktree、tmux、CLI agents、remote browser mode、code review |
它解决的是“agent 太多以后谁在干什么”
README 里的问题描述很直接：当你同时运行 5 个以上 AI agent，它们分散在不同终端、仓库和 branch 里，切换上下文会变慢，状态会丢，多个 agent 在同一个 repo 上改代码还会制造 merge conflict。dev-3.0 的答案不是把 agent 塞进一个新编辑器，而是给每个任务创建隔离工作区。
这个选择很关键。很多 AI IDE 的默认假设是“人还在编辑器中央，agent 是旁边的助手”。dev-3.0 的默认假设更像是“agent 在多个车道里跑，人需要一个调度面板”。任务卡片先进入 Kanban board，然后自动拥有自己的 git worktree 和 tmux session。你可以从卡片看到终端预览、注意力提醒和当前阶段，而不用在一堆 terminal tab 之间猜哪个任务已经完成。
这也解释了它为什么强调 “not an IDE”。代码仍然可以在 VS Code 或 Cursor 里打开，但 dev-3.0 不想接管编辑器。它更关心 agent 运行的外层结构：任务、worktree、终端、状态、review 和远程访问。对已经习惯让 Codex 或 Claude Code 大段改代码的人来说，这个外层结构反而是日常痛点。
git worktree 是并行的基本单位
多 agent 并行最怕的是它们在同一个 checkout 里互相踩文件。dev-3.0 把每张任务卡和一个 git worktree 绑定起来，天然把分支、依赖目录、dev server 和终端进程隔开。README 还提到 Copy-on-Write clone paths，可以把 node_modules、.venv、build 等重目录快速复制到 worktree，尽量减少“隔离很好但启动太慢”的代价。
这个设计适合几种具体场景。比如你想让一个 agent 修 bug，另一个 agent 写测试，第三个 agent 做 review，它们可以各自拿到独立 worktree。最终你看每张卡片的 diff 和终端状态，再决定哪条线进入 review。它不保证 merge 永远简单，但至少不会让几个 agent 在同一个工作目录里同时改到不可收拾。
tmux 则负责把 terminal session 变成可持久的运行面。dev-3.0 支持一个任务里并排跑多个 agent，也可以从卡片悬停看到 live terminal preview。对 CLI agent 来说，这比“打开一个终端然后祈祷自己还记得它在做什么”稳很多。
支持 Codex、Claude Code 和其他 CLI agent
agent-support-matrix.md 里列了它已经考虑的 agent：Claude Code、Cursor Agent、Codex、Gemini CLI 和 OpenCode。不同 agent 的能力不一样，例如 session resume、permission mode、model selection、status hooks、skill injection，都需要各自适配。这个文件的存在说明 dev-3.0 不是只在 README 里写一句“支持任意 agent”，而是真的在处理 CLI agent 之间的差异。
对 Codex 来说，文档里提到它通过 session id 和 tmux pane 记录来做 targeted recovery，并用 hooks 管理状态流转。对 Claude Code，它也处理 status hooks、skill injection 和 rate-limit tracking。即便你不用所有功能，这种差异表也很有价值：多 agent 工作台真正难的地方，不是启动一个 shell 命令，而是长期追踪“这个 shell 属于哪张卡、哪个 worktree、哪个 agent session”。
README 的安装路径也偏向实用。macOS 可以通过 Homebrew cask 安装；Linux 更偏 headless 用法，通过 dev3 remote 在服务器上跑，再从浏览器打开完整 UI。项目也提供 agent-driven install 文本，让你把安装说明丢给 Claude Code、Codex 或 Gemini CLI 之类的 agent 处理。Windows 目前还在 roadmap 上，这是一个需要注意的平台边界。
它把 review 也放进同一个工作台
dev-3.0 的 feature list 里有一个容易被忽略的点：PR review mode 和 built-in code review。它可以 checkout remote branch，把任务切到 review 语境，并提供带语法高亮的 inline diff viewer、line-range comments，以及把 review 导回 agent 的入口。
这点很符合 agent-heavy workflow。让 agent 写代码只是前半段，后半段往往是人如何快速判断它有没有改偏。传统方式是打开 PR、看 diff、回到终端继续提示 agent。dev-3.0 试图把这些动作拉到同一个任务卡附近：卡片上看终端，diff 里留评论，再把 review 反馈丢回 agent。它不是替代 GitHub PR，而是给本地调度提供一个更短回路。
另一个有意思的功能是 bug hunters：可以启动一组只读 agent 并行检查 branch diff。这个功能听起来很“AI 时代”，但背后的工程含义很朴素：如果 agent 检查也能并行，就需要更明确的任务边界和输出归档，否则你只是多了几段散落的聊天记录。
远程模式适合服务器工作流，但要理解安全边界
Linux 上推荐的路径是 dev3 remote：在远程开发机或云 VM 上跑 headless server，然后用浏览器访问 UI。README 写到它会打印访问 URL 和 QR，也可以使用 Cloudflare quick tunnel；如果只想本地连接，则可以传 --no-tunnel。这对经常在远端机器跑 agent 的人很有吸引力，因为 agent 进程、repo、worktree、dev server 都可以留在服务器上，人只拿浏览器做控制面。
但这也是需要谨慎的地方。任何能控制 coding agent 和终端的远程 UI，本质上都接近开发机控制面。README 提到 token 会轮换、浏览器会记住受信设备，但真正用于生产仓库前，仍然应该先搞清楚端口、tunnel、SSH forward、机器权限和 agent 凭据如何隔离。dev-3.0 的方向是提高个人速度，不是替你完成企业级访问治理。
需要注意的地方
第一，项目仍年轻。它在 2026-02-18 创建，star 数还在小众范围内，虽然近期提交很密集，但还不是已经被大规模验证的基础设施。
第二，它的理想用户很窄。README 自己也说，如果你想待在编辑器里手写代码和 Git，应该选 agent IDE；如果你要买给整个团队、有 SSO、seat、audit 的平台，应该找 team orchestrator。dev-3.0 更适合一个人同时开多路 agent 并亲自调度。
第三，平台边界要看清。macOS 和 Linux 是主要路径，Windows 还在 roadmap。Linux 的 Homebrew 安装也提示不要用 root 跑，这对服务器环境会影响初次部署方式。
第四，调度面板不能替代工程判断。worktree、tmux、Kanban 都能降低混乱，但 agent 写出的代码仍然要 build、test、review。dev-3.0 提高的是并行管理能力，不是自动保证结果正确。
总结
h0x91b/dev-3.0 有意思的地方，是它承认 AI coding 的瓶颈正在从“怎么让 agent 写代码”转向“人怎么管理多路 agent 的注意力”。它没有做另一个编辑器，而是把 Kanban、git worktree、tmux、远程浏览器 UI 和 review 入口拼成一个调度面。
如果你现在只偶尔开一个 Codex 或 Claude Code session，它可能显得过重。但如果你已经开始同时跑多个 agent、多个 branch、多个远程任务，并且经常忘记哪个终端在做什么，dev-3.0 值得放进观察列表。它的价值不是让 agent 更聪明，而是让人不被并行中的 agent 淹没。