给 Agent 做 IDE：三个进程怎么切权限

做一个能自己改代码的桌面 Agent。第一个要想清楚的不是「怎么调模型」，而是谁有权力说「这次成功了」。

使用者痛点：在缺乏明确授权的程序里任何 UI 按钮都可能直接触发代码写入，导致不可追溯的错误修改。

先看一个样本

我们参考的开源 CLI里有这么一段：

// src/sdk.ts:-// SDK 模式下工具调用自动批准

还有子 Agent 在消息总线缺失时的处理：

// src/tools/task.ts:-// bus 不可用 → fail-open。继续执行

这两处单独看都有理由：SDK 是给程序调的，没人能点确认；bus 挂了不该让整个流程崩。但合起来的含义是：「没人批准」和「批准了」在代码里走同一条方法。

使用者痛点：同一条代码方法既处理授权也处理业务逻辑，使得审计、拒绝和追责几乎不可能实现。

三个进程。三种权力

flowchart TB
R
P
M
C
S
K
X
R -->|意图| P
P -->|校验后的 IPC| M
M -->|私有 MessagePort| C
C --> S
C --> X
M --> K

图里那个存储节点要表达的是边界证据存储由 Core 独占，Renderer 和 Main 都碰不到。至于用什么存，原型阶段是 JSONL + 未加密目录。这条也在 README 的「还没做的」里 —— 别把图当成已实现清单。注意凭据是另一回事：那条走 M --> K,用 Electron safeStorage 落在钥匙串里。

进程	有什么	明确没有什么
Renderer	展示、收集输入 Node、文件程序、shell、密钥、Run 终态	业务授权、方法解析、Task / Run / Approval 权威、Agent Loop、仓库写权限
Preload	白名单方法、shape 校验 通用 invoke、业务授权、方法解析	Task / Run / Approval 权威、Agent Loop、工具执行、Mutation 长期明文凭据、任意宿主方法、监听端口
Main	原生目录选择 钥匙串、监督 Core Task / Run / Approval 权威、Agent Loop、工具执行、Mutation 长期明文凭据等	Main 不持有业务权威

使用者痛点：Main 进程如果拥有全部能力。会成为“全能黑盒”，难以定位谁真正负责审批，从而导致安全审计失效。

Preload 长什么样

关键是不暴露通用能力

const bridge: RepoPilotBridge = {
protocolVersion: PROTOCOL_VERSION。request {
return ipcRenderer.invoke(IPC_CHANNEL.request,{
protocolVersion: PROTOCOL_VERSION,method,payload,});},subscribe {
/* 只读事件订阅 */
},};contextBridge.exposeInMainWorld;

注意这里没有** `invoke`**。Renderer 连 channel 名字都拿不到 ——它只能调用 `request`，而 `'run.cancel'` 必须在 Main 的白名单里：

const ALLOWED_METHODS = new Set();

*不在集合里的一律拒绝*。这不是「多一层校验」，而是让「注册一个新的特权通道」必须改 Main 源码。不能由插件或运行时动态完成。

使用者痛点：If a developer can inject arbitrary IPC channels at runtime,hidden privileged pathways appear。making security reviews impossible.

状态提交协议

• Main 完成边界校验后仅把请求转发给 Core；不写任何业务事实，
• Core 在单事务里持久化 intent + expected version + 幂等键。
• The Runtime/Model/Tool 子模块只能向 Core 返回 proposal 与 observation。按理说，
• The Core 验证 schema、状态版本、lease、审批与预算后才真正提交状态与事件。

The **第 一步** 「Main 不先写」很容易被忽略。 一旦 Main 为了「快一点」先在本地记一笔。就出现了两个真相源，crash 后它们会不一致。

使用者痛点：Main 若自行写入状态。会产生“双写”风险，一旦进程异常重启就会出现数据冲突或丢失。

踩的坑

坑 ：事件推送早于订阅

Core 启动完发 `ready`，Main 转发给 Renderer。但窗口创建是异步的 ——如果 Core 比 window 先就绪。这条推送就发给了空气，UI 永远停在「Core 启动中」。

// 示例修复
mainWindow.webContents.on => {
pushToRenderer({
说到type。'core.status',status: coreReady?'READY' : core?'RESTARTING' : 'DOWN',detail: coreReady?'Agent Core 已就绪' : 'Agent Core 尚未就绪',});})，

User Pain Point:If an event is emitted before any subscriber exists,UI will hang indefinitely without feedback.

坑 ：Core 挂了在途请求永远挂着

child.on => {
coreReady = false;// 所有在途请求必须收到明确失败，不能永远挂着
for {
pending.delete;resolve({
从ok来看，false,error: {
至于code，'CORE_UNAILABLE'。message: 'Agent Core 已退出',detail: `exit code ${code}`
},});}
if setTimeout;})，

`if ` 必须保留，否则退出应用时会疯狂重启 Core。

User Pain Point:The UI shows endless loading spinners because unresolved promises are never rejected when child process crashes.

坑 ：ESM 打包下的 require

const { execFileSync } = require;

This passes type‑checking because `@types/node` declares `require`,but Electron‑vite builds main process as ESM . At runtime `require` simply does not exist.

User Pain Point:A seemingly harmless import causes runtime crashes that are only discovered after launching app.

怎么证明它真的跑起来了

"启动没报错" 不算证据。我加了一个自检模式，走**完全相同**的 Main → Core 通道：

REPOPILOT_SELFTEST= npx electron .

 Core 就绪，用时 106ms
PASS doctor.run → {"checks":
PASS 未知方法被拒绝 → {"code":"BAD_REQUEST"。"message":"未知方法: run.deleteEverything"}
PASS renderer 已挂载
ALL PASS

The last line is crucial – it runs a tiny piece of JS in page and confirms that `` really has children and that `window.repopilot` truly exists. “Compilation passed” and “React mounted” are two different things.

User Pain Point:If you only rely on build success,you might miss integration bugs that only surface at runtime.

可以带走的

1. 先想清楚「谁能宣布成功」，再想怎么调模型。 权限边界定错了后面全是补丁。
2. Main 不持有业务权威。 把它限制为「能力代理」可以避免授权混乱。
3. No generic invoke API. 没有 invoke 就没有意外多出来的特权通道。怎么说呢，推送要考虑订阅晚到。<\/stong> 加载完成时补发一次当前状态成本极低。<\/li>} 给自己写一个走真实通道的自检。<\/stong> 它抓到的 bug 比读代码多。<\/li>} <\/ol>

.

---