• 人工智能
• AI 应用
• 代码智能体
• 桌面应用
• 开发工具
• dsh-plugin

PiDeck 是一款开源的桌面 AI 工作台，基于 Electron 构建。它的核心工作方式是：用 Electron 主进程作为"外壳"，为每个 pi Agent 会话启动一个独立的 pi 子进程，并通过 stdin/stdout 上的 JSONL RPC 协议与之通信。本文带你完整走一遍这条链路——从定位 pi 可执行文件、组装启动参数、spawn 子进程，到多进程的生命周期管理与回收，帮你彻底看懂 PiDeck 背后的进程模型。

整体架构：一个外壳，N 个 RPC 进程

PiDeck 的进程模型可以概括为一句话：1 个 Electron 主进程 + N 个 pi RPC 进程。

• Electron 主进程：负责窗口、UI 状态、会话列表、Git 集成、终端等所有"桌面能力"。
• pi 子进程：每个 Agent 会话对应一个pi --mode rpc子进程，独立持有自己的会话文件与工作目录。
• 通信方式：不依赖端口或服务，而是直接在子进程的 stdin/stdout 上传输一行一条的 JSON 消息（严格 JSONL 协议）。

这种"一会话一进程"的设计天然隔离：一个会话崩溃不会波及其他会话，模型配置、扩展、信任策略也都能按进程独立注入。

整体管理入口在主进程的AgentManager里，所有运行时都挂在一张映射表中：

• 核心管理器：AgentManager.ts（private readonly agents = new Map<string, AgentRuntime>()）
• 每个运行时只有两个成员：UI 用的tab和真正的子进程process（AgentManager.ts）

第一步：找到 pi —— PiLocator 的定位逻辑

在 spawn 之前，外壳得先回答一个问题：pi 装在哪里？

PiLocator负责这件事，它的探测策略大致按优先级排布：

1. 用户手动指定的路径（设置里的customPiPath）——解决 npm 全局目录、nvm 等场景下 PATH 找不到的问题；
2. 官方安装器标记（managed-install.json）与包管理器全局安装；
3. PATH 中的 pi，必要时还会异步反查登录 shell 的 PATH（覆盖 nvm 这类延迟初始化的环境）；
4. WSL 探测：在 Windows 上启用 WSL 时，会异步在发行版内查找 pi，并用进程级缓存 + 负缓存 TTL 避免反复探测拖慢界面。

探测结果和pi --version输出都会被缓存，所以连续打开多个 Agent 时不会重复启动检测（PiLocator.ts、PiProcess.ts）。

第二步：组装启动参数，进入 RPC 模式

PiProcess.start()是参数组装的总装配线，最终拼出的等效命令行大致长这样：

pi --mode rpc --no-themes --offline [--session <会话文件>] [-e <内置扩展> ...]

几个关键参数的用意：

参数列表见 PiProcess.ts。此外还有两个细节值得留意：

• 信任标志：pi 0.79.0 起支持--approve/--no-approve。用户拒绝信任项目时，外壳会校验 pi 版本确实支持该标志后才放行——"拒绝必须 fail closed"（PiProcess.ts）；
• WSL 路径改写：当 pi 运行在 WSL 发行版内时，--session与-e后面的 Windows 路径会被自动转换成/mnt/c/...形式的 Linux 路径（PiProcess.ts）。

第三步：spawn 子进程，打通 JSONL RPC 通道

参数就绪后，主进程用 Node 的child_process.spawn拉起 pi，三条管道（stdin/stdout/stderr）全部接管（PiProcess.ts）。spawn 配置里有两个跨平台细节：

• Unix 下detached: true：让 pi 成为新进程组组长，停止时可用负 pid 对整个进程组发信号，兜底清理 pi 自己拉起的子代理；
• Windows 下windowsHide: true：PiDeck 是无控制台的 GUI 程序，隐藏子进程窗口避免 cmd 控制台一闪而过。

stdout 由PiRpcClient接管，它维护着一个严格 JSONL 解析器：

• 每条命令以\n结尾写入 stdin，按id与响应配对（PiRpcClient.ts）；
• 大行延后解析：超过 256KB 的 JSONL 行推迟到setImmediate再JSON.parse，避免阻塞主进程事件循环（PiRpcClient.ts）；
• 行缓冲硬上限 8MB：无换行的失控输出（比如启动脚本误打印二进制）会让行缓冲无限增长直至 OOM，超限即视为 stdout 被污染并上报协议错误（PiRpcClient.ts）。

也就是说，"pi 进程死了"和"管道写爆了"这类异常，都有明确的终结路径，不会让 Electron 主进程带病运行。

启动握手：get_state 才算真正就绪

子进程"起来了"不等于"能用了"。AgentManager.spawnAndGetState()在process.start()之后还会发出第一条 RPC 请求get_state，收到响应才算完成启动握手（AgentManager.ts）。

这里有两个防坑设计：

• 握手用独立超时（上限 90 秒），不复用用户给长任务配置的 RPC 超时——否则"进程活着但不就绪"会静默等待满 10 分钟才报错（AgentManager.ts）；
• 真正的启动失败不等超时：spawn 失败或进程提前退出时，PiRpcClient会立即以 close 原因终结所有挂起的请求，毫秒级返回错误，用户立刻看到启动诊断卡。

如果首次握手因坏扩展/技能失败，还会按策略自动用--no-extensions重试一次，把问题范围快速收敛到"扩展"这一层（AgentManager.ts）。

多进程管理：空闲回收与彻底清理

管理多个 pi 进程，PiDeck 用了三层机制：

1️⃣ Standby 预热池。StandbyAgentPool允许为每个项目提前握手一个"未绑定会话"的 pi 进程（standby=true时对 UI 不可见），用户真正发第一条消息时直接"认领"，省去冷启动时间。池子单实例、按项目一个，带 10 分钟 TTL 到期自动回收，防止预热进程永远占着内存（StandbyAgentPool.ts）。

2️⃣ 运行中状态回查。UI 侧的运行状态不只依赖事件推送，还会在关键节点主动查询get_state确认 pi 是否真的空闲，避免"动画永久转圈"这类丢事件导致的假死（AgentManager.ts）。

3️⃣ 停止即树杀。用户停止 Agent 时，AgentManager.stop()先清理本地全部状态映射，再调用process.stop()，内部通过killProcessTree杀掉整棵进程树——Unix 走进程组信号，Windows 走taskkill /T，保证 pi 派生的子进程不残留（AgentManager.ts、PiProcess.ts）。

关键源码速查表

小结

PiDeck 的多进程管理本质上是一套非常克制的工程实践：用进程边界换隔离，用 JSONL 协议换零依赖通信，用手握式get_state换可靠的"就绪"语义，用预热池 + TTL + 树杀换响应速度与资源安全。看懂这条链路后，你就能理解为什么 PiDeck 可以同时让多个项目、多个模型的 pi Agent 互不干扰地并行工作，也能快速定位"Agent 启动失败"类问题的排查方向——答案往往就在PiProcess打印的那条等效命令行里。

• 人工智能
• AI 应用
• 代码智能体
• 桌面应用
• 开发工具
• dsh-plugin