昨天，DeepSeek V4 Pro 正式版发布，DeepSeek 自己的 Agent 产品也终于上线了。
名字没叫 DeepSeek Code，也没叫 DeepSeek Work，而是一个有点工程味的名字——DeepSeek Harness，简称 DSH。
●先理解什么是 Harness
过去我们用 Claude Code、Codex、WorkBuddy，背后其实都跑着一整套的“约束”或者“驾驭”。
模型负责理解和推理，Harness 负责给它喂上下文、工具、Skills、文件系统、沙箱、存储、Agent 循环和任务调度。
这些统称为Harness。
只是这些能力通常都被厂商封装在产品里。
普通用户能调整提示词、知识库、Skill 和 MCP，但具体怎么喂给 AI, 基本看不见，也改不了。
●DeepSeek Harness 最大的不同：一切皆插件
DeepSeek Harness 最大的不同，是把这些东西几乎全拆成了插件。
模型是插件，工具是插件，Skills 是插件，存储、会话、Agent 循环和 UI 也都是插件。
底层的 Cordis 内核只负责插件的加载、卸载和依赖管理。不同插件重新组合，就能拼出不同的 Agent。
所以它现在给出的四种模式，说到底也就是四套预设组合，或者说 4 个 Agent。
-
标准模式适合正常使用。
-
PTC模式让模型通过代码批量调用工具。 -
极简模式用来测模型最基础的
Agent能力。 -
最特别的创造模式，可以检查当前环境、开发插件，再把新能力装回自己身上。
说得直白点，这不是一个固定的 Agent 产品，更像是一套可以随便拆装的 Agent 底座。
DeepSeek 官网上有个公式，我很认同，最近的分享和培训一直在讲。
Agent = Model + Harness
现在，DeepSeek Harness 通过插件去落地了这个公式。
●当别人都在做 Work，DeepSeek 为什么反着来
顺着上面，再聊聊 DeepSeek 的选择。
最近国内几家厂商都在抢 Work 市场。
方向很一致：屏蔽提示词工程、上下文工程等等，让用户开箱即用，尽可能降低门槛。
DeepSeek Harness 却反着来。
它直接把整个 Agent 拆开，摆到开发者面前。
所以，我感觉，DSH 更像是一个：
面向开发者的、可组合、可二开的 Agent 工程化底座。
虽然它现在界面比较糙、开发者术语一堆、普通人不容易看懂，但却足够灵活、可控，也完美地符合我对 DeepSeek 团队的印象。
●“一切皆插件”，可能也是一种生态打法
抛开技术角度，其实“一切皆插件”可能本身也是一种运营打法。
在 DSH 里，所有能力全部都可由插件提供。
这给开发者留了非常大的可操控空间。
有人补视觉能力，有人做自动化，有人接企业内部系统，也有人重新设计文件管理和交互界面。
可操控空间大了之后，玩的人就多了，生态也就起来了，自然也会演化出各种稳定、好用的方案（方案即 Agent），这里面可能就会有 DSCode、DSWork、DSDesign。
也许，真的会繁星满天？
●那现在要不要用
聊了这么多“虚”的，那面对 DSH，我们应该如何选择呢？
我的观点是分人：
如果你是技术人，我建议赶紧研究下。
先跑通标准模式，看它怎么组织插件、会话和运行轨迹。有兴趣，再试着装一个，或者自己写一个小组件。
等接口和生态稳了，它很可能会成为一个值得考虑的二次开发框架，用来落地你自己的 Code Agent 或者行业 Agent。
如果你不是技术人，只是想找个 Agent 干日常工作，标准模式简单体验一下也行，但我暂时不推荐当主力。
毕竟还是开发者预览版，插件、兼容性、稳定性和交互都还得打磨。
现阶段直接用 WorkBuddy、Codex 这类已经封装好的产品，明显更容易上手一些。
另外就是，大家可以持续关注下：灵活组合的 Agent 是否有足够的市场，对应的 DeepSeek 的 Agent 生态之路是否可以搞起来。
