都说 MacBook 用起来丝滑流畅而且电池耐用，可我却并没有这种感受，反而经常觉得卡卡的，而且键盘和掌托可以把我手烤熟，让我怀疑是不是买到了假苹果电脑。
这次又被烫得不行的时候，我打开活动监视器，果然 Code Helper (Plugin) 和 chrome_crashpad_handler 两个老熟人赫然在列。之前也不是没有查过它们的信息，都说是 VS Code 插件和 Chrome 浏览器的问题。可是就算退出两个软件，进程依旧还在，并且 CPU 占用始终居高不下。
之前让 Codex 诊断过，但没有解决。想到豆包近期的更新增加了电脑操作方面的能力，耕读君我就想试试看，本土的 AI 会不会有更好的手段。
把截图丢给豆包，它不是单纯解读图片上的信息，而是加载 doubao-pc-optimizer 技能（skill）来查看当前实际情况，这让我瞬间觉得，说不定有戏。
收集系统信息后，豆包确认不是硬件问题：
进一步调查，豆包发现虽然名字看起来像是 Chrome 浏览器的锅，然而其实两个进程都是 VS Code 的。
而插件和崩溃处理程序如此异常，是因为当初我下载 VS Code 程序到 Downloads 路径下，固定到程序坞之后就一直这么用着，没有拖到「应用程序」里。原理如下：
macOS 对从下载文件夹启动的 App 会做 AppTranslocation（隔离转译），让它从只读临时副本运行 —— 这是已知会引发 Electron 类应用崩溃循环、插件异常的典型诱因，也很可能就是 crashpad 空转的根源。
讲真，如果不是 agent 实际探查进程和本地的文件路径，我打死也想不到是因为这个原因导致的。
诊断清楚原因，豆包提供了解决方案，我也不打算自己动手了，让它直接操作。很快操作完成，给了处理结果：
之后我依然开了几个 VS Code 窗口同时使用，再也没有出现程序频繁崩溃导致 CPU 长时间占用以及发热的情况。
Agents 兴起后，AI 就不再是单纯的内容生产工具，而是变成了可以与系统、软件交互的中枢，应用场景增加了不止一个维度。
各大模型都在竞争排行榜和性价比，但模型的强大只是一方面，配套的生态也很重要，像 Codex、WorkBuddy、ZCode 这些 agent 就都做得挺成功的。如果遇到某个问题，单个模型或 agent 无法解决的话，不妨多试几个，说不定很快就搞定了。
