e里开了四个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 的进程.