04 实时协同的边界

04 实时协同的边界

本节摘要:这是第 8 章的收尾。前面三节让人感觉「改了立刻生效」,但实时性是有边界的——不是所有变更都能实时,有些必须重启。本节诚实地说清这些边界:哪些能实时生效、哪些需要重启引擎或服务端、为什么。建立合理预期,避免「为什么我改了这个没生效」的困惑。

一、能实时生效的(大多数能力变更)

好消息是:大多数能力变更能实时生效。靠第 5 章(配置注入)+ 第 8 章(Reload)的机制,这些变更改完几秒内生效:

这些都是「引擎配置面」的变更,通过配置注入 + 重建实例实时生效。

二、需要重启引擎的(少数)

有些变更不能靠重建实例解决,需要重启引擎:

这些变更属于「进程级」——它们影响的是「引擎进程本身」,不是「引擎实例配置」。实例重建是在同一进程内换实例,改不了进程。所以这类变更要重启整个引擎进程。

⚠️ 判断标准:「这个变更影响的是实例配置还是进程本身?」实例配置 → 重建即可(实时);进程本身 → 重启引擎。

三、需要重启服务端的(更少)

极少数变更需要重启服务端:

这些是「服务端进程级」变更——比引擎进程级还底层。同样,实例重建改不了服务端进程,要重启服务端。

四、为什么有这些边界

这些边界不是「OpenWork 没做好」,而是技术客观限制:

• 进程级的东西(二进制、进程配置)只能靠进程重启改。
• 实例级的东西(配置面)才能靠重建实例改。
• 这是所有软件的通用规律,不是 OpenWork 特有。

OpenWork 能做到「实例级实时生效」已经很彻底了——它把能实时的都做实时了,剩下的进程级是物理限制。

五、桌面端的「重启引擎」能力

对于需要重启引擎的变更,OpenWork 桌面端提供了「重启引擎」的能力(第 9 章运行时管理器)——用户可以在界面触发引擎重启,不用关掉整个应用:

需要重启引擎的变更
   │
   ▼ 用户点「重启引擎」
   │
   ▼ 运行时管理器(第 9 章)停止旧引擎进程
   │
   ▼ 启动新引擎进程(新二进制/配置)
   │
   ▼ 生效
​

这是「进程级变更」的应对——不重启整个应用,只重启引擎子进程。第 9 章详讲运行时管理器如何优雅地做这件事。

六、建立合理预期

读完第 8 章,你应该有这样的预期:

• 改技能/命令/MCP/插件/Agent/配置 → 几秒内实时生效(大多数情况)。
• 更新引擎二进制 → 需要重启引擎(界面可触发)。
• 更新服务端 → 需要重启服务端(较少见)。

带着这个预期,你就不会困惑「为什么我更新了引擎还没生效」——因为那需要重启,不是 Reload 能解决的。

七、第 8 章收尾:实时协同的全貌

读完第 8 章四节,你掌握了 OpenWork 实时协同的完整图景:

核心认知:OpenWork 用「指纹去重 + 游标轮询 + 重建实例」实现了大多数能力变更的实时生效,剩下的进程级变更是物理限制,靠重启引擎解决。第 9 章我们钻进桌面端,看运行时管理器如何管理引擎与服务端子进程的生命周期(包括「重启引擎」这种操作)。

本节要点回顾

1. 大多数能力变更实时生效:技能/命令/MCP/插件/Agent/配置——靠配置注入+重建。
2. 需重启引擎:引擎二进制更新、进程级配置——重建改不了进程。
3. 需重启服务端:服务端二进制、服务端级配置——更少见。
4. 边界是技术客观限制:进程级只能重启,实例级才能重建——通用规律。
5. 桌面端可触发引擎重启:运行时管理器(第 9 章)优雅重启引擎子进程。
6. 合理预期:改能力几秒生效;换二进制需重启。
7. 第 8 章结束:指纹去重+游标轮询+重建实例=大多数实时,进程级靠重启。

第 8 章结束。下一章讲 Desktop 深度——Electron 主进程与运行时管理器。