DeepSeek Harness 插件化架构深度解析：一切皆插件，Agent 操作系统的"乐高时刻"
一、引言：一个不寻常的夜晚
2026年8月13日晚，DeepSeek 做了一件看起来有些反常的事：它没有发布新的模型权重，而是把一个名为 DeepSeek Harness（简称 DSH，命令行名 dsh）的开源项目甩到了 GitHub 上，MIT 协议，代码全开。
同一天晚上，DeepSeek 还做了两件事：先宣布 API 调价方案（V4 Pro 高峰输出价从 6 元涨到 27 元/百万 token），随后上线 DeepSeek-V4-Pro-0813 正式版。一晚上三件事叠在一起，想不上热搜都难。
但真正引爆社区的不是涨价，也不是新模型，而是这个 Harness。
上线首日，GitHub 星数在半小时内破万，1.5 小时破 22,000，速度超过 Grok-1 和 DeepSeek-R1 当年破 2 万星的纪录。到 8 月 15 日，总星数已超过 6 万。GitHub 上打 dsh-plugin 标签的仓库超过 1000 个，社区插件的增长速度甚至超过了官方预期。
这到底是个什么东西？为什么它能让整个开发者社区如此兴奋？
本文将从架构角度，深入拆解 DeepSeek Harness 的插件化设计——从 Cordis 微内核到三层插件运行时，从四种运行模式到 Trajectory 轨迹系统，再到它与 Claude Code、Codex 的架构哲学差异。
二、定位：Model + Harness = Agent
首先厘清一个关键问题：Harness 不是新模型。
DeepSeek 官方给出了一个简洁到不能再简洁的公式：
Model + Harness = Agent
模型负责思考推理，Harness 负责实际执行——读文件、调工具、管理上下文、跑终端命令、调度子 Agent、失败重试……所有模型"自身做不到"的事情，都由 Harness 来完成。
可以把 Harness 理解为"Agent 的操作系统"。
┌──────────────────────────────────────────────┐
│ Agent │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Model (灵魂) │ │
│ │ 思考、推理、决策、生成代码 │ │
│ └──────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ Harness (身体/操作系统) │ │
│ │ ┌────┐ ┌────┐ ┌──────┐ ┌───────┐ │ │
│ │ │工具│ │会话│ │沙箱 │ │存储 │ │ │
│ │ ├────┤ ├────┤ ├──────┤ ├───────┤ │ │
│ │ │循环│ │调度│ │子Agent│ │UI │ │ │
│ │ └────┘ └────┘ └──────┘ └───────┘ │ │
│ └──────────────────────────────────────┘ │
└──────────────────────────────────────────────┘
这个定位直接对标的是 Anthropic 的 Claude Code 和 OpenAI 的 Codex。但 DeepSeek 从第一天就没打算做一个"更好用的 Claude Code"，它走的是另一条路——把这一层整个开源化。
这个区别，至关重要。
三、核心设计理念：“Everything is a Plugin”
Harness 的核心设计理念只有一句话，写在仓库首页最显眼的位置：
“Everything is a Plugin”——一切皆插件。
这不是营销口号，而是一个彻底的技术承诺。
在 Harness 中，下列所有能力模块都是可替换的插件：
DeepSeek Harness 插件全景图
┌─────────────────────────────────────────────────────┐
│ │
│ 模型适配器 (Model Adapter) ← 插件 │
│ 工具注册表 (Tool Registry) ← 插件 │
│ 技能 (Skills) ← 插件 │
│ 会话管理 (Session) ← 插件 │
│ 沙箱 (Sandbox) ← 插件 │
│ 存储 (Storage) ← 插件 │
│ Agent 循环 (Agent Loop) ← 插件 │
│ 调度器 (Scheduler) ← 插件 │
│ 用户界面 (UI) ← 插件 │
│ 审批策略 (Approval Policy) ← 插件 │
│ 凭据管理 (Credential) ← 插件 │
│ 遥测 (Telemetry) ← 插件 │
│ │
│ ──── 没有一行代码是焊死在框架里的 ──── │
│ │
└─────────────────────────────────────────────────────┘
这意味着什么？意味着：
- DeepSeek 自己的模型没有特殊地位，它只是又一个插件。你想换成 Claude、GPT、Gemini、Kimi、GLM——跟换个主题皮肤是同一个操作。
- 连 Web UI 界面本身也是插件。默认的界面不够用？社区已经有人把整个界面重写成了 Claude Code 风格的全屏终端。
- Agent Loop 也是插件。如果你对默认的循环逻辑不满意，可以自己写一个自定义循环插件顶替。
- 沙箱也是插件。社区里有 sandbox-micro、sandbox-mxc、sandbox-nono 三个沙箱插件，对应三种隔离方案，挑一个换上就行。
官方文档里有一句话说得特别好：“没有特权核心需要修补。” 你想扩展 Harness，不用改源码，在旁边挂一个插件就行。
四、Cordis 插件元框架：时空可组合性的数学根基
如果说"一切皆插件"是 Harness 的 slogan，那 Cordis 就是让这句话成为现实的底层引擎。
4.1 Cordis 是什么
Cordis（拉丁语意为"心"）是一个元框架（Meta Framework）——即"用于构建框架的框架"。它不耦合任何具体业务领域，只专注于解决一个核心问题：如何让软件的各个组件可以安全地组合、热插拔，并在卸载时完整逆转其所有副作用。
Cordis 最初从知名的聊天机器人框架 Koishi 中抽离出来，作为其底层插件系统独立发展。Koishi 在四年间积累了超过 4000 个社区插件，覆盖即时通讯适配器、数据库驱动、管理控制台等各类功能，Cordis 的成熟度经过了长期生产验证。
Cordis 架构层级
┌─────────────────────────────────────────────────┐
│ Koishi 应用层 │
│ (聊天机器人框架，4000+ 社区插件) │
├─────────────────────────────────────────────────┤
│ Cordis 元框架 │
│ ┌──────────┐ ┌──────────┐ ┌───────────────┐ │
│ │ 插件加载 │ │ 插件卸载 │ │ 依赖管理 │ │
│ │ 生命周期 │ │ 副作用 │ │ 服务注册/发现 │ │
│ │ 管理 │ │ 回收 │ │ 事件通信 │ │
│ └──────────┘ └──────────┘ └───────────────┘ │
├─────────────────────────────────────────────────┤
│ DeepSeek Harness 应用层 │
│ (模型/工具/会话/沙箱/存储/循环/UI 等插件) │
└─────────────────────────────────────────────────┘
2026 年 8 月，北京大学与 DeepSeek 联合发表论文 《A Programming Paradigm for Spatiotemporal Composability》（《一套处理时空可组合性的编程范式》），作者包括 Yifan Shi（同时属 DeepSeek）、Wei Zhang，以及 DeepSeek Harness 团队负责人崔添翼（Tianyi Cui）。这篇 80 多页的论文，为 Cordis 的设计建立了形式化模型，正文包含二十多个定理和证明。
4.2 时间可组合性：可逆副作用
时间可组合性（Temporal Composability） 解决的是这样一个问题：
传统软件架构中，组件安装后往往难以干净地卸载。一个模块可能注册了事件监听器、打开了文件句柄、修改了全局状态，当它被移除时，这些副作用常常残留，导致内存泄漏、状态污染甚至系统崩溃。
论文做了一个实证：截至 2026 年 6 月 9 日，VSCode Marketplace 排名前 100 的扩展中，87 个包含可执行代码，一旦激活就无法在运行时单独卸载，禁用或删除后必须重启整个扩展宿主。
Cordis 的解法是 可逆副作用（Reversible Effects）：
插件加载时的副作用追踪
┌─────────────────────────────────────────────────┐
│ 时间轴 → │
│ │
│ 插件 A 加载 │
│ ├─ ctx.on('event', handler1) → 记录 disposer1 │
│ ├─ ctx.effect(conn.open()) → 记录 disposer2 │
│ └─ ctx.service('my-svc', impl) → 记录 disposer3│
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ 撤销栈 (逆序执行) │ │
│ │ [disposer3, disposer2, disposer1] │ │
│ │ → 卸载时从栈顶开始依次执行 │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ 插件 A 卸载 │
│ ├─ 执行 disposer3 (撤销服务注册) │
│ ├─ 执行 disposer2 (关闭连接) │
│ └─ 执行 disposer1 (移除事件监听) │
│ │
│ 系统状态 = 精确恢复到插件 A 加载前的状态 │
└─────────────────────────────────────────────────┘
每个插件注册时产生的所有副作用都会被追踪，卸载时自动回收，不留垃圾、不漏内存。这个特性翻译成使用体验就是热插拔——装插件、卸插件、换整套 UI，都不用重启，系统跑着跑着就把自己的一部分换掉了。
4.3 空间可组合性：反应式依赖
空间可组合性（Spatial Composability） 解决的是另一个问题：
复杂系统中，组件之间存在大量隐式依赖。A 模块依赖 B 模块的某个功能，但如果没有显式声明，系统无法知道 B 必须在 A 之前加载，也无法在 B 不可用时优雅地处理 A 的行为。
Cordis 的解法是 反应式余效应（Reactive Coeffects）：
插件依赖的自动编排
┌─────────────────────────────────────────────────────────┐
│ │
│ 插件 B: 数据库驱动 │
│ inject: [] │
│ provide: ['database'] │
│ │
│ ↓ 提供 database 服务 │
│ │
│ 插件 A: 聊天功能 │
│ inject: ['database', 'messenger'] │
│ provide: ['chat'] │
│ └─ 等待 database 和 messenger 就绪后 → ACTIVE │
│ │
│ ↓ 依赖者自动激活 / 提供者撤走 → 依赖者自动暂停 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 插件 A │──────▶│ 插件 B │──────▶│ 插件 C │ │
│ │ (依赖方) │ │ (提供方) │ │ (提供方) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │
│ │ 依赖 database │ 依赖 messenger │
│ ▼ ▼ │
│ ACTIVE ← 依赖满足 ACTIVE ← 依赖满足 │
│ INACTIVE → 依赖缺失 INACTIVE → 依赖缺失 │
│ │
│ 依赖关系变化时，系统自动推导拓扑编排，无需手写 │
└─────────────────────────────────────────────────────────┘
插件通过 inject 属性声明所需服务。Cordis 会等待这些服务就绪后，才启动该插件。提供者出现，依赖者自动激活；提供者撤走，依赖者先停下来，等它把自己的 effect 撤回之后，提供者再完成卸载。
4.4 Cordis 的五大核心概念
Cordis 用五个概念构成完整的设计体系：
| 概念 | 作用 | 说明 |
|---|---|---|
| Plugin（插件） | 能力单元 | 实现 Service 的对象，可以是带 inject 和 apply(ctx) 的函数，也可以是 Service 子类 |
| Context（上下文） | 服务容器 | 一个"服务仓库"，每个服务占一个稳定的键，如 ctx.tools、ctx.llm、ctx.sessions |
| Inject（依赖注入） | 依赖声明 | 插件声明它需要哪些服务，加载器保证这些服务先就位 |
| Typed Events（类型化事件） | 通信机制 | 四种派发模式：emit（观察）、waterfall（中间件式可短路）、parallel（并行）、serial（串行） |
| Reversible Effects（可逆副作用） | 安全卸载 | 所有注册动作通过 ctx.effect() / ctx.on() 安装，插件卸载时自动回滚 |
Cordis 的核心实现极为精简，约 2000 行 TypeScript 代码。这种精简性意味着心智负担很低——开发者不需要学习庞大的 API，只需理解"插件-上下文-副作用"这一核心三角即可。
五、三层插件运行时架构
DeepSeek Harness 的运行时架构可以清晰地划分为三个层次，每一层解决不同粒度的问题。
第一层：组装层（Assembly Layer）
组装层解决的是"一个运行实例由哪些插件组成"的问题。
第一层：组装层 (Assembly Layer)
┌──────────────────────────────────────────────────────────┐
│ │
│ Bundle (可分发插件组) │
│ ┌────────────────────────────────────────────────────┐ │
│ │ dsh-base (所有 profile 的基础层) │ │
│ │ ├─ 模型适配器 ├─ 工具注册表 │ │
│ │ ├─ 持久化 ├─ 沙箱 │ │
│ │ ├─ 审批策略 ├─ 设置 │ │
│ │ ├─ 凭据管理 ├─ 遥测 │ │
│ │ └─ ... │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ Profile (命名运行时组合) │
│ ┌────────────────────────────────────────────────────┐ │
│ │ profile: web │ │
│ │ bundles: [dsh-base, dsh-web-ui, ...] │ │
│ │ config: cordis.patch.yml │ │
│ │ └─ 用户可以通过 patch 覆盖任意配置 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ Preset (预设模式 = 预定义 Profile) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 标准模式 │ │ PTC模式 │ │ 极简模式 │ │ 创造模式 │ │
│ │ (standard)│ │ (code) │ │ (minimal)│ │ (creator)│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 想查看实际加载了什么，运行： │
│ $ dsh --profile web --dump-config │
│ → 打印的每一行都能用你自己的 patch 覆盖 │
│ │
└──────────────────────────────────────────────────────────┘
Bundle 是 Cordis 配置行 + 代码的分发格式。dsh-base 是所有 profile 的第一层，负责模型适配器、工具、持久化、沙箱、审批策略、设置、凭据、遥测等基础能力。
Profile 是一种命名的运行时组合，存着一组 bundle 的顺序、装了什么插件，以及用户自己的 cordis.patch.yml。dsh web 本质上是启动 web profile，dsh --profile headless 启动 headless profile。
Preset 是预定义的 Profile，即四种运行模式。这个设计的有趣之处在于：官方模式与社区做的整合包在地位上没有任何差别，都是插件组合。
第二层：Cordis 运行层（Runtime Layer）
第二层是 Cordis 微内核的实际运行环境，负责插件的生命周期管理、服务注册与发现、事件通信。
第二层：Cordis 运行层 (Runtime Layer)
┌──────────────────────────────────────────────────────────┐
│ │
│ Context 服务容器 │
│ ┌────────────────────────────────────────────────────┐ │
│ │ ctx.tools │ ctx.llm │ ctx.sessions │ │
│ │ ctx.sandbox │ ctx.storage │ ctx.scheduler │ │
│ │ ctx.ui │ ctx.skills │ ctx.credentials │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ Service / Provider / Consumer 模式 │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Plugin A (Provider) → 注册 service: 'database' │ │
│ │ Plugin B (Consumer) → 注入 inject: ['database'] │ │
│ │ Cordis 自动匹配提供者与消费者 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ Event 事件系统 (四种派发模式) │
│ ┌────────────────────────────────────────────────────┐ │
│ │ emit(串行广播) : 所有 listener 依次收到通知 │ │
│ │ waterfall(瀑布) : 中间件式，可短路/修改数据 │ │
│ │ parallel(并行) : 所有 listener 同时执行 │ │
│ │ serial(串行等待) : 按序执行，等待每个完成 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ 插件生命周期 Fiber 状态机 │
│ ┌────────────────────────────────────────────────────┐ │
│ │ PENDING → LOADING → ACTIVE → DISPOSED │ │
│ │ 每个状态转换都是确定性的，失败时事务回滚 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘
Context 服务容器 是 Cordis 的核心抽象。每个服务占据一个稳定的键（如 ctx.tools、ctx.llm），别的插件通过键来找服务，而不是 import 一个具体实现。这从根本上解耦了插件之间的直接依赖关系。
Service/Provider/Consumer 模式 让插件可以声明自己提供什么服务、需要什么服务。Cordis 自动解析依赖图谱，确保加载顺序正确。
Event 系统 提供了四种事件派发模式，覆盖了从广播通知到中间件拦截的所有场景。Agent Loop 的执行过程就是通过事件串联的：
Agent 执行的事件链
┌─────────────────────────────────────────────────────────┐
│ │
│ turn/start → agent/pre-step → agent/request │
│ → llm/stream → tool/call → tools/pre-execute │
│ → tools/execute → tools/post-execute │
│ → tool/result → step/end → turn/end │
│ │
│ 每个事件都是扩展点： │
│ - 在 agent/request 前改写或拒绝输入 │
│ - 在 tools/pre-execute 周围加审批/超时/监控 │
│ - 在 llm/stream 时拦截或记录流式输出 │
│ │
└─────────────────────────────────────────────────────────┘
第三层：Agent 能力层（Capability Layer）
第三层是实际面向用户的能力层，由一系列 Cordis 插件构成。
第三层：Agent 能力层 (Capability Layer)
┌──────────────────────────────────────────────────────────┐
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Model Plugin │ │ Tool Plugin │ │ Skill Plugin│ │
│ │ │ │ │ │ │ │
│ │ • DeepSeek │ │ • 文件编辑 │ │ • 代码审查 │ │
│ │ • Anthropic │ │ • Shell │ │ • 架构分析 │ │
│ │ • OpenAI │ │ • 搜索 │ │ • 重构 │ │
│ │ • 自定义 │ │ • 自定义工具 │ │ • 自定义技能 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Session Plugin│ │ Sandbox Plugin│ │ Storage Plugin│ │
│ │ │ │ │ │ │ │
│ │ • 会话管理 │ │ • Landlock │ │ • 文件系统 │ │
│ │ • 事件日志 │ │ • 容器 │ │ • 数据库 │ │
│ │ • 历史追溯 │ │ • 远程沙箱 │ │ • 云存储 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Agent Loop │ │ Scheduler │ │ UI Plugin │ │
│ │ Plugin │ │ Plugin │ │ │ │
│ │ │ │ │ │ • Web UI │ │
│ │ • 标准循环 │ │ • 任务调度 │ │ • TUI │ │
│ │ • PTC模式 │ │ • 子Agent │ │ • 自定义 │ │
│ │ • 自定义循环 │ │ • 定时任务 │ │ • 远程渠道 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘
六、四种运行模式：同一套插件的不同组合
Harness 内置四种运行模式，本质是四份不同的插件配置清单。这个设计本身就很有意思——官方模式和社区做的整合包在地位上没有任何差别，都是插件组合。
标准模式（Standard Mode）
标准模式是完整的编程 Agent，面向日常开发任务。开箱即用的工具包括：
- 文件编辑（
str_replace_editor） - Shell 终端
- 文件搜索与网页搜索
- 技能（Skills）
- 规划（Planning）与目标管理（Goals）
- 子 Agent（Subagents）
- 工作流（Workflows）
这是大多数开发者的第一站，也是功能最完整的模式。
PTC 模式（Programmatic Tool Calling）
PTC 模式是这次发布中最值得关注的技术创新之一。
传统模式下，模型每调一次工具就得跟客户端来回一次，十次工具调用需要十轮往返：
传统 Agent 工具调用
用户: "帮我重构这个项目"
→ 模型: "我先看看文件结构" → 工具: readdir
→ 模型: "再读一下 package.json" → 工具: read_file
→ 模型: "看看 main.ts" → 工具: read_file
→ 模型: "我需要改这三个文件" → 工具: edit_file × 3
→ 模型: "跑一下测试" → 工具: shell
→ ... 每次工具调用都需要一次完整的模型往返
PTC 模式换了个思路：模型通过 Code Mode SDK 直接产出一段 TypeScript 脚本，把这些操作串起来一次跑完：
PTC 模式工具调用
用户: "帮我重构这个项目"
→ 模型: 生成一段 TypeScript 脚本
async function refactor() {
const files = await readdir('.');
const pkg = await readFile('package.json');
const main = await readFile('src/main.ts');
// ... 批量编辑
await editFile('src/main.ts', newContent);
await shell('npm test');
}
→ 工具: run_code(refactor)
→ 一次执行完成所有操作
→ 模型: "重构完成，测试通过"
好处：快、省 token、减少模型与工具之间来回对话的次数，适合结构化、多步骤、可并行的操作。
代价：模型生成的代码获得了更强的调度能力，对沙箱隔离、超时、资源配额和权限控制提出了更高要求。
极简模式（Minimal Mode）
极简模式只保留两个工具：
- 一个持久的 Bash 终端
- 一个
str_replace_editor文件编辑器
系统提示词也被压缩成一句非常简单的"你是一个有帮助的软件工程助手"。
这个模式不是为了日常使用，而是为了最小环境下的模型基准测试。DeepSeek 官方跑自己的 Coding Agent 基准时，用的就是极简模式——去掉 Harness 外围变量的影响，直接测量模型自身的自主规划、代码修改和终端操作能力。
创造模式（Creator Mode）
创造模式是四种模式中最具实验性的一种。它拥有标准模式的完整能力，但额外允许 Agent：
- 检查当前运行时：查看正在运行的 Cordis 插件树
- 在内存中试验插件：动态加载、卸载临时插件
- 组合新模式：把试验成功的插件组合成新的 Preset
创造模式：Agent 自我修改
┌─────────────────────────────────────────────────────────┐
│ │
│ 用户: "帮我创建一个专门做安全审计的模式" │
│ │
│ Agent 检查当前运行时: │
│ → 发现缺少文件只读插件 │
│ → 在内存中创建一个临时插件 (只读文件访问) │
│ → 挂载到当前运行时 │
│ → 创建新的 Profile (安全审计模式) │
│ → 导出为可复用的 Preset │
│ │
│ 整个过程不重启、不写文件、不改配置 │
│ 重启后临时插件消失 │
│ │
└─────────────────────────────────────────────────────────┘
这个模式的信任等级被标注为等同于 Shell 访问权限，默认不开启。临时插件只存在于进程内存里，不写文件、不装包、不改配置，重启即消失。
七、Trajectory 轨迹系统：可追溯的会话日志
如果说"一切皆插件"是 Harness 的横向扩展能力，那 Trajectory 就是它的纵向可观测性。
Harness 采用 append-only（仅追加） 的会话日志设计。模型看到的一切——系统提示词、推理过程、工具调用与结果、子 Agent 调度、每一次上下文注入——都被记录进一份只能追加的会话日志中。
Trajectory 轨迹系统
┌─────────────────────────────────────────────────────────┐
│ │
│ Session 事件流 (append-only) │
│ │
│ Event 1: [system] 系统提示词 │
│ Event 2: [user] 用户消息 │
│ Event 3: [reasoning] 模型推理过程 │
│ Event 4: [tool_call] 工具调用: read_file package.json │
│ Event 5: [tool_result] 工具返回: {"name": "express"} │
│ Event 6: [context_inject] 上下文注入: 文件摘要 │
│ Event 7: [subagent] 子 Agent 调度: "分析依赖" │
│ Event 8: [compression] 上下文压缩事件 │
│ ... │
│ │
│ 硬约束: Model-visible means logged │
│ 模型可见的每一字节，都必须能从日志里重建 │
│ 运行时通过 assert 校验这一点 │
│ │
│ 从同一事件流派生的能力: │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │恢复 │ │分叉 │ │回放 │ │搜索 │ │转写 │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │
│ │
└─────────────────────────────────────────────────────────┘
关键设计原则：上下文压缩不会删除原始历史，只是用替换事件改变模型此后看到的表象。原始事件流永远完整可查。
这意味着当 Agent 在第几十步做错决定时，开发者可以回到当时模型真正看到的上下文，逐条核查记录，确认问题来自模型判断、工具返回、提示词变化还是错误的上下文注入。对于长任务调试，这是质变——从"猜它当时看见了什么"变成"看录像"。
八、插件生态：72 小时，1000+ 插件
社区对 Harness 的反应快得离谱。
36氪在 8 月 13 日当晚实测时，一个目录收录了 288 个插件仓库。到 8 月 15 日，GitHub 上打 dsh-plugin 标签的仓库已超过 1000 个，而且还在涨。
几个有代表性的社区插件：
| 插件 | 功能 |
|---|---|
| dsh-vision-toolkit | 给纯文本模型加视觉能力，支持图片问答、长截图 OCR、UI 还原 |
| dsh-TUI | Claude Code 风格的全屏终端交互界面 |
| dsh-web-ui | Web UI 增强全家桶：任务看板、Git 图谱、皮肤中心 |
| DSH-better-sidebar | VSCode 风格的工作台：文件编辑、终端、Git、子代理管理 |
| dsh-session-supervisor | 会话生命周期守护，超时/静默/异常轮次告警 |
| dsh-dream-reflection | 让模型定期反思并沉淀知识，但需人工审批才能生效 |
| dsh-browser-automation | 隔离的浏览器自动化，DNS 级出网策略，逐次人工审批 |
| dsh-ui-whale | 像素鲸鱼桌宠，空闲时眨眼游动，思考时喷水 |
最绝的是 Nagi-ovo/dsh-ads 这个插件——给 Web 界面加上 2005 年中文网站风格的侧栏广告、对话内信息流和角落弹窗，连关闭按钮的点击区域都故意做得比看着小。而社区里紧挨着一个专门屏蔽它的插件——广告是插件、去广告也是插件，生态自己先完成了一轮攻防。
远程渠道插件也迅速涌现：qqbot、dsh-weixin-bot、dsh-feishu-bot、dsh-wecom-bot、telegram，装上之后 DSH 就能变成一个在 QQ 群、飞书里被 @ 的机器人。
九、与 Claude Code / Codex 的架构对比
Harness 最常被拿来与 Claude Code 和 OpenAI Codex 比较。但三者的架构哲学存在根本性差异。
架构哲学差异
| 维度 | DeepSeek Harness | Claude Code | OpenAI Codex |
|---|---|---|---|
| 架构哲学 | 可重组的插件框架 | 成品工具箱 | 成品工具箱 + 开源 CLI |
| 模型锁定 | 无锁定，模型即插件 | 主要为 Claude 系列 | 主要为 OpenAI 系列 |
| 可扩展边界 | 整个运行时（含 Loop/UI） | 工具/技能/MCP 层 | 工具/技能/MCP 层 |
| Agent Loop | 可替换插件 | 固定 | 固定 |
| UI | 可替换插件 | 终端/IDE/桌面/Web | CLI/IDE/桌面/Web |
| 许可证 | MIT 开源 | 商业产品 | 商业产品 + 开源 CLI |
| 沙箱 | 可替换插件 | 内置成熟系统 | 内置细粒度控制 |
| 热插拔 | 运行时无重启 | 不支持 | 不支持 |
| 产品成熟度 | 开发者预览版 | 成熟商业产品 | 成熟商业产品 |
核心差异：你到底能改什么？
Claude Code 和 Codex 是"整机"交付的。模型、工具、执行循环、UI 全部耦合在一起。厂商给你什么，你用什么。你可以写 Skill、写 MCP Server，但 Agent Loop 是焊死的，UI 是焊死的，调度逻辑是焊死的。
Harness 把这事反过来做了。从模型到 UI，从沙箱到调度，每一个组件都是可替换的插件。这不是"开放了几个 API 接口让你们写插件"的伪开放——连 Agent 本身的循环逻辑都是插件，你可以替换它。
战略差异：为什么 Anthropic 需要 Harness 值钱，而 DeepSeek 需要它不值钱？
Anthropic 的商业模式是"模型 + 外壳"一体化交付。Claude Code 的闭源外壳是它的产品壁垒——用户订阅费买的就是这套模型与外壳的咬合。别人拆不开，也抄不走。
DeepSeek 的战略正好相反。它的模型强、价格低，但之前 API 文档的 Agent 集成板块列了十几家第三方工具——Claude Code、Codex、Cursor、Copilot……唯独没有自家 Agent 产品。等于模型是它家的，干活的手是别人家的。
Harness 改变了这个局面。一旦 Agent 执行层被拉平成 MIT 开源公共品，竞争就被压回模型本身的能力和价格上——那现在已经是 DeepSeek 的主场了。
十、战略意义：从模型提供商到 Agent 生态入口
10.1 崔添翼与 Harness 团队
Harness 团队负责人 崔添翼（Tianyi Cui） 的履历在 AI 圈并不常见。90 后，本科毕业于浙江大学计算机系（梁文锋的学弟），大学期间拿下六枚 ACM 亚洲区域赛金牌。毕业后在华尔街顶级量化机构 Jane Street 香港和纽约办公室深耕九年，专攻高并发、高容错的量化交易系统。
选择这样一个人来主导 Agent 底座，逻辑非常清晰：Harness 本质上是模型外围的一套执行控制系统。它要求的不是"更聪明的算法"，而是极致的稳定性与确定性、全链路的可观测与可追溯、严格的风险与权限边界——这些与高频量化系统对基础设施的苛刻标准几乎同构。
10.2 从"蓝鲸"到"虎鲸"的品牌隐喻
一个值得注意的细节：DeepSeek 主品牌长期使用蓝色鲸鱼标识，而 Harness 团队的 logo 换成了一头黑色虎鲸。
这不仅是视觉区分，更是一种战略隐喻：
- 蓝鲸：体量庞大、以量取胜——对应模型本身的能力上限与规模
- 虎鲸：高智商、强社会性、善于群体协作——对应在复杂环境中组织、调度、协作完成任务的能力
DeepSeek 似乎在用品牌语言宣告：大模型时代的胜负手，正在从"谁更聪明"转向"谁能把聪明组织成生产力"。
10.3 开源策略的深意
MIT 协议开源选择是战略性的。MIT 是限制最少的开源许可证之一——任何人都可以自由使用、修改、再发布，甚至闭源商用。
DeepSeek 赌的是：基础设施层才是价值沉淀的地方，而不是模型本身。如果 Harness 成为 Agent 领域的"Android 开源底座"，那 DeepSeek 就在 Agent 生态的入口处占据了不可替代的位置。
十一、当前局限与风险
实事求是地说，Harness 目前还是 v0.1 开发者预览版。官方 README 用全大写字母写了一句话：
THERE WILL BE COMPATIBILITY-BREAKING CHANGES.
主要风险点
接口未冻结：核心插件和 API 会持续演进，现在将其用于生产环境等于赌它不改。
学习曲线陡峭：Cordis、插件、服务、事件、Profile、Bundle 等一套概念体系，上手成本不低。
成熟度未知：没有独立第三方基准测试，没有大规模生产案例。提交虽多（约 12,293 次），但主要是内部演化，外部踩坑还少。
生态仍在早期：1000+ 个插件看似热闹，但质量参差不齐，缺乏官方审核机制和版本兼容性保障。
热度不等于成熟度：6 万+ GitHub 星标主要来自 DeepSeek 品牌和"对标 Claude Code"的叙事，不等于工程稳定。
数据治理挑战：append-only 日志包含代码、凭证线索、内部文件内容，可回放提高了可审计性，也扩大了需要保护的数据面。
十二、结论与展望
DeepSeek Harness 不是又一个 Claude Code 的克隆版。它是一个架构信号——代表着 AI Agent 框架从"单体核心难以扩展"向"微内核 + 事件溯源 + 运行时热插拔"的范式转变。
它的核心价值可以概括为三句话：
- 架构信号：以 Cordis 为代表的"时空可组合"插件范式，可能是 Agent 框架摆脱单体架构死结的一条可信路径。
- 生态信号：开源 + MIT + 社区插件冷启动，说明 DeepSeek 想做的不是又一个闭源 Agent 产品，而是一个可被二次开发的开放底座。
- 战略信号：模型厂商的下一个战场，已经从"上下文窗口大小、跑分高低"转移到了"执行层与反馈闭环"。
对开发者来说，现在最好的姿态是：把它 clone 下来，跑一遍 npx @deepseek-ai/dsh web，读一读 docs/architecture.md，亲自感受一下"一切皆插件"到底是什么手感。
AI 工程的战场，已经从"谁的模型强"悄悄转移到"谁的 Agent 跑得稳、扩得动"。DeepSeek Harness 给的答案很激进——把 Agent 的每一块都做成能插拔的零件。这个答案对不对，时间会给出检验。
但有一点可以确定：2026 年 8 月 13 日这个夜晚，Agent 领域的游戏规则，被改写了。