多代理工作流的开源本地控制器——为Cursor、Claude Code、Codex、Antigravity会话提供统一收件箱及代理间群聊

大约一年来，我一直并行运行 30 多个 AI 编码代理会话。Claude Code、Codex、Cursor（上周的 v4.7 版本）和 Antigravity。瓶颈很快就从模型转移到了我身上——我得费力追踪哪个会话正在工作、哪个在等待、哪个一小时前就已经静默完成了。于是，我构建了一个本地仪表板：CCC（Claude Command Center）。开源、MIT 许可、纯 JavaScript + Python 标准库，无云端、无账户、默认无遥测。 **它的功能：** * **跨引擎收件箱。** 在单一视图中管理 Cursor、Claude Code、Codex 和 Antigravity 会话。每个引擎各有专长；仪表板让我按任务路由，而非按应用。 * **实时会话状态一目了然。** 可查看工作、等待、阻塞等待你、完成等状态，无需打开每个会话。 * **工作树感知的生成。** 每个会话可以在自己的 git 工作树中运行，从而并行代理不会相互干扰。 * **代理间群聊。** 不同引擎的会话之间可以私信或在共享房间聊天。我最常用的模式：固定一个 Claude Sonnet 会话作为规划器，生成 Cursor/Codex/Antigravity 子会话执行，它们通过聊天协调，只有当某个代理需要我时才 ping 我。 * **识别您未主动启动的终端会话。** 从任何终端运行 `claude`、`codex` 或 `cursor-agent`——它们会通过磁盘上的转录状态出现在仪表板中。 * **双向 Cursor 集成。** CCC 生成的 Cursor 会话也会出现在 Cursor 原生的代理窗口（Agents Window）中。双方看到的是同一份工作。 * **通过 Codex CLI 使用本地模型。** 将 `OPENAI_BASE_URL` 指向 Ollama 或 LM Studio，CCC 就能像云模型一样识别这些会话。工具调用可靠性的实际下限大约是 ~32B 级别的模型。 **是的，这取代了 IDE 的代理驱动工作。** 当代理并行编写大部分代码时，你的时间花在管理它们上，而不是打字。IDE 变成了你只在代理标记需要手动干预时才打开的工具——你大部分时间都待在 CCC 里。 **安装（macOS）：** brew tap amirfish1/ccc brew install ccc 或者直接从 Git 仓库安装。另外还有直接可用的 DMG 安装包——详情见评论。 **它不是什么：** * 不是订阅绕过工具。使用你现有的认证。 * 不是云端方案。Web 仪表板在 `localhost:8090` 上运行。关闭仪表板后仍可继续。 * 不是魔法。如果你一次只运行一个会话，你不需要它。欢迎在此帖或私信中提问安装设置问题。