ADR-0006：引擎以长驻子进程运行

背景

平台需要一个智能体循环来理解意图、挑工具、解释结果。这一循环跑在哪，决定了三件事：故障隔离、进程模型的复杂度、以及工具怎么交给引擎。

两项事实约束着选择：Codex 是 Rust 二进制，只能以子进程驱动，无法进程内嵌入；Pi 提供两种形态——进程内库（SDK），以及长驻子进程（RPC 模式，官方附带 RpcClient 客户端库）。若一个进程内、一个子进程，适配层要维护两套进程模型。

另有一个运行期问题：Node 是单线程。智能体循环与平台服务同进程时，长任务会挤占事件循环，影响所有会话的响应。

选项	做法	代价	不选的理由
A 引擎都进程内	Pi 进程内、Codex 也进程内	无 IPC 开销	Codex 无法进程内嵌入，此路不通
B 引擎都子进程	两个引擎都以长驻子进程运行，平台通过各自官方客户端通信	Pi 侧要写扩展桥与进程管理	选定
C Pi 进程内 + Codex 子进程	维持现状	无需新增工作	两套进程模型；智能体循环与平台争抢事件循环

选 B：两个引擎都以长驻子进程运行，由平台拉起与守护。

首版一个会话对应一个引擎进程；若进程数成为负担，再评估进程复用（Pi 支持会话切换，Codex 支持多线程复用）。

隔离：智能体循环不再占用平台的事件循环，长任务不拖累其他会话
工具面仍然不同，没有统一：Codex 可通过 MCP 或实验性动态工具接收平台能力；Pi 需要在 pi 侧写一个扩展，注册工具并把调用以本地 HTTP 回调平台，平台再走 Core.invoke。该链路的鉴权复用现有模式：loopback 随机端口 + nonce 注入 + origin 校验
进程管理是共用的：启停、超时、崩溃重启、日志轮转、父进程看门狗只写一套；可借鉴现有 Electron sidecar 的实现
对代码：server/agent 增加引擎进程管理与 Pi 扩展桥；Pi 扩展放在 pi 侧的扩展目录，由平台启动子进程时指定
对任务：A3.3 改为以子进程接入；新增两个工作包（引擎进程管理、Pi 扩展桥）
不可省：无论哪个引擎，工具调用只有一个出口 Core.invoke