深夜测试说明书

我之前也踩过这个坑，MCP拉起进程的时候确实不会自动带torchrun那套环境变量，你得自己在tool里把MASTER_ADDR、MASTER_PORT、RANK和WORLD_SIZE这些显式传给子进程，不然init_process_group肯定找不到通信端点。而且我感觉MCP官方可能压根没想过要直接兼容分布式训练，它的定位更偏向于agent工具调用，所以别指望它自动处理多机通信。我现在的做法是

别太纠结prompt，7B模型对格式约束的跟随能力确实有限，这不是你写法问题。我试过最稳的办法是让模型先输出一个“思考草稿”再让它生成JSON，或者干脆用函数调用（function calling）模式，比纯靠prompt硬掰靠谱得多。另外可以加个后处理脚本兜底，比如用正则校验字段名，漏了就补默认值，比反复调prompt省心。

我之前也踩过这个坑，后来发现问题多半出在拼接顺序和分隔符上。MCP返回的上下文会被当做一个连续序列，你直接把多个片段堆一起，模型自然容易把注意力全放在末尾。建议在工具返回前，给每个片段加上明确的元信息，比如来源和相关性评分，再按分数降序排列，中间用特殊标记隔开，这样模型能更好分辨边界。 另外top_k别死磕一个值，我最后是动态调的，先让工具返回5个片段，然后根据查询和片段的相似度做一次重排，只保

八成是stdio的通信超时设置问题，试试在server代码里把read_timeout调大点。 我之前也卡这，后来发现是Python SDK默认的等待时间太短，改完就稳了。

这个分析挺到位的，我试过直接替换asar，结果每次Codex一更新就得重新弄，确实烦。Dream Skin这种动态加载的思路靠谱，相当于把皮肤做成了独立模块，升级时只要适配器还兼容就行。不过有个疑问，钩子注入这种方式在Electron底层改动大的版本（比如Chrome内核升级）会不会也失效？毕竟拦截的是API，如果接口签名变了，适配器也得重写吧。

同感，代码审查这块我也试过。上周拿GPT-5跑了几个内部项目的PR，确实对那种多层嵌套的逻辑错误抓得比GPT-4准很多，尤其是那种“if-else里套了三层循环还带异常捕获”的烂代码，它能直接指出某条路径永远不可达。但边界条件是真的拉胯——我测了个经典的并发HashMap写入场景，它居然没识别出putIfAbsent和get的竞态问题，反而建议加synchronized块，这解法在低竞争场景下其实