1. 先搞清楚 DeepSeek Harness 和插件能解决什么实际问题如果你在用 DeepSeek Harness大概率遇到过两个痛点一是官方功能在某些高频场景下不够顺手二是想深度集成到自己的工作流里却发现缺少关键环节。Harness 本身是个强大的 AI 编程辅助工具但工具越强大我们对它的期待就越高。官方版本能满足基础需求但真要把它变成自己开发环境里的一部分总感觉差那么一两个“开关”或者“连接器”。这就是插件的价值所在。它不是要替代官方功能而是填补那些官方暂时没覆盖、但对特定开发者群体又至关重要的缝隙。比如你可能需要更精细地管理对话历史或者想把 Harness 的输出无缝对接到另一个内部工具里。官方没提供不代表需求不存在。自己动手写插件就是把通用工具“私有化定制”成专属生产力的过程。我写的两个插件就是基于这种“补位”思路。它们不涉及底层模型调用也不修改核心推理逻辑而是聚焦在交互流程和数据流转这两个环节让 Harness 用起来更顺信息处理起来更高效。接下来我会先带你看看这两个插件具体做了什么然后拆解从构思到实现的完整路径包括环境准备、代码核心、调试避坑以及最重要的——如何判断一个插件想法值不值得做。2. 动手前的准备环境、权限与思路澄清在开始写任何 Harness 插件之前有几件事必须提前确认这能避免你写到一半发现路走不通。2.1 确认你的 Harness 版本与插件支持情况首先DeepSeek Harness 的插件系统并非完全开源或拥有像 VSCode 那样庞大的公开 API 文档。它的扩展能力可能依赖于特定版本的客户端桌面端或提供了某种程度的脚本注入/配置扩展点。你需要先明确你用的是哪个版本是官方的桌面应用程序还是通过其他方式集成的查看帮助菜单里的“关于”信息。官方是否有插件开发指南去 DeepSeek Harness 的 GitHub 仓库、官方文档或社区论坛搜索 “plugin”、“extension”、“developer” 等关键词。这是最权威的信息源。现有的插件市场如果有里有什么观察dsh插件市场或dsh插件商店里已有的插件能直观了解官方开放了哪些能力。比如是只能修改 UI 主题还是能拦截请求、添加新的侧边栏工具如果找不到明确的开发文档并不意味着不能开发。很多工具的插件生态始于社区的反向工程和需求探索。这时你的开发思路就要从“基于官方 API”转向“基于现有能力的创造性组合与外部工具集成”。2.2 开发环境与工具链假设我们是在一个相对灵活的桌面端环境进行开发典型的准备如下代码编辑器VSCode 或 PyCharm 均可。VSCode 的轻量和插件生态可能更适合快速迭代。核心语言大概率是 JavaScript/TypeScript如果插件涉及 UI或 Python如果插件侧重后端逻辑和集成。根据你对 Harness 客户端技术栈的猜测来选择。从vscode插件和pycharm中文插件这些热词看基于 Electron 或类似框架的桌面端可能性较大JS/TS 是首选。调试工具浏览器开发者工具如果客户端是基于 Web 技术或对应的桌面应用调试器。学会在 Harness 中打开开发者工具通常快捷键是F12或CtrlShiftI是第一步。版本管理使用 Git。为你的插件项目单独建一个仓库。2.3 明确插件边界什么能做什么要谨慎在动手前想清楚你的插件目标是增强体验还是修改核心例如“一键整理对话历史”是增强体验“修改模型推理参数”可能触及核心风险高且可能随版本更新失效。需要网络权限吗如果你的插件需要调用外部 API比如将代码片段同步到你的笔记软件需要考虑网络请求权限和潜在的安全提示。数据存在哪里插件产生的配置、缓存数据放在哪里是本地文件、LocalStorage 还是独立的数据库这关系到数据持久化和迁移。对性能的影响大吗一个实时监控所有输入输出的插件如果代码效率低下会拖慢整个 Harness 的速度。我的原则是第一个插件尽量简单目标明确不碰敏感区域如用户认证 Token、核心模型请求。先实现一个“有用”的最小功能验证整个开发、加载、运行流程是通的。3. 插件一对话历史增强管理器第一个插件源于一个具体痛点Harness 的对话历史列表在长时间使用后变得冗长查找某个特定会话或代码片段需要滚动很久。官方可能提供了搜索但缺少基于标签、项目或自定义状态的管理能力。3.1 功能定义与目标这个插件的核心目标是为 Harness 的对话历史增加轻量级的管理维度。具体功能包括为会话打标签可以为每个对话添加如#bug-fix、#algorithm、#refactor等自定义标签。会话置顶/归档将重要的会话置顶或将已完成的会话归档让活跃会话更突出。基于标签的过滤视图在历史侧边栏提供一个过滤框只显示带有特定标签的会话。会话导出/备份将单个或一批会话以结构化格式如 JSON 或 Markdown导出到本地。为什么先做这个因为它不依赖复杂的后端数据操作集中在客户端风险可控。它直接解决“找东西难”的问题价值感知强。3.2 技术实现路径拆解由于没有官方插件 SDK我们需要采用“注入”的方式。假设 Harness 桌面端是基于 Electron那么其渲染进程通常是一个 Chromium 浏览器。步骤 1探索与侦察打开 Harness调出开发者工具。切换到Elements或Components标签查看历史列表的 DOM 结构。找到会话列表项div的类名或属性。切换到Console尝试用document.querySelector来选取这些元素验证你的选择器是否正确。在Network标签下观察当你点击历史会话时触发了哪些 API 调用或数据加载。这有助于理解数据来源。步骤 2设计数据存储我们不能直接修改 Harness 的内部数据库。稳妥的做法是将插件管理所需的元数据标签、置顶状态存储在独立的地方。方案 A使用localStorage或IndexedDB。以会话的唯一 ID可以从 DOM 属性或数据请求中获取为键存储对应的标签信息。这是最直接的方式。方案 B使用本地文件。通过 Node.js 的fs模块在 Electron 渲染进程中可用读写一个 JSON 配置文件。这种方式更结构化易于备份。这里以方案 A 为例因为它更简单无需处理文件路径权限。步骤 3构建插件脚本创建一个独立的 JS 文件比如conversation-manager.js。核心逻辑包括监听历史列表更新使用MutationObserver监听历史列表容器的 DOM 变化当新会话项出现时为其注入操作按钮如“添加标签”。渲染标签 UI在会话项旁添加一个标签显示区域和编辑按钮。点击按钮可以弹出一个小输入框。数据绑定将输入的标签保存到localStorage并在下次加载时读取、渲染。实现过滤在历史列表上方添加一个输入框根据输入的标签关键词动态显示或隐藏会话项。// 示例非常简化的核心逻辑框架 (function() { // 1. 尝试找到历史列表容器 const historyContainer document.querySelector([data-testidconversation-list]) || document.querySelector(.history-list); if (!historyContainer) { console.warn(Conversation Manager: 未找到历史列表容器插件可能不适用于此版本。); return; } // 2. 创建过滤输入框并插入到页面 const filterInput document.createElement(input); filterInput.placeholder 按标签过滤 (例如: #bug)...; filterInput.style.cssText margin: 10px; padding: 5px; width: calc(100% - 20px); box-sizing: border-box;; historyContainer.parentNode.insertBefore(filterInput, historyContainer); // 3. 使用 MutationObserver 监听列表变化 const observer new MutationObserver((mutations) { // 遍历新增的节点为每个会话项添加管理按钮 // 这里需要根据实际DOM结构编写具体的选择和注入逻辑 // injectManagementButtons(newNodes); }); observer.observe(historyContainer, { childList: true, subtree: true }); // 4. 实现过滤函数 filterInput.addEventListener(input, (e) { const keyword e.target.value.trim().toLowerCase(); // 遍历所有会话项根据 localStorage 中存储的标签进行匹配和显示/隐藏 // filterConversations(keyword); }); console.log(Conversation Manager 插件已加载。); })();步骤 4加载插件如何让 Harness 运行我们的脚本有几种常见方法开发者工具加载最简单将脚本复制到 Console 中执行。但每次重启都要重做。修改客户端启动参数/加载本地文件这需要更深入的研究可能涉及修改客户端代码或配置。注意这可能违反用户协议请谨慎评估仅用于个人学习。一种更安全的方式是将其开发成一个独立的、通过浏览器扩展如 Tampermonkey 用户脚本来运行的脚本前提是 Harness 的 Web 版本支持。3.3 避坑与验证选择器失效Harness 更新 UI 后你的querySelector可能失效。尽量使用>async function sendToWebhook(content, config) { const { serviceName, webhookUrl, apiKey } config; try { const response await fetch(webhookUrl, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey} // 根据目标服务调整 }, body: JSON.stringify({ text: content, source: DeepSeek Harness, timestamp: new Date().toISOString() }) }); if (!response.ok) { throw new Error(HTTP error! status: ${response.status}); } console.log([${serviceName}] 发送成功); // 可以在这里添加一个成功的 toast 提示 } catch (error) { console.error([${serviceName}] 发送失败:, error); // 在这里添加一个错误的 toast 提示 } }步骤 4处理认证错误从热词中看到token exchange failed: token endpoint returned status 403 forbidden这类错误。在你的插件里必须妥善处理认证失败清晰提示捕获 403、401 等错误向用户显示友好的提示如“API 密钥可能已失效或无权访问请检查配置”。重试与降级对于网络波动可以实现简单的重试机制。对于认证失败则应引导用户重新配置。不存储敏感逻辑不要试图在插件内部处理复杂的 OAuth 令牌刷新流程除非该流程非常简单且公开。对于复杂的认证更好的方式是引导用户去目标工具生成一个长期有效的 Token 或 Webhook。4.3 安全与可靠性考量密钥安全向用户明确说明密钥的存储位置和方式。如果可能提供“仅在内存中保留会话”的选项。请求安全确保发送的数据不包含敏感信息除非用户明确知道。对于外部 Webhook使用 HTTPS 端点。错误隔离一个服务的调用失败不应影响整个插件或其他服务。使用try...catch妥善隔离。验证成功配置一个简单的 Webhook 测试站点如 requestbin.com在 Harness 中选中一段文本通过右键菜单发送查看测试站点是否能成功接收到格式化的数据。5. 从想法到可用插件开发流程与心态写插件尤其是为没有完备文档的工具写插件更像是一个探索和工程结合的过程。5.1 标准化你的开发流程需求最小化不要一开始就想做一个全功能套件。就像我这两个插件第一个只做“打标签”和“过滤”第二个只做“发送到单个 Webhook”。先做出一个可用的核心。环境隔离建议为插件开发创建一个独立的 Harness 用户配置文件或测试环境避免影响你日常使用的主环境。迭代开发采用“实现一个功能 - 测试 - 修复”的快速循环。频繁地在开发者工具中测试你的脚本。代码管理即使脚本一开始很小也用 Git 管理起来。写好README.md说明功能、安装方式尽管可能很原始和已知限制。文档化你的发现在代码注释里详细记录你找到的关键 DOM 选择器、事件监听点和数据接口。这对自己后续维护和他人理解都至关重要。5.2 应对变化与维护官方应用会更新你的插件很可能在某个版本后“失效”。你需要有心理准备和应对策略松散耦合尽量让插件逻辑不依赖于非常具体的 DOM 结构或内部类名。可以通过多种选择器组合或者通过更稳定的属性如role、>
1. 先搞清楚 DeepSeek Harness 和插件能解决什么实际问题如果你在用 DeepSeek Harness大概率遇到过两个痛点一是官方功能在某些高频场景下不够顺手二是想深度集成到自己的工作流里却发现缺少关键环节。Harness 本身是个强大的 AI 编程辅助工具但工具越强大我们对它的期待就越高。官方版本能满足基础需求但真要把它变成自己开发环境里的一部分总感觉差那么一两个“开关”或者“连接器”。这就是插件的价值所在。它不是要替代官方功能而是填补那些官方暂时没覆盖、但对特定开发者群体又至关重要的缝隙。比如你可能需要更精细地管理对话历史或者想把 Harness 的输出无缝对接到另一个内部工具里。官方没提供不代表需求不存在。自己动手写插件就是把通用工具“私有化定制”成专属生产力的过程。我写的两个插件就是基于这种“补位”思路。它们不涉及底层模型调用也不修改核心推理逻辑而是聚焦在交互流程和数据流转这两个环节让 Harness 用起来更顺信息处理起来更高效。接下来我会先带你看看这两个插件具体做了什么然后拆解从构思到实现的完整路径包括环境准备、代码核心、调试避坑以及最重要的——如何判断一个插件想法值不值得做。2. 动手前的准备环境、权限与思路澄清在开始写任何 Harness 插件之前有几件事必须提前确认这能避免你写到一半发现路走不通。2.1 确认你的 Harness 版本与插件支持情况首先DeepSeek Harness 的插件系统并非完全开源或拥有像 VSCode 那样庞大的公开 API 文档。它的扩展能力可能依赖于特定版本的客户端桌面端或提供了某种程度的脚本注入/配置扩展点。你需要先明确你用的是哪个版本是官方的桌面应用程序还是通过其他方式集成的查看帮助菜单里的“关于”信息。官方是否有插件开发指南去 DeepSeek Harness 的 GitHub 仓库、官方文档或社区论坛搜索 “plugin”、“extension”、“developer” 等关键词。这是最权威的信息源。现有的插件市场如果有里有什么观察dsh插件市场或dsh插件商店里已有的插件能直观了解官方开放了哪些能力。比如是只能修改 UI 主题还是能拦截请求、添加新的侧边栏工具如果找不到明确的开发文档并不意味着不能开发。很多工具的插件生态始于社区的反向工程和需求探索。这时你的开发思路就要从“基于官方 API”转向“基于现有能力的创造性组合与外部工具集成”。2.2 开发环境与工具链假设我们是在一个相对灵活的桌面端环境进行开发典型的准备如下代码编辑器VSCode 或 PyCharm 均可。VSCode 的轻量和插件生态可能更适合快速迭代。核心语言大概率是 JavaScript/TypeScript如果插件涉及 UI或 Python如果插件侧重后端逻辑和集成。根据你对 Harness 客户端技术栈的猜测来选择。从vscode插件和pycharm中文插件这些热词看基于 Electron 或类似框架的桌面端可能性较大JS/TS 是首选。调试工具浏览器开发者工具如果客户端是基于 Web 技术或对应的桌面应用调试器。学会在 Harness 中打开开发者工具通常快捷键是F12或CtrlShiftI是第一步。版本管理使用 Git。为你的插件项目单独建一个仓库。2.3 明确插件边界什么能做什么要谨慎在动手前想清楚你的插件目标是增强体验还是修改核心例如“一键整理对话历史”是增强体验“修改模型推理参数”可能触及核心风险高且可能随版本更新失效。需要网络权限吗如果你的插件需要调用外部 API比如将代码片段同步到你的笔记软件需要考虑网络请求权限和潜在的安全提示。数据存在哪里插件产生的配置、缓存数据放在哪里是本地文件、LocalStorage 还是独立的数据库这关系到数据持久化和迁移。对性能的影响大吗一个实时监控所有输入输出的插件如果代码效率低下会拖慢整个 Harness 的速度。我的原则是第一个插件尽量简单目标明确不碰敏感区域如用户认证 Token、核心模型请求。先实现一个“有用”的最小功能验证整个开发、加载、运行流程是通的。3. 插件一对话历史增强管理器第一个插件源于一个具体痛点Harness 的对话历史列表在长时间使用后变得冗长查找某个特定会话或代码片段需要滚动很久。官方可能提供了搜索但缺少基于标签、项目或自定义状态的管理能力。3.1 功能定义与目标这个插件的核心目标是为 Harness 的对话历史增加轻量级的管理维度。具体功能包括为会话打标签可以为每个对话添加如#bug-fix、#algorithm、#refactor等自定义标签。会话置顶/归档将重要的会话置顶或将已完成的会话归档让活跃会话更突出。基于标签的过滤视图在历史侧边栏提供一个过滤框只显示带有特定标签的会话。会话导出/备份将单个或一批会话以结构化格式如 JSON 或 Markdown导出到本地。为什么先做这个因为它不依赖复杂的后端数据操作集中在客户端风险可控。它直接解决“找东西难”的问题价值感知强。3.2 技术实现路径拆解由于没有官方插件 SDK我们需要采用“注入”的方式。假设 Harness 桌面端是基于 Electron那么其渲染进程通常是一个 Chromium 浏览器。步骤 1探索与侦察打开 Harness调出开发者工具。切换到Elements或Components标签查看历史列表的 DOM 结构。找到会话列表项div的类名或属性。切换到Console尝试用document.querySelector来选取这些元素验证你的选择器是否正确。在Network标签下观察当你点击历史会话时触发了哪些 API 调用或数据加载。这有助于理解数据来源。步骤 2设计数据存储我们不能直接修改 Harness 的内部数据库。稳妥的做法是将插件管理所需的元数据标签、置顶状态存储在独立的地方。方案 A使用localStorage或IndexedDB。以会话的唯一 ID可以从 DOM 属性或数据请求中获取为键存储对应的标签信息。这是最直接的方式。方案 B使用本地文件。通过 Node.js 的fs模块在 Electron 渲染进程中可用读写一个 JSON 配置文件。这种方式更结构化易于备份。这里以方案 A 为例因为它更简单无需处理文件路径权限。步骤 3构建插件脚本创建一个独立的 JS 文件比如conversation-manager.js。核心逻辑包括监听历史列表更新使用MutationObserver监听历史列表容器的 DOM 变化当新会话项出现时为其注入操作按钮如“添加标签”。渲染标签 UI在会话项旁添加一个标签显示区域和编辑按钮。点击按钮可以弹出一个小输入框。数据绑定将输入的标签保存到localStorage并在下次加载时读取、渲染。实现过滤在历史列表上方添加一个输入框根据输入的标签关键词动态显示或隐藏会话项。// 示例非常简化的核心逻辑框架 (function() { // 1. 尝试找到历史列表容器 const historyContainer document.querySelector([data-testidconversation-list]) || document.querySelector(.history-list); if (!historyContainer) { console.warn(Conversation Manager: 未找到历史列表容器插件可能不适用于此版本。); return; } // 2. 创建过滤输入框并插入到页面 const filterInput document.createElement(input); filterInput.placeholder 按标签过滤 (例如: #bug)...; filterInput.style.cssText margin: 10px; padding: 5px; width: calc(100% - 20px); box-sizing: border-box;; historyContainer.parentNode.insertBefore(filterInput, historyContainer); // 3. 使用 MutationObserver 监听列表变化 const observer new MutationObserver((mutations) { // 遍历新增的节点为每个会话项添加管理按钮 // 这里需要根据实际DOM结构编写具体的选择和注入逻辑 // injectManagementButtons(newNodes); }); observer.observe(historyContainer, { childList: true, subtree: true }); // 4. 实现过滤函数 filterInput.addEventListener(input, (e) { const keyword e.target.value.trim().toLowerCase(); // 遍历所有会话项根据 localStorage 中存储的标签进行匹配和显示/隐藏 // filterConversations(keyword); }); console.log(Conversation Manager 插件已加载。); })();步骤 4加载插件如何让 Harness 运行我们的脚本有几种常见方法开发者工具加载最简单将脚本复制到 Console 中执行。但每次重启都要重做。修改客户端启动参数/加载本地文件这需要更深入的研究可能涉及修改客户端代码或配置。注意这可能违反用户协议请谨慎评估仅用于个人学习。一种更安全的方式是将其开发成一个独立的、通过浏览器扩展如 Tampermonkey 用户脚本来运行的脚本前提是 Harness 的 Web 版本支持。3.3 避坑与验证选择器失效Harness 更新 UI 后你的querySelector可能失效。尽量使用>async function sendToWebhook(content, config) { const { serviceName, webhookUrl, apiKey } config; try { const response await fetch(webhookUrl, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${apiKey} // 根据目标服务调整 }, body: JSON.stringify({ text: content, source: DeepSeek Harness, timestamp: new Date().toISOString() }) }); if (!response.ok) { throw new Error(HTTP error! status: ${response.status}); } console.log([${serviceName}] 发送成功); // 可以在这里添加一个成功的 toast 提示 } catch (error) { console.error([${serviceName}] 发送失败:, error); // 在这里添加一个错误的 toast 提示 } }步骤 4处理认证错误从热词中看到token exchange failed: token endpoint returned status 403 forbidden这类错误。在你的插件里必须妥善处理认证失败清晰提示捕获 403、401 等错误向用户显示友好的提示如“API 密钥可能已失效或无权访问请检查配置”。重试与降级对于网络波动可以实现简单的重试机制。对于认证失败则应引导用户重新配置。不存储敏感逻辑不要试图在插件内部处理复杂的 OAuth 令牌刷新流程除非该流程非常简单且公开。对于复杂的认证更好的方式是引导用户去目标工具生成一个长期有效的 Token 或 Webhook。4.3 安全与可靠性考量密钥安全向用户明确说明密钥的存储位置和方式。如果可能提供“仅在内存中保留会话”的选项。请求安全确保发送的数据不包含敏感信息除非用户明确知道。对于外部 Webhook使用 HTTPS 端点。错误隔离一个服务的调用失败不应影响整个插件或其他服务。使用try...catch妥善隔离。验证成功配置一个简单的 Webhook 测试站点如 requestbin.com在 Harness 中选中一段文本通过右键菜单发送查看测试站点是否能成功接收到格式化的数据。5. 从想法到可用插件开发流程与心态写插件尤其是为没有完备文档的工具写插件更像是一个探索和工程结合的过程。5.1 标准化你的开发流程需求最小化不要一开始就想做一个全功能套件。就像我这两个插件第一个只做“打标签”和“过滤”第二个只做“发送到单个 Webhook”。先做出一个可用的核心。环境隔离建议为插件开发创建一个独立的 Harness 用户配置文件或测试环境避免影响你日常使用的主环境。迭代开发采用“实现一个功能 - 测试 - 修复”的快速循环。频繁地在开发者工具中测试你的脚本。代码管理即使脚本一开始很小也用 Git 管理起来。写好README.md说明功能、安装方式尽管可能很原始和已知限制。文档化你的发现在代码注释里详细记录你找到的关键 DOM 选择器、事件监听点和数据接口。这对自己后续维护和他人理解都至关重要。5.2 应对变化与维护官方应用会更新你的插件很可能在某个版本后“失效”。你需要有心理准备和应对策略松散耦合尽量让插件逻辑不依赖于非常具体的 DOM 结构或内部类名。可以通过多种选择器组合或者通过更稳定的属性如role、>
![洛谷 P7912：[CSP-J 2021 T4] 小熊的果篮 ← 双向链表](http://pic.xiahunao.cn/yaotu/洛谷 P7912：[CSP-J 2021 T4] 小熊的果篮 ← 双向链表)
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
