30 秒看懂
Theo Browne 调查运行 T3 Code 时浏览器 GPU 进程持续占用 CPU 的问题。他展示了如何通过受控 CSS 开关、隔离浏览器和人工检查发现相互作用的渲染效果,以及编程 agent 如何提供有用工具但给出不可靠的初步解释。
- 1空闲页面仍消耗资源Theo 观察到浏览器 GPU 进程占用较高 CPU,尤其是在高分辨率显示器上。
- 2自信但无效的修复agent 大幅改写网络和 React 逻辑,却没有明显改善所观察的症状。
- 3用于实验的开关工具agent 制作的控制台工具可以暂时关闭不同 CSS 效果;分别测试后,调查范围得以缩小。
- 4效果之间相互作用Theo 发现持续动画、背景模糊和全页面噪声覆盖层在他的设置中相互影响。
- 5其他标签干扰测量关闭另一些 Claude 窗口后,共享 GPU 进程的 CPU 数值下降。
要点建议
- 页面响应流畅,也可能让浏览器 GPU 进程持续繁忙。
- 任务管理器中的 GPU 进程 CPU 数值由多个标签共享,不等于 GPU 利用率。
- 分别切换候选效果并重复测量,有助于缩小渲染问题范围。
- 动画、覆盖层和模糊可能相互影响;单台机器上的结果不能证明普遍规律。
- 即使 agent 最初的自信解释有误,它仍可构建有用的诊断工具。
按章节阅读整理后的全文
症状与误导性的首个修复
看似空闲的页面让 Theo 的笔记本发热。agent 生成的大型性能补丁没有解决观察到的问题。
我想谈谈网页性能,以及一个由编程 agent 参与造成、却没能由它们正确诊断的问题。GPT-5.6 和 Fable 很强,但现有工具和它们推理问题的方式,仍可能让关键调查落回人身上。

T3 Code 看起来响应迅速,但浏览器 GPU 进程在 720p 下占用约 13% 至 15% 的 CPU,在更大的高分辨率显示器上可达到约 50%。这指的是 GPU 进程的 CPU 占用,并不是 GPU 本身利用率为 50%。一个简单的空闲界面不该让我的笔记本这么热。
这个问题花了我大约一天半的间歇工作,还咨询了几位性能专家。一个 Tailwind 动画类参与其中,但问题并非某个类本身必然糟糕:在这个具体布局里,持续动画、模糊和全页面噪声层之间的组合很重要。
我当时大量使用 T3 Code,同时处理许多线程和 pull request。高帧率远程串流游戏时,笔记本变得很热;第二天游戏关闭后机器仍然发热。这让我转而调查浏览器,而不是认定串流设置是唯一原因。
agent 工具链运行在其他电脑上,因此它们的资源消耗不应解释本机发热。浏览器性能工具没有显示明显异常的 JavaScript 或布局开销,但 GPU 进程仍很忙。页面响应迅速,也可能在渲染管线中消耗大量资源。
浏览器任务管理器中的 GPU 进程由多个标签页共享,并不专属于某个标签。我另开 Chrome,只保留 T3 Code,然后切换到其他网站。GPU 进程的 CPU 数值明显下降,让我更有把握认为问题与这个页面有关。

一开始我给 Codex 的描述比较模糊。它的报告指向 WebSocket 和 React 更新路径,并做出一个大改动,自信地称之为修复。但在我的使用中,症状并没有明显改善;看似合理的解释和很大的补丁,都不能证明观察到的问题已经解决。
隔离渲染问题
Theo 隔离浏览器,并让 agent 制作 CSS 开关,通过反复测量缩小问题范围。
隔离浏览器后,我开始关注可能高频反复发生的渲染工作,尤其是在 120 Hz 高分辨率屏幕上。我让 agent 盘点可能触发渲染或 GPU 工作的代码。这改变了它的角色:不再由它直接决定答案,而是协助我测试假设。
浏览器生成的摘要和两个 agent 都反复指向 Ultra Think 特效。但这个特效只在特定 Claude Code 状态下出现,而我使用 Codex、没有启用它时也遇到了问题。这提醒我们:先检查怀疑的组件在复现时是否真的存在。
我让 agent 制作一个控制台辅助工具,暂时关闭运行页面中的不同 CSS 效果。它提供动画、模糊、滤镜、阴影和噪声等开关。全部应用后,GPU 进程的 CPU 占用降到约 3%,虽然页面外观也被破坏;重置后数值又升高。

这还不是完整诊断:同时改变多个因素,只能说明这一组因素有关。我分别测试噪声和模糊,随后关闭动画,看到了更大幅度的下降。辅助工具最初的动画开关还会关闭过渡效果,所以我们把两者分开,继续更精确地调查。

agent 帮我列出并暂停动画,我再把实际测量结果反馈给它。有些检查中我关闭了 DevTools,因为打开开发者工具本身可能改变页面行为和性能。任务管理器有助于对比,但它显示的是共享进程,因此仍需谨慎解释。
动画、模糊与噪声层
在测试的布局中,状态脉冲与合成效果相互作用。视觉修复也需要仔细调整。
我的测试表明,侧边栏的脉冲状态指示器(包括终端图标)影响明显;上下文圆环则没有同样的效果。模型推测持续的不透明度动画可能让高刷新率屏幕上的合成工作持续进行。这是对渲染路径的假设,并非所有脉冲动画都昂贵的普遍规律。
第一个建议是删除或缩短脉冲,我不喜欢它的视觉效果,也认为范围太窄:其他状态指示器同样有影响。较慢的闪烁在我的测试中只稍好一些,外观也不理想。修复若损害体验或漏掉相关场景,只改善一个指标还不够。
我把另一条调查交给独立 Linux 机器上的 Fable,让不同 agent 工作时不互相干扰。Fable 列出了动画清单,最初优先关注加载骨架和 Ultra Think 特效,但两者都无法解释我正在测试的空闲场景。

清单后面列出了反复运行的状态脉冲,以及一个可能放大开销的因素:背景模糊。agent 认为,模糊层后面的内容变化可能增加渲染工作。这个解释有助于指导调查,但具体浏览器行为仍取决于页面、浏览器和硬件。
页面还有一个低透明度噪声覆盖层,用来让灰色表面不那么单调。在我的环境中,这个全页面效果与模糊、持续动画组合,造成了严重的空闲开销。先前单独切换噪声时并不足以解释问题;关键观察是这些效果的组合。

最初的视觉修复让不同区域的灰色不一致,在我的 HDR 显示器上尤其明显。我移除了全局覆盖层并花时间调色;agent 的建议多次改错了区域。最终结果既需要性能检查,也需要人工检查外观。
其他标签与 agent 的角色
其他浏览器窗口解释了修复后具有误导性的读数。Theo 反思由人引导诊断、由 agent 构建工具的方式。
发布修复后,我回到常用浏览器,却再次看到 GPU 进程的 CPU 占用很高。我以为合并可能失败,于是逐个关闭标签继续调查,而不是立即断定补丁无效。因为进程是共享的,这一步是重要的对照。
我忘了另外两个打开 Claude 页面的浏览器窗口。关闭它们后,数值降到了预期水平。我在自己机器上观察到这些页面有明显的空闲开销,但这是本地观察,不能当作对所有版本和设备的基准结论。
我也曾在其他 agent 界面中看到性能回退,这也是我构建开源替代品的原因之一。即便已有大量用户,我仍花了两个深夜追踪这个问题。更强的模型并没有消除复现、测量和理解问题的必要性。
agent 仍然很有价值:它们快速搜索代码,并构建自定义工具测试我的假设。它们自信给出的诊断和修复建议经常出错,但这些工具让调查比完全手工操作快得多。我的经验则提供了问题和解释,指导工具的使用。

最终改动调整了状态动画,把颗粒效果从固定的全视口覆盖层移走,并修正了视觉色调。我对自己环境中的改进很满意。经验是:即使 agent 无法独立找到答案,也可以用证据引导它,让它帮助构建诊断工具。
agent 不必事先知道解决方案才能发挥作用。它可以协助搜索、构建实验和比较结果,而工程师仍负责提出问题、测量以及最终判断。
同频道的其他文章
38:47EN → 简体中文
36:07EN → 简体中文
30:37EN → 简体中文
0:43EN → 简体中文
29:22EN → 简体中文
31:13EN → 简体中文