长会话被 max-tokens 截断后，不能直接把“页面还能输入”当成会话已经损坏，也不能把升级 v0.1.0-rc.7 当成所有旧状态都会自动迁移。本文按失败症状拆分诊断路径，给出日志保全、隔离验证、工作区核对和恢复或重建的判定标准。
长会话被 max-tokens 截断后，不能直接把“页面还能输入”当成会话已经损坏，也不能把升级 v0.1.0-rc.7 当成所有旧状态都会自动迁移。本文按失败症状拆分诊断路径，给出日志保全、隔离验证、工作区核对和恢复或重建的判定标准。
官方接口把 finish_reason = length 定义为输出达到 max_tokens，或输入与输出合计超过上下文长度；这两个原因在界面上都可能表现为“回答突然停了”。(api-docs.deepseek.com)
症状：回答不完整、继续发送后无响应，或者旧会话能打开却无法再次执行。
最快解法：先区分单次输出截断、会话状态损坏和上游模型错误；复制工作区与原始日志，在隔离环境验证 v0.1.0-rc.7，无法重建最后一个完整步骤时，停止旧会话并新建任务。
最后更新于 2026 年 8 月 19 日，版本状态核实自官方 v0.1.0-rc.7 发布说明、官方会话持久化实现文档与官方 API 返回字段说明。
这篇内容适合三类人：长会话突然停止且继续发送无响应的 DeepSeek Harness 用户；准备升级 v0.1.0-rc.7、需要在远程环境维护实例的人员；以及必须决定“恢复旧会话还是重建 Agent 任务”的开发者和运维人员。
如果页面仍能显示输入框、模型选择没有丢失、会话标题和历史列表也能正常打开，第一步不要立刻重建。先观察最后一轮是否有完整的回合结束记录，或者是否明确出现 finish_reason、请求失败或工具调用未闭合等信号。
官方 API 文档说明，finish_reason = length 只能说明生成因长度限制停止，并不能单独证明会话文件已经损坏；输入历史过长也可能触发同一类结果。(api-docs.deepseek.com)
此时可以发送一个无副作用的短请求，例如要求 Harness 只返回“已收到”，不要读文件、不要执行 Shell、不要调用外部工具。若短请求能正常开始下一轮，说明展示层截断与会话执行能力暂时分离，应该保留当前会话，再把未完成任务拆成更小的续接指令。
停止条件：短请求也没有产生新的事件，或者请求返回后历史中出现半截工具调用、缺失 assistant 回合或无法闭合的事件链。此时不要继续点击发送。
如果每次继续都在同一段历史、同一个模型或同一个工具结果附近失败，问题就不再像普通输出长度不足。我们会先记录失败发生的位置，再检查该位置前后的持久化记录是否一致。
重点查看以下观察信号：
不要连续重试。长会话每重放一次历史，都可能再次触发同样的 Provider 限制、历史解析错误或状态重建失败，同时增加调用消耗。先把日志目录、运行参数、版本信息和工作区状态复制到单独位置，再进行下一步。
两者可能共享 finish_reason = length，但处理方式不同。max_tokens 控制单次请求最多生成多少输出；上下文长度则受输入历史、系统提示、工具定义、工具结果与本轮输出的总量影响。官方文档明确指出，输入 token 与生成 token 的总长度受模型上下文长度限制。(api-docs.deepseek.com)
| 观察结果 | 更可能的原因 | 首选动作 | 恢复评分 |
|---|---|---|---|
| 回答末尾突然停止，短请求仍能执行 | 单次 max_tokens 截断 |
保存当前回合，拆分任务后继续 | 4 / 5 |
| 同一历史位置反复失败，换新会话正常 | 历史回放或状态兼容问题 | 复制会话副本，隔离测试 rc.7 | 2 / 5 |
| 新旧会话都失败，接口返回明确错误 | 上游模型、参数或 Provider 问题 | 保存请求与响应，做最小复现 | 2 / 5 |
| 页面可打开，但旧会话无法进入执行 | 持久状态或事件链损坏 | 不删除原目录，使用副本加载 | 1 / 5 |
| 会话能继续，但文件、进程、审批状态对不上 | 叙述恢复，任务状态未恢复 | 停止旧任务，重建并人工注入摘要 | 1 / 5 |
这个表的评分不是官方恢复率，而是我们用于排障决策的风险等级：分数越低，越不适合在原会话中继续写文件或运行命令。DeepSeek API 的多轮接口本身是无状态的，客户端需要重新提交历史，因此 Harness 是否能正确保存并重放事件，直接影响旧会话能否继续。(api-docs.deepseek.com)
先创建一个新会话，用同一运行环境、同一模型和一个无副作用请求测试。如果新会话正常，而旧会话失败，排查范围应优先收窄到持久状态、历史兼容或事件重建，不要先归因于网络。
会话数据应按“原件、复制件、测试件”分开：
检查 SessionEvent 时，不要只看 UI 上已经渲染出来的文字。需要对照最后一次用户输入、assistant 输出、工具调用、工具结果、审批决定和回合结束信号，确认事件顺序没有断裂。若某一段只有工具调用而没有对应结果，或者有结果却没有完整回合收束，就不能把它当成可安全恢复的最后一步。
⚠️ 经验提醒：旧会话无法继续时，不要删除日志目录。日志是判断历史重放、状态损坏和上游错误的唯一证据之一；即使最终决定重建任务，也应保留原始副本和升级前后的复现记录。
不应该先删除。正确做法是先复制、校验副本可读性，再在副本上尝试加载和升级；只有确认原始日志已经完成归档、并且不会再用于提交问题或回滚时，才考虑清理临时副本。
如果旧会话目录占用空间较大，可以压缩归档或移动到独立存储，但不要用“清空目录后重新启动”代替诊断。删除会让我们无法比较升级前后的最后事件，也无法判断 rc.7 是修复了加载逻辑，还是只是绕开了某条未被再次触发的历史路径。
官方发布说明确认，v0.1.0-rc.7 已发布针对“max-tokens 截断导致会话无法继续”的修复路径；这代表修复代码进入该版本，并不等于所有既有损坏状态都获得自动迁移保证。具体恢复结果仍要结合原版本、日志位置、事件内容与工作区状态判断。
建议按以下 5 步进行隔离验证：
停止条件：副本仍在同一 SessionEvent 附近失败、加载后历史顺序改变、模型复述的最后一步与日志不一致，或测试请求触发了真实工作区修改。满足任一条件，就不能把“页面打开了”判定为恢复成功。
不能直接回答“能”或“不能”。rc.7 可以作为首选验证版本，但发布说明没有承诺所有历史损坏会话都能自动修复。对于只因截断后续写入不完整、但此前事件链仍完整的会话，恢复可能性通常高于已经出现事件缺失、工具结果错位或工作区状态漂移的会话；这属于排障推断，不是官方恢复率承诺。
如果升级后旧会话可以读取，但下一轮仍失败，应记录：
随后再决定向官方提交问题，还是暂时回退到原运行环境。不要用反复重试来“证明它最终会恢复”。
下面的清单用于结束排障，而不是替代日志分析。重要任务必须在隔离副本中完成验证。
SessionEvent。若前 4 项全部通过，可以在复制工作区中恢复旧会话，再逐步开放工具权限。若任一关键项无法通过，尤其是工作区状态与会话叙述不一致，就应保留原日志、新建会话，并注入人工核验过的任务摘要、已完成步骤、未完成步骤和当前仓库状态。
重建提示不要写成“请继续之前的工作”这种模糊指令，建议明确列出：
这样做会牺牲一部分上下文连续性，但比让模型依据一段可能损坏的历史继续修改代码更可控。
长会话恢复不只是 Harness 版本问题，还涉及运行环境是否能稳定保留进程、日志和工作区。临时 SSH 断开、终端关闭、远程目录未挂载或权限变化，都可能制造“会话无法继续”的假象。若需要长期维护远程 Mac，可以先参考 VNCMac 的远程 Mac 使用入口，把会话目录、工作区和归档日志放在可独立备份的位置。
我们建议把以下内容分开管理：
如果当前方案是在个人电脑上直接运行，常见缺点是睡眠或重启会打断长任务、日志与工作区容易混在同一目录、升级验证无法与生产任务隔离。与其在故障发生后临时抢救，不如为重要 Agent 任务准备一台可远程访问、可复制工作区的 Mac 环境；需要临时算力或测试节点时，可以查看 VNCMac 的 Mac 方案页面，再根据任务时长和隔离要求选择。长期稳定重负载、必须连接特定物理设备，或需要完全掌控硬件的场景，则更适合自购设备，而不是租赁。
真正稳妥的顺序不是“升级后继续点发送”，而是先保存会话与工作区证据，再在副本中验证 v0.1.0-rc.7；如果最后一个完整步骤无法重建，就停止旧任务并新建会话。只有历史、下一轮执行、工作区状态和任务证据同时一致，恢复才算完成。