https://blog.yvling.cn/tags/deepseek/ Recent content in DeepSeek on 喻灵的博客 Hugo -- 0.145.0 zh Copyright © 2025 yv1ing 桂ICP备2024040959号-1 Fri, 14 Aug 2026 15:55:36 +0000 https://blog.yvling.cn/posts/%E5%8D%9A%E5%AE%A2%E6%96%87%E6%A1%A3/%E6%8A%80%E6%9C%AF%E7%A0%94%E7%A9%B6/2026-08-14-%E5%AF%B9-deepseek-harness-%E7%9A%84%E5%AD%A6%E4%B9%A0%E4%B8%8E%E6%80%9D%E8%80%83/ Fri, 14 Aug 2026 15:55:36 +0000 https://blog.yvling.cn/posts/%E5%8D%9A%E5%AE%A2%E6%96%87%E6%A1%A3/%E6%8A%80%E6%9C%AF%E7%A0%94%E7%A9%B6/2026-08-14-%E5%AF%B9-deepseek-harness-%E7%9A%84%E5%AD%A6%E4%B9%A0%E4%B8%8E%E6%80%9D%E8%80%83/ <p>昨晚睡前看到了 deepseek harness 发布的消息，但是太困直接睡觉了。今早一看已经 60 k+ star，这个涨星速度太夸张了。</p> <p>正好今天周五了，没什么心思上班，于是从它的仓库开始，在我的 agent 帮助下，一点点梳理 deepseek harness 的设计哲学。暂时没有去看它的源码，只想弄明白一件事情：<strong>为什么 Everything is a Plugin？</strong></p> <p>整个 deepseek harness 构建在 Cordis 之上，仓库里的文档说得很明白：</p> <blockquote> <p>它是一个小型运行时，其中的每项能力，包括工具、LLM（大语言模型）适配器、文件访问乃至 agent loop（智能体循环）本身，都是挂载到共享上下文中的插件。</p></blockquote> <h2 id="插件系统的核心问题">插件系统的核心问题</h2> <p>这篇文章想解决的一个核心问题是：</p> <blockquote> <p>一个组件能否在系统运行时被安全地动态加载、替换和卸载；当它所依赖或提供的能力发生变化时，相关组件能否自动、按照正确顺序调整自己的生命周期。</p></blockquote> <p>展开来说，传统软件中的组件、依赖之间的组合大多是静态的，一般通过模块导入、函数调用、类的继承等方式实现。在这些机制下，组件之间的组合关系通常在编译、链接或系统初始化阶段确定，并在后续运行期间保持相对稳定。</p> <p>插件系统和长期运行的服务经常需要在运行时插入、替换和移除组件，文章将这类能力统称为“动态组合”。</p> <p>为了解决上述问题，作者在文章中将其拆分成了两个相互正交但又必须同时成立的维度：</p> <ul> <li><strong>时间可组合性</strong>：组件删除后，它做过的事情能否全部撤销？</li> <li><strong>空间可组合性</strong>：组件依赖谁，依赖变化后谁先启动或退出？</li> </ul> <p>注：时间指的是组件从加载到卸载的整个生命周期；空间指的是组件在依赖图中的位置。</p> <h2 id="effectcoeffect-和-context">Effect、Coeffect 和 Context</h2> <p>再来看文章中提到的两个名词：<code>effect</code> 和 <code>coeffect</code>。</p> <ul> <li><strong>Effect</strong>：程序对外部做了什么？</li> <li><strong>Coeffect</strong>：程序需要外部提供什么？</li> </ul> <p>在此基础上，文章把一个组件定义成以下公式：<code>组件 = 所需依赖 + 提供能力 + 激活时执行的可撤销操作</code>，这里重点关注“可撤销操作”。</p> <p>传统的插件通常这样设计：</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-ts" data-lang="ts"><span style="display:flex;"><span><span style="color:#a6e22e">activate</span>()<span style="color:#f92672">:</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">注册路由</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">注册监听器</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">启动定时器</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">打开连接</span> </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span><span style="color:#a6e22e">deactivate</span>()<span style="color:#f92672">:</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">删除路由</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">删除监听器</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">停止定时器</span> </span></span><span style="display:flex;"><span> <span style="color:#960050;background-color:#1e0010">关闭连接</span> </span></span></code></pre></div><p>开发者需要手动维护一个组件的构造函数和析构函数，在组件数量庞大时，很容易出现构造函数中创建的资源没有在析构函数中进行回收，从而导致资源泄露的问题出现。</p> <p>为了解决这个问题，文章提出了“可撤销操作”的概念。系统运行时会将组件的可撤销操作记录下来，并在组件移除时，按照先进后出的顺序逐项撤销，也就是典型的 <strong>栈式回收</strong>。如此一来，开发者不再需要单独维护一套与激活逻辑分离的组件级卸载流程，而是在创建每个原子 <code>effect</code> 时同时提供对应的 <code>inverse</code>，运行时负责追踪这些 <code>inverse</code>，并自动组合成完整的卸载过程。</p>