本文永久链接 – https://tonybai.com/2026/08/14/deepseek-harness-everything-is-a-plugin
大家好，我是Tony Bai。
【导读】
昨晚，DeepSeek悄悄放出了一枚重磅炸弹——开发者预览版 Agent 驾驭框架 DeepSeek Harness（dsh），并以 MIT 协议同步开源。它最大的野心不是又造一个「能跑」的 Agent，而是把模型、工具、技能、会话、沙箱、存储、循环、调度、UI 这些原本焊死在代码里的能力，统统拆成了可插拔的插件。这篇文章带你拆开引擎盖，看看「一切皆插件」到底是怎么做到的，以及它在会话压缩、长期记忆这些前沿方向上，交出了一张什么样的答卷。
【文章要点】
今天，DeepSeek Harness 开发者预览版（v0.1）面向全球开发者开放测试，代码仓库同步以 MIT 协议公开。官方在公众号文章中直言，这仍是一个「有许多细节有待改进和打磨」的早期预览版，核心插件与基础接口都会在后续快速迭代演化。
但即便只是 v0.1，这个项目透露出的架构野心已经足够让做 Agent 工程的人坐直了身子——它的设计目标不是「造一个好用的 Agent」，而是「造一个能长出无数种 Agent 的地基」。
过去一年，「模型」之外的战场正在悄悄转移到「Harness（驾驭框架）」。同样一个基础模型，套上不同的循环逻辑、工具集、上下文管理策略，跑分和体验能差出一大截。Claude Code、Codex CLI 这类产品的成功，某种程度上正是把「Harness工程」和「模型能力」拆成了两条同样重要的曲线。
DeepSeek 这次交出的答卷，选择了一条相对少见的路：不是做一个功能强大但结构封闭的驾驭框架，而是先把「架构可扩展性」立住，再把功能一点点长出来。这也是为什么，它给自己的核心设计思路只起了一个名字——「一切皆插件」。
DeepSeek Harness 的底层由一个叫 Cordis 的元框架驱动，这套框架的思路来自论文《A Programming Paradigm for Spatiotemporal Composability（时空可组合性的编程范式）》。在 Cordis 的世界观里，插件向一个共享的上下文（context）贡献服务、类型化事件和「可逆效应」，而 Agent Harness 里的每一个部分——模型适配器、工具注册表、会话日志，乃至 Agent 循环本身——都是插件。
这意味着这个项目里不存在一个可以被「修改」的特权内核。要扩展 dsh 的能力，开发者不需要改动 DeepSeek Harness 的源码本身，只需要把自己的插件挂载到插件树旁边；插件卸载时，它注册过的一切也会随之撤销（reversible effects）。这也是官方反复强调的最重要设计原则：一切皆插件。
如果说 Cordis 是骨架，那么 profile（配置档案） 和 bundle（能力捆绑包） 就是把骨架组装成一个具体产品的方式。
cordis.patch.yml。官方内置了 web 和 headless 两套模板。一个真正跑起来的 dsh，是启动时按顺序层层叠加出来的插件树：先按 profile 里列出的顺序挂载各个 bundle，再依次应用 profile 级、用户主目录级、以及命令行 --patch 传入的补丁——每一层补丁都可以按 id 定位某一行配置，整体替换，或者插入新行。开发者甚至可以用一条命令直接看到自己机器上实际跑起来的插件树：
dsh --profile web --dump-config
打印出来的任意一行，都可以被自己的补丁替换掉。这套机制把「换一个模型」、「换一套工具」、「换一个沙箱」等这类原本要改代码的操作，变成了改配置。
「一切皆插件」听起来讨巧，但真正决定一个 Harness 好不好用的，是它的 Agent 循环（loop）设计得够不够干净。DeepSeek Harness 把这部分拆得相当细致。
在 dsh 的模型里，一个 step（步骤）是一次模型请求加上它调用的工具；一个 turn（回合）由零到多个 step 组成，从认领第一份输入开始，到没有任何「欠账」时结束。
一次典型的回合大致会经历这样的流程：
-> 认领下一步的输入与排队消息
-> 组装提示词分区与工具schema
-> 进入 agent/pre-step 决定模型到底能看到什么
-> 追加消息进日志
-> 发起模型请求
-> 流式接收结果
-> 按需调用工具
-> 决定是否需要下一个 step，直到整个回合收尾
这套循环里的每一个关键节点，都对应着一个可以被插件监听或拦截的事件，官方把这些事件分成三类：
session/event 广播，凡是需要「重启后还在」的东西都用它；agent/*）：携带一个「活的」Agent 对象——收件箱、步骤、状态、请求、校验、续跑，用来观察或介入正在进行中的工作；其中 agent/pre-step、agent/request、llm/stream 以及三个 tools/* 事件是瀑布型（waterfall）事件——监听者必须显式调用 next() 才能把控制权继续向下传递，这意味着任何一个插件都可以在这里「拦下」一次请求、重写要发给模型的消息，甚至直接拒绝掉这次输入；而 agent/turn-stopping 是串行事件，没有 next()，专门用来终止一个回合。
换句话说，Loop 本身也只是一个默认实现的插件（对应 core/agent-loop 包），开发者理论上可以完整替换掉它，换上自己的调度逻辑。
DeepSeek Harness 有一条贯穿全文的硬规则：模型看到的一切，都必须能从日志里还原出来。
会话日志是一份仅追加（append-only）的 SessionEvent 流，deriveMessages() 函数负责从这条日志里投射出模型实际看到的历史，而原始的 assistant/chunk 流式事件则保留了回放与 UI 还原的完整保真度。
这个设计带来的直接收益是：分叉（fork）、恢复（resume）、完整轨迹回放、遥测与持久化，全部由同一条事件流派生而来，不需要额外维护一套「状态快照」逻辑。
官方产品里的 Trajectory（轨迹）视图，就是把系统提示词、思维链、工具调用与结果、子 Agent 调度、每一次上下文注入，按来源摊开展示，支持从任意节点恢复、分叉、检视和回放，而且这些操作共享同一份事件流——这在débug 长任务、复盘 Agent 决策路径时会非常实用。
对 Harness 工程师而言，比「循环怎么设计」更硬核的问题往往是：上下文快用完了怎么办、Agent 怎么记住几天前做过的事。这恰好是这次开源代码里最值得多看两眼、但官方公众号没有展开讲的部分。
从代码目录结构看，DeepSeek Harness 在 核心层专门留出了一个 compaction/ 包，定位是「压缩能力（capability）+ 一个基础 provider（basic provider）」——也就是说，官方目前提供的是一套可替换的压缩接口，配上一个相对朴素的默认实现，而不是一套开箱即用的高级上下文管理策略。这符合整个项目「先立骨架、再长功能」的节奏：v0.1 阶段先把「压缩是什么、怎么接入」的接口定清楚，具体怎么压得更聪明，留给后续版本和插件生态去卷。
有意思的是，插件生态几乎是在开源当天就闻风而动：目前已经能看到一批围绕上下文与记忆的第三方插件在路上，比如把「模型自己决定何时压缩、压缩什么」的自适应上下文压缩（ACP）思路移植过来的压缩插件、面向跨会话长期记忆与后台自我进化的记忆插件，还有主打用小模型做因果图检索、实现超长等效记忆的轻量记忆插件。这些探索方向，恰恰是当前 Agent Harness 领域公认的前沿难题——没有一家能说自己已经做到最优，DeepSeek 选择把这道题目留在插件层，某种程度上也是「一切皆插件」这套架构哲学的自我验证：官方负责把接口和边界定义清楚，剩下的交给整个开发者社区去共同摸索。
顺带一提，「同一会话内目标管理」这类偏记忆/规划性质的能力，在架构文档里也单列了一个扩展点（ctx.goals），配合子 Agent 委派机制（subagent seam），理论上可以支撑更复杂的多步骤、多 Agent 协作场景——但这些同样还处在「接口已定义、玩法待长出」的阶段，值得持续关注后续版本的进展。
除了循环和日志，dsh 还有一个专门用来保证「插件可替换性」落到实处的抽象，官方称之为 seam：每一个可替换能力都由三个角色组成——声明接口的 Service Definition、实现接口的 Service Provider、使用接口的 Consumer（通常是一个面向模型的工具）。一个包可以同时承担多个角色，但只承担一个角色并不足以构成一个完整的 seam。
这个设计的价值在于「一次替换，处处生效」。举个官方给出的例子：文件系统与子进程 provider 共享同一个执行世界，所以只要把它们指向一个远程沙箱，Bash、PTY（伪终端）、LSP（语言服务器）这些能力会跟着一起迁移过去，不需要为每个工具单独做适配分支。子 Agent 的 provider 同样可以在这套接口下自由切换——从「拉起一个全新的子 Agent」到「把这个 turn 委托给另一个产品处理」，背后都是同一个接口。
针对不同的使用场景，DeepSeek Harness 提供了四种预设的加载不同插件集合的运行模式：
想快速体验的话，在已安装 Node.js 的机器上，一条命令即可拉起 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
DeepSeek 在文章末尾说得很实在：v0.1 版本只是一个起点。比起「功能是否够多」，这次开源更值得关注的是架构选择本身——把模型、循环、会话、存储、UI 全部拆成同一套接口下的平等插件，没有特权内核，没有必须硬编码进主干的「官方逻辑」。
这套打法的下限，是给开发者一个足够干净、足够可控的地基；它的上限，则取决于会不会有足够多的人愿意在这个地基上，去啃压缩、记忆、多 Agent 协作这些真正难啃的骨头。
至少从开源当天生态插件冒头的速度看，这个赌注，已经开始有人接了。
资料来源
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。