多Agent开发笔记:为什么4个Codex加1个Claude会把cpu跑满
700X跑满
好家伙,
vscode里开了四个codex拓展 + 一个 claude把我cpu吃满了,不是哥们,我9700X啊
按理说,8 核 16 线程的桌面 CPU,日常开发应该不算弱.
但我同时开了:
4 个 Codex |
1 个 Claude |
然后 CPU 直接跑到 100%.
因为这些 agent 背后的大模型推理,又不是在我本机 CPU 上跑.
那为什么还会这么吃性能?
排查了一圈以后,我发现问题不在"聊天模型推理".
真正重的是:
多个 agent 同时驱动本地工具链. |
这篇就把这个问题整理一下.
0.先说结论:不是9700X弱
我看到本机当时的情况大概是:
codex.exe 4 个 |
claude.exe 2 个 |
VS Code 子进程 30 多个 |
VS Code 相关内存 6GB+ |
多个 vite / pnpm dev / go run |
多个 language server |
多个 file watcher |
多个 extension host |
任务管理器里看到的:
Visual Studio Code (71) |
这不是一个单独的 VS Code.
它其实是一组进程.
里面可能有:
Codex / Claude agent |
VS Code extension host |
terminal pty host |
renderer / webview |
TypeScript language server |
Go language server |
file watcher |
Git refresh |
vite dev server |
pnpm dev |
go run |
所以 CPU 跑满的时候,不能简单理解成:
VS Code 太卡 |
也不能简单理解成:
Codex 本地推理把 CPU 吃满 |
更准确的说法是:
agent + VS Code + dev server + language server + file watcher 同时被触发. |
这才是峰值来源.
1.Agent不是普通聊天窗口
如果只是开 5 个网页聊天窗口,本地 CPU 压力不会这么夸张.
但 Codex / Claude agent 不一样.
它不是只在聊天.
它会干这些事:
搜索文件 |
读取代码 |
分析目录 |
修改文件 |
跑测试 |
跑构建 |
执行 shell 命令 |
生成 diff |
触发 Git 状态变化 |
触发 language server 重新分析 |
比如一个 agent 在项目里搜索:
rg "TODO" |
另一个 agent 在跑测试:
python -m unittest |
第三个 agent 改了前端文件.
第四个 agent 又触发了 vite 热更新.
Claude 那边也在读文件或改文件.
这些事情叠起来,就不是"聊天开销"了.
可以看这张图:
这张图里最关键的是:
agent 一动文件,本地工具链就会跟着动. |
比如:
agent 改 TypeScript |
-> VS Code watcher 发现变化 |
-> tsserver 重新分析 |
-> Git refresh |
-> Vite 热更新 |
-> agent 又跑测试 |
如果是 1 个 agent,问题还好.
如果是 5 个 agent 同时做这些事,8 核 16 线程被打满就不奇怪了.
2.为什么VS Code插件模式更吃资源
我后面又问了一个问题:
在 VS Code 的 Codex 插件里跑, |
是不是比终端 CLI 更吃资源? |
答案是:
通常是的. |
不是因为插件模式的模型更大.
而是因为插件模式多了一层 VS Code 环境.
大概可以这样理解:
VS Code 插件模式 |
-> VS Code window |
-> extension host |
-> codex.exe app-server |
-> powershell / conhost |
-> file watcher / language server / git refresh |
-> webview / renderer |
而终端 CLI 更接近:
codex.exe |
-> powershell helper |
-> conhost |
结构差异大概是这样:
插件模式的优点也很明显:
交互舒服 |
diff 展示直观 |
权限提示清楚 |
和编辑器集成好 |
但如果要高并发跑 4-5 个 agent,插件模式的额外开销就会明显.
因为每个 VS Code 窗口可能都带着:
extension host |
renderer |
webview |
file watcher |
language server |
Git 状态刷新 |
这就是为什么:
一个 VS Code 插件 agent 还好. |
四五个 VS Code 插件 agent 同时跑,本地会明显重很多. |
3.如果我就是要跑4到5个agent怎么办
可以跑.
但是要换跑法.
核心原则是:
把 agent 干活 和 你看代码/Git diff 拆开. |
不要让每个 agent 都挂在一个完整 VS Code 窗口里.
更推荐:
Windows Terminal: |
tab1: codex -C C:\proj1 |
tab2: codex -C C:\proj2 |
tab3: codex -C C:\proj3 |
tab4: codex -C C:\proj4 |
VS Code: |
一个 multi-root workspace |
同时打开 4 个项目 |
只负责看代码和 Git diff |
结构大概是这样:
这样做的好处是:
agent 仍然可以并发跑. |
但 VS Code 只启动一套主 UI. |
你依然能在 VS Code 里看 4 个项目的 Git 状态.
但不用开 4 个完整窗口.
可以用这个命令打开:
code C:\proj1 C:\proj2 C:\proj3 C:\proj4 |
或者做一个.code-workspace.
以后直接打开这个 workspace.
4.如果是同一个项目多个agent怎么办
如果是同一个项目,不要让 5 个 agent 同时改同一个工作区.
更稳的方式是:
每个 agent 一个 git worktree. |
比如:
git worktree add ..\repo-agent-1 -b agent-1 |
git worktree add ..\repo-agent-2 -b agent-2 |
git worktree add ..\repo-agent-3 -b agent-3 |
git worktree add ..\repo-agent-4 -b agent-4 |
然后分别跑:
codex -C ..\repo-agent-1 |
codex -C ..\repo-agent-2 |
codex -C ..\repo-agent-3 |
codex -C ..\repo-agent-4 |
这样每个 agent 都有自己的工作区.
好处是:
不会互相踩文件 |
不会互相污染 Git 状态 |
方便最后分别 review 和合并 |
坏处是:
磁盘占用会增加 |
项目依赖可能重复安装 |
需要管理分支 |
但如果你真的要高并发 agent,这个成本是值得的.
5.给agent降优先级和绑核
如果机器还会被拖死,可以给 agent 降低优先级.
比如当前已经启动了 Codex / Claude:
Get-Process codex,claude -ErrorAction SilentlyContinue | ForEach-Object { |
$_.PriorityClass = 'BelowNormal' |
$_.ProcessorAffinity = 0xFFF0 |
} |
这里要注意:
BelowNormal 是降低进程优先级. |
ProcessorAffinity 是限制进程能跑在哪些逻辑线程上. |
0xFFF0这个值不要死记.
它只是一个例子.
在 16 个逻辑线程的机器上,可以理解成:
避开前 4 个逻辑线程 |
把一部分响应空间留给 VS Code、浏览器和系统. |
这样做不一定能让 agent 更快.
但能让桌面更稳.
也就是说:
宁愿 agent 慢一点,也不要整台机器卡死. |
6.dev server要单独管
我这次看到的另一个问题是:
多个 vite |
多个 pnpm dev |
多个 go run |
这些开发服务平时没什么感觉.
但 agent 一改文件,它们就可能热更新、重建、重新编译.
如果 4 个 agent 同时在 4 个项目里改文件,那就很容易出现:
agent 在跑 |
watcher 在跑 |
dev server 在重建 |
language server 在分析 |
Git 在刷新 |
所以高并发 agent 时,我建议:
单开cmd控制服务进程
只保留当前真正要看的 dev server. |
不用的 vite / pnpm dev / go run 先停掉. |
不要觉得 dev server 空在那里就没成本.
只要文件在变,它就可能被触发.
7.VS Code也要做workspace exclude
VS Code 的文件监控和搜索范围也要收一下.
比如可以在 workspace settings 里加:
{ |
"files.watcherExclude": { |
"**/node_modules/**": true, |
"**/dist/**": true, |
"**/build/**": true, |
"**/.git/**": true, |
"**/coverage/**": true, |
"**/tmp/**": true, |
"**/*.log": true |
}, |
"search.exclude": { |
"**/node_modules/**": true, |
"**/dist/**": true, |
"**/build/**": true, |
"**/coverage/**": true, |
"**/tmp/**": true |
} |
} |
这不是解决所有问题.
但能减少 VS Code 在大目录里反复监控和搜索.
尤其是:
node_modules |
dist |
build |
coverage |
日志目录 |
临时目录 |
这些目录没必要让 agent 和 VS Code 一直盯着.
8.CPU再跑满时怎么定位
任务管理器只能看到一个大概.
比如:
Visual Studio Code (71) |
这时候你很难知道到底是:
extension host |
tsserver |
gopls |
git |
webview |
terminal |
某个 dev server |
某个 agent |
更适合的方法是:
VS Code -> Developer: Open Process Explorer |
打开后按 CPU 排序.
这样更容易看到是哪个 extension、哪个 renderer、哪个 language server 在吃 CPU.
如果发现是某个语言服务一直高占用,就去看对应项目.
如果发现是 extension host 高占用,就考虑关闭不必要扩展.
如果发现是 dev server,就停掉不用的服务.
9.我现在会怎么配置
如果我就是要同时跑 4 到 5 个 agent,我会这样配置:
1. 主 VS Code 只保留一个窗口 |
2. 4 个 agent 用 Windows Terminal 跑 |
3. 每个 agent 一个项目目录 |
4. 同一个 repo 多 agent 时用 git worktree |
5. VS Code 用 multi-root workspace 看代码和 Git diff |
6. 插件模式只保留 1-2 个需要强交互的 agent |
7. 不用的 dev server 关掉 |
8. 给 agent 降优先级或绑核 |
9. CPU 异常时用 Process Explorer 定位 |
也就是:
高并发任务交给 CLI. |
强交互体验交给 VS Code 插件. |
看代码和 Git diff 交给一个 multi-root workspace. |
这样 9700X 当然还是会忙.
但桌面不会那么容易被拖死.
10.总结
这次问题的核心不是:
9700X 不行. |
也不是:
Codex 或 Claude 在本地跑大模型推理. |
更准确地说是:
多个 agent 同时驱动本地开发工具链. |
VS Code 插件模式又叠加了 extension host、webview、watcher、language server. |
dev server 和 Git refresh 再一起触发. |
所以 CPU 跑到 100% 并不奇怪.
我现在会先记住这句话:
Agent 不是聊天窗口,而是会动本地工程的自动化进程. |
高并发跑法要换思路:
少开完整 VS Code 窗口. |
多用 CLI agent. |
用 multi-root workspace 看代码. |
用 git worktree 隔离同仓库任务. |
停掉不用的 dev server. |
用 Process Explorer 定位真正吃 CPU 的进程. |