两个月、12293 个提交，DeepSeek Harness 开源的不是另一个 Claude Code

发表于
从 6 月 10 日首次提交到开发者预览，DeepSeek Harness 用 19 位贡献者和 12293 个提交搭出一套“一切皆插件”的 Agent 运行时；真正值得关注的是 Harness 层被打开，而不是又多了一个聊天式编程界面。

从 6 月 10 日第一笔提交，到 8 月 13 日晚正式宣布开源，DeepSeek Harness 只用了 64 天。

截至 8 月 14 日上午，GitHub 仓库首页显示 19 位贡献者、12,293 个提交。这个数字很容易把讨论带向“DeepSeek 两个月写了多少代码”，或者把它直接叫作又一个 Claude Code。

我的判断是：12,293 个提交首先说明这套系统经历了极高频的内部迭代，不等于 12,293 个独立功能。DeepSeek Harness 真正重要的地方，是把模型之外那层决定 Agent 如何工作、如何调用工具、如何保存状态、如何被约束的运行时公开了。

这不是单纯多了一个 Coding Agent 客户端，而是模型公司开始争夺 Agent 的“操作系统层”。

64 天和 12,293 个提交，应该怎样读

仓库的首次提交发生在 2026 年 6 月 10 日 22:58，没有父提交，只加入了 5 个基础文件。最初的 AGENTS.md 还把项目描述为承载 DeepSeek Code 的 monorepo，并明确写出底层基于 Cordis。

8 月 13 日 21:02，DeepSeek 在官方 X 账号宣布 DeepSeek Harness v0.1 进入 Developer Preview，完整代码以 MIT License 开放。到了 8 月 14 日上午，仓库已经显示 12,293 个提交。

GitHub Contributors 页面还给出了更细的节奏：

  • 6 月 7 日所在周只有 37 个提交；
  • 7 月 12 日所在周上升到 1,422 个；
  • 7 月 19 日所在周是 2,169 个；
  • 7 月 26 日所在周达到 3,646 个峰值；
  • 提交最多的一位贡献者累计 5,235 个提交。

GitHub 甚至因为提交数超过 10,000，停止在 Contributors 图表中展示增删行数。

但这里必须加一个边界：commit 不是功能、不是 Pull Request，也不是质量单位。 仓库历史里同时存在功能开发、合并提交、文档同步、命名重构、测试调整、依赖与 vendored 源码维护，以及开源前密集的发布准备。把 12,293 直接翻译成“做了 12,293 件事”，和把代码行数当作生产力一样不可靠。

这个数字真正能证明的是迭代方式：少量贡献者把变更拆得很细，并在 7 月下旬进入极高频的集成阶段。它能说明工程节奏，不能替代架构审查、安全测试和真实任务评测。

DeepSeek 开源的是模型外面的那一层

DeepSeek 官方页面用一句话定义 Harness：

Agent = Model + Harness

模型负责理解和推理，Harness 负责让模型看见环境、调用工具、维持状态，并把一次回答变成可以持续工作的过程。

传统 Coding Agent 往往把这些能力包在一个产品里。用户可以更换模型或添加少量工具，却很难替换会话存储、Agent Loop、权限策略和 UI。DeepSeek Harness 采用了更激进的设计：Everything is a Plugin，一切皆插件。

它底层使用 Cordis。Cordis 内核只处理插件的加载、卸载和依赖关系，不承载某个不可替换的 Agent 核心。按照官方架构文档，下面这些部分都可以从配置层组合或替换：

Agent 能力 在 DeepSeek Harness 中的角色 替换后可能改变什么
模型适配器 把不同模型协议接入统一运行时 模型、推理协议、流式响应
工具注册表 提供工具描述与受控执行管线 Shell、文件、检索、MCP 等能力
Session Log 保存仅追加的会话事件 恢复、分叉、检索、回放和审计
Agent Loop 驱动模型请求、工具调用和下一步 任务循环、错误恢复、停止条件
文件系统与沙箱 定义 Agent 能访问和执行的环境 本机、远程沙箱、权限隔离
调度与子 Agent 组织并行或委派任务 工作拆分、后台任务、协作方式
UI 与 Profile 组合具体产品形态 Web、Headless 或自定义工作台

这套设计的关键不是“插件数量多”，而是没有一个必须修改的特权核心。要接入新的模型、工具或沙箱，目标不是给主循环不断增加条件分支，而是在现有能力接缝旁挂载新的插件。

如果它能保持这一边界，DeepSeek Harness 更像一个 Agent 运行时发行版，而不是一款只能按官方方式使用的编程助手。

“每次运行都有迹可循”比界面更重要

在所有插件中，最值得关注的不是模型适配器，而是 Session Log。

DeepSeek Harness 使用仅追加的事件日志。系统提示词、模型可见上下文、模型输出、工具调用与结果、子 Agent 调度和上下文注入都会写入同一条事件流。架构文档把规则写得很直接：Model-visible means logged，模型能看到的内容必须可以从日志重建。

因此，恢复会话、创建分叉、生成 transcript、回放过程、统计 telemetry 和渲染 Web UI，不需要分别维护几套状态，而是从同一份日志派生。

这解决了 Agent 系统一个很现实的问题：失败通常不是出现在最终答案，而是发生在中间某一步。模型为什么看到了这段上下文？哪个工具返回了错误结果？权限批准发生在第几轮？如果运行过程无法重建，团队就只能根据最后一句“任务已完成”猜测。

不过，可观测性也有代价。系统提示词、工具结果、文件内容和上下文注入都可能包含敏感信息。仅追加日志让审计更可靠，也扩大了需要定义保存期限、访问权限、脱敏和删除流程的数据面。能回放不是天然安全，日志本身就是需要保护的生产数据。

四种模式，其实是四套 Harness 实验条件

官方预览版提供四种模式：

模式 工具和执行方式 适合观察什么
标准模式 文件、Shell、检索、Skills、计划、子 Agent 等完整能力 日常 Coding Agent 工作流
PTC 模式 让模型生成 TypeScript 程序，组合多轮工具调用 减少工具往返并测试程序化编排
极简模式 只保留 Bash 和 str_replace_editor 在统一、最小 Harness 下比较模型
创造模式 增加运行时检查、插件实验与 Preset 创作能力 组合新的 Agent 形态

这里最容易被低估的是极简模式。公开模型评测经常把“模型能力”和“Agent Harness 能力”混在一起。只提供 Bash 与文件编辑工具，可以把更多变量固定下来；标准模式则更接近真实生产，但结果也会受到工具、Skills、子 Agent 和权限策略影响。

这正好延续了我在 Coding Agent 评测文章 中的判断：榜单测量的从来不只是模型，而是模型、Harness、工具、指令、环境和评分器组成的完整系统。

DeepSeek 把几套运行模式放在同一框架里，意味着开发者可以更清楚地回答一个问题：这次成功究竟来自模型变强，还是 Harness 给了它更多能力？

它并不要求你只用 DeepSeek 模型

虽然项目叫 DeepSeek Harness，但模型适配层不是 DeepSeek 专用接口。

官方模型配置指南列出了 DeepSeek、Anthropic、OpenAI、Bedrock、Vertex、Azure 与 Codex 等认证路径，也允许配置企业网关、自建服务和其他 OpenAI 兼容端点。模型切换会在下一次请求生效，不需要重启服务。

快速体验只需要安装 Node.js，然后执行：

1
npx @deepseek-ai/dsh web

Web UI 默认启动在 http://127.0.0.1:3080。选择工作区、配置模型后，Agent 可以读取和修改文件、运行命令、委派任务和维护计划；遇到权限策略要求审批的操作，Web UI 会先询问用户。

这进一步说明 DeepSeek 争夺的不是某个模型入口，而是模型进入真实工作环境之后的控制层。如果开发者能在同一 Harness 下替换模型、工具和沙箱，模型提供方之间的比较会更透明，团队也更容易建立自己的路由与回归评测。

MIT 开源，不等于已经进入稳定期

“正式开源”和“正式可用于生产”是两件事。

仓库 README 明确标记为 Developer Preview，并用大写警告后续会出现破坏兼容性的改动。8 月 14 日查询时，GitHub 仍显示 0 个 Tags；开源前最后的发布准备提交使用的是 0.1.0-rc.5。这不是语义稳定、升级路径清楚的长期支持版本。

开源治理也还没有完全开放。CONTRIBUTING.md写明，项目当前暂不接受外部 Pull Request。社区可以在 Discussions 报告问题、编写文档和开发带有 dsh-plugin topic 的插件，但官方仓库的代码合入仍由内部团队控制。

所以目前更准确的状态是：

维度 8 月 14 日的状态
源码许可 MIT，可查看、修改、分发和派生
产品阶段 v0.1 Developer Preview
API 稳定性 官方明确可能出现破坏性变更
外部代码贡献 暂不接受官方仓库 Pull Request
社区参与 Discussions、文档、教程和独立插件

这不削弱开源本身的价值，但它决定了采用方式：可以研究、试用、Fork 和做插件，暂时不应该把 master 或浮动的 npx 版本直接当作稳定生产依赖。

源码开放回答“能不能看、能不能改”，开放治理回答“社区怎样共同决定下一版”。DeepSeek Harness 已经完成前者，后者还在起步。

团队现在最值得做的不是迁移，而是拆开看

如果团队已经在使用 Claude Code、Codex、OpenCode 或自研 Agent，没有必要因为 12,293 个提交就立刻迁移。更有价值的做法是把 DeepSeek Harness 当作一份可执行的架构样本。

可以先验证五件事：

  1. 固定版本：记录测试使用的 commit SHA，不让浮动依赖在不同时间自动改变实验条件；
  2. 重放真实任务：使用同一个模型、仓库和验收脚本，对比现有 Harness 与 DeepSeek Harness 的成功率、耗时、工具轮数和人工接管；
  3. 检查权限边界：验证文件系统、Shell、网络、子 Agent 和审批策略是否符合自己的安全要求；
  4. 审查日志数据：确认模型可见内容写到哪里、保存多久、谁能读取，以及怎样脱敏和删除；
  5. 测试插件升级：挑一个模型适配器或工具插件，观察替换是否真的不需要修改 Agent Loop，并记录破坏性变更成本。

这五项比“它能不能生成一个小游戏”更接近生产选型。Demo 证明能力存在，回归测试和权限审计才证明能力可控。

12,293 个提交之后，竞争对象变了

DeepSeek Harness 的开源，把最近几天的两件事连到了一起：模型升级负责提高推理与代码能力，Harness 负责把这些能力变成可以调用工具、保持状态、接受约束和持续运行的系统。

模型像发动机，Harness 不是简单的车壳，而是变速箱、制动、仪表、行车记录和驾驶规则。发动机再强，如果周围系统无法替换、无法重建过程、无法限制权限，团队仍然不敢让它驶入生产。

因此，12,293 个提交不是 DeepSeek Harness 的质量证书。它更像一份公开的施工记录：告诉我们 19 位贡献者在两个月里怎样不断拆分、重组和收敛一套 Agent 运行时。

真正的里程碑是，DeepSeek 不再只开放模型和 API，而是把决定模型如何工作的 Harness 层也摆到了桌面上。

接下来要看的，不是谁能最快 Fork 仓库，而是谁能证明“一切皆插件”在经历外部扩展、版本升级和生产故障后，仍然保持可组合、可回放和可控制。

资料与口径