Agent不是普通聊天窗口
如果只是开 5 个网页聊天窗口,本地 CPU 压力不会这么夸张.

但 Codex / Claude agent 不一样.

它不是只在聊天.

它会干这些事:

搜索文件
读取代码
分析目录
修改文件
跑测试
跑构建
执行 shell 命令
生成 diff
触发 Git 状态变化
触发 language server 重新分析
比如一个 agent 在项目里搜索:

rg “TODO”
另一个 agent 在跑测试:

python -m unittest
第三个 agent 改了前端文件.

第四个 agent 又触发了 vite 热更新.

Claude 那边也在读文件或改文件.

这些事情叠起来,就不是"聊天开销"了.

可以看这张图:

Agent并发引发的本地工具链峰值

这张图里最关键的是:

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
结构差异大概是这样:

VS Code插件模式和CLI模式差异

插件模式的优点也很明显:

交互舒服
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
结构大概是这样:

4个项目4个Agent推荐跑法

这样做的好处是:

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要单独管
1780653460482

我这次看到的另一个问题是:

多个 vite
多个 pnpm dev
多个 go run