DeepSeek Harness 多模态升级：从 rc.8 到 v0.1.1-rc.2
DeepSeek Harness 从 rc.8 到 v0.1.1-rc.2 连续补齐原生图片、视觉模型、Files API、子代理 Bundle 与 Windows PTY。本文解释能力边界和升级风险。
DeepSeek Harness 多模态升级：从 rc.8 到 v0.1.1-rc.2
DeepSeek Harness 的多模态能力不是一次性上线的。8 月 19 日，v0.1.0-rc.8 打通图片进入 Agent Loop 的第一条路径；8 月 21 日，v0.1.1-rc.1 加入明确的视觉模型；同一天的 rc.2 又补上 Files API 复用、自动缩放和格式转换。
只看 rc.8 的更新清单，很容易得出“DSH 现在能看图了”的结论。真正值得工程团队关注的，是这三版逐步补齐了输入表达、模型路由、载荷管理和执行协作。图片不再只是聊天框附件，而开始贯穿 /goal、/plan、MCP/ACP、子代理和会话历史。
先说结论
- rc.8 是多模态主线的起点，不是截至 8 月 22 日的最新版；当前 GitHub Release 是
v0.1.1-rc.2。- rc.8 增加原生图片请求、命令图文输入、文件/会话引用，并修复大图与累计图片载荷导致的请求失败。
- rc.1 接入
DeepSeek-V4-Flash-Vision-Exp；rc.2 优先通过 Files API 上传并复用图片，同时按模型要求自动调整尺寸与格式。- Claude Code 与 Codex 可以按需作为 Profile Bundle 安装，支持非交互权限模式和多个命名实例，但这不等于任务自动获得安全隔离。
- DSH 仍明确处于 developer preview，Release 全部标为 Pre-release；rc.8 还包含不兼容的 SQLite 数据结构变更，不应无备份滚动升级。
rc.8 做的不是“加个上传按钮”
rc.8 的官方 Release 同时列出多模态、子代理、Windows PTY、工具调用与存储调整。来源：DeepSeek Harness GitHub，截图于 2026 年 8 月 22 日。
官方 Release 把 rc.8 分成新增功能、问题修复、体验优化、其他变更和 SDK。若按产品影响重新整理，大致是 5 条主线，而不是简单的“14 个功能”。
| 主线 | rc.8 的变化 | 对工作流的实际影响 |
|---|---|---|
| 多模态输入 | DeepSeek 适配器可配置原生图片请求；/goal、/plan 接收图文 | 图片可以参与目标定义和计划，而不只作为普通消息附件 |
| 上下文引用 | 输入框 @ 菜单可引用文件和会话 | 减少手工复制内容，保留上下文来源 |
| 子代理 | Claude Code、Codex 作为 Profile Bundle 按需安装 | 同一 Harness 可组合不同编码子代理和命名实例 |
| 终端 | Windows PTY 支持持久 PowerShell，会在 Minimal 预设默认启用 | 连续命令共享 shell 状态，减少反复初始化 |
| 可靠性与性能 | 大图载荷、流式取消、自定义网关、历史分叉、SQLite 优化 | 修复的是长会话和非默认环境中更容易出现的真实故障 |
这里最容易被低估的是 /goal 和 /plan。如果图片只能出现在普通聊天消息里，Agent 也许能描述截图，却未必会把视觉证据带入目标约束和计划阶段。命令层接受图文后，“根据这张错误截图定位并验证修复”才有机会成为完整任务，而不是一次孤立问答。
@ 引用也不只是输入体验优化。文件和会话引用让宿主界面知道上下文来自哪里，后续才可能做权限检查、重放和审计。把文件内容直接粘进 Prompt 会丢失这些关系。
原生视觉与工具层视觉是两种不同能力
媒体和社区讨论中，“纯文本模型也能看图”是最吸引眼球的说法。技术上需要拆成两条路径。
原生视觉路径把图片作为模型支持的输入类型发给视觉模型。它更适合照片、复杂空间关系、视觉风格和需要整体语义理解的任务。模型适配器必须正确表达图片、限制尺寸，并处理提供商协议差异。
工具层视觉路径则先用 OCR、图像元信息、颜色统计、像素或布局分析把图片转成结构化文本，再交给文本模型推理。它对界面截图、文档、表格和简单流程图可能很有效，因为这些任务的关键信息本来就可以被文字与坐标表达。
但两者不能互相冒充。OCR 能读出按钮文字，不代表它可靠理解人物动作、遮挡关系或摄影语义；像素统计能发现颜色区域，不代表它知道那是告警、品牌色还是背景。工具层视觉提供的是可检查的局部证据，不是通用视觉模型的等价替代。
rc.8 官方 Release 确认的是原生图片请求及其载荷处理，并没有承诺内置一套会自动从失败的 read_image 切换到 OCR、颜色统计和像素扫描的通用降级链。社区插件可以实现类似方案，但文章和产品设计都应把“官方能力”和“插件组合”分开。
rc.1：从“能传图片”到“有明确视觉模型”
v0.1.1-rc.1 的 Release 明确新增 DeepSeek-V4-Flash-Vision-Exp。来源：DeepSeek Harness GitHub，截图于 2026 年 8 月 22 日。
rc.8 解决了 Harness 如何表达图片，rc.1 则让 DeepSeek 适配器拥有明确的多模态视觉理解模型 DeepSeek-V4-Flash-Vision-Exp。这两步并不重复：协议能够携带图片，不代表当前选择的模型一定接受图片；模型支持视觉，也不代表 Harness 已正确处理附件生命周期。
这也是升级后首先要检查的地方。Agent 的能力声明至少要回答：
- 当前模型是否声明
image输入，而不是只凭名称猜测； /goal、/plan、普通消息和子代理转发是否使用一致的图片表示；- 不支持图片的模型收到附件时，是明确报错、路由到视觉模型，还是调用经过批准的解析工具；
- 图片是否会进入会话持久化、分叉与重放；
- 图片中的密钥、用户数据和内部界面是否遵守同一套数据策略。
自动路由如果隐藏得太深，反而会让成本、隐私和结果来源不可解释。更好的 UI 应显示本轮由哪个模型或工具处理图片，并保留可检查的轨迹。
rc.2：真正棘手的是图片生命周期
v0.1.1-rc.2 优先通过 Files API 上传并复用图片，同时按模型要求自动缩放和转换格式。来源：DeepSeek Harness GitHub，截图于 2026 年 8 月 22 日。
rc.2 只有两条更新，却比“支持图片输入”更接近生产问题：DeepSeek 适配器优先使用 Files API 上传图片并复用已上传文件；预处理会根据模型要求自动缩放并转换格式。
为什么重要？如果每个 Turn 都把同一张图片重新编码进请求，长会话会快速膨胀。延迟、请求体大小和失败率都会随历史附件累积。Files API 把“图片内容”和“消息引用”分开，复用上传结果可以减少重复传输。自动缩放和格式转换则降低超出像素、字节或格式限制的概率。
但复用会引入新的生命周期问题：文件保存多久、由谁删除、跨 Thread 能否引用、分叉后是否仍可访问、提供商返回的文件 ID 能否跨账号使用。Release 没有给这些问题做通用保证，集成方需要根据实际 Files API 契约验证，不能把“可复用”理解为永久存储。
Claude Code 与 Codex 进入子代理体系
rc.8 允许将 Claude Code 和 Codex 作为 Profile Bundle 按需安装，并支持非交互权限模式与多个命名实例。这比“多接两个模型”更深：子代理带有自己的 Harness、工具行为、会话语义和权限机制。
多个命名实例允许为同一种子代理配置不同角色。例如 codex-reviewer 只读代码并输出审查意见，codex-builder 可以在隔离工作区修改文件。父 Agent 不需要把所有任务交给一个全能实例。
不过，名字不是安全边界。非交互权限模式只是减少等待人工点击，不等于允许跳过宿主策略。至少要固定每个实例的工作目录、网络范围、凭证、最长运行时间和允许的工具，并记录父任务为何委派、子任务返回了什么以及结果如何被父任务采用。
reportDelivery 在 rc.8 中会及时反馈并唤醒父任务，解决的是协作调度中的一个实际延迟：子代理已经完成，父任务却还在等待或轮询。它提升响应性，却不负责判断报告是否完整。父任务仍应对交付物做 Schema 或测试验证。
Windows、网关与会话：不显眼但更影响日常使用
持久 PowerShell 会话让连续工具调用保留当前目录、环境变量和 shell 状态。对 Windows 用户来说，这比每次启动新进程更接近真实终端，也减少重复初始化的时间。不过，状态持久化也意味着前一步留下的环境变化会影响后一步；复现问题时要记录会话起点，而不能只复制最后一条命令。
rc.8 还修复了两类容易让 Agent 会话“悄悄变质”的问题：
- 取消流式生成后，已经显示的回复前缀会被带入后续提问和分叉，避免 UI 所见与模型历史不一致；
- 自定义 OpenAI 兼容网关的请求格式差异和 reasoning content 回传得到修复，减少“接口兼容但语义丢失”。
“OpenAI-compatible” 从来不是严格一致的协议认证。自定义网关仍要测试图片字段、工具调用、流式事件、推理内容和错误结构，不能因为文本聊天成功一次就宣布兼容。
升级前先看这个：SQLite 格式不兼容
rc.8 Release 明确写出，SQLite 后端在改善读写、分叉性能和存储体积的同时，数据结构不兼容。这一条比大部分 UI 优化更重要。
升级开发环境前至少执行：
- 备份 DSH 数据目录和现有 SQLite 文件；
- 记录当前版本、Profile Bundle 与插件锁定版本；
- 用副本验证旧会话读取、搜索和分叉；
- 检查图片附件和 Files API 引用在恢复后是否仍有效；
- 准备回退二进制与数据的成对方案，不要只回退包版本。
DeepSeek Harness 的 README 仍明确提示 developer preview 会出现兼容性破坏。rc.8、rc.1、rc.2 也都被 GitHub 标为 Pre-release。适合快速实验，不适合在没有迁移演练、版本固定和回滚路径的情况下承载唯一生产副本。
一份多模态 Agent 验收清单
“上传图片后得到回答”只能证明 Happy Path。更有价值的验收矩阵应该覆盖：
| 场景 | 应验证什么 |
|---|---|
| 单张 UI 截图 | 文字、布局和视觉状态能否区分；输出是否引用可见证据 |
| 超大图片 | 是否缩放、格式是否变化、细节损失是否可接受 |
| 多轮复用同图 | 是否重复上传；延迟和请求体是否稳定 |
| 历史累计多图 | 是否触发载荷上限；压缩或淘汰策略是否透明 |
| 文本模型收到图片 | 明确拒绝、路由或工具降级是否符合策略 |
/goal 与 /plan | 图片约束是否贯穿后续执行，而不是首轮后消失 |
| 子代理转发 | 图片、来源、权限和任务目标是否一同传递 |
| 流式取消与分叉 | UI 已显示内容与恢复后的模型历史是否一致 |
| 敏感截图 | 日志、遥测、Files API 和子代理是否泄露数据 |
对截图修 Bug 这类任务，可以继续参考多模态 Coding Agent：截图修 Bug 什么时候真的有效？。它给出的核心原则同样适用于 DSH：视觉输入必须与复现条件、代码状态和验证结果绑定，不能把一张截图当完整 Bug 报告。
结论：多模态正在成为 Harness 能力，而不只是模型能力
从 rc.8 到 rc.2，DeepSeek Harness 展示了一条清晰路线：先让图片进入目标、计划与会话，再接入明确的视觉模型，最后处理上传复用、尺寸和格式。这个顺序很务实，因为生产中的多模态问题往往不是“模型看不懂”，而是附件没被正确传递、历史越来越重、路由不可解释或数据生命周期没有边界。
插件化让 DSH 可以把视觉模型、OCR 工具、子代理和业务 Skill 组合起来。它最大的机会也正来自这里：感知能力不必全部锁死在一个模型里。但组合越自由，能力声明、权限、追踪和版本兼容就越重要。
因此，这次更新值得试，但别只测试“能不能看图”。真正应该验证的是：图片如何进入、由谁处理、如何复用、怎样跨会话和子代理传递，以及失败时系统是否诚实地告诉你发生了什么。
FAQ
DeepSeek Harness 当前最新版是 rc.8 吗？
不是。截至 2026 年 8 月 22 日，GitHub Releases 列出的最新版本是 v0.1.1-rc.2。rc.8 是 8 月 19 日开启这轮多模态主线的重要版本。
纯文本模型能直接理解图片吗？
不能原生理解。插件可以先通过 OCR、布局或像素工具提取结构化证据，再让文本模型推理；这种工具层视觉适合部分文档和 UI 任务，但不等价于视觉模型。
Claude Code 和 Codex 子代理会自动安装吗？
不会。rc.8 将它们做成可按需安装的 Profile Bundle。启用后仍要配置实例、权限、工作空间和凭证边界。
rc.8 可以直接覆盖升级吗？
不建议无备份升级。官方说明 SQLite 数据结构不兼容，应先备份并用数据副本验证会话、分叉、图片引用和回退流程。
DSH 多模态现在适合生产吗？
官方仍将项目标记为 developer preview，相关 Releases 均为 Pre-release。可以用于受控实验和内部工具；生产使用需要固定版本、迁移演练、数据隔离、可观测性和回滚方案。
