RFC: Mycel Modular Architecture — 拆分为独立服务

[nmhjklnm]

背景

当前 Mycel 是一个 FastAPI 单体，所有功能耦合在同一进程中（lifespan.py 初始化 15+ 个 service，app.state 作为隐式全局状态）。导致：

• 任何模块启动失败，整个后端挂掉
• 难以独立调试和测试单个功能
• 无法按模块独立部署和扩缩容

目标架构

服务	职责	部署位置
mycel-agent	Agent 运行时 + LLM 调用 + 工具决策	中心服务器
mycel-container	Sandbox 生命周期编排（创建/销毁/监控）	中心服务器
mycel-chat	消息路由 + 通讯录 + 好友关系	中心服务器
mycel-hub	市场（已独立）	中心服务器
mycel-admin	管理面板	中心服务器
sandbox-daemon	轻量 fs/shell 执行器	sandbox 目标（云/用户电脑）

前端保持单 SPA，不拆分（各 store 已按功能域隔离，天然支持多后端）。

耦合分析

当前模块间依赖（无循环依赖，均为单向）：

mycel-chat ←── mycel-agent（delivery callback）
mycel-container ←── mycel-agent（sandbox 创建/销毁）
mycel-hub ←── 无（已独立）
mycel-admin ←── 读 member_repo/thread_repo（只读）

各模块拆分难度：

模块	难度	关键阻塞
mycel-chat	★☆☆☆☆	仅 3 个外部触点：avatar_url、FastAPI deps、member/thread 查询
mycel-admin	★★☆☆☆	前端已独立部署，后端改为直连 Supabase 或轻量 BFF
mycel-container	★★★☆☆	sandbox/ 不依赖 core/（零反向 import），需定义 SandboxProvider 协议
mycel-agent	★★★★☆	依赖 chat（消息投递）和 container（沙箱执行），是耦合中心

数据层设计

共享一个 Supabase PostgreSQL 实例，按 schema 隔离数据归属。

Schema 划分

Supabase PostgreSQL
  ├── identity.*    ← 共享 schema（所有服务可读，仅 auth 服务可写）
  │                   members, accounts
  ├── chat.*        ← mycel-chat 独占
  │                   messages, chat_members, relationships, message_reads
  ├── agent.*       ← mycel-agent 独占
  │                   threads, events, queue, agent_configs
  ├── container.*   ← mycel-container 独占
  │                   leases, container_events, sandbox_configs
  └── hub.*         ← mycel-hub 独占（已有）
                      marketplace_items, versions, downloads

规则

• 只能读自己的 schema + identity.*，不能直接查别人的 schema
• 跨模块数据通过 API 获取，不走直接 SQL join
• 现有 SQLite 文件（sandbox.db、events.db 等）收敛进 Supabase 对应 schema
• ~/.leon/members/ 等文件系统数据迁入 agent.* 表或对象存储

数据迁移路径

现状	目标 schema	说明
Supabase public.members, public.accounts	identity.*	rename schema
Supabase public.messages, public.chat_members, public.relationships	chat.*	rename schema
Supabase public.marketplace_items	hub.*	rename schema
SQLite ~/.leon/sandbox.db	container.*	迁移到 Supabase
SQLite ~/.leon/events.db, queue.db	agent.*	迁移到 Supabase
文件系统 ~/.leon/members/	agent.* + Supabase Storage	结构化存储

拆分顺序

Phase 1: mycel-chat（消息 + 通讯录 + 好友关系）
  - 当前耦合最低，messaging/ 已有清晰边界
  - 仅需搬 avatar_url、换 FastAPI deps、迁 chat.* schema
  - 产出：独立服务 + 独立 schema

Phase 2: mycel-agent（Agent 运行时 + 工具链）
  - 依赖 Phase 1 完成（消息投递改为跨服务 API）
  - SQLite → Supabase agent.* schema 迁移
  - ~/.leon/ 文件系统数据结构化

Phase 3: mycel-container（Sandbox 生命周期）
  - 依赖 PoC 验证 WebSocket 通信可行性（见 #267）
  - 拆出 sandbox-daemon + container 控制面
  - sandbox.db → Supabase container.* schema

Hub 和 Admin 已独立或接近独立，不阻塞主线。

相关

• PoC: Remote Sandbox — Agent ↔ Sandbox via Supabase Realtime #267 — PoC: Remote Sandbox 通信验证