搜索
← 全部笔记技术

技术

DeepSeek Harness 的独特定位：它能解决 Claude Code 和 Codex 解决不了的什么？

从插件化运行时、模型兼容性与扩展边界出发，分析 DeepSeek Harness 相对 Claude Code 和 Codex 的独特位置。

约 10 分钟阅读
#DeepSeek#AI#Agent#Harness#开源

2026 年 8 月 13 日，DeepSeek 在 V4-Pro 模型转正的同一天开源了 DeepSeek Harness（命令行 dsh），MIT 协议，开发者预览。第一眼这像是又一个"DeepSeek 版 Claude Code"，但官方把它定义为面向"全球 agent harness 开发者"的预览版——给 harness 开发者用的底座，而不只是给程序员的编程工具。定位差异决定了本文的答案：确实存在几类 Claude Code 和 Codex 结构上做不到的场景，但日常编程的大部分需求，dsh 并不会从这两家手里抢走。

harness 为什么重要

DeepSeek 的公式是 Agent = Model + Harness：模型负责推理决策，harness 是包在模型外面的执行环境——模型能看到什么上下文、能调用哪些工具、出错如何重试、何时判定完成，都由它决定。

这不是宣传话术。社区开发者 sentdex 做过公开对照实验：同一份 DeepSeek V4 Flash 权重，在 Terminal-Bench v2.1（89 道真实终端任务）上，用他自制的极简 harness 只解出 44 题（49.4%）；换成功能完整的社区 harness，解出 64 题（71.9%）。同样的模型和基准，仅更换 harness 就多 20 题；代价是强 harness 每解一题约消耗 5.3 倍 token。Composio 的横向测试也显示，同一模型跑在 Claude Code、Codex、OpenCode 等不同 harness 里，成功率、成本、速度各自主场。（两组数据经第三方深度评测转述，出处见文末。）

比较两个模型时如果底层 harness 不同，比的其实是两套厨房，不只是两位厨师。这解释了开源权重厂商 DeepSeek 为什么必须做 harness：模型能力不会自动变成智能体能力，转化靠这层脚手架。V4-Pro 官方基准 Terminal Bench 2.1 得分 87.9，正是在 Harness 极简模式下测出的。

独特定位：把整个运行时变成插件

DeepSeek Harness 的核心主张只有一句：Everything is a plugin。模型、工具、技能、会话、沙箱、存储、主循环、调度乃至 UI，全部是 Cordis 插件，可混搭、替换、扩展，且都在配置层完成，不碰源码。

graph TD
  K[Cordis 内核<br/>插件挂载 / 卸载 / 依赖管理] --> P[插件层]
  P --> M[模型] & T[工具 / 技能] & S[会话 / 沙箱 / 存储] & L[主循环 / 调度 / UI]
  M & T & S & L --> C[配置组合] --> S1[Standard] & S2[Code] & S3[Minimal] & S4[Creator]

Cordis 内核只管插件的挂载、卸载与依赖，设计来自一篇提出"时空可组合性"编程范式的配套论文：插件卸载时自动回滚全部副作用，插件间依赖自动协调。官方的立场很明确——不存在需要打补丁的特权核心，扩展就是在别的插件旁边再挂一个插件。这正是它与 Claude Code、Codex 的根本分野：

维度 DeepSeek Harness Claude Code Codex
开放程度 MIT 全源码开源 闭源客户端 CLI 开源（Apache-2.0）、云服务闭源
模型 不绑定：DeepSeek、Anthropic、OpenAI、Bedrock、Vertex、Azure 及任意 OpenAI 兼容端点 仅 Claude 系列 仅 GPT 系列
扩展边界 整个运行时（主循环、沙箱、会话、UI 均可换） 工具 / 技能 / hook 层 工具 / MCP 层
形态 本地 Web UI + CLI + Python SDK 终端 CLI 终端 CLI + 云端沙箱

Claude Code 和 Codex 是成品：可以接 MCP、写 skills、配 hooks，但主循环、上下文策略、会话模型由厂商封装，模型也只能用各家的。dsh 只提供一个薄内核加一套可组合部件，四种模式只是四套插件组合：Standard 是完整编程智能体；Code 模式让模型写一段 TypeScript 把多轮工具调用编排成一次执行；Minimal 只留 bash 和文件编辑器，专测模型本体的智能体能力；Creator 允许检查运行时、试验插件、定制模式。官方还强调全程可追溯：模型看到的一切进入同一份仅追加会话日志，随时分叉、检索、回放。

必须用 dsh 才能解决的场景

诚实的答案是：严格"非 dsh 不可"的场景比宣传文章里少，但有几类是结构性的。

场景一：主力模型不是 Anthropic 或 OpenAI 家的。 Claude Code 只接 Claude，Codex 只接 GPT，这是产品级绑定。团队若要在自托管开源权重、私有化模型或内部网关上跑智能体编程，两者结构上无法担任主 harness。dsh 的模型目录覆盖 DeepSeek、Anthropic、OpenAI、Bedrock、Vertex、Azure，还能添加任意 OpenAI 兼容端点（官方文档已核实；第三方实测称也可接 Ollama 等本地模型，此点需要验证）。

场景二：需要改造运行时本身。 想做自己的 agent 产品或 harness 研究——自定义主循环、调度策略、沙箱、会话存储，甚至换掉 UI——封闭主循环的 Claude Code 和 Codex 无从谈起，只能从零自研。dsh 提供现成的 MIT 底座，商用二次开发也被协议允许。这就是它"给 harness 开发者"定位对应的场景。

场景三：跨厂商智能体编排。 dsh 可以把别的编程智能体当子代理调度：Codex 已进入官方 provider 目录（OAuth 认证，官方文档可查），第三方实测还报告 Claude Code 与 Codex 可被整体接为子代理（默认关闭）。Claude Code 也能派生子代理，但那是 Claude 的分身；让互为竞品的智能体在同一编排层下统一干活，两家都给不了。

场景四：智能体行为的全链路审计与回放。 仅追加事件流记录每一次上下文注入和子代理调度，支持任意节点 fork 与 replay。对行为研究、事故复盘、合规审计这是硬需求；Claude Code 支持会话续接，但没有同等级的事件流分叉与回放。

场景五：受控测量模型的智能体能力。 Minimal 模式提供统一口径的双工具最小环境，DeepSeek 官方基准即在此测出，做模型选型评测时是现成的实验协议。

两点诚实说明。其一，这些场景多数是"Claude Code/Codex 做不到"，而非"只有 dsh 做得到"——OpenCode 等开源 harness 能覆盖场景一的一部分；但运行时级插件化、官方维护、配套 V4 模型三者结合，目前只有 dsh。其二，若需求只是"在 Claude Code 里用 DeepSeek 模型"，根本不需要 dsh：DeepSeek 官方提供 Anthropic 兼容端点，并给出在 Claude Code、Codex、OpenCode 等第三方 harness 中运行 DeepSeek 模型的配置指南。这条反向路线恰好说明，DeepSeek 并不打算把用户锁进自家 harness。

现在该不该用

日常编程，Claude Code 和 Codex 仍是更稳的选择：产品更成熟、一方模型更强、生态更厚。dsh 还是 v0.1 预览，官方明示会有破坏性变更，核心插件与 API 仍在快速演化，把它固定到生产系统并不明智。

但对要为自己产品选 agent 底座的团队、代码不能出内网且必须用自托管模型的企业、需要可控变量实验与可回放运行记录的研究者、想统一调度多家智能体的平台方，DeepSeek Harness 是这些方向上目前唯一的完整开源答案。

这次发布更深的意义在于竞争维度的切换：智能体编程的比拼正从模型权重转向 harness 与基础设施。权重开源、harness 以 MIT 开源，第一次出现了厂商提供的、从模型到运行时的完整开放技术栈。它能走多远，取决于插件生态的长势和破坏性变更何时稳定。

来源