昨天能用，今天先查 Desktop 是否仍在运行

如果工具是通过 AIGoCode Desktop 接入的，合上窗口和彻底退出 App 的结果不同。官方说明，工具通过 Desktop 的本机服务连接模型；关闭窗口后 App 会留在菜单栏或托盘，彻底退出则会停止这项服务。

因此，遇到“昨天配置好了，今天原工具却不能用”，第一步是检查 Desktop 的运行状态，随后再检查工具会话和配置。本文给出一次按层定位的重开流程，不假设某个具体报错一定由退出 App 导致。

先把两个程序分开看

这里至少有两个需要分别确认的程序：Desktop 负责连接配置和本机服务，Claude Code、Codex、OpenCode 或 Pi 等原工具负责编码、对话和任务。原工具窗口还开着，不能据此认定 Desktop 的本机服务也还在。

请打开 Desktop 查看对应工具页。如果只是关闭了 Desktop 窗口，可以到菜单栏或托盘核对 App 是否仍在运行；如果之前彻底退出过，重新打开 App 后再继续检查。本文不承诺系统会自动启动 Desktop，也不承诺重新打开后会续上之前中断的请求。

需要了解两者职责，可先阅读 Desktop 使用说明。直接在 App 内绘画是另一条使用流程；本文只讨论通过本机服务连接编码工具的场景。

用三层记录代替一次性改配置

建议每一步只记观察到的状态，按顺序前进。这是一份人工排查表，不是 App 自动生成的诊断报告。

如果第一层尚未确认，不必先删除 Key 或重装原工具。先恢复应当存在的运行条件，再观察问题是否仍出现，才能避免在排查中引入新的变量。

完全退出并重开的是“对应工具”

官方接入流程要求：页面显示“已接入”后，完全退出并重新打开对应工具，再按 Desktop 页面说明选择模型。不要把这一步误读成“把 Desktop 也彻底退出”。进行这次工具重开和消息验证时，Desktop 应保持运行。

例如，Claude Code 可以输入 /model 选择模型；OpenCode、Pi 等工具在模型列表选择对应来源。请以自己使用的工具页为准，重新核对实际选择，而不是只看昨天留下的会话标题。

随后发送一条不含项目秘密的简单消息。收到正常回复，是这次基本调用验证的结果；只显示“已接入”仍属于配置层状态。已有 供应商与模型状态说明 可以帮助辨认页面选择，本文将它放在运行状态确认之后使用。

App 在运行却仍失败，转查哪一层

若运行状态和工具重开都已确认，官方要求继续检查：Key 是否可用，分组是否支持当前工具，模型是否在该分组目录中。分组说明与模型目录是核对依据，不根据模型名称相似就推断可用。

如果原工具继续使用原来的连接方式，应按 Desktop 页面的提示检查旧配置冲突。这里不提供通用“删掉配置目录”的处理，也不把某个工具的配置文件路径套给所有工具。优先保留当前状态和错误，按对应页面处理冲突，避免失去对照。

此时可以把结果写成：“Desktop 已运行；工具显示已接入；重开后选中某模型；简单消息返回某错误。”这比仅写“连不上”更能说明已经排除哪些环节。不要将本机服务状态、认证失败和模型不适用混成同一个原因。

请求没有结果时，先记录，再决定下一次操作

本流程的目标是定位运行与配置条件，不证明某次已中断请求没有执行或没有消费。若你不能确认上一请求结果，先保留时间、错误提示与自己看到的状态，再决定如何核对；不要连续发送相同任务来测试服务是否恢复。

仍需协助时，官方支持通过工单提交工具名称、错误提示和截图。建议再补充操作系统、Desktop 是关闭窗口还是彻底退出、何时重开、重开原工具后的新结果。截图先遮盖 Key 等敏感信息；不需要附完整配置或项目内容。

完成这轮检查后，应能明确区分“Desktop 未运行”“原工具需要重开”“配置条件仍不匹配”与“仍未定位”。没有充分证据时保留未定位，下一步就能沿着具体错误继续核查，而不必重复从换 Key 开始。