OpenWork · 第 2 章 整体架构:三进程模型与控制流

OpenWork · 第 2 章 整体架构:三进程模型与控制流

章节摘要:理解 OpenWork 最大的障碍,是搞不清「到底有几个东西在跑」。答案是一个三进程模型:用户看到的界面是渲染进程(一个 React 单页应用);它跑在 Electron 主进程(桌面外壳)里;主进程又生成并管理一个本地服务端(自研 HTTP 中枢);服务端再反向托管底层引擎(OpenCode)。四层各司其职,而贯穿这套拓扑的核心设计哲学叫**「服务端消费优先(Server-consumption first)」**——App 只是服务端 API 的客户端,绝不发明平行行为,凡是服务端能做的都走服务端。本章要用一张拓扑图建立全书地图,讲清每一层的职责边界与这条哲学为何如此重要,再用「一次用户操作的控制流旅程」把抽象拓扑变成可见的数据流,最后点出全书最精巧的设计——能力四源与 meta-MCP 双工具脊柱的全局图。读完本章,后续每一章你都能准确定位「我在哪一层」。

学习目标

阅读完本章,你应当能够:

1. 画出 OpenWork 的三进程模型(渲染进程→Electron 主进程→服务端→引擎),指出每层的职责边界。
2. 解释**「服务端消费优先」**设计哲学,说明它为何能避免行为漂移、为何让 App 与 CLI/其他客户端天然一致。
3. 描述一次用户操作(如在界面发起一次会话)的控制流旅程:渲染进程→主进程→服务端→引擎→返回。
4. 识别三种产品形态(桌面应用、任意 Agent 经 MCP 接入、企业 Den)如何共用同一套服务端中枢。
5. 在能力四源与 meta-MCP 全局图上定位后续每一章的主题。

核心概念速览

一句话总结:三进程模型 + 服务端消费优先——App 只是服务端的客户端,服务端是唯一中枢,引擎是被托管的运行时;这套拓扑让桌面、CLI 接入、企业云三种形态共用同一个服务端,而 meta-MCP 是它们共享能力的脊柱。

子章节导航

01 三进程拓扑与职责边界

本章核心。用一张拓扑图讲清渲染进程、Electron 主进程、服务端、引擎各自做什么、彼此如何解耦。重点说明:为什么把 HTTP 中枢独立成服务端(而不是塞进主进程)——这让它能被多种客户端共用。

02 「服务端消费优先」设计哲学

讲这条贯穿全项目的设计哲学:App 是服务端 API 的客户端,不发明平行行为。为什么这条哲学如此重要——它避免了「桌面能做但 CLI 不能做」的行为漂移,让 App、CLI、企业云天然一致。

03 一次用户操作的控制流旅程

用一个具体场景(在界面发起一次会话并调用能力)串起整条控制流:渲染进程发起→经 IPC 桥接到主进程→主进程调服务端 API→服务端代理到引擎或执行能力→返回渲染。配合时序图,把抽象拓扑变成可见过程。

04 能力四源与 meta-MCP 全局图

点出全书最精巧的设计:云端 meta-MCP 只暴露两个工具(检索能力/执行能力),能力来自四源(REST 目录、外部 MCP 连接、市场插件能力、原生 Provider 能力)。这一节是第 7 章的预告,也是全书架构图的高光。

子章节之间的逻辑关系

本章遵循「看清拓扑 → 理解哲学 → 体验流程 → 瞥见脊柱」的地图建立路径:

三进程拓扑 (01) ──建立全局地图
   │
   ▼
服务端消费优先 (02) ──理解核心哲学
   │
   ▼
控制流旅程 (03) ──用一次操作把拓扑串起来
   │
   ▼
meta-MCP 全局图 (04) ──瞥见全书最精巧的设计
   │
   ▼
第 3 章:深入服务端这个中枢
​

拓扑不清后续每一章都悬空,哲学不懂就读不懂「为什么 App 不自己做」,控制流把前两节固化,meta-MCP 全局图则为第 7 章埋下全书最重要的伏笔。

前置知识与后续延伸

前置知识:

• 第 1 章的环境准备与首次跑通(知道它跑起来是什么样)
• 对 Electron、HTTP 服务端、进程管理的基本概念
• 对「AI Agent」「MCP」的基本了解

本章为后续章节奠定的基础:

• 三进程模型是第 3~13 章所有子系统定位的总纲
• 服务端消费优先是第 3、9、10 章理解服务端、桌面、前端边界的前提
• meta-MCP 全局图为第 7 章深入铺垫