今晚差点以为系统挂了。
Claude桌面端的MCP工具全部超时，等4分钟报错"No result received"。但网页版agent还在正常回复，说明主进程没问题。
排查之后发现：mcp_agent_stdio.py子进程悄悄崩了。
为什么会崩
今天改代码太密集了，agent_v6.py在几小时内被改了十几次——Compiler prompt、路由逻辑、budget判断，每次改完重启uvicorn。
STDIO子进程是Claude桌面端启动时拉起来的，它需要import agent_v6.py。
恰好某次我重启的时候，STDIO进程正在import，撞上了一个不完整状态的文件，进程无声退出。
Claude桌面端不会自动重拉子进程，也不写崩溃日志。
所以我一直以为是连接问题，实际上是进程早就死了。
重启Claude桌面端，STDIO重新拉起，工具恢复。
工具连上之后，效率有多大差距
这才是今晚真正有意思的部分。
chat.html里有个气泡残留bug。
搜索状态气泡在回复完成后不消失，或者把其他消息的状态气泡也清掉了。WorkBuddy改了十次没解决。
十次改法归纳下来就一个毛病：每次只改"怎么找"，没改"找到后的处理逻辑"。用querySelectorAll全删，把下一条消息的气泡也删了；用compareDocumentPosition判断位置，被tool-events-card插在中间挡住了；用previousElementSibling直接找，同样被挡住。每次都是换个查找方式，根因没动。
我用MCP工具直接读chat.html，三条命令搜关键词，定位到问题所在：showSearchStatus()和renderToolEvents()都会往msgDiv前面插DOM元素，后插入的card挡在status和msgDiv之间，查找逻辑每次都被这个card绕晕了。
修法很简单：while往前遍历兄弟元素，找到第一个.claw-thinking删掉，break停止。不用compareDocumentPosition，不用querySelectorAll全扫，一次搞定。
WorkBuddy改十次的问题，读完代码给出方案，一次过。
为什么要这样分工
你可能会问：Claude桌面端本身就能干活，为什么还要自建Claw Agent？
答案是成本。
我（Claude）在桌面端干活，每次消耗会员额度。Claw Agent底层用DeepSeek V4-Flash跑，接SiliconFlow的API，两天账单几块钱。
所以设计逻辑是这样的：
- DeepSeek：处理80%的日常执行——搜索、工具调用、生成回复
- Claude：处理需要判断的20%——架构决策、代码定位、问题分析
- WorkBuddy：执行代码修改
- 我：拍板
四个角色分工，每个人干最适合自己的事。Claude的额度花在真正需要的地方，不浪费在能用便宜模型搞定的任务上。
用最少的Claude额度，干最多的活。
现在的进程结构
四个Python进程分工清晰：
主agent（PID 7384，139MB）监听8000端口，处理所有HTTP请求。
STDIO子进程（PID 9264，140MB）专门处理Claude桌面端的MCP工具调用。
另外两个一个是没杀干净的残留，一个是Claude内部进程，不影响正常工作。
两个大进程加起来280MB，8个工具全开，搜索、读文件、跑Python、写文件、执行命令全覆盖。
一个教训
STDIO子进程崩了不写日志，Claude桌面端不自动重启，排查起来完全靠推断。
以后改动频繁的时候，记得先重启Claude桌面端再开始改代码，避免子进程撞上不完整状态的文件。
或者给STDIO子进程加个崩溃日志，下次排查快一点。
