DeepSeek 把 Harness 开源了：模型、工具、Agent Loop 全是插件

DeepSeek 的 Harness 终于来了。

8 月 13 日，DeepSeek 面向全球开发者开放 DeepSeek Harness 开发者预览版，首个版本为 v0.1，并同步以 MIT 协议开放源代码： https://github.com/deepseek-ai/deepseek-harness

开发者现在可以通过 npx @deepseek-ai/dsh web 直接启动 Web UI，也可以从 GitHub 拉取完整项目。

从版本号看，这还远未到成熟产品阶段。DeepSeek 也明确表示，当前仍有大量细节需要打磨，核心插件和基础接口将在后续快速迭代。不过，这次发布已经回答了外界最关心的问题：DeepSeek 会怎样做自己的 Harness？

过去几个月，围绕 AI Coding 的讨论正在从模型转向 Harness。同一个模型被放进不同的 Agent 系统，最终表现可能相差很大。原因并不复杂：模型只负责预测下一步，Harness 决定模型能看到什么、可以调用哪些工具、如何组织上下文、遇到错误怎么重试，以及什么时候判断任务已经完成。

目前主流 Coding Agent 虽然普遍支持插件、MCP 或自定义工具，但可扩展的范围通常集中在工具与技能层。DeepSeek Harness 把插件边界进一步下沉到了整个运行时：模型、工具、技能、会话、沙箱、存储、Agent Loop、调度和 UI，全都由插件组成。

这意味着，可替换范围从某个搜索工具或 MCP Server，一直延伸到 Agent 如何循环、如何调度子 Agent、如何保存会话，以及最终采用什么交互界面。整个过程无需修改 Harness 源码。

支撑这套架构的是 Cordis 插件系统。Cordis 元框架本身只处理插件的加载、卸载与依赖关系，具体的 Agent 能力则由不同插件提供。插件之间通过服务和事件协作，再由配置决定它们如何组合。

工具调用也被拆成了一条可扩展流水线。请求执行前会经过 Hook、审批、权限检查、沙箱和超时控制，执行后还可进行结果改写、记录和 UI 渲染。开发者无需修改工具或 Agent Loop，就能在各个环节插入插件。

PTC 模式中的代码及其子调用同样要经过这套流水线，不能绕过审批与沙箱。普通工具调用和程序化工具调用入口不同，但共享同一套安全与观测机制。

因此，DeepSeek Harness 的定位更接近一套可组装的 Agent 运行时底座，与功能固定的 Coding Agent 有明显区别。DeepSeek 此次首先面向的也是 Harness 开发者，而非只想下载一个客户端直接写代码的普通用户。

基于同一套底座，DeepSeek Harness 当前提供四种运行模式。它们没有分别维护四套系统，主要差异来自默认加载的插件集合。

标准模式提供完整工具组合，面向常规 Agent 任务；PTC 模式支持程序化工具调用（Programmatic Tool Calling），允许模型生成代码，将多轮工具调用组合起来执行；极简模式只保留 shell 和文件编辑两个工具，主要用于减少其他组件干扰，在最小环境中测试模型能力；创造模式则允许 Agent 检查当前运行时，在内存中试验 Cordis 插件，并据此组合、创作新的运行模式。

其中最值得关注的是创造模式。传统 Harness 的运行方式通常由产品开发者预先写定，用户只能在既有配置中选择。创造模式试图让 Agent 直接理解自己所处的运行时，再按任务需要试装插件和组合能力。换句话说，Harness 的配置本身也开始成为 Agent 可以操作的对象。

这距离“Agent 自己改造自己的 Harness”还有多远，需要等代码、示例和真实任务验证。目前能够确认的是，DeepSeek 已经把运行时的可组合性同时交给了模型、配置文件和框架开发者。

DeepSeek Harness 已经内置了一套完整的多 Agent 系统。父 Agent 可以通过 Spawn 启动拥有全新上下文的子 Agent，也可以通过 Fork 让子 Agent 继承已有会话；面对更复杂的任务，模型还能通过 workflow 工具现场编写 JavaScript，用 parallel() 和 pipeline() 组织并行或流水线任务，并通过 Ralph 模式让多个全新 Agent 按轮次接力。

如果放进常见的五种编排模式中，DeepSeek Harness 最接近层级式 Supervisor–Worker：父 Agent 负责拆解、分配和汇总任务，子 Agent 负责执行。更准确地说，它是一个以层级式编排为主，兼容并行、流水线和 Ralph 循环的混合系统。

它目前离真正的 Swarm 还有较大距离。系统中的任务分配和控制权主要掌握在父 Agent 手中，缺少 Agent 之间的自主发现、协商、竞争和动态接管任务机制。

所以，DeepSeek Harness 的多 Agent 有创新，但谈不上范式创新。Spawn、Fork、Pipeline 和 Ralph Loop 都已有成熟先例，真正特别的地方在于，它把这些编排方式做成了可以随配置替换的插件，甚至可以把 Claude Code、Codex 或支持 ACP 的外部 Agent 接到同一个子 Agent 接口后面。架构设计有新意，编排范式没有突破。放在开源 Harness 中，这套设计已经相当先进；如果将其宣传成“全新的多 Agent 架构”，就吹过头了。

DeepSeek Harness 的另一个核心设计，是仅追加的会话日志。

模型看到的所有内容都会进入同一份 append-only 日志，包括系统提示词、推理内容、工具调用及其结果、子 Agent 调度和每一次上下文注入。开发者可以在 Trajectory 视图中按照来源检查这些信息；会话恢复、分叉、检索与回放，也都建立在同一份事件流之上。

这项设计首先解决的是可观测性。Agent 任务失败时，问题可能出在模型判断、工具返回、上下文注入、调度策略或系统提示词。若这些内容散落在不同组件中，开发者很难还原模型当时究竟看到了什么。统一事件流给调试、评估和回放提供了一份共同底稿。

它也为会话分叉提供了更自然的数据结构：新分支可以沿用分叉点以前的事件，再追加新的上下文和行动，无需覆写原有历史。对于一个强调插件可替换的系统，这尤其重要，因为开发者需要比较不同 Loop、工具或调度插件在相同任务轨迹上的表现。

从此次披露的信息看，DeepSeek Harness 当前最鲜明的差异落在架构层：Harness 各层能力都被拆成了可替换插件。此次尚未公布新的多 Agent 编排算法，重点是让开发者既能更换“Agent 手里拿什么工具”，也能改变“Agent 按什么规则工作”。

一位业内专家向 InfoQ 表示，从 Harness 的完整链路看，工具调用、记忆管理和任务规划等大方向已经基本确定，未来仍有大量创新会发生在各个局部环节。以记忆管理为例，当记忆不断累积时，需要进行压缩；当不同记忆之间出现冲突时，还要及时整理和清理，否则可能干扰 Agent 后续的判断。

任务规划同样存在继续改进的空间。Agent 没有必要每次都从头规划，面对相似问题时，可以复用已有的规划路径。计划生成之后也可以增加一层近似“编译”的检查：先把 Plan 表示成结构化数据，再检查异常处理分支是否完整、是否包含无法执行的操作，以及所有步骤是否处于权限范围内。这里的“编译”并非真正编译计划，而是对执行计划进行结构化校验。

按照这一判断，Harness 的整体框架正在趋同，真正拉开差距的将是记忆压缩、冲突清理、路径复用和 Plan 校验等环节能否做得足够细。DeepSeek“一切皆插件”的价值，也正在于为这些局部能力预留替换、组合和持续试验的空间。

不过这条路线也带来了明显挑战。插件边界越深，接口稳定性、依赖管理、版本兼容、性能开销和调试复杂度就越难控制。尤其在 v0.1 阶段，核心插件与基础接口仍会快速变化，现在进入生态的开发者需要承受较高的迁移成本。

此外，“什么都能换”并不会自动带来更好的任务成功率。真正决定这套架构价值的，仍然是官方能否给出高质量的默认插件、稳定的组合范式和可信的评测结果，以及第三方开发者是否愿意围绕它持续构建插件。插件系统提供的是差异化空间，最终效果还要由具体实现兑现。

不过，DeepSeek 此次选择 MIT 协议，并在开发者预览阶段就开放完整源码，说明其目标已经超过一个封闭的 DeepSeek 模型客户端。它试图把模型、工具、Loop、调度和 UI 都放进同一套可组合框架中，再邀请外部开发者共同扩展这套系统。

DeepSeek Harness v0.1 只是起点。接下来真正值得观察的，是“一切皆插件”能否形成一套足够稳定的开发标准，以及它最终会长成 DeepSeek 自己的 Coding 产品，还是成为更多 Agent 产品共同采用的底层 Harness。

已经安装 Node.js 开发工具链的用户，可以运行以下命令启动 Web UI：

npx @deepseek -ai/dsh web 复制代码

git clone https: //github.com/deepseek-ai/deepseek-harness 复制代码