夜雨聆风
DeepSeek 在 2026 年 8 月 14 日开源了 DeepSeek Harness（dsh），定位是 Agent 运行时框架。它最值得拆的不是模型能力，而是插件化架构——README 写 "everything is a plugin"，读完源码发现这不是口号，是字面意思：模型适配器、工具注册表、session 持久化、agent loop、sandbox policy 全部作为 Cordis 插件存在，启动时由 profile/bundle/patch 层叠组合出一棵运行时树。
这让我想到另外两个参照物。OpenCode 是当前 AI coding agent 里插件体系做得最认真的开源产品，围绕 server-client 架构做了 in-process 的 transform/hook 层。VS Code 则是上一代编辑器插件体系的天花板，Extension Host 隔离 + contribution points 声明式注册，上万插件共存不崩。三者解决的问题不同，但"插件应该挂在哪一层、暴露多深"这个核心取舍，放在一起看非常有意思。
一、DeepSeek Harness：插件就是运行时本身
核心设计考虑
DeepSeek Harness 要解决的问题是：同一套 Agent 内核，怎么在 Web UI、命令行 headless runner、未来可能的 IDE 嵌入等不同场景下跑起来，且每种场景的安全策略、工具集、模型选择都可以不同。
它的答案是把"场景"本身做成插件组合。不存在一个固定的 App 再往上挂扩展，而是先用 profile 和 bundle 声明这次要组装什么，Cordis 框架按声明合成一棵 service tree，然后 Agent 在这棵树上运行。插件不是附属物，是构成物。
这个思路和 Kubernetes 的 CRD + Operator 模式有点像：平台不预设你要跑什么，而是提供组装机制，让你用声明式配置把需要的能力拼出来。
实现思路
启动时 CLI 先选 profile（比如 web-app 或 headless），然后按 bundle patch → profile patch → home patch → --patch overlay 的顺序层叠合成 Cordis 配置。每个 patch 可以插入、替换或删除 tree 上的 row（一个 row 就是一个插件实例）。base bundle 提供 agent loop、session、tools、LLM adapter 等核心 row；surface bundle（如 web-app 或 headless）决定入口和交互方式。
举个具体例子：dsh --profile headless "run the tests" 启动后，headless bundle 不挂 HTTP server 和 Web UI，只插入一个 headless-runner 插件。这个 runner 创建一个 Agent、把 task 当用户消息送进去、等执行完毕、把结果写到 stdout。它和 Web UI 里的 Agent 用的是同一套 session/turn/step 机制，差别只在 surface 插件不同。
代价
patch 是全量替换 row config 而非 deep merge，局部覆盖需要把保留字段全抄一遍。插件作者要理解 Cordis 的 service 依赖和 scope 机制，门槛不低。这是给平台团队准备的，不适合社区快速写轻量扩展。
二、OpenCode：围绕产品对象做钩子
核心设计考虑
OpenCode 面对的问题不一样。它是一个已经成型的 AI coding agent 产品，有自己的 server、TUI、IDE 集成。插件系统要解决的是：用户和团队怎么在不 fork 代码的前提下，定制 agent 行为、切换模型、保护敏感文件、注入自定义工具。
它的答案是在已有产品对象上提供 transform 和 hook。插件 context 本质上是一个 OpenCode server client——能改什么、能拦什么，取决于 OpenCode 选择暴露哪些产品对象的操作面。底层运行时没有被拆成可重排的 service tree，插件操作的是 agent、model catalog、tool、session 这些产品级概念。
实现思路
插件是一个 TS 文件，export 一个 setup(ctx) 函数。ctx 上有 ctx.agent.transform()、ctx.catalog.transform()、ctx.tool.transform()、ctx.session.hook("context") 这类 API，可以在 agent 创建、模型请求、工具执行等环节做拦截或变换。配置写在 opencode.json(c) 里，也支持从 .opencode/plugins/ 或 npm 包加载，有 ordered entries、disable selector、hot reload、setup 返回 cleanup 这些工程化基础设施。
opencode serve 启动 headless HTTP server，TUI 和 IDE 插件都是这个 server 的 client。插件运行在 server 进程内，拦截的是 server 处理链路上的事件。
代价
V2 API 到现在还标着 beta，entrypoints 和 hook shapes 在 stable 前可能变。插件 context 不暴露私有 Core services，想做更深的替换（比如换掉 session 持久化或 sandbox 机制），目前没有正式路径。
三、VS Code：保护编辑器，不让插件成为内核
核心设计考虑
VS Code 要解决的问题和前两者完全不同。它是一个服务上千万开发者的编辑器，上万插件需要共存。核心诉求是：插件能做很多事，但绝不能拖慢启动、阻塞 UI、破坏编辑器稳定性。
它的答案是 Extension Host 隔离 + 声明式 contribution points。插件跑在独立的 Extension Host 进程里，不能碰 VS Code UI 的 DOM，不能用自定义 CSS 改内部结构。你通过 package.json 声明自己贡献什么（commands、menus、language features、keybindings……），VS Code 按 activation events 懒加载你的运行时代码。
实现思路
插件的 package.json 声明 contributes（贡献点）和 activationEvents（何时激活）。运行时代码通过 main（Node.js）或 browser（WebWorker）入口加载到 Extension Host 中。桌面、远程、Web 场景下可能有多个 extension host，extensionKind 决定插件偏向 workspace 还是 UI。
编辑器给的 API 覆盖 commands、configuration、language features、debugging、webview、terminal、file system、SCM 等维度，够宽但有明确边界。你扩展编辑器的能力，而不是替换编辑器的能力。
代价
如果你想做的不是"扩展编辑器"而是"嵌入一个 Agent 运行时"，VS Code 插件体系帮不了你。OpenCode 的 VS Code 扩展就是一个典型例子——它只做三件事：注册快捷键、启动一个 terminal 跑 opencode、把当前文件/选区信息注入到 opencode TUI。Agent 内核不在 Extension Host 里跑。
四、为什么这么设计：厂商定位决定插件深度
三套插件体系的差异，归根到底是三家公司在产业链里的位置不同。
DeepSeek：模型厂商做 Agent 平台。 DeepSeek 手里有模型，开源 Harness 的目标不是做一个终端产品让用户直接用，而是做一个可组装的 Agent 运行时，让下游（包括自己的产品线）在上面构建不同形态的 Agent 应用。所以它需要插件深入到 runtime 内核——模型适配、安全边界、持久化、审批流都得能换。它不需要讨好社区插件生态，因为目标用户是平台开发者，不是终端用户。这解释了为什么它选了 Cordis 这种"组合一切"的框架，也解释了为什么门槛高得理直气壮。
OpenCode：独立开源产品做用户生态。 OpenCode 是一个面向开发者的终端产品，需要社区围绕它写插件、分享配置、建生态。插件系统的首要目标是上手快、传播容易。一个 TS 文件加几行 JSON 就能跑起来，这才能让社区有动力贡献。同时它又不想把底层完全暴露——暴露了就要承诺稳定性，对一个还在快速迭代的产品是负担。所以它选了"产品对象 transform + 请求路径 hook"这个中间层：够用、够快、改起来不伤筋动骨。
VS Code：大厂编辑器做开发者工作台。 微软需要上万插件稳定共存、需要远程开发和 Web 版兼容、需要一个插件崩了不影响编辑器。这些约束把它推向了最强的隔离和最严格的 API 边界。VS Code 的插件体系不是为了"让你改掉编辑器"，而是为了"让你安全地往编辑器上加东西"。Agent 时代到来后，VS Code 插件自然不适合承载 Agent 内核——但它仍然是把 Agent 产品接进开发者工作流的最好桥梁。
五、我的判断
DeepSeek Harness 的插件化适合"把同一个 Agent 运行时发行成多种形态"的场景——Web、CLI、嵌入式、不同安全等级。它的工程后劲最大，但生态门槛也最高。如果你是平台团队，需要在 Agent runtime 层面做深度定制，这是目前开源方案里走得最远的。
OpenCode 的插件化适合"让用户和团队快速定制 agent 行为"的场景——换模型、拦工具、注入上下文。上手快，传播容易，对社区生态友好。V2 API 稳定之后，有机会成为 AI coding agent 领域的标准插件接口。
VS Code 的插件体系不在同一个坐标系。它管的是开发者工作台，不管 Agent 内核。把 DeepSeek Harness 或 OpenCode 嵌进 VS Code，合理做法是写 VS Code extension 负责快捷键、菜单、终端和上下文注入，Agent 的模型、工具、权限和会话留在自己的 runtime 插件体系里。
三者不是互相取代的关系，而是在不同层各管各的事。
参考资料
•DeepSeek Harness 源码（master）：https://github.com/deepseek-ai/deepseek-harness•OpenCode V2 插件文档：https://opencode.ai/v2/docs/build/plugins；server 文档：https://opencode.ai/docs/server。•VS Code Extension API：https://code.visualstudio.com/api/get-started/extension-anatomy、Extension Host https://code.visualstudio.com/api/advanced-topics/extension-host、Extension Capabilities https://code.visualstudio.com/api/extension-capabilities/overview。