DeepSeek Harness 是什么：一切皆插件的 Agent 底座

一句话：Model + Harness = Agent

DeepSeek 在 2026 年 8 月 13 日开源了 DeepSeek Harness（命令行 dsh，npm 包 @deepseek-ai/dsh，MIT 协议，目前是开发者预览版）。官方给的公式很短：Model + Harness = Agent。模型是"大脑"，负责推理与决策；Harness 是环绕在模型外面的那层控制与编排系统——工具怎么调、任务状态怎么存、循环怎么跑到结束、界面怎么呈现。

它和 Claude Code、Codex 的根本区别不在功能清单，而在于这一层是不是产品本身。Claude Code 和 Codex 的 harness 是闭源的，你只能通过 MCP、扩展 API 去"接入"，核心看不见也改不了。Harness 反过来：把 harness 本身开源，并且宣称 "Everything is a plugin"——模型适配器、工具注册表、技能、会话日志、沙箱、存储、调度、UI，乃至 Agent 循环本身，全部是插件。你不需要动框架源码，就能以配置的方式替换任意一层。

内核：Cordis 的"时间可组合性"

这层的能力来自 Cordis——一个通用 TypeScript 插件元框架，作者是 Koishi（跨平台聊天机器人框架，社区插件超过 4000 个）的作者 Shigma（Yifan Shi）。DeepSeek 把 Cordis 源码 vendor 进自己仓库，改 scope 为 @deepseek-ai/cordis，并让几乎所有自家包都对它设成 peerDependency。设计思想有正式的论文支撑：《A Programming Paradigm for Spatiotemporal Composability》（arXiv:2608.25512，北京大学与 DeepSeek-AI 联合署名，2026 年 8 月预印本）。

论文把"动态组合"拆成两个正交维度：

时间可组合性（temporal composability）：组件被移除时，它对共享环境做的副作用必须被完整逆转。Cordis 的做法是"可逆 effect"：每一次上下文变换（注册服务、挂监听器、占用资源）都在运行时登记一个逆操作，卸载时按注册的逆序（LIFO）回滚。
空间可组合性（spatial composability）：组件声明依赖，依赖的出现 / 消失 / 替换会自动驱动该组件激活或停用。这被称为"响应式 coeffect"——上下文每次变化都拿组件的依赖规格去比对，判定为激活、停用或中性。

作者把这两者统一成单一 Context 类型，所有对外的交互都经由它中介，论文称之为 "context paradigm"。一个关键洞察是：进程重启和容器编排其实是粗粒度的可组合性——OS 能按进程回收资源，K8s 能按服务调整依赖拓扑，但为删掉一个组件而重启整个进程，会丢掉缓存、连接、中间计算。Cordis 想把这个保证下推到"进程内组件"级别。

这解释了 DSH 里几个乍看奇怪的设计：

每个 Agent 能力都挂在 ctx.<key> 服务上。搜索结果显示常见槽位包括 ctx.llm（模型适配器）、ctx.tools（工具注册表）、ctx.shell、ctx.sessions、ctx.agentLoop、ctx.subagents 等，各自的提供方都可以被替换。
配置即插件树。cordis.yml 里一行就是一个插件实例；@deepseek-ai/dsh-base 这类组合包，本质是把几十个插件一次性 insert 进空根，部署方在自己的 patch 层按 id 覆盖一行即可，无需改源码。
前端 UI 也是插件。dsh-client-ui-* 系列有几十个包，浏览器里跑着一个独立的 Cordis 客户端运行时；"双半插件"把宿主半（服务端逻辑）和浏览器半（UI）用 RPC 串起来。

写一个插件长什么样

Cordis 里"插件就是一个函数"，签名通常是 (ctx, config)，可选声明 inject 依赖。注册本身就是 effect：

import type { Context } from '@deepseek-ai/cordis'

export const name = 'greeter'
// 声明依赖：只有 llm 服务就绪时本插件才激活（空间可组合性）
export const inject = ['llm']

export function apply(ctx: Context, config: { greeting: string }) {
  // 注册服务：卸载时自动从服务表撤回
  ctx.provide('greeter', {
    greet: (who: string) => `${config.greeting}, ${who}!`,
  })
  // 注册监听器：同样是 effect，随插件卸载一并移除
  ctx.on('greet', (who: string) => console.log('hello', who))
}

注册一个模型可调用的工具，走的也是同一套机制：

export function apply(ctx: Context) {
  ctx.inject(['tools'], (ctx) => {
    ctx.effect(() => ctx.tools.register({
      name: 'hello',
      description: 'greet someone',
      parameters: { name: { type: 'string' } },
      async execute(args) { return `Hello, ${args.name}!` },
    }))
  })
}

register() 返回 disposer，插件卸载时工具自动注销；tools/result 事件让任何插件都能观察每次工具调用，而不必认识执行者。事件有四种派发模式：emit / parallel / bail / waterfall（waterfall 监听器必须调用 next() 才继续，否则短路）。

Harness 里最"自指"的包是 @deepseek-ai/dsh-tool-cordis，它给 Agent 五个工具：cordis_inspect（只读巡检当前进程：哪些服务在跑、各 fiber 状态、注册了哪些工具）、cordis_define（现场定义一个小插件）、cordis_run（把宿主半放入 node:vm 沙箱执行）、cordis_stop / cordis_undefine。也就是说，Agent 可以在运行中检查自己所在的框架、现场写一个插件、用完卸载，全程不改 cordis.yml、不装 npm 包、不重启进程。官方文档对信任边界说得很直白：动态包与 bash 同权，沙箱隔离全局但不构成安全边界。

四种模式与真实数据

开箱即用的四套预设：

模式	保留的能力	适用场景
标准模式	完整 coding agent：文件编辑、shell、搜索、Skills、计划、目标、子 Agent（20+ 工具）	日常写代码
PTC / Code 模式	标准能力 + 通过 Code Mode SDK 让模型生成 TypeScript 编排多次工具调用	多步骤、长程任务
极简模式	只有持久 shell + `str_replace_editor`	基准测试、研究模型原生能力
创造模式	完整能力 + 运行时巡检、插件实验、Preset 创建	开发 Harness / 插件

PTC 模式的动机是降低往返次数：传统是 LLM→Tool→LLM→Tool 串行，中间结果全塞回上下文；PTC 让模型先写一段程序，把"搜索→过滤→读取→修改"一次跑完，中间结果留在代码环境里，只把最终结果返回，天然支持 Promise.all 并行。

会话可观测性是另一条主线：只追加（append-only）的会话日志，规则是"模型看到的，一定被记录"——系统提示词、思维链、工具调用与结果、子 Agent 调度、每一次上下文注入都在里面，可在 Trajectory 视图按来源追溯，并支持恢复、分叉、检索、回放。

社区整理的官方 leaderboard 给了一组横向数据（同一 DeepSeek V4.1 Flash 模型，DeepSWE v1.1 resolved / Terminal-Bench 2.1 pass@1）：mini-SWE 74.2/90.3，DSH 极简 72.6/90.6，DSH 标准 70.5/85.8，Claude Code 69.8/88.0，DSH PTC 67.6/85.8，OpenCode 65.5/85.0。两个可读信号：极简模式反而略高于标准模式（72.6 vs 70.5），且榜首是"根本不是给人用"的基准专用 harness。这组数字只能当参考——同一模型换 harness 分数区间能拉开十几个点，说明"模型行不行"很大程度上是"你拿什么工具跑它"。

取舍：它适合谁

优势：MIT 协议可 fork 后闭源嵌入企业产品；模型无关（约 40 家 provider，子 Agent 甚至能委派给竞品 agent）；自托管、可自审计；沙箱是真实 OS 级隔离（Linux 上用 bwrap + Landlock，macOS 上用 Seatbelt，Windows 上用受限 ACL token，默认 fail-closed）；能力的可替换性把"换模型 / 换沙箱 / 换循环"从改装变成配置。

代价则集中在三点：

稳定性。官方明确写了"会有破坏性变更"。v0.2.1-alpha.1 单次发布就移除了运行时 invariant 插件并重命名了 composer 统计项，两者对插件作者都是破坏性的。想稳定就得 npx @deepseek-ai/dsh@<version> 钉版本。
安全。OX Security 报告了 CVE-2026-82533（CVSS 9.4）：沙箱内的 shell 能通过 loopback 访问 Harness 未认证的本地控制 API，而该 API 把请求里调用方自己提供的 Host 头当作信任凭据，于是一条被诱导的 shell 命令就能把会话设成 danger-full-access 并关掉审批提示。影响 0.1.1-rc.2 及更早版本，官方称在 0.1.2-alpha.1 修复。更普遍的教训是：控制平面绝不能落在被约束进程够得着的范围内，"能改写自己规则的沙箱是权限 UI，不是安全边界"。
成熟度。issue tracker 一度关闭，星数增长（12 小时约 5 万、28 小时约 9.2 万、10 天超 18.6 万、9 月底约 24.2 万）衡量的是关注度而非部署量，社区也在质疑发布是否存在营销推动。

适合谁：想自托管、不想被托管端点锁住、需要在自家产品里嵌入 Agent 运行时的团队；做 Agent 基础设施或插件生态的开发者；以及要研究"模型原生能力 vs 脚手架影响"的评测方（极简模式正为此而生）。不太适合只想找一个开箱即用 coding agent 的个人用户——那样 Claude Code / Codex 的完成度更省心。上生产的建议是：先在容器或 VM 里验证插件权限模型与第三方插件来源可信度，生产凭证不要靠近。

安装与上手：

# 直接跑（需要 Node）
npx @deepseek-ai/dsh web        # 起本地 Web UI，默认 http://127.0.0.1:3080

# 或从源码构建插件
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness && pnpm install && pnpm run build && pnpm dsh web

2026 年 9 月 29 日发布的 v0.2 预览还带来了 macOS / Windows 桌面端、无需 Node/pnpm 的应用内插件管理、计划任务，以及实验性的异步问答模式（等待超时后 Agent 继续干活，之后再和用户的回答对账）。桌面版在 Hacker News 上拿到 378 分、204 条评论——讨论里认同可观测性与插件模型的人不少，但同样多的人在问：它真的比别的 harness 更好用吗？该不该信任一个权限很宽、还会自我更新的二进制？

参考链接

Shi, Zhang, Cui, A Programming Paradigm for Spatiotemporal Composability, arXiv:2608.25512 — https://arxiv.org/abs/2608.25512
deepseek-ai/deepseek-harness（GitHub 仓库）— https://github.com/deepseek-ai/deepseek-harness
DeepSeek Harness 官方文档：Cordis tutorial — https://github.com/deepseek-ai/deepseek-harness/blob/7a71ab9a92cbb36f5e5e08fe6629ee245b84ac45/docs/cordis-tutorial/index.md
DeepSeek Harness 官方产品页 — https://www.deepseek.com/harness/en/
KDnuggets, What I've Learned About DeepSeek Harness（实测与沙箱细节）— https://www.kdnuggets.com/what-ive-learned-about-deepseek-harness
eesel, DeepSeek Harness (dsh) explained: how it works and what it costs（定价与开发者反馈）— https://www.eesel.ai/blog/deepseek-harness
OX Security 关于 CVE-2026-82533 的分析（沙箱控制平面越权）— https://www.hotmolts.com/post/-permission-checks-belong-outside-the-model-b2682b7b-bbe9-4aa7-b732-487c3701f34c

posted @ 2026-10-07 21:05 frankzch 阅读(32) 评论(0) 收藏举报

刷新页面返回顶部