DeepSeek 最近的两个动作，被外界放到了一起审视：一是 V4 Pro 涨价，二是智能体框架 DeepSeek Harness 上线。按照原文作者的观察，这两个看似分开的发布，可能都指向同一个问题——DeepSeek 下一步要争的，已经不只是模型本身。
在过去一段时间里，DeepSeek 最鲜明的标签，是把复杂能力做得更便宜。V3、R1 之后，行业对它的印象相对一致：模型性能强，但价格并不高。原文提到，DeepSeek 过去的路径很清楚，先把模型做强，再把价格压低，然后通过开源把能力继续往外扩展，从模型权重到 API，再到开发者生态，逐步放大使用范围。
但到了 V4 Pro，这条路径开始出现变化。模型继续升级，价格却没有继续下探。单独看涨价本身，并不一定特殊；真正值得留意的是，V4 Pro 与 Harness 几乎同时出现。原文据此判断，DeepSeek 可能开始从争取更多模型调用，转向争取调用发生在什么环境里。
从模型竞争转向运行环境竞争
原文认为，模型要真正产生价值，还要经过一层运行环境，包括调工具、读文件、管理权限和执行任务。过去，这一层往往被封装在具体产品内部，用户甚至不会察觉它的存在。Harness 则是 DeepSeek 第一次把这层能力单独拿出来展示。
按这一思路，V4 Pro 与 Harness 像是两个方向同时推进：前者让模型重新回到更清晰的商业核算中，后者则把触角伸向模型之外的基础设施。文章将这种变化概括为，DeepSeek 过去争的是模型调用量，现在开始争调用发生的位置，而这已经是两种不同的竞争。
Harness 把 Agent 拆成可替换部件
为了说明 Harness 的特点，原文拿苹果的产品哲学作对照。苹果更强调由产品承担复杂性，用户不需要理解 CPU 调度、内存管理或文件系统，只需要直接使用设备。类似的逻辑也被带进了 Agent 产品。原文提到，Claude Code、Codex、WorkBuddy 都把 Agent 运行所需的工具、Skills、沙箱、权限和工作流封装起来，用户只需下达任务，剩下由产品完成。
Harness 的做法与此不同。它不是继续把复杂性藏起来，而是把模型、工具、Skills、工作流、UI 分别拆开，让它们都成为可以单独替换的部件。按照原文描述，连运行中的插件也可以动态加载、卸载和重新组合。
这也是原文认为 Harness 更值得关注的地方：它改变的不是某个单一功能，而是封装边界。传统产品思路是由平台替用户封装复杂性，Harness 则是先把复杂性拆成模块，再把修改权交还给开发者。
原文还提到，这或许也解释了它为什么被命名为 Harness，而不是 DeepSeek Code。前者更强调运行环境，后者更像在描述具体用途。按文中的表达，若把 Agent 拆开看，可以理解为「Agent = 模型 + Harness」：模型负责思考，Harness 负责把思考变成行动，而过去这整层执行机制通常都隐藏在产品后面。
Cordis 指向运行中可变的 Agent
如果只把 Harness 看作一个 Agent 产品，原文认为它甚至显得有些反常，因为一家模型公司主动允许用户使用其他模型，并不符合常见路径。文章把解释落到了其插件系统背后的 Cordis 上。
Cordis 被描述为 Harness 底层的内核，负责插件安装、卸载以及它们之间的配合。原文特别强调，Cordis 的边界很克制：它不碰模型，不碰工具，也不直接定义具体 Agent 能力，只处理插件如何动态加载、动态卸载、如何被管理，以及在变化过程中如何保持系统稳定。
围绕这一点，原文提到两个技术概念。一个是「时间可组合性」，即插件被卸载之后，此前造成的影响是否能够完整撤销；另一个是「空间可组合性」，即当一个插件依赖另一个插件时，后者如果消失或发生变化，前者能否重新接上依赖关系。
这些表述虽然技术性较强，但原文试图回答的是同一个问题：Agent 在运行过程中，能不能改变自己。传统软件通常不是这样工作的。程序一旦启动，能力大体已经固定；可以升级版本，但不会在任务执行途中临时补上缺失能力。按原文的理解，Cordis 想提供的，正是这种在运行时自我调整的可能。
文章举例称，在 Harness 的创造模式下，Agent 可以检查当前运行环境，发现缺少什么能力后，当场生成、挂载，再继续执行任务。开发者可以把它配置成一个只读代码、不允许修改文件的安全审计 Agent，也可以做成接入内部搜索、固定使用某个模型、并配上三种专属 Skills 的企业研究 Agent。
这与传统 Agent 的区别在于，过去通常需要由人预先完成配置；而 Harness 试图探索的是，人只提出目标，Agent 再去调整自己的运行环境。原文把这比作一台机器在运转过程中发现缺少零部件，然后现场制造并安装。
不锁定自家模型，目标可能是运行时平台
文章接着指出，Harness 在商业上更值得注意的一个细节，是它并没有把用户限制在 DeepSeek 自家的模型上。对于模型公司而言，把 Agent 与自家模型深度绑定，本是更自然的路线。原文列举了 OpenAI、Anthropic 和 Google 的产品逻辑，认为 Agent 常被视作模型触达用户的最后一公里，绑定越紧，理论上自家模型调用就越多。
但 DeepSeek 没有这么做。按照原文说法，Harness 允许开发者自定义模型、协议和 Base URL，也可以接入其他公司的模型。换句话说，理论上用户完全可以在 DeepSeek Harness 中调用竞争对手的模型。
从一个 Agent 产品的角度看，这种选择并不常见；但若从基础设施的角度看，逻辑就变得清楚。原文认为，DeepSeek 真正想掌控的，可能不是模型本身，而是模型之下那层 Agent 运行时环境。
文章把这种位置比作操作系统。Windows 不需要自己开发所有软件，Android 也一样。平台价值并不只在于自己提供多少应用，而在于是否能让更多开发者愿意在其上构建。开发者多，软件会增加；软件多，用户会随之增加，平台本身的分量也会抬升。按照这一判断，Harness 试图复制的是类似逻辑。
V4 Pro 涨价背后，被放进新的生态叙事
在前述框架下，原文也给出了对 V4 Pro 涨价的另一种解释。过去，DeepSeek 依靠低价模型吸引更多用户，更多用户再带来更多调用，进而带来更多开发者和影响力，最终反过来支撑更强的模型。
Harness 出现之后，文章认为一套新的生态循环正在形成。与此前相比，最大的变化是模型的位置变了：它不再只是终点，而更像是一台发动机。过去 DeepSeek 主要依靠低价把用户拉到模型前面；现在，它开始尝试让整个 Agent 生态持续消耗模型能力。
基于这一判断，Harness 不强制绑定 DeepSeek 模型这件事，也就有了新的解释。原文认为，DeepSeek 真正想要的，是让各类 Agent 都运行在它定义的运行时之上。至于底层最终使用哪一家模型，在这个逻辑里反而没那么重要。只要运行时成为生态，模型调用自然会在其中发生。
因此，文章把涨价理解为角色变化后的结果：DeepSeek 不再需要始终扮演价格压制者，模型开始被放进一个能持续产生现金流的位置。
对普通用户不友好，可能恰好说明面向对象不同
原文最后把视角落到产品体验本身。作者直言，第一次打开 DeepSeek Harness 时，并不知道该如何使用：界面偏工程师风格，文档里也充满术语。普通用户面对它，最直接的问题可能是，这个产品究竟是给谁准备的。
文章给出的答案是，DeepSeek 也许根本没有把普通用户设定为第一批目标用户。在这种判断下，早期阶段最重要的不是消费者规模，而是最先进入平台的建设者。原文提到，Windows、Linux、Android 在起步时依靠的也首先是开发者，而不是大众用户。
按这一标准，判断 Harness 是否成功，未必应该先看下载量，而是看插件、看 Agent、看是否有人围绕它持续构建新东西。原文进一步提出，如果未来有人基于 Harness 去搭建自己的 Harness，那才意味着平台真正开始生长。
文章最后认为，现在人们把 Agent 理解为一种产品；但如果未来 Agent 也能像软件一样被不断搭建、修改、组合，甚至由 Agent 自己继续搭建，那么今天的 Agent 形态，也许只是最早的一种形式。
原文在结尾写道，一家公司的野心，有时藏在它发布了什么，也有时藏在它没有替用户做什么。就这篇文章的判断而言，DeepSeek Harness 没有把 Agent 做成一个完成品，而是把一个尚未完成的东西交给开发者。对于一家想做基础设施的公司，这种「未完成」本身，恰恰意味着仍然保留了足够大的空间。