两种 Harness 哲学：从 DeepSeek Harness 的"过度抽象"争议，看 OpenClaw.NET 的另一种答案 - 张善友
内容提要
DeepSeek Harness因“一切皆插件”设计引发争议，但可能面向模型自优化而非开发者。其Cordis内核源于作者历史路径，支持动态装卸，适合RL训练。对比OpenClaw.NET，后者将动态性隔离在JIT通道，保持核心静态，强调可检查的治理结构。两者分歧在于模型何时能自主修改Harness，当前务实设计应隔离动态性并纳入治理流程。
延伸解读
“一切皆插件”为何引发争议
DeepSeek Harness 将 Agent Loop、Memory 等不同性质的组件统一为可动态装卸的插件，在开发者看来是过度抽象。历史上追求理论优美的设计常因对接成本高而失败，但该设计可能并非面向开发者，而是为模型自优化准备的，因此“烂”的评价需结合目标用户重新审视。
动态性隔离：OpenClaw.NET 的务实选择
OpenClaw.NET 将动态插件限制在 JIT-only 通道，核心保持静态可裁剪，避免类型信息降级为运行时属性。这种设计承认动态性的存在，但将其隔离在边界，使核心更稳定、可检查，与 DeepSeek Harness 的“全内核动态”形成鲜明对比，体现了对当前模型能力的务实考量。
可检查性：Agent 治理的关键
OpenClaw.NET 通过 Shared Harness State 和 Codebase Harness Map 将工作流投影为可检查的 DAG，动作与读写集为节点，依赖与验证义务为边。这种“被动可检查”设计优于“内核可替换”，因为治理、回归测试和人机协作都依赖结构可观察，而非热插拔能力。
Q&A
DeepSeek Harness 的设计为什么在开发者社区引发争议？
DeepSeek Harness 采用“一切皆插件 + 插件动态装卸”的设计，将 Agent Loop、Memory 等不同性质的组件都压平为可随意替换的插件，被批评为过度抽象，犯了软件工程经典错误，让应用开发者感到别扭。
DeepSeek Harness 的 Cordis 内核设计有哪些历史渊源？
Cordis 作者 Shigma 早年开发聊天机器人框架 Koishi，动态装卸插件是其基因，2023 年重构为 Cordis；Harness 团队负责人崔添翼在量化领域工作多年，量化交易系统也偏爱动态插件架构。两条路径在 DeepSeek 汇合，影响了设计。
为什么说 DeepSeek Harness 的设计可能是面向模型自优化的？
如果目标是让 Agent 在执行或 RL post-train 过程中自主优化自己的 Harness，那么“一切皆可修改、可卸载”就合理了。卸载插件的能力只有模型要亲手改造运行环境时才是刚需，且该功能被标记为 deliberate opt-in，说明它偏自用研究场景。
OpenClaw.NET 与 DeepSeek Harness 在动态性处理上有何不同？
DeepSeek Harness 让动态性渗透整个内核，而 OpenClaw.NET 将能力分为四条通道，动态插件被明确划进 JIT-only 通道，核心运行时保持 NativeAOT 友好、静态可裁剪，将动态性隔离在边界上。
OpenClaw.NET 如何实现可检查的治理结构？
OpenClaw.NET 通过 Shared Harness State（参与方、动作、读写集、假设、验证义务、证据链接、冲突）和 Codebase Harness Map（仓库静态结构投影），将 Agent 工作流投影成可检查的 DAG 结构，动作与读写集是节点，依赖与验证义务是边，使治理、回归测试和人机协作成为可能。
DeepSeek Harness 和 OpenClaw.NET 的根本分歧是什么？
根本分歧在于模型何时能自主修改 Harness。DeepSeek Harness 押注未来模型能力，允许模型直接修改 Harness；OpenClaw.NET 则面向当前模型能力，让模型提议、留证、过回归、经人审，将动态性隔离并纳入治理流程。
