多Agent开发笔记:为什么4个Codex加1个Claude会把cpu跑满

700X跑满好家伙,vscode里开了四个codex拓展 一个 claude把我cpu吃满了,不是哥们,我9700X啊按理说,8 核 16 线程的桌面 CPU,日常开发应该不算弱.但我同时开了:4 个 Codex1 个 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 agentVS Code extension hostterminal pty hostrenderer / webviewTypeScript language serverGo language serverfile watcherGit refreshvite dev serverpnpm devgo 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 hostrendererwebviewfile watcherlanguage serverGit 状态刷新这就是为什么:一个 VS Code 插件 agent 还好.四五个 VS Code 插件 agent 同时跑,本地会明显重很多.3.如果我就是要跑4到5个agent怎么办可以跑.但是要换跑法.核心原则是:把 agent 干活 和 你看代码/Git diff 拆开.不要让每个 agent 都挂在一个完整 VS Code 窗口里.更推荐:Windows Terminal:tab1: codex -C C:\proj1tab2: codex -C C:\proj2tab3: codex -C C:\proj3tab4: codex -C C:\proj4VS 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-1git worktree add ..\repo-agent-2 -b agent-2git worktree add ..\repo-agent-3 -b agent-3git worktree add ..\repo-agent-4 -b agent-4然后分别跑:codex -C ..\repo-agent-1codex -C ..\repo-agent-2codex -C ..\repo-agent-3codex -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 excludeVS 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_modulesdistbuildcoverage日志目录临时目录这些目录没必要让 agent 和 VS Code 一直盯着.8.CPU再跑满时怎么定位任务管理器只能看到一个大概.比如:Visual Studio Code (71)这时候你很难知道到底是:extension hosttsservergoplsgitwebviewterminal某个 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 worktree5. VS Code 用 multi-root workspace 看代码和 Git diff6. 插件模式只保留 1-2 个需要强交互的 agent7. 不用的 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 的进程.