Mission Control：自托管 AI 代理控制平面，用 SQLite 管住任务与花费
项目速览：用于 AI 代理的自托管控制平面：调度任务、审查运行、跟踪支出以及操作 OpenClaw、Claude Code、Codex 和其他运行时。
秒懂
- 它是什么？
- Mission Control 是一个面向多代理、多运行时场景的自托管控制平面，用 SQLite 存储状态，提供任务派发、审查、花费追踪和治理功能。它不替代代理的推理循环，而是补上运营层。
- 适合谁用？
- Mission Control 适合那些同时运行多个代理或运行时，且难以回答“谁负责哪个任务、哪个结果通过了审查、花费和失败堆积在哪里”的团队。它不适合单代理单机器、需要托管多租户 SaaS、或需要框架来定义规划工具的场景。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月17日）和我们的分析，不构成法律意见。
开源项目深度解析
代理多了，问题就变了
单个代理在单台机器上跑，原生 CLI 足够。一旦有多个代理、多个运行时，比如 OpenClaw、Claude Code、Codex 混在一起，你就需要回答几个问题：这个任务谁负责？哪个结果通过了审查？花费和失败堆积在哪里？Mission Control 就是为回答这些问题而生的。它把自己定位为控制平面，而不是代理框架。它不替代代理的推理和工具循环，而是给这些循环周围的工作提供一个运营视图。README 里明确说，它不属于任何运行时，而是站在它们之上。这个定位很关键，意味着你不需要重写代理逻辑，只需要接入它的 API 和观察面。
SQLite 后端，状态在本地
Mission Control 用 SQLite 存储控制平面状态，整体自托管。这意味着你的任务、代理注册、花费记录和审计日志都留在自己机器上，不经过第三方服务。架构上，它提供 REST API、WebSocket、SSE、CLI 和 MCP server 多种接口。一个可选的 gateway 用于任务、项目、代理、调度器、webhook、告警和花费工作，但实时会话消息需要连接运行时 gateway。这种设计让最小部署可以完全离线，只依赖本地 SQLite。不过，这也意味着如果你需要跨机器共享状态，就必须自己处理 gateway 和持久化，文档里提到了部署指南，但没有给出具体的集群方案。
启动：一条命令，一个端口
本地启动很简单，需要 Node.js 22 或更新版本以及 pnpm。克隆仓库后运行 `bash install.sh --local`，然后打开 `http://localhost:3000/setup` 创建第一个管理员账户，再从 Settings 复制 API key。手动方式也支持，`pnpm install` 加 `pnpm dev` 即可。Windows 用户可以用 `./install.ps1 -Mode local`。Docker 用户直接 `docker compose up`，或者拉取多架构镜像 `ghcr.io/builderz-labs/mission-control:latest` 运行。对于需要网络访问的部署，文档提供了一个 hardened Compose overlay，`docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d`。这个 overlay 显然是针对安全加固的，但没有细节说明它具体加固了什么，你需要读 deployment guide 才能知道。
任务流转：从收件箱到完成，Aegis 卡在中间
任务板把工作分成几个阶段：收件箱、分配、执行、审查、质量审查、完成。其中 Aegis 质量门是个硬性要求，一个任务要到达完成状态，必须有一条批准记录。这不是可选的软检查，而是流程的一部分。你可以通过 REST API 注册代理、创建任务，然后代理自己轮询队列。示例里 `curl -X POST /api/agents/register` 注册一个叫 scout 的代理，`curl -X POST /api/tasks` 创建任务并分配给 scout，最后 `curl /api/tasks/queue?agent=scout` 让代理认领。这个流程很直接，但注意，Aegis 审查需要人工或自动化批准记录，这意味着你不能完全放手让代理自动跑完，审查环节是强制的。
花费追踪和治理，不只是任务列表
Mission Control 覆盖的不只是任务。它有活动流、调度器、告警、webhook、日志、token 使用和花费视图。治理层面包括角色、API key、安全事件、信任信号、批准、审计和评估。这些功能放在一个控制平面里，说明作者考虑的是运营责任，而不只是任务分发。比如，花费视图和 token 使用数据，能帮你回答“上个月代理烧了多少钱”这种问题。但注意，这些数据来自 SQLite 本地存储，如果你有多个 gateway 或分布式部署，数据聚合方式需要额外确认。文档没有给出多实例花费合并的细节。
适配器深度不齐，别假设功能对等
README 列出了 OpenClaw、Claude Code、Codex、CrewAI、LangGraph、AutoGen 和 Claude SDK 工作流的适配器和观察面。但紧接着有一句警告：适配器深度因运行时而异，使用前需要阅读 agent setup 和 CLI integration 文档，不要假设功能对等。这是一个诚实的提醒，也是一个实际的限制。如果你的团队主要用 Claude Code，那么接入 Mission Control 可能很顺滑，但如果你依赖某个小众运行时的特殊功能，可能发现适配器只支持基础的心跳和任务队列，不支持更复杂的会话管理。这种不均衡是自托管控制平面的常见问题，因为每个运行时的 API 和权限模型都不同。
alpha 阶段的风险和升级成本
Mission Control 明确标注为 alpha 软件。README 用警告框提示：API、schema 和配置可能在版本之间变化。最近发布的 v2.3.0 是依赖安全补丁、工具链刷新和 locale 完整性更新，v2.2.0 是安全加固和工作区隔离。这些版本号表明项目在快速迭代，但快速迭代意味着升级时你可能需要迁移数据或调整配置。没有提供迁移工具或升级路径的细节。如果你在生产环境使用，每次升级前必须测试。另外，MIT 许可证意味着你可以自由使用和修改，但没有任何担保，安全问题需要自己负责。对于不能容忍 schema 变更的团队，这是明确的阻碍。
什么时候别用它
项目自己列出了不适合的场景：单个代理单机器、需要托管多租户 SaaS、需要一个框架来定义规划工具、或者不能容忍 alpha 变更。这些判断很直接。如果你只是用 Claude Code 在本地写代码，原生 CLI 就够了，Mission Control 反而增加复杂度。如果你需要一个多租户平台，自托管控制平面不是答案，你该找 SaaS。如果你想用框架来定义代理的规划和工具使用，Mission Control 不提供这种能力，它只做运营层。一个更贴近的替代方案是直接使用各运行时的原生 API 和日志，比如 Claude Code 的 CLI 输出和 Codex 的会话历史，加上一个简单的脚本聚合花费，但那样你就失去了统一的审查门和治理层。Mission Control 的价值在于把分散的运营数据集中到一个 SQLite 数据库里，如果你不需要这种集中，它的价值就大打折扣。
编辑结论
Mission Control 适合那些同时运行多个代理或运行时，且难以回答“谁负责哪个任务、哪个结果通过了审查、花费和失败堆积在哪里”的团队。它不适合单代理单机器、需要托管多租户 SaaS、或需要框架来定义规划工具的场景。在采用前，先验证两件事：一是你能否接受 alpha 阶段的 schema 和 API 变更，二是你的运行时适配器深度是否满足需求，文档明确警告适配器深度因运行时而异，不要假设功能对等。如果你的部署无法容忍破坏性变更，或者你只是需要一个更简单的 CLI 管理单个代理，那么这不是正确的工具。最后，检查你的网络暴露方式，阅读安全指南，并使用 hardened Compose overlay 进行生产部署。
社区笔记