DeepSeek Harness 又迎来了一次更新。
8 月 20 日，项目发布 v0.1.0-rc.8 预发布版本，距离上一个 RC 版本仅过去两天。这次更新涉及多模态支持、子代理、Windows 终端体验、工具调用效率以及底层性能等多个方面。
单看更新日志，这似乎只是一次常规迭代。
但最近 DeepSeek Harness 在开发者群体中受到越来越多关注，背后其实有一个更值得讨论的问题：决定 Agent 实际体验的，可能不只是模型本身，模型外面的 Harness 同样重要。
这也是 rc.8 值得仔细看的原因。
如果你之前没有接触过这个项目，可以先查看 DeepSeek Harness 官方介绍。
DeepSeek Harness 不只是一个编程界面
DeepSeek 对 Harness 的定义很直接：
Agent = Model + Harness
模型负责推理和生成，而 Harness 负责模型之外的工程能力，包括工具调用、终端、任务规划、权限、会话、存储、子代理以及任务执行等。
它还有一个很核心的设计理念：
Everything is a Plugin。
换句话说，DeepSeek Harness 更像一个模块化的 Agent 运行框架，而不是一个功能固定的 AI 编程助手。
这也是为什么海外开发者经常把它和 Claude Code、Codex、OpenCode 等工具放在一起讨论。
大家关心的问题已经不只是：
哪个模型更强？
而是进一步变成：
什么样的运行环境，能让模型发挥得更好？
从早期社区反馈来看，同一个 DeepSeek 模型放在不同 Harness 中使用，实际体验确实可能出现明显差异。
多模态能力继续补强
rc.8 最值得关注的变化之一，是多模态支持进一步完善。
DeepSeek 模型适配器现在可以配置原生图片请求，/goal、/plan 等命令支持图文混合输入，@ 菜单也能更方便地引用文件和会话。
同时，这次更新还修复了大尺寸图片，以及长对话中累计图片数据过多时可能导致请求失败的问题。
对于需要处理截图、流程图、UI 设计稿或其他视觉信息的 Agent 工作流来说，这些改动都很实用。
不过这里需要特别区分一点：
这并不意味着 DeepSeek V4 本身突然变成了原生视觉模型。
目前 DeepSeek 官方 API 文档仍将自身的 chat-completions 路由描述为文本输入。rc.8 更准确的意义，是补齐了 Harness 层面的多模态处理链路，尤其适合连接本身支持图片输入的模型或第三方 Provider。
这点很重要，因为 DeepSeek Harness 并不只能运行 DeepSeek 模型，它也支持 OpenAI、Anthropic 以及兼容 OpenAI API 的第三方服务。
也就是说，Harness 本身正在向多模态运行框架发展，而底层具体使用什么模型，可以根据任务需要切换。
Claude Code 和 Codex 也能成为子代理
rc.8 另一个很有意思的变化，是 DeepSeek Harness 对其他编程 Agent 的处理方式。
现在，Claude Code 和 Codex 都可以通过 Profile Bundle 安装，并作为子代理使用。
Codex 还增加了非交互权限模式，以及多个命名实例的支持。
这让多 Agent 协作变得更容易实现。比如主 Agent 负责任务规划和整体调度，同时让多个子代理分别处理代码审查、功能开发或不同仓库任务。
新的 reportDelivery 机制也让这种协作更顺畅。子代理完成任务后，可以主动把结果返回给父任务并唤醒它，不需要父任务反复查询执行状态。
这背后其实透露出一个很有意思的方向：
Claude Code 和 Codex 不一定只是 DeepSeek Harness 的竞争对手，它们也可以成为 Harness 内部可调度的一部分。
当然，目前多 Agent 工作流仍处于比较早期的阶段。社区里已经有人认可它的架构方向，也有人反馈子代理还存在稳定性和配置体验方面的问题。考虑到 DeepSeek Harness 目前仍是 Developer Preview，这并不意外。
海外开发者很关心 Token 成本
最近开发者讨论里出现频率很高的另一个话题，是 Token 消耗和缓存命中率。
Agent 编程天然会消耗大量上下文。
它可能反复读取代码仓库、工具定义、历史对话、任务计划以及工具返回结果。如果 Harness 对上下文管理得不够好，即使底层模型价格很便宜，最终一次任务的成本也可能并不低。
一些早期用户反馈称，在较长的 DeepSeek Harness 编程会话里，他们能看到 90% 以上的缓存命中率。
这些数据目前主要来自个人体验，并不是严格控制变量的 Benchmark，因此不适合直接当成官方性能指标。但它确实提出了一个很实际的问题：
比较 DeepSeek Harness、Claude Code、Codex 或 OpenCode 时，只看模型单价并不够。
更有参考价值的比较方式应该是，在同一个代码仓库、同一个任务、同一个模型下，对比：
- 总输入 Token
- 缓存与非缓存 Token
- 输出 Token
- 完成时间
- 最终任务质量
一个价格便宜的模型，如果 Agent 不断重复发送无效上下文，最终成本一样可能很高。
它比 Claude Code 或 Codex 更好吗？
目前还没有一个统一答案。
目前社区反馈比较分化。
有些开发者认为，官方 Harness 能让 DeepSeek 模型的表现更稳定；也有人仍然更喜欢 Claude Code 或 Codex，因为它们在日常编程中的流程成熟度和稳定性更高。
现阶段，两类产品的定位其实并不完全相同。
Claude Code 和 Codex 更接近成熟的 AI 编程产品。
而 DeepSeek Harness 想做得更底层一些：它更像一个 可编程的 Agent Runtime，模型、工具、子代理、权限和工作流都可以自由组合和扩展。
它提供了更多灵活性，但灵活性也意味着更高的配置成本，以及更多可能出现问题的环节。
Windows 体验终于有所改善
rc.8 也专门改善了 Windows 使用体验。
DeepSeek Harness 现在支持持久化 PowerShell 会话，并且在 Minimal 预设中默认开启。
过去，如果 Agent 每执行一次命令都丢失 Shell 状态，Windows 开发者就可能反复恢复工作目录、环境变量、虚拟环境或本地服务。
支持持久会话之后，终端体验会更接近日常真实开发环境。
不过，从社区反馈来看，Windows 目前依然存在一些边缘问题，所以这次更新更适合理解为“明显改善”，而不是“Windows 已经完全没有问题”。
一些不起眼，但很实用的修复
rc.8 还包含不少日常体验上的优化。
例如，当用户中断流式输出时，已经生成的内容现在可以继续保留，并作为后续提问或分叉会话的上下文。
OpenAI 兼容网关的适配也有所增强，对于使用自定义模型服务或企业内部 Gateway 的开发者来说会更友好。
web_search 工具现在支持并发查询，多关键词检索的等待时间会缩短。
本地运行 dsh web 时，系统也可以自动打开浏览器，省去了手动输入地址的步骤。
这些变化单独看都不算“大功能”，但对于长时间使用 Agent 的开发者来说，会直接影响整体流畅度。
升级前最好先备份
rc.8 还有一个非常值得注意的变化。
DeepSeek 对 SQLite 后端进行了优化，提高了读写和会话分叉效率，同时降低存储占用。
但与此同时，新的存储格式与旧版本并不兼容。
升级后系统会重新建立索引，旧工作区数据也可能无法直接迁移。
如果你已经使用 DeepSeek Harness 保存了重要会话或工作区数据，升级之前最好先做好备份。
这也再次提醒大家：DeepSeek Harness 目前仍然属于 Developer Preview，预发布阶段出现不兼容改动是正常情况，不建议完全按照稳定生产软件的标准来使用。
DeepSeek 正在把 Harness 当成独立产品
这次更新中，DeepSeek 还进一步明确了 Harness 的品牌使用规范。
开发者可以使用 “built on DeepSeek Harness” 或 “compatible with DeepSeek Harness” 来描述项目和 Harness 的关系，但未经授权的项目不应直接把完整的 DeepSeek Harness 商标放进产品名称。
官方更推荐生态项目使用 DSH 这一缩写。
这看起来像一个比较小的品牌规范变化，但实际上也能说明 DeepSeek 对 Harness 的定位正在发生变化。
它不再只是 DeepSeek 模型旁边的一个开源工具。
DeepSeek 正在逐渐把它当成一个独立的平台来运营。
为什么 rc.8 值得关注？
rc.8 真正值得关注的，不只是 PowerShell、多模态或子代理中的某一个功能。
更重要的是这些功能共同指向的方向。
DeepSeek 正在把“模型之外的运行层”当成一个独立产品来建设。
模型可以替换，工具可以增加，Claude Code 和 Codex 可以作为子代理，视觉内容可以进入同一套任务流程，会话也可以独立分叉、回放和管理。
当然，它目前仍然有不少明显的早期产品问题，包括兼容性、多 Agent 稳定性、Token 消耗，以及预发布版本升级带来的数据风险。
所以，现阶段并不适合所有开发者立刻把现有 Claude Code 或 Codex 工作流全部迁移过去。
但 DeepSeek Harness 已经越来越值得测试。
因为随着 Agent 系统越来越复杂，未来最重要的问题可能不再只是：
你正在使用哪个模型？
而会变成：
这个模型外面，到底运行着什么？