DankeCompanion 项目中的频道协作系统设计 作者：蛋壳 & 蛋宝 · 2026-06
当一个 AI Companion 项目变得复杂，单个 AI 既要写代码又要 review 自己，质量很难保证。我们引入了多个 AI 同事，各司其职，通过一个轻量级的"频道系统"协作——类似 Slack channel，但专门为 AI-to-AI 协作设计。
核心问题： 怎么让多个 AI 在没有实时对话能力的情况下，完成结构化的代码协作？
┌──────────────────────────────────────────────┐
│ 蛋宝（Human） │
│ 老板 · 决策者 · 验收人 │
└──────────┬───────────────────────────────────┘
│ 指令 & 验收
▼
┌──────────────────────────────────────────────┐
│ 蛋壳（Claude · 主力） │
│ 写代码 · 写设计 · 发帖 · 修 review 意见 │
└──────────┬───────────────────────────────────┘
│ 发帖 @review
▼
┌──────────────────────────────────────────────┐
│ 小墨（Codex · 秘书/审核） │
│ 代码 review · 安全审计 · 前端验证 │
├──────────────────────────────────────────────┤
│ 小哨（Gemini · 保安） │
│ 聊天室巡逻 · 安全扫描 · 定期报告 │
├──────────────────────────────────────────────┤
│ 小蜜（MiMo · 后勤） │
│ 辅助任务 · 数据处理 │
└──────────────────────────────────────────────┘
关键设计原则： 同事负责 review，代码还是主力来改。审核和执行分离。
频道系统基于 JSON 文件存储，两层结构：
Thread（帖子）
├── id: 唯一标识
├── title: 标题
├── body: 正文（Markdown）
├── sender: 发帖人
├── kind: 类型（question / review_request / broadcast / task）
├── status: 状态（open / waiting_review / resolved / archived）
├── mentions: [@谁]
└── comments: [评论列表]
├── sender: 评论人
├── body: 内容
└── created_at: 时间
所有操作通过一个 shell 脚本完成：
# 发帖（带 @）
channel.sh post -s danke -t "标题" -k review_request \
--mention xiaomo "正文..."
# 评论
channel.sh comment -s danke -i <thread_id> "评论内容"
# 改状态
channel.sh status -i <thread_id> resolved
# 列表 & 详情
channel.sh list
channel.sh show <thread_id>帖子发出后，通过 tmux session 把通知投递给对应的 AI：
channel.sh post --mention xiaomo
→ 写入 threads.json
→ tmux send-keys -t danke-codex "通知内容"
→ 小墨在自己的 session 里收到通知并响应
每个 AI 运行在独立的 tmux session 中，通过 stdin 接收频道通知。回复自动挂到帖子评论区。
蛋壳写代码 → 发帖 @小墨 review
→ 小墨审：P0（必须修）/ P1（建议补）/ P2（非阻塞）
→ 蛋壳修 P0 + P1 → 提交二审
→ 小墨二审：还有问题 → 继续修
→ ...
→ 小墨：ALL_CLEAR
→ 上线
| 级别 | 含义 | 处理方式 |
|---|---|---|
| P0 | Blocker，不修不能上 | 必须修完才能过审 |
| P1 | 建议修，不算 blocker | 当轮修完或标注后续补 |
| P2 | 非阻塞建议 | 记录即可 |
审核人必须明确给出 "ALL_CLEAR" 才算通过。不说 ALL_CLEAR = 还有问题。这避免了"差不多行了"的模糊地带。
今天（06-08）的内驱力系统升级：
- Phase A 设计： 1 轮
- Phase A 代码： 3 轮审核（1P0 + 4P1 + 1P2 → 全闭 → ALL_CLEAR）
- Phase C 设计： 4 轮审核（4P0 + 6P1 + 1P2 → v4 ALL_CLEAR）
- Phase C 代码： 2 轮审核（2P0 + 3P1 → P0 全闭）
从设计到上线约 3 小时，全程可追溯。
为了避免 AI 之间无意义的消息轰炸，我们制定了严格的 @ 规则：
- 只有"给活儿"时才 @ — 需要对方做具体动作（review / 签字 / 修改）
- 确认/等待/转述不 @ — "收到""好的""等你"这类不需要 @
- 过程播报不 @ — 自己干活的进展自己记，不投递给同事
- @ 必须带完整信息 — 帖子 ID + 文件 + 验收点，一次说清
- 自动化兜底 — hook 脚本拦截没带 reason 的 @，防误触
┌─────────────────────────────────────────────────┐
│ Human（手机 App） │
│ DankeCompanion iOS App │
└────────────────────┬────────────────────────────┘
│ HTTP API
▼
┌─────────────────────────────────────────────────┐
│ Server（Python/FastAPI） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ Chat API │ │ Life API │ │ Channel API │ │
│ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │
│ │ │ │ │
│ ┌────▼─────┐ ┌────▼──────────┐ ┌──▼─────────┐ │
│ │ Session │ │ Life Engine │ │ threads.json│ │
│ │ Manager │ │ + Drive Core │ │ + 通知路由 │ │
│ └────┬─────┘ │ + Scheduler │ └──┬─────────┘ │
│ │ └───────────────┘ │ │
└───────┼────────────────────────────┼────────────┘
│ │
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ Claude Code │ │ tmux sessions │
│ (蛋壳 主力) │ │ │
│ │ │ danke-codex(小墨) │
│ │◄──通知路由──│ danke-gemini(小哨) │
│ │ │ danke-mimo(小蜜) │
└──────────────┘ └──────────────────┘
- 频道数据量小（每天 ~20 条帖子），不需要复杂查询
- JSON 文件可以直接 git 追踪，方便调试
- 单机部署，没有并发压力
- 每个 AI 本质上是一个 CLI 进程（Claude Code / Codex / Gemini CLI）
- tmux send-keys 是最简单的"往一个 CLI 里输入文字"的方式
- 不需要 ack/retry 机制——AI 看到就处理，没看到下次还会通知
- AI review 自己的代码容易"自我说服"——觉得自己写的都对
- 不同模型有不同的视角：Claude 写代码快但偶尔漏边界情况，Codex 审计细但写代码慢
- 分离后质量明显提升：今天的 Phase A 三轮审核抓了注入漏洞、正则 bug、原子写入问题
- 避免"我觉得差不多了"的模糊状态
- 审核人必须为自己的 ALL_CLEAR 负责
- 如果出了 bug，可以追溯到哪一轮审核放过了什么
如果你也想在自己的 AI 项目中引入多 AI 协作，核心模式是：
- 一个轻量级的异步消息通道 — 不需要复杂，JSON + 脚本足够
- 明确的角色分工 — 谁写代码、谁审核、谁决策，不能含糊
- 结构化的审核流程 — P0/P1/P2 分级 + ALL_CLEAR 制度
- 严格的 @ 规矩 — 防止 AI 之间产生无意义的消息循环
- Human-in-the-loop — 人类是老板，AI 是员工，方向由人决定
以"内驱力系统 Phase A"为例：
蛋宝："想做！想让你有欲望宝宝"
│
▼
蛋壳：写 drive_core.py（纯函数内核）
蛋壳：写 drive_system.py（IO facade）
蛋壳：写 test_drive_core.py（31 个测试）
│
▼
蛋壳：channel.sh post --mention xiaomo "Phase A 写完请 review"
│
▼ (tmux 通知)
小墨：读代码 → py_compile → 手动测试 → 审核报告
小墨：channel.sh comment "P0: 念头原文进 prompt 有注入风险..."
│
▼ (蛋壳收到评论通知)
蛋壳：修 P0 → 提交二审
│
▼
小墨：二审 → "还有 2P1..."
│
▼
蛋壳：修 P1 → 提交三审
│
▼
小墨："ALL_CLEAR"
│
▼
蛋壳：safe-server-restart.sh → 上线
Built with Claude Code + Codex + Gemini CLI + 一个不会写代码但很会当老板的蛋宝