DeepSeek Harness 深度解析

目录

1. 引言：黑鲸出水，DeepSeek 的 Agent 底座正式开源
2. Agent = Model + Harness：理解 Harness 的本质
3. Cordis 微内核：一切皆插件的架构基石
4. 四种运行模式：一套内核，四种装法
5. 多 Agent 编排：Spawn、Fork、Workflow 与 Ralph
6. 全链路可观测：Append-only 会话日志与 Trajectory
7. 工具执行流水线：从 Hook 到沙箱的全链路管控
8. 快速上手：从安装到自定义插件
9. 竞品对比：Harness vs Claude Code vs Codex
10. 挑战与局限：v0.1 阶段的冷静思考
11. 总结与展望

01引言：黑鲸出水，DeepSeek 的 Agent 底座正式开源

2026 年 8 月 13 日晚间，DeepSeek 做了一次"闪电二连击"：在发布 DeepSeek-V4-Pro-0813 正式版模型的同时，悄然开源了 DeepSeek Harness 开发者预览版 v0.1[1][2]。这是 DeepSeek 官方推出的首款开源 Agent 运行框架，以 MIT 协议在 GitHub 上开放了完整源码，仓库地址为deepseek-ai/deepseek-harness[3]。

上线不到 48 小时，GitHub Star 数就突破了 9.3 万，首日更是以约 3.75 万 Star 的速度刷新了 AI 开源项目的记录[4]。这一数据甚至超过了当年 DeepSeek-R1 开源时的盛况，引爆了全球 AI 开发者社区。从俄罗斯的技术媒体到中国的开发者论坛，从 HN 到 Reddit，DeepSeek Harness 成为本周最热门的技术话题。

DeepSeek Harness（简称dsh）不是一个模型，也不是一个 API 客户端，而是一个智能体运行框架。它的核心口号只有五个字——"一切皆插件"（Everything is a Plugin）[5]。这句话的真意是：框架里没有特权组件，模型、工具、技能、会话、沙箱、存储、Agent 循环、调度乃至 UI，全部由可替换的插件组成。

项目负责人崔添翼（Tianyi Cui）在发布时说了一句被社区广泛传播的话："闭源为用户提供现在，开源让用户自己掌握未来。"[6]这句话也道出了 DeepSeek Harness 的产品哲学——它不是要做一个精致封闭的成品，而是要交出一套可组合、可替换、可扩展的底座。

本文将从架构设计、运行模式、多 Agent 编排、可观测性、工具执行流水线等多个维度，深入拆解 DeepSeek Harness 到底"厉害"在哪里，并通过可运行的代码示例帮助开发者快速理解其设计理念。

02Agent = Model + Harness：理解 Harness 的本质

2.1 什么是 Agent Harness

在理解 DeepSeek Harness 之前，需要先理解"Harness"这个概念在 AI Agent 语境下的含义。DeepSeek 官方给出了一个简洁的公式[5]：

Agent = Model + Harness

模型（Model）是 Agent 的灵魂，负责推理、决策和生成下一步内容。但模型本身只会"想"，不会"做"。一个能在真实环境中持续工作的 Agent，还需要处理大量模型之外的事情：

• 执行能力：读写文件、执行命令、调用外部服务
• 上下文管理：长任务中积累的大量中间信息需要压缩、筛选和注入
• 权限控制：哪些目录能碰、哪些命令需要批准
• 状态保存与错误恢复：任务中断后能恢复、重试
• 循环与停止条件：什么情况下继续、什么情况下收尾
• 可观测性：记录每一步的输入输出，方便排查问题

Harness 就是负责这一切的运行时底座——你可以把它理解成 AI 的操作系统外壳。它决定了模型能看到什么、可以调用哪些工具、如何组织上下文、遇到错误怎么重试，以及什么时候判断任务已经完成[2]。

2.2 为什么 Harness 正在成为关键变量

过去几个月，围绕 AI Coding 的讨论正在从"模型能力"转向"Harness 设计"。核心原因很简单：同一个模型被放进不同的 Agent 系统，最终表现可能相差很大。

当模型评测从"单次问答"走向"真实工程任务"之后，Harness 本身已经成为影响评测结果的重要变量。一个设计良好的 Harness 能让中等水平的模型在复杂任务中表现优异，而一个糟糕的 Harness 可能让顶级模型频繁出错。

这正是 DeepSeek 选择在 V4 Pro 正式版发布的同时开源 Harness 的原因——模型能力和运行框架必须协同进化。V4 Pro 提供了更强的 Agent 能力，而 Harness 提供了让这种能力充分发挥的运行环境[7]。

2.3 AI 工程范式的三次跃迁

从宏观视角看，AI 工程范式正在经历第三次跃迁：

DeepSeek Harness 正是第三次跃迁的代表作之一。它不再只拼模型能力，而是把"模型如何利用工具、如何持续运行"变成一套可编程、可组合的底层运行时[8]。

03Cordis 微内核：一切皆插件的架构基石

3.1 Cordis 是什么

DeepSeek Harness 底层的插件框架叫做Cordis——一个只负责插件加载、卸载和依赖管理的微内核[9]。Cordis 本身"几乎什么都不干"，它只提供三样东西：

1. 插件的加载（mount）：把插件挂载到共享上下文中
2. 插件的卸载（unmount）：卸载时自动撤销该插件注册的所有副作用
3. 依赖关系管理：插件可以声明依赖，框架保证依赖先于消费方启动

你可以把整个 Harness 想象成一棵由插件组成的树：

Cordis Root ContextLoader PluginLLM AdapterTool RegistryAgent LoopDeepSeek APIOpenAI APIClaude APIShell ToolFile EditorSandboxApproval没有特权核心 —— 所有能力都是插件模型、工具、会话、沙箱、存储、循环、调度、UI 全部可替换

图 1：DeepSeek Harness 插件树架构总览

Cordis 的理念来自北京大学与 DeepSeek 联合署名的论文《A Programming Paradigm for Spatiotemporal Composability》，强调"时空可组合性"[8]：

• 时间可组合性：插件卸载后，它注册过的服务、事件和副作用能随之撤销
• 空间可组合性：插件可以声明依赖，并在其他组件变化时重新建立协作关系

3.2 插件的三种形态

Cordis 接受三种插件形态：函数插件、对象插件和类插件（Service 子类）[9]。下面通过一个最简单的示例来理解插件的写法。

代码示例 1：你的第一个 Cordis 插件

import type { Context } from '@deepseek-ai/cordis' export const name = 'hello' export function apply(ctx: Context) { console.log('hello from my first plugin') }

每个插件通过一个apply(ctx)函数描述自己贡献的内容，而cordis.yml负责把这些插件"组合"成一个应用：

- name: './hello.ts'

cordis.yml是一组 Cordis 配置项的列表。name是模块指定符，可以是相对路径或 NPM 包名。各项会并发启动，所以列表顺序不保证加载先后——加载顺序由服务依赖（inject）决定，而非文件中的位置[9]。

整个过程中，你的文件里没有框架启动代码：插件只描述自己的贡献，cordis.yml负责组合应用。这正是"一切皆插件"理念的直接体现。

3.3 服务：插件间的协作桥梁

服务是一个插件提供、其他插件通过ctx消费的具名能力。在 Harness 中，ctx.tools、ctx.llm和ctx.agents都是服务[9]。消费方只指定'tools'之类的能力，而不导入其提供方，因此配置可以选择提供方，无需修改消费方。

代码示例 2：服务定义与消费

// greeter.ts —— 定义服务 import { Service, type Context } from '@deepseek-ai/cordis' declare module '@deepseek-ai/cordis' { interface Context { greeter: GreeterService } } export class GreeterService extends Service { constructor(ctx: Context) { super(ctx, 'greeter') } greet(who: string) { return `Hello, ${who}!` } } export const name = 'greeter' export function apply(ctx: Context) { ctx.plugin(GreeterService) } // consumer.ts —— 消费服务 import type { Context } from '@deepseek-ai/cordis' export const name = 'consumer' export const inject = ['greeter'] // 声明依赖 export function apply(ctx: Context) { console.log(ctx.greeter.greet('world')) }

这里有两部分协同工作：

• 运行时：super(ctx, 'greeter')以名称greeter注册该实例。此后任何插件都可以通过ctx.greeter访问它
• 编译时：declare module块使用 TypeScript 声明合并，把greeter加入Context接口，使ctx.greeter在各处都能通过类型检查

inject列出该插件需要的服务。Cordis 会让插件保持PENDING状态，直到列出的每项服务都存在[9]。这意味着cordis.yml中的加载顺序无关紧要——决定插件何时启动的是依赖关系，而不是文件顺序。

核心设计：依赖跟踪是动态的

inject并非一次性的启动检查。如果应用运行期间所需服务消失——例如提供方被卸载或热替换——每个依赖插件也会随之卸载，并在服务恢复后再次加载。结合 effect 机制，这能防止运行中的消费方保留对不可用服务的引用。这也是配置中可以替换服务的原因：卸载dsh-bash-local，挂载另一个shell提供方，所有注入'shell'的插件都会重新启动并使用新实现。

3.4 生命周期与 Effect：自动清理的资源管理

Cordis 插件可能因修改配置、热重载、显式资源释放或所需服务消失而卸载。通过 Cordis API 建立的注册属于effect，会在所属插件卸载时自动撤销[9]。

代码示例 3：生命周期与 Effect

import type { Context } from '@deepseek-ai/cordis' export const name = 'lifecycle-demo' function heartbeat(ctx: Context) { console.log('heartbeat plugin loading') ctx.effect(() => { const timer = setInterval(() => console.log('tick'), 200) return () => { clearInterval(timer) console.log('heartbeat cleaned up') } }) } export function apply(ctx: Context) { // 挂载子插件并保留其 fiber 以便后续释放 const fiber = ctx.plugin(heartbeat) ctx.effect(() => { const timer = setTimeout(async () => { await fiber.dispose() console.log('disposed') process.exit(0) }, 700) return () => clearTimeout(timer) }) }

每个已加载插件实例都拥有一个fiber，并在以下状态之间转换：

PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED ↘ FAILED

fiber.dispose()会等该插件的所有清理工作（包括异步 disposer）完成后才结束，并递归卸载它挂载的所有子插件[9]。这种设计确保了插件系统的"时间可组合性"——卸载是干净的、可逆的、递归的。

3.5 事件系统：五种分发模式

服务支持直接调用；事件让插件无需知道有哪些插件正在监听，就能发出通知[9]。Cordis 提供了五种事件分发模式：

代码示例 4：Waterfall 事件 —— 转换与短路

import type { Context } from '@deepseek-ai/cordis' declare module '@deepseek-ai/cordis' { interface Events { 'demo/transform'(input: string, next: () => Promise<string>): Promise<string> } } export const name = 'waterfall-demo' export function apply(ctx: Context) { // 监听器 1：包装下游结果 ctx.on('demo/transform', async (input, next) => { const downstream = await next() return downstream.toUpperCase() }) // 监听器 2：满足条件时短路（否决） ctx.on('demo/transform', async (input, next) => { if (input.includes('blocked')) return '** blocked **' return next() }) void (async () => { console.log(await ctx.waterfall('demo/transform', 'hello', async () => 'hello')) console.log(await ctx.waterfall('demo/transform', 'blocked words', async () => 'blocked words')) })() }

运行结果：

HELLO ** BLOCKED **

这个 waterfall 模式在 Harness 中有实际用途：agent/request事件允许插件替换模型调用配置；approval/request事件允许策略代替用户作答[9]。一个重要纪律是：只负责观察或标注的 waterfall 监听器必须调用next()，否则会悄无声息地吞掉所有下游的默认行为。

3.6 配置与 Schema：类型安全的插件配置

代码示例 5：带 Schema 验证的可配置插件

import type { Context } from '@deepseek-ai/cordis' import Schema from '@deepseek-ai/schemastery' export const name = 'config-demo' export interface Config { greeting: string targets: string[] } export const Config: Schema<Config> = Schema.object({ greeting: Schema.string().default('Hello'), targets: Schema.array(String).default(['world']), }) export function apply(ctx: Context, config: Config) { for (const target of config.targets) { console.log(`${config.greeting}, ${target}!`) } }

导出的Config既是 TypeScript 接口，也是同名的运行时 schema：消费方获得类型，Cordis 获得验证器。错误配置会导致加载失败并给出准确错误——插件绝不会在配置不完整时启动[9]。

04四种运行模式：一套内核，四种装法

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

4.1 标准模式：最"省心"的全能选手

标准模式提供完整工具组合，包括文件操作、Shell 执行、文件和 Web 搜索、技能（Skills）、计划（Planning）、目标（Goals）、子 Agent（Subagents）和工作流（Workflows）[5]。这是日常开发中最常用的模式，能力最全，开箱即用。

4.2 PTC 模式：让模型写代码来编排工具调用

PTC（Programmatic Tool Calling，程序化工具调用）模式是四种模式中最具技术深度的创新之一。传统工具调用是"一轮一次"的：模型决定调用某个工具，等待结果，再决定下一步。而 PTC 模式允许模型先生成一段 TypeScript 程序，再由这段程序编排多轮工具调用[2]。

这适合需要根据中间结果分支、循环、批量处理的复杂任务。例如，模型可以写一段代码：先查询文件列表，对每个文件检查内容，根据匹配结果决定是否修改——整个过程在一次模型请求中完成，减少了多轮对话的延迟和上下文消耗。

安全设计

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

4.3 极简模式：模型基准测试的"无尘室"

极简模式只保留一个 Shell 工具和一个文件编辑工具（str_replace_editor），主要用于减少其他组件干扰，在最小环境中测试模型能力[5]。当你要评测不同模型在相同条件下的表现时，极简模式提供了最"干净"的测试环境。

4.4 创造模式：让 Agent 改造自己的运行时

创造模式是四种模式中最值得关注的设计。传统 Harness 的运行方式通常由产品开发者预先写定，用户只能在既有配置中选择。创造模式试图让Agent 直接理解自己所处的运行时，再按任务需要试装插件和组合能力[2]。

换句话说，Harness 的配置本身也开始成为 Agent 可以操作的对象。这距离"Agent 自己改造自己的 Harness"还有多远，需要等代码、示例和真实任务验证。但目前能够确认的是，DeepSeek 已经把运行时的可组合性同时交给了模型、配置文件和框架开发者。

4.5 Profile 与 Bundle：模式背后的组合机制

四种模式本质上是四种Profile。一个 Profile 是存储在 Harness 主目录中的命名组合，它列出了要堆叠的 Bundle、持有的任何外部插件，并保留用户自己的cordis.patch.yml[10]。

一个Bundle是 Cordis 配置行及其所挂载代码的分发格式——无论它插入什么，都可以被上层 patch 覆盖。每个 Bundle 在自己的package.json中通过dsh字段声明：dsh.profile列出 Profile 的 Bundle，dsh.bundle指向 Bundle 的 patch 文件。

# 查看你的机器实际启动的配置树 dsh --profile web --dump-config

这条命令打印出的任何行都可以被你自己的 patch 替换。这就是"一切皆插件"在配置层面的落地方式——不 fork 源码，只改配置。

05多 Agent 编排：Spawn、Fork、Workflow 与 Ralph

DeepSeek Harness 已经内置了一套完整的多 Agent 系统[2]。父 Agent 可以通过多种方式启动子 Agent，面对更复杂的任务还能通过 workflow 工具现场编写 JavaScript 来组织并行或流水线任务。

Parent AgentSpawn (fresh)ForkWorkflowRalphChild (new ctx)Child (inherited)parallel() / pipeline()Relay Agents全新上下文独立探索任务互不干扰继承父会话共享上下文前缀缓存友好模型写 JS 代码并行 / 流水线复杂编排多 Agent按轮次接力持续工作层级式 Supervisor-Worker 架构父 Agent 负责拆解、分配和汇总；子 Agent 负责执行

图 2：DeepSeek Harness 多 Agent 编排模式

5.1 Spawn 与 Fork

Spawn启动拥有全新上下文的子 Agent，适合独立的探索任务。Fork让子 Agent 继承已有会话——在 fork 模式下，子请求保持父 Agent 的系统提示词和消息历史字节级一致，追加一个结构化状态快照，然后添加子 Agent 角色指令和任务[11]。这种设计让 DeepSeek 前缀缓存复用率保持在较高水平，同时给子 Agent 提供了续写、审查、摘要或压缩工作所需的上下文。

5.2 Workflow：parallel() 与 pipeline()

面对更复杂的任务，模型还能通过 workflow 工具现场编写 JavaScript，用parallel()和pipeline()组织并行或流水线任务[2]。这意味着模型不再局限于"一步一工具"的串行调用，而是可以像写程序一样设计 Agent 间的协作流程。

5.3 Ralph 循环模式

Ralph 模式让多个全新 Agent 按轮次接力——每个 Agent 在自己的轮次中工作，完成后将控制权交给下一个 Agent。这种模式适合需要持续迭代的长时间任务，比如"不断审查和改进代码直到通过所有测试"。

5.4 编排范式的冷静评估

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

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

创新在哪里

Spawn、Fork、Pipeline 和 Ralph Loop 都已有成熟先例，真正特别的地方在于——它把这些编排方式做成了可以随配置替换的插件，甚至可以把 Claude Code、Codex 或支持 ACP 的外部 Agent 接到同一个子 Agent 接口后面[2]。架构设计有新意，编排范式没有突破。放在开源 Harness 中，这套设计已经相当先进。

06全链路可观测：Append-only 会话日志与 Trajectory

DeepSeek Harness 的另一个核心设计，是仅追加的会话日志（append-only session log）[2]。这是整个框架最具特色的功能之一。

6.1 统一事件流

模型看到的所有内容都会进入同一份 append-only 日志，包括：

• 系统提示词（system prompts）
• 推理内容（reasoning / thinking）
• 工具调用及其结果（tool calls and results）
• 子 Agent 调度（subagent scheduling）
• 每一次上下文注入（context injection）

开发者可以在Trajectory（轨迹）视图中按照来源检查这些信息[5]。会话恢复、分叉、检索与回放，也都建立在同一份事件流之上。

6.2 Turn Flow：一次对话的完整生命周期

一个step是一次模型请求加上它调用的工具。一个turn是零或多个 step[10]。完整的 Turn Flow 如下：

turn/startassemble prompt + tool schemasagent/pre-step (waterfall)step/startagent/request → llm/streamtools/pre-execute → executeassistant/chunk* → messagetools/post-execute → resultstep/end → turn/enddurable eventextension point

图 3：Turn Flow —— 一次对话的完整生命周期

turn/*、step/*、user/message、assistant/*和tool/*是持久化会话事件；其余的是跨三个域的实时扩展点[10]。agent/pre-step、agent/request、llm/stream和三个tools/*事件是 waterfall，其监听器必须调用next()来委托；agent/turn-stopping是 serial 且没有next()。

6.3 为什么统一事件流如此重要

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

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

架构文档中有一条关键的运行时不变量：模型可见即已记录（Model-visible means logged）[10]。任何到达模型请求的内容都必须可以从日志中重建，运行时会断言这一点。这就是为什么一个新的模型可见输入需要一个新的会话事件。

07工具执行流水线：从 Hook 到沙箱的全链路管控

工具调用在 DeepSeek Harness 中被拆成了一条可扩展流水线[2]。这条流水线是整个框架安全设计的核心。

Hook前置拦截Approval人工审批Permission权限检查Sandbox沙箱隔离Execute实际执行Rewrite结果改写Record记录+UI工具执行流水线（Tool Execution Pipeline）请求执行前执行执行后

图 4：工具执行流水线 —— 从请求到结果的全链路管控

请求执行前会经过Hook、审批、权限检查、沙箱和超时控制，执行后还可进行结果改写、记录和 UI 渲染。开发者无需修改工具或 Agent Loop，就能在各个环节插入插件[2]。

7.1 Capability Seams：可替换的能力接缝

Harness 架构中有一个核心概念叫Seam（接缝）——一个可替换的能力，包含三个角色[10]：

• Service Definition（服务定义）：声明接口
• Service Provider（服务提供方）：实现接口
• Consumer（消费方）：使用接口，通常是面向模型的工具

Seams 是为什么"一次提供方替换就能改变整个产品"的原因。文件系统和子进程提供方共享一个执行世界，因此将它们指向远程沙箱时，Bash、PTY 和 LSP 会随之移动，无需 provider 分叉[10]。子 Agent 提供方也在一个接口后面变化极大——从一个全新的子 Agent 到另一个产品中的委托轮次。

7.2 扩展点地图

架构文档中有一张详细的"新行为归属"映射表，列出了所有可扩展的入口[10]：

这张表的含义非常明确：几乎所有你能想到的扩展需求，都有对应的插件入口，不需要修改 Harness 源码。

08快速上手：从安装到自定义插件

8.1 一行命令启动

对一个刚开源的 v0.1 来说，DeepSeek Harness 安装简单得有点不像官方产品。前置条件只有一个：装好 Node.js（v22.19 及以上或 v24 及以上）[8]。

代码示例 6：快速启动

# 方式一：npx 一行命令，尝鲜首选 npx @deepseek-ai/dsh web # 启动成功后浏览器打开 http://127.0.0.1:3080 # 在设置 → 模型中填入 DeepSeek API Key 并保存 # 选择工作区目录，发送第一个任务 # 方式二：从源码构建（想改插件、读源码选这个） git clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build pnpm dsh web

国内网络较慢时，可以先配置 npm 镜像：

npm config set registry https://registry.npmmirror.com

8.2 配置模型

DeepSeek Harness 是模型无关（Model-agnostic）的。官方内置 DeepSeek 模型接入，同时支持 Anthropic、OpenAI 等提供方，以及任意 OpenAI 兼容的自定义端点[8]。模型配置变更下次请求即生效，无需重启服务。

对于自定义提供方（公司网关、自建服务器等），只需选择"添加自定义提供方"，填写 Provider ID、基础 URL、API 协议、凭据和至少一个模型即可。Provider ID 是永久的——请求、已保存会话、模型默认值和凭据引用都会使用它[8]。

8.3 Python SDK：程序化调用

适合把 Harness 的能力嵌入自己的脚本或自动化流程，而不是通过 Web 界面交互[8]。

代码示例 7：Python SDK 调用

# 安装 SDK pip install deepseek-harness-sdk # 设置环境变量 export DEEPSEEK_API_KEY=你的密钥 export DSH_MODEL=deepseek-v4-flash # 运行仓库内置示例 python examples/jsonrpc-agent/minimal.py \ --workspace /绝对路径/workspace \ --session-root /绝对路径/sessions \ --session-id example-001 \ "Inspect the repository and fix the failing tests."

Windows 注意

官方 Python SDK 文档目前列出的前置环境为Linux x64 / Linux arm64 / macOS 14+ (arm64)，示例组合不支持 Windows。Windows 用户建议用 Web UI 方式体验，或借助 WSL。

8.4 编写你的第一个自定义插件

结合前面学到的 Cordis 知识，让我们写一个更有实际意义的插件——一个简单的统计服务，记录工具调用次数：

代码示例 8：完整的统计服务插件

import { Service, type Context } from '@deepseek-ai/cordis' declare module '@deepseek-ai/cordis' { interface Context { stats: StatsService } interface Events { 'stats/report'(name: string, count: number): void } } export class StatsService extends Service { private counts = new Map<string, number>() constructor(ctx: Context) { super(ctx, 'stats') } bump(name: string) { const next = (this.counts.get(name) ?? 0) + 1 this.counts.set(name, next) this.ctx.emit('stats/report', name, next) } } export const name = 'stats' export function apply(ctx: Context) { ctx.plugin(StatsService) // 监听工具执行事件，自动统计 ctx.on('tools/execute', () => { ctx.stats.bump('tool_call') }) }

然后在cordis.yml中挂载它：

- name: './stats.ts' - name: './reporter.ts' # 消费 stats 服务的插件

这个示例展示了 Cordis 的几个关键设计在实践中的组合：服务定义、事件声明、effect 自动清理、以及通过事件钩子集成到 Harness 的工具执行流程中。

09竞品对比：Harness vs Claude Code vs Codex

DeepSeek Harness 的定位更接近一套可组装的 Agent 运行时底座，与功能固定的 Coding Agent 有明显区别[2]。让我们把它和主流竞品做一个对比：

说白了，Claude Code 是精装房，拎包入住；DeepSeek Harness 是毛坯工坊，工具给齐了，但家具得你自己拼[6]。两者面向的用户群体不同：Claude Code 面向想开箱即用写代码的开发者，Harness 面向想搭建自己的 Agent 工作流的 Harness 开发者。

与 MCP 的关系也值得一提：两者不在同一层。MCP 是连接 AI 应用与外部数据、工具、工作流的开放标准；Harness 是更上层的运行逻辑。MCP Server 可以成为 Harness 里的一个插件[8]。

10挑战与局限：v0.1 阶段的冷静思考

10.1 官方自己的警告

DeepSeek 在 GitHub 仓库的 README 中明确标注[3]：

DeepSeek Harness is currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES.

这意味着现在进入生态的开发者需要承受较高的迁移成本。核心插件与基础接口仍会快速变化，尝鲜、学习、做二次开发完全没问题；追求稳定、要上生产，建议等版本收敛[6]。

10.2 插件边界的代价

"什么都能换"这条路线也带来了明显挑战[2]：

• 接口稳定性：插件边界越深，接口稳定性就越难控制
• 依赖管理：插件之间的依赖关系可能变得复杂
• 版本兼容：不同版本的插件之间可能不兼容
• 性能开销：插件化的间接调用带来额外开销
• 调试复杂度：问题可能出在任何一个插件的交互中

10.3 "可替换"不等于"更好"

更重要的是，"什么都能换"并不会自动带来更好的任务成功率[2]。真正决定这套架构价值的，仍然是：

1. 官方能否给出高质量的默认插件
2. 能否形成稳定的组合范式
3. 能否提供可信的评测结果
4. 第三方开发者是否愿意围绕它持续构建插件

插件系统提供的是差异化空间，最终效果还要由具体实现兑现。

10.4 未来真正的差距在哪里

一位业内专家向 InfoQ 表示，从 Harness 的完整链路看，工具调用、记忆管理和任务规划等大方向已经基本确定，未来仍有大量创新会发生在各个局部环节[2]：

• 记忆管理：当记忆不断累积时需要压缩；当不同记忆之间出现冲突时需要及时整理和清理
• 任务规划：Agent 没有必要每次都从头规划，面对相似问题时可以复用已有路径
• Plan 校验：计划生成后可以增加一层近似"编译"的检查——先把 Plan 表示成结构化数据，再检查异常处理分支是否完整、是否包含无法执行的操作

DeepSeek "一切皆插件"的价值，也正在于为这些局部能力预留替换、组合和持续试验的空间。

11总结与展望

DeepSeek Harness v0.1 的发布，标志着 DeepSeek 从"模型公司"向"模型 + 框架公司"的延伸。它选择 MIT 协议并在开发者预览阶段就开放完整源码，说明其目标已经超过一个封闭的 DeepSeek 模型客户端[2]。

从架构层面看，DeepSeek Harness 当前最鲜明的差异落在三个点上：

1. 一切皆插件：从模型到 UI，所有能力都可替换，没有特权核心
2. 全链路可观测：Append-only 事件流让每次运行都有迹可循
3. 四种运行模式：一套内核覆盖从基准测试到 Agent 自我改造的全场景

它试图把模型、工具、Loop、调度和 UI 都放进同一套可组合框架中，再邀请外部开发者共同扩展这套系统。这是一个雄心勃勃的方向，但也是一个充满挑战的方向。

接下来真正值得观察的是：

• "一切皆插件"能否形成一套足够稳定的开发标准
• 它最终会长成 DeepSeek 自己的 Coding 产品，还是成为更多 Agent 产品共同采用的底层 Harness
• 社区生态能否在 v0.1 的不稳定期存活并壮大

DeepSeek Harness v0.1 只是起点。对于爱折腾的开发者来说，现在正是上手体验、参与生态建设的最佳时机。想要什么能力，自己拼——这正是"一切皆插件"的承诺。

相关资源

• GitHub 仓库：github.com/deepseek-ai/deepseek-harness
• 官方网站：deepseek.com/harness
• 官方文档：deepseek-harness.github.io
• 社区插件：GitHub Topics: dsh-plugin
• Cordis 论文：A Programming Paradigm for Spatiotemporal Composability
• npm 包：@deepseek-ai/dsh（npx @deepseek-ai/dsh web一键启动）

参考来源

1. CGTN, DeepSeek launches V4 Pro model with enhanced AI agent capabilities. 2026-08-14.DeepSeek launches V4 Pro model with enhanced AI agent capabilities
2. Tina, InfoQ. DeepSeek 把 Harness 开源了：模型、工具、Agent Loop 全是插件. 2026-08-14.DeepSeek 把 Harness 开源了：模型、工具、Agent Loop 全是插件 - InfoQ
3. GitHub, deepseek-ai/deepseek-harness. DeepSeek Harness: Everything is a Plugin.GitHub - deepseek-ai/deepseek-harness: DeepSeek Harness: Everything is a Plugin. · GitHub
4. Habr, DeepSeek Harness набрал 37 тысяч звёзд за первый день. 2026-08-14.DeepSeek Harness набрал 37 тысяч звёзд за первый день: что умеет новый кодинг‑агент / Хабр
5. DeepSeek Official, DeepSeek Harness Developer Preview. Everything is a plugin.DeepSeek Harness developer preview: Everything is a plugin
6. 晚安code, 阿里云开发者社区. DeepSeek Harness 一切皆插件：开源Agent框架强在哪，怎么装. 2026-08-15.DeepSeek Harness 一切皆插件：开源Agent框架强在哪，怎么装-阿里云开发者社区
7. China Daily, China's DeepSeek upgrades its V4 Pro model. 2026-08-13.China's DeepSeek upgrades its V4 Pro model - Chinadaily.com.cn
8. 掉落的果实, 博客园. DeepSeek Harness 教程：一切皆插件的开源 Agent 框架. 2026-08-15.DeepSeek Harness 教程：一切皆插件的开源 Agent 框架 - 掉落的果实 - 博客园
9. CSDN, DeepSeek Harness Cordis 教程：从零到接入真实 harness. 2026-08-14.DeepSeek Harness Cordis 教程：从零到接入真实 harness-CSDN博客
10. GitHub, deepseek-ai/deepseek-harness/docs/architecture.md. DeepSeek Harness Architecture.deepseek-harness/docs/architecture.md at master · deepseek-ai/deepseek-harness · GitHub
11. GitHub, sockerch/DeepSeek-TUI/docs/SUBAGENTS.md. Sub-Agents documentation.DeepSeek-TUI/docs/SUBAGENTS.md at main · sockerch/DeepSeek-TUI · GitHub