DeepSeek Harness：一个难用的Agent框架，意在争夺运行时
DeepSeek在V4 Pro涨价的同时推出Agent框架Harness，将模型、工具、Skills、工作流、UI拆成可独立替换的模块，并允许接入别家模型。分析认为，其真正目标不是绑定模型调用，而是成为Agent运行时的基础设施，通过生态持续消耗模型、形成新的商业循环。
事件概述
DeepSeek 近期同步发生两件大事：V4 Pro 涨价，以及 Agent 框架 DeepSeek Harness 上线。此前 DeepSeek 靠 V3、R1 等模型确立“顶级模型不一定昂贵”的印象，并以低价、开源、开放 API 扩张。这次转向被解读为从争夺模型调用量，转向争夺调用发生的“运行时环境”。
Harness 的核心设计
Harness 把 Agent 运行所需的模型、工具、Skills、工作流、UI 都拆成可单独替换的部件，插件支持动态加载、卸载和重新组合。底层内核 Cordis 专门管理插件状态，涉及两个技术概念：时间可组合性（插件卸载后能否完整撤销其影响）和空间可组合性（依赖变化后能否自动重接）。Harness 的“创造模式”允许 Agent 在运行中检查环境、发现能力缺口并现场补充。
与 Claude Code、Codex 等把复杂性封装进产品的路线不同，Harness 把封装重新打开，将修改权交给开发者。文章比喻称，苹果的逻辑是替用户承担复杂性，Harness 则是把复杂性模块化后交给使用者。
商业逻辑：不强制绑定自家模型
Harness 没有把用户限制在 DeepSeek 模型上，而是允许自定义模型、协议和 Base URL，理论上可以接入竞争对手模型。文章认为，这说明 DeepSeek 想控制的不是模型本身，而是 Agent 的运行时环境——类似 Windows/Android 的生态逻辑：开发者、插件、Agent 都跑在 Harness 定义的平台上，模型调用自然会发生。V4 Pro 涨价也可以理解为模型从获客工具变成持续产生现金流的“发动机”。
值得关注
Harness 可能刻意没有把普通用户当作第一批用户。它的界面和文档偏工程师导向，评价其成功与否不应只看下载量，而要看是否有开发者围绕它生产插件、Agent，甚至用它搭建新的 Harness。文章认为，这反映出 Agent 可能从“完成品”变成可被不断搭建、修改、组合的开放环境。