ARTICLE · 1034021
六个 AI 编程工具,谁在偷吃你的内存
我这台笔记本内存不大。早上开机，没跑编译，没开虚拟机，free -h 看可用只剩三分之一。翻进程表：WorkBuddy 16 个进程、CodeBuddy CN 28 个、opencode 一个，三个加起来 6.3 GB。
与其猜，不如量。我写了个脚本，在同一台机器、同一套口径下，把 ZCode、WorkBuddy、CodeBuddy、Cursor、dsh 挨个跑了一遍。
结论先给：一个 AI 编程工具吃多少内存，跟它背后是哪家的模型基本无关，由它的进程模型决定。有窗口的按 GB 算，没窗口的按百 MB 算。
六个工具的进程模型
ZCode 是智谱的 Electron 桌面应用。WorkBuddy 是腾讯的桌面级 Agent，同样是 Electron 外壳，但里层自带一份 CodeBuddy CLI 并主动拉起，进程数比一般桌面应用更多。
CodeBuddy 装的是 CN 版，从配置看是 VS Code 的 fork。Trae 是字节的，同样是多进程架构。
Cursor 我用的是命令行版 Cursor Agent CLI。dsh 是 DeepSeek Harness，纯 Node CLI，没有窗口。
四个有窗口的走的是 Chromium 那套多进程模型：浏览器进程、渲染进程、GPU 进程、utility 进程，再加若干 zygote。两个没窗口的就是一个 Node 进程。差别从进程模型开始，最后落到 GB 级的差距。
空载内存差了 4.5 倍
下面所有数字按进程树合计，以 PSS 计。RSS 会把 fork 出来的共享页重复计算，Electron 应用因此虚高，同一款工具两者能差 15%。
四个工具，同样从零开始，不开项目、不写代码、刚起来就量：
第一行是基线。一个空载的 Node 进程 38 MB，任何 Node 系工具都要先付这 38 MB，剩下的才是它自己的开销。dsh 和 Cursor CLI 扣掉基线约 150 MB；ZCode 停在登录页已经 846 MB，11 个进程、149 个线程，是前者的 4.5 倍。
同样打开等着输入，一个 188 MB，一个 846 MB。差的是整套 Chromium 运行时和它的进程池。
驻留之后：数字更难看
两个最重的不是跑久了涨上来的。WorkBuddy 从启动到采样只有 25 分钟，已经 2258 MB；CodeBuddy 驻留 3 天，2326 MB。它们是打开就重。
增长最明显的反而在最静的地方。同一个 Cursor Agent CLI 二进制，冷启动 188 MB，另一个实例驻留 27 天之后变成 477 MB，而这期间空载 CPU 全程 0.00%。
多出来的 289 MB 在进程外面归不了因，但增长本身是量出来的。这种增长不会有任何告警跳出来，只会某天让你发现风扇一直转。
图 1：六款工具的常驻内存（PSS）。上组冷启动，下组在位；CLI 蓝色、Electron 橙色、单文件二进制紫色。
opencode 那行是对照组，它不在名单里。一个进程、一个二进制、没有窗口，照样到 805 MB。所以没窗口不等于轻，变量是它加载了多少索引和上下文。
内存消耗的四个来源
图 2：内存消耗的四个来源和各自的实测依据。单看每一项都不算多，叠起来才是后面那几个 GB。
进程模型。Chromium 和 VS Code 的底子本身就是一套浏览器：主进程、渲染进程、GPU、utility 加 zygote，ZCode 空载就 11 个进程、149 个线程。VS Code 官方文档写得很直白，扩展必须跑在独立进程里，否则一个写坏的扩展能拖垮整个编辑器。多一层隔离就多一组常驻进程，这部分没有开关可关。
索引与文件监听。项目越大，索引和监听的面积越大。同时开多个窗口，每个窗口一套语言服务和索引；把家目录当工作区打开，下载目录、缓存目录、每一个项目全被扫进来。CodeBuddy CN 那三个 node 侧服务进程各约 235 MB，就是这类语言服务和索引。
Cursor 那个 72 GB 的案例里列了七个放大因素，其中一个就是把家目录当工作区。
会话上下文。Cursor 官方论坛里工作人员的原话是：长会话期间，渲染进程会一直保留已完成的工具调用状态，改前和改后的文件内容、diff 都在里面，而且不释放。从产品角度看这是记忆，从内存角度看这是不回收的活数据。论坛里那个 18.4 GB 的案例：渲染进程物理占用 18.4 GB、swap 16.9 GB、CPU 持续 435% 到 574%。
MCP 与插件进程。每挂一个 MCP server 就多一个常驻进程，一份 11 个主流 MCP server 的基准给的中位数是 188 MB，十个就是 1.9 GB。用 npx 起 MCP 是双进程链，只看父进程会低估 18 倍；会话结束没人发 SIGTERM，就会留下吃内存的孤儿进程，有个 issue 记录了一台服务器上 41 个残留 MCP 进程占约 2.4 GB。
插件同理。Trae 官方文档点名过两个确认会引起性能问题的插件。
这几项叠起来，才是那几个 GB。所以"内存泄漏"这个词要慎用：Trae 官方说的是已经修复了多个泄漏，Cursor 官方说的是这类已知 bug 没有 ETA，dsh 是有具体 issue 的。前两个是产品问题，第三个更像设计取舍。
内核资源：inotify 实例配额
内存和 CPU 之外，工具还占内核资源，这块几乎没人量。inotify 是 Linux 的文件变动监听机制，工具要监听一个目录，就得先向内核申请一个实例。内核给每个用户的实例上限是 128，这台机器上用掉了 142。
图 3：inotify 实例按归属拆开。红线是内核上限 128，实测 142 已经越线。
超限的后果是新进程申请实例直接报 EMFILE。我量 dsh 的时候撞上了：
$ dsh web --no-open
Error: EMFILE: too many open files, watch '~/.dsh/profiles/web'
退出码 1
它连启动都启动不了。报错信息有误导性："too many open files"看着像文件描述符耗尽，但文件描述符和 watch 数的上限都还很高，真正的瓶颈是实例配额。我最后绕过文件监听，才拿到它那 195 MB。
说句公道话：75 个实例是系统桌面组件拿走的，几个 AI 编程工具加起来 29 个。问题在于因果不直观，一个工具起不来，往往是别人先把配额用光了。
怎么把占用降下来
图 4：按四个来源逐项对应的做法，每条都给出依据，外加通用三条。
能不用窗口就别用。同样的活，命令行版 188 MB 到 193 MB，桌面版得按 GB 算。
关掉窗口不等于退出进程。macOS 上要用 Cmd+Q，退出后查一遍 PPID 是 1 的残留进程。
工作区开小。别把家目录当项目；用 .cursorignore 把 node_modules/、dist/、.git/ 排掉；多仓库拆成多个小工作区，不要一个窗口挂九个仓库。
长任务按阶段分会话，完成一个逻辑完整的阶段就开新的，这是 Cursor 官方给的建议。内存已经涨上去了，执行 Developer: Reload Window 可以回收，不需要整个重启。
MCP 少装，用不上的先禁用。尽量别用 npx 起，全局安装之后单进程占用能从 100 MB 降到 40 MB 上下。
通用三条：看内存看 PSS，别只看任务管理器那个数；定期查孤儿进程；把构建、测试和本地服务挪到系统终端里跑，不要在 IDE 的终端面板里长时间挂着，这条是 Trae 研发工程师说的。
最后
上面所有数字都在实测记录里，脚本只用 Python 标准库和 /proc。WorkBuddy 那一行的数字，是它一边跑这篇稿子一边量出来的，含着这次写作会话的开销。
你机器上的数字一定和我这张表不一样，项目规模、窗口数、插件、会话时长，任何一项都会改写结论。别记我的表，把脚本在你机器上跑一遍。