DeepSeek Harness 对比 Claude Code：哪款编程 Agent 更适合你的技术栈？

DeepSeek Harness (dsh) 于 2026 年 8 月 13 日面世，其定位十分瞩目。VentureBeat 的发布头条将其称为“Claude Code 的开源劲敌”，并与 API 上的 DeepSeek V4-Pro 一同推出。一周后，该仓库的 Star 数已达到约 16.9 万（截至 8 月 20 日）。这无疑是一个强势的登场。

但 Star 数量并不能回答开发者真正关心的问题：我应该在 DeepSeek Harness 还是 Claude Code 上运行我的编程 Agent？这两款工具走的是不同的路线。前者是一个采用 MIT 协议的开发者预览版，围绕插件内核和本地 Web UI 构建；后者则是一款闭源、成熟且拥有深厚生态的产品，支持 skills、hooks、原生 MCP、子 Agent 以及五种运行媒介。

本次对比将从几个关键维度展开：开源协议、界面、模型自由度、价格、成熟度、可扩展性、权限以及 MCP。没有虚构的基准测试，没有凭感觉的性能宣称。只对比每款工具目前确实能做到的事情。如果你是 dsh 的新用户，可以先了解 DeepSeek Harness 是什么以及它是如何工作的，然后再回到这里。

这两款 Agent 都有一个共同点：它们都是基于 API 编写代码，而其表现完全取决于你提供给它们的规范。无论你选择哪款 Agent，Apifox 都能确保该规范经过测试且保持最新。更多相关内容见下文。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

快速对比

维度	DeepSeek Harness (dsh)	Claude Code
开源协议	MIT，GitHub 源码开源	闭源；“保留所有权利”，Anthropic 商业条款
发布时间	2026 年 8 月 13 日发布；开发者预览版	已正式商用（GA），成熟产品
稳定性	README 警告可能存在不兼容的变更	稳定的发布渠道，版本化设置
界面	本地 Web UI（运行于 `127.0.0.1:3080`），以及基于配置文件的 CLI 模式（含无头模式）	终端 CLI、VS Code、JetBrains、桌面版、网页端和移动端
支持模型	DeepSeek，以及目录服务商（Anthropic、OpenAI、Bedrock、Vertex、Azure）和任何兼容 OpenAI 的接口	仅限 Claude 模型（直接连接，或通过 Bedrock、Vertex、Foundry 连接）
价格	框架免费；根据所连接的 API 按 Token 计费	Claude Pro/Max 订阅，或通过控制台按用量进行 API 计费
可扩展性	一切皆插件（Cordis 内核）；社区 `dsh-plugin` 主题	插件、skills、hooks、子 Agent、Agent SDK
权限	在启用权限策略的情况下，通过 Web UI 弹出确认提示	六种已文档化的权限模式，细粒度的允许/拒绝规则
MCP	社区插件（dsh-mcp-manager），非核心功能	原生、一等公民支持

下面是详细对比，因为上述表格隐藏了大部分有趣的技术细节。

开源与闭源：MIT 协议究竟能给你带来什么

DeepSeek Harness 采用 MIT 许可协议，第三方依赖关系在 THIRD_PARTY_NOTICES.md 中进行跟踪。这可以说是最宽松的许可协议了。你可以阅读 agent 循环、进行 fork、打补丁、将其嵌入商业产品，并精确审计它通过网络发送的每一项内容。对于具有严格合规要求的团队，或者任何因厂商弃用其所依赖的功能而深受其害的人来说，这种透明度就是最核心的卖点。

这重要吗？这取决于你是谁。独立开发者主要关心工具是否好用。将 agent 嵌入内部工具的平台团队则非常在乎：MIT 协议意味着 dsh 可以成为基础设施的一部分，而 Claude Code 则始终只是一个需要订阅的产品。坦率地讲，开源只有在项目能持续维护的情况下才能带来回报，而 dsh 才诞生了 7 天。MIT 协议是对权利的承诺，而非对其生命周期的保证。

界面：本地 Web UI 对比随处可用

作为一款“CLI” agent，dsh 另辟蹊径。快速启动命令为 npx @deepseek-ai/dsh web，它会在 http://127.0.0.1:3080 启动一个本地 Web UI 并自动打开浏览器（可传入 --no-open 跳过自动打开）。你需要选择一个工作区，将其指向启动 dsh 的项目目录，然后就可以在浏览器中进行工作了。这是本地优先的：UI 服务直接由你的本地机器提供，而不是托管服务。

除了 Web UI 之外，dsh 的 CLI README 还介绍了基于配置文件的入口模式：dsh --profile <name> 会在 $DSH_HOME/profiles/<name> 下启动一个命名配置文件，而无头（headless）配置文件会运行一个持久化会话，输出最终答案后退出。dsh web 本身只是 web 配置文件的简写形式，而 dsh plugin 则通过转发至 pnpm 来管理配置文件的插件。因此，尽管编写脚本和自动化是可行的，但 Web UI 显然是主要的入口。

Claude Code 最初以终端优先起家，并在此基础上不断向外延伸。根据官方文档，它现在可以在终端运行，可以作为 VS Code 和 JetBrains 的扩展运行，作为独立的桌面版运行，以及在浏览器中访问 claude.ai/code 运行，甚至还支持移动端。会话可以在不同的界面之间流转。其无头模式也已经非常成熟：claude -p "prompt" 可以通过管道接入 CI、cron 定时任务和 shell 流水线。

如果你只需要在单台机器上的单个项目里工作，dsh 的本地 Web UI 提供了愉悦且开箱即用的体验。但如果你需要在 IDE、终端、CI 以及手机之间来回切换，Claude Code 目前所覆盖的场景维度则完全处于另一个量级。

模型自由度：最尖锐的理念分歧

在这个维度上，这两款工具在“代码 agent 应该是什么样”这一问题上产生了真正的分歧。

dsh 在设计上是与模型无关的（model-agnostic）。它的 provider docs 提供了针对 Anthropic、OpenAI、Bedrock、Vertex 和 Azure 的内置提供商，并允许你在 $DSH_HOME/settings.yaml 中注册任何兼容 OpenAI 的接口：设置 apiKeyEnv、api: openai-completions、baseURL 和模型列表，测试套件就会像对待其他任何后端一样对待它。API 密钥保存在独立的 .credentials.yaml 中，因此你的配置文件可以保持共享状态。这意味着 dsh 可以通过本地服务端驱动 DeepSeek 自己的模型、竞争对手实验室的 API，或者在你自己 GPU 上运行的量化模型。我们在如何运行 DeepSeek Harness 中的任何模型中详细介绍了完整的设置方法。

Claude Code 运行的是 Claude 模型。仅此而已。你可以通过 Amazon Bedrock、Google Cloud 的 Agent 平台或 Microsoft Foundry 来路由推理，而不是使用 Anthropic 的 API，但这只是计费和基础设施层面的选择；模型本身依然是 Claude。Anthropic 的立场是，测试套件和模型是协同开发的，紧密集成优于灵活性。

两种立场都没有错。当价格波动或别处发布了更好的模型时，模型绑定（lock-in）会让人感到难受。而当厂商将 Agent 循环与模型进行联合微调时，紧密耦合就会带来回报。选择哪一个取决于你有多看重“退路”（选择权）。

价格：按 Token 计费 vs 订阅制

dsh 测试套件本身是免费的。你只需要为你所连接的任何 API 的推理付费。如果使用的是 DeepSeek 自身的 API，你需要支付 DeepSeek 的按 Token 费率；根据 VentureBeat 的发布报道，与 dsh 同日发布的 V4-Pro 的价格高于其前代产品，请注意这一点。如果你选择这条路线，我们关于 DeepSeek V4-Pro-0813 API 的指南涵盖了模型 ID 和请求格式。按 Token 计费非常透明，并且在你不写代码时费用归零，但在重度使用 Agent 的会话中，可能会不可预测地消耗大量 Token，且没有封顶费用。

Claude Code 则相反。大多数用户是通过订阅 Claude Pro（每月 20 美元）或 Max（每月 100 或 200 美元）来运行它，对于更倾向于按量计费的团队，也可以选择通过 Claude Console 进行基于使用量的 API 计费。订阅制为你提供了一个可预测的账单和使用限制，而不是像电表一样实时计量，而这些限制一直是一个热门话题：Anthropic 在 2026 年 7 月将每周限制提高了 50%，我们在关于 Claude Code 周限制提升的报道中对此进行了详细剖析。

粗略规则：轻度或突发性使用往往更适合按 Token 计费；日常重度使用则更适合固定费率的订阅制。此外，由于 dsh 也可以通过其内置的提供商指向 Anthropic 的 API，因此定价问题在某种程度上与测试套件的选择是相互独立的。

成熟度：诞生七天 vs 整个生态系统

这里需要坦率地直言。DeepSeek Harness 目前还是开发者预览版，其自身的 README 中也逐字写道：“THERE WILL BE COMPATIBILITY-BREAKING CHANGES（将会存在不兼容的变更）。”这不是一种托词，而是一个预告。你今天编写的配置下个月可能就无法解析了。插件可能需要重写。文档仍有缺失；引用的几个页面内容单薄或处于变动之中。如果你现在就基于 dsh 构建工作流，你就必须做好在频繁变动中维护它们的准备。

Claude Code 自 2025 年初以来就已交由开发者使用，其在生产环境下的打磨体现在各个方面：CLAUDE.md 项目记忆（project memory）、自动内存、用于打包工作流的 skills、在 agent 动作前后运行 shell 命令的 hooks、带有协调主 agent 的子 agent、用于构建自定义 agent 的 Agent SDK、GitHub Actions 和 GitLab CI/CD 集成，以及定时例行程序。这些功能早已不再新奇；它们已具备完善的文档、版本控制，并处于日常使用中。我们在 Claude Code vs Codex CLI 中将其与另一个成熟的竞争对手进行了对比，其生态系统的深度在当时也是决定性的。

反之，dsh 的发展势头非常迅猛。在一周内（截至 8 月 20 日）获得了大约 16.9 万个 star 和 1.81 万个 fork，这意味着社区蕴含着巨大的活力，而社区生态系统能够快速填补功能上的差距。但就目前而言，“预览版”与“正式产品”是对两者最准确的定位。

可扩展性：插件内核 vs 插件生态

这两款工具都是可扩展的。但它们的扩展性所处的位置有所不同。

在 dsh 中，插件不是一个附加层，而是其架构本身。该框架基于 Cordis 构建，Cordis 是一个插件内核，其设计在论文《A Programming Paradigm for Spatiotemporal Composability》中有所描述。模型适配器、工具注册表、会话日志，甚至连 agent 循环本身都是可替换的插件。如果你不喜欢 agent 循环重试失败的工具调用的方式，你可以直接更换该循环。可以通过 GitHub 的 dsh-plugin 主题发现社区插件，而且非官方项目（桌面端包装器、上下文管理器、视觉路由）也已经在不断增加。

Claude Code 暴露的是扩展点而非内部结构：通过插件、skills、hooks、MCP 服务端和子 agent，你可以在定义明确的衔接点自定义行为，但其核心循环仍属于 Anthropic。对于大多数团队来说，这已经足够了，而且安全护栏的存在意味着升级很少会破坏你的自定义配置。对于想要重构引擎的折腾家来说，dsh 是这两者中唯一提供“扳手”的那一个。

权限：策略提示 vs 六种模式

一个会修改文件并运行命令的 agent 需要有刹车机制。

根据 dsh 的用户指南，其 Web UI 在执行“在当前激活的权限策略下需要审批”的操作前会进行询问。这是目前公开文档中已验证的全部内容；策略级别及其确切语义尚未在指南索引中详细说明，这本身就是预览阶段文档的典型特征。

Claude Code 的权限系统文档记录得详尽到近乎繁琐：包含六种模式（default、acceptEdits、plan、auto、dontAsk、bypassPermissions）、针对每个工具和命令的细粒度允许/拒绝规则、工作目录边界，以及管理员可以在组织范围内强制执行的托管策略。plan 模式允许 Agent 在不编辑的情况下进行探索；auto 模式使用后台分类器评估操作，而不是提示你确认；bypassPermissions 则适用于沙箱容器。

如果你对权限细粒度有要求（受监管的代码库、初级开发人员较多的团队、CI 自主性），Claude Code 目前在文档和控制方面明显处于领先地位。

MCP：原生 vs 社区插件

Model Context Protocol（模型上下文协议）是编程 Agent 连接外部系统（如数据库、工单追踪器、接口定义/规范）的方式。Claude Code 原生支持 MCP；连接服务端是官方文档中支持的一等公民流程，且 MCP 工具也适用于与其他功能相同的权限规则。

在 dsh 中，MCP 支持目前并不是其核心的一部分。目前存在的是一个社区插件 dsh-mcp-manager，它为 MCP 添加了一个设置（Settings）页面，支持远程 HTTP 和本地 stdio 服务端，处理 OAuth 或静态 Token，并将工具注册为 mcp__<name>__*，支持针对每个项目的服务端配置。它能正常工作，但由于是社区维护而非官方维护，因此继承了预览版本迭代动荡的风险。鉴于 dsh 插件优先的架构，未来推出官方 MCP 支持也并不令人意外，只是目前还没有。

这在处理 API 工作时尤为重要。Apifox MCP Server 让编程 Agent 可以直接访问你团队真实的接口定义/规范，从而根据真实的契约生成客户端代码，而不是凭空臆造字段名称。在 Claude Code 中，这种连接是原生的。而在 dsh 中，它需要通过社区插件进行路由。无论哪种方式，能够读取你已测试规范的 Agent 都能编写出更好的 API 代码。你可以下载 Apifox 并在两个 Agent 工作的同一个项目上运行其 MCP 服务端。将其与 CI 中的 Apifox CLI 回归测试结合使用，无论哪个 Agent 在你的评估中胜出，你都拥有同样的安全保障。

你应该选择哪一个？

这里没有唯一的赢家，因为这两款工具在不同的成熟度阶段做出了不同的押注。

出现以下情况，请选择 DeepSeek Harness：

你需要源代码。对于某些团队来说，MIT 许可、可审计性和可分叉性是硬性要求，而 dsh 是两者中唯一提供这些特性的工具。
你不希望被单一模型绑定。使用一个框架驱动 DeepSeek、兼容 OpenAI 的本地模型以及主流的云端服务商，是 dsh 真正的架构优势。
你是一个极客（喜欢折腾的人）。Cordis“一切皆插件”的设计，非常适合那些想要重塑 Agent 本身的人。
你能够忍受软件崩溃或不可用。README 中的警告非常明确，你应当予以重视。

出现以下情况，请选择 Claude Code：

你想要一个成熟的成品。五个交互面、完善的文档，以及由 skills、hooks、subagents 和原生 MCP 构成的生态系统，而 dsh 目前还没有时间去发展这些。
你需要企业级控制。文档化的权限模式、托管策略和云服务商路由都是已经发布的功能，而不是路线图上的规划。
可预测的计费方式非常重要。Pro 或 Max 订阅能够限制你的费用上限，而按 token 计费则无法做到这一点。
你乐于使用 Claude 模型，因为规则就是如此。

一个务实的折中方案：许多开发者会同时运行这两者一段时间。尝试 dsh 毫无成本（运行 npx @deepseek-ai/dsh web 即可体验），而且订阅 Claude Code 也并不妨碍你进行实验。无论你最终选择哪一个，都可以通过 Apifox 来确保 API 层的可靠性：只需一份经过测试的接口规范，便可通过 MCP 提供给任意一个 agent，并在 agent 每次修改代码后通过 CLI 运行回归测试进行验证。

FAQ

相比 Claude Code，DeepSeek Harness 真的开源吗？

DeepSeek Harness 可以使用 Claude 模型吗？

可以。dsh 内置了针对 Anthropic、OpenAI、Bedrock、Vertex 和 Azure 的提供商支持，并允许通过 settings.yaml 配置自定义的 OpenAI 兼容接口。反之则不然：Claude Code 仅支持运行 Claude 模型，无论是直接来自 Anthropic，还是通过 Bedrock、Vertex 或 Foundry 接入。

DeepSeek Harness 足够稳定以用于日常工作吗？

目前它还处于开发者预览阶段，其 README 用大写字母警告称后续会引入破坏兼容性的变更。虽然它完全可以用于实际工作，但你需要做好应对配置和插件频繁变动的准备。对于你无法承受重建成本的工作流，Claude Code 是更安全的选择。

这两个 agent 都能与 Apifox 配合使用吗？

是的。Apifox 的 MCP 服务端可以向任何支持 MCP 的 agent 暴露你的接口规范：在 Claude Code 中是原生支持，在 dsh 中则可以通过社区的 dsh-mcp-manager 插件来实现。Apifox CLI 还可以在任一 agent 的终端循环中运行脚本化的回归测试；我们在《在 DeepSeek Harness 中使用 Apifox CLI》中详细介绍了 dsh 的配置流程。