Mission Control 是一款面向独立创业者的开源 AI 智能体任务管理指挥中心，它的架构核心是"本地优先（Local-First）+ JSON 作为人与 AI 智能体共享的数据源"——没有数据库、没有云服务，你（人）和 AI 智能体读写的是同一组 JSON 文件。这篇文章带你看懂这套设计为什么如此与众不同，以及它如何真正做到"人类管决策，智能体管执行"。

一、Mission Control 是什么？给 AI 智能体的任务管理指挥中心

传统任务管理工具（Linear、Asana、Notion）是为"人类填表单"设计的。而 Mission Control 从第一天起就是agent-first（智能体优先）的：

• 📥Brain Dump：随手记录一个想法
• 🔍研究：Researcher 智能体调研市场，输出 Go/No-Go 报告
• 🛠️构建：Developer 智能体搭建 MVP
• 🚀发布：Field Ops 执行真实动作——发帖、付款、投放广告，全程带审批流和花费上限

你在整个流程中可能只做三次决策，剩下的交给智能体完成。

下图展示了从"记录想法"到"智能体执行"的完整工作流：

二、架构全景：一个数据层，三类使用者

打开 README.md 的 Architecture 章节，你会看到整个系统的分层极其克制：

┌─────────────┬──────────────┬────────────────┐ │ Web UI │ AI Agents │ Daemon 守护进程 │ │ (人类操作) │ (Claude Code │ (24/7 自动化) │ │ │ Cursor 等) │ │ └──────┬──────┴──────┬───────┴────────┬───────┘ │ API 路由 │ 直接读写文件 │ ▼ ▼ ▼ ┌─────────────────────────────────────┐ │ data/ 目录（JSON 文件 = 唯一真相源） │ └─────────────────────────────────────┘

关键就一句话：data/目录是唯一真相源（Source of Truth）。人类通过 Web 界面、智能体通过文件或 API、守护进程通过轮询——三者操作的是同一份数据，因此天然不存在"同步"问题。

三、本地优先：不装数据库，所有数据就在一文件夹里

这是 Mission Control 最"反常规"的决策：存储层不是 SQLite、不是 Postgres，而是明文 JSON 文件。

mission-control/data/目录下的核心文件构成：

这样做的好处非常直接：

• 📂零运维：pnpm dev就能跑，不需要部署任何数据库服务
• 🔍全透明：智能体做了什么？cat activity-log.json一目了然，黑盒变白盒
• 💾可备份：备份整个data/目录就等于备份了全部工作区；项目还内置了 Checkpoint 机制，把整组核心数据快照到 mission-control/data/checkpoints/，随时可回滚
• 🚪零锁定：数据格式公开、可读、可迁移，随时能导出

四、JSON 作为共享数据源：人机如何"说同一种话"？

既然 JSON 是人和 AI 的"共同语言"，那么双方靠什么约定来协作？答案是一份"操作手册"——根目录的 CLAUDE.md。

它定义了完整的数据 Schema（每个字段的类型、取值范围）和智能体通信协议：

• 收件箱：智能体把完成报告写入 inbox.json，人类在 Web 界面读取并回复
• 决策请求：智能体遇到需要人类判断的问题时，向 decisions.json 提交问题 + 选项，人类在 UI 中点选回答
• 活动日志：一切重要变更都追加到 activity-log.json，形成完整审计链

这意味着：任何一个能读文件的 AI 工具（Claude Code、Cursor、Windsurf 甚至一个普通脚本）都可以即插即用地加入这个工作区——这就是项目的 BYOAI（Bring Your Own AI）理念。

五、多智能体并发写 JSON，如何保证不写坏数据？

"用 JSON 文件存数据"听起来朴素，但真正的工程含量在这里：当多个智能体同时写文件时，如何避免数据损坏？

Mission Control 的答案是三层防线：

1. Zod 校验：所有 API 写操作先过 Zod 模式校验（项目实际引入本地依赖，非外链），字段错误在入口处被拦下，脏数据根本进不了文件
2. 按文件互斥锁：数据访问层 mission-control/src/lib/data.ts 为每个数据文件维护一个async-mutex互斥锁，两个智能体同时写tasks.json时会自动排队，绝不交叉
3. API 认证与 CSRF 防护：mission-control/src/middleware.ts 实现了常量时间字符串比较防时序攻击，并对跨站请求的 Origin 做校验

CLAUDE.md 中还明确写了智能体的"写入策略"：读取可以直接读文件（快），写入必须走 API（安全）。这种"读快写稳"的分工，是共享数据源架构能落地的关键。

六、Token 优化：让 AI 读数据的成本降到最低

AI 智能体每次读取数据都要消耗 token（钱）。如果智能体每次都加载几个上万 token 的原始 JSON，效率会很差。Mission Control 为此做了两个专门的优化：

• 压缩上下文快照：运行pnpm gen:context（脚本见 mission-control/scripts/generate-context.ts），把整个工作区状态压缩成约 650 token 的ai-context.md摘要，智能体先看摘要、按需再查细节
• 稀疏查询 API：API 支持过滤和字段裁剪，例如GET /api/tasks?assignedTo=developer&kanban=in-progress&fields=id,title,kanban——官方数据：约 50 token 就能拿到一个智能体当前该干的活，而读取全量数据需要约 5400 token，压缩率约 92%

对"JSON 文件当共享数据源"这套架构来说，token 优化等于把"共享"的成本降到了可接受的范围。

七、自治守护进程：让任务 7×24 小时无人值守

data/目录里的 daemon-config.json 配置了一个自治守护进程（源码在 mission-control/scripts/daemon/）：

• 轮询：每 5 分钟检查tasks.json是否有待办任务，有则自动启动 Claude Code 会话执行
• 定时任务：用 cron 表达式定时跑daily-plan（每日计划）、standup（每日站会）、weekly-review（每周回顾）
• 并发控制：最多同时运行 6 个智能体会话，超时、重试、续跑都有配置

它的/daemon仪表盘可以实时查看运行状态、启动/停止会话：

而且这个守护进程不监听任何网络端口——它是一个纯本地进程，零网络攻击面，这与其"本地优先"的哲学一脉相承。

八、安全设计：把 AI 智能体关进"有围栏的游乐场"

当智能体开始执行真实动作（发帖、转账）时，安全就是底线。项目为此做了分层防御：

• 加密保险库：AES-256-GCM 加密 + scrypt 密钥派生存储服务凭证
• 财务安全控制：每个服务 + 全局的花费上限，外加可一键熔断的"断路器"
• 三级自治：全手动审批 / 高风险审批 / 全自动，且自治级别修改需要主密码
• 紧急停止按钮：一键终止守护进程、暂停所有任务并锁定保险库
• 凭证清洗：日志中的所有密钥信息在写入前被自动脱敏

设计目标用官方一句话概括："Mission Control 是围栏游乐场——智能体可以在里面撒欢，但很安全。"

九、快速上手：三步在本地跑起 Mission Control

本地优先架构的最大红利就是：起步成本极低。

git clone https://gitcode.com/gh_mirrors/missionco/mission-control cd mission-control/mission-control pnpm install pnpm dev

打开http://localhost:3000，点击"Load Demo Data"即可用示例任务、智能体和消息体验完整功能。想要让智能体真正执行任务，再安装 Claude Code 并在该工作区打开即可。

十、总结：一个朴素决策带来的架构红利

回看 Mission Control 的架构哲学，最核心的其实就一个朴素决策：把 JSON 文件当作人与 AI 共享的数据库。

由它推导出来的一切都很自然——不需要同步层（大家读写同一份文件）、不需要专有 SDK（任何会读文件的 AI 都能参与）、天然透明可审计（明文 + 活动日志）、备份就是复制文件夹、上手只需pnpm dev。再配上 Zod 校验、文件级互斥锁、token 优化 API 和分层安全控制，这套"本地优先 + JSON 共享数据源"的设计，为"人类做决策、AI 干执行"的智能体时代提供了一个既简单又稳健的底座。🚀