2026 年 10 月 1 日，我在继续维护 A Tour of Go 多语言翻译项目时，遇到了一次相当奇怪的问题。
表面现象是：
原本一直正常使用的 Desktop Commander / RDC，在多个已有 ChatGPT 会话中突然不可用了。
但经过一整天的排查以后，我越来越觉得问题并不只是 Desktop Commander。
因为与此同时，ChatGPT 本身也出现了一种我以前遇到过的、非常熟悉的异常行为：
能分析，能解释，能告诉我“下一步应该做什么”，但就是很难真正把任务连续执行完。
更值得注意的是：
到了第二天，也就是 2026 年 10 月 2 日，在没有重新设计整个项目工作流的情况下，这些问题又基本消失了。
RDC 可以正常工作，ChatGPT 也重新恢复了长时间连续执行能力，一个回复甚至可以持续工作二十多分钟。
这让我最终更倾向于认为：
10 月 1 日真正的问题，很可能不是我的项目，也不仅仅是 RDC，而是当天 ChatGPT 后台模型路由或运行时能力出现了异常。
先强调一点：
我无法看到 OpenAI 后台真实的 model route，也没有 server-side trace，因此无法证明请求究竟被路由到了哪个具体模型。
文中提到的“可能被路由到 GPT-5.5”，是基于两次高度相似的实际使用表现作出的判断，不是后台日志意义上的事实。
一、项目背景
我目前维护的是：
shuijingwan/go-tour-i18n这是一个 A Tour of Go 多语言翻译项目。
整个工作流不是普通的“问 ChatGPT 一个问题，然后复制答案”。
项目长期使用：
- ChatGPT Generation session；
- Independent Reviewer session；
- Desktop Commander Remote；
- 本地 Git 仓库；
- 自动 validation；
- Snapshot；
- QC state machine；
- Production gate。
Desktop Commander / RDC 在里面承担的作用非常重要。
ChatGPT 需要通过它：
- 读取
AGENTS.md； - 读取 workflow / runbook；
- 检查真实仓库状态；
- 写入语言文件；
- 执行 validation；
- 导出、检查和处理后续工作材料。
因此，一旦 RDC 工具能力异常，整个 Agent 工作流都会受到影响。
二、10 月 1 日：已有会话突然失去 RDC
当天继续工作时，我先在已有项目会话中做了一个非常简单的测试：
请确认当前会话是否具有 Desktop Commander / RDC 工具访问能力。
如果具有：
请读取：
~/code/go-tour-i18n/AGENTS.md返回结果很明确：
当前会话没有 Desktop Commander / RDC 工具访问能力。
也就是说，这个原本一直参与项目工作的 ChatGPT 会话，此时甚至无法读取本地仓库中的基础 authority 文件。
这时候最直观的怀疑当然是：
Desktop Commander 出问题了。
但事情随后变得更复杂。
三、ru-RU Generation 旧会话也失去实际执行能力
当时我还有一个正在处理 ru-RU 的 Generation session。
这个会话的工作原本很明确。
它应该继续生成和写入：
internal/tour/ui/ru-RU.json以及：
locales/ru-RU/article-metadata.json这意味着它不仅要“回答问题”，还必须真正完成：
读取 authority
→ 读取 glossary
→ 生成译文
→ 写入文件
→ JSON validation
→ TODO residue check但当天实际发生的事情是：
会话告诉我：
当前消息环境中没有可调用的 Remote Desktop Commander。
因此不能：
- 读取真实仓库文档；
- 修改
internal/tour/ui/ru-RU.json； - 修改 article metadata；
- 执行 validation；
- 检查实际文件状态。
随后它又开始告诉我：
当前唯一下一步……
这张截图后来变得非常重要。
因为我当天遇到的不只是：
“一个工具连接不上。”
与此同时，ChatGPT 又重新出现了我此前非常熟悉的一种行为：
分析
→ 继续分析
→ 解释自己应该做什么
→ 给出下一步
→ 不实际完成任务而不是正常情况下的：
读取
→ 执行
→ 写入
→ 验证
→ 返回证据对普通问答来说，这种区别可能不那么明显。
但对于已经重复执行过很多次固定流程的工程项目来说，差别非常大。
四、为了恢复 RDC，我实际上做了远不止一次“状态确认”
这里需要特别说明。
后来看到 Desktop Commander 显示 Online，并不是因为我只是随手重新运行了一次命令。
在此之前，我已经做了一系列恢复操作，包括：
- Revoke 原设备 / 授权；
- 卸载 ChatGPT 中的 Desktop Commander 插件；
- 重新启动和检查 RDC；
- 再次完成授权；
- 重新安装 ChatGPT 中的插件；
- 重新建立设备连接。
也就是说：
后来的
Status: Online是经过一整轮重新绑定和重新安装后的结果。
最终 Desktop Commander Remote 终端显示：
Device marked as online
Device ready
Desktop Commander Remote is connected
Status: Online管理页面同时显示：
You're connected
因此，这张截图不能简单理解成：
“确认 RDC 本地状态正常。”
它代表的是：
经过比较复杂的一轮恢复操作后，RDC 基础连接终于重新建立。
五、旧会话仍然不可靠，于是我重新创建 ChatGPT 会话
RDC 恢复之后，我又继续测试。
这时候我开始发现：
已有旧会话的状态仍然不可靠。
因此我没有继续死磕原来的几个聊天窗口，而是重新创建了一批新的会话。
在新会话中再次进行最小测试：
请确认当前会话是否具有 Desktop Commander / RDC 工具访问能力。
如果具有：
请使用 Remote Desktop Commander 读取：
~/code/go-tour-i18n/AGENTS.md
只需要返回：
1. RDC 是否可用；
2. AGENTS.md 文件前 5 行内容。这一次成功了。
新会话返回：
RDC 可用。
并且真的读取了：
~/code/go-tour-i18n/AGENTS.md
到这里，看起来问题似乎解决了。
但实际上还没有。
六、“可以读取”并不等于“已经恢复正常工作”
这是当天非常容易误判的一点。
新的 ChatGPT 会话已经可以：
调用 RDC
→ 读取 AGENTS.md如果只进行一个简单 smoke test，很容易得出结论：
RDC 已经恢复，一切正常。
但真正回到 Generation 工作以后，我发现情况并不是这样。
实际体验仍然是：
- 简单读取偶尔可以完成；
- 真正进入较长的 Generation 流程以后，执行连续性明显不足；
- 很容易重新回到“说明自己准备怎么做”的模式；
- 本来应该连续完成的读取、生成、写入和验证，会停在中间。
也就是说：
工具表面上恢复了，但 Agent 的完整工作能力没有恢复。
这是我后来开始怀疑模型本身的关键原因。
七、当天我考虑过两个 RDC 侧原因
在还不能判断是不是模型问题的时候，我当然首先从 RDC 自身找原因。
当时有两个值得怀疑的时间因素。
可能原因 1：RDC 月度额度重置
10 月 1 日正好处于新的月度周期。
因此我考虑过：
RDC 的月度额度、账户状态或者服务侧资源重置，是否可能让已有连接或授权状态出现异常？
这个方向当时无法验证。
但至少从时间点上值得记录。
这里需要强调：
我说的是：
RDC 月度周期变化
→ 可能影响 RDC 连接状态而不是：
额度重置
→ ChatGPT 自动变成某个模型后者没有因果依据。
可能原因 2：RDC CLI 升级
另一个可能因素是：
Desktop Commander CLI 当时也存在版本变化。
因此同样存在一种可能：
RDC CLI 更新
→ 连接 / session / compatibility 出现变化这也是为什么当天我花了大量时间：
- 重装；
- Revoke；
- 重新授权；
- 重建连接。
但是最终，仅仅解释成 RDC 自身问题仍然解释不了所有现象。
因为即使新的 ChatGPT 会话已经能够读取文件：
ChatGPT 整体执行能力仍然明显异常。
八、真正让我怀疑模型路由的，是“只说不做”
这其实是整件事情最重要的一部分。
当天的 ChatGPT 界面仍然显示：
GPT-5.6 Sol High但是实际工作表现却让我产生了非常强烈的违和感。
最典型的现象就是：
只说不做。
例如任务要求的是：
生成 ru-RU UI
→ 写回文件
→ validation结果却很容易变成：
我已经读取……
接下来需要……
下一步是……
请继续……但真正的文件修改迟迟没有完成。
这不是我第一次遇到这种情况。
此前我已经经历过一次几乎完全相同的行为变化。
因此当天后半段，我越来越怀疑：
虽然界面仍显示 GPT-5.6 Sol High，但后台实际处理请求的模型 route 可能已经发生了变化。
我当时最怀疑的是：
请求可能被路由到了 GPT-5.5，或者至少没有运行在此前正常工作的 GPT-5.6 Sol High 路径上。
仍然需要再次强调：
我无法直接证明具体后台模型 ID。
用户侧没有：
- OpenAI routing log；
- server trace；
- hidden model ID；
- 内部调度信息。
所以“GPT-5.5”仍然是工程判断，而不是服务器日志结论。
九、为什么我当天最终决定停止工作
到下午以后，我发现继续工作已经开始得不偿失。
这是一个严格依赖状态机的工程项目。
TranslationUnit、Glossary Review、QC、Snapshot、Production 都有明确的 gate。
如果模型只是：
慢一点。
那完全可以继续。
但如果表现是：
偶尔能读
但执行不完整
状态判断不稳定
不断告诉用户下一步那么继续推进的风险就太高了。
最坏的情况不是：
今天少完成一门语言。
而是：
- 半成品被当成完成；
- validation 没有真正运行；
- 文件状态与聊天描述不一致；
- provenance 混乱；
- 后续还要重新审计恢复。
因此我最终决定：
停止当天正式项目推进。
连原本准备写的博客也停止了。
更新了一下电脑软件以后直接关机，准备第二天重新测试。
十、10 月 2 日：情况突然恢复正常
第二天早上，也就是 2026 年 10 月 2 日，我重新开始工作。
结果和前一天形成了非常明显的反差。
这一次：
- RDC 可以正常连接；
- ChatGPT 可以正常调用 RDC；
- 可以读取真实仓库；
- 可以继续执行实际 Generation 工作；
- 长任务连续执行能力恢复。
其中一个实际任务，单次回复持续执行了：
23m 56s也就是接近 24 分钟。
而且不再是前一天那种：
分析一下
→ 说明下一步
→ 停下来等待而是可以持续工作很长时间。
这张截图对我的判断影响很大。
因为项目、机器和整体工作方法并没有在一夜之间发生根本变化。
但是：
10 月 1 日
→ RDC 异常
→ 新会话只能勉强读取
→ Generation 连续执行能力明显下降
→ 大量“只说不做”到了：
10 月 2 日
→ RDC 正常
→ 工具工作正常
→ 长任务连续执行恢复
→ 单次执行超过 20 分钟差异非常明显。
十一、为什么现在我基本倾向于模型路由异常
经过第二天的对照，我现在对前一天问题的判断比当天更明确。
如果问题主要来自：
项目 workflow 错误
那么第二天不应该自行恢复。
本地仓库错误
同样不会自行恢复。
Prompt 设计突然失效
也很难解释为什么第二天相同类型工作重新正常。
RDC CLI 本身持续存在严重兼容问题
那么 ChatGPT 第二天也不应该直接恢复正常的长期 Agent 工作。
但实际情况恰恰是：
第二天一切基本恢复。
而最明显变化的是：
ChatGPT 本身重新具备了正常的长任务执行能力。
因此，从用户侧工程表现来看，我现在基本倾向于：
10 月 1 日存在模型路由或运行时能力异常。
并且结合我此前遇到过一次几乎相同的情况，我个人进一步怀疑：
界面虽然显示 GPT-5.6 Sol High，但当时实际请求可能被路由到了 GPT-5.5，或者某个能力明显低于正常 GPT-5.6 Sol High 的运行路径。
我无法把这写成 OpenAI 后台已经确认的事实。
但从工程排障角度：
它已经是目前最能够同时解释所有现象的假设。
十二、这次故障给我的一个重要经验
这次最值得记录的并不是：
“某一天 ChatGPT 不太好用。”
而是：
在长期 AI Agent 工程中，模型能力本身也应该被当成一种运行时依赖。
以前我们更多关注：
代码版本
CLI 版本
依赖版本
网络
服务器
配置文件但 AI Agent 工作流还多了一层：
实际模型执行能力即使 UI 上写着同一个模型名称：
GPT-5.6 Sol High用户真正能够观察到的仍然是：
它是否真的能完成任务。因此以后再遇到类似问题，我不会只做：
能不能调用工具？而会进行一个完整的能力检查：
能否调用工具
→ 能否读取
→ 能否写入
→ 能否执行命令
→ 能否验证结果
→ 能否连续完成 10～20 分钟以上的真实任务最后这一项其实非常重要。
因为：
能够读取一个文件，并不代表 Agent 已经恢复。
十三、总结
2026 年 10 月 1 日，我遇到的异常大致经历了以下过程：
已有 ChatGPT 会话失去 RDC
↓
ru-RU Generation session 无法继续真实工作
↓
Revoke RDC
↓
卸载 ChatGPT 中的插件
↓
重新授权
↓
重新安装插件
↓
RDC 恢复 Online
↓
建立新的 ChatGPT 会话
↓
简单 RDC 读取恢复
↓
真正 Generation 工作仍然出现“只说不做”
↓
暂停当天工作
↓
2026-10-02 重新开始
↓
RDC 与 ChatGPT 全面恢复
↓
单次任务可以连续运行 23m56s当天排查时，我曾考虑过：
- RDC 月度额度周期变化；
- RDC CLI 更新；
- 插件 / 会话重新绑定问题。
这些因素都可能解释 RDC 为什么一度无法连接或为什么旧会话工具状态异常。
但是它们无法很好解释：
为什么 ChatGPT 自身的长期任务执行能力也在同一天明显下降，并在第二天重新恢复。
所以经过第二天的对照，我目前最倾向的解释仍然是：
10 月 1 日发生了 ChatGPT 模型路由或运行时能力异常。
至于是不是确切地路由到了 GPT-5.5，没有后台日志就无法最终证明。
但对于实际使用者而言，最重要的并不是内部 route 名称本身，而是：
界面显示 GPT-5.6 Sol High 时，实际得到的能力是否仍然是正常的 GPT-5.6 Sol High 水平。
这一次，我的答案是：
10 月 1 日明显不是。
而到了 10 月 2 日：
熟悉的正常工作能力又回来了。
这也是为什么我最终决定把这次经历完整记录下来。