DeepSeek Harness rc.7 更新！这 6 个变化最值得升级

昨天还在研究 DeepSeek Harness rc.6 的社区踩坑，结果到了 8 月 17 日晚上，官方已经把 rc.7 合进主仓。

这次速度确实有点夸张。

从 rc.6 到 rc.7 不到 4 天，中间累计 106 个提交，改动超过 500 个文件。里面当然有大量测试、文档、依赖和底层重构，但真正会让普通用户明显感受到的，我筛下来主要是 6 个。

其中最夸张的一项，是 Persistent Bash。原来一个只需要几十毫秒的 `echo`，可能硬生生等到 3 秒多；rc.7 修完以后，官方实测直接掉到 88 毫秒。

所以这次 rc.7，我觉得已经不是单纯“追一个新版本号”了。

rc.7 不是小修小补，106 个提交里已经开始补“能不能长期用”

DeepSeek Harness 刚公开的时候，最吸引人的还是架构：Everything is a Plugin、Cordis、PTC Mode、Subagent、Creator Mode……

但一个工具真正开始天天用以后，问题会慢慢从“有没有功能”变成：

终端为什么这么慢？

Agent 跑 Codex 的时候我只能等吗？

MCP 返回图片为什么模型看不到？

插件为什么还要手改 YAML？

一轮被 `max_tokens` 截断以后，为什么整个 Session 都不能继续用了？

rc.7 很大一部分改动，恰恰开始处理这些“不够酷，但每天都会遇到”的问题。

所以我更愿意把这个版本理解成：

rc.6功能已经很多rc.7开始补速度、稳定性和长期使用体验

下面这 6 个变化，是我认为最值得实际升级以后去试的。

Persistent Bash 终于不再每条命令先“发呆”3.5 秒

如果最近用 DSH 连续跑过 Shell，很可能遇到过一种很诡异的感觉。

比如：

echo hello

明明一瞬间就结束了，DSH 却迟迟不返回。

接着运行：

pwd

又在那里等几秒。

这次官方终于找到了原因。

DSH 的 Persistent Bash 会长期保留同一个 Shell，所以当前目录、环境变量、虚拟环境、函数和后台进程都可以跨多次调用继续存在。

为了判断命令到底有没有结束，终端后端有一套受控 Prompt。

问题是 Persistent Bash 初始化时，又自己修改了一遍 `PS1`。

于是就变成：

终端后端等待提示符 APersistent Bash把提示符改成 B两边永远对不上只能等静默超时

生产默认值下，一次 Tool Call 可能白白多等大约 3.5 秒。

rc.7 改成由后端自己维护 Prompt，每次都会把被覆盖的 `PS1` 修回来。

官方在 macOS 上实测：

spawn + init + echo7180 ms355 ms

echo3560 ms88 ms

pwd3566 ms91 ms

不同系统不会完全得到同样的数字，但这个差距已经足够说明问题。

以前你觉得：

DeepSeek 怎么调用终端这么慢？

很可能模型根本没慢。

Shell 也没慢。

DSH 只是在那里傻等。

复杂任务里 Agent 调几十次 Bash，这种几秒钟的小等待累计起来，就是几分钟。

所以只从体感来说，这可能是 rc.7 最值得升级的一项。

Codex、Claude Code 子 Agent 现在可以扔到后台跑

前面已经试过，DSH 可以真正把任务交给本机 Codex 和 Claude Code，而不是简单换一个模型 API。

关系大概是：

DeepSeek Harness├── Codex└── Claude Code

rc.6 的问题是：

一旦 DSH 调用 Codex，父 Agent 基本只能等它完成。

如果 Codex 查项目需要 10 分钟，那 DSH 这 10 分钟也就卡在这里。

rc.7 把 Product Subagent 接进了现有 Job Runtime。

启用相关 Subagent 后，现在可以显式让它：

run_in_background: true

于是工作流开始变成：

DeepSeek Harness├── Codex│   后台检查后端├── Claude Code│   后台审查架构└── DSH自己继续检查前端

后台任务会先返回一个 Job ID。

后面统一用：

job_listjob_outputjob_kill

查看、收结果或者停止。

比如可以直接给 DSH：

让 Codex 在后台检查所有 API 调用的异常处理。让 Claude Code 在后台检查整个项目的架构问题。你自己同时检查数据库层。不要等待两个子 Agent。等你自己的任务完成以后，再读取两个后台 Job 的结果，最后汇总三方结论。

这里最大的变化不是又多了几个参数。

而是三个 Agent 第一次真正可以同时干不同的事情。

当然，它仍然属于 One-shot Task。

每次任务都会启动新的 Codex 进程或者 Claude Code Query，任务结束以后释放资源，并不是给你养了两个永久在线的员工。

但对于代码审查、项目分析、找 Bug 这种可以独立拆开的工作，并行比前台排队好用太多了。

MCP 和 PTC Mode 的图片链路终于补上了

以前 MCP Tool 可以返回文本、结构化结果，甚至图片。

但 DSH 的图片处理链路并没有完全贯通。

于是某些工具可能真的已经：

截图成功。

结果到了 Agent 那里：

图没了。

rc.7 把这条路径重新补了一遍。

现在 MCP 返回图片后，会经过：

MCP Image解码检查当前模型是否支持图片写入 Attachment Store生成持久附件交给模型

这里最重要的是 Attachment Store。

它不是单纯把 Base64 临时塞进一次请求，而是进入 DSH 自己的持久附件体系。

于是后面的 Session、ACP、模型输入，都可以围绕同一份附件继续工作。

PTC Mode 也一起补了图片返回。

所以以后这种流程才真正成立：

MCP抓取网页截图PTC Mode继续组合其他工具DeepSeek直接看图分析

对于只拿 DSH 写代码的人，这个变化暂时没 Persistent Bash 那么明显。

但从 Harness 的方向看，它很重要。

因为浏览器、图表、截图、图像生成、视觉分析这些 Agent 能力，最终都绕不开图片。

第三方插件终于可以自己在设置页面“安家”

这个变化对普通用户今天感受可能还不强，但对 DSH 插件生态非常重要。

以前第三方 Plugin 可以拥有自己的 Settings Namespace，比如：

API Key模型路径超时时间开关

但想把这些配置漂亮地放进 DSH Web 设置页面，并没有那么自由。

插件已经注册了自己的 Settings，Web 页面却还受 DSH Core 里的硬编码名单限制。

结果可能变成：

第三方插件已经有配置用户还是得打开 settings.yaml 手动改

这对普通用户显然不友好。

rc.7 改成一个很合理的原则：

注册即暴露。

一个插件可以在 Host 侧注册自己的 Settings Namespace，同时在 Browser 侧注册对应的设置 Card。

例如：

my-plugin├── Settings Namespace└── Settings Card

两边 Key 对上以后，Web Settings 就能把它们组合起来。

以后插件更有机会做到：

安装 Plugin打开 DSH 设置找到插件自己的卡片填写 API Key / 参数保存

而不是要求用户看 README 再手改 YAML。

当然，插件作者仍然要主动实现自己的 Browser Card。

并不是升级 rc.7 以后，所有老插件都会自动拥有漂亮设置页。

但至少平台层已经把门打开了。

以后判断 DSH 插件做得好不好，可能不只是看：

功能强不强。

还要看：

安装、配置、升级是不是能自己闭环。

Ask User 那张“大卡片”，终于可以暂时收起来了

Agent 在任务过程中遇到需要用户选择的时候，会弹出 Ask User 卡片。

例如：

你希望：A. 修改当前配置B. 新建配置C. 只分析

以前这张卡最高可以占：

min(60vh, 520px)

差不多半个屏幕甚至更多。

偏偏很多问题又需要先回头看之前的聊天记录才能决定。

于是画面经常变成：

上面想看的聊天记录下面一张巨大问题卡挡着

rc.7 增加了折叠按钮。

收起以后只留一个很窄的 Header：

┌────────────────────────┐│ Agent 还有问题   ∨   × │└────────────────────────┘

看完历史，再展开回来继续回答。

关键是收起不会丢掉：

已经选好的选项当前题目位置还没提交的输入

也不会重新抢走输入框焦点。

这不是一个会让 DSH “更聪明”的功能。

但这种小改动其实特别体现一个产品是不是已经开始有人天天用了。

因为只有真正长时间使用，才会发现：

这张卡太挡屏幕了。

一次 max_tokens 截断，不应该再把整个 Session 永久“毒死”

最后这一条对长任务很重要。

Agent 跑很久以后，有时候会遇到：

max_tokens

也就是这一轮输出到达 Token 上限，被截断。

单纯截断其实没什么。

问题出在，如果这时候刚好还有一个没完成的 Tool Call。

旧版本里可能出现：

真正保存的内容已经删除残缺 Tool CallReplay State仍然按照原始完整消息保存

下一次恢复历史时：

Content有 3 个 BlockReplay Metadata却认为有 4 个

最后报：

INVALID_REPLAY_STATE

麻烦的是，这个错误已经写进 Session。

于是可能出现：

下一轮失败再下一轮失败重启 DSH还是失败

一个聊了很久的 Session 因为一次截断直接废掉。

rc.7 做了两层处理。

第一层是以后写入的时候，让：

Content BlockReplay Entry

统一决定保留还是删除。

残缺 Tool Call 被删除：

Tool Call对应 Replay Metadata一起删

第二层更重要。

对于磁盘里已经存在的旧坏数据，rc.7 不再一律硬失败。

遇到：

旧版 Replay State未知格式Block 数量不匹配Metadata 损坏

会尽量退化成普通 Provider-neutral Message 继续使用。

也就是：

以前：

这条历史坏了，整个 Session 停止。

现在：

高级回放信息坏了，那就不用高级信息，正文至少继续保住。

Replay State 可以提高模型历史恢复的保真度。

但真正更重要的是：

用户已经积累几个小时的 Session 不能因为一条 Metadata 废掉。

对于长期 Agent，我觉得这个优先级非常高。

rc.7 我会升，这次理由比 rc.6 明确得多

单看：

rc.6rc.7

只是增加了一个数字。

但不到 4 天的 106 个提交里，真正值得普通用户看的方向已经很明确：

Persistent Bash从秒级等待回到毫秒级Codex / Claude Code可以真正后台并行MCP / PTC图片链路打通第三方插件开始拥有自己的设置界面Ask User不再霸占半个屏幕长 Session出现异常以后更容易救回来

另外 Safari 输入框、PowerShell Terminal、历史分页等地方，也有一批稳定性修复。

所以这次如果问我 rc.6 要不要升级 rc.7，我的答案会比上一版积极得多。

可以直接指定版本尝试：

npx @deepseek-ai/dsh@0.1.0-rc.7 web

已经有重要配置和项目的朋友，升级以前还是建议把当前环境留个备份。

毕竟 DeepSeek Harness 现在依旧处于 Developer Preview，rc.7 不等于从此稳定。

但我觉得这个版本透露出来的变化很重要：

DSH 已经不只是继续往里面塞能力了。

它开始认真解决另一件更难的事：

让已经很强的能力，真正跑得快、跑得稳，出了事故还能继续干活。

对于一个 Harness 来说，这一步可能比再增加 20 个新工具更重要。