系统流程
GCA 系统中各个核心流程的完整走查
1. 客户端启动流程
客户端打开后的完整启动链路
- App 启动 → 加载本地配置（Gateway 地址、Token、代理设置）
- 启动 MCP Server → 客户端内置 MCP Server 开始监听，暴露本机能力（file/exec/screen/sysinfo 等）
- 连接 Gateway → WebSocket 连接 OpenClaw Gateway，发送认证 Token
- 注册设备 → 向 Gateway 报告设备信息（名称、IP、OS、能力列表）
- 开始心跳 → 每 30 秒发送心跳，Gateway 更新设备在线状态
- OTA 检查 → 启动 3 秒后检查一次更新，之后每 24 小时检查一次
- 就绪 → 设备出现在 Gateway 设备列表中，可被 AI 或其他设备调用
客户端启动
│
├── 1. 读取本地配置
│ └── Gateway URL / Token / 代理 / 设备名
│
├── 2. 启动 MCP Server
│ └── 注册 36 个 MCP Tools (file/exec/screen/sysinfo/...)
│
├── 3. 连接 OpenClaw Gateway
│ ├── WebSocket → ws://gateway:port
│ └── 发送认证 Token
│
├── 4. 注册设备
│ └── { name, ip, os, capabilities }
│
├── 5. 心跳循环 (30s)
│ └── 持续上报设备状态
│
└── 6. OTA 检查 (启动后 3s + 每 24h)
└── expo-updates 检查 → 静默下载 JS bundle
2. AI 控制设备流程
用户通过任意通道发送自然语言指令
- 用户发消息 → 通过微信/飞书/Telegram/自建客户端发送："看看服务器磁盘满了没"
- Gateway 接收 → OpenClaw Gateway 的 AI Agent 接收消息，理解意图
- AI 选择工具 → AI 决定调用
exec 工具，参数 device="cloud-svr", command="df -h"
- Gateway 路由 → Gateway 将 MCP Tool 调用转发到 cloud-svr 客户端
- 客户端执行 → cloud-svr 的 MCP Server 执行
df -h，返回磁盘信息
- AI 格式化 → AI 将原始数据格式化为易读的回复
- 回复用户 → 通过原通道返回结果给用户
用户: "看看服务器磁盘满了没"
│
▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 任意通道 │───▶│ Gateway │───▶│ cloud-svr │
│ 微信/飞书/ │ │ AI Agent │ │ 客户端 │
│ Telegram │ │ │ │ MCP Server │
└─────────────┘ └──────┬──────┘ └──────┬──────┘
│ │
│ MCP Tool 调用 │
│ exec("df -h") │
│──────────────────▶│
│ │
│ 执行结果 │
│◀──────────────────│
│ │
│ AI 格式化回复 │
▼ │
"磁盘使用率 78%， │
剩余 120GB" │
│ │
▼ │
回复给用户 │
3. 人工远程控制流程
用户通过客户端直接操控远端设备（类 TeamViewer）
- 选择设备 → 在客户端设备列表中点击目标设备
- 发起远程桌面 → 客户端发送
screen_stream_start 请求
- 建立数据通道 → 客户端与目标设备建立 WebSocket 直连（不经过 Gateway，低延迟）
- 屏幕推流 → 目标设备以 MJPEG 格式推流（15-30fps）
- 输入转发 → 用户的鼠标/键盘操作通过数据通道实时转发到目标设备
- 剪贴板同步 → 双向剪贴板同步（可选）
- 结束 → 用户断开，数据通道关闭
用户客户端 Gateway 目标设备
│ │ │
│ ① 请求远程桌面 │ │
│ MCP: screen_stream_start │ │
│───────────────────────────▶│ │
│ │ ② 转发请求 │
│ │─────────────────────────▶│
│ │ │
│ │ ③ 返回数据通道地址 │
│ │◀─────────────────────────│
│ ④ 数据通道地址 │ │
│◀───────────────────────────│ │
│ │
│ ⑤ 直连数据通道 (WebSocket) │
│◀══════════════════════════════════════════════════════▶│
│ │
│ ⑥ 屏幕推流 (MJPEG 15-30fps) │
│◀──────────────────────────────────────────────────────│
│ │
│ ⑦ 鼠标/键盘事件 │
│───────────────────────────────────────────────────────▶│
│ │
│ ⑧ 剪贴板同步 (可选) │
│◀══════════════════════════════════════════════════════▶│
4. AI 自动操控应用流程
AI 代理自动操作设备上的应用（无需人工干预）
- 用户指令 → "帮我打开 Chrome，搜索今天的天气"
- AI 分解任务 → ① 启动 Chrome ② 打开 Google ③ 输入搜索词 ④ 点击搜索
- 执行 Step 1 → MCP Tool:
exec("home-pc", "start chrome")
- 执行 Step 2 → MCP Tool:
browser_open("home-pc", "https://google.com")
- 执行 Step 3 → MCP Tool:
browser_fill("home-pc", "input[name=q]", "今天天气")
- 执行 Step 4 → MCP Tool:
browser_click("home-pc", "input[name=btnK]")
- 返回结果 → 截图返回给用户
用户: "帮我打开 Chrome，搜索今天的天气"
│
▼
AI Agent 分解任务:
├── Step 1: exec("home-pc", "start chrome")
├── Step 2: browser_open("home-pc", "https://google.com")
├── Step 3: browser_fill("home-pc", "input[name=q]", "今天天气")
├── Step 4: browser_click("home-pc", "input[name=btnK]")
└── Step 5: screenshot("home-pc") → 返回截图给用户
每个 Step 都是 MCP Tool 调用，通过 Gateway 路由到 home-pc 客户端执行
5. 跨设备文件传输流程
从一台设备传输文件到另一台设备
- 用户指令 → "把 NAS 上的 backup.zip 传到电脑桌面"
- AI 调用 → MCP Tool:
file_transfer("nas", "/backup/backup.zip", "home-pc", "C:\\Desktop\\")
- Gateway 协调 → Gateway 分别连接 NAS 和 home-pc 的 MCP Server
- NAS 读取 → NAS 客户端读取文件，通过数据通道流式传输
- PC 写入 → home-pc 客户端接收并写入目标路径
- 完成 → 返回传输结果（文件大小、耗时）
用户: "把 NAS 上的 backup.zip 传到电脑桌面"
│
▼
Gateway AI → file_transfer("nas", "/backup.zip", "home-pc", "C:\Desktop\")
│
├── NAS 客户端 Gateway home-pc 客户端
│ │ │ │
│ │ ① 读取文件 │ │
│ │◀──────────────────│ │
│ │ │ │
│ │ ② 流式传输 │ │
│ │──────────────────▶│ │
│ │ │ ③ 写入文件 │
│ │ │─────────────────────▶│
│ │ │ │
│ │ │ ④ 完成确认 │
│ │ │◀─────────────────────│
│ │ │ │
└─────┴───────────────────┴──────────────────────┘
│
▼
"传输完成，128MB，耗时 3.2s"
6. OTA 更新流程
JS bundle 静默更新（小更新）
- 开发者修改代码 → 修改 JS/TS 代码（新增页面、修 Bug、改 UI）
- 导出 bundle →
npx expo export --platform android 生成 JS bundle
- 上传到 Gitee → 将 bundle 上传到 Gitee 静态仓库
- App 检查更新 → 启动时 + 每 24 小时自动检查
- 静默下载 → 发现新版，后台下载 JS bundle（~1-2MB）
- 下次启动生效 → 用户下次打开 App 自动使用新版本
APK 重装（大更新）
- 开发者修改原生代码 → 新增原生模块、改图标、升级 RN
- 构建 APK →
eas build -p android --profile preview
- 发布到 Gitee → 上传 APK 到 Releases
- 通知用户 → App 内提示有新版本
- 用户手动安装 → 下载 APK 并安装
小更新 (JS bundle OTA):
开发者 → expo export → 上传 Gitee → App 自动检查 → 静默下载 → 下次启动生效
用户无感，1-2MB，几秒钟完成
大更新 (APK 重装):
开发者 → eas build → 上传 Gitee Releases → App 提示 → 用户手动下载安装
需要用户操作，15-30MB
7. 多通道记忆流程
用户在不同通道的对话如何统一记忆
- 身份映射 → OpenClaw 的
identityLinks 将微信/飞书/Telegram 账号映射为同一用户
- 会话共享 →
dmScope: "per-peer" 确保同一用户跨通道共享会话上下文
- 记忆存储 →
MEMORY.md 存储持久记忆（设备信息、用户偏好、操作历史）
- 每日笔记 →
memory/YYYY-MM-DD.md 记录当天操作日志
- 记忆蒸馏 → Dreaming 系统自动从每日笔记中提取有价值信息晋升到长期记忆
- 跨通道回忆 → 在飞书中问"刚才微信说的那个文件在哪"，AI 能从记忆中找到
微信: "帮我备份桌面 PDF"
│
▼
AI 执行 file_list + file_move → 完成
│
├── 写入 memory/2026-07-16.md:
│ "用户要求备份桌面 PDF，已移动 12 个文件到 D:\备份\"
│
▼
飞书 (3小时后): "刚才那个备份做了吗？"
│
▼
AI → memory_search("备份 PDF") → 找到今日笔记
│
▼
"已备份，共 12 个 PDF 文件到 D:\备份\"
8. 设备连接生命周期
设备从离线到在线的完整流程
设备状态流转:
offline ──客户端启动──▶ online ──开始操控──▶ busy ──操控结束──▶ online
│ │
│ ├── 设备休眠 ──▶ sleeping ──唤醒──▶ online
│ │
│ └── 维护模式 ──▶ maintenance ──完成──▶ online
│
└── 连接失败 ──▶ unreachable ──重连成功──▶ online
│
└── 重连失败 ──▶ offline
Gateway 设备注册表:
┌──────────────────────────────────────────────┐
│ 设备ID │ 协议 │ 状态 │ 最后心跳 │
│─────────────┼─────────┼─────────┼─────────────│
│ home-pc │ MCP SSE │ online │ 2s ago │
│ cloud-svr │ MCP SSE │ online │ 5s ago │
│ my-phone │ MCP SSE │ busy │ 1s ago │
│ game-svr │ MCP SSE │ offline │ 2h ago │
└──────────────────────────────────────────────┘
9. 安全控制流程
多层安全防护
请求进入
│
▼
┌─────────────────────────────────────┐
│ ① 身份验证 │
│ - Gateway Token 认证 │
│ - 设备配对 Token │
│ - 通道身份验证 (微信/飞书) │
└──────────────┬──────────────────────┘
▼
┌─────────────────────────────────────┐
│ ② 权限控制 │
│ - Tool 白名单/黑名单 │
│ - 设备级权限 │
│ - 通道级权限 │
└──────────────┬──────────────────────┘
▼
┌─────────────────────────────────────┐
│ ③ 执行沙箱 │
│ - 命令白名单 │
│ - 路径限制 │
│ - 超时控制 │
└──────────────┬──────────────────────┘
▼
┌─────────────────────────────────────┐
│ ④ 审计日志 │
│ - 所有操作记录 │
│ - 异常行为告警 │
└──────────────┬──────────────────────┘
▼
执行完成