从插件开发看 DeepSeek Harness

　　最近 DeepSeek Harness 开源，代码仓库上那个"Everything is a plugin"的口号被反复提起。很多人第一反应是把它跟各种 agent 的 skill 划等号——不都是给 AI 加点能力吗？可一旦真从开发者的角度去写一个插件，就会很快意识到，这俩根本不是一回事。skill 大多是在一个已经装好的 agent 上面再叠一层专门的提示词和工具约定，属于"给成品加配件"；而 DeepSeek Harness 的插件，是你手里那台机器本身的零件，模型、工具、沙箱、存储、安全策略、上下文管理，乃至驱动整个智能体转起来的那条 agent 循环，全都是插件。官方用了个很直白的公式：Agent = Model + Harness。翻译过来就是，你想要什么样的智能体，不是从别人预装好的配置里挑，而是你自己动手把它拼出来。

　　从插件开发的视角看，这种"一切皆插件"带来的第一个感受，是边界感极其清晰。写一个 dsh 插件，你面对的不再是一坨只能往里塞指令的黑盒，而是一个明确的、可独立加载卸载的单元：它声明自己依赖哪些接口、提供哪些能力、怎么跟模型循环交互、又怎么在沙箱里被调用。底层那个叫 Cordis 的内核，只负责一件事，就是插件的加载和卸载，别的一概不管。这种设计让开发者的心智负担一下子小了很多——你不需要理解整个 agent 的每一行代码，只要按接口规范把属于自己的那个插件写好，它就能干净地插进系统里，也能在不需要的时候被干净地拔掉。想给 Harness 装双"眼睛"，就写一个视觉路由插件；想接进某家新模型，就写一个模型适配器插件。粒度小、职责单，这正是很多 agent 的 skill 机制给不了的。

　　第二个感受是组合的自由度。skill 通常是往上叠，而 dsh 的插件是横着换。你可以把模型层从 DeepSeek 换成 OpenAI、Anthropic、Google、Kimi 这些接近四十家的任意一家；可以把默认的工具循环替换成自己更顺手的实现；连界面这种听起来跟"能力"八竿子打不着的东西，都是一个可以替换的插件。缺什么就装一个，不顺手就换一个，不满意就拔掉。对开发者来说，这意味着你不再是"在别人定的框架里做微调"，而是能真正按自己对一个智能体该长什么样的理解，去重新组织它的每一层。社区的插件目录已经在飞快地长，那些把 Harness 改造成专属工具的插件，本质上就是在用这套积木，拼出别人没拼过的样子。

　　当然，深入进去也会碰到它另一面。自由是要付代价的，“一切皆插件"意味着你最好对这套组装机制本身有一定理解，否则面对满桌子的零件反而会无从下手。跟开箱即用的 agent 比起来，dsh 的初期学习曲线更陡，它更像一块留给有组装能力的开发者的洞洞板，而不是一台按个键就能跑的整机。文档、版本兼容、插件之间的接口约定，这些都是写插件时绕不开的功课。好在它的安装和分发足够轻量，一条 dsh plugin add 指向仓库就能装，内核更新和补丁也能用命令行顺手完成，生态的滚动速度很快，社区里已经有大量现成的插件可以拿来当范本。

　　回过头看，skill 和 dsh 插件之争，本质是两种产品哲学的差异：前者把 agent 当成品，能力是附加的选项；后者把 agent 当原材料，一切皆可组装。DeepSeek 想造的不是又一个编程助手，而是"组装智能体的一种方式”——这句话才是理解它插件体系的关键。对我来说，写一个 dsh 插件最大的吸引力，不是又多了一个能装的功能，而是它第一次让我觉得，一个智能体到底该怎么组织，决定权真正回到了我自己手里。这种把"能力"变成"零件"的思路，也许才是这波 Agent 工具竞争里，最值得琢磨的那一环。