AI 状态不稳时，怎样换模型而不重做项目？

修复做到一半，三个文件已经改了，还有一个测试没过。偏偏这时 Agent 用完额度，或者开始重复前面做错的事。直接新开会话又舍不得：过去一小时的调查，全在聊天里。

先把这一小时真正留下的进展保住。下一个 Agent 需要当前文件、已经确认的发现、还有效的约束，以及下一件可以做完的小事。前面的每一轮聊天，未必都要重新经历一遍。

这套做法适合应对最近的模型质量波动，也适合日常额度耗尽、客户端异常或工作环境切换。原问题继续调查，手上的项目也可以接着做。

先决定换模型、换 harness，还是只开新会话

这三件事解决的问题不完全相同。

如果问题是依赖没装好，换模型本身并不会让缺失的依赖自动出现。文件状态已经错了，新会话看到的也还是那些文件。先保存症状，再选最有可能起作用的调整。

产品名称容易让这些选择混在一起，可以先看 harness 与模型的区别。目标入口的访问与计费条件也提前核对：一个服务里的额度，不会自动转移到另一个服务。

交出文件之前，先停下旧的写入者

暂停原任务，确认它启动的子任务或进程是否还在修改同一批文件。关掉标签页，不一定代表所有工作都已经停止。确实要停进程时，先认清哪一个属于当前任务，避免影响其他工作。

然后检查工作目录。除了已提交的代码修订，还要保存未提交的 diff，以及属于本次任务的未跟踪文件。按仓库已有的检查点或备份方式处理。只有一个 commit hash，带不走编辑器里尚未提交的补丁。

别动同目录中无关的工作。如果交接需要干净环境，准备独立副本或 worktree，不要为了“清爽”丢掉已有改动。接收方应该拿到的是你打算继续的准确状态。

把确认过的事实，从旧猜测里分出来

一段长时间排查，通常会留下几个后来没被证实的解释。摘要写得过于顺畅，反而容易把它们变成事实。

对比两段交接说明，下面均为示例：

超时由数据库导致，继续优化查询。

一万行测试文件会触发请求超时。已保存的追踪中，查询本身能够完成，剩余耗时还未定位。曾怀疑数据库瓶颈，目前没有确认。

第二段让接收方知道能核对什么。第一段可能把它引向一个上轮排查都没有证实的方向。

重要发现尽量对应到文件、测试、追踪片段或实际看到的界面状态。失败思路如果能避免下一位重复踩坑，就简短保留；没必要把每一句猜测都继续带下去。

一份可以直接交给下一个 Agent 的模板

把方括号替换成当前任务的事实。确实不适用的部分可以省略。

目标[用户需要的结果，以及验收条件。]
起始状态[代码修订或快照、分支或副本位置。][未提交修改，以及属于本任务的未跟踪文件。][复现当前状态所需的环境信息。]
已完成并验证[已经做了哪些修改，对应文件在哪里。][真正运行过哪些检查，结果是什么。]
尚未解决[当前失败现象与复现步骤。][仍未确认的猜测，明确标注。]
约束与授权[必须保持成立的要求。][已授权的工作，以及需要另行批准的边界。][需要保留的其他工作与文件。]
下一步[一件范围明确、能判断完成与否的事情。]
编辑前先检查实际文件和当前 diff，核对交接中的已完成事项是否仍符合当前状态。如果记录与文件不一致，指出具体差异。再完成已授权的下一步，并验证结果。

不要把密钥写进交接说明，沿用环境既有的凭据配置方式即可。影响复现的依赖版本、测试文件位置要留下，但不需要默认附上一整份环境转储。

接收方最先应该做的是核对状态：找到了预期修改，确认了相关基线，知道剩余问题是什么。只把交接内容复述得很漂亮，却没有看文件，还不算完成这一步。

举个具体例子：继续修复 CSV 导入

假设原 Agent 已经加上流式解析，但取消操作的检查仍然失败。这是一个用于说明交接粒度的虚构项目。

交接可以写成这样：

目标：导入大型 CSV 时页面不冻结。用户取消后，不再继续处理后续行。
状态：从保存的任务检查点和当前 diff 继续。已有修改涉及导入器与进度展示。大文件样本位于本任务的测试数据目录。
已验证：小文件导入检查通过。未解决：大文件导入取消后，仍有更多行被处理。尚不确定原因在解析还是队列处理。
下一步：复现取消失败，找到取消后仍在执行的工作，做范围最小的相关修复。修改后同时检查成功导入和取消流程。
保留既有 CSV 格式和无关 UI 改动。本次授权本地修改与验证，发布需要另行批准。

新 Agent 可以检查真实 diff，运行失败场景，不用重新问一遍为什么产品需要导入大文件，也不会把上一个 Agent 偏爱的原因当成结论。

修好以后，同时验证取消和正常导入。接收方交出经过检查的结果，交接才真正发挥了作用；仅仅回复“我理解了上下文”，还没有把工作接起来。

在 Agent.Space 中怎样接着做

Agent.Space 的 Workspace可以让普通项目文件在多个 Session 之间保留下来。你可以新开使用 Codex、Claude Code 等受支持 harness 的 Session，并从该 harness 兼容的模型中选择。项目文件加上明确的交接说明，构成继续工作的基础。

这些 Session 共享文件。每个 Session 不会自动获得私有分支，同时发生的修改也不会自动合并。顺序交接时，先停旧的写入者；想并行对照，就在开始前准备独立副本或分支。

如果已经有本地 Codex 或 Claude Code 会话，历史导入可以把选中的历史保留在原 harness 中。项目文件需要另外准备：导入聊天不等于上传仓库，也不会把 Codex 会话转换成 Claude Code 会话。要换 harness，在准备好的文件上新建对应 Session，再提供交接说明。

这一步看似细小，却能避免一种常见的假成功：聊天记录到了，新 Agent 却找不到它应该继续修改的代码。

长任务做到一个阶段，就留一个能恢复的起点

每完成一个有意义的阶段，保存工作状态，更新几行任务记录：改了什么、什么通过了、还差什么、下一步是什么。用团队已经记录任务的地方即可，不必再建立一套永久文档体系。

下次会话不稳定时，你手里就有可恢复的项目状态，不需要临时从长聊天里拼凑。仍然可以用模型路由记录或回归题目调查原问题，同时由另一个 Agent 继续已授权的工作。

可以从一个很小的任务试起：打开 Agent.Space，在 Workspace 中准备项目，把一段边界明确、验收条件清楚的工作交给下一个 Session。先让它从实际文件出发，完成下一件有用的事。

流程与示例由 Agent.Space 编写。产品行为于 2026 年 9 月 15 日依据当前实现与已有产品指南核对；模型与访问能力以实际可用配置为准。