deepseek-harness 的核心思路是把 Agent 运行时做成一个纯插件系统，模型适配、工具注册、会话管理，甚至 Agent 循环本身都是插件，没有什么是特权核心。底层只靠两样东西兜底：
一是可逆的注册机制，插件卸载时资源自动回收；
二是类型化的事件扩展机制。
这两点立住了，系统的底子才能稳。

在这个基础上，有三个设计特别关键：
第一，把能力拆成了铁三角：接口定义、具体实现、消费方（通常是模型工具）。这样一来，文件系统和子进程就能共用一套执行环境。换 Provider 的时候，Bash、PTY、LSP 这些下游会自动跟着切，不用为每个 Provider 单独写一套适配逻辑，可替换是架构上的硬性约束。
第二，事件被划进了三个域，各司其职。Session 事件负责落盘存档；Agent 事件对应运行中的实例，方便观察或拦截；Capability 事件则专门用来挂策略和适配器。改动前先想清楚动的是哪个域，是这套体系的基本要求。
第三，发给模型的内容必须全程可追溯。凡是塞进模型请求的东西，日志里都要能原样还原，还有运行时断言把关。如此一来，fork、resume、replay 这些操作都基于同一份日志，状态不需要额外维护。

组合层的设计也很完整。插件树由 Profile 声明，Bundle 承载配置和代码，Patch 按行覆盖，叠加顺序清清楚楚。装配关系变成了一份看得见、改得动、查得到的显式配置。

当然，代价也很明显：
一是心智负担重：三角色、三类事件、三层组合加上 Patch 语义，缺哪一环都很难正确扩展。
二是缺乏实战检验：目前这些设计还没经过真实场景的打磨，Patch 语义、会话格式都不承诺兼容，还停留在它自己闭环里的自洽。

总的来说，这是一个逻辑自洽、且比多数同类项目做得更彻底的方案。真正把可组合、可替换、可审计当成了硬性指标在执行，但这种彻底带来的复杂度，是要长期背负的。现在更像是一份结构严谨的蓝图，缺的是真实使用场景的验证。