一个面向 AI 编码任务的调度与执行系统。
它不是单纯把 Claude Code、Codex 之类的 CLI 包一层 UI，而是试图解决一个更具体、也更日常的问题：当你同时开着很多 AI CLI 会话做开发时，真正拖慢效率的，往往已经不是模型本身，而是多 agent 带来的管理成本。
日常使用 Claude Code、Codex 等 AI CLI 进行项目开发时，尤其是在多项目、多微服务并行推进的场景下，一个很常见的习惯是同时打开多个终端会话，让不同 AI 分头协助不同任务。
这种方式在任务简单时很直接，但一旦会话数量变多，问题就会越来越明显：
- 要在多个窗口、多个 tab 之间来回切换，上下文切换成本很高。
- 某个 AI 会话执行了很久，期间人切去做别的事情，回来时常常忘了它其实已经执行完成，结果后续动作被无声阻塞。
- 偶尔遇到 LLM 响应卡顿，人的注意力也会一起被拖住。
- 一个需求已经交给 AI 拆解执行，但中途又冒出许多后续想法，而这些想法依赖前序任务完成，只能先零散记下来，等执行结束后再手动衔接。
- 同一个项目里明明有多个任务可以并行推进，但如果都落到同一份代码工作区里，又容易产生代码冲突；而
git worktree虽然能解决一部分问题，日常使用成本并不低。
这里姑且把一个 CLI 会话视作一个 agent。随着 agent 数量增加，真正的瓶颈逐渐从“AI 能不能做”转移到了“人如何同时管理多个 agent”。
我调研过一些多 agent 编排方案，也认真看过 beads 和 gastown。它们给我最大的启发，是应该以“任务”而不是“会话”作为组织核心，这和我原本的直觉基本一致。但另一方面，这类方案往往要么概念偏重，要么倾向于让 AI 长时间自动运行、自动编排、自动决策。
而我更关心的是另一件事：
在当前阶段，AI 依然需要人持续参与。
一旦方向跑偏，人需要尽快介入修正；相比追求“全自动自治”，提升人机协作体验、降低多 agent 管理负担，反而是更现实也更有价值的方向。
于是有了这个项目。
Agent Task Orchestrator 的目标，是提供一个以任务为核心、以人工参与为前提的多 agent 调度与执行系统：把 AI CLI 会话从“散落的终端窗口”提升为“可调度、可追踪、可恢复、可并行管理”的任务执行单元。
这个项目目前采用两层模型：
Session：一个实际运行中的 AI CLI 会话，对应一个终端/agent。Task：一个待执行或执行中的任务，任务可以被调度到某个 session 上运行。
也就是说，用户不必一直围绕“我现在有多少个终端”来思考，而是可以更多围绕“我现在有哪些任务，它们分别处于什么状态，哪些已经可执行，哪些在等待，哪些需要我接手”来管理工作。
这背后的取舍很明确：
- 不追求当前阶段的完全自动化自治。
- 强调人在回路中的调度、纠偏与确认。
- 让 AI 更适合承担持续执行和并行推进的部分。
- 让人把注意力放在任务推进本身，而不是窗口管理和状态记忆上。
当前版本已经是一个可运行的 Electron 桌面应用，围绕 Claude CLI 的多会话管理和任务调度展开。
- 统一创建和管理多个 Claude 会话
- 每个会话可指定独立工作目录
- 支持会话重命名、删除、排序拖拽
- 支持在单窗口内切换多个终端会话
- 基于
xterm.js + node-pty提供接近原生终端的交互体验 - 持久化会话元数据，应用重启后可重新恢复会话
- 创建会话时保存 Claude 的本地
session_id - 重新打开会话时优先走
claude --resume <session_id> - 若恢复信息不完整，会尝试从本地 Claude 历史中推断并回填
- 当恢复链路不可用时，可以直接为该会话新开一条 Claude 对话
- 内置 Kanban 风格任务面板
- 任务包含标题、描述、工作目录
- 支持状态流转：
createdreadyrunningpauseddonefailed
- 用户可以手动创建任务、激活任务、完成任务、删除任务、重新激活任务
- 内置 worker 池，按可用槽位自动分发任务
ready任务会被调度为running- 调度器会自动为任务创建 session，并把任务描述写入 Claude 会话
- 当任务关联的会话退出后，任务会转为
paused - 用户可以在合适的时机恢复该 session，继续推进任务
- 应用重启后，调度器会恢复任务与 worker 槽位的关联状态
- 查看当前 worker 池占用情况
- 查看活跃 session 列表
- 从监控页直接跳转到对应 session
- 提供配置页管理最大 worker 数量
- 配置持久化到本地文件
- 可直接查看和打开配置文件路径
- 使用 SQLite 保存 session 与 task 元数据
- 运行数据统一存放在
~/.agent-tool - 应用重启后保留历史状态，不依赖终端窗口继续存在
- 同时推进多个需求、多个 bug、多个重构任务
- 多微服务并行开发
- 一个主需求下拆出多个可并行子任务，让不同 agent 分头执行
- 希望减少“盯着多个终端窗口来回切换”的精力损耗
- 希望把临时想到的后续任务显式挂到任务系统里，而不是散落在备忘录里
当前应用包含 4 个主页面：
Tasks：任务看板，作为任务调度入口Sessions：会话列表与终端交互界面Monitor：worker 池与活跃 session 监控Config：本地配置管理
更推荐的使用方式不是“先开一堆 session”，而是：
- 先创建任务。
- 把准备好执行的任务激活为
ready。 - 让调度器在 worker 池中自动分配执行。
- 在
Monitor和Sessions中观察进展。 - 当某个任务需要人工介入或继续推进时，再恢复对应 session。
- Electron
- React + TypeScript
- Zustand
- xterm.js
- node-pty
- better-sqlite3
- Tailwind CSS
- Vite
应用运行时会在本地创建如下数据目录：
~/.agent-tool/
├── agent-tool.db
├── config.json
├── logs/
├── crashDumps/
└── session-data/
其中：
agent-tool.db用于保存 sessions 和 tasksconfig.json用于保存应用配置，例如maxWorkers
- Node.js 18+
- npm
- 本机可正常执行
claude命令 - 已配置 Claude CLI 所需的认证与环境变量
npm installnpm run devnpm run buildnpm start由于项目依赖 node-pty 和 better-sqlite3，如果 Electron 版本或本机环境变化后出现原生模块问题，可执行：
npm run rebuild也可以直接执行：
npx electron-rebuild当前项目中的 npm run rebuild 实际就是执行 electron-rebuild，两者效果基本等价。
当前任务状态语义如下：
created：任务已创建，但还未进入调度队列ready：任务已激活，等待调度器分配 workerrunning：任务已被调度，正在执行，或等待重新占用 workerpaused：关联 session 已退出，任务暂时停住，等待用户继续推进done：任务已完成failed：任务执行失败，可重新激活
这套状态机体现的不是“AI 全自动完成一切”，而是“AI 执行 + 人接力确认”的协作过程。
当前实现仍然是一个早期版本，边界也比较明确：
- 目前实际聚焦的是
Claude CLI，还不是通用的多 CLI 适配平台 - 配置页保存
maxWorkers后，只影响后续启动，不会立即热更新当前 worker 池 - 任务调度目前以单机本地执行为主，不涉及分布式执行
- 还没有把“想法记录 / 后续依赖任务 / 更复杂的任务编排关系”完整建模出来
- 同项目多任务的代码隔离问题，目前仍主要依赖使用者自行规划工作目录
这个项目并不打算把“完全自治”当作第一目标。
原因很简单：当前 AI 在很多编码任务上已经足够有帮助，但还不足以稳定地长时间独立推进复杂任务而不偏航。相比让系统自动编排一切、自动运行很久、最后再由人接收结果，我更看重以下几点：
- 人能随时看到任务处于什么阶段
- 人能方便地切回某个 agent 继续协作
- 人不会因为窗口分散和状态割裂而丢失上下文
- 人可以低成本地把并行任务组织起来
所以它更像是一个“人机协作的任务调度器”，而不是一个“替你完全自治的软件工程团队”。
接下来值得继续推进的方向包括：
- 更完善的多 CLI 适配层，而不局限于 Claude
- 更强的任务依赖与任务链编排能力
- 更适合并行开发的工作区隔离方案
- 更清晰的提醒、通知与任务接力机制
- 围绕任务而不是会话的操作流进一步打磨
这个项目想解决的，不是“如何再多开几个 AI”，而是“当 AI 会话越来越多之后，人怎么还能保持顺畅地工作”。
如果说传统的 AI CLI 更像是给你一个更强的终端搭档，那么 Agent Task Orchestrator 想做的是：把这些搭档组织起来，让它们围绕任务协同工作，同时始终把人放在调度与决策的中心。