三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

两种 Harness 哲学:从 DeepSeek Harness 的过度抽象争议,看 OpenClaw.NET 的另一种答案

两种 Harness 哲学:从 DeepSeek Harness 的过度抽象争议,看 OpenClaw.NET 的另一种答案

1

DeepSeek Harness 发布后在开发者社区引发了不小的争议,有资深开发者直言其设计"烂"。但事情可能没有这么简单。本文借一篇深度分析文章的透镜,对比 DeepSeek Harness 与 .NET 生态的 OpenClaw.NET,聊聊 Agent Harness 设计的两条路线。

一、DeepSeek Harness 的设计到底"怪"在哪

DeepSeek Harness 的核心是 Cordis 内核,主张"一切皆插件 + 插件动态装卸"。Agent Loop、Memory 这些性质完全不同的组件,全部被压平为可以随意装载、替换、卸载的插件。

这个设计在应用开发者看来很别扭,原因有三:

  • 它不是 To C 的:普通用户不需要 Claude Code 那样的体验之外还关心插件热插拔。
  • 它不是 To Dev 的:开发者更新插件重启载入即可,根本不需要"卸载插件"这种能力;Skill 动态加载已经满足了大半需求。
  • 它也不是 To B 的:企业交付场景不关心这种运行时动态性。

而且它犯了软件工程史上的经典错误——过度抽象。就像"一切皆文件"在今天看来应该表述为"一切皆 Handle + Trait",磁盘文件和 Socket 不该被当作只是属性略有差别的同类;Agent Loop 和 Memory 也不该被当作同等的插件。历史上追求理论优美的设计,落地时往往要么削足适履,要么对接环节的成本超过了抽象本身的价值。

二、一个出人意料的解读:它是 To LLM 的

公众号"孔某人的低维认知"的一篇文章给出了两个解读角度。

第一是历史路径依赖。 Cordis 作者 Shigma(Yifan Shi)早年做聊天机器人框架 Koishi,动态装卸插件正是其基因,2023 年重构为 Cordis,2024 年进入 DeepSeek-V3 技术报告作者名单。而 Harness 团队负责人崔添翼在 Jane Street 做了九年量化,又创业做过量化公司——量化交易系统恰好也偏爱动态插件架构。两条路径在 DeepSeek 汇合,做出这样的设计并不奇怪。

第二是逆向 RL 推导:这个设计是 To LLM 自己的。 如果目标是让 Agent 在执行或 RL post-train 过程中自主优化自己的 Harness,那么"灵活性、一切皆可被修改、可以被彻底卸载"就突然合理了。需要"卸载插件"这个能力,恰恰是最好的分析切入点——只有模型要亲手改造自己的运行环境时,卸载才是刚需。目前这个功能被标记为 deliberate opt-in,也印证了它偏自用研究场景、顺便开源的定位。

三、OpenClaw.NET:同一个问题,时间轴另一端的答案

OpenClaw.NET 是 .NET 生态的 Agent 运行时与网关(NativeAOT 友好,自托管,兼容 OpenClaw 的 TS/JS 插件与 SKILL.md 生态)。它和 DeepSeek Harness 面对同一个问题——"Agent 与它的 Harness 之间应该是什么关系"——但给出了几乎相反的答案。

1. 动态性:内核原语 vs 边界隔离

Cordis 让动态性渗透整个内核。OpenClaw.NET 则把能力分成四条通道:Core / Optional / Experimental / JIT-only——动态插件(channels、commands、hooks、providers、原生 .NET 插件)被明确划进 JIT-only 通道,核心运行时保持 NativeAOT 友好、静态可裁剪。

这正好规避了对 DeepSeek Harness 的批评:类型信息留在类型层面,不降级为运行时属性。动态性被承认,但被隔离在边界上。

2. Harness 自演化:模型直改 vs 治理流水线

这是两者最深层的分歧:

  • DeepSeek Harness 赌的是模型即将有能力安全地修改自己的 Harness,所以把"可修改性"做成内核原语。
  • OpenClaw.NET 假设模型暂时没这个能力,于是把自演化做成一条"审查优先"的治理流水线
    • Passive Harness Contracts / Evidence Bundles:Agent 的工作计划、证据、风险全程可检查,但不干预默认行为;
    • Plan-Execute-Verify:高风险工具执行的受治理通道;
    • Harness Evolution Proposals:Agent 可以提议改进自己的 Harness 策略、路由、记忆检索、工具治理,但落地要过人审;
    • Harness Regression Suite(openclaw harness test):任何 harness 变更在获得信任之前,先过离线回归测试。

一句话:DeepSeek Harness 是"未来模型能力下 To LLM 的赌注",OpenClaw.NET 是"当前模型能力下 To Dev 的务实形态"。

3. 可检查性:黑盒插件 vs 结构化投影

还有一个常被忽视的差异。Cordis 的插件是可热替换的黑盒单元;而 OpenClaw.NET 的 Shared Harness State(参与方、动作、读写集、假设、验证义务、证据链接、冲突)加上 Codebase Harness Map(仓库的静态结构投影),实际上把 Agent 的工作流投影成了可检查的 DAG 结构——动作与读写集是节点,依赖与验证义务是边。

这很关键:一切治理、回归测试、人机协作的前提都是结构可观察,而不是可热插拔。从这个角度看,"被动可检查"(Passive-first)反而比"内核可替换"更接近 Agent 自演化真正需要的基础设施。

四、结语

DeepSeek Harness 的"怪设计"未必是烂设计——它只是不是为你我设计的,而是为模型自我迭代的未来准备的。OpenClaw.NET 则证明了同一条演化路线可以用另一种方式走:不让模型直接改 Harness,而是让模型提议、留证、过回归、经人审。

两条路线谁对谁错,取决于一个尚未有答案的问题:模型什么时候才配得上修改自己的 Harness?在那一天到来之前,把动态性隔离在边界、把演化关进治理流水线,也许才是对开发者和运维者真正负责任的设计。


本文基于"孔某人的低维认知"《DeepSeek Harness是服务于Agent自主优化Harness的,不是To C/Dev的原创》一文及 OpenClaw.NET 开源仓库整理分析。

← 返回列表