界面持续等待 → 先核对任务事件和进程，再决定继续等；没有新的重试开始证据或等待边界不可控 → 保存现场并停止，不要反复刷新页面。
这套方法适合本地用户、远程 Agent 运维人员和平台工程师：你可以判断等待到底发生在 LLM retry、网络连接、模型配置，还是工具与审批环节。
先用一个失败现场确认：页面运行，不等于任务在运行
一个常见现场是：DeepSeek Harness 页面一直显示“运行中”，没有明显报错，也看不到新的结果。用户等了很久后刷新页面，页面仍然显示等待，于是继续等。
这一步最容易误判。加载动画只能证明界面还在展示某种状态，不能证明模型请求已经发出，更不能证明后台任务仍在推进。你需要把观察对象从页面切换到证据链：
- 任务状态是否发生过变化；
- 会话事件是否持续产生；
- 是否出现新的模型请求或工具调用；
- 运行进程是否仍存在；
- 工作目录中的输出、检查点或日志时间是否变化。
DeepSeek API 在等待调度时可能持续返回空行，流式请求也可能收到 SSE 保活注释，因此“连接没有立即断开”不等于模型已经返回内容。官方文档还说明，如果请求在 10 分钟内没有开始推理，服务器可能关闭连接。(api-docs.deepseek.com)
⚠️ 注意： 不要把浏览器刷新当成恢复手段。刷新最多改变你看到的界面，不会修复凭据、网络出口、工具进程或工作目录问题。
如果任务事件停在“等待工具结果”或“等待审批”，就不要继续沿着模型重试路径排查。此时真正的阻塞点可能在 Bash、Hook、人工确认或外部工具。
第一步：等待界面没有新证据时，先查三组状态
观察信号
你看到的现象通常包括：
- 页面状态长时间不变；
- 没有新的请求开始记录；
- 没有新的 assistant、tool 或结果事件；
- CPU、网络和工作目录都没有明显变化；
- 终端仍保持连接，但任务没有输出。
其中，最有价值的不是“页面还亮着”，而是最后一条可确认事件。例如，最后一条记录是“模型响应完成”，后面没有工具完成事件，那么问题更可能在工具执行，而不是 LLM retry。
核验动作
按以下顺序检查：
- 导出或复制当前任务的会话标识；
- 查看持久化事件中最后一条记录的类型和时间；
- 对照是否有新的请求创建、请求结束或重试开始证据；
- 检查任务进程是否仍存在；
- 查看工作目录中日志、临时文件和检查点是否有更新；
- 确认当前远程连接只是断开，还是主机已经重启或身份改变。
停止条件
满足任意一项，就不要无限等待：
- 只有“重试已安排”，没有对应的“重试开始”；
- 连续观察期间没有新的会话事件；
- 等待时间已经无法由当前任务的超时策略解释；
- 进程消失，或者工作目录已经不可访问；
- 同一确定性错误反复出现。
恢复标准
只有同时满足以下条件，才适合继续观察：
- 任务状态仍可读取；
- 进程仍存在；
- 会话事件继续推进；
- 工作目录和环境身份未变化；
- 下一次请求或工具调用有明确开始证据。
第二步：重试已安排但请求没有开始，保存现场再判断
“重试已安排”只表示调度器记录了下一步意图，不表示下一次 HTTP 请求已经发出。你至少要寻找一组成对证据：
| 需要核对的证据 | 能说明什么 | 缺失时的风险 |
|---|---|---|
| 重试安排记录 | 系统决定进入重试流程 | 可能只是写入计划，尚未执行 |
| 重试开始记录 | 新请求实际进入执行阶段 | 没有它就不能证明正在重试 |
| 请求结束记录 | 请求得到响应或明确失败 | 网络中断时可能只有开始没有结束 |
| 进程状态 | 本地或远程工作进程仍在运行 | 连接断开不代表进程一定停止 |
| 工作目录变化 | 任务可能仍在写入结果 | 无变化也不能单独证明任务已死 |
远程连接断开有两种完全不同的含义：网络会话断了，但远程进程仍在；或者主机休眠、重启、容器退出，任务已经不存在。仅凭 SSH、终端或网页连接断开，不能证明任务仍在运行，也不能证明任务已经停止。
在停止前，至少保存以下现场：
- 当前版本和启动参数；
- 会话标识、任务标识和工作目录；
- 最近一条事件及其时间；
- 已出现的错误状态和错误文本；
- 当前模型、Provider、Base URL 配置摘要；
- 进程列表、主机重启记录和网络出口信息。
如果现场可读但没有推进证据，优先选择“取消并保存现场”。不要先删除会话、清空目录或重新安装 Harness，否则你可能丢失判断重试链路的关键证据。
第三步：同类错误反复出现，停止增加重试次数
观察信号
每次请求都返回同类模型错误，通常表现为：
- 错误状态码和错误文本高度一致；
- 请求一开始就失败；
- 没有成功的最小请求作为对照；
- 重试间隔变化，但错误内容没有变化；
- 修改提示词后仍然立即失败。
这类故障更像模型链路配置问题，而不是需要更多等待时间。官方错误说明中，400 对应请求格式问题，401 对应 API Key 认证失败，402 对应余额不足，422 对应参数无效，429 对应请求过快，500 和 503 分别对应服务器错误与过载。(api-docs.deepseek.com)
核验动作
依次核对：
- 当前模型名称是否仍在官方模型目录中；
- API Key 是否来自当前账户，是否被截断、过期或读错环境变量；
- Base URL 是否与当前 Provider 配置匹配；
- 请求是否带入了当前模型支持的参数；
- 是否误把旧模型名、旧路径或旧参数继续写入配置；
- 是否因为 thinking 模式的上下文字段缺失而触发确定性错误。
DeepSeek 官方文档指出，在带工具调用的 thinking 模式中，后续请求需要正确传回 reasoning_content；缺失时可能返回 400。这类错误不是靠增加 LLM retry 次数解决的。(api-docs.deepseek.com)
停止条件
出现以下情况时，应立即停止自动重试：
- 连续得到相同的确定性状态码；
- API Key、Base URL 或模型名尚未核对；
- 当前配置使用了未经确认的 Provider；
- 请求体结构与官方接口文档不一致；
- 错误证据不完整，无法判断是请求失败还是解析失败。
恢复标准
修复后不要直接恢复原来的长任务。先发起一个最小文本请求，只验证：
- 凭据能否通过；
- Base URL 是否可达；
- 模型是否接受当前请求；
- Harness 是否能记录完整的开始、响应和结束事件。
DeepSeek 的 Chat Completions 文档列出了模型、消息、工具调用、流式响应和结束原因等字段。最小请求应尽量删除工具、长上下文和复杂输出格式，只保留必要消息。(api-docs.deepseek.com)
第四步：模型已经成功，卡住点转到工具执行
模型响应成功后，Agent 任务仍然可能没有完成。因为模型只负责返回文本或工具调用，实际函数、Shell 命令和外部服务仍由你的 Harness 执行。官方工具调用流程也是“模型返回工具调用 → 客户端执行工具 → 把工具结果送回模型”，模型本身不会替你执行函数。(api-docs.deepseek.com)
观察信号
重点看最后一条事件：
- 有 assistant 响应，且包含 tool call；
- 没有对应的 tool started 或 tool finished；
- 有工具开始事件，但没有工具结束事件；
- 工具输出为空，进程却持续存在；
- 任务停在审批、Hook 或 Bash 阶段。
核验动作
从最小权限开始检查：
- 确认工具进程是否存在；
- 单独执行同一个工具的最小参数；
- 检查 Bash 是否等待标准输入；
- 检查审批队列是否有未处理项目；
- 检查 Hook 是否等待文件、端口或外部服务；
- 检查工具返回值是否被 Harness 正确写入会话；
- 检查工作目录是否仍是任务启动时的目录。
不要为了试错直接放开全部权限。这样可能掩盖路径错误、命令阻塞和审批缺失，还会扩大远程任务的安全边界。
停止条件与恢复标准
工具没有开始事件时，先查路由和审批；工具有开始但没有结束时，先停止该工具进程；工具完成但模型没有继续请求时，查工具结果序列化和会话写入。
恢复标准不是“页面重新显示运行中”，而是最小工具调用能完成、返回结果，并生成下一条可核验的会话事件。
第五步：远程进程和网络波动，分开处理瞬时故障
网络波动通常不会留下与配置错误相同的证据。你需要区分：
✅ 可恢复的瞬时问题： 请求曾成功开始，偶发连接重置，远程进程仍在，工作目录持续更新。
❌ 持续复现的环境问题： 每次请求都在同一出口失败，主机反复重启，休眠后进程消失，路径或权限发生变化。
检查项目包括：
- 运行进程和父子进程关系；
- 网络出口、DNS 和 TLS 连接；
- 系统是否休眠、重启或被回收；
- 工作目录、挂载盘和临时目录；
- API Key 是否只存在于交互式 Shell；
- 远程会话断开后，后台任务是否仍由独立进程托管。
如果环境身份已经变化，例如主机重建、工作目录迁移、密钥重新注入或进程树消失，就不要强行续跑旧任务。先创建一个新验证任务，确认模型、工具和目录都能工作，再决定是否从检查点恢复。
你也可以先参考 MACCOME 的云端 Mac 算力方案 了解远程环境交付边界；如果任务依赖固定工作目录和持续运行进程，环境验收应先于模型重试参数调整。
FAQ：把最容易误判的 4 个问题一次分清
DeepSeek Harness 一直等待，是不是正在重试？
不一定。你必须同时看到重试安排和重试开始的证据，才能确认进入 LLM retry。只有页面状态、空行或连接保活，都不足以证明请求正在重试。若最后事件停在工具或审批阶段，应改查工具管线。
自动重试的次数应该到哪里查？
不要使用没有版本依据的固定次数。当前公开边界不足以支持统一数字，具体行为可能受错误类型、Provider 和版本影响。运维上应记录每次安排、开始和结束事件，并为不可控等待设置人工停止边界。
反复重试时，应该继续等还是取消？
有新事件、进程仍在、环境未变且错误可能是瞬时上游问题时，可以继续观察。没有新的重试开始证据，或同一配置错误重复出现时，应取消并保存现场。反复刷新 Web UI 不会改变这个判断。
远程任务重试后，如何恢复现场？
先核验进程、工作目录、会话持久化和环境身份。身份未变时，从最后一个完整检查点恢复；身份已变时，创建新验证任务，不要直接续跑旧任务。恢复必须以最小模型请求和最小工具调用成功为准。
用这张清单决定：继续等待、取消重跑，还是迁移环境
- [ ] 已保存版本、会话标识、任务标识和工作目录。
- [ ] 已确认最后一条事件，而不是只查看页面加载状态。
- [ ] 已找到“重试安排”和“重试开始”的成对证据。
- [ ] 已确认远程进程仍存在，且工作目录仍在更新。
- [ ] 已核对模型路由、API Key、Base URL 和 Provider。
- [ ] 已保存官方返回的状态码与错误文本。
- [ ] 已用最小文本请求验证 DeepSeek API 链路。
- [ ] 已将工具、审批、Hook 和 Bash 与模型请求分开检查。
- [ ] 已完成最小工具调用，并拿到可读返回值。
- [ ] 已确认远程主机没有重启、休眠或身份变化。
- [ ] 若环境身份改变，已创建新的验证任务。
- [ ] 已定义取消、重跑和迁移的责任人与时间边界。
结尾前的方案对比：不要把环境故障伪装成模型故障
| 当前处理方式 | 适合情况 | 真实缺点 | 更稳妥的做法 |
|---|---|---|---|
| 本地 Mac 长时间运行 | 任务短、需要本地文件和物理接口 | 睡眠、断网、终端关闭会影响后台任务 | 使用独立进程并保存检查点 |
| 临时远程主机 | 短期验证和一次性测试 | 重启后身份、目录、密钥可能变化 | 先做环境验收，再提交长任务 |
| 只增加重试次数 | 明确的瞬时上游故障 | 会放大成本，掩盖确定性配置错误 | 先区分 429、5xx、凭据和参数问题 |
| 刷新 Web UI | 只想重新查看状态 | 不会恢复进程、工具或网络 | 读取持久化事件和进程状态 |
对于只在断线、休眠或长时间无人值守时复现的问题，当前本地方案往往有 3 类真实短板：后台进程容易随会话退出、网络与睡眠状态不可控、故障现场不一定能保留。临时远程主机则可能出现身份变化、工作目录丢失和凭据未注入。此时，把问题简单归因于 DeepSeek Harness 的重试逻辑，通常会让排障方向越走越偏。
如果你的任务需要临时算力、远程验证或连续运行的后台任务，可以对照 MACCOME 的 Mac mini 云算力租赁方案评估固定环境、远程连接和恢复条件。它不一定适合长期稳定重负载或必须直接接入物理设备的场景，但比在不稳定的本地会话中无限等待，更适合做可控的 DeepSeek Harness 验证与迁移。
最终分流：按证据落到一个动作
| 证据组合 | 结论 | 下一步 |
|---|---|---|
| 有新事件、有进程、环境未变 | 任务仍可能推进 | 继续观察，并记录下一条事件 |
| 只有重试安排，没有重试开始 | 调度或进程可能中断 | 保存现场，达到边界后取消 |
| 同一 400、401、402、422 类错误重复出现 | 更像确定性配置问题 | 停止重试，修复配置后做最小请求 |
| 出现 429、500、503 或连接波动 | 可能是上游或网络问题 | 核对状态、出口和并发，再有限度重跑 |
| 模型成功但工具无结束事件 | 工具管线阻塞 | 停工具、查审批与 Hook，不要改模型重试 |
| 远程环境身份已改变 | 旧任务恢复条件不成立 | 创建新验证任务，再从可验证检查点迁移 |
排障的终点不是让页面重新出现“运行中”，而是拿到一条完整证据链：请求是否开始、模型是否响应、工具是否执行、结果是否写回、远程环境是否保持一致。只要其中一环没有证据，就不要用“再等一会儿”代替判断。