就在今晚，DeepSeek 正式发布并开源 DeepSeek Harness（DSH）开发者预览版。
这是一个由 DeepSeek 自己开发的 Agent Harness：它不是新的基础模型或者一个 API 客户端，而是负责把模型接入文件系统、终端、网页、代码工具和其他 Agent，并组织上下文、工具调用和任务执行的一整套 Agent 运行框架。
目前 DeepSeek Harness 已在 GitHub 开源，并可以通过 npm 直接启动。按照官方说明，用户安装Node.js后运行 npx @deepseek-ai/dsh web，即可在本机启动 Web UI。不过官方也特别强调，目前产品仍处于 Developer Preview 阶段，接下来快速迭代过程中可能出现破坏兼容性的修改。
在持续一年多围绕模型性能、开源权重和低价 API 展开竞争之后，DeepSeek 第一次把手伸到了模型输出之后的执行层。或者我们可以换一种更直接的说法：DeepSeek 终于有了一个属于自己的Vibe Coding入口。
这一动作其实早有预兆。7 月 31 日，DeepSeek 发布 V4 Flash 正式版时，就在更新日志中留下了一行容易被忽略的信息：在公开 Code Agent benchmark 中，V4 Flash 使用的测试框架正是“即将发布”的 DeepSeek Harness 极简模式。也就是说，Harness 在正式公开之前，已经开始参与 DeepSeek 对自身模型 Agent 能力的评估。
就在 Harness 发布前，DeepSeek 还完成了另一块拼图。
8 月 13 日早些时候，DeepSeek-V4-Pro 正式版上线 App、Web 和 API，API 对应模型已经更新为 DeepSeek-V4-Pro-0813。V4 Pro 支持 1M Token 上下文、最高 384K Token 输出。官方尤其强调了 Agent 能力提升：Terminal Bench 2.1 得分达到 87.9，DeepSWE 为 62.7，Toolathlon-Verified 为 74.1，DSBench-FullStack 为 71.1。
如果把过去两天的两次更新放在一起看，逻辑就变得清楚了：V4 Pro 提供更强的基础模型能力，Harness 则负责把这种能力真正组织成可以工作的 Agent。
这也是 Harness 最关键的不同。当传统聊天模型收到一个问题，然后返回一段文本；Coding Agent 则需要不断重复“理解任务—寻找文件—修改代码—运行命令—检查结果—继续修改”的循环。这里决定最终效果的已经不只是模型本身，还包括模型拿到了什么工具、系统提示词如何组织、上下文怎样压缩、错误之后是否重试、任务如何拆分，以及什么时候应该调用另一个 Agent。
而 DeepSeek 对 Harness 给出的架构答案是：Everything is a plugin，一切皆插件。
官方文档显示，DSH 建立在Cordis之上，包括模型适配器、工具注册、Session Log，甚至 Agent Loop 本身都被设计成可以替换的插件。模型、文件系统、Shell、网页访问、Skill、子 Agent、存储、安全策略和交互界面，都可以通过配置重新组合。因此，它并不只是“DeepSeek 版 Claude Code”或者“DeepSeek 版 Codex”。
提前参与内测的报道显示，DSH 已经包含项目管理、长任务协作、多 Agent 编排、上下文管理、联网搜索、Skill 等本地 Agent 工作台常见能力；同时可以通过不同 Agent Preset，为同一套系统安装不同的提示词、工具和运行规则。
以官方目前开放的形态来看，DeepSeek Harness 更接近一套运行在用户本地环境里的 Agent 工作台。
它不只给出答案，还可以进入实际工作环境继续行动。比如，用户可以把一个代码项目所在的文件夹交给它，让它先阅读项目结构和文档，再寻找相关代码、修改文件、调用终端运行程序或测试；如果测试报错，它还可以根据错误信息继续定位问题、再次修改，而不是每一步都等用户复制粘贴代码和报错信息。
这些能力主要通过 Web UI 提供，同时还有面向终端用户的TUI、适合脚本和 CI 的 Headless 模式，以及 ACP、JSON-RPC 和 Python SDK 等自动化入口。换句话说，同一套 Harness 既可以做成人直接操作的编程工作台，也可以被接进自动化流程：例如收到一个任务后自动检查代码、执行测试，完成后再返回结果。提前体验资料显示，这些形态共享同一套模型、会话和底层插件，只是通过不同组件组合成不同的产品形态。
它还支持更复杂的长任务和多 Agent 协作。一个主 Agent 可以把工作拆给多个子 Agent，例如让一个负责搜索项目和资料，一个负责修改代码，另一个负责执行测试，再由主 Agent 汇总结果并决定下一步。官方框架同时提供计划、目标、待办事项和后台任务等机制，目的就是让 Agent 不必局限在“一问一答”，而可以持续完成一串彼此关联的操作。
这让 DeepSeek 开始进入 Claude Code、Codex 等产品已经率先展开的竞争。基础模型公司不再满足于提供一个 API，而是进一步争夺模型和真实计算环境之间的执行层。
此前OpenAI 甚至已经直接使用“harness”来描述 Codex 的这部分能力。其今年公开的技术文章将 Codex CLI 定义为本地软件 Agent，并把负责组织模型、工具和用户交互的 Agent Loop 称作 Codex Harness。Codex 桌面端随后又进一步加入多 Agent 并行、Skills、Automations 和 computer use。
这背后还有一个更重要的原因：AI Coding 正在成为观察和训练 Agent 能力最理想的场景之一。
相比写文章、回答问题等开放式任务，代码拥有密集而且相对客观的反馈。程序能不能运行、编译是否成功、测试是否通过、终端返回什么错误，都可以直接被机器验证。因此，一个 Coding Agent 可以不断形成“执行—获得反馈—修改—再次执行”的闭环。比如修复一个 Bug 时，模型修改代码后可以直接运行测试，再根据新的报错继续调整，不止停在“给出一段代码建议”这一步。
这使 Coding 也越来越像基础模型 Agent 能力的实验场。模型是否会规划、能否稳定调用工具、面对错误能否调整策略、能不能完成数十甚至上百步的长任务，都会在真实代码环境中暴露出来。
而 Harness 控制着这个闭环。DeepSeek Harness 的 Session Log 设计要求，凡是模型真正看到的内容都必须能够从日志重建，包括用户消息、模型请求、工具调用、工具结果、上下文压缩和权限变化。其目的首先是让任务能够恢复、回放、调试和审计，但从模型工程角度看，这同样意味着 Agent 的执行过程开始变得可以被系统化记录和分析。
这也是为什么，同一个模型放进不同 Harness，实际表现可能出现明显差异。提前体验 DSH 的媒体曾将同一版本 V4 Flash 放入不同 Agent 框架完成相同任务，结果出现了肉眼可见的差异。当然，单次测试无法证明哪种 Harness 普遍更强，但至少说明，工具、提示词、上下文组织和执行策略已经成为 Agent 最终性能的一部分。
过去谈 DeepSeek，竞争焦点几乎始终落在模型本身：参数规模、训练成本、Benchmark 和 API 价格。但到了 V4 Pro 与 DeepSeek Harness，这条边界正在发生变化。
模型仍然决定智能的上限，但当模型开始真正进入代码库、终端和长期任务后，如何把这种智能接入真实环境，开始成为另一半问题。DeepSeek Harness 的意义也正在这里：它不仅给 DeepSeek 补上了一个 Vibe Coding 产品入口，也让 DeepSeek 第一次拥有了一套自己定义的 Agent 执行框架。
从 V4 Pro 到 Harness，DeepSeek 正在从“造一个更强的模型”，走向“让这个模型真正开始工作”。
1.https://github.com/deepseek-ai/deepseek-harness
2.https://www.npmjs.com/package/@deepseek-ai/dsh
3.https://api-docs.deepseek.com/updates/
注：封面/首图由 AI 辅助生成