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

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

好家伙,

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 的进程.

插件模式体验好.

终端模式更适合高并发.

这俩不是谁完全替代谁.

而是看场景分工.