初见DeepSeek Harness和论文解析 DeepSeek Harness 简介DeepSeek Harness简称 DSH是 DeepSeek 于 2026 年 8 月开源的一款 AI Agent 运行时框架基于 Node.js 构建以 MIT 协议发布。它的核心理念是 “一切皆插件”——模型适配器、工具注册表、会话日志乃至 Agent 主循环本身均为可替换插件底层基于北大与 DeepSeek 联合研发的 Cordis 元框架实现动态组合。DeepSeek 给出了一个直白的公式Model Harness Agent。模型负责思考推理Harness 则赋予模型“动手”的能力——读写文件、执行命令、调用工具、组织多步任务让 AI 不再止步于对话而是能从头到尾把事情做完。Harness 预置了四种运行模式标准模式提供完整的编码 Agent 能力极简模式仅保留两个核心工具适用于基准测试PTC 模式让模型生成 TypeScript 脚本将多步工具调用压缩为单次交互大幅提升效率创造模式则允许 AI 检查和修改自身运行时配置。框架兼容 OpenAI、Anthropic、AWS Bedrock 等 40 余家模型提供商并内置 MCP 客户端与多层沙箱安全机制。截至 2026 年 8 月发布仅数日DSH 在 GitHub 已收获超 14.9 万 Star社区贡献了超 5100 个插件被开发者称为“Agent 领域的 Linux 时刻”。接入 DeepSeek Harness通过npx运行安装Node.js然后运行npx deepseek-ai/dsh web该命令默认会在http://127.0.0.1:3080启动 Web UI本机启动时还会用默认浏览器打开页面。通过 SSH 启动时只打印宿主机 URL因为本地转发地址由 SSH 客户端或编辑器管理。传入--no-open可仅运行服务器而不打开浏览器。详见 Web UI 指南。从源码运行如需从仓库源码运行git clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build pnpm dsh webpnpm run build会准备仓库产物。pnpm dsh web会直接使用这些已构建产物不会重新构建。安装方式摘自 DeepSeek Harness GitHub 主页这里也将地址贴出来大家有需要可以自己去看看DeepSeek Harness GitHubDeepSeek Harness 设计原理它采用一切皆插件的架构并由 Cordis 驱动其设计参见论文 A Programming Paradigm for Spatiotemporal Composability。我在阅读完论文后也整理出了一些个人见解。我把自己觉得比较有意思的内容摘了出来那些理论知识我其实也没有理解得很透彻这篇文章只是将论文中的一些原理整理出来。1、 静态组合 vs 动态组合传统组合函数调用、模块导入、类继承在编译期解析、运行期不变。而插件架构、自我进化的 agent harness 需要在运行时加载、卸载、重配置组件。尽管实践上越来越重要动态组合的形式化基础远落后于静态组合的丰富理论。作者提出组合性的两个正交维度超越已被充分研究的代数方面维度含义静态情形下的退化形式动态情形下的困难时间可组合性组件移除时其对共享环境的修改能被完全、安全地逆转词法作用域RAII、bracket 模式长生命周期、有状态的效应作用域不再被词法界定空间可组合性组件间依赖能结构化地声明、发现、解析、响应变化模块导入解析依赖在运行中出现、消失、更换身份2、 动机示例VSCode 插件系统时间维度的失败所有扩展跑在共享的 extension host 进程中无法在运行时卸载单个扩展的代码。前 100 名扩展中 87 个含可执行代码禁用/卸载它们必须重启整个宿主。deactivate钩子只是宿主进程终止前的优雅退出回调不支持热移除且它把效应清理与效应创建在activate中分离违反局部性原则清理的完备性无法验证。VSCode 的空间维度失败extensionDependencies几乎无人使用前 100 名仅 7 个声明vscode.extensions.getExtension(...).exports返回any无类型契约。自我进化的 agent harnessharness 在持续服务请求的同时生成并部署对自身组件的修改。没有时间可组合性 → 每次自修改都要全量重启、丢弃进程内累积状态、打断在途任务甚至一次错误的自修改可能摧毁恢复机制本身没有空间可组合性 → 每个模块只能以 ad hoc 方式探测依赖变化朴素替换会静默破坏依赖方或引入重载时才暴露的循环依赖。粗粒度替代方案的代价OS 在进程粒度提供时间可组合性、容器编排器在服务粒度提供空间可组合性。代价重启丢失所有进程内状态缓存、连接、部分计算重建需秒到分钟级还需冗余副本维持可用性容器级编排无法表达同地址空间内的组件依赖把本可以是本地函数调用的交互变成网络开销。3、 贡献清单形式化可逆效应revertible effects——局部时间可组合性形式化反应式协效应reactive coeffects——局部空间可组合性统一为单一上下文类型观测等价供给效应独立性——构成一种编程范式给出动态组合演算及其元理论把两维保证从单组件提升到整个系统实现Cordis元框架核心库 声明式加载器 HMR并以 Koishi 验证。实现Cordis以下至“案例Koishi”部分为论文 §5 内容的摘译整理非我的原创内容。三层核心库效应/协效应→ 组件加载器配置 reconciliation HMR→ 应用框架Koishi。Table 2 给出 30 余条理论-实现对应举要理论实现Γ∞ctx一等上下文effectΓ(e)ctx.effect(callback)Σ / Σiso / Σinterctx[store]/ctx[isolate]/ctx[intercept]get(k) / set(k,v)ctx.get(key)/ctx.set(key, value)fiber ⟨d,p,e,π,σ,τ,θ⟩fiberfiber.uid/fiber.inject/fiber.apply/fiber.parent/fiber.state累加器 gfiber.dispose承诺视图 ωfiber.committed目标视图 targetfiber.target由refresh重算惯性 Futurefiber.inertiaO-Insert / O-Retirectx.use与其回调的逆L-Begin/Iter/Finishexecute的迭代循环L-Leaverefresh标记 UNLOADINGL-Unload 的守卫unload等待被通知的依赖方1、 核心库Algorithm 1效应追踪ctx.effect(callback)是effectiter的实现。execute引擎把回调当效应迭代器驱动guard 在每步前检查目标稳定性每个 yield 的逆前插复合LIFO。dispose翻转 armed 标志同时停止在途迭代 保证恢复至多一次——二次触发会把逆施加到没有应用产生过的状态并把自己前插到父上下文的ctx.dispose——子效应的逆本身是父上的效应即²Γ的递归结构。运行时不验证见证条件逆是否真的恢复效应是组件作者的义务§6.1 划定其边界。Algorithm 2/3协效应操作三个 symbol 键槽位storerealm → 值、isolatekey → realm、interceptkey → 元数据。set 是 ctx.effect 调用安装和移除都调notify。notify 遍历所有活 fiber若变化 key 在其 inject 中且解析到同一 realm则 refresh 之并返回受影响的 fiber供调用方等待。绑定只在安装它的 fiber 处于 ACTIVE 时可用——这使撤回对依赖方提前一步可见进入 UNLOADING 的 provider 已停止提供依赖方在其绑定全部仍在时就开始自己的拆卸。隔离/拦截都派生子上下文覆盖一张表恢复是隐式的丢弃子上下文。Algorithm 4/5生命周期ctx.use(component, config)config 绑定进fiber.applycallback注册原语执行时 refresh 启动子生命周期恢复时强制目标为 ⊥ 并触发 unload——实例化是父的普通被追踪效应卸载父级联到子refresh重算 fiber.target每个声明 key 解析到 provider 的 uid 的摘要——按 provider 而非按值识别uid fresh 不复用替换 provider 不会被误认不在转移中则发起 reload 或 unload 任务reload提交解析视图fiber.committedexecute 驱动 applyguard 是目标未变完成时再检查目标——仍匹配进 ACTIVE 并 notify不匹配链接到 unload不论新目标是 ⊥ 还是另一组 providerunload先await所有被通知依赖方到达 INACTIVE守卫再施加fiber.dispose最后按当前目标链回 reload 或落定 INACTIVE。等待置于整个恢复之前而非某个逆内部因为 fiber 的各效应并发启动放在其中一个里会使其余的失序。终止性对应 Thm 66fiber 只等待已不可能满足的依赖方provider 图按需遍历而非预先分析。两个互补层级转移级reload/unload 完成时检查目标——惯性链接 迭代级execute 在每个迭代边界检查目标——部分回滚分别对应 §4.3.3 的转移间链接与 Thm 64 依赖的转移内过期检查。Algorithm 6Proxy 属性访问ctx[key]沿 fiber 链向上走——第一个承诺视图绑定 key 的 fiber 授权访问遇到声明了 key 但未承诺的 fiber 抛INACTIVE_ACCESS走到 root 无声明抛UNDECLARED_ACCESS。与裸ctx.get的区别Proxy 对照访问者自己的视图解析并在使用点强制执行规格 d读视图而非读存储正是 Thm 63 的支点依赖消失触发拆卸的组件在拆卸期间仍能读它。这是运行时检查但 d 是静态声明的编译期检测原理上可行§6.4。2、 组件加载器声明式配置entry {id, url, isolate, intercept, config, disabled}。entry 能忠实指定 fiber 的原因支撑集Definition 67恰好只读 τ/π/d/p而 entry 给出全部四个——disabled 给 τ、树中父给 π、url 选定组件从而给 d 和 p。cordisjs/group子 entry 列表与cordisjs/include外部 YAML/JSON是普通组件嵌套树仍在演算内。Reconciliation 的可靠性由元理论逐条供给Thm 73 ⇒ quiescent 状态只是最终配置的函数增量重建与从零装配殊途同归Thm 66 ⇒ 必然 quiesceCorollary 62 ⇒ 重建一个 entry 不波及邻居Thm 63 ⇒entry 可并发实例化无加载顺序问题——依赖约束的是激活时机而非模块求值时机模块可并行加载。分派按字段取最小扰动操作id/url 重建isolate 重指派 realmintercept 原地更新读时生效无需重载config 交给组件 diffdisabled 卸/载。group 的 config 就是子 entry 列表 → keyed diff与 entry 更新递归下降。受管 realm 与 Algorithm 7entry 可在组间移动loader 自己管理 realm——isolate: true要私有 realm按 id 标记随 entry 移动字符串要全局共享 realm。难点realm 符号可能被多个 fiber 共享而只有一个是 provider。解法分隔符每 key 一个符号 δₖcontext 上写标签、后代继承——entry 与 provider 的标签一致 iff 两者派生自同一 isolate 作用域即绑定是 entry 自己的、必须随它移动。重指派后own 在依赖方与 provider 上一致 ⇒ 两者同移或同留依赖方看到的绑定不变分离 ⇒ 依赖方获得或失去绑定。HMR三阶段§5.2.2fiber 已界定组件的全部效应与协效应所以模块替换 处置旧 fiber 用重载的模块实例化新 fiber无需 Webpack/Vite 那种开发者标注的 accept 边界。Phase 1 模块分类stashed已变更externals不可热替换不动点传播有 import 被接受则接受、全部 import 被拒绝则拒绝、环中悬置者默认拒绝Phase 2 过期 entry 检测依赖树与 accepted 相交则过期树并入 acceptedPhase 3 事务性重载失效缓存备份逐 entry dispose 重新 import 换 fiber任一失败则恢复缓存、全部回滚到备份组件——系统永不处于半重载状态。3、 案例KoishiKoishi 是基于 Cordis 的开源聊天机器人框架历经四年发展已积累 4000 社区插件。它验证了表达力——每个功能都是上下文原语上的插件Koishi 只贡献聊天机器人领域词汇一般性——Web 控制台是第二个独立 Cordis 应用插件组合的是浏览器与 UI 原语。时间维度编排器从控制台禁用插件效应就地撤回HMR 保存时重应用编辑过的插件同时保留系统别处的缓存状态与活连接——不熟练的作者也不写卸载路径就获得有序清理局部性原则的恢复。空间维度真实依赖拓扑IM 适配器、数据库驱动作为 provider功能插件声明协效应切换存储后端只重激活解析到它的依赖方插件与依赖通常由不同作者编写除连接它们的协效应外无任何协调。效度威胁单生态、单宿主语言、观察性证据——建立的是存在性与采纳性结果量化对比留作未来工作。结束语回头看这篇论文的贡献链条其实很清晰可逆效应解决能不能安全地撤反应式协效应解决依赖变了怎么办动态组合演算把这两个保证从单个组件推广到整个系统最终落到 Cordis 这个能跑的框架上。它不是一篇读完就能用的工程手册但它回答了插件系统领域一个长期悬而未决的问题动态组合这件事能不能像静态组合一样被形式化地保证论文给出的答案是能并且给出了实现路径。而 DeepSeek Harness 让我感兴趣的地方恰恰是论文结尾写下的那个未来方向——把 Cordis 应用于自我进化的 agent harness。当我在 DSH 里切换插件、看着它热更新自己的组件时用的正是这套理论的落地形态。论文里那些我当时读得吃力的概念——卸载时的累加器、依赖的解析视图——此刻就真实存在于这个工具的运行时里。先摸到工具再回头读懂原理这大概是我这次初见最大的收获理论和产品之间的那层纸被这次阅读捅破了一个角。必须坦白的是这篇 88 页的论文我并没有完全吃透——元理论部分的证明细节我仍是一知半解上面的整理如果有理解偏差欢迎指正我会去核对修正。但即便只读懂了一部分它带给我的启发也是真实的原来卸载一个插件这样习以为常的操作背后可以有一整套严谨的形式化保证。如果你也在用 DSH或者对插件系统、agent 架构感兴趣强烈推荐读一读原论文哪怕和我一样只能读懂一部分那部分也值回阅读的时间。后续我也会把实际使用 DSH 的体验整理出来算是这篇纸上得来的下篇。