《AI OS的升维之旅》文章系列第二篇:从单体到三体,一个进程为什么不够用

我构建了一套多智能体协同系统，取名为三体架构。三个体各有独立职责。OpenClaw 是意识中枢，负责理解意图、路由任务、管理对话，不做任何有副作用的操作。Hermes 是执行层，负责搜索、文件操作、浏览器自动化、shell 命令以及内容写作，不做决策。Codex 是编码层，负责写代码、重构、调试、测试。三个体通过 sessions_spawn 通信，不共享内存，不共享进程空间，故障互相隔离。

支撑这套系统持续进化的是一套知识基础设施，以 Obsidian 为基础的知识库。每次写作完成，新概念自动写入原子笔记，文章索引自动更新，知识图谱重新关联。知识不会停在原地，它会在系统内部流动，从原始对话逐渐提炼成可复用的结构化知识。

三体加 Obsidian 知识库构成了一个从意图理解到执行落地到知识沉淀的完整闭环。

本文是「AI OS 升维之旅」系列第二篇。

社区版单体进程的四个隐性约束

社区版 OpenClaw 是一个单体进程。对话路由、工具调用、代码生成、知识检索、模型调度、技能管理，全装在一个进程里。安装后启动一个二进制文件就能用，Agent 跑在同一个地址空间里共享上下文。单进程架构在开发阶段非常方便，不用操心进程间通信，不用处理序列化，不用建立保活机制。启动快，调试简单，日志集中在同一个进程名下。但到了运行阶段，四个隐性约束开始显现。

显存争夺

Agent 推理调用本地模型时，Ollama 的 KV cache 占住显存不释放。同一时间如果 memorySearch 再调用一次本地 embed 模型，两个推理进程在显存上冲突。8GB VRAM 的笔记本上，一次推理加一次 embed 检索就可能触发 OOM。

I/O 阻塞

社区版的 exec 工具直接在 Gateway 进程里执行 shell 命令。如果 shell 命令是长时间运行的任务，比如 docker compose up 或者大型 git clone，会阻塞整个 event loop。Gateway 要同时处理 WebSocket 心跳和消息推送，一个阻塞操作把全部渠道的延迟一起拉高。

CPU 资源竞争

第三个是推理与工具调用互相抢 CPU。Agent 做工具调用的中间步骤时，LLM 推理在另一个线程。两个线程都处在 CPU 密集区域时彼此抢上下文切换。不会死锁，但每次 LLM 调用的延迟平均高出百分之二十八左右。这个数据来自内部多次运行统计。

故障传播

任何一个 Agent 的运行时错误，工具调用返回异常格式、模型输出不满足 schema 校验、插件 hook 抛出未捕获异常，都可以让 Gateway 进程崩溃。社区版恢复只有 openclaw restart，进程一旦挂掉，所有渠道同时断连。这四个约束指向同一个结论：单体进程在 8GB 显存的笔记本上做生产化运行，资源边界不够。

定制版三体架构拆分

定制版把单进程拆成三个独立体。每个体有独立名称、独立保活机制、独立故障隔离域。三个体之间通过 sessions_spawn 通信，传递序列化后的任务摘要，不共享内存。三个体各管一块，边界清晰到任何一个人接手维护，不需要理解其他两个体的内部逻辑。

OpenClaw：意识中枢

OpenClaw 是意识中枢，保留了 Gateway 的全部对话路由能力。通信控制面、WebSocket 协议、Agent 注册和调度、channel 绑定、消息路由、工具定义、技能加载。SOUL.md 的人格约束、AGENTS.md 的 Agent 路由矩阵、TOOLS.md 的搜索策略，全部在 OpenClaw 这一层加载。OpenClaw 的边界在于不执行 shell 命令，不做文件系统操作，不运行代码。任何可能引起副作用的操作，通过 sessions_spawn 下发给另外两个体。社区版的 exec 工具直接暴露给主 Agent，定制版在 AGENTS.md 里把执行类关键词全部路由到 Hermes，Main Agent 不持有 exec 工具。

Hermes：执行层

Hermes 是执行层，管理所有 shell 命令生命周期。文件操作、web 搜索、浏览器自动化、子进程启动和监控、MCP 工具对接，全归 Hermes。它有独立的 sandbox 隔离子会话，每个子进程有独立的工作目录和环境变量。Hermes 不做决策、不维护知识。只接受 OpenClaw 下发的子任务并返回执行结果摘要。Hermes 配置了多级模型 Fallback，主模型走 DeepSeek Chat，第一 Fallback 走 lfm2.5:8b，第二 Fallback 走 MiniMax M2.7。API 不可用时不会卡死，直接降级到本地模型。

Codex：编码层

Codex 是编码层，运行在 codex CLI 中的独立进程，只做编码相关任务。写文件、重构代码、调试、测试。Codex 不做文件系统操作、不写文章、不搜索网络。主对话中使用 GLM 5.2 模型，一百二十八万上下文窗口。温度 0.25，读写受限 Shell。

每个体不做什么写进了架构级约束。社区版的 Agent 曾经在代码生成时用 exec 删过目标目录，也曾经在 root 权限下执行 docker 命令时没有确认机制。三体架构通过约束禁掉了这些操作路径，不是运行时校验，是架构级隔离。

三体架构的通信机制

三个体之间不走共享内存，不走网络 socket，不走文件锁。唯一的通道是 OpenClaw 自带的 sessionsspawn。你说一句"搜一下 Docker Compose 最新版本"，OpenClaw 做一次 sessionsspawn，参数是 agentId 为 hermes-executor 和 task 文本。调用返回一个 run ID，不阻塞。父进程调用 sessions_yield 交出控制权，让子 Agent 的完成事件在下一轮可见消息中到达。

sessionsyield 不是 sleep，它把当前 session 的上下文管理权交给运行时。子 Agent 完成后，运行时把结果以 agent turn 的方式推回父 session。这个过程有稳定幂等性标识，不会丢消息，不会重复。sessionshistory 用于追溯调用链。父 Agent 可以看到子 Agent 的 session 摘要，但看不到内部消息细节。OpenClaw 不需要知道 Hermes 内部调了几个 shell 命令，只需要拿到执行结果摘要。

通信路径经过一次重构，早期走 webhook POST 到 8644 端口，后来统一到 sessions_spawn。一条通信通道对应一条调试路径，三条通道让问题定位复杂度翻倍。子 Agent 强制五分钟回传状态，五分钟内没有状态更新就判定超时，防止了子 Agent 卡住的死锁场景。层级间通信只传摘要和结果路径，不传全文，大幅降低上下文污染。

三体架构的保活机制

三个体各有独立保活机制。OpenClaw 通过 cron 实现心跳，每小时检查一次所有外部依赖。任何异常通过微信通知到管理员。Hermes 的保活更激进，hermes keepalive 是单独启动的守护脚本，通过轮询检查进程是否存活，不在了就直接重启。Codex 的保活走 codex daemon，CLI 本身有自动重连机制。还有一个兜底检查，tri heartbeat 每三十秒一轮轮询，三个进程的存活状态写入一个 trace span。哪个体挂了，在 Grafana 上能一眼看出。

与主流方案的对比

与主流方案对比，OpenAI Assistants API 用同一进程的不同线程管理 run 和 tool use，线程共享进程堆，一个 memory leak 累积到 OOM 会让所有线程同时挂掉。三体的进程级隔离意味着一个体的内存泄露不影响其他体。LangChain AgentExecutor 是单进程多步循环，model call 到 tool execution 到 result feeding 串行执行在一个进程里。三体在多进程层面实现了同样的节点解耦，代价是多了一层序列化和通信开销。Anthropic Tool Use 把执行层嵌入 API 调用，延迟低但也有故障传播问题。三体把执行层作为进程级搭档，出错时体本身隔离，不会影响到生成序列。

架构拆分的权衡

三个进程比一个进程多了三层复杂度。序列化成本增加约二到五毫秒，高频连续工具调用下会累积，二十次搜索操作三体模式比社区版慢约百分之十二。跨体数据必须显式传输，不能直接赋值。调试需要看三份日志加 trace 记录。但这个拆分带来了故障隔离、资源隔离、职责隔离。对于要在 8GB 显存笔记本上做生产化运行的系统来说，这个权衡是划算的。

完整的《AI OS升维之旅：从单体到三体·社区版到定制版的工程跃迁》全书，关注公众号或者加我好友索取pdf。