DeepSeek 把 agent harness 开源，表面看是一次工具层面的开放，实际是三层叠加的动作。开源高效的 harness，本身是一种价格杠杆——同一个模型换一层 harness，实际成本能差出七倍。它也把竞争维度从"模型分高不高"挪到了"系统设计强不强"。但最大的野心在第三层：想让这套插件架构变成整个行业默认拿来插东西的地基，而不只是一个好用的工具。这条路能不能走通，不取决于 DeepSeek 自己，取决于有多少人愿意在这层地基上盖房子。
一、先排除两个显眼的猜测
DeepSeek Harness 发布之后，最先冒出来的两种猜测，可能都站不住。
第一种最直接：DeepSeek 也做了一个 Claude Code。但这个说法忽略了它真正在开放的东西。模型适配器、工具注册表、会话日志，甚至 agent loop 本身，在这套架构里全部是插件，谁都能替换。开放的不是一个产品的功能列表，是产品下面那层骨架。而且这层骨架从设计上就没有把自己锁死在 DeepSeek 的模型上，它默认接入的 provider 列表覆盖了 Anthropic、OpenAI、Azure、Bedrock，甚至内置了两个可以直接调用 Claude Code 和 Codex 二进制的 subagent provider。一个想靠抢用户活下去的产品，通常不会主动把入口开给对手的工具。
第二种更隐蔽一点：开源一层能看到用户全部操作轨迹的系统，图的是训练数据。这个猜测目前也缺乏支撑。遥测能力默认关闭，即使主动打开，数据发到哪里由部署方自己决定；本地日志走的是 JSONL 文件或 SQLite，用户通过 Claude、OpenAI 等其他模型跑出来的任务轨迹，不会自动流回 DeepSeek 的服务器。就算调用的是 DeepSeek 自己的 API，它能看到的也只是那一次请求送进去的上下文，不是整套本地记录。把这套架构说成一条免费铺好的数据管道，证据还不够。
排除掉这两种猜测之后，真正值得问的问题变成：一个几乎不限制用什么模型、甚至主动桥接竞品的开源项目，图的到底是什么。
二、效率是价格杠杆
答案的第一层，藏在一个不太起眼的测试里。有机构做过一次横向对比，让同一个 DeepSeek 模型在八个不同的 harness 上跑同一批任务。最便宜的一个开源 harness，每完成一个任务平均花费不到三美分；而某个主流编程 agent，跑同样的任务平均要花将近两毛美元。同一个模型，换一层 harness，实际成本能差出七倍。
这个数字揭示了一件容易被忽略的事：用户实际感知到的成本，从来不是 API 标价单独决定的，是标价乘以完成一个任务需要多少轮调用、多少 token。如果 harness 本身设计得笨重，让模型多绕几圈弯路、多读几遍不必要的上下文，标价再便宜也没用；反过来，如果 harness 足够高效，标价涨一点，用户实际掏的钱也不一定涨。
这给了 DeepSeek 一个价格战之外的杠杆。开源一套高效的 harness，相当于把"用起来便宜"这件事，从"模型标价便宜"这一个维度，拆成了标价和效率两个维度。标价可以按市场情况随时调整，效率这层护城河，一旦 harness 成了大家默认在用的那套骨架，就不容易被绕开。
三、把战场从模型搬到系统
这层杠杆还带来一个更深的变化：竞争的战场本身在挪位置。
过去谈论一家模型公司的竞争力，几乎都是在谈模型本身：参数规模、训练成本、跑分、API 标价。这些指标的好处是直观，谁的数字好看，谁就暂时领先，而且很容易被下一次发布刷新。
但如果同一个模型放进不同 harness，表现能出现肉眼可见的差异，这条评价标准就不够用了。工具怎么设计、上下文怎么组织、什么时候压缩历史、错误怎么恢复，这些原本被归到"工程细节"里的东西，开始变成 agent 最终表现的一部分。模型的分数不再是唯一变量，骨架的设计能力也要算进去。
对 DeepSeek 来说，这条新战线是有利的。就算某一代模型不是分数最高的那个，只要 harness 设计得足够扎实，综合体验依然能打。这不算放弃在模型层面竞争，更像是给自己多开一条不完全依赖模型分数的赢法。
四、真正的赌注：不是工具，是生态位
但如果只停在效率杠杆和多一条赢法这两层，还是低估了这件事的野心。
真正大的赌注在于：DeepSeek 想要的，可能根本不是让自己的 harness 成为"最好用的那个工具"，而是让它成为"大家默认拿来插东西的那层地基"。
这个思路和云计算领域一个老对照很像。早年的云平台，与其说是在卖一个产品，不如说是在定义一套让计算、存储、网络、身份认证可以独立开发、替换、组合的接口标准，不同厂商各自专注自己最擅长的模块，再按标准拼装成完整的平台。DeepSeek Harness 想干的事，结构上是同一件：把 agent 拆成模型适配、工具、沙箱、记忆、编排这些可以独立开发、独立交付的模块，谁做出一个足够好的沙箱插件，就有机会同时进入好几个行业的 agent 系统，不用每个项目从头造一遍轮子。
如果这套插件生态真的立起来，过去藏在每个项目内部、被重复开发很多遍的东西，比如一套通过金融机构安全审查的沙箱、一个成熟的企业记忆模块，会变成可以反复交付的标准品。这时候 DeepSeek 未必需要自己把每一个插件都做到最好，它占住的是"接口由谁定义"这个位置。接口一旦被广泛采用，后来者想绕开都要先过这一层。
这是四点里最难兑现、也最有野心的一条。前三点靠一次发布、一次测试就能验证，这一条不行。生态位不是官方文档里写一句"我们希望成为标准"就能成立的，得靠外部开发者真的愿意往上面堆插件，堆出足够的密度和覆盖面，才算数。
五、这个赌注目前的裂缝
目前看，这块地基还没打稳。
开发者的反馈两极分化得很明显：一派认为底层架构扎实，尤其对做"自进化 agent"方向研究的团队来说，这套设计提供了目前其他方案都没有的骨架；另一派的评价更直接，对大多数日常写代码的开发者来说，这套系统重得没有必要。这两种评价其实不矛盾，只是说明目前它更像一套面向前沿研究的基础设施，离普通开发者的日常工作流还有距离。
更值得留意的是一条安全方面的提醒：插件架构目前没有签名机制，也没有权限清单，装一个插件本质上就是允许它直接跑代码。默认信任，等于默认给了一个还没被验证过的攻击面。这不是一个可以事后修补的小问题，如果生态想要真的做大，涉及金融、医疗这些对合规和安全要求极高的行业，插件的信任机制迟早要补上，补晚了，前面提到的跨行业复用就无从谈起。
这些裂缝不是在否定这步棋的逻辑，是在提醒一件事：生态位这种打法，风险和野心是成正比的。地基打得越大，能塌的地方也越多。
资源该往哪压，一直是 DeepSeek 决策逻辑里的核心问题：要不要做多模态，要不要把资源留给推理和 agent 能力，现在这个问题又多了一层——要不要把 agent 的骨架，做成一个谁都能插、谁都能拿去用的公共接口。
模型层面的输赢，几周内一次跑分就能见分晓。生态位的输赢，要等外部开发者真的把插件堆起来之后，一两年后才看得清楚。现在能做的判断，只是这步棋在逻辑上站不站得住。从目前的架构设计和它主动打开的边界来看，这步棋站得住，但兑现与否，不取决于 DeepSeek 自己，取决于有多少人愿意在这层地基上盖房子。