一切皆插件：DeepSeek Harness 想重新定义 Agent 的“骨架”

参考资料：

code.claude.com/docs/en/plu...

www.deepseek.com/harness/

github.com/topics/dsh-...

前言

过去一年，我们讨论 Coding Agent 时，注意力几乎都放在了模型上

Claude Code 背后是 Claude，Codex 背后是 GPT，DeepSeek 也在不断推出更适合代码与 Agent 场景的模型。于是很多时候，我们会下意识地认为：一个 Agent 好不好用，主要取决于它背后的模型够不够强

但真正用过不同 Coding Agent 之后，你很快会发现一个有意思的现象：

即使底层模型能力接近，换一个 Agent，实际体验也可能完全不同

它什么时候读取文件？什么时候调用工具？上下文如何组织？任务失败后要不要重试？什么时候压缩上下文？是否需要权限确认？多个 Agent 又该如何协作？

这些事情，其实都不是模型本身决定的，在模型之外，还存在着另外一层越来越重要的东西------Harness

实际上 DeepSeek 就在最近公布了他的 Harness，打开github.com/deepseek-ai... README，没有大篇幅的描述他的实现原理和架构，而留下了非常吸引眼球的一句话： everything is a plugin

大家都有插件，为什么 DeepSeek 还要强调「Everything is a Plugin」？

在我看见这个README 的时候就产生了一个疑问🤔，这有什么特别的？Claude Code 不也有 Plugin、Skill、Hook、MCP 吗？但实际上他们的差别是非常巨大的，你可以这么理解，Claude Code、Codex 是给房子添家具；DeepSeek 是连墙、门、厨房甚至户型本身都做成了可替换模块"

css 复制代码

Claude Code / Codex

┌─────────────────────┐
│      Plugins        │  ← Skills / MCP / Connectors...
├─────────────────────┤
│     Agent Core      │  ← Loop / Runtime / 内置能力
├─────────────────────┤
│       Model         │
└─────────────────────┘

而DeepSeek 走了一个完全不一样的路：

vbnet 复制代码

DeepSeek Harness

┌──────────────────────────────────┐
│            Cordis Core           │
│        Service / Event / DI      │
├──────────────────────────────────┤
│ Model Plugin     Tool Plugin     │
│ Skill Plugin     Session Plugin  │
│ Sandbox Plugin   Storage Plugin  │
│ Loop Plugin      Scheduler       │
│ UI Plugin        ...             │
└──────────────────────────────────┘

这个实现思路就和之前的完全不一样了，在 DeepSeek 的理解中，Harness 不应该是一套固定的 Agent 实现，而应该是一套组装 Agent 的框架

回到我们的疑惑，为什么 DeepSeek 要把一切都给插件化，为了解决什么问题？在我看来 DeepSeek Harness 是一个潜力非常大的产品，他将一切可插件化也就意味着他把可扩展性都交给用户，为什么现在 Agent 迭代这么快？为什么都没有一个统一的方案？各家都有各家的产品的实现思路？

实际上，现在大家都还在摸索阶段，对于 Agent 的开发并没有一个统一的标准，这一点在我之前和某大厂面试官交流的时候也能感受到

**那么在我看来，DeepSeek 将一切插件化，想解决的其实是 Harness 迭代速度跟不上模型迭代速度的问题。**现在 Agent 变化太快了。今天大家觉得 ReAct 好用，明天可能换成 plan-execute；今天用本地 shell，明天可能换 sandbox；不同模型甚至可能适合完全不同的 context 管理、tool calling、agent loop

如果这些东西全部写死在 Harness 里面，每做一次实验都得：

复制代码

改核心代码
→ 测试
→ 处理耦合
→ 重新发布

而 DeepSeek 的思路是：

复制代码

换一个 Plugin
→ 改配置
→ 重新组合

所以 Everything is a Plugin 最重要的价值其实不是"扩展性"，而是"可实验性"，与其说现在的 DeepSeek Harness 是一款产品，倒不如说是 DeepSeek 相当于把 Harness 从一个产品，变成了一个实验台

体验 DeepSeek Harness：既然是实验台，那我们就做一个有点离谱的实验

前面说了这么多，如果最后只是打开聊天框问一句 Hello World，其实很难感受到 DeepSeek Harness 和其他 Coding Agent 到底有什么区别

既然 DeepSeek 一直在强调 Everything is a Plugin，那我觉得体验它最好的方式也不是让它写一段代码，而是亲手换掉其中的一小块

所以这一次，我决定做一个稍微有点离谱的实验：

能不能让 Harness 在运行命令的时候监听环境声音，如果我突然拍一下桌子，它就大喊一声"我有异议"，然后立刻把正在运行的命令中断掉🤔

先把 DeepSeek Harness 跑起来

目前最简单的体验方式是直接运行：

arduino 复制代码

npm config set registry <https://registry.npmjs.org/>
npx @deepseek-ai/dsh web

终端里出现：

arduino 复制代码

dsh web: <http://127.0.0.1:3080>

第一次打开时，它会提醒你这还是开发者预览版，并让你配置 DeepSeek API Key。这个阶段的 Harness 很明显还不是一个"下载完就能直接干活"的成熟产品，它更像是一套正在快速生长的开发框架

打开插件列表，我开始理解「Everything is a Plugin」了

进入「设置 → 插件 → 插件列表」之后，会看到一个非常夸张的插件清单

我这次从源码构建的版本里一共显示了 134 个插件，这个数字会随着预览版本变化，但真正有意思的不是数量，而是里面装的东西：

llm、session、sandbox-local、agent-loop、tool-bash、compaction、storage，甚至 ui-layout 本身都是插件

从源码构建的预览版插件清单，这次显示 134 个插件

也就是说，这里所谓的插件并不是我们平时理解的"给 Agent 多装一个能力"，而是 Agent 自己就是由这些插件拼出来的

如果把普通 Agent 的插件系统比作给汽车加一个行车记录仪，那么 DeepSeek Harness 更像是连发动机、变速箱、方向盘和仪表盘都可以单独拆下来换

给 Harness 装一个「拍桌中断器」

这个实验的目标可以拆成下面几步：

scss 复制代码

拍桌 / 敲击桌面
→ Web Audio API 检测瞬时声音峰值
→ 播放"我有异议"
→ 调用当前 Session 的 cancel()
→ AbortSignal 传到命令执行器
→ 终止正在运行的进程树

我给它起了一个很直白的名字：ui-objection

插件本身并不复杂，它是一个纯 Web 客户端插件，挂载之后会在 Harness 右上角多出一个「拍桌中断器」。为了避免直接使用游戏原声，我没有复制《逆转裁判》的音频，而是让浏览器通过 SpeechSynthesis 合成一句原创的"我有异议"，保留一点戏剧感就够了

ui-objection 插件挂载后的界面，可以调节灵敏度，也可以手动模拟拍桌

声音检测部分其实很朴素，浏览器会不断读取麦克风的时域数据，计算这一帧声音的峰值：

javascript 复制代码

analyser.getByteTimeDomainData(samples)

let peak = 0
for (const value of samples) {
  peak = Math.max(peak, Math.abs(value - 128) / 128)
}

if (peak >= Number(threshold.value)) {
  void object()
}

真正关键的代码反而只有几行：

ini 复制代码

const current = ctx.sessions.list.getSnapshot().current
const session = ctx.sessions.binding(current)?.session
const result = await session.cancel()

return result.ok

这里最能体现 Harness 的地方是：这个插件不需要让模型先"听懂"我在拍桌子，也不需要在 Prompt 里教模型什么时候停止。

它直接拿到了 Session 服务，在声音触发后调用 cancel()。取消信号会继续传给 Agent 和命令执行器，正在执行的 Bash 进程树也会被终止

换句话说，这不是"建议模型停下来"，而是在 Harness 的控制层直接踩下急刹车

拍一下桌子，会发生什么？

为了方便测试，我还给插件加了一个「模拟拍桌」按钮。这样即使没有授权麦克风，也可以稳定复现整个触发过程

点击之后，界面会立刻进入红色的 OBJECTION 状态，同时浏览器念出"我有异议"，然后尝试取消当前会话：

模拟拍桌触发后的状态

这和给 Agent 写一个 Skill 有什么区别？

做到这里之后，我才真正理解 DeepSeek 为什么要强调 Everything is a Plugin

如果这是一个 Skill，我们能做的通常是告诉模型：

当用户拍桌子时，请停止当前任务

问题是模型根本听不到拍桌子，而且即使它"理解"了，正在运行的命令也不一定会立刻停止

但插件可以直接接触 Harness 的运行时服务。它可以监听浏览器事件、替换 UI、读取 Session、调用取消接口，甚至继续往下换掉 Sandbox 或 Agent Loop

所以 Skill 更像是教 Agent 一套新的做事方法，而 Harness Plugin 是在改造 Agent 的身体结构

实际体验之后，我怎么看 DeepSeek Harness？

先说最爽的地方：可实验性确实非常强。

我不需要去修改 Agent 的核心循环，也不需要 fork 一整套产品。只要新增一个客户端插件，把它写进组合配置里，重新构建之后，页面就真的多出了一块新的能力。在插件列表里搜索 ui-objection，也可以看到它已经被 Harness 正常挂载，可以单独看到它的挂载状态：

自定义插件 ui-objection 已经被 Harness 挂载并启用

但我现在并不会把 DeepSeek Harness 看成一个"更好用的 Claude Code"，它更像是一套用来研究下一代 Agent 应该如何组装的实验设备，更适合我们去探索 Harness 各式各样的玩法，目前DSH 的 plugin 社区也出现了很多有意思的内容 github.com/topics/dsh-...

在我看来，DSH 更多的是面向想研究 Agent Loop、上下文管理、Sandbox、多人协作，或者想验证一种全新交互方式的人来说，这种自由度非常诱人

而这次"拍桌中断器"的实验虽然有点搞笑，却刚好说明了 Everything is a Plugin 真正有意思的地方：

当 Harness 本身也可以被改造时，我们能实验的就不再只是"让模型做什么"，而是"Agent 到底可以长成什么样"