Agent 工程与评测实验室

外观

DeepSeek Harness 案例

本页速览 剖析 DeepSeek 开源的 agent harness「dsh」——「Everything is a plugin」不是口号而是架构事实：模型适配器、工具注册表、会话、沙箱、存储乃至 agent 循环本身全部是 Cordis 插件。它与 Claude Code 的垂直整合路线构成设计空间的另一极，也是 meta-harness 思路的第一个大规模开源对照实验。

本页含时效性内容，数据截止于 2026-10；JD、价格、产品功能等信息可能已变化，引用前请核对原始出处。

DeepSeek Harness 案例 ​

2026 年 8 月 13 日，DeepSeek 把一个名为 DeepSeek Harness（命令行入口 dsh）的项目丢上了 GitHub：MIT 协议，一行 npx @deepseek-ai/dsh web 启动，自我定位只有一句话——"an open-source agent harness"。它没有捆绑任何新模型，没有宣称任何 benchmark 纪录，甚至 README 里用加粗字体警告：这是一个 developer preview，"会有破坏性变更"。

它引起轰动的原因不在功能，而在架构宣言：Everything is a plugin（万物皆插件）。模型适配器是插件，工具注册表是插件，会话、沙箱、存储是插件，agent 循环本身也是插件。支撑这套架构的底座是一个叫 Cordis 的插件内核——一个把"插件架构"本身写成论文（A Programming Paradigm for Spatiotemporal Composability）的元框架。

热度数据能说明这个方向踩中了什么：据第三方报道，开源两天 GitHub stars 即达约 9.5 万，六天超过 12 万（知乎专栏的统计），一个月后来到约 24 万（博客园）；开源仅两天，社区就长出了七百多个第三方插件（aistar.cool 的盘点）。这些数字全部来自第三方统计，无法逐一复核，但数量级本身已经是信号。

为什么这个案例重要

在 模型与 Harness 中我们说 "Agent = Model + Harness"。此前的案例——Claude Code、Cursor、Aider——都是产品：harness 是厂商写死的骨架，用户最多在外围扩展。DeepSeek Harness 是第一个把"Agent = Model + Harness"这个公式直接做成开源运行时的项目：模型可换，harness 的每一层也可换。它是 frontier 综述里 Anthropic "meta-harness" 设想的第一个大规模开源对照。

设计空间：垂直整合 vs 可组合 runtime ​

先把 dsh 放进我们已经解剖过的坐标系里：

维度Claude Code / Cursor 路线DeepSeek Harness 路线
harness 的产权厂商私有（或部分开源）的核心资产MIT 开源，且结构上鼓励被拆开
扩展方式外围扩展点（hooks、MCP、插件 API）没有"外围"——一切组件都是插件，包括循环
模型关系为特定模型深度调优（垂直整合）模型适配器是可替换插件，官方模型只是默认值
骨架的稳定承诺产品级稳定，向后兼容developer preview，明说会有破坏性变更
生态赌注产品体验的一致性插件生态的网络效应

这不是"谁更先进"的问题，而是两种不同的赌注。垂直整合赌的是：harness 与模型协同调优的复利大于开放性的损失——Claude Code 的工具描述、权限门控都是围绕 Claude 的行为特点精调的。可组合 runtime 赌的是另一边：harness 的组件正在变成易耗品，模型每升级一代，针对旧模型的 harness 补丁就过期一批（这正是 Anthropic 在 meta-harness 一文里承认的问题，见 frontier），因此与其维护一个写死的骨架，不如把骨架拆成可更换的关节。

"没有特权核心"是什么意思

dsh 产品文档里有一句关键表述（据腾讯云开发者社区对架构的转述）："没有特权核心可打补丁——你扩展 dsh 的方式是在其他插件旁边挂载一个新插件。"这与 VS Code 当年的选择同构：编辑器本体也只是一批插件。代价是厂商放弃了"核心永远正确"的护城河，收益是社区不是在给一个产品做锦上添花，而是在参与定义这个产品是什么。

架构：一棵插件树 ​

dsh 的运行时组织形式是插件树：启动器按 profile（一份具名的组装清单）把一层层插件依序挂载，形成一棵可增删、可替换的树。据官方架构文档（经 DSH Plugin Hub 的架构教程转述），树的第一层是 dsh-base——被各种运行方式共同复用的公共能力层；往上才是各运行形态各自的插件层。

text
┌─────────────────────── dsh 启动器（按 profile 组装） ───────────────────────┐
│                                                                            │
│   运行形态层    Web UI 插件 │ headless 插件 │ SDK 插件 │ ACP 插件 │ TUI 插件 │
│  ────────────────────────────────────────────────────────────────────────  │
│   dsh-base（所有运行方式复用的公共层）                                        │
│     ├─ 模型适配器（插件）      ├─ 工具注册表（插件）                          │
│     ├─ 会话（插件）            ├─ 沙箱（插件）                                │
│     ├─ 存储（插件）            ├─ 调度（插件）                                │
│     └─ Agent 循环（插件）      └─ 技能 / UI（插件）                           │
│  ────────────────────────────────────────────────────────────────────────  │
│   Cordis 内核：只负责插件的加载/卸载与依赖关系                                 │
│   插件之间通过「服务 + 类型化事件 + 可逆副作用」协作                            │
└────────────────────────────────────────────────────────────────────────────┘

官方架构参考对 Cordis 的角色描述得很克制（dsh 官方文档 Architecture 一章）：插件向一个共享 context 贡献服务（services）、类型化事件（typed events）和可逆副作用（reversible effects）；"产品的每一部分都是插件"。Cordis 源自 Koishi 聊天机器人生态（据 DataCamp 的梳理）——一个久经考验的插件内核被移植到了 agent runtime 上。

启动方式印证了"薄启动器"的设计：README 给出的主路径是 npx @deepseek-ai/dsh web，默认在 http://127.0.0.1:3080 起 Web UI；文档另有 headless、SDK、ACP 等模式，桌面端则在 2026 年 9 月底发布（据博客园报道）；全屏终端入口 @deepseek-ai/dsh-tui 同样是一个独立插件而非内置界面（据 GitCode 博客的架构分析）。交互形态与 agent 内核是两层可独立替换的东西——这与 Kimi Code 把 CLI/Desktop 做成同一 agent 核心的两个壳（见 Kimi Code 案例）思路相通，但 dsh 走得更远：连"壳有哪些"都由插件生态决定。

时空可组合性：插件架构的论文级地基 ​

"万物皆插件"的难点不在"能挂插件"——任何框架都能挂——而在两个插件组合之后行为是否还可预测。Cordis 的设计论文标题里的关键词是"spatiotemporal composability（时空可组合性）"，其中"空间"一维解决的是一个具体的问题——多 agent 化之后才会暴露的问题：

同一个进程里跑两个 agent，它们可能要用不同的模型、不同的工具集、不同的沙箱。如果 ctx.llm 永远指向一个全局单例，插件替换就只能发生在进程级，多会话并存立刻冲突。据掘金上对 Cordis 机制的拆解，Cordis 的解法是 Context.isolate：为指定服务名创建一个 realm（隔离域）标签，服务注册与查找都以该标签定位——同名服务在不同子上下文里各自存在，子上下文通过原型继承父上下文。换句话说，"哪个 agent 用哪个模型"从全局配置变成了作用域问题。

从 harness 视角看，这件事的意义要放大了看：子代理与多 agent 编排的第一个工程瓶颈往往不是智能，而是配置隔离——主 agent 与子 agent 的模型路由、工具白名单、权限策略如何各不相扰。dsh 把这个问题下沉到了插件内核层面解决，而不是在每个上层功能里各自打补丁。

插件化对 harness 研究的三重意义 ​

第一重：权限边界变得可插拔。 当沙箱、工具注册表都是插件，"这个 agent 能碰什么"就不再是 harness 写死的策略，而是组装决策——给生产环境的 profile 挂强沙箱插件 + 白名单工具注册表，给实验环境的 profile 挂宽松实现，代码一行不改。dsh 官方快速上手里"如果根据当前权限策略某项操作需要审批，Web UI 会先询问你"的表述（官方文档）说明权限策略本身就是可替换组件。这为权限与安全提供了一个新实验台：权限机制可以作为独立变量被 A/B 比较，而不必换整个产品。

第二重：agent 循环成为研究对象。 循环是插件，意味着研究者可以在同一套工具、会话、存储之上，只替换 agent 循环的实现来比较 ReAct 式、规划式、事件驱动式循环的差异——harness 消融实验的基础设施第一次以开源形态存在。考虑到 2026 年 5 月"不披露 harness 的分数不可比较"的评测檄文（见 frontier），一个组件级可替换、配置可公开分享的 harness，恰好是"可比较性"需要的土壤。

第三重：社区开始反向定义组件清单。 开源两天七百多个插件的构成很有说服力：长期记忆、上下文体检、轨迹调试（断点回放、分叉对比）、多 agent 团队、computer use（据 aistar.cool 的盘点）。注意这份清单——它几乎就是本站组件章目录的市场化投票：记忆、上下文工程、可观测性、多代理、计算机操作，每一个都立刻有人愿意写代码补。这反向验证了 harness 组件分类学不是学院派的构造，而是用户真实需求的形状。

权衡与取舍 ​

可组合性的账单同样清晰，且 dsh 自己从不掩饰：

  • 破坏性变更是常态而非事故。 README 明写 "THERE WILL BE COMPATIBILITY-BREAKING CHANGES"。插件生态越繁荣，内核每次破坏性变更的波及面越大——这是 VS Code 用多年才趟平的治理问题，dsh 把它压缩进了几个月。
  • 组合自由意味着组合责任。 当一切可替换，"我的 agent 为什么行为诡异"的答案空间就从"产品 bug"扩展到了"插件 A × 插件 B × 模型 C 的交互"。调试责任被分散到了一个没有统一质量门槛的生态里——插件质量参差、生态碎片化的风险，社区观察者自己也在提（据知乎专栏的直言："不是因为它今天能投产，是因为它的架构方向"）。
  • 没有垂直整合，就没有协同调优的复利。 Claude Code 的工具描述是为 Claude 的行为习惯磨出来的；dsh 的模型适配器要同时迁就多家模型的脾气，任何单一模型上的峰值体验都很难追平垂直整合产品。它卖的不是"今天最好用"，是"明天不被锁死"。
  • ** stars 不等于可用性。** 二十几万 stars 投的是架构方向的票，不是生产就绪的票。developer preview 阶段把它当研究对象和二次开发底座是合理的，当生产力工具则需要自担风险。

从 DeepSeek Harness 学到的 ​

  1. harness 的组件清单可以被市场验证。 插件生态的自发构成（记忆、上下文管理、轨迹调试、多代理）是对"agent 系统该由哪些组件构成"最真实的投票。
  2. 可替换性本身是一种架构能力，需要地基支撑。 "万物皆插件"能成立，靠的是内核级的服务隔离（realm）与可逆副作用，而不是一个 plugins/ 目录。想做可组合 harness，先把作用域和生命周期问题在内核层解决。
  3. 垂直整合与可组合是真权衡，不是先进与落后。 前者买协同调优的复利，后者买不被模型迭代和厂商绑定锁死的自由。选型前先问自己：你的 harness 补丁，有多少会在下一代模型发布时过期？
  4. 把循环、权限、沙箱做成可替换件，harness 就变成了实验仪器。 这是 dsh 对研究社区独特的价值——消融与对照第一次不需要重写整个脚手架。

延伸阅读 ​

参考资料 ​