DeepSeek Harness node-pty 升级：远程 Mac 重测清单

官方于 2026 年 8 月 17 日发布 v0.1.0-rc.7。Release 同时列出持久 Bash 卡顿修复、Safari 输入框问题修复，以及 node-pty 1.2 beta 升级。这里要分开看：

官方仓库仍将 DeepSeek Harness 定义为 developer preview，并明确提示会出现兼容性破坏变化。因此，升级远程 Mac 的 DeepSeek Harness 终端环境时，不建议只看安装是否成功，也不建议因为 Bash 卡顿修复就直接扩大采购或全面迁移。(github.com)

这次 node-pty 变化足以消除 Bash 卡顿吗？
它可能改善一部分由伪终端兼容性或底层事件处理引起的卡顿，但不能覆盖模型等待、网络传输、浏览器渲染、Shell 子进程和构建工具本身的延迟。你需要把“输出没有继续出现”拆成多个可能位置，而不是把所有停顿都归因于 node-pty。

第一轮不要从大型构建开始。先使用短命令确认终端最基本的闭环：

1. 启动远程 Mac 上的 DeepSeek Harness。
2. 进入实际使用的工作区。
3. 执行会立即返回的 Bash 命令。
4. 执行会连续产生输出的命令。
5. 执行一个明确失败的命令。
6. 观察结束状态、退出码或错误反馈。
7. 再发送下一条命令，确认会话没有停在半关闭状态。

建议保留下面这些证据：

• 输入内容是否完整回显；
• 输出是否按顺序连续出现；
• 长行、ANSI 控制字符或进度信息是否导致界面异常；
• 命令结束后，后续输入是否仍然可用；
• 失败命令是否真的结束，而不是界面显示结束但后台仍在运行。

升级后是否要先调整远程终端配置？
通常不应因为 node-pty 升级就先改动全部 Shell、权限或远程访问配置。先在原配置下复测；只有出现明确的启动失败、终端尺寸错误、信号无法传递或权限变化，才针对对应环节调整。这样才能区分“版本行为变化”和“配置变化”两种原因。

官方修复的是持久 Bash 调用卡顿，不等于构建过程中的所有等待都被修复。远程 Mac 上的长任务至少有三条链路：

• 终端链路：PTY 是否持续读取并转发输出；
• 任务链路：Shell、构建工具或子进程是否仍在工作；
• 模型链路：DeepSeek Harness 是否正在等待下一步推理或工具调用。

你可以先运行一个会持续输出的轻量任务，再运行实际构建任务。不要只记录“最后成功”或“最后失败”，而要记录卡顿发生的位置：

升级 rc.7 后哪些命令任务要回归？
优先回归你真正会运行的命令，不要为了覆盖终端特性而罗列一整套命令。至少应包括：普通 Bash、带连续输出的脚本、实际构建命令、可取消的长任务，以及会启动子进程的任务。若项目依赖交互式输入，再加入一个真实需要输入控制的命令。

交互程序的重点不是“终端功能越多越好”，而是确认 DeepSeek Harness 真实任务是否依赖这些能力。建议选择一个确实会改变终端尺寸、读取按键或等待输入的程序，记录以下结果：

• 窗口尺寸改变后，程序是否重新布局；
• 输入是否被程序接收，而不是只出现在界面；
• Ctrl-C、Ctrl-D 或应用自身退出命令是否有效；
• 退出后是否回到可用的 Bash 提示符；
• 程序异常退出时，子进程是否仍残留。

如果失败，保留最小复现环境：版本、系统版本、启动命令、终端尺寸、输入序列和退出结果。不要只截一张“卡住了”的图片。node-pty 上游发布记录显示，近期版本仍在持续处理 macOS 相关的文件描述符和退出回调问题，这说明底层 PTY 行为本身仍可能随 beta 版本变化。(github.com)

远程 Mac 的终端断开后，后台任务会发生什么？
断线通常会影响你对任务的观察和控制，但不代表伪终端进程一定停止，也不代表重连后一定可以恢复。浏览器标签页关闭、网络切换、远程访问中断和后台子进程退出，是四个不同事件。

按下面步骤复测：

1. 启动一个可观察输出的长期任务。
2. 记录任务启动命令和开始时间。
3. 主动断开浏览器或网络连接。
4. 等待一段可控时间后重新连接。
5. 检查断线期间产生的输出是否补齐。
6. 尝试发送无副作用输入，确认控制权是否恢复。
7. 在远程 Mac 上直接检查目标进程和子进程状态。
8. 结束任务后确认没有残留进程、锁文件或半成品输出。

如果你的任务需要跨断线继续运行，建议先阅读 后台任务验收思路，把“页面能否回来”改成“进程、输出、控制权是否同时可验证”。如果还在核对远程 Mac 的访问方式、工作区持久性和交付后的实际访问路径，可以把这些项目列入远程环境验收记录，避免把浏览器恢复误认为任务恢复。对于需要临时准备远程 Mac 进行版本复测的场景，也可先查看 远程 Mac 交付选项，再按同一套验收条件检查访问与工作区状态。

并发验证不要一开始就追求数量。选择少量代表性终端任务，分别执行普通命令、持续输出任务和可取消任务，然后观察：

• 一个任务的输出是否出现在另一个任务中；
• 取消一个任务是否误伤其他任务；
• 每个任务的当前工作目录是否保持正确；
• 工作区文件是否被错误覆盖；
• 某个任务结束后，其他会话是否仍能继续输入；
• 断线重连后，任务标识和输出归属是否一致。

本文不提供通用并发阈值。并发数量、CPU 使用、内存变化和输出速率都必须来自你自己的远程 Mac 实测；在没有本站真实节点数据的情况下，不应虚构“支持多少任务”或“资源增加多少”。

升级验证必须保留原版本证据。最简单的做法，是固定一组任务，不改变工作区、权限、Shell 和远程访问方式，只切换 DeepSeek Harness 版本。

可以按下面的条件做决定：

• ✅ 所有关键任务通过，且没有新增回归：扩大到更多非关键工作区；
• ⚠️ Bash 改善，但断线或取消仍不稳定：限制为有人值守任务；
• ⚠️ 交互程序失败，但普通构建正常：避开该程序，保留最小复现；
• ❌ 输出、控制权或进程状态出现不可解释差异：暂停扩大试点；
• ❌ 原版本稳定、rc.7 新增回归：回退，并等待后续 Release。

node-pty 上游仍处于 beta 迭代阶段，官方项目也提醒 DeepSeek Harness 在 developer preview 阶段会出现兼容性破坏变化。升级依赖本身不是采购或全面扩容的充分证据。(github.com)

• [ ] 记录 DeepSeek Harness 版本、node-pty 解析到的实际版本、Mac 系统版本和日期；
• [ ] 在原配置下验证 Bash 输入回显；
• [ ] 验证连续输出是否推进；
• [ ] 验证命令结束状态和错误反馈；
• [ ] 验证取消后真实子进程是否结束；
• [ ] 验证一个实际构建任务；
• [ ] 验证一个确有业务需要的交互程序；
• [ ] 主动断线并检查重连后的输出、控制和进程状态；
• [ ] 并行运行少量代表性任务，检查串线和取消隔离；
• [ ] 用原版本与 rc.7 的同一任务形成对照；
• [ ] 在证据不足时选择限用或回退，而不是直接扩大试点。

如果你当前方案是本地临时 Mac、普通远程桌面或没有持久会话保障的云主机，常见缺点是：断线后进程状态不透明、输出记录不完整、权限和工作区需要重复确认，长期构建还容易把终端问题与机器资源问题混在一起。对于需要临时验证 DeepSeek Harness、复现终端兼容问题或交付一个可回收的远程 Mac 环境，使用 CALMVPS 的远程 Mac 方案更容易把版本、任务和验收步骤固定下来；但长期稳定重负载、依赖物理接口或需要完全自主管理底层系统时，自购 Mac 仍可能更合适。第一轮结果应先沉淀为远程运行检查项，再决定是否继续使用 rc.7。