基础信息
排查日期：2026-06-08 ~ 06-09
环境：Windows 11 家庭中文版 · Intel Core Ultra X7 358H · Codex 桌面版 26.602.71036
一、摘要（一句话版）
你以为"Codex 只是云端推理的壳子、本地不该发热"，但实测发现：推理确实在云端，本地却跑着一个完整的 Electron 应用 + 一个会无限重启的失败插件 + 在沙箱里被放大 80 倍的本地测试。这些"脉冲式"本地负载，把你那颗低基础频率的笔记本 CPU 反复踹进 Turbo，于是出现了"任务管理器看着不忙、机器却烫、风扇狂转"的反直觉现象。根因与云端推理无关，全在本地。
二、起点：一个反直觉的现象
- 观察：运行 Codex 时，PC 明显发热、风扇拉高，系统像是进入了"性能模式"。
- 用户心智模型：Codex = 云端 agent 的瘦客户端，本地只做 UI 和消息收发，不该有重计算。
- 矛盾点：既然推理在云端，本地凭什么发热？
这个矛盾正是整个排查的线索——它说明本地一定在做某种"看不见的重活"。
三、排查叙事：五轮逐步逼近真相
排查不是一步到位的，每一轮都修正了上一轮的判断，过程本身很有参考价值：
第 1 轮 · 抓 CPU 占用 → 扑空。
按进程采样 CPU，最高的codex也才 5~6%。表面看"没有谁在烧 CPU"，反而加深了困惑。
第 2 轮 · 查电源与频率 → 发现真正的反差。
电源方案是"平衡"，但% Processor Performance持续129%~187%——CPU 一直骑在 Turbo 上（base 仅 1.9GHz 的 Core Ultra X7）。关键认知诞生：发热由频率/电压决定，不由占用率决定。占用 30%+ 却满频，正是发热效率最差的状态。
第 3 轮 · 抓底层唤醒证据 → 锁定"脉冲负载"。
上下文切换5~6 万次/秒、中断 2~3 万次/秒（空闲机器通常仅几千）。这是"大量短命任务不停戳醒 CPU"的铁证。同时排除了计时器分辨率（被微信/钉钉拉高，非 Codex）。
第 4 轮 · 实时盯进程创建 → 抓到真凶。
高频监控进程 spawn，发现codex.exe每~13 秒重启同一组进程：npx -y xcodebuildmcp+node mcp/server.cjs+ 4 层git ls-remote。一个失败的 MCP 服务器卡在重启循环里。
第 5 轮 · 读测试代码 + 对比跑 → 发现第二个独立热源。
你提到那条 pytest 在 Codex 里跑 40 分钟。读完代码确认无单点 hang，再在普通终端实测：249 个测试 29.9 秒通过。两者相差约80 倍——确认是Codex 沙箱放大了本地 I/O。
四、环境画像
| 维度 | 实际情况 |
|---|---|
| 操作系统 | Windows 11 家庭中文版 |
| CPU | Intel Core Ultra X7 358H，基础频率仅1.9GHz，异构核（P/E/LP-E），开启 Speed Shift(HWP) |
| Codex 形态 | 桌面应用（WindowsApps\OpenAI.Codex），基于Chromium 149 的 Electron，多进程 + GPU 进程 |
| 显示 | 高分屏，device-scale-factor=1.75（渲染面积约 3 倍） |
| Codex 配置 | 启用了build-ios-apps/build-macos-apps插件；[windows] sandbox = "unelevated" |
| 项目 | imterminal0228 /localim（IMAgent，企业 IM 本地终端机器人） |
| 背景软件 | 微信、钉钉、飞书、搜狗输入法、小米服务、Clash 代理(127.0.0.1:7890) |
五、根因拆解（三层因果）
第 1 层 · 物理层：为什么"占用不高也发烫"
CPU 功耗 ≈电压² × 频率。Turbo 把频率从 1.9GHz 拉到 3GHz+ 时电压同步抬高，功耗呈平方级上升。所以同样的活，用 Turbo 高频去做，发热是 base 频率的数倍。占用率不是发热指标，频率才是。
第 2 层 · 调度层：为什么频率被钉在 Turbo
Speed Shift 调速器在亚毫秒级反应，策略是"race to idle"——见到任何小爆发就立刻顶到最高频率尽快做完。只要爆发足够密集（5~6 万次/秒上下文切换），频率就几乎一直停在 Turbo，哪怕平均占用很低。低基础频率 + 薄机身散热，把这个效应进一步放大。
第 3 层 · 触发源：是谁在制造密集爆发
本地有三个独立来源，叠加供热：
失败 MCP 的重启循环（尖峰主因）
你在 Windows 上启用了 Mac 专属插件build-ios-apps/build-macos-apps，其.mcp.json定义的npx -y xcodebuildmcp@latest需要 Xcode、在 Windows 必然失败 → Codex 每 ~13 秒重启它 → 每轮喷一波npx/node/git冷启动短命进程（V8 初始化、包解析、TLS 握手都是 CPU 密集）。因为是短命进程，任务管理器抓不到。Codex 桌面版的 Electron + GPU（常驻底噪）
它本质是个 Chromium 浏览器内核，多进程 + GPU 渲染进程长期是全机 GPU 占用第一；流式输出时按帧重绘，叠加 1.75x 高分屏，持续供热。沙箱里的 40 分钟测试（间歇大热源）
你的测试套件含约 50 个"每条都真起一次 HTTP 服务器"的 web 用例。裸终端 30 秒，但 Codex 的sandbox=unelevated拦截放大每一次 socket/进程/文件 I/O 约80 倍→ 膨胀成 40 分钟满载。
已排除的因素
- ❌ 云端推理跑到本地（CPU 无推理负载）
- ❌ 系统代理拖慢（实测 127.0.0.1 绕过代理、2 秒内连接被拒）
- ❌ 测试代码本身有 bug 或死循环（裸终端 30 秒健康通过）
- ⚠️ 计时器分辨率被拉到 4ms——元凶是微信/钉钉/输入法，非 Codex，仅次要加重
六、关键证据链汇总
| 证据 | 实测值 | 含义 |
|---|---|---|
| 各进程 CPU | 全程 < 6% | 排除"推理在本地" |
| % Processor Performance | 129%~187% | CPU 持续骑 Turbo |
| 上下文切换 / 中断 | 5~6 万 / 2~3 万 每秒 | 密集短命任务唤醒 |
| 进程创建监控 | xcodebuildmcp等每 ~13s 重启一轮 | 失败 MCP 的重启循环 |
.mcp.json+ config.toml | npx -y xcodebuildmcp，插件enabled=true | 重启循环的来源 |
| pytest 裸终端 vs Codex | 29.9s vs 40min（~80×） | 沙箱放大本地 I/O |
--durations | 慢的全是test_web_bridge.py~0.5s/条 | 每测试真起 HTTP 服务器是主成本 |
七、解决方案（按问题分场景）
A. 立即止血：发热（重启循环）
在 Windows 的 Codex 里关掉build-ios-apps/build-macos-apps插件（config.toml里enabled=false，重启 Codex）。这直接干掉每 13 秒的进程风暴。等真在 Mac 上开发时再在 Mac 端启用。
[plugins."build-macos-apps@openai-curated"] enabled = false [plugins."build-ios-apps@openai-curated"] enabled = falseB. 根治：40 分钟测试（满足"全覆盖 + Codex 即时感知"）
- 共享服务器 fixture：把
test_web_bridge.py的make_server()从"每测试一个"改成module 级 fixture，整文件复用 1 个服务器——沙箱要放大的 I/O 从 ~50 次降到 1 次，不丢任何用例。 - 并行：
pytest -n auto（pytest-xdist），16 核近线性加速；port=0+tmp_path天然隔离，并行安全。 - 改完重测；若仍偏慢，再用节奏分层（快层每次迭代跑、全量层关键节点跑，但两层都跑、不漏覆盖）。
C. 降基础底噪（可选）
关 Codex 多余工作区窗口、关 GPU 硬件加速；退掉常驻微信/钉钉后台（顺带解决计时器警告）。
D. 工程隔离（架构层）
Xcode 依赖的用例加@pytest.mark.skipif(sys.platform != "darwin")，macOS 专属验证交给 Mac 或 macOS CI；日常在 Windows 开发跨平台逻辑即可，无需迁到 Mac。
八、引申思考
"瘦客户端"是个幻觉。现代 agent 桌面应用 = Electron 浏览器内核 + 本地 agent 后端 + 插件子进程。云端只承担推理，"编排、渲染、工具执行、插件托管"全在本地，发热天然来自本地。
占用率是个误导性指标。在低基础频率 + 激进 Speed Shift 的笔记本上，真正决定发热的是频率和负载的时间形状。脉冲式负载（Electron 帧、流式刷新、短命进程风暴）是最坏的一类——平均占用低却长期满频。诊断这类问题要看频率、上下文切换、进程 churn，而非任务管理器的占用百分比。
失败要"响亮"，不要"静默重试"。
xcodebuildmcp在错误平台上启动失败，本应一次性禁用并告警；而"每 13 秒静默重启"把一个配置错误变成了持续的资源黑洞。任何重启/重试逻辑都该有退避和上限。跨平台野心要配跨平台守卫。你为"将来上 macOS"启用了 Mac 插件、写了 Mac 相关测试——方向对，但缺少"按平台隔离"的纪律。平台抽象的价值，恰恰在于让不属于当前平台的代码/插件/测试自动失效，而不是在错误平台上空转。
沙箱的隐性成本要量化。安全沙箱拦截 I/O 会带来数量级的性能税。对"重 I/O 的集成测试"，沙箱内外可能差 80 倍。决策原则：要么消除真 I/O（进程内测试 / 共享资源），要么把重 I/O 任务移出沙箱——但前提是先用"沙箱内 vs 外对比"把成本测出来，而不是凭感觉。
排查方法论：现象 → 机制 → 触发源，逐层下钻。本案每一轮都推翻或修正了上一轮的假设（CPU 占用→频率→唤醒→进程风暴→沙箱）。遇到反直觉现象时，最初的解释往往是错的；用数据逼近，并对自己的假设保持可证伪。
附录 · 复现/诊断命令速查
# 1. 采样 Top CPU 进程（3 秒增量）$p1=@{};Get-Process|?{$_.CPU}|%{$p1[$_.Id]=$_.CPU};Start-Sleep3;Get-Process|?{$_.CPU-and$p1[$_.Id]}|%{[PSCustomObject]@{N=$_.ProcessName;Pct=[math]::Round(($_.CPU-$p1[$_.Id])/3/16*100,1)}}|sortPct-desc|select-First 10# 2. 看 Turbo / 唤醒Get-Counter'\Processor Information(_Total)\% Processor Performance','\System\Context Switches/sec','\Processor(_Total)\Interrupts/sec'# 3. 实时盯进程创建（抓重启循环）—— 见正文第 4 轮脚本# 4. 测试套件在普通终端跑（对比 Codex）cd/d D:\PersonalProject\imterminal0228$env:PYTHONDONTWRITEBYTECODE='1';python-B-m pytest tests-q-p no:cacheprovider--durations=25# 5. 能耗诊断报告（需管理员）powercfg/energy/duration 60/output"$env:USERPROFILE\energy-report.html"附录 B · 第七节 B “共享 fixture” 方案（现状：已落地）
复查
tests/test_web_bridge.py时发现，这套共享服务器方案已经实现在代码里（ReusableWebBridgeHarness+_rebind+ module 级 autouse fixture）。以下记录的是实际实现，而非草稿。
B.1 设计思路（三块拼图）
把"每个测试起一个ThreadingHTTPServer"改成"整个 module 共用一个服务器、每个测试只重绑后端状态"，关键是在不重启服务器的前提下做到测试间状态隔离。靠三个部件配合：
单例 harness + 重绑（
ReusableWebBridgeHarness.configure/_rebind）
服务器只在第一次configure()时start_background()起一次；之后每个测试不再新建服务器，而是把现有 bridge 的router / settings / task_center / schedule_store / files / memory / shares / authorizer等重新指向当前测试的cwd，并清空 token、jsapi ticket、h5 session 等易脏字段。代理句柄 + 让
shutdown()变空操作（ReusableWebBridgeHandle）
返回给测试的不是真 bridge，而是一个透传属性的句柄；它的shutdown()调的是harness.release()（no-op）。这样现存测试里那一堆bridge.shutdown()一行都不用改，却不会真的把共享服务器关掉。专门有一条test_web_bridge_test_server_survives_per_test_handle_shutdown守住这个不变量。module 级 autouse fixture + 环境还原
@pytest.fixture(scope="module", autouse=True)负责建/拆唯一的 harness；另一个 function 级 autouse fixture 在每个测试后还原被改动的LOCALIM_*环境变量，保证隔离。
B.2 为什么满足"全覆盖 + 即时感知"
- 覆盖不丢：用例、断言、调用方式全不变（
make_server()签名和返回元组都保持），只是底层从"新建服务器"变成"重绑"。 - 服务器启停 50 次 → 1 次：沙箱要放大的 socket/线程 I/O 大幅减少。
make_server仍有非共享回退：当_SHARED_WEB_BRIDGE is None时退回原来的"每次新建"，独立调用该函数的代码不受影响。
B.3 现状下的剩余优化空间（如还需更快）
共享服务器之后，单条 web 测试的开销已不再是 HTTP 服务器启动，而是每测试_rebind时重建MessageRouter / SessionStore / LocalFileService / AgentTranscriptReader.from_env / ...的构造成本（裸终端实测约 0.5s/条）。要再压：
- 并行：
pip install pytest-xdist→pytest -n auto（注意：module 级共享服务器在 xdist 下是每 worker 一个，仍安全）。收益最大、零改动。 - 削构造成本：检查
AppSettings.from_env()与AgentTranscriptReader.from_env()在构造期是否做了可缓存的工作（读盘 / 扫目录 / 探测二进制），能否在测试里用一个轻量 settings 复用。 - 沙箱是独立轴：以上都是"减少要被放大的 I/O"；若在 Codex 里仍偏慢，仍需配合第七节 A/④（关失败插件、让该项目测试绕过沙箱）一起解决。
B.4 实现骨架（节选自当前代码，供归档对照）
classReusableWebBridgeHandle:# 透传到真 bridge；shutdown() 改为释放（no-op），保护共享服务器defshutdown(self)->None:self._harness.release()classReusableWebBridgeHarness:defconfigure(self,cwd,token="",task_center=None,schedule_store=None):router,settings=new_router_and_settings(cwd)ifself.bridgeisNone:# 只起一次self.bridge=WebBridgeServer(router,host="127.0.0.1",port=0,...)self.bridge.start_background()else:self._rebind(router,settings,token,task_center,schedule_store)# 重绑而非重启returnrouter,self.handle@pytest.fixture(scope="module",autouse=True)defshared_web_bridge_harness():global_SHARED_WEB_BRIDGE harness=ReusableWebBridgeHarness()_SHARED_WEB_BRIDGE=harnesstry:yieldfinally:_SHARED_WEB_BRIDGE=Noneharness.shutdown()# module 结束才真正关服务器defmake_server(cwd,token="",task_center=None,schedule_store=None):if_SHARED_WEB_BRIDGEisnotNone:return_SHARED_WEB_BRIDGE.configure(cwd,token,task_center,schedule_store)# 回退：无共享 harness 时仍每次新建（保持独立调用兼容）...
