插件核心概念与最小实现结构

DeepSeek Harness 的核心扩展机制在于其基于 Cordis 的插件系统。博主指出，插件本质上是一个接收 Context 的函数。它的主要职责包括声明自身依赖的服务、在 Context 上注册新的能力，并在卸载时由框架统一清理资源。这种设计使得模型、会话工具以及 Web 界面都可以沿着这条扩展边界接入 Harness。插件的开发可以从最小的 Hello World 案例开始，其核心仅需三个元素：第一是一个可以被加载的模块入口；第二是 apply 函数，它接收 Context 参数；第三是在 apply 内部注册具体能力。例如，一个简单的 Hello World 插件只需在 Host（后端）注册一个名为 hello 的工具，该工具接收名字作为输入并返回 "Hello" + 名字的字符串。如果插件需要配置，则需额外导出 Config 类型和对应的 Schema。Harness 会利用这些 Schema 校验配置，并在管理界面中展示正确的字段。

“插件本质上是一个接收 Context 的函数，它声明自己依赖哪些服务，在 Context 上注册新的能力，并在卸载时让框架统一清理。”

在这一最小实现中，首次引入了两个关键概念：Host 和 Client。Host 是运行 DeepSeek Harness 的后端进程，负责模型、工具网络连接以及密钥管理；而 Client 则是我们在浏览器中看到的 Harness Web UI，负责组件展示和交互界面。同一个插件可以仅扩展 Host 端能力，也可以同时提供 Host 和 Client 两个入口。在 Hello World 案例中，插件仅在 Host 端注册工具，Web UI 则复用原有的消息界面显示结果。这种分离架构确保了后端逻辑与前端展示的解耦，为更复杂的插件开发奠定了基础。

Host 端代码结构与契约定义

深入 Hello World 插件的项目结构，可以看到源码、示例、测试、文档和包配置分布在根目录。在 src 目录下，代码被细分为 config、connection、protocol、RPC、tools 和 client。开发者无需逐行阅读所有代码，只需关注入口配置、浏览器端逻辑以及核心契约即可把握开发主干。打开 src/index.ts 文件，最关键的部分是几行公开契约（Contract）。其中 name 字段定义了插件的名称；inject 声明了插件对 Config 的依赖，交由 Harness 进行配置校验；apply 函数接收 Context 和已验证的配置对象。对于需要长期存在的连接、RPC 调用以及工具注册，必须将其放入 ctx.effect 中。这样做的目的是确保当插件卸载时，Harness 能够统一释放这些资源，避免内存泄漏或僵尸进程。

“apply接收Context和配置，需要长期存在的连接RPC和工具注册都放进ctx.effect，这样插件卸载时Harness能统一释放它们。”

这些代码行构成了 Host 端插件与框架对接的必须接口。接着查看 config.ts，这里使用 Schema 描述了两种配置分支：stdio 和 Streamable HTTP。Schema 明确区分了哪些字段是必须的，哪些具有默认值，从而规范了插件的配置行为。这种结构化的配置方式不仅便于开发者实现接口和 Schema，也方便使用者只需填写包名、serverName、transport 和 URL 等参数即可创建插件实例。这就是插件的核心价值：将复杂的实现封装成一个配置清晰、可重复使用的扩展能力，使用者无需关心底层细节。

Client 端交互与 MCP Apps 案例背景

Client 端的逻辑位于 client/index.tsx，这是浏览器的入口文件。与 Host 端类似，Client 同样声明了 inject 和 apply，但其注册的是工具结果视图。一个插件包可以同时构建 Host 与 Client 两个入口，各自在自己的运行环境中使用 Context。本期演示选择的案例是 MCP Apps 插件，因为它不仅涉及注册模型工具，还需要同时扩展 Host 和 Web Client，能完整展示一个相对复杂的 Harness 插件形态。传统 MCP（Model Context Protocol）工具通常返回文字、图片资源或结构化数据，而 MCP Apps 允许工具在描述信息中引用一个 UI 资源。Host 端可以将这些 UI 资源预加载到受限的 iframe 中，从而使工具能够在对话上下文中提供表单、图表、游戏或其他交互界面。

“MCP Apps让工具在描述信息中引用一个UI资源，Host可以把它预加载到受限的iframe中，这样工具就能够在对话里提供表单图表游戏或其他交互的界面。”

MCP Apps 的工作流程并不复杂。Host 从工具描述中的 meta.ui.resourceUri 获取界面地址，并从 Server 端拉取 UI 资源。当模型调用工具后，结果被推送给已经加载的界面。该界面还可以通过安全的 postMessage 通道请求资源、调用工具、发送消息或更新模型上下文。这种机制打破了传统文本交互的限制，实现了真正的双向交互式应用集成。博主强调，理解这一流程是开发此类插件的关键前提。

插件实现细节：连接、沙箱与桥接

在具体的 Host 端实现中，插件使用成熟的 MCP SDK 连接 stdio 或 Streamable HTTP Server。它将远端的工具注册为 Harness 的模型工具，并提供受限的资源与调用桥接。在 Client（Web）端，插件在工具结果区域创建沙箱 iframe。为了实现 Host 与 Client 之间的通信，引入了 App Bridge。App Bridge 将界面的请求交回给 Host，确保连接和密钥始终保留在安全的后端环境中。只有允许展示的资源和调用结果才会流向浏览器前端。这种架构设计保证了安全性，防止敏感信息泄露。

“Client也就是Web在工具结果区域创建沙箱iframe，再用App Bridge把界面请求交回给Host。连接和密钥留在Host允许展示的资源和调用结果才会流向浏览器。”

以 VibeFun MCP Server 为例，插件在 Host 端建立连接后，模型可以通过调用远端工具来触发游戏逻辑。当需要展示 2048 游戏时，插件读取对应的 UI 资源（如 HTML/JS/CSS），并通过受限的 iframe 在对话流中渲染出来。用户可以在浏览器中与游戏进行交互，操作指令通过 postMessage 发送给 Host，Host 再转发给 MCP Server。这种“后端控制逻辑与密钥 + 前端渲染交互”的模式，是构建复杂 Harness 插件的标准范式。

本地配置与完整运行流程验证

完成代码开发后，需要将插件部署到本地 Harness。首先通过 DSH Home 指定运行目录，并将插件安装到 Web Profile。在 Cordis patch 配置中声明插件的名称，在本例中填入 VibeFun MCP Server 的连接方式和地址。这样当 Harness 启动时，就会自动加载该插件。配置过程极其简化：开发者负责实现接口和 Schema，使用者只负责填配置。

“最后我们把插件真正配置到本地Harness先通过DSHHome来指定运行目录再把插件安装到WebProfile然后在Cordispatch里声明插件的名称填入VibeFunMCPServer的连接方式和地址。”

启动 Harness Web 界面后，在对话中让模型通过 VibeFun 打开 2048 游戏。此时，模型调用远端的 MCP 工具，插件读取对应的 UI 资源，把一个可以直接交互的 2048 游戏加载到对话里。从安装、配置到实际运行，整个流程闭环验证成功。这一案例不仅展示了插件的安装方式，更证明了 Harness 能够无缝集成第三方 MCP Server 的复杂应用。博主指出，项目代码和配置示例均已放在视频描述中，供读者参考学习。

结论

写 DeepSeek Harness 插件的开发路径可以归纳为：先从最小结构入手，包括模块入口、apply 函数、Context 注册以及可选的 Config Schema。随着能力变复杂，再逐步增加服务依赖、生命周期清理机制和 Client 端入口。MCP Apps 案例的核心意义在于展示了如何将一种新的交互能力（如游戏、表单）做成插件，并配置到 Harness 中运行。它证明了 Harness 不仅是一个模型调用工具，更是一个支持前后端分离、安全沙箱交互的扩展平台。通过 Host 处理逻辑与密钥，Client 负责渲染与用户输入，开发者可以构建出功能丰富且安全的 Web 应用集成方案。