DSH：Agent 的 VSCode 时刻？

2026 年 8 月，DeepSeek 发布 DeepSeek Harness（以下简称 DSH）的 developer preview，并将项目开源。它给自己的定位不是"一个更强的聊天应用"，而是 Agent Harness：把模型放进一个可以理解环境、使用工具并持续执行任务的运行环境。

DeepSeek 的宣传口径很简洁：Agent = Model + Harness。模型负责推理，Harness 负责把推理连接到工具、文件、网络、权限、状态和执行过程。官方进一步用两句话概括 DSH： "Everything is a plugin. Every run is traceable." 中文对应的是"一切皆插件，运行有迹可循"。

DSH 是什么：一层可组合的 Agent Runtime

从官方口号出发

官方的一个口号是："一切皆插件"。架构文档明确写道，模型适配器、工具注册表、Session Log、Agent Loop 都是插件。基础能力由一棵 Cordis Plugin Tree 在启动时组合出来------至于什么是 Cordis，我们等会儿再说。

而另一个口号则是："运行有迹可循"。DSH 的 Session 是追加式、类型化的事件日志。模型请求、工具调用、工具结果、上下文注入、状态变化和相关配置都记录在其中；模型历史不是另外存一份，而是从 Session Log 投影出来。

因此，DSH 的两个口号实际上对应两件工程工作：

插件化解决"能力怎么组合、替换和嵌入"；
事件化解决"执行发生了什么、如何恢复和重建"。

来看看代码

结合源码，DSH 至少包括 4 个部分：

Agent Loop：负责接收输入、组织模型请求、处理工具调用，并决定是否继续下一步。一个 Step 是一次模型请求及其调用的工具；一个 Turn 可以包含多个 Step。
组织工具和执行环境：Tool Pipeline 负责工具 Schema、调用前后的事件、审批和结果；文件系统、Shell、PTY、远程执行和 Sandbox 则由不同的 Provider 提供。
Session 的管理和恢复：Session Event Log 记录模型可见内容、工具调用和运行状态，Fork、Resume、Transcript、Telemetry 和 UI 都可以从这条事件流派生。
提供产品接入面：DSH 当前支持 Web UI、Headless Runner、ACP 和 JSON-RPC 等入口，也可以通过插件增加自定义 UI、Conversation Node 和业务侧的数据展示。

这意味着 DSH 把许多产品决定留给了上层：使用哪个模型、连接哪些业务系统、怎么设计权限、哪些动作需要审批、数据存在哪里，以及最终用户看到的是聊天框、报表还是工作台。

所以，"一切皆插件"不是说 DSH 已经把所有插件都准备好了，而是说它把这些能力放在了可替换的组合边界上。哪些能力由 DSH 提供，哪些能力由业务产品提供，哪些能力交给外部系统，是使用者需要自己做出的设计选择。

Cordis 是什么？

DSH 使用 Cordis 作为插件内核，并管理插件之间的挂载、服务发现、事件协作和生命周期。

可以先把几个概念翻译成更直白的工程对象：

DSH / Cordis 概念	更直白的理解
Plugin	一组可挂载、可卸载的能力或行为
Service	插件对外提供的具名能力接口
Provider	Service 的具体实现
Consumer	使用 Service 的 Agent、Tool、UI 或其他插件
Event	运行过程中的扩展点和观察点
Scope	把能力限制在某个 Agent 或 Session
Profile	一套命名的运行时组合
Bundle	可分发的一组 Cordis 配置和代码
Patch	在组合层替换或插入配置
Session Event Log	可恢复、可回放的运行状态记录

Service、Provider 和 Consumer

这套分层最容易从执行环境看出来。以 Shell 为例，DSH 不需要让模型工具直接绑定"本机 Bash"这一实现，而可以把能力拆成三部分：先定义 Shell Service 和请求结果类型，再提供本地执行、远程执行或 Sandbox Provider，最后由 Tool Consumer 把它暴露成模型可调用的工具。

text 复制代码

Shell Service Definition
          ↓
Local Provider / Remote Provider / Sandbox Provider
          ↓
Bash Tool Consumer
          ↓
Agent 可调用的 bash 工具

替换 Provider 后，上层工具仍然可以沿用同一个能力接口。文件系统、子 Agent、持久化和模型适配器也可以沿着类似的 Capability Seam 进行替换。

这套结构的价值不只是代码拆得更细。它把三个经常被混在一起的问题分开了：能力应该提供什么接口，能力在哪里运行，以及模型应该如何看到和调用它。对于需要嵌入业务系统的 Agent，这种分离比"把所有东西写进一个主循环"更容易形成多个产品组合。

Event、Scope 和 Profile

Event 是插件扩展 Agent 的主要入口。插件可以监听模型请求、工具执行、审批、Session 事件或 Agent 生命周期，在不直接修改 Agent Loop 的情况下增加策略、审计、上下文注入、结果处理和 UI 投影。

Scope 解决的是隔离问题。一个工具可以只注册到某个 Agent 或 Session，某个 Provider 也可以只对一段运行生效。对于企业产品，这意味着不同 Agent 可以共享一套 Runtime，但不必共享完全相同的工具和数据权限。

Profile、Bundle 和 Patch 解决的是组装问题。一个 Web Profile 可以叠加基础 Bundle 和 Web Bundle；Headless Profile 则可以换成没有服务器的 Runner；部署者还可以用 Patch 替换模型、执行环境、工具或策略，而不必 fork 整个 DSH。

架构示意图

图中底部的 Cordis 负责插件挂载、依赖解析、服务协作、事件扩展、作用域和生命周期；中间的 DSH Runtime 负责 Agent Loop、工具管线、上下文和 Session；两侧分别是产品入口和可替换 Provider。

从 Runtime 到 Agent 产品：以招聘系统为例

下面设想一家招聘 SaaS 把 DSH 嵌入自己的招聘系统。

这张图中，招聘协同 Agent 是招聘流程的"调度中枢"，它连接候选人分析、AI 面试、人才库巡检、Offer 跟进等多个专业 Agent，同时对接 ATS/招聘系统，负责让数据、任务和状态在这些能力之间流转。几个专业的 Agent 包括：

候选人分析 DSH：负责简历抓取、解析、归一化、匹配证据和候选人画像，本质上是"找谁合适"。
AI 面试 DSH：通过微信/H5 面向候选人，负责题库、追问、视频/转写、技能评分，最后输出结构化面试报告。
人才库巡检 DSH：定期扫描人才库、去重、发现高潜候选人并提醒。
Offer 跟进 DSH：负责确认、材料、入职提醒等后续流程。

同时在招聘系统里也有一个上层的业务 UI，实现人与 agent 的交互。

思考：Agent Runtime 的未来

我愿意称 DSH 的出现，是 Agent 时代的 VSCode 时代。

VSCode 在 IDE 和 Editor 之间巧妙地搭起了一座桥梁：VSCode 只负责一组稳定、通用的东西：文件、窗口、编辑、命令、Extension Host、UI 框架、Workspace、Terminal、Debug 接口。而大量的扩展能力------例如 Python 如何开发，Docker 如何管理，远程服务器如何连接------都交给了插件。

现阶段 DSH 的核心用户，是 Agent/Harness 开发者，或者是 AI 工程师，而 DSH 的价值则是帮助他们快速搭建自己的智能体运行环境，并且实现场景的适用性。

同样我相信，基于 DSH 或类似的脚手架，能够快速涌现出大量场景化的智能体环境，并服务于更广阔而垂直的终端用户。

DSH 会不会最终成为成功的那一个框架，依然很难说，但我相信这个趋势与方向将不可抵挡。