DeepSeek Harness是DeepSeek开源的Agent运行时框架，把Agent拆成可组合的积木。这是Harness系列第2篇，上篇讲了Harness是什么，这篇拆一个真的给你看。

我第一次听说DSH的时候，以为又是来卷Coding Agent的。Claude Code、Codex已经够多了，再来一个能有多大区别。真正读进去才发现，它问的问题根本不在同一层：一个Agent跑起来，到底哪些能力必须固定，哪些都可以换。这个问题一换，整个架构的形状都不一样了。

上一篇讲Harness是什么，这篇拆一个真的给你看

上篇我们聊的是通用道理：模型负责想，Harness负责剩下的一切。这篇落到一个具体的东西上，看DeepSeek怎么把这套道理变成代码。

2026年8月DSH开源的时候，Flask作者Armin Ronacher公开说，这是他第一次在这个领域看到新东西，有必要回头重新审视自己团队的一些选择。一个见惯了框架的人说出这种话，说明DSH动的不是皮毛。

它的起点是：传统Agent框架更像是先造好一个Agent，再让你扩展它。Context怎么组织、模型怎么调、工具怎么执行、会话怎么存，框架先定好，再通过工具、MCP、插件向外扩。DSH反过来，先把模型、会话、工具、执行循环、沙箱、子Agent这些运行时基础能力拆开，再通过不同组合形成不同类型的Agent。Coding Agent只是其中一种组合结果。说到底，一个是卖整机，一个是卖积木。

别把它当Coding Agent，它是卖积木的

一切皆插件这句话很容易被误解。Claude Code、OpenCode都有插件，如果DSH只是允许加工具加Hook，那确实没什么特别。

真正的区别在于，别人是先有一个相对固定的Agent核心，再让插件扩展这个核心。DSH把传统上属于核心的很多能力本身也做成了插件。官方有一句很强的表述：不存在一个只有改框架核心源码才能改变其行为的特权核心。换会话、换文件系统、换模型供应商，甚至换Agent的运行方式，都希望通过插件和能力组合完成，而不是Fork上游代码。

Agent Loop就是典型例子。准备上下文、调模型、调工具、返回结果、进下一轮，这通常被认为是最核心的逻辑。但DSH把Agent是什么和Agent怎么运行进一步拆开，定义状态和契约的部分归一边，循环本身做成默认驱动，意味着循环也是可替换的能力。还有Code Mode，模型主要通过写程序、在程序内部连续调工具，而不是每一步都经过模型。这种做法的本质，是把部分程序控制流从模型手里交还给代码执行。极简预设只保留少量基础工具，背后的判断是：模型越强，真正不可缺少的基础能力反而越少。

插件化到什么程度，连Agent Loop都能换？

光说能换还不够，怎么换得稳才是关键。DSH第二个值得看的设计是会话。

普通Agent系统往往同时维护好几份记录：聊天历史、工具历史、追踪、运行日志，调模型前临时拼出真正的请求。这样很容易出一个问题：日志里记的东西，不一定等于模型当时真正看到的东西。比如某个插件临时往提示词里注入了一段上下文，却没同步进聊天历史，事后就算保存了聊天记录，也回答不了一个问题：当时模型到底看到了什么。

DSH做了两层约束。第一，会话用只追加的事件日志，已经发生的事件不直接改，通过追加新事件表达变化，让会话日志成为事实来源。第二，模型看到的内容必须能由会话日志重建，用户消息、助手消息、工具结果从日志生成，系统提示词、工具结构、调用配置也都通过事件记录。官方把它概括成一句话：只要模型看到了，就必须有日志依据。这样一来，回放、恢复、分叉、调试、审计都好做，只追加的历史还有利于保持提示词前缀稳定，复用缓存。真正重要的不是事件日志本身，而是DSH在保证一件事：模型实际看到的东西和事后日志，不应该变成几份逐渐不一致的数据。

模型看到的东西，必须能从日志里还原

如果只是把系统拆成很多包，并不会自动获得可组合性。关键在模块之间有没有稳定的能力边界，DSH把这种边界叫做能力接缝。

拿文件操作举例，模型看到的可能是读文件、写文件这些工具，但底层真正执行的可以是本地文件系统，也可以是沙箱或远程环境。一个能力通常拆成三个角色：定义能力和接口，真正干活的实现，以及把两者接起来的声明。模型只认接口，不关心底下是谁在跑。今天跑本地，明天切沙箱，模型侧不用变。这种解耦才是插件化能玩起来的前提，不然所谓插件只是换皮的配置项。

但最狠的不是插件，是能热重载的底座

理解DSH可以分三层。第一层是能直接用的Coding Agent，本地网页界面是快速入口，和自家模型适配度很高。第二层是一切皆插件的构造框架，核心能力都能自定义，包括执行循环。第三层是底层的元框架，让插件真正做到热重载、自由组合，以及彻底的遗忘和删除。

第三层是最容易被低估的。它的插件不好直接类比MCP或技能，更像是把钩子、外部工具、子Agent和内部核心循环统一成了一种插件机制。解决的是动态组合问题：组件能在依赖出现或消失时重组，卸载时撤回副作用。注重可组合性和生态扩展，这让DSH有点像早期的Unix，有了类似操作系统的高潜力上限。

还有个Creator模式值得关注，形式像交互式Agent工厂：允许开发者指导Agent检查当前运行时、试验插件、创作新的Agent预设。虽然还不是自进化系统，但能收集Agent用来学习自进化的数据。官方同时鼓励社区创建分发第三方插件，这个模式可能成为插件生态的创作入口。DSH更长期的目标用户，很可能从面向开发者走向面向Agent：把Harness做成Agent自己可以修改、热重载的对象。一边执行长任务，一边更换支撑自身运行的部件，就像一艘持续航行的忒修斯之船。

四种协作模式，其实你早就见过三种

既然一切皆插件，多Agent协同当然也是插件组合。DSH自带四种预设，不同预设加载的插件不一样。极简模式默认只保留文件编辑和终端工具，没有委派子Agent的工具。另外三种预设默认提供委派相关工具，会话加载哪些插件由配置文件决定。

常见的多Agent协作方式大致四种，也可以混着用。主从委派是一个主Agent拆任务、派活、汇总结果。流水线是任务按阶段传递，上游输出就是下游输入。共享看板是多个Agent读写同一个共享空间，谁有空谁认领。对等通信是多个Agent平等通信，像群聊一样互相点名，没有固定中心。

有意思的是，这几种我在Hermes里早就见过。原生的委派任务就是典型主从，采集加视频学习的工作流算流水线接力，看板拆卡加认领实现是主从与看板的混合。模式是通的，差别在实现层：DSH里这些全是插件组合，换预设就换协作方式。官方的Agent Teams还在实验阶段，四种预设默认都没加载，社区已经有插件实现了相近功能。

最后说说两种路线之争。一家是为当前范式做出最好的Agent产品，目标最有效、最简单，最大化模型能力边界。另一家押注下一个范式，把替换、组合、撤销作为首要假设来设计。好用的框架和可塑的底座，研究的是两个不同的问题：前者问有了好模型该怎么设计架构，后者问架构一直会被模型内化和重写，最重要的是怎么高效地修改替换撤销。要说距离真正的自进化还缺什么，缺的是完整的学习闭环：学习并提出修改的循环，加上评估修改有效性的基准。DSH给的是运行时自我修改的底座，这是第一步，但只是第一步。

判断很简单：选框架先问自己要整机还是积木，要现在好用还是以后好改。