99% 的人以为“本地 Web 页面”就等于“所有数据都只在本机”，在 DeepSeek Harness 上，这个想法很危险。dsh 不只是一个聊天框，而是能读写代码、跑命令、调度子代理的“本地控制台”。如果你打算上手 rc.8，这篇会带你从安装到验证，一步步把风险压到可控范围。

DeepSeek Harness（命令名 dsh）是 DeepSeek AI 的开源智能体（Agent）运行框架。本指南版本钉死在 dsh-v0.1.0-rc.8，对应 2026 年 8 月 19 日发布版本，并在 8 月 20 日对照官方源做过校验。rc.8 标记为 Pre-release，整个项目仍处于 Developer Preview 阶段，未来出现破坏性更新是官方明确预期。

简单说，最短的上手路径是：装好 Node.js，在一个安全目录里启动本地 Web UI，在 Settings → Models 配好模型，选一个刻意“阉割”的测试工作区，然后对每一次权限请求都点开看清楚再决定。关键点在边界：本地浏览器地址不等于“推理一定只在本机”，选中的 workspace 也不等于操作系统级沙箱。

**版本与安全提醒：**rc.8 建议先在一次性或已完整备份的工作区里试用。官方发布说明写明：SQLite 存储格式与旧版本不兼容。升级前务必备份或隔离 Harness 的 home 目录；不要把 Web UI 暴露到公网，不要把密钥直接贴进对话，不要给未经审查的插件访问敏感仓库的权限。

DeepSeek Harness 是什么

Agent Harness 与“万物皆插件”

DeepSeek 把 Harness 定义为“Agent Harness”，并强调“Everything is a plugin”，底层由 Cordis 驱动。它的 Web UI 可以协调一个智能体去读取和编辑工作区文件、执行命令、拆分子任务、维护任务计划，这种权限级别远超普通聊天框。

换句话说，装好 dsh、配好模型，只是“能跑起来”；真正决定风险的是：你给了它哪个目录、开了哪些插件、允许它执行什么命令、把哪些数据送给了哪个模型。说实话，把它当成“本地 IDE 里的超级助手”会更接近真实风险画像。

有用户反馈，把整个公司 monorepo 直接当 workspace 给 dsh，结果一个自动重构任务改动了上千个文件，虽然有 Git 回滚，但 review 成本巨大。

权限比你想象的大得多

据官方架构描述，Harness 支持：

  • 读写工作区内文件
  • 通过 Shell 插件执行命令
  • 调用 Web 搜索等外部工具
  • 调度 Codex、Claude Code 等子代理

这意味着：

  • 你不是在“和一个模型聊天”，而是在“给一个自动化运维/开发助手下达指令”；
  • 每一次“允许执行命令”“允许修改文件”，都相当于给它一次 sudo-lite；
  • 工作区边界、权限策略、插件开关，和模型质量一样重要。

我也不太确定“万物皆插件”是不是对所有团队都是好事，但可以肯定的是，它把复杂度和可配置性一起拉满了。

已验证与未验证的内容

npm 版本与标签状态

2026 年 8 月 20 日，我们对 npm 做了一次只读检查，解析 @deepseek-ai/dsh@0.1.0-rc.8，记录了分发完整性和 tarball URL。当时 npm 的 next 标签指向 0.1.0-rc.8，而 latest 仍指向 0.1.0-rc.7。这就是为什么本指南使用显式版本号安装 rc.8，而不是直接跑不带版本的命令。

需要强调：我们没有在本地实际运行 rc.8 的 CLI 或 Web UI，没有从 rc.7 迁移 home，没有配置密钥、发起模型请求，也没有验证 rc.8 新增的图像、多智能体、PowerShell、Web 搜索、存储或网关行为。

数据显示，很多团队在试新版本时只看 README，不看 release notes 里的“破坏性变更”小节，结果踩到存储不兼容、配置字段变更这类坑。

rc.7 本地运行记录（作为对照）

下面的本地运行证据来自 rc.7，保留它是为了如实呈现当时观察到的行为，而不是把它“偷换标签”成 rc.8 证据。2026 年 8 月 19 日，我们解析 @deepseek-ai/dsh@0.1.0-rc.7，记录了分发完整性。钉死 rc.7 的 CLI 返回版本 0.1.0-rc.7，并暴露 web 和 plugin 两个子命令。

一份脱敏批处理摘要记录了三次连续的本地回环请求：访问 http://127.0.0.1:3080，HTTP 200，text/html; charset=utf-8，页面标题为 DeepSeek Harness，正文大小 12,076 字节，SHA-256 一致。额外一条原始脱敏 GET 用于对账，状态码、内容类型、大小和 URL 都匹配，原始三请求流未保留。

在 Codex 桌面端更新恢复“受控内嵌浏览器”后，第二轮隔离运行使用了单独的 DSH_HOME。又有三次干净的回环 GET 返回 HTTP 200 和相同的 12,076 字节体积 SHA-256。监听检查显示仅有一个 TCP 监听占用 3080 端口，绑定在 127.0.0.1。在确认路径和启动时间后，只强制停止了该次运行的 Node 监听和启动包装进程，两个 PID 都被确认不存在，3080 端口释放。

rc.7 UI 行为与移动端缺陷

在 1440 × 1000 分辨率下，rc.7 界面约 5 秒内可用。先出现 Internal Testing Notice，点击 Continue 后弹出 API key 模态框，选择 Configure later 跳过密钥输入。主界面此时没有选中 workspace，输入区只读，Commands 和 Send 按钮不可用。

Settings 中可以看到：General 下的 Workspace Write，模型页有 DeepSeek / deepseek-official 条目但 key 为空，插件卡片包括 Shell、Agent loop、Web search，预设有 PTC mode、Standard、Minimal、Creator。没有开启会话时 Job Panel 不可见，因此不对 Job Panel 行为做任何结论。

在 390 × 844 视口下，主视图使用 390 px 宽度，无页面级横向滚动，核心布局仍可用。但 Settings 对话框有一个可复现的响应式缺陷：对话框宽 342.4 px（x=24 到 x=366.4），隐藏横向溢出，而 Standard 和 Workspace Write 控件分别延伸到 x=401.26 和 x=413.65，被裁剪在对话框和视口之外。没有保留截图，这是带具体测量值的人工观察记录。

浏览器环境限制与结论边界

在受控浏览器中，window.showDirectoryPicker 为 undefined，点击 Add workspace 没有弹出目录选择器，也没有可用的 Chrome 绑定。我们将其归类为“检查环境限制”，而不是 Harness 产品缺陷，因此不声称看到“选中 workspace 后的行为”。

综合来看：

  • rc.7 记录支持：钉死安装、回环启动、无密钥桌面状态、命名设置界面、移动端布局缺陷；
  • rc.8 记录只支持：npm 包身份和标签状态；
  • 二者都不能证明 rc.8 的实际运行、workspace 迁移、模型连通性、工具执行、多模态输入、PTC Mode 任务、Job Panel 行为、子代理兼容性、安全保证或具体模型提供商行为。

安装 dsh 前的准备

安装前的安全清单

  • 确认 Node.js 环境完整：需要 Node.js、自带 npm 和 npx。官方说明没写最低版本，建议用你团队常用的 LTS 版本，并记录下来。
  • 准备一次性工作区：用一个小目录做测试，里面不要放任何凭证、生产数据、私钥、客户文件或无关仓库。
  • 备份可能被编辑的内容：版本控制可以帮你 review 改动，但替代不了离线备份或快照。
  • 提前决定可用的托管模型：在把代码或数据交给某个模型前，先看清楚该提供商的隐私政策和平台条款。
  • 使用单独的 API Key：能用临时或权限收紧的 key 就别用主 key，控制好余额或配额，用完就撤销。

有团队反馈，用主账号 key 做测试，结果一个误配置的自动补全任务在几分钟内烧掉了整月配额，这种“学费”完全没必要交。

一个简单的风险判断方法

判断“这个目录适不适合当 dsh workspace”，可以用三问法：

  1. 这个目录里有没有任何你不希望第三方模型看到的东西？
  2. 如果一个脚本在这里误删/误改文件，你是否能在 10 分钟内恢复？
  3. 这个目录是否已经在 Git 等版本控制下，并且有远端备份？

只要有一个答案是否定的，就把它从“首轮测试工作区”名单里划掉。

步骤 1：验证 Node.js、npm 与 npx

命令行自检

在一个全新的终端里运行：

node --version
npm --version
npx --version

三条命令都必须返回版本号。如果 node 正常但 npx 报错，先重开终端，再确认 Node.js 安装目录已经加入系统 PATH。没把这一步跑干净，不要急着执行 Harness 相关命令。

常见环境坑

  • 用系统自带的极老 Node 版本（比如某些 Linux 发行版仓库里的），可能遇到依赖安装失败；
  • 同机多版本 Node 混装，PATH 指向错了，导致 npx 找到的是旧版本；
  • 在公司受控环境里，npm 被代理或镜像劫持，包版本与公网不一致。

遇到这些情况，建议先在一台“干净环境”的个人机器上完整跑通，再迁移到受控环境。

步骤 2：在安全目录启动 rc.8 Web UI

钉死版本启动命令

切换到你准备好的一次性目录，为了可复现性，用钉死版本的命令启动：

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

官方 README 给出的“移动命令”是 npx @deepseek-ai/dsh web，但没有写版本。在 8 月 20 日的 npm 检查中，latest 仍指向 rc.7，next 才指向 rc.8，所以我们不把不带版本的命令当作 rc.8 安装器。

当前 README 写明：本地启动会自动打开默认浏览器，--no-open 可以关闭这一行为。默认地址是 http://127.0.0.1:3080，如果终端输出的 URL 不同，以实际输出为准。

端口与网络边界

  • 保持终端开着，整个使用过程中不要关掉；
  • 不要为了“手机也能访问”就加防火墙例外、反向代理、公网隧道或改成 0.0.0.0 绑定；
  • 如果 3080 端口已被占用，先查清楚是谁在用，而不是直接 kill 一个未知进程。

Sanitized DeepSeek Harness rc.7 install and loopback startup evidence

步骤 3：配置模型，但别泄露密钥

在 Settings → Models 中设置

进入 Web UI，打开 Settings → Models。官方 quickstart 的做法是在这里填入 DeepSeek API key 并保存，说明模型路由会立即可用，无需重启服务。

在这一步，建议遵守以下密钥安全规则：

  • 只把 key 粘贴到明确标注为“密钥/Secret”的输入框；
  • 不要把 key 写进 prompt、源码文件、README、命令行参数、截图或工单；
  • 配置时避免录屏，尤其是共享屏幕场景；
  • 在发送仓库上下文前，再次确认选中的模型和提供商是否正确；
  • 评估结束后撤销临时 key，并实际验证它已经失效。

这些是通用的密钥操作规范，并不是对 Harness 内部存储方式的背书。长期使用前，应该针对你部署的版本，独立验证它的凭证存储与加密策略。

团队如果要集中管理模型密钥，更稳妥的做法是用 API 网关和密钥隔离，而不是把本地客户端配置当成“企业级密钥管理”。

团队级密钥管理建议

团队集中管理时，可以考虑：

  • 在网关层做路由与限流，把 dsh 当成“受限客户端”；
  • 用不同 key 区分环境（dev/stage/prod），并限制 prod key 只在 CI/CD 或受控服务中使用；
  • 定期轮换 key，并在轮换前后做一次“谁在用、用在哪”的盘点。

步骤 4：有意识地选择 workspace

workspace 不是系统级沙箱

dsh 进程默认以启动目录作为文件系统根，但官方 quickstart 写明：全新 Web UI 初始状态下没有选中 workspace。你需要点击 Choose workspace，添加你启动 dsh 的那个一次性项目目录，并选中它。选中前，输入区是不可用的。

不要把 workspace 选择器当成“已经帮你做了系统级隔离”的证据。根据文档，Agent 可以：

  • 读取和编辑 workspace 内文件；
  • 运行命令（视插件与权限策略而定）。

所以：

  • 把敏感的兄弟目录从测试路径里移走；
  • 在第一次任务前，先看清楚权限控制界面；
  • 每次 UI 弹出审批请求时，都核对路径和具体操作。

DeepSeek Harness no-key workspace and permission boundary observation

一个简单的 workspace 选取流程

可以按这个顺序来：

  1. 新建一个只包含公开示例代码的小目录；
  2. 用 Git 初始化，并做一次初始提交；
  3. 把这个目录作为唯一 workspace 加入 dsh；
  4. 在任务结束后，对比 Git diff，确认所有改动都在预期范围内。

步骤 5：用低风险任务做首轮试跑

推荐的首个任务

官方 quickstart 建议做“仓库总结”类任务。在一次性公共示例仓库里，可以用这样的首条指令：

Summarize this repository and identify its main packages.

发送前，再确认两件事：

  • 当前 workspace 里没有任何机密内容；
  • Settings 中选中的模型提供商就是你打算用的那一个。

任务执行过程中，对每一个拟修改文件、每一条命令都单独审阅。审批弹窗是一个“需要你判断”的节点，而不是“系统已经帮你审过”的证明。

审批时的红线

  • 不清楚命令作用时，不要因为“想看结果”就点允许；
  • 看到涉及 rm、mv、chmod、chown 等高风险命令时，优先拒绝并改写任务；
  • 对跨目录访问（如访问上级目录）保持警惕，必要时重启并换更小的 fixture。

本地、workspace 与模型提供商的三重边界

三个“本地”的误解

很多人会混淆三个概念：

  • 本地 Web UI：浏览器访问的是 127.0.0.1；
  • 本地进程：dsh 进程在你机器上跑；
  • 本地推理：模型计算也在你机器上完成。

前两个成立，并不自动意味着第三个也成立。只要你用的是托管模型，代码和数据就会被发往远端推理服务。

DeepSeek Harness local Web UI and hosted model data-flow boundary

一个实用的隐私判断标准

判断“这段内容能不能给模型看”，可以用这个标准：

  • 如果你不愿意把它发到该云厂商的客服邮箱，就不要发给它的模型；
  • 如果你需要额外签 NDA 才敢发，那就先确认模型服务是否在 NDA 覆盖范围内；
  • 如果你连“这是谁的云”都没搞清楚，那就先停下，查清楚再说。

rc.8 带来了什么变化

官方 release notes 中的新增能力

根据 rc.8 官方发布说明，本次变更包括（以下为官方范围事实，而非本地测试结果）：

  • 多模态输入：DeepSeek 适配器可配置为使用原生图像请求；/goal、/plan 等命令可接收图文混合输入，@ 菜单可引用文件和会话；
  • Claude Code 与 Codex Bundle：两者都可按需作为 Profile Bundle 安装，说明中还提到 Codex 的非交互式权限模式和多命名实例；
  • Windows PowerShell：Windows PTY 终端获得持久化 PowerShell 会话，在 Minimal 预设中默认启用；
  • 模型与流式修复：修复了大图像或累计图像负载导致的请求失败，保留被取消流式响应的前缀以便后续追问和分支，修正部分自定义 OpenAI 兼容网关格式与 reasoning 内容问题；
  • 工具与编排：web_search 支持并发查询，子代理 reportDelivery 可以更快上报并唤醒父任务；
  • UI 与启动体验：支持 ~ 作为 home 目录缩写，改进窄屏输入区布局、工作流与模型选择交互，重试失败的本地文件打开，减小依赖下载体积，本地 dsh web 自动打开浏览器，加速长历史会话的分支创建；
  • 存储：提升 SQLite 读写、分支性能和存储体积，但明确写明“存储格式不兼容”；
  • SDK 与品牌：Python SDK runtime 覆盖四个内置 Agent 预设，并包含 rg/glob 搜索与 MCP stdio 工具依赖；发布说明还链接了注册商标 DeepSeek Harness 的品牌使用指引。

Official DeepSeek Harness rc.8 changes for multimodal input, agent bundles, PowerShell, tools, and storage

升级边界与风险提示

**升级边界提醒：**release notes 并不等于“迁移成功证明”。

rc.8 明确写了 SQLite 存储格式不兼容，但没有保证：

  • 现有 rc.7 home 一定能平滑迁移；
  • 失败时一定能无损回滚；
  • 所有历史会话都能在 rc.8 下正常打开。

所以：

  • 升级前先完整备份原有 Harness home；
  • 用一个全新的、一次性的 DSH_HOME 做 rc.8 试跑；
  • 在确认 rc.8 行为符合预期前，不要让它指向唯一一份重要会话数据。

PTC Mode 与 Job Panel：来自 rc.7 的上下文

rc.7 中的相关改动

根据 rc.7 发布说明（不是我们的本地运行结果）：

  • 英文 Code mode 预设被重命名为 PTC mode；
  • MCP 与 ACP 在 PTC Mode 下获得可持久的图像附件，并支持嵌套转发；
  • Job Panel 可以管理 Codex 与 Claude Code 子代理任务。

rc.8 在此基础上，增加了按需安装的 Profile Bundle 和扩展的多模态输入。但我们没有在任一版本中实际操作 PTC Mode 任务、Job Panel、图像转发、Bundle 安装或 Codex 权限模式。

关于 PTC 的一个提醒

不要凭猜测去扩展 PTC 的含义，也不要把 Harness 里的某个控制项，当成所有 API 面的“统一契约”。如果你关心的是当前可用的 API 字段与行为，应以官方 DeepSeek API 文档为准，而不是 UI 命名。

如何验证你自己的安装

一套可复用的验证步骤

  1. 记录：release tag、npm 包精确版本、npm 标签状态、Node.js 版本、npm 版本、npx 版本、日期和操作系统；
  2. 跨越 rc.8 SQLite 存储边界时，使用已备份或一次性的 Harness home，并记录路径（对外发布时脱敏）；
  3. 确认页面从干净的回环 URL 加载，没有被重定向到非回环主机；
  4. 在未选中 workspace 前，记录输入区是否不可用，是否与官方说明一致；
  5. 只选择一次性 fixture 作为 workspace，并在 UI 中确认显示路径；
  6. 打开 Settings → Models，在不暴露 key 的前提下，确认提供商与模型配置；
  7. 分项记录 rc.8 的各个界面：图像输入、@ 引用、PowerShell 持久化、PTC Mode、Job Panel、已安装 Bundle、Codex 权限模式、并发 Web 搜索、父任务唤醒行为，对未观察到的项目标记为 N/A；
  8. 任务结束后，检查每一个被修改的文件和命令结果，停止本地进程，并撤销所有临时 key。

一个经验：把“官方宣称的能力”和“你自己机器上实际看到的行为”分开记录。release notes 证明“有这个开关”，运行记录才证明“在你的环境里，这个开关是怎么工作的”。

认知增量：验证≠信任

很多团队会把“安装成功 + 跑通一个 demo”当成“可以上生产”的信号，这个逻辑是错的。更合理的做法是：

  • 把 dsh 当成一个需要安全评估的本地服务；
  • 把每个插件、每个模型提供商、每个 Bundle 当成独立的信任决策；
  • 把“能跑起来”与“适合跑在生产仓库上”分开对待。

DeepSeek Harness 故障排查

npx 无法识别

安装官方渠道的 Node.js，重开一个新终端，再跑一遍三个版本检查命令。如果只有 npx 缺失，优先修复 Node.js/npm 安装，而不是随手下载一个名叫 npx 的可执行文件。很多恶意软件就靠这种“名字撞车”混进系统。

Web UI 无法在 3080 端口打开

先看终端里实际打印的 URL，再检查是否已有其他进程占用 3080 端口。不要凭空猜测命令行参数，也不要随便 kill 一个未知进程。重试前，记录下终端报错、包版本和 Node.js 版本，这些信息会极大提升后续排查效率。

输入区（composer）不可用

全新 Web UI 需要先选中 workspace。点击 Choose workspace，添加你启动 dsh 的目录并选中。如果输入区仍不可用，先记录当前 UI 状态和操作步骤，而不是反复乱改设置，这样更容易复现和上报问题。

模型路由不可用

回到 Settings → Models，确认目标提供商配置已保存，并在 UI 之外单独检查 key 是否正确。官方说明写明：路由应在保存后立即可用，无需重启。如果仍不可用，把具体错误信息当作“版本特定行为”记录下来，而不是简单归类为“网络问题”。

rc.7 会话或 home 在 rc.8 升级后失效

先停掉进程并保留原始数据。rc.8 发布说明明确写了 SQLite 存储格式不兼容，但没有给出保证成功的迁移或回滚流程。用一个全新的、一次性的 DSH_HOME 复现问题，不要在唯一一份重要会话数据上反复打开、覆盖或试错。

请求的操作范围过大

如果某个操作看起来“太大”或“太模糊”，直接拒绝，缩小 workspace 或任务范围，再检查当前权限策略。不要为了让任务继续而勉强点“允许”。当你搞不清楚它要动哪个路径、做什么操作时，最稳妥的做法是：关掉当前会话，换一个更小的测试 fixture 重来。

现在适合用 DeepSeek Harness 吗？

如果你明确想评估 DeepSeek 自家、插件化的 Agent Harness，并且能接受 Developer Preview 阶段的破坏性更新和不兼容存储边界，那 rc.8 值得一试。前提是：

  • 始终钉死版本；
  • 隔离 Harness home 与 workspace；
  • 把每一个提供商、插件、Bundle、权限策略和更新都当成独立的信任决策。

对于还在选型阶段的团队，可以把 dsh 放进“实验环境工具箱”，和其他 Agent 框架一起对比。等你真正要把它接入生产仓库时，这篇指南里的边界与验证步骤，会比问身边人“好用吗”更有参考价值。

Chat-Deep.ai 是独立参考站点，与 DeepSeek 无隶属、代言或运营关系。“DeepSeek Harness”一词仅用于指代官方项目本身。

常见问题

Q：DeepSeek Harness（dsh）到底是什么？

A：DeepSeek Harness（dsh）是 DeepSeek AI 开发的开源智能体运行框架，官方称其架构为“万物皆插件”，由 Cordis 驱动。它的 Web UI 不只是聊天界面，而是一个可以读写工作区文件、执行命令、调度子代理的控制台。判断要不要用它，关键是看你是否需要这种“高权限自动化助手”，以及是否有足够的权限与安全边界管理能力。建议先在一次性工作区里体验，再考虑接入真实项目。

Q：rc.8 作为预发布版，稳定性有多差？

A：rc.8 被官方标记为 Pre-release，整个项目处于 Developer Preview 阶段，DeepSeek 明确提示会有兼容性破坏更新。实际风险包括：存储格式不兼容、配置字段变更、插件行为调整等。使用时应钉死版本号、隔离 Harness home，并在每次升级前后做一次最小验证集（启动、选 workspace、跑一个小任务）。生产环境不建议直接依赖 rc.8 的存储与行为做关键业务决策。

Q：如何正确启动 DeepSeek Harness 的 Web UI？

A：前提是已安装 Node.js。官方 README 给出的命令是 npx @deepseek-ai/dsh web，但为避免 npm 标签漂移，本指南推荐 npx @deepseek-ai/dsh@0.1.0-rc.8 web。启动后，默认 Web UI 地址是 http://127.0.0.1:3080，浏览器通常会自动打开。若未自动打开，可手动访问终端输出的 URL。启动前后建议记录 Node.js 版本、包版本和日期，方便后续排查或复现问题。

Q：dsh 对文件系统的访问范围是怎样的？

A：dsh 进程以启动目录作为默认文件系统位置，但 Web UI 初始没有选中 workspace，需要你手动添加并选择。选中 workspace 后，Agent 可以读取和编辑该目录内的文件，并在权限允许时执行命令。需要注意的是：workspace 选择器并不等于操作系统级沙箱，Agent 仍可能通过命令访问其他路径。因此，测试时应使用一次性目录，并避免在同级目录放置敏感数据。

Q：DeepSeek Harness 会把我的代码“只留在本地”吗？

A：不能这么假设。虽然 Web UI 默认通过回环地址（127.0.0.1）提供服务，但只要你使用的是托管模型，提交给模型的上下文就会发送到远端推理服务。是否“只留在本地”，取决于你选用的模型类型和部署方式，而不是 UI 地址。实际使用前，应阅读模型提供商的隐私政策和开放平台条款，并为机密代码与数据单独设计访问策略和脱敏流程。

Q：在 DeepSeek Harness 里应该如何管理 API Key？

A：官方 quickstart 指定在 Settings → Models 中填写 API Key，这是唯一推荐位置。操作时不要把 key 写进 prompt、仓库文件、命令行参数、截图或日志。更稳妥的做法是使用临时或权限收紧的 key，并在测试结束后立即撤销。团队级使用时，可以在 API 网关层集中管理 key，把 dsh 当成“受限客户端”，避免在多台开发机上散落长期有效的高权限密钥。

Q：rc.8 对 PTC Mode 和图像能力做了哪些增强？

A：rc.8 发布说明中提到：DeepSeek 适配器支持可配置的原生图像请求，/goal、/plan 等命令可以接收图文混合输入，@ 菜单可以引用文件和会话。rc.7 则引入了 PTC Mode 下的持久图像附件和嵌套转发。需要强调的是，这些是 release notes 中的声明，我们没有在本地逐项验证图像路径与 PTC Mode 的实际行为。若你依赖这些能力做关键任务，建议自行设计测试用例并记录结果。

Q：rc.8 如何集成 Codex 和 Claude Code？

A：根据 rc.8 发布说明，Claude Code 与 Codex 子代理可以按需作为 Profile Bundle 安装，Codex 还支持非交互式权限模式和多命名实例。rc.7 说明中提到 Job Panel 可以管理它们的子代理任务。我们没有测试安装流程、权限模式、任务交付或功能对齐情况。实际使用前，建议在一次性仓库中单独验证：Bundle 安装是否成功、权限提示是否清晰、Job Panel 是否能正确展示和控制子任务。

Q：升级到 rc.8 后还能复用 rc.7 的会话存储吗？

A：不要默认可以。rc.8 发布说明明确写了 SQLite 存储格式不兼容，这意味着直接复用旧 home 目录可能导致会话无法打开或数据损坏。正确做法是：先完整备份 rc.7 的 Harness home，然后用一个全新的、一次性的 DSH_HOME 启动 rc.8 做试验。如果确认 rc.8 行为符合预期，再考虑是否迁移旧数据，并在迁移前设计好回滚方案。没有把握时，宁可保留两套独立环境，也不要冒险覆盖唯一数据。

官方来源与后续关注

  • DeepSeek Harness 官方仓库
  • dsh-v0.1.0-rc.8 官方发布页
  • dsh-v0.1.0-rc.7 官方发布页（PTC Mode 与 Job Panel 历史背景）
  • DeepSeek Harness 品牌使用指引
  • DeepSeek Harness 官方 Web UI 快速上手
  • DeepSeek 隐私政策
  • DeepSeek 开放平台服务条款

官方仓库、rc.8 发布页和品牌指引最近一次直接核对时间为 2026 年 8 月 20 日。因为 Harness 仍处于 Developer Preview 阶段，每次升级前，都值得再花几分钟重读一次最新的 release notes 和 quickstart。这个判断方法在多次项目中被反复验证有效，留在手边，等你下一次做“要不要升级”的决定时再翻出来看看，也许能帮你少踩一个坑。