Electron 进程模型
OpenCowork 的主进程、渲染进程、预加载脚本和共享契约如何分工。
Electron 进程模型 / Electron Process Model
OpenCowork 的 Electron 架构不是“一个窗口 + 一个渲染页”这么简单，而是一个有明确边界的四层系统：Main、Preload、Renderer、Shared。
进程边界 / Process boundaries
| 层 | 入口 | 职责 |
|---|---|---|
| Main | src/main/index.ts | 窗口、托盘、数据库、IPC、MCP、Cron、SSH、消息平台、更新、崩溃日志 |
| Preload | src/preload/index.ts | 只暴露白名单 API，提供最小安全桥接 |
| Renderer | src/renderer/src/main.tsx | UI、Agent Loop、Tool Registry、Stores、Preview、Team Runtime |
| Shared | src/shared/ | 跨进程类型、事件协议、消息协议、Team Runtime 契约 |
Main 进程 / Main process
主进程承担所有“系统级”能力：
- 注册
fs、db、settings、config、mcp、cron、ssh、plugin、channel、notify、screenshot、web-search、oauth、git、wiki、migration、sidecar、team-runtime、team-worker等 IPC - 管理 SQLite 数据库和本地数据目录
- 创建窗口、通知窗口、托盘和更新器
- 运行主进程 Agent Runtime，为 Cron 和插件自动回复复用同一套协议
- 负责退出时的清理：停止 channel、mcp、cron、ssh、terminal、worker 和数据库
Renderer 进程 / Renderer process
渲染进程承担 UI 和 Agent 工作流：
- React UI 和右侧面板
- Agent Loop 和流式事件渲染
- Provider 调用和流式文本 / thinking / tool-use 处理
- Tool Registry 和审批流
- 计划、任务、团队、MCP、插件、预览和浏览器面板
渲染进程是“工作台”，不是“系统权限入口”。它不直接操作文件系统、数据库或 SSH，而是通过 IPC 和工具系统请求主进程。
Preload 脚本 / Preload script
Preload 只暴露经过筛选的桥接：
window.electron：Electron IPC 的安全子集window.api：图像、Team Runtime、Team Worker 等最小必要 API
这层的目标是把“能做什么”控制得很窄，把“谁能调用什么”变得清晰。
Shared / 共享契约
src/shared/ 维护跨进程类型契约，主要包括：
- Agent loop 事件协议
- Team Runtime 类型
- OpenAI / Anthropic / Responses 消息结构
- 迁移相关类型
主进程为什么还要有 Agent Runtime？
因为有些工作并不来自用户窗口：
- Cron 定时任务
- 消息平台自动回复
- 后台队列式任务
- 某些需要独立生命周期的系统自动化
这些场景会复用主进程 JS Agent Runtime，而不是强行依赖前台 UI。
安全结论 / Security takeaway
- renderer 负责表达和编排
- main 负责系统与持久化
- preload 负责安全桥接
- shared 负责协议稳定
这四层分工，是 OpenCowork 能同时兼顾“可用性”和“可控性”的基础。