「一切皆插件」之后：Harness 该拆到什么程度

8 月中旬 DeepSeek 开源了 Harness（dsh），MIT 协议，底层由 Cordis 驱动。它最 striking 的设计不是又造了一个能跑的 Agent，而是把模型适配器、工具、Agent 循环、沙箱、UI 甚至会话压缩，都拆成可插拔插件——官方说法是没有「特权内核」。

preview 版当然还在快速迭代，但这个方向对 Harness 工程很有启发：我们到底该把哪些能力做成可替换模块，哪些必须钉死在不变量里？

一、插件化真正解决的是什么

过去很多 Agent 框架把循环、工具注册、模型调用焊在一套代码里。换模型要改 import，换工具要动核心 loop，加一个沙箱后端可能牵一整条链路。结果是：框架越强大，团队越不敢动它。

「一切皆插件」首先解决的是替换成本。模型从 DeepSeek 换到 Kimi，循环从 ReAct 换到 Plan-Execute，沙箱从本地 shell 换到容器——如果这些都在插件边界上，团队可以在不动核心的前提下做 A/B，甚至让不同业务线挂不同组合。

dsh 启动时按 profile 列出的 bundle 顺序挂载，再叠加 profile 级、用户主目录级、命令行 --patch 的补丁。你能用一条命令看到最终跑起来的插件树——这对排查「到底哪层配置生效了」非常关键。

二、但不是所有能力都值得插件化

插件化有代价：边界越多，组合爆炸越快；每一层 patch 都可能 silently override 上一层；权限和审计如果也变成「可选插件」，生产环境就失去了最低安全基线。

我自己的划分标准是：

适合插件化的：模型适配器、具体工具实现、UI 形态、上下文压缩策略、可选的 Agent 循环变体。它们影响「怎么做得更顺」，但不决定「系统是否可信」。

不适合插件化的：权限闸门（什么动作在什么状态下允许）、审计留痕（谁批准了什么副作用）、独立验收（完成是否被另一套规则判定）。这些是 Harness 的不变量——换模型、换工具、换循环，它们仍必须存在且不可被 patch 关掉。

dsh 把 compaction 做成「能力接口 + 默认 provider」，方向是对的：压缩策略可换，但「长上下文必须可管理」这件事不能没有。反例是：如果把「工具调用前校验」也做成可卸载插件，那 patch 一层就能把整个安全壳拿掉。

三、插件边界该怎么画

一个好用的判据：如果去掉这个模块，你还能不能回答「任务是否被正确完成」？

能回答，说明它是能力增强，可以插件化。不能回答，说明它是信任根基，应该进不变量内核或至少是不可禁用的 mandatory bundle。

另一条实践线：看故障时第一反应。插件化过度时，线上挂了你会问「哪个 bundle 把 timeout 改没了」；边界清晰时，你会问「验收为什么通过了但副作用没发生」——后者至少把问题锁在 Harness 不变量上，而不是在配置迷宫里打转。

四、和「大一统 Harness」的关系

「一切皆插件」不等于「没有核心」。Cordis 提供的是组合语义——bundle 顺序、patch 叠加规则、事件拦截点（agent/*、tools/*）。这些是元层，比具体插件更稳定。

团队容易犯的错误是：看到 dsh 火，就把自家 Skill、记忆、网关、评测全拆成插件，却没有定义 mandatory 层。最后 everyone 都能 patch，no one 能 guarantee。更稳的路径是：

1. 先钉死不变量 bundle（权限、审计、验收、超时熔断）
2. 再把模型、工具、循环、UI 开放为可替换插件
3. 用分层 patch 处理 dev / staging / prod 差异，而不是 fork 代码

五、给正在选型的人

如果你在做 Harness 架构决策，不必 rush 到「全插件」。可以先问三个问题：

• 换模型时，我们要改几处代码？
• 关掉任意一个 bundle，权限和验收还在吗？
• 出问题时，能否打印出最终生效的配置树？

dsh v0.1 还在 preview，API 会变，但「可组合 + 有不变量」这个方向值得跟。Harness 的成熟度，最终不看接了多少插件名，而看：在插件任意组合的情况下，系统是否仍能证明自己做对了。

结语

插件化是手段，不是目的。DeepSeek dsh 把 Agent 循环本身都做成可换模块，是在逼我们重新想 Harness 的内核到底是什么。我的答案是：内核不是某个 loop 实现，而是那几条不可被 patch 掉的约束——能刹住、能接上、能验收。其余的一切，都可以是插件。