值班记录：编码代理断线后，先核对现场再恢复会话

断线提示出现，先别把任务重发一遍

编码代理正在改文件，终端突然显示连接失败。此时最重要的不是立刻点击重试，而是确认它停在哪里。连接断开，只说明通信出了问题，不代表任务没有执行。请求可能尚未送达，也可能已经处理，只是结果没能传回。

可以把现场分成三部分：电脑上的代码文件、工具保存的对话记录，以及服务端正在处理的请求。三者不一定同步。屏幕上没看到完成消息，不等于磁盘上没有新代码。

先查本地进程，再查已经落盘的修改

如果只是网络中断，先保留原来的终端窗口，观察工具是否还在运行。若是远程开发连接断开，可以重新连接机器，检查原进程是否仍然存在。不要同时启动多个代理处理同一个目录。

• 记录最后一条可见消息、错误提示和大致时间，方便判断中断发生在生成回答还是执行工具期间。
• 用 git status 查看哪些文件发生变化，再用 git diff 检查具体内容，不要直接撤销所有修改。
• 检查测试输出和后台进程，确认测试、安装依赖或构建任务是否仍在运行。

代理可能只写完一部分文件。文件存在，不代表功能已经完成；测试没有返回结果，也不能当作测试通过。发现有价值的修改后，可以先保存差异或建立本地检查点，但不要顺手提交密钥或临时文件。

有历史会话，就从已确认的断点接续

查看当前工具的帮助或会话列表，确认它是否支持继续历史会话。Claude Code、Codex、Gemini CLI 的具体操作可能随版本变化，不要照搬另一种工具的恢复命令。

能恢复历史记录时，先让代理说明它认为已经完成了什么，再与本地文件核对。可以这样交代：“刚才网络中断，请先检查当前差异和测试状态，列出已完成与未完成的步骤，未经确认不要重复执行外部操作。”

恢复会话不等于恢复执行位置。工具可能保留了对话，却没有收到最后一次命令的结果，仍然需要检查现场。

找不到旧会话，就写一份短交接

新会话不会自动知道旧会话发生过什么。交接时说明任务目标、工作目录、已修改文件、最后执行的命令，以及尚未确认的结果。相关错误可以摘录，但应先删除密钥、令牌和敏感数据。

让新代理先阅读现有修改，再给出下一步计划。不要仅说“继续刚才的任务”，也不要把整段终端记录不加筛选地复制过去。

重试前，把有副作用的步骤单独核实

读取文件通常容易重做，但部署、数据库迁移、提交代码和调用付费接口可能产生额外影响。遇到这些步骤，应先查目标系统的实际状态，再决定是否重试。超时并不是失败证明，也不是可以安全重复执行的许可。

恢复后先运行与修改相关的小范围测试，再按需要扩大检查范围。若持续断线，应分别检查本地网络、代理设置、服务状态和错误信息，避免一边改代码一边频繁切换连接配置。

接入可以统一，恢复现场仍靠交接

如果你需要让多个工具使用统一的模型接入入口，Relay365 这类按量付费的中转服务值得考虑。它可配合 Claude Code、Codex、Gemini CLI 和 OpenAI SDK 使用；接口基础地址为 https://api.api365relay.com，OpenAI 客户端需加上 /v1，具体仍应核对工具配置。

中转服务不能替代本地会话记录，也不能保证断线后自动续跑。确有统一接入需求时，可以创建一个 Relay365 账户，先用小任务验证连接和恢复流程。

本次交接的收尾标准很明确：保留有效修改，确认关键操作是否执行，验证剩余任务，并记录恢复位置。网络恢复只是重新接通，现场核对完成，才算真正接班。