前面研究 Claude Code、Codex 时，我们逐渐形成了一套比较稳定的 Agent Harness 认知：

User Goal
    ↓
Harness
    ↓
Instruction
    ↓
Skill / Agent / Tool
    ↓
Policy
    ↓
Sandbox
    ↓
Execution

在这套模型里，通常存在一个相对稳定的：

Harness Core

然后再围绕 Core 挂载：

Skill
Plugin
MCP
Hook
Custom Agent

也就是说，我们习惯的扩展模型大致是：

                 Harness Core
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
        Skill       Plugin       Tool
          │           │           │
          └───────────┼───────────┘
                      ↓
                   Runtime

但 DeepSeek 最近开源的 DeepSeek Harness，在架构上选择了一条明显不同的路线。

官方给这个项目的核心定位非常直接：

Everything is a Plugin

DeepSeek Harness，简称：

dsh

是 DeepSeek AI 官方开源的 Agent Harness，目前仍处于 Developer Preview 阶段，官方明确提示其接口和架构仍然会快速演进，并可能发生兼容性破坏。项目底层由 Cordis 驱动。

真正值得研究的地方并不是：

DeepSeek Harness 支持 Plugin

而是：

DeepSeek Harness 本身，就是通过 Plugin 组合出来的。

官方架构文档明确把 Model Adapter、Tool Registry、Session Log、Agent Loop 都纳入 Plugin 体系，并说明运行中的 dsh 是启动阶段通过多层配置组合出来的一棵 Plugin Tree。

所以理解 DeepSeek Harness 时，需要先把传统的：

Harness Core
    ↓
Load Plugin

换成另一种思路：

Plugin
+
Plugin
+
Plugin
+
Composition
    ↓
Plugin Tree
    ↓
Agent Runtime

这也是我们这一篇首先要建立的架构地图。

---

一、先认识 DeepSeek Harness：它到底不一样在哪里

1. DeepSeek Harness 是什么

从使用方式来看，dsh 仍然是一个典型的 Agent Harness。

官方目前可以直接通过：

npx @deepseek-ai/dsh web

启动 Web UI，默认监听：

http://127.0.0.1:3080

也可以从源码运行：

git clone https://github.com/deepseek-ai/deepseek-harness.git

cd deepseek-harness

pnpm install

pnpm run build

pnpm dsh web

这些都是当前官方 README 给出的运行入口。

如果只从产品形态来看，它很容易让人联想到：

Claude Code

Codex

OpenCode

这些 Coding Harness。

因为它们最终都需要完成类似的事情：

User
    ↓
LLM
    ↓
Agent Loop
    ↓
Tool
    ↓
Filesystem / Shell / Web
    ↓
Observation
    ↓
Next Loop

但 DeepSeek Harness 真正特别的地方，不在这条 Agent Loop 本身，而在于：

这条 Loop 是怎么被构造出来的。

---

2. 传统 Harness：Core 先存在

在很多 Harness 中，我们可以用一个比较直观的模型理解：

Harness Core
│
├── Session Manager
├── Agent Loop
├── Tool Registry
├── Context Manager
├── Permission
└── Runtime

然后 Core 再提供：

Extension Point

让外部能力加入：

Plugin
Skill
Hook
Tool
Agent

于是：

Core
    ↓
Extension API
    ↓
Plugin

这是一种典型的：

Core + Extension

架构。

---

3. DeepSeek Harness：Runtime 本身也是 Composition

DeepSeek Harness 官方架构文档则强调：Cordis 下面的插件可以向共享 Context 贡献 Service、Typed Event 和可逆的 Effect；包括 Model Adapter、Tool Registry、Session Log、Agent Loop 在内的产品组件本身都是 Plugin。

所以可以把它抽象成：

                    Cordis
                       │
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
   LLM Plugin      Tool Plugin    Session Plugin
       │               │               │
       └───────────────┼───────────────┘
                       ↓
                Agent Loop Plugin
                       ↓
                    Runtime

这里最值得注意的是：

Agent Loop

自己也不是绝对固定的 Core。

官方在 package 设计里专门将：

core/agent

和：

core/agent-loop

拆开，前者提供 Agent 接口与 Registry，后者提供默认 Driver；官方 package 说明也明确指出 dsh-agent-loop 是可替换的。

因此 DeepSeek Harness 更接近：

Plugin
    ↓
Composition
    ↓
Runtime

而不是：

Runtime
    ↓
Plugin

这就是理解整个项目的第一把钥匙。

---

二、从源码目录建立 DeepSeek Harness 的静态地图

理解一个 Harness，第一步仍然应该从磁盘结构开始。

因为目录结构往往能够回答几个非常基础的问题：

Core 在哪里？

Capability 在哪里？

Runtime 在哪里？

Plugin 在哪里？

配置与分发在哪里？

---

1. 先看整个 Monorepo

目前 DeepSeek Harness 官方仓库根目录主要包括：

deepseek-harness/
│
├── .agents/
├── .claude/
├── .github/
│
├── apps/
├── assets/
├── docs/
├── examples/
│
├── native/
├── packages/
├── patches/
├── python/
├── scripts/
├── vendor/
├── website/
│
├── AGENTS.md
├── CLAUDE.md
├── package.json
├── pnpm-workspace.yaml
└── ...

这是一个明显的 Monorepo，官方仓库当前确实以 apps/、packages/、native/、python/、vendor/ 等目录组织代码。

如果从 Harness 架构而不是普通源码阅读的角度看，可以先压缩成：

deepseek-harness/
│
├── apps/
│      → Product Entry
│
├── packages/
│      → Harness Components
│
├── vendor/
│      → Underlying Framework / Vendored Dependencies
│
├── native/
│      → Native Runtime Capability
│
├── python/
│      → Python-side Capability
│
└── docs/
       → Architecture / Development Contract

第一篇不需要把每个目录都展开。

真正应该重点关注的是：

packages/

因为大部分 Harness 能力都在这里。

---

2. packages 并不是一个简单的 Tool 集合

当前官方 packages/README.md 已经列出了非常多的 package group，例如：

core
api
llm
subprocess
shell
terminal
sandbox
fs
lsp
skill
context
subagent
jobs
workflow
web
bundle
extensions
hooks
session
settings
credentials
workspace
interaction
boot
host
client
...

官方给每个 group 都定义了明确角色，例如：

core
    → Product API spine

llm
    → LLM capability family

shell
    → Bash capability family

fs
    → Filesystem capability family

skill
    → Skill capability family

subagent
    → Subagent capability family

workflow
    → Workflow seam

sandbox
    → Process confinement

bundle
    → Profile patch layers

这些角色都可以在当前 package 索引里直接确认。

不过，如果直接把几十个 package 平铺给读者，其实很难建立整体认知。

所以为了理解架构，我们可以做一次工程化重新归类。

注意：下面这个分类不是 DeepSeek 官方真实目录层级，而是本文为了理解 Harness 使用的架构抽象。

---

3. 可以把 packages 重新理解成五层

第一层：Runtime Core

Runtime Core
│
├── core
├── llm
├── session
├── context
├── settings
└── interaction

主要解决：

Agent
Session
Prompt
Tool Registry
LLM
Context
Human Interaction

其中官方核心架构目前明确列出了：

ctx.sessions
ctx.systemPrompt
ctx.tools
ctx.agents
ctx.agentLoop
ctx.llm

这些 Context Service。

---

第二层：Execution Capability

Execution Capability
│
├── fs
├── subprocess
├── shell
├── terminal
├── lsp
├── web
├── code-runtime
└── sandbox

这一层解决：

Agent 到底可以操作什么。

例如：

Filesystem

Process

Shell

PTY

Language Server

Web

Code Execution

---

第三层：Agent Capability

Agent Capability
│
├── skill
├── subagent
├── workflow
├── jobs
├── plan
├── goal
└── preset

这一层开始进入：

Agent 如何组织工作。

例如：

Skill
Delegation
Workflow
Background Job
Plan
Goal
Agent Preset

---

第四层：Runtime Infrastructure

Runtime Infrastructure
│
├── credentials
├── storage
├── workspace
├── hooks
├── extensions
└── telemetry related components

主要解决：

Credential
Storage
Workspace
Lifecycle Extension
Runtime Modification
Observability

---

第五层：Composition / Product Surface

Composition
│
├── bundle
├── boot
├── host
├── client
├── api
└── sdk

主要解决：

这些能力最终怎么被组合成一个可以运行的产品。

---

于是原本看起来非常复杂的几十个 packages，就可以先收敛成：

DeepSeek Harness
│
├── Runtime Core
│
├── Execution Capability
│
├── Agent Capability
│
├── Runtime Infrastructure
│
└── Composition

从这里开始，整个项目就清楚很多了。

---

4. 先画出第一张静态架构图

如果暂时不考虑实现细节，可以得到：

                    DeepSeek Harness
                           │
         ┌─────────────────┼─────────────────┐
         ↓                 ↓                 ↓
    Runtime Core       Capability       Infrastructure
         │                 │                 │
         ├────────────┬────┴───────┬─────────┤
         ↓            ↓            ↓         ↓
       Agent         Tool        Session    Sandbox
         │            │            │
         └────────────┼────────────┘
                      ↓
                  Composition
                      ↓
                    Cordis

但是这里马上出现一个问题：

这些模块到底是怎么连在一起的？

答案就在：

Cordis

---

三、Cordis：为什么 DeepSeek Harness 能做到 Everything is a Plugin

DeepSeek Harness 官方将 Cordis 定义为 dsh 底下的 Framework。

插件通过共享 Context 提供：

Service
Typed Event
Reversible Effect

同时，插件卸载时，对应注册可以反向撤销。

所以第一篇里，可以先把 Cordis 理解成：

Cordis
=
Plugin Runtime
+
Service Composition
+
Event Extension
+
Lifecycle Management

注意，这仍然是为了理解系统而做的工程抽象。

---

1. Context：所有 Plugin 的公共运行空间

Cordis 中一个非常核心的概念是：

Context

Plugin 并不是互相直接硬编码调用。

它们更多是围绕共享 Context 注册或消费能力。

例如官方架构文档列出的：

ctx.sessions

ctx.systemPrompt

ctx.tools

ctx.agents

ctx.agentLoop

ctx.llm

这些都属于 Runtime 中可以被其他 Plugin 使用的 Service。

可以把它抽象成：

                     Context
                        │
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
       Service        Event         Effect
          │             │             │
          ↓             ↓             ↓
      Capability    Extension     Lifecycle

如果熟悉 Spring，可以把其中：

Service

暂时类比成：

Bean / Service Registry

但它并不只是一个普通 DI Container，因为 Cordis 还把：

Event
Effect
Plugin Lifecycle

统一纳入了运行模型。

---

2. Service：Plugin 如何向 Runtime 提供能力

例如：

LLM Plugin
    ↓
ctx.llm

或者：

Tool Plugin
    ↓
ctx.tools

再比如：

Session Plugin
    ↓
ctx.sessions

从工程上可以抽象成：

Plugin
    ↓
Provide Service
    ↓
Context
    ↓
Other Plugins Consume

于是各个 Runtime 部件不需要直接依赖某个固定实现。

这也为后面的：

Provider Replacement

提供了基础。

---

3. Event：Runtime 行为本身就是扩展点

Cordis 的第二个重要机制是：

Event

DeepSeek Harness 官方架构文档明确把 Event 称为扩展点，并把事件大致分成：

Session Events

Agent Events

Capability Events

例如：

agent/*

tools/*

fs/*

这些事件允许 Plugin 在不直接修改 Agent Loop 的情况下介入 Runtime。

例如官方当前的 Tool Pipeline 包含：

tool/call
    ↓
tools/pre-execute
    ↓
tools/execute
    ↓
tools/post-execute
    ↓
tool/result

如果放到我们之前研究 Codex Hook 的语言里，就非常容易理解：

PreToolUse

Tool Execution

PostToolUse

但 DeepSeek Harness 做得更彻底：

Event

不是额外附加在 Harness 外围的一套 Hook 系统，而是 Runtime 自身的扩展机制。

---

4. Effect：Plugin 生命周期为什么可以撤销

Cordis 还有一个非常值得注意的概念：

Effect

官方架构强调，Plugin 的注册本身可以被视为可逆 Effect，Plugin 卸载时对应注册会被撤销。

所以可以抽象成：

Plugin Load
    ↓
Register Service
    ↓
Register Event
    ↓
Create Effects
    ↓
Runtime Running

当 Plugin 被卸载：

Plugin Unload
    ↓
Dispose Effects
    ↓
Remove Events
    ↓
Remove Services

于是 Plugin 不再只是：

startup hook

而拥有真正意义上的：

Lifecycle

这也是动态 Plugin Runtime 必须具备的基础。

---

5. Everything is a Plugin 到底到了什么程度

现在再回来理解官方的：

Everything is a Plugin

就会清楚很多。

官方直接列出的例子包括：

Model Adapter

Tool Registry

Session Log

Agent Loop

这些都是 Plugin，并且都可以通过配置替换。

也就是说：

Agent Loop

并不是所谓：

不可替换的 Harness Kernel

官方文档甚至明确表达了一个非常重要的原则：扩展 dsh 不应该依赖修改某个特殊的特权核心，而是把新的 Plugin 挂到现有 Plugin 旁边。

于是：

Everything is a Plugin

真正表达的是：

Harness Runtime 的组成部件原则上都通过统一 Plugin 机制参与组合，而不是由一个巨大、不可替换的 Core 对外暴露少量扩展点。

这和传统 Plugin System 的区别非常大。

---

四、Capability：Tool、Skill、Subagent 为什么可以统一起来

理解完 Cordis，还不能直接进入 Bundle 和 Profile。

中间还有一个非常重要的概念：

Capability Seam

这是 DeepSeek Harness 设计中非常值得关注的一层。

官方将一个 Seam 定义为一个可替换的 Capability，并且拆成三个角色：

Service Definition

Service Provider

Consumer

这实际上回答了一个非常重要的问题：

Tool 到底是不是 Capability？

DeepSeek Harness 给出的答案更接近：

不是。

---

1. Capability 不是一个 Tool 函数

传统 Agent Framework 很容易把：

read_file()

write_file()

bash()

web_search()

直接称为：

Capability

但实际上 Tool 往往只是模型看到的接口。

真正完成工作的可能是另一个底层实现。

DeepSeek Harness 将它进一步拆成：

Service Definition
        ↓
Service Provider
        ↓
Consumer

例如 Filesystem 可以抽象为：

Filesystem Interface
        ↓
Filesystem Provider
        ↓
read_file / write_file

其中：

Service Definition

定义：

能力是什么

Provider

定义：

能力在哪里执行

而：

Consumer

决定：

谁来使用这个能力

Consumer 很多时候才是：

Model-facing Tool

官方文档明确说明，Consumer 通常可以是面向模型的 Tool，但 Tool 本身并不等同于整个 Capability Seam。

---

2. 用 Filesystem 举一个简单例子

为了理解这个设计，我们可以做一个 Java 风格工程抽象：

interface FileSystem {

    String read(String path);

    void write(String path, String content);

}

这是：

Service Definition

然后可以有：

LocalFileSystemProvider

SandboxFileSystemProvider

RemoteFileSystemProvider

这些是：

Service Provider

最后：

read_file

write_file

search_file

是模型看到的：

Consumer / Tool

于是形成：

                Capability
                    │
          Service Definition
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       Local     Sandbox    Remote
      Provider   Provider   Provider
          │
          └─────────┼─────────┘
                    ↓
                 Consumer
                    ↓
                   Tool

这里的 Java Interface 只是为了理解架构，并不是 DeepSeek Harness 的真实内部类。

---

3. Provider 为什么比 Tool 更值得关注

这种拆分最有价值的地方在于：

Tool 可以不变

但：

Execution Backend 可以变化。

例如 Agent 仍然调用：

bash

但底层可以从：

Local Machine

切换为：

Remote Sandbox

官方架构文档专门以 Filesystem 和 Subprocess 为例说明：它们共享执行世界，因此当 Provider 被指向远程 Sandbox 时，Bash、PTY、LSP 可以一起迁移，而不需要每个 Tool 分别复制一套远程实现。

这个设计非常关键。

因为真正的企业 Harness 往往不是：

Tool 要不要换

而是：

Tool 在哪里执行。

例如：

Developer Laptop

Docker Sandbox

Remote VM

Kubernetes Pod

Secure Execution Environment

都可能提供同一个：

bash

能力。

---

4. Skill、Subagent、Workflow 也被放进 Capability Family

当前官方 package 索引里明确存在：

skill/
subagent/
workflow/

并分别描述为：

Skill capability family

Subagent capability family

Workflow seam

其中 Skill 包含 Provider Registry、本地 Provider 和面向模型的 Catalog/Loader；Subagent 包含 Provider Registry Contract 和 Delegation Tool；Workflow 则包含 Seam、Worker Engine 与面向模型的 Workflow Tool。

因此可以把它们统一理解成：

                    Capability
                         │
       ┌─────────────────┼─────────────────┐
       ↓                 ↓                 ↓
   Filesystem          Skill            Subagent
       │                 │                 │
       ├─────────────────┼─────────────────┤
       ↓                 ↓                 ↓
     Shell            Workflow            Web

这和我们此前习惯的：

Tool
Skill
Agent
Workflow

各自拥有完全独立扩展体系的做法不太一样。

DeepSeek Harness 更倾向于先问：

这个能力的接口是什么？

谁提供它？

谁消费它？

然后再决定它最终表现成：

Tool

Agent

Workflow

UI

中的哪一种形式。

---

五、Plugin、Bundle、Profile：一个 Harness Runtime 是怎样“拼”出来的

到这里，我们已经知道：

Plugin

可以提供 Service、Event 和 Effect，

也知道：

Capability

可以由 Definition、Provider 和 Consumer 组成。

但还有一个更关键的问题：

dsh 启动时到底加载哪些 Plugin？

答案并不是一个固定写死的列表。

而是：

Profile
+
Bundle
+
Patch

共同完成 Runtime Composition。

---

1. Plugin：Runtime 最基本的组成单元

首先是：

Plugin

从我们目前看到的架构，可以把它理解为：

Runtime Component

例如：

LLM Adapter Plugin

Tool Plugin

Session Plugin

Agent Loop Plugin

Sandbox Plugin

Plugin 进入 Cordis Context 后，可以：

Provide Service

Listen Event

Create Effect

最终成为 Runtime 的组成部分。

---

2. Bundle：一组 Plugin 的组合与分发

如果只有 Plugin，会出现另一个问题：

一个完整 Harness 可能需要几十个 Plugin。

每次启动时逐个配置：

Plugin A
Plugin B
Plugin C
Plugin D
...

显然不可维护。

因此 DeepSeek Harness 又增加了：

Bundle

官方当前定义的 Bundle 是一个 npm package，它通过 package manifest 中的 dsh.bundle 指向一个 cordis.patch.yml，从而成为 Profile 可以加载的一层 Patch。

可以把它理解成：

Bundle
=
Plugin Composition Package

结构大致可以抽象成：

my-bundle/
│
├── package.json
│       │
│       └── dsh.bundle
│
├── cordis.patch.yml
│
└── optional runtime glue

Bundle 最核心的内容并不是一个巨大 Runtime 类，

而是：

哪些 Plugin Row 应该被挂载。

---

3. 官方当前有三个关键 Bundle

目前官方 Bundle 目录明确列出了：

base

web-app

headless

其中：

base

是所有 Profile 先加载的共享核心层；

web-app

增加浏览器侧运行面；

headless

增加无 Host / Web Layer 的一次性任务运行方式。

官方 dsh-base 当前包含的基础 Runtime 组合涉及：

Model Adapters

Default Model Selection

Tools

Persistence

Policy

Settings / Credentials

Telemetry

Subagent Providers

等能力，并作为每个 Profile Bundle Stack 的第一层。

所以：

dsh-base

可以粗略理解为：

Default Runtime Foundation

但仍然要注意：

它不是一个不可修改的 Core Binary。

它本质仍然是：

一层 Runtime Composition。

---

4. Profile：决定“我要启动哪一种 dsh”

在 Bundle 之上，还有：

Profile

官方定义 Profile 是一个存在于 Harness Home 中的命名组合，它记录：

要堆叠哪些 Bundles

安装哪些额外 Plugin

用户自己的 cordis.patch.yml

当前官方提供：

web

headless

两个模板。

所以：

web

可以先抽象理解为：

Profile: web
│
├── dsh-base
├── dsh-web-app
└── user patch

而：

headless

则大致是：

Profile: headless
│
├── dsh-base
├── dsh-headless
└── user patch

于是三者的关系就清楚了：

Plugin
    → Runtime Component

Bundle
    → Plugin Composition Package

Profile
    → Named Runtime Composition

---

5. Patch：为什么 Runtime 可以层层覆盖

这里最关键的配置文件是：

cordis.patch.yml

官方架构目前给出了明确的层叠顺序：

Empty Entry List
        ↓
Profile 中声明的 Bundles
        ↓
Profile cordis.patch.yml
        ↓
Home cordis.patch.yml
        ↓
--patch CLI Overlay

所以真正启动出来的 Runtime 并不是某一份固定配置，而是：

Bundle A
+
Bundle B
+
Profile Patch
+
Home Patch
+
CLI Patch
=
Effective Plugin Tree

这个机制和我们前面分析 Codex 时的：

Effective Config

有一点很像。

但它更进一步。

Codex 更多是在计算：

最终哪个配置值生效。

DeepSeek Harness 这里实际上是在计算：

最终有哪些 Plugin Row 存在，
以及它们共同构成怎样的 Runtime Topology。

所以可以把它称为：

Effective Runtime

或者更精确一点：

Effective Plugin Tree

官方也提供了：

dsh --profile web --dump-config

来查看当前环境真正会启动的组合树。

---

6. 所以 dsh 的启动过程是什么

到这里就可以把启动过程串起来。

传统 Harness 很容易理解成：

Harness Start
    ↓
Initialize Core
    ↓
Load Config
    ↓
Discover Plugins
    ↓
Register Plugins
    ↓
Start Runtime

DeepSeek Harness 更接近：

dsh Start
    ↓
Select Profile
    ↓
Resolve Bundle Stack
    ↓
Apply Patch Layers
    ↓
Build Plugin Tree
    ↓
Mount Plugins
    ↓
Register Services
    ↓
Register Events
    ↓
Create Effects
    ↓
Construct Runtime
    ↓
Start Agent Loop

官方明确描述运行中的 dsh 是在启动阶段，从有序 Layers 组合出来的 Plugin Tree。

所以这里真正重要的一句话是：

Runtime 并不是先存在然后再加载 Plugin；Runtime 本身就是 Plugin Composition 的结果。

---

7. 再看 Agent Loop，就容易理解了

官方当前把一次执行区分成：

Turn

Step

其中一个 Step 是：

一次模型请求
+
该请求产生的 Tool Calls

一个 Turn 则可以包含零到多个 Step。

核心链路可以简化成：

turn/start
    ↓
claim input
    ↓
assemble prompt + tools
    ↓
agent/pre-step
    ↓
step/start
    ↓
derive model history
    ↓
agent/request
    ↓
llm/stream
    ↓
assistant/message
    ↓
tool/call
    ↓
tools/pre-execute
    ↓
tools/execute
    ↓
tools/post-execute
    ↓
tool/result
    ↓
step/end
    ↓
Next Step?
    ↓
turn/end

为什么这条链可以高度扩展？

因为：

Agent Loop

不是把所有逻辑硬编码进去。

大量行为通过：

Service
+
Event

参与 Runtime。

例如：

agent/pre-step

可以介入模型即将看到的输入；

tools/pre-execute

可以介入 Tool 执行之前；

tools/post-execute

可以处理执行后的结果。

这就是：

Composable Runtime

真正进入运行阶段后的样子。

---

六、重新理解 DeepSeek Harness：从 Plugin System 到 Composable Runtime

把前面的结构连起来之后，就可以看出 DeepSeek Harness 真正值得研究的地方了。

它不仅仅是在做：

一个新的 Coding Agent

而是在探索：

Agent Harness 本身应该怎样被构造。

---

1. 它和传统 Harness 最大的区别是什么

如果用最简化的方式表达：

传统 Harness 更接近：

              Harness Core
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
       Skill     Tool     Plugin

DeepSeek Harness 更接近：

               Profile
                  │
               Bundles
                  │
                Patch
                  │
                  ↓
              Plugin Tree
                  │
          ┌───────┼────────┐
          ↓       ↓        ↓
        LLM      Tool    Session
          │       │        │
          └───────┼────────┘
                  ↓
              Agent Loop
                  ↓
                Runtime

这两种架构关注的问题并不完全一样。

第一种问：

Harness 有哪些 Extension Point？

第二种则进一步问：

Harness 本身能不能就是一种 Composition？

---

2. Plugin System 和 Composable Runtime 不是一回事

很多系统都有：

Plugin System

但通常意味着：

Core
+
Optional Extensions

DeepSeek Harness 更值得注意的是：

Core-like Components

本身也进入 Plugin Composition。

于是：

Plugin

不再只是：

给 Runtime 增加一个功能

还可能：

参与定义 Runtime 本身。

所以我更愿意把 DeepSeek Harness 当前的架构称为：

Composable Agent Runtime

而不只是：

Plugin-based Agent

这是本文基于官方架构做出的工程抽象，不是 DeepSeek 官方给出的正式架构名称。

---

3. 这会改变我们对 Marketplace 的理解

我们之前研究 Claude Code、Codex 时，逐渐形成了一个 Marketplace 模型：

Marketplace
    ↓
Plugin Package
    ↓
Install
    ↓
Capability Registry
    ↓
Harness Runtime

也就是说：

Marketplace

主要负责分发：

Capability

例如：

Skill

Tool

Agent

MCP

Hook

但是到了 DeepSeek Harness，这个模型可能需要再增加一层：

Marketplace
    ↓
Plugin / Bundle
    ↓
Profile
    ↓
Runtime Composition
    ↓
Plugin Tree
    ↓
Capability
    ↓
Agent Runtime

这意味着 Marketplace 未来分发的不一定只是：

一个能力

还可能是：

一套 Runtime 组合方案。

例如可以设想：

Java Coding Profile

Security Review Profile

Research Profile

Data Analysis Profile

每个 Profile 都可能组合不同的：

Model Adapter
Tool Set
Skill
Subagent
Workflow
Sandbox
Policy
Agent Loop

所以：

Marketplace 中的商品，可能从 Capability Package 进一步演进成 Runtime Blueprint。

这是 DeepSeek Harness 对我们整个 Harness Marketplace 系列非常重要的一个启发。

---

4. 对自研 Harness 的启发：Registry 之外还需要 Composer

我们此前设计企业 Agent Harness 时，很容易想到：

PluginRegistry

CapabilityRegistry

SkillRegistry

AgentRegistry

ToolRegistry

PolicyRegistry

这些组件解决的是：

系统里有哪些能力。

但是 DeepSeek Harness 提醒了我们另外一个问题：

这些能力如何组成不同类型的 Runtime？

于是可能还需要：

BundleRegistry

RuntimeProfile

RuntimeComposer

形成：

                    Marketplace
                         │
                         ↓
                   PluginRegistry
                         │
                         ↓
                   BundleRegistry
                         │
                         ↓
                  RuntimeProfile
                         │
                         ↓
                  RuntimeComposer
                         │
                         ↓
                  Effective Runtime
                         │
                         ↓
               CapabilityRegistry
                         │
                         ↓
                    Agent Loop

例如可以做一个工程抽象：

record RuntimeProfile(
    String name,
    List<String> bundles,
    List<String> plugins,
    String policyProfile
) {}

再通过：

RuntimeProfile
    ↓
BundleResolver
    ↓
PluginResolver
    ↓
RuntimeComposer
    ↓
Effective Runtime

构建不同的 Agent 环境。

这不是 DeepSeek Harness 的真实 Java 实现，而是我们从它的架构模式推导出的自研 Harness 设计。

---

5. 不同 Agent 甚至可以拥有不同 Runtime

例如：

Developer Agent

可以组合：

Filesystem Write
Shell
LSP
Git
Skill
Subagent

而：

Reviewer Agent

可以组合：

Filesystem Read
Search
LSP
No Shell Write
No Network

Production Agent 则可能使用：

Remote Sandbox

Strict Permission

Audited Tool Gateway

Restricted Network

这已经不是简单：

Tool Permission

问题。

而是：

Runtime Composition

问题。

---

6. Everything is a Plugin 也会带来新的治理难题

当然，这种高度插件化设计并不是只有好处。

越多东西可以替换，就意味着越多东西需要治理。

例如：

谁可以安装 Plugin？

谁可以发布 Bundle？

谁可以修改 Profile？

Plugin 可以注册哪些 Service？

一个 Plugin 能否替换 Agent Loop？

谁可以提供 Sandbox Provider？

谁可以提供 Credential Provider？

不同 Plugin 出现 Service 冲突怎么办？

甚至更危险的问题是：

如果安全组件自己也是 Plugin，
谁来保证这个 Plugin 不被替换？

所以企业环境最终一定需要建立：

Plugin Trust

Bundle Trust

Profile Policy

Provider Allowlist

Signature

Version Pin

Capability Diff

Permission Review

Audit

换句话说：

Everything is a Plugin

最终很自然会推导出：

Everything needs Governance

这也会成为 DeepSeek Harness 系列后面权限、Sandbox 和企业 Marketplace 篇的重要问题。

---

7. 最后把整个 DeepSeek Harness 收敛成一张图

经过这一篇，我们可以先形成下面这张统一架构图：

                         Marketplace
                              │
                              ↓
                       Plugin / Bundle
                              │
                              ↓
                           Profile
                              │
                         Patch Layers
                              │
                              ↓
                        Plugin Tree
                              │
                              ↓
                       Cordis Context
                              │
           ┌──────────────────┼──────────────────┐
           ↓                  ↓                  ↓
        Service             Event              Effect
           │                  │                  │
           ↓                  ↓                  ↓
      Capability          Extension          Lifecycle
           │
           ↓
     Capability Seam
           │
    ┌──────┼──────┬────────┬───────────┐
    ↓      ↓      ↓        ↓           ↓
   FS    Shell   Skill   Subagent   Workflow
    │
    ↓
 Provider
    │
    ↓
Consumer / Tool
    │
    ↓
 Agent / Agent Loop
    │
    ↓
 Session / Observation
    │
    ↓
 Next Step

如果继续压缩，可以得到 DeepSeek Harness 当前最核心的一条链：

Profile
    ↓
Bundle Stack
    ↓
Patch Layers
    ↓
Plugin Tree
    ↓
Cordis Context
    ↓
Services / Events / Effects
    ↓
Capability Seams
    ↓
Agent Runtime
    ↓
Agent Loop

---

结语：DeepSeek 开源的可能不只是另一个 Coding Agent

如果只从产品使用角度看：

DeepSeek Harness

当然可以被理解为：

一个新的 AI Coding Harness。

但从 Agent Engineering 的角度，它更值得研究的问题其实是：

一个 Agent Harness 到底应该拥有多大的固定 Core？

Claude Code、Codex 让我们重点看到的是：

如何给 Harness 增加能力。

DeepSeek Harness 则把问题进一步推进到：

Harness 本身能不能也是一种可组合对象？

于是：

Model

Tool

Skill

Subagent

Workflow

Session

Agent Loop

Sandbox

不再只是：

Harness 内部的固定组件

而越来越像：

Runtime Composition 中可以选择、提供、替换的服务。

这也是：

Everything is a Plugin

真正值得关注的地方。

它并不只是一个 Plugin API。

它背后真正体现的是一种：

Composable Agent Runtime

架构。

而要真正理解这套架构，下一步就必须继续往下进入它的底层：

DeepSeek Harness：深入 Cordis，Everything is a Plugin 到底是怎么实现的

下一篇我们将重点拆解：

Context
    ↓
Service
    ↓
Plugin
    ↓
Effect
    ↓
Event
    ↓
Inject
    ↓
Isolate
    ↓
Plugin Lifecycle
    ↓
Plugin Tree

真正从源码和运行机制层面回答：

一个 Plugin 是如何进入 Cordis 的？

Service 是如何注册和发现的？

Plugin 为什么能够卸载？

Event 为什么能够改写 Runtime？

Plugin 之间如何形成依赖？

最终又是怎样一步步组成 Agent Harness 的？

到了那里，DeepSeek Harness 的：

Everything is a Plugin

才算真正被拆开。