1. 9700X 被 4 个 Codex 加 1 个 Claude 跑满问题到底出在哪先说一个很多人第一反应会搞错的地方Codex 和 Claude 这类 Agent 的模型推理并不在你本机 CPU 上跑所以 CPU 100% 不是本地在算大模型。我一开始也以为是 9700X 太弱后来把进程摊开看才明白真正吃满 8 核 16 线程的是多个 Agent 同时驱动本地工具链这件事本身。你可以把每个 Agent 想成一个会自己动手的实习生它不只是跟你聊天它会rg搜代码、读文件、改文件、跑测试、跑构建、执行 shell、生成 diff。它每动一次文件就会连锁触发一串本地进程——VS Code 的 file watcher 发现变化、tsserver 重新分析、Git 状态刷新、Vite 热更新、language server 重扫。一个 Agent 这么干还好4 个 Codex 加 1 个 Claude 同时干峰值就叠上来了。我实测时任务管理器里最扎眼的一行是Visual Studio Code (71)——注意这不是一个 VS Code而是一组进程extension host、renderer、webview、terminal pty host、TypeScript language server、Go language server、file watcher、Git refresh再加上多个vite、pnpm dev、go run。所以VS Code 太卡和Codex 本地推理吃满 CPU这两个判断都不准确准确的说法是Agent VS Code dev server language server file watcher 被同时触发。这篇就按这个思路走先讲清楚为什么插件模式更重再给出用 TaoToken 统一 Key/API 通道的配置片段然后用 VS Code 加 git worktree 的并行目录做验证最后用任务管理器和日志定位到底是哪个进程在吃 CPU。适合正在本地跑多 Agent 并发、机器被拖到卡死的开发者。2. 为什么 VS Code 插件模式比终端 CLI 更吃资源多 Agent 并发场景怎么选结论先放这插件模式通常比终端 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 插件 Agent就多带一套 extension host、renderer、webview、file watcher、language server 和 Git 状态刷新。一个插件 Agent 还好四五个同时跑本地就明显重很多。插件模式的优点也很实在——交互舒服、diff 展示直观、权限提示清楚、和编辑器集成好所以它不是不能用而是要分工。我踩过的坑是一开始 5 个 Agent 全塞进 VS Code 插件里结果桌面直接卡到鼠标都飘。后来改成高并发任务交给 CLI强交互体验交给 VS Code 插件情况立刻好转。具体分工可以这样场景推荐跑法原因4-5 个 Agent 并发干活Windows Terminal 多 tab 跑 CLI每个 Agent 只带 conhost开销小需要看 diff、点权限确认VS Code 插件只留 1-2 个交互体验好但别全塞进来看代码和 Git diff一个 multi-root workspace只启动一套主 UI同仓库多 Agentgit worktree 隔离避免互相踩文件和污染 Git 状态这里有个关键认知Agent 不是聊天窗口而是会动本地工程的自动化进程。你开 5 个网页聊天窗口CPU 压力不会夸张但你开 5 个会改文件、跑测试、触发 watcher 的 Agent本地工具链就被反复唤醒。理解这一点后面的配置和排查才有方向。3. TaoToken 统一 Key 与 API 通道的可复制配置片段多 Agent 并发时另一个容易被忽略的痛点是 Key 管理4 个 Codex 加 1 个 Claude如果每个都单独配 Key、单独记 Base URL改一次要改五处还容易配错。我的做法是用 TaoToken 统一 API 通道所有 Agent 指向同一个 Base URL 和同一套 Key模型 ID 按需区分。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 这个不加 UTM。下面给出可直接复制的配置片段路径和原文保持一致。Codex 的auth.jsonWindows 下一般在%USERPROFILE%\.codex\auth.json{ OPENAI_API_KEY: 你的_TaoToken_Key, OPENAI_BASE_URL: https://taotoken.net/api }Codex 的config.toml同目录%USERPROFILE%\.codex\config.tomlmodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key OPENAI_API_KEY wire_api responsesClaude Code 的环境变量PowerShell 里临时设或写进系统环境变量$env:ANTHROPIC_BASE_URL https://taotoken.net/api $env:ANTHROPIC_API_KEY 你的_TaoToken_Key $env:ANTHROPIC_MODEL claude-sonnet-4-5VS Code 里 Cline / MCP 类插件的 settings 片段settings.json{ cline.apiProvider: openai, cline.openAiBaseUrl: https://taotoken.net/api, cline.openAiApiKey: 你的_TaoToken_Key, cline.openAiModelId: gpt-5-codex }三件套记牢Base URL Key Model ID。Base URL 统一填https://taotoken.net/apiKey 用同一把Model ID 按 Agent 需要填Codex 用gpt-5-codexClaude 用claude-sonnet-4-5之类。这样 5 个 Agent 共用一套通道改配置只改一处排查时也能快速判断是通道问题还是本地工具链问题。注意Key 不要写进会提交到 Git 的文件里。auth.json、settings.json这类文件建议加进.gitignore或者用环境变量注入。配好之后建议先用一个 Agent 单独验证通道通不通再开并发。验证方法见下一节。4. 用 VS Code 加 git worktree 并行目录验证请求是否成功配置改完别急着开 5 个 Agent先用单 Agent 验证请求能通。最直接的方式是跑一次最小请求看返回里有没有正常的choices或内容字段。验证 Codex 通道终端里跑codex -C C:\proj1 用一句话说明当前目录有几个 .ts 文件如果返回正常文本说明 Base URL、Key、Model ID 三件套没问题。如果报401多半是 Key 错了如果报local proxy failed多半是 Base URL 写错或网络出口有问题如果报reading choices相关错误多半是返回体不是预期格式检查 Model ID 是否被通道支持。验证 Claude 通道claude 回复 ok 两个字母即可同仓库多 Agent 用 git worktree 隔离。如果你要在同一个项目上跑 4 个 Agent不要让它们改同一个工作区否则文件互相踩、Git 状态互相污染。正确做法是每个 Agent 一个 worktreegit 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-4VS Code 只开一个 multi-root workspace 看代码和 diffcode C:\proj1 C:\proj2 C:\proj3 C:\proj4或者做一个.code-workspace文件以后直接打开。这样 Agent 在各自 worktree 里并发干活VS Code 只启动一套主 UI 负责看代码和 Git diff不用开 4 个完整窗口。验证成功的标志4 个终端 tab 各自有 Agent 在跑任务管理器里codex.exe有 4 个、claude.exe有 1 个VS Code 只有一个主窗口加一组子进程而不是 4 个Visual Studio Code (71)那样的进程组。这时候 CPU 会忙但桌面不会卡死。5. 多 Agent 并发常见报错排查401、local proxy failed、reading choices、OAuth并发跑起来后报错会集中在几类。下面按真实报错对照排查每条都给可复制动作。401 Unauthorized。最常见Key 错了或没生效。先确认环境变量有没有真正加载echo $env:OPENAI_API_KEY echo $env:ANTHROPIC_API_KEY如果为空说明当前终端没继承到。Codex 走auth.json的话检查文件里OPENAI_API_KEY字段有没有拼错。改完重启终端再试。local proxy failed。通常是 Base URL 写错或者本机网络出口有问题。确认填的是https://taotoken.net/api不要多写或少写路径。可以用 curl 直接测curl https://taotoken.net/api/v1/models -H Authorization: Bearer 你的_TaoToken_Key如果 curl 也失败问题在通道或网络如果 curl 通但 Agent 失败问题在 Agent 配置。reading choices 相关错误。返回体不是预期格式多半是 Model ID 不被通道支持或者wire_api配错。Codex 的config.toml里wire_api要和通道匹配responses和chat不能混。检查 Model ID 拼写比如gpt-5-codex不要写成gpt5-codex。OAuth 相关报错。有些 Agent 默认走 OAuth 登录流程你配了 API Key 但它还在尝试 OAuth。这时候要显式指定用 API Key 模式或者清掉旧的 OAuth 缓存。Codex 的话检查auth.json里有没有残留的 OAuth token 字段有就删掉只留 API Key。CPU 跑满但不知道谁在吃。任务管理器只能看到Visual Studio Code (71)这种聚合定位不到具体进程。用 VS Code 的Developer: Open Process Explorer命令面板里搜打开后按 CPU 排序就能看到是 extension host、tsserver、gopls、git、webview、terminal 还是某个 dev server 在吃。如果是 language server 一直高占用去看对应项目如果是 extension host考虑关掉不必要扩展如果是 dev server停掉不用的。给 Agent 降优先级和绑核。如果机器还是被拖死可以给已启动的 Agent 降优先级Get-Process codex,claude -ErrorAction SilentlyContinue | ForEach-Object { $_.PriorityClass BelowNormal $_.ProcessorAffinity 0xFFF0 }BelowNormal是降优先级ProcessorAffinity是限制能跑在哪些逻辑线程上。0xFFF0只是例子在 16 逻辑线程机器上可以理解成避开前 4 个逻辑线程把响应空间留给 VS Code、浏览器和系统。这不一定让 Agent 更快但能让桌面更稳——宁愿 Agent 慢一点也不要整台机器卡死。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 一直盯着。dev server 单独管。多个vite、pnpm dev、go run平时没感觉但 Agent 一改文件它们就热更新、重建、重编译。4 个 Agent 在 4 个项目里改文件就很容易出现 Agent 在跑、watcher 在跑、dev server 在重建、language server 在分析、Git 在刷新。建议单开一个 cmd 控制服务进程只保留当前真正要看的 dev server不用的先停掉。6. 多 Agent 并发跑法总结与 TaoToken 通道入口把上面的东西收一下。9700X 被跑满核心不是 CPU 弱也不是 Codex 或 Claude 在本地跑大模型推理而是多个 Agent 同时驱动本地开发工具链VS Code 插件模式又叠加了 extension host、webview、watcher、language serverdev server 和 Git refresh 再一起触发。我现在会这样配主 VS Code 只保留一个窗口4 个 Agent 用 Windows Terminal 跑每个 Agent 一个项目目录同仓库多 Agent 用 git worktreeVS Code 用 multi-root workspace 看代码和 Git diff插件模式只留 1-2 个需要强交互的 Agent不用的 dev server 关掉给 Agent 降优先级或绑核CPU 异常时用 Process Explorer 定位。通道层面用 TaoToken 统一 Key 和 Base URL5 个 Agent 共用一套配置改一处就够。需要拿 Key 或看接入文档的走 API Keys 页面和接入文档想先验证模型通不通用模型对话页面跑一次最小请求长期跑编码和 Agent 任务的看 Coding Plan。API Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite最后留一句我自己的经验Agent 一动文件本地工具链就会跟着动这是并发跑法的根本约束。把干活和看代码拆开把高并发和强交互拆开9700X 还是会忙但桌面不会那么容易被拖死。