注：本文基于 2026 年 8 月 15 日公开的 DeepSeek Harness 仓库进行分析。DSH 当前仍处于 Developer Preview，官方明确提示后续会出现兼容性破坏，因此本文更关注其架构思想，而不是把当前实现视为已经稳定的产品规格。

2026 年 8 月 13 日，DeepSeek 开源了一个全新的 Agent 框架：DeepSeek Harness，简称 DSH。这是一个看起来非常简洁、但包含了 DeepSeek 自己对 Agent 框架思考的东西。网上已经有很多人对它做了介绍，评价差异也很大：有人认为这是程序员的"幻想"，做出来的东西没什么实用价值、易用性差；也有人认为这是一个新时代的产品。Flask 作者、目前主导 Pi 开发的 Earendil 联合创始人 Armin Ronacher 也公开表示，他并不认为 DSH 是完美的，但这是他第一次在这个领域看到新东西、并觉得有必要回头重新审视自己团队的一些选择，他还特意补了一句很喜欢开源的这一面。

DSH 之所以引起这么广泛的关注，不只是因为 DeepSeek 的名气，它本身的架构设计其实也非常有意思。我们在这里试图解析并理解一下 DSH 最特别的几处设计，以及它和当前业界 Agent 框架的一些差异。

Harness 工程是今年比较火的概念，是继 Context 工程之后又一个比较热的方向。业界目前没有统一定义，但大体都把它理解为"围绕大模型构建 Agent 执行闭环的工程"。DeepSeek 直接把自己的 Agent 框架命名为 DeepSeek Harness，可见他们认同这个理念。换个角度说，当前大家一致认为，大模型负责思考，harness 负责让它真的能干活——决定模型每一步看到什么上下文、工具怎么调、结果怎么回灌、什么时候该停下、能碰哪些文件和命令、出错了怎么恢复，这一整套跑在模型周围的工程系统就是 harness。同一个模型换一个 harness，实际表现和调用成本可能差出很远。

尽管业界已经有 Claude Code、Codex 等优秀产品，但是核心能力不开源，大家能做的都是为其开发一点插件做做外围工作；而业界开源的产品如 OpenCode、Pi 等则各有各的设计哲学。那为什么 DeepSeek 自己还需要推出这样一个东西？显然他们觉得业界目前的形态还不够。本次开源的 DSH 有几个非常突出的设计逻辑，使其与业界的产品有较大的差异，接下来我们逐一拆开看。

一、DSH 是什么：从 Coding Agent 到 Agent Runtime Framework

尽管前面我们已经将 DeepSeek Harness 称为 Agent 框架，并将它和 Claude Code、OpenCode 等产品放在一起比较，但真正安装并启动 DSH 之后，第一感觉可能反而是有些困惑。

根据官方教程，在安装 Node.js 后执行 npx @deepseek-ai/dsh web，打开 http://127.0.0.1:3080 就可以看到 DSH 的 Web 页面。

这个页面看起来像一个 Web 版的 Agent 聊天应用，可以创建 Session、和 Agent 对话、查看工具调用和运行轨迹；但与此同时，又可以配置模型、权限、Agent Preset 等内容。因此它既有明显的“运行态”，又带有一些“设计态”和“调试态”的感觉。

这个感觉其实没有错。

Claude Code、Codex、OpenCode 等产品首先都有一个相对明确的 Agent Runtime，然后再向外提供 Tool、MCP、Skill、Plugin 等扩展能力。DSH 则试图再往下一层：它并不急于规定一个 Agent 最终应该长什么样，而是先提供一个用于组合和运行 Agent Runtime 的框架。

所以与其简单把 DSH 理解为“DeepSeek 做的另一个 Coding Agent”，我更愿意把它称为一个 Agent Runtime Framework。

在这个框架里，模型、Session、Tool、Agent Loop、Sandbox、Subagent 等不是一个固定 Agent 身上不可拆开的组成部分，而是可以被组合起来的 Runtime Capability。官方架构文档甚至明确写道，包括 Model Adapter、Tool Registry、Session Log 和 Agent Loop 本身在内，“产品的每个部分都是插件”。

DSH 启动的本质也不是加载一个固定 Agent。一个正在运行的 DSH 是从空插件树开始，由 Bundle、Profile、用户 Patch 和命令行 Overlay 一层层组合出来的；官方甚至提供 dsh --profile web --dump-config，可以在启动前直接看到最终会得到怎样的一棵 Plugin Tree。

因此，DSH 更接近：

             DeepSeek Harness
                    │
             Runtime Composition
                    │
      ┌─────────────┼─────────────┐
      │             │             │
    Model         Session        Tools
      │             │             │
 Agent Loop     Persistence    Sandbox
      │
   Subagent

Coding Agent 只是这种组合可以得到的一种结果，而不是 DSH 对 Agent 的唯一预设答案。

理解这一点之后，DSH 后面很多乍看奇怪的设计就容易理解了。我认为最值得关注的是四个方面：Everything is a Plugin、模型请求必须可重建、Capability Seam 的三角色模型，以及 Subagent 被提升为正式的 Runtime Capability。

二、Everything is a Plugin：真正插件化的是 Agent Runtime 本身

“一切皆插件”是 DSH 最容易被说出来、同时也最容易被误解的一句话。

因为 Claude Code 有 Plugin，OpenCode 有 Plugin，Pi 也有非常强大的 Extension。如果只是允许开发者增加 Tool、Hook 或 Skill，那么 DSH 并没有什么特别。

真正的区别在于，其他产品大多是：

              Agent Core
                  │
        ┌─────────┼─────────┐
        │         │         │
      Tool       MCP      Plugin

也就是说，先有一个 Agent，再让插件扩展这个 Agent。

而 DSH 更接近：

                Cordis
                  │
      ┌───────────┼───────────┐
      │           │           │
    Model       Session      Tools
    Plugin      Plugin       Plugin
      │           │           │
 Agent Loop   Persistence   Sandbox
   Plugin       Plugin       Plugin

它把传统上我们认为属于 Agent Core 的很多东西本身也做成了 Plugin。官方甚至用了一个很强的表述：“There is no privileged core to patch”——扩展 DSH 的正常方式应该是在现有 Plugin 旁边挂载另一个 Plugin，而不是修改某个中心 Core。

这里的 Plugin 不是浏览器插件那种“给主体增加一点功能”的概念，而更像一个运行时软件模块。底层负责这套机制的是 Cordis，一个独立的 TypeScript 插件框架，提供 Context、Service、依赖注入、事件和生命周期等机制。DeepSeek 并没有把 Cordis 当普通 npm 依赖使用，而是直接把指定版本的源码 vendoring 到 DSH 仓库中，目前使用的上游 Cordis 为 4.0.0-rc.7，并维护了一份包含生命周期、Loader、Patch 语义等修改在内的本地差异清单。DeepSeek 给出的理由也很直接：希望 Harness 能完整掌控这层 Framework，使其版本固定、可审计、可修改。

这也是为什么连 Agent Loop 都可以成为 Plugin。

我们通常认为 Agent Loop 是一个 Agent 最核心的东西：

读取 Context
    ↓
调用 LLM
    ↓
模型调用 Tool
    ↓
执行 Tool
    ↓
结果回灌 Context
    ↓
继续调用 LLM

Codex 官方甚至直接把 Agent Loop 称为 Codex CLI 的 “core logic”。

DSH 的处理方式是把“Agent 是什么”和“Agent 如何被驱动”拆开。core/agent 提供 Agent 的状态和契约，而 core/agent-loop 是当前默认的具体 Driver，后者通过 ctx.agentLoop 进入 Plugin Tree。

也就是说，Agent Loop 本质上只是一个控制策略：

Agent Loop
   │
   ├── 使用 Session
   ├── 使用 LLM
   ├── 使用 Tools
   └── 决定下一步做什么

它自己不必拥有这些能力。

因此理论上，一个 Coding Agent 可以采用标准的多轮 ReAct：

LLM → Tool → LLM → Tool → LLM

而某个业务 Agent 完全可以采用：

Router LLM
    ↓
多个确定性 API 并行执行
    ↓
Summary LLM

二者只是不同的 Runtime Composition。

需要注意的是，这里说的是架构控制权，不是说 DSH 当前已经提供了十几种 Agent Loop。当前真正随框架提供的仍然是默认 Driver，但 Agent Loop 已经不再被定义成一个其他模块必须直接依赖的不可替换核心。

DSH 的 Profile / Bundle / Patch 机制让这种思想进一步落实到了配置层：Bundle 插入能力，Profile 决定组合哪些 Bundle，上层 Patch 又可以按 ID 替换其中任何一行配置。

所以 DSH 所谓 Everything is a Plugin，真正特别的并不是“插件数量很多”，而是：

它试图尽量不提前规定 Agent Runtime 的最终形态。

三、Model-visible means logged：不只是保存历史，而是要求模型请求可重建

DSH 第二个我认为非常有意思的设计，是 Session。

传统 Agent 系统往往同时维护 Conversation History、Tool History、Trace、Session State 和运行日志。真正请求模型时，再由不同组件把这些东西拼起来。

问题在于：日志里记录的东西，不一定就是模型当时真正看到的东西。

例如某个插件临时向 Context 注入了一段内容：

Session History
      +
System Prompt
      +
临时 Context
      +
Tool Result
      ↓
    Model

如果“临时 Context”只存在于当次请求内，那么之后即使保存了聊天记录，也很难完整解释为什么模型当时会产生那个回答。

DSH 对此采取了一个非常强的约束：

Model-visible means logged。

Session 被设计成 append-only 的 Event Log，deriveMessages() 根据日志投影出模型消息历史，而不是另外维护一份可以随意修改的 messages[]。Fork、Resume、Transcript、Telemetry 和 Persistence 都建立在同一条事件流之上。

早期理解这个设计时，很容易把它概括成：

模型看到的消息
    =
日志中可以重建的消息

但当前实现实际上已经更进一步。

DSH 现在增加了 request/header 事件。除了消息历史以外，每次正常 Agent Loop 请求所使用的 system prompt、tool schemas、call config 以及 request prefix 也会被记录，并能够和 deriveMessages() 一起重新构造模型实际使用的请求。

因此更准确的结构是：

               Session Event Log
                      │
          ┌───────────┴───────────┐
          ↓                       ↓
   deriveMessages()          request/header
          │                       │
     Message History        System Prompt
                            Tool Schemas
                            Call Config
                            Prefix
          └───────────┬───────────┘
                      ↓
                 Model Request

这和“我们把所有请求打印进日志”仍然不是一回事。

关键在于 DSH 把它做成了 Runtime Contract：新的模型可见内容不能偷偷从旁路进入模型，而必须能从日志和其定义的投影规则中重新得到。官方架构文档直接说明，任何到达模型请求的内容都必须可以从 Log 重建，并由 Runtime Invariant 进行检查。

这会带来几个非常直接的好处。

当你想知道：

为什么模型知道这件事？

可以回到对应的 Session Event。

当你想 Replay：

当时真正给模型的 System Prompt 和 Tool Schema 是什么？

也有明确的数据来源，而不是拿“当前配置”去猜历史配置。

这种设计同时还和调用成本有关。

LLM 的 Prefix Cache 本质上依赖前缀稳定。DSH 对 Session 的设计非常强调 append-only：如果 system prompt、tool schemas、配置和旧历史都没有变化，那么下一轮通常只是继续向原有前缀后面增加内容，可以最大化复用此前的 KV Cache；如果 Prompt、Tool Schema 或 Compaction 真正改变了模型看到的前缀，则从第一个变化的位置开始影响缓存复用。DSH 的 Session 和 DeepSeek Adapter 文档已经把 KV Cache effect 作为每项能力需要说明的正式工程属性。

这意味着，在 DSH 中：

Context 稳定性
     │
     ├── 决定 Replay 是否可靠
     ├── 决定问题是否可调试
     └── 同时影响 Prefix Cache 和调用成本

Compaction 因此也不再只是“上下文太长了总结一下”。压缩会真正重写模型后续看到的历史，所以什么时候压缩，同时是一个上下文质量问题和 Cache 成本问题。DSH 自己甚至专门修过 Compaction 导致 Prefix Cache 无法复用的问题。

当然，这个原则也有边界。比如 Compaction 自己为了生成摘要而发出的 one-shot 模型调用，并不属于 Agent Loop 所拥有的那条请求 Invariant；它会记录自己的模型、Token 上限等 envelope 信息，并依赖被引用的日志区域和确定性代码进行重建。

所以更准确地说，DSH 并不是简单提出：

“所有 LLM 调用都必须经过一个 messages 数组。”

而是在尝试建立一个更强的原则：

对于 Agent 正常执行链路，模型为什么会看到这些东西，应该有唯一、可重建、可验证的数据来源。

我认为这是 DSH 最值得借鉴的设计之一。

四、Capability Seam：为什么一个能力要拆成三个角色？

“一切皆插件”如果只是把一个大项目拆成很多 npm package，其实并没有太大意义。

真正让这些 Plugin 可以互换的，是 DSH 对 Capability Seam 的定义。

官方规定，一个完整的可替换能力通常存在三个角色：

Service Definition
       │
       ├──── Service Provider
       │
       └──── Consumer

即：

• Definition 定义“这个能力是什么”；
• Provider 定义“这个能力具体怎么实现”；
• Consumer 定义“谁、以什么方式使用这个能力”。

官方甚至明确说，只有其中一个角色并不能构成真正的 Seam。

Bash 是最好理解的例子。

DSH 将其拆成：

dsh-shell
Service Definition
      │
      │ ctx.shell
      ↓
┌──────────────┬────────────────┐
│              │                │
dsh-bash-local dsh-bash-sandbox...
Provider       Provider
      ↑
      │
dsh-tool-bash
Consumer
      │
      ↓
    Model

dsh-shell 只定义 ShellExecutor 的请求与返回契约；dsh-bash-local 或 dsh-bash-sandbox 提供具体执行能力；dsh-tool-bash 则负责把这个能力变成模型看到的 bash Tool。

这里有一个很容易忽略、但我认为非常重要的细节：

模型看到的 Tool Schema 本身只是 Consumer，而不是能力本身。

今天：

bash Tool
   ↓
Local Bash

明天可以变成：

bash Tool
   ↓
Sandbox Bash

模型调用的接口可以完全不变。

反过来也可以保持同一个底层 Provider，却改变它如何暴露给模型。

所以三者分别解决：

Definition：双方说什么语言
Provider：这件事情实际上怎么做
Consumer：怎样把这个能力提供给当前使用者

这比普通的 Interface + Implementation 又多拆了一层。

因为在 Agent 系统里，“执行能力”和“模型如何理解并调用这个能力”实际上是两个不同问题。

这套结构也让安全能力可以比较自然地插入其中。例如当 Bash Provider 支持 Sandbox 时，仍然不需要换一个新的 Tool。dsh-tool-bash 会根据 Provider 暴露的 capability 自动增加 sandbox_permissions 和 justification 等字段。

DSH 甚至把权限协商的一部分直接写进了模型可见协议。当一次命令因为 Sandbox 被拒绝时，如果存在可升级权限，Tool Result 会告诉模型：可以在当前 Turn 内对同一个命令重试一次，但必须选择最小的更高权限并给出 justification，然后由 Approval 流程询问用户。审批服务不可用、审批取消或者被拒绝时，命令不会执行。

这其实是一个很典型的 Agent 工程设计：

不仅告诉模型“你没权限”，还告诉模型“正确的权限协商协议是什么”。

五、Subagent：把“另一个 Agent”也变成一种 Provider

现在几乎所有主流 Agent 产品都已经开始支持 Subagent，因此单纯说“DSH 支持子 Agent”没有什么特别。

DSH 真正特别的是：它把“把一段工作委派给另一个 Agent”本身也做成了 Capability Seam。

主 Agent 面对的是统一的：

ctx.subagents

而背后可以注册多个不同 Provider。当前官方文档明确列出了：

spawn-in-process
fork
ACP
Codex
Claude Code
DSH SDK

也就是说，对于主 Agent 来说：

“调用另一个 DSH Agent”

和：

“把任务交给 Codex”

或者：

“把任务交给 Claude Code”

都可以是同一个 Subagent Service 后面的不同 Provider。

因此它的抽象不是：

Main Agent
   ↓
Subagent Tool
   ↓
固定的 Child Agent

而是：

Main Agent
      │
      ↓
ctx.subagents
      │
 ┌────┼───────┬──────────┐
 ↓    ↓       ↓          ↓
spawn fork   Codex   Claude Code

这其实非常符合前面 Capability Seam 的设计哲学：主 Agent 只依赖“委派”这个能力，不依赖“另一个 Agent 到底是什么产品”。

DSH 对 Provider 能力本身也做了显式协商。例如一个 Subagent Provider 可以声明自己是否支持 outputSchema、depthLimit、toolFilter 和 persona。如果请求使用了 Provider 不支持的能力，DSH 的原则是直接返回 UNSUPPORTED_CAPABILITY，而不是悄悄忽略。

递归深度也进入了正式的 Runtime 模型。子 Agent 的 delegation depth 会被持久化，进程内 child 在父 Agent 基础上加一；即使之后 Cold Resume，也不能把这个深度悄悄恢复成 0。

这意味着：

Main Agent
   │
   ├── Research Agent
   │       │
   │       └── Search Agent
   │
   └── Coding Agent

不是简单依赖“Tool 能不能再调一个 Tool”绕出来，而是 Harness 本身开始理解 Agent lineage 和 delegation depth。

另外，DSH 还支持 continuable child。也就是说子 Agent 不一定完成一次任务就消失，它可以拥有自己的 durable child identity，之后再通过 send_message 等方式继续交互。

所以 DSH 对 Multi-Agent 的理解其实相当统一：

另一个 Agent 也只是 Runtime 中的一种可替换计算能力。

六、Standard、Code、Minimal：同一个 Harness 可以长成完全不同的 Agent

前面这些架构设计并不只是停留在接口层。

DSH 当前随产品提供了多种不同 Agent Preset，包括 standard、code、minimal 和面向 Cordis 自身编辑能力的预设。

它们并不是四套不同的 Agent Framework，而是同一套 Runtime Capability 的不同组合。

其中最有意思的是 Code Mode，也就是很多讨论里提到的 PTC。

普通 Agent 调用工具的方式通常是：

LLM
 ↓
Tool A
 ↓
LLM
 ↓
Tool B
 ↓
LLM
 ↓
Tool C

而 Code Mode 下，模型真正直接看到的核心入口可以缩成一个 run_code。其他 Tool 会被生成成一份 TypeScript SDK 放进 Prompt，模型写一段程序，通过：

await tools.xxx(...)

在程序内部编排多次 Tool 调用。

于是变成：

LLM
 ↓
生成 TypeScript
 ↓
run_code
 ├─ Tool A
 ├─ Tool B
 ├─ Tool C
 └─ Promise.all(...)
 ↓
LLM

程序内部的子 Tool 调用仍然会通过正常的 Tool Execution Pipeline，并被记录下来，但中间结果不必全部重新回灌给模型；最终只需要把程序真正决定输出的内容返回。

这其实是在尝试减少 Agent 中非常昂贵的一件事情：用 LLM 本身承担每一步程序控制流。

而 minimal Preset 又走向另一个极端：官方当前将它压缩到一个非常短的 System Prompt，并只组合 persistent shell 和 str_replace_editor 两个主要操作能力。

这里和 Pi 的设计有一个很有意思的呼应。Pi 默认也只给模型四个基本工具：read、write、edit、bash，并明确强调核心应该尽量小，其他能力通过 Extension 增加。

两个在底层架构上走了不同路线的项目，都在实践中得到一个类似结论：

对于一个足够强的模型，真正不可缺少的基础能力可能非常少；大量“功能”其实属于 Harness 产品设计，而不是 Agent 能力本体。

七、DSH 和 Claude Code、Codex、OpenCode、Pi 的真正差异

讲到这里，再回头比较几个产品，会比单纯比较“谁支持 MCP、谁支持 Subagent”更清晰。

真正的问题其实是：

一个 Agent Framework 到底应该替开发者固定多少东西？

Claude Code 的思路很明确：首先提供一个完整、高度优化的 Coding Agent，然后通过 Plugin 增加 Skill、Agent、Hook、MCP、LSP 等能力。Anthropic 官方对 Plugin 的描述本身就是“extend Claude Code”。

Codex 同样存在非常明确的 Codex Core。OpenAI 官方说明，Codex Core 同时是 Agent 逻辑所在的 Library 和运行 Agent Loop、管理一个 Thread 持久化的 Runtime；Agent Loop 本身被直接定义为 Codex 的核心逻辑。

OpenCode 的开放程度更高，也支持通过 Plugin Hook 各种 Event、增加 Tool 或修改行为，但官方定义仍然是“extend OpenCode”以及“modify OpenCode's default behavior”——也就是说首先还是存在一套 OpenCode Default Runtime。

Pi 是目前和 DSH 哲学最接近的一个。

Pi 明确称自己是 “minimal terminal coding harness”，它甚至有意不把 Subagent、Plan Mode、Permission Popup 等做进 Core，而是鼓励开发者通过 Extension 或 Package 自己实现。

但两者仍然有一个很有意思的差异：

Claude Code / Codex
──────────────────
完整 Agent Core
       +
Extension

OpenCode
──────────────────
开放的 Agent Runtime
       +
Plugin / Hook

Pi
──────────────────
Minimal Agent Core
       +
Aggressive Extension

DSH
──────────────────
Minimal Composition Kernel
       +
Agent Runtime 本身由 Plugin 组合

Pi 的问题更像是：

“一个 Agent Core 可以做到多小？”

而 DSH 又往下一层问：

“为什么 Session、Loop、Persistence 这些东西一定天然属于 Agent Core？”

所以我认为 DSH 真正特别的地方，不是插件机制本身有多先进，而是：

它把 Runtime 架构控制权进一步交还给了框架使用者。

这对于普通 Coding Agent 用户未必是优势。

Claude Code 控制完整 Stack，反而更容易提供一致、精心打磨的体验。

但对于想把一个 Agent Runtime 长期嵌入自己平台的团队，这个区别非常重要。因为最难解决的问题通常不是“怎么增加一个 Skill”，而是：

未来如果我要改变 Session 怎么办？
改变 Context 怎么办？
改变 Persistence 怎么办？
改变 Subagent Runtime 怎么办？
甚至改变 Agent Loop 怎么办？

在固定 Agent Core 的产品里，这些需求很容易最终变成外围绕一层，或者直接 Fork 上游源码。

DSH 从一开始就在试图让这类事情成为正式 Extension Seam。

八、这种架构的优点、代价，以及为什么值得关注

到这里很容易得出一个过于简单的结论：既然什么都可以替换，那么 DSH 的架构就一定更加先进。

其实并不是。

Everything is a Plugin 最大的优点是自由度和架构控制权。

如果未来不满意默认 Persistence，可以换 Provider；不满意 Local Bash，可以切换 Sandbox 或 Remote Provider；不满意某种 Subagent，可以换成其他 Agent Runtime。

这对于平台型系统非常有吸引力，因为它尽量避免了：

业务需求
   ↓
框架没有扩展点
   ↓
外围补能力
   ↓
仍然解决不了
   ↓
Fork 上游项目

但自由度越大，框架替你保证的东西就越少。

过去写死在 Core 中时：

Loop + Session + Tool + Permission

开发者只需要相信这个组合。

当它们全部变成可替换模块之后，需要重新回答：

这个 Provider 和那个 Consumer 兼容吗？

换掉 Session 后 Replay 还成立吗？

换掉 Loop 后所有 Security Hook 都一定经过吗？

一个 Plugin 的生命周期异常会不会影响其他 Plugin？

复杂度并没有消失，而是从 Core 内部转移到了 Contract、Lifecycle、Composition 和 Compatibility Governance。

安全更能说明这个问题。

DSH 当前 Sandbox 本身有一些很严谨的设计：如果请求了受限模式，却没有可用的 Sandbox Runner，会 fail closed，而不是悄悄退化为无隔离执行；权限升级也要求 Approval。

但官方文档同时明确承认，当前 Sandbox 主要约束的是文件效果，Network 和 Process Visibility 并没有被限制，因此它不是一个通用意义上的完整安全 Sandbox。

Web CLI 目前也刻意禁止直接通过命令行绑定 0.0.0.0，说明这套 Web Runtime 当前首先还是面向本机开发环境，而不是一个已经完成远程认证、授权和多租户治理的企业服务。

所以：

Everything is a Plugin

解决的是：

Software Architecture Boundary

而不是：

Security Boundary

如果未来把这种架构用于企业级 Agent 平台，我认为最终很可能还需要重新建立一层：

        Small Trusted Core
              │
 Authentication / Authorization
 Tenant Isolation
 Audit
 Resource Boundary
 Mandatory Security Policy
              │
        ───────────────
              │
       Composable Runtime
              │
   Loop / Session / Tool / Subagent

也就是说，并不是所有东西都真的应该拥有同样的“可替换权”。

除此之外，当前 DSH 最大的现实问题其实不是理论上的插件组合复杂度，而是成熟度。

DeepSeek 自己对此非常坦率。README 直接标明 Developer Preview，并用大写提示会发生兼容性破坏；项目内部开发规范甚至写明，在首次正式发布之前，相比维护 Compatibility Shim，更优先建立正确的基础，可以自由 Rename 和 Repackage，Session Format 当前仍保持 Version 0，而且 Backend 可以拒绝旧的磁盘格式。

所以现在把 DSH 当成一个成熟的企业 Runtime 去选型，还为时过早。

但这并不妨碍它值得研究。

因为如果只是为了再做一个可以读文件、改代码、跑 Bash 的 Coding Agent，市场上已经有太多这样的产品了。

DSH 更有意思的地方，是它重新打开了一批逐渐被大家默认的问题：

Agent Loop 为什么一定是 Core？

Session History 为什么要和 Runtime Trace 各自维护一份状态？

Tool 的模型 Schema 为什么必须和实际执行实现绑在一起？

Subagent 为什么必须是当前 Framework 自己定义的那一种 Child Agent？

一个 Agent Framework 到底应该替开发者规定多少东西？

DeepSeek 对这些问题给出的答案其实相当统一：

Everything is a Plugin
        ↓
尽量减少固定 Runtime 形态

Capability Seam
        ↓
把能力和实现解耦

Reconstructable Request
        ↓
自由组合不能破坏可重建的不变量

Subagent Provider
        ↓
连“另一个 Agent 是什么”也不提前规定

这也是我认为 DSH 最值得关注的地方。

Claude Code、Codex 更多是在不断回答：

怎样做出一个更好的 Agent？

Pi 的问题更接近：

怎样做一个足够小、又足够容易扩展的 Agent Harness？

而 DeepSeek Harness 这次提出的问题似乎更底层：

一个 Agent Runtime 到底最少需要固定什么？

Everything is a Plugin 最终是不是正确答案，现在还远远不能下结论。高度可组合的架构可能带来巨大的灵活性，也可能最终被生命周期、兼容性、安全和治理复杂度反噬。

但至少 DSH 并没有只是重新实现一个 Claude Code Clone。

它真正值得关注的，是重新讨论了 Agent Runtime 的边界本身。