01 反向托管引擎 本节摘要:OpenWork 不是一个从零造的 Agent 引擎——它基于一个开源 AI 编码 Agent 引擎(OpenCode)构建。但「基于」二字背后的工程不简单:OpenWork 要反向托管这个引擎——由服务端通过子进程方式生成它、注册为信任进程、管理它的生命周期。本节讲清这套反向托管:服务端怎么生成引擎、为什么要「注册为信任进程」、信任关系意味着什么。这是理解「平台如何接管引擎」的第一步。 一、「反向托管」是什么意思 先澄清一个反直觉的点。通常我们说「A 托管 B」,是 A 把 B 放在自己的环境里跑。OpenWork 的「反向托管」恰恰相反——是服务端(管理者)去生成并管理引擎(被管理者)的子进程。 为什么叫「反向」?
本节摘要:OpenWork 不是一个从零造的 Agent 引擎——它基于一个开源 AI 编码 Agent 引擎(OpenCode)构建。但「基于」二字背后的工程不简单:OpenWork 要反向托管这个引擎——由服务端通过子进程方式生成它、注册为信任进程、管理它的生命周期。本节讲清这套反向托管:服务端怎么生成引擎、为什么要「注册为信任进程」、信任关系意味着什么。这是理解「平台如何接管引擎」的第一步。
先澄清一个反直觉的点。通常我们说「A 托管 B」,是 A 把 B 放在自己的环境里跑。OpenWork 的「反向托管」恰恰相反——是服务端(管理者)去生成并管理引擎(被管理者)的子进程。
服务端(管理者) │ ▼ 以子进程方式生成 引擎 OpenCode(被管理者的子进程)
为什么叫「反向」?因为引擎本身是个能独立跑的产品(用户可以直接用引擎),但在 OpenWork 里,它被「降级」成服务端的一个子进程,由服务端控制它的生与死、给它喂配置。这种「管理者反过来生成被管理者」的关系,就是「反向托管」。
回忆第 2 章的拓扑:渲染进程、Electron 主进程、服务端、引擎。为什么托管引擎的是服务端,不是主进程?
所以引擎由服务端托管,主进程只负责「让服务端跑起来」(运行时管理器,第 9 章)。
服务端通过子进程方式生成引擎实例。大致流程:
服务端启动 │ ▼ 决定需要托管引擎(如配置了「由服务端管理引擎」) │ ▼ 创建托管引擎的句柄 │ ▼ 以子进程方式 spawn 引擎 │ ▼ 引擎实例跑起来,在某个端口监听 │ ▼ 服务端通过 HTTP 与引擎通信(代理请求)
注意:服务端和引擎之间是父子进程 + HTTP的关系。服务端是父进程,引擎是子进程;父进程通过 HTTP 把请求代理给子进程(第 3 章的反向代理)。这种关系让服务端能控制引擎的生命周期(启动/停止/重启),同时又能通过标准 HTTP 与它通信。
这里有个关键机制——服务端把生成的引擎注册为信任进程。这是什么意思,为什么需要?
引擎在某些操作上会区分「谁在调我」——有些操作只接受「被信任的调用方」。服务端作为引擎的管理者,需要执行一些特权操作(比如注入配置,下一节),这些操作必须以「信任方」身份才能做。
所以服务端在生成引擎后,会把自己(或引擎对服务端的认知)注册为信任进程,建立一条信任链:
服务端 ──注册为信任进程──► 引擎认可服务端的特权调用 │ ▼ 服务端可以执行特权操作 ├─ 注入运行时配置(第 02 节) ├─ 协调引擎重载(第 8 章) └─ 其他管理操作
💡 类比:信任进程就像「管理员通道」——普通调用方走普通通道(受限制),服务端走管理员通道(能做特权操作)。没有这条信任链,服务端没法接管引擎。
「信任」不是无条件的,它意味着一套权责:
这种「有限的信任」很重要——它让服务端能接管,又不破坏引擎的独立性。引擎还是一个有自己完整运行时的产品,只是把某些特权交给了它信任的服务端。
最后强调「反向托管」在生命周期上的体现。正常情况下,引擎的生命周期由「启动它的人」控制。但在 OpenWork 里:
引擎在 OpenWork 里不掌握自己的命运——它的命运由服务端掌握。这就是「托管」的全部含义:被托管者失去自主权,由托管者全权负责。理解了这一点,你才能理解为什么 OpenWork 能让引擎「按它的意志行事」而不需要改引擎代码——靠的就是托管 + 配置注入。
托管关系建好了,下一步就是「让引擎听指挥」的具体手段——运行时配置注入,下一节。