浏览器一关，页面里的任务卡片消失；远程连接断开后，代码却还在修改工作区——这两种现象都不能直接证明任务是否安全运行。
本周建议动作：先用同一个基准任务完成隔离、状态、取消、通知、断线和重启测试，再决定上线。后台任务能启动不等于可以跨进程或跨重启续跑；关键任务应放进独立、持续可访问的运行环境，并避免与交互试验混跑。
这篇文章适合三类人：准备把耗时构建、测试、代码分析或批处理交给 DeepSeek Harness 的开发者；负责持续 AI Agent 环境交付和值守的运维人员；需要判断是否扩容、拆分任务环境的项目负责人。
⚠️ 最后更新于 2026 年 8 月 18 日，数据核实自 DeepSeek Harness 官方仓库、任务子系统文档、持久化说明及可控长任务验收方法。该项目仍处于开发预览阶段，官方明确提示可能出现兼容性破坏变更。 官方仓库 README
SECTION 01 先把“后台运行”拆成 3 个不同问题
验收时最容易犯的错误，是把所有现象都归类为“任务还在后台跑”。实际上，你至少要区分：
- 界面连接是否存在：浏览器、Web UI 或远程桌面还能不能看到任务。
- Harness 进程是否存在：负责调度任务的主进程是否仍在运行。
- 任务子进程是否存在：编译器、测试器、分析脚本和其他工具是否真的继续执行。
浏览器关闭主要影响第一层，远程连接中断可能影响观察路径，但不一定等同于任务终止。Harness 进程退出、系统重启则属于更深层的故障，不能用“我重新打开页面还能看到记录”来替代恢复测试。
官方文档说明，DeepSeek Harness 的 Web UI 使用启动进程的目录作为默认文件系统位置，首次使用时还需要选择工作区；这意味着工作区、运行进程和持久化日志必须被同时纳入验收，而不是只检查一个任务编号。可参考 官方 Web UI 指南。
SECTION 02 所有权隔离：任务编号不是权限模型
后台任务一旦交给多个 Agent 或多个操作者，最先要验收的不是速度，而是“谁可以看到什么、等待什么、取消什么”。仅仅因为任务 ID 不同，并不能证明任务已经实现所有权隔离；如果任意会话都能读取、等待或取消其他会话的任务，长时间运行时就会出现误取消、串写工作区和错误交付。
两个受控会话的验收动作
准备会话 A 和会话 B，各自使用不同工作区、不同输入标记和不同产物目录，然后按以下顺序记录结果：
- A 创建任务后，B 是否能列出或读取 A 的任务详情；
- B 是否能等待 A 的任务完成；
- B 是否能取消 A 的任务；
- A 是否能读取 B 的日志、输入和产物；
- 两个任务同时运行时，是否出现工作区锁冲突或文件覆盖；
- 任务完成后，状态记录是否仍然关联到原始执行者和工作区。
每一次操作都要保存截图、命令输出、任务标识、会话标识和时间点。若 B 的交叉访问被拒绝，要记录拒绝结果，而不是只记录“没有看到任务”。若权限边界依赖前端隐藏按钮，也不能判定为通过，必须在实际操作层面验证。
官方架构文档将会话、日志、工具注册和 Agent 循环都视为可组合的插件层；这对扩展很灵活，但也意味着权限、工作区和任务生命周期不能凭经验推断，应结合当前版本契约复核。官方架构说明
SECTION 03 状态可观察性：没有完成证据就不能签收
一个后台任务至少要能回答 5 个问题：它由谁创建、使用哪个工作区、输入是什么、当前执行到哪里、最终产物在哪里。如果状态页或命令输出只能给出一个模糊的“运行中”，却无法关联到具体输入和产物，运维人员即使看到了状态，也无法定位故障。
建议为每个基准任务准备一份验收记录：
- 任务创建时：保存任务标识、会话、工作区和输入摘要；
- 运行中：保存至少两次状态快照，并记录日志是否持续增长；
- 失败时：保存错误信息、失败阶段和最后一个有效产物；
- 完成时：保存退出结果、产物清单、文件校验值或可复核的目录快照；
- 重新连接后：确认状态、日志和产物仍能关联到同一任务。
这里的重点不是状态名称，而是证据链。官方持久化目录说明会话事件包含递增序号、时间和可序列化数据，并强调当前格式处于预发布状态、没有兼容性承诺；因此你不能把某次版本中的日志结构直接当作长期稳定接口。官方持久化事件目录
如果状态无法关联到工作区、任务输入和产物，结论应直接写成“不可交付”，而不是“基本通过”。
SECTION 04 取消、超时与残留进程：把止损分成 3 轮测试
取消功能的验收不能只点击一次按钮。至少要覆盖正常取消、任务无响应和子进程残留三种情况。
第一轮：正常取消。
启动一个可观察的长任务，在日志持续写入时发起取消，随后检查任务状态、Harness 进程、子进程、文件锁和产物目录。通过条件是：任务不再继续修改工作区，相关子进程退出，日志留下取消结果，且重新连接后不会被错误标记为成功。
第二轮：任务无响应。
让任务进入等待外部输入、网络响应或长时间无输出的状态，再执行取消。记录取消请求是否被接收、状态是否变化、日志是否继续写入，以及是否需要人工终止进程。不要自行填写“超时多少秒”之类的固定数值，时间数据必须来自当前官方说明或明确标注测试环境与日期。
第三轮：子进程残留。
任务界面显示取消后，检查进程树、端口、临时文件、工作区锁和后台写入。若主任务已经变成取消状态，但测试进程、构建进程或脚本仍然存在，这只能判定为“界面取消成功，资源止损失败”。
官方测试文档和任务子系统文档应作为当前版本的契约入口；验收表中要区分“取消请求已发出”和“实际执行已终止”这两个结果。官方测试文档 · 官方任务子系统文档
SECTION 05 完成通知：通知到达不等于产物已经交付
无人值守场景中，完成通知必须和产物完整性绑定。你要分别测试完成、失败和取消三种结果，并记录 Agent、操作人员以及外部监控各自收到什么信号。
验收时可以使用一个会生成多个文件的代表性任务：让任务先写入中间产物，再写入最终清单，最后发送完成信号。检查通知到达时：
- 最终文件是否已经落盘；
- 文件大小是否稳定；
- 工作区锁是否释放；
- 日志是否包含最终退出信息；
- 任务状态是否与产物结果一致；
- 失败或取消时，是否错误地发送“完成”。
如果通知先到、文件后到，或者通知显示成功但产物目录不完整，就不能把该通知接入自动交付流程。通知缺失时，要保留一条人工巡检路径：按任务标识进入状态记录，检查最后日志、工作区变更和产物清单，再由责任人签收。
对于 background jobs，真正有价值的不是“有人收到提醒”，而是提醒能够让人无需重新猜测任务究竟执行到了哪一步。
SECTION 06 FAQ：断线、关闭浏览器与远程 Mac 重启
DeepSeek Harness 关闭浏览器后，后台任务还能继续吗？
不能只凭浏览器界面判断。关闭浏览器只验证前端连接是否断开，任务本身是否继续取决于 Harness 进程、任务持久化和运行环境是否仍然存活。你应在关闭浏览器前记录任务标识、工作区和输入，再通过另一条管理路径核对日志、状态和产物，不能把页面消失当成任务仍在运行的证据。
后台任务卡住后，怎样取消才不会留下残留进程？
先记录取消前的状态、工作区和子进程，再执行正常取消；如果状态不变化，继续核对进程树、文件锁、日志写入和产物目录。只有确认相关进程退出、锁释放且任务不再修改文件，才算取消成功。只改变页面状态、没有终止子进程的操作，不能作为安全止损方案。
多个 AI Agent 同时跑后台任务，会不会互相影响？
会，尤其是在共享工作区、凭据目录、缓存、端口、文件锁或有限 CPU 与内存时。任务 ID 不等于权限隔离。至少用两个受控会话验证互相查看、等待、取消和读取产物的边界，并为不同 Agent 分配独立工作区；无法证明边界时，应拆分运行环境。
远程 Mac 重启后，未完成任务可以自动继续吗？
不能预设一定可以。后台任务、会话日志和操作系统进程属于不同层次，持久化记录存在不代表运行中的子进程会在重启后恢复。你需要单独测试重启前后的任务状态、日志连续性、工作区变更和产物完整性，再决定采用自动恢复、人工重跑还是禁止无人值守。
SECTION 07 断线和异常恢复：每种故障都要单独记录
你至少要按以下顺序完成 4 组恢复测试：
- 关闭浏览器：重新打开管理界面，核对任务是否仍有状态、日志和产物。
- 断开远程连接：不要结束远程 Mac 上的 Harness 进程，稍后通过新的连接检查任务是否继续。
- 退出 Harness 进程：记录退出前状态，再重新启动，检查任务是恢复、失败、停留在未知状态，还是只能人工重跑。
- 重启操作系统：记录未完成任务、持久化日志、工作区文件和锁的变化，确认启动后是否存在重复执行或半成品覆盖。
这 4 组测试必须使用相同基准任务，并在每次测试前清理工作区、记录软件版本和保留日志。尤其要避免把“浏览器关了还能看到历史记录”解释为“系统重启后可以续跑”；官方持久化说明描述的是事件记录和会话重建边界，不等于操作系统级进程恢复。
如果远程 Mac 只是临时交互设备，断线后无法找到任务、日志或产物，那么它不适合承载无人值守长任务。若你需要持续运行，应先参考 VPSNIX 的远程环境入口，把可访问性、重连方式、工作区保留和人工接管路径一并写入运维方案。
SECTION 08 用对比表形成上线结论
不要预设某个 CPU、内存或并发数字就是合格线。不同构建、测试和代码分析任务的资源曲线差异很大，验收应关注趋势、冲突和交付结果。
| 方案 | 隔离边界 | 断线后的观察能力 | 重启后的恢复结论 | 适合的上线判断 |
|---|---|---|---|---|
| 交互会话与后台任务共用工作区 | 容易串写、抢锁 | 依赖同一页面或连接 | 通常需要人工确认 | ❌ 不建议承载关键任务 |
| 同一环境、不同工作区 | 有一定隔离，但仍共享资源 | 可通过独立会话观察 | 需按版本和测试结果判断 | ⚠️ 适合低风险试运行 |
| 独立远程 Mac、独立工作区 | 权限、文件和资源更清晰 | 可建立持续访问路径 | 可根据实测制定恢复流程 | ✅ 适合验收后承载长任务 |
| 拆分多个独立环境 | 隔离最明确 | 单任务故障影响较小 | 可分别重试和交付 | ✅ 适合多 Agent 或高风险批处理 |
最终结论建议只使用三类：
- 可上线：所有权边界清晰，状态可定位，取消能止损，通知与产物一致，断线和异常恢复结果已记录。
- 需拆分环境：单任务可以运行，但多个 Agent 共享工作区、锁、端口或资源后出现互相影响。
- 暂不适合持续运行：无法确认任务是否完成，取消后仍有残留进程，或重启后只能依赖人工猜测。
SECTION 09 容量验收：不设先验阈值，但要看资源拐点
容量测试的目标不是找一个漂亮的平均值，而是找出任务开始互相拖累的拐点。使用代表性构建、测试、代码分析和批处理任务，逐步增加同时运行的任务数量，分别记录：
- CPU 使用趋势与编译、分析阶段是否出现明显排队；
- 内存压力、交换空间和 Harness 响应性；
- 存储读写、临时目录增长和剩余空间；
- 工作区锁、端口、缓存和凭据目录冲突；
- 任务状态查询是否延迟或丢失；
- 单任务完成时间、失败类型和产物完整性。
每一项都要有“检查动作、证据产物、判定结果”。例如，检查内存压力时保存系统监控截图和任务日志；检查工作区锁时保存锁文件、进程树和任务结果；检查交付完整性时保存产物清单和校验记录。
签收材料至少包含：基准任务输入、Harness 版本、操作系统版本、插件与权限配置、测试日期、复测条件、责任人、异常记录和最终上线类别。由于官方仓库截至 2026 年 8 月 18 日仍标注为开发预览，版本升级后应重新核对 生命周期文档、任务契约和持久化目录，而不是沿用旧验收表。
如果你现有环境在浏览器关闭、远程连接中断、进程异常或重启后无法稳定保留任务证据，问题通常不只是 Harness 配置，而是运行环境缺少独立的任务边界、持续访问和人工接管路径。与其让多个 Agent 挤在同一台机器上反复重跑，不如按任务占用窗口和隔离要求评估独立远程 Mac，并先用同一个基准任务完成试运行；需要临时算力或测试环境时，可以从 VPSNIX 的环境方案页面开始核对可用选项。