1. 为什么我要自己造一个桌面 IDE市面上不缺编辑器VS Code 装几个插件也能凑合用但我真正动手写这个项目是因为在同时用 Claude、Codex、Pi 这几个编程代理干活的时候被切来切去的窗口逼疯了。一个代理在终端里跑另一个在浏览器标签页里等结果第三个又要单独开一个客户端改完代码还得手动刷新预览。一天下来真正写逻辑的时间可能不到三成剩下的全耗在窗口管理和上下文搬运上。这个项目的定位很明确把多个编程代理收进同一个桌面壳子里让它们共享同一份工作区、同一套文件树、同一个内置浏览器再补上一个手机远程控制的入口。它不是要替代谁而是做一个代理聚合层。适合的人群也很清楚——已经在日常开发里用上 Claude Code、Codex CLI 或者 Pi Agent 的开发者尤其是那种手上同时开着两三个代理任务、需要频繁对照结果的人。我把它开源出来核心诉求有三个。第一统一入口所有代理的会话、输出、文件改动都在一个界面里可见不用来回切。第二内置浏览器代理改完前端代码可以直接在 IDE 内预览省掉手动刷新和端口切换。第三手机远程控制出门在外用手机就能查看代理进度、发指令、确认改动不用背着笔记本。这三点听起来简单但真做起来每一块都有不少坑下面我按模块拆开讲。提示这篇文章讲的是我自己的实现思路和踩坑记录不是官方文档。你如果打算复现建议先跑通最小闭环再逐步加功能别一上来就全量堆。2. 多代理接入层的设计Claude、Codex、Pi 怎么统一2.1 代理之间的差异比想象中大一开始我以为接入多个代理就是起个进程、读 stdout这么简单结果发现三家的交互模型完全不一样。Claude Code 偏向会话式一次任务会持续输出多轮中间可能停下来等你确认Codex 更接近命令式你给它一个指令它执行完就结束输出相对集中Pi Agent 则是事件驱动会主动推送状态变化。如果用一个统一的请求-响应模型去套必然有一方会水土不服。我的做法是抽象出一层Agent Adapter每个代理实现同一组接口但内部各自处理自己的协议。接口大致包含这几个方法startSession、sendPrompt、onOutput、onStatusChange、stopSession。关键在于onOutput不是简单的字符串回调而是一个带类型的事件流类型包括text、tool_call、file_change、error、done。这样上层 UI 就能用同一套渲染逻辑处理不同代理的输出而不用为每家写一套界面。interface AgentAdapter { startSession(workspace: string): PromiseSessionHandle; sendPrompt(handle: SessionHandle, prompt: string): Promisevoid; onOutput(handle: SessionHandle, cb: (event: AgentEvent) void): void; stopSession(handle: SessionHandle): Promisevoid; } type AgentEvent | { type: text; content: string } | { type: tool_call; name: string; args: unknown } | { type: file_change; path: string; diff: string } | { type: error; message: string } | { type: done };2.2 进程隔离与工作区共享的平衡多代理同时跑最大的风险是它们互相踩文件。我试过让两个代理操作同一个目录结果一个在改package.json另一个同时在装依赖锁文件直接冲突。后来我改成工作区共享但写入串行化所有代理看到的是同一份文件树但任何写操作都要经过 IDE 的写入队列同一时刻只允许一个代理落盘。读操作不限随便并发。具体实现上我在主进程里维护了一个WriteQueue代理发起的文件改动先进入队列按到达顺序执行执行完再广播给其他代理和 UI。这样既保留了共享工作区的便利又避免了并发写的灾难。代价是写入有轻微延迟但实测下来对交互体验几乎没影响因为代理的写操作本来就不是高频的。2.3 会话状态的持久化代理跑到一半IDE 崩了或者你手贱关了窗口会话就没了——这个体验非常糟糕。所以我给每个会话做了状态快照定期把会话上下文、当前任务、已产生的文件改动序列化到本地的一个.ide-sessions目录。重启后可以恢复。这里要注意不要把代理的完整内部状态都存下来那玩意儿可能很大而且格式不稳定只存你自己能理解的那部分任务描述、消息历史、文件改动列表。恢复的时候重新起一个会话把这些上下文喂回去就行。注意不同代理的会话恢复能力不一样。有的支持--resume之类的参数有的只能重开。适配层里要留一个canResume的标志UI 根据它决定是显示恢复还是重新开始。3. 内置浏览器不是套个 iframe 那么简单3.1 为什么不用系统浏览器最省事的方案当然是代理改完代码你手动切到 Chrome 刷新。但这就回到了老问题切窗口。而且代理经常需要看到页面结果才能继续下一步比如它改了个按钮样式想确认渲染是否正常。如果浏览器在 IDE 外面代理拿不到这个反馈闭环就断了。内置浏览器的价值就在于让代理和预览在同一个进程上下文里代理可以通过 IDE 暴露的接口读取页面状态、截图、甚至触发点击。3.2 渲染方案选型iframe 还是独立渲染进程我一开始用 iframe简单直接但很快撞墙。iframe 的同源策略让代理没法读取跨域页面的 DOM而且很多现代前端框架在 iframe 里的行为跟独立窗口不一致热更新经常失灵。后来换成独立的渲染进程用类似 Electron 的BrowserView或者自己起一个无头浏览器实例通过调试协议跟主进程通信。这样代理可以拿到完整的页面上下文截图、DOM 查询、网络请求监控都能做。代价是资源占用上去了。一个内置浏览器实例大概多吃 100-200MB 内存如果同时开多个预览就有点肉疼。我的折中是默认只保留一个活跃预览实例切换目标时复用不活跃的自动销毁。实测下来单实例方案在 16GB 内存的机器上跑得很稳。3.3 代理与浏览器的通信协议代理要操作浏览器得有个协议。我定义了一组简单的消息类型走 IDE 内部的 IPC消息类型方向用途browser.navigate代理 → IDE让浏览器打开某个 URLbrowser.screenshot代理 → IDE请求当前页面截图browser.query代理 → IDE查询 DOM 元素browser.click代理 → IDE触发点击browser.consoleIDE → 代理推送控制台日志browser.errorIDE → 代理推送页面错误这套协议的关键是异步 超时。代理发一个screenshot请求IDE 不一定马上能返回可能页面还在加载。所以每个请求都带一个超时时间超时后返回一个明确的错误让代理自己决定重试还是放弃。我踩过的坑是早期没设超时代理发了个请求就卡死在那等整个会话僵住。// 代理侧发起截图请求 const result await ide.browser.request(browser.screenshot, { timeout: 5000, fullPage: false }); if (result.error) { // 明确知道失败了可以重试或换策略 }4. 手机远程控制出门也能盯着代理干活4.1 远程控制的核心需求拆解手机远程控制听起来很酷但真做的时候要先想清楚你到底要在手机上干什么我的答案是三件事——看进度、发指令、确认改动。不是让你在手机上写代码那不现实。所以远程端的 UI 要极度精简一屏之内能看到当前有哪些会话在跑、每个会话的状态、最近几条输出然后有一个输入框可以发新指令有一个确认/拒绝按钮处理代理的待确认操作。4.2 通信链路的选择桌面 IDE 和手机之间怎么连我考虑过几种方案。直接局域网发现最简单但出了门就不行。走公网中转需要服务器成本和维护都是问题。最后我选的是基于现有同步服务的点对点通道桌面端和手机端通过一个轻量的信令服务建立连接之后数据尽量走直连。这样既不用自己维护重资产的中转服务器又能覆盖大部分场景。这里要强调一点远程控制必须默认关闭且开启时需要显式确认。我在设置里做了一个开关打开后生成一个一次性的配对码手机端输入配对码才能连上。配对码有效期很短用完即失效。这是基本的安全底线不能省。4.3 手机端 UI 的取舍手机屏幕小信息密度要控制。我最终只保留了三个视图会话列表显示所有活跃会话每个会话一行包含代理类型、任务摘要、状态指示灯。会话详情滚动查看最近输出底部固定一个输入框和发送按钮。待确认队列代理需要人工确认的操作集中在这里可以批量处理。实测下来最常用的其实是待确认队列。因为代理大部分时间在自动跑真正需要你介入的就是那些它拿不准的操作。把这个视图做顺手远程体验就成功了一大半。提示手机端不要做实时全量同步输出流用增量推送 本地缓冲。否则网络一抖界面就花屏。5. 实操中踩过的坑与排查链路5.1 代理输出乱码与编码问题第一次跑 Codex 的时候输出里夹杂着一堆乱码。排查了半天发现是子进程的 stdout 编码跟主进程不一致。Windows 上默认可能是 GBK而代理输出的是 UTF-8。解决方案是在启动子进程时显式指定编码并且在读取流的时候做一次解码校验。const child spawn(agentCmd, args, { env: { ...process.env, LANG: en_US.UTF-8 }, stdio: [pipe, pipe, pipe] }); child.stdout.setEncoding(utf8);这个坑的隐蔽之处在于它只在特定平台特定代理组合下出现本地测试好好的换台机器就炸。所以我在适配层里加了一个编码探测逻辑启动时先发一个已知的 UTF-8 字符串看回显是否正常不正常就切换编码策略。5.2 会话卡死从现象到根因的完整排查有一次代理跑到一半突然不动了UI 上状态还是运行中但没有任何新输出。排查过程是这样的先看进程ps一看代理进程还在没死。再看网络抓包发现代理在等一个 HTTP 响应但那个请求一直没回来。定位到超时缺失代理内部的 HTTP 客户端没有设超时服务端那边可能因为某种原因挂起了连接。根因不是我的 IDE 的问题是代理自身的健壮性不足。但作为宿主我得兜底。解决方案是在适配层加一个心跳检测如果代理超过 N 秒没有输出任何事件IDE 主动发一个轻量的探测请求如果探测也超时就判定会话僵死提示用户并允许强制重启。这个机制后来救了我好几次。5.3 文件监听的性能陷阱内置浏览器要热更新就得监听文件变化。我一开始用fs.watch递归监听整个工作区结果在node_modules巨大的项目里CPU 直接飙满。后来改成只监听源码目录 忽略规则并且用防抖合并短时间内的多次变更。const watcher chokidar.watch([src, public], { ignored: /node_modules|\.git/, awaitWriteFinish: { stabilityThreshold: 300 } });awaitWriteFinish这个参数很关键。编辑器保存文件时可能触发多次事件等文件稳定 300ms 再处理能避免大量重复的刷新。5.4 手机端连接断开的处理移动网络不稳定连接断开是常态。早期我没做重连手机一锁屏再打开就白屏。后来加了自动重连 状态补偿断线后客户端指数退避重试重连成功后向服务端请求自上次断开以来的增量事件把错过的内容补上。这样用户感知上就是卡了一下又好了而不是整个断了。6. 这套东西适合谁以及后续可以怎么扩展说实话这个 IDE 不是给所有人用的。如果你平时就一个代理、一个项目VS Code 加个终端完全够用没必要折腾。它的价值在多代理并行 需要频繁预览 有移动场景这三个条件同时成立的时候才体现出来。我自己是同时跑 Claude 做重构、Codex 写测试、Pi 盯构建三个任务并行这时候统一入口的收益就非常明显。后续我打算扩展的方向有几个。一是代理之间的协作比如让 Claude 改完代码自动触发 Codex 跑测试测试失败再把结果喂回 Claude形成一个自动闭环。二是更细粒度的权限控制现在代理的写操作是全放行的未来想做成按目录、按文件类型授权。三是远程端的语音输入手机上打字还是慢语音发指令会更自然。最后分享一个我自己的使用习惯给每个代理分配固定的角色不要让它什么都干。Claude 负责架构和重构Codex 负责具体实现和测试Pi 负责监控和告警。角色固定之后你在会话列表里一眼就能看出谁在干什么心智负担小很多。这个习惯比任何功能都更能提升效率。