DSH 的插件理念

“一切都是插件”具体指什么

Harness 管的是模型如何工作

模型生成下一步内容，harness 把这一步接到真实环境：准备输入，提供工具，执行调用，保存结果，再决定是否继续。相同模型配上不同的工具、上下文和停止规则，会形成不同的工作方式。DSH 官网用 “Agent = Model + Harness” 表达这组关系，并提供 Standard、Code、Minimal、Creator 等模式。它们分别用于完整编码、代码编排工具、最小环境和创建新预设。官方模式说明

可以把一次资料研究想成一个具体过程：模型要判断该查什么；搜索工具去取网页；记忆组件补充已有资料；记录组件保留引用；审核规则决定哪些结果可交付。读者看到一篇报告，背后有多种职责。插件化让这些职责有独立的替换位置。

开放到了默认运行循环

常见扩展需求是增加一个工具或按钮。DSH 进一步开放了运行循环、工具注册表、会话记录等内部能力。架构文档说明，产品能力通过插件挂入共享上下文，注册动作随插件卸载而撤销。这里仍然存在负责组合的 Cordis 内核，以及插件必须遵守的接口。架构：Cordis 与 Core packages

“同一套接口”也不意味着“所有插件功能相同”。提供文件访问的插件，和消费文件服务的工具插件，职责不同。官方把可替换能力分成接口定义、实现提供者和使用者。替换提供者时，使用者应继续按原来的接口工作。能力关系图

Plugin、Tool、Skill、MCP 各管什么

Skill 可以带脚本，MCP 也能承载丰富的交互；表格只区分主要职责。一个 DSH 插件可以加载 Skill，连接 MCP，再注册工具和界面。OpenViking 的 DSH 集成就把这些能力装在同一个 bundle 中。Agent Skills 标准、MCP 标准、OpenViking

Cordis 为什么能把插件组合起来

依赖有明确名字

插件通过 ctx.tools、ctx.llm 等服务名取得能力，用 inject 声明依赖。所需服务出现后，插件才开始装载；所需服务缺失时，可以处于等待状态。这样开发者可以围绕能力写代码，减少对某个具体实现和人工启动顺序的依赖。Cordis Primer

例如，“报告工具”依赖一个搜索服务。公司后来把公网搜索换成内部搜索，只要保持约定的返回格式与行为，报告工具可以继续使用同一个服务名。这里的兼容条件需要开发者设计和验证，名字相同本身不能证明兼容。

注册和清理放在一起

插件装载时会留下监听器、定时器、连接等资源。DSH 教程要求：框架未自动管理的资源，通过 ctx.effect() 注册，并返回清理函数。卸载时执行清理；子插件也归属父插件的生命周期。生命周期教程

下面是根据官方接口写的教学示例，展示资源所有权；它没有在本次调研中执行。

import type { Context } from '@deepseek-ai/cordis'

export const name = 'research-heartbeat'

export function apply(ctx: Context) {
  ctx.effect(() => {
    const timer = setInterval(() => {
      console.log('research session is alive')
    }, 5000)

    // Release the resource when this plugin unloads.
    return () => clearInterval(timer)
  })
}

其中 5000 是示例自定的毫秒间隔。要点是：申请资源的地方同时交代如何释放资源。作者若绕开框架创建资源，又没有提供清理函数，框架无法替作者补出完整的撤销逻辑。

空间组合与时间组合

Yifan Shi、Wei Zhang、Tianyi Cui 的论文把问题拆成两个方向。空间组合处理组件之间的依赖；时间组合处理组件移除时的影响撤销。论文作者署名中，Shi 和 Cui 有 DeepSeek-AI 归属，Zhang 的归属是北京大学。这是可确认的官方人员研究材料，不能扩展为公司管理层的商业承诺。Cordis 论文，2026-08-26

把两者放进一个例子：搜索服务下线，依赖它的报告插件应停止工作；报告插件卸载，自己添加的监听器也应移除。前者关乎依赖关系，后者关乎资源生命周期。两者都处理好，插件才能反复加入、退出和更换。

配置本身表达产品组合

当前 DSH 使用 profile、bundle 和 patch 组织启动配置。Profile 选择 bundle，后续 patch 可以调整其中的条目。官方启动文档还区分会动态重载的配置与启动时读取的配置；不能把所有应用都理解为可随时无损替换。启动与组合文档

学习配置时，可以先查看实际启动树：

dsh --profile web --dump-config

这条命令来自官方架构文档。它要求已有可运行的 DSH 环境。本页提供的是阅读与实验路径。架构：Profiles and bundles

这个理念好在哪里

下列判断是根据官方机制和开发案例做的工程分析，尚无证据证明它适合所有产品。

把变化限制在较小的范围

假设一个团队需要让助手在公司内部机器上执行代码。如果文件访问、进程执行与上层工具直接绑在一起，改动会一路传到工具和界面。明确服务边界之后，可以把变化集中在执行环境提供者，再用测试检查上层行为是否保留。DSH 的架构文档给出了远程执行环境同时服务 Bash、PTY 和 LSP 的设计。架构：Capability seams

这类价值在需求变化频繁时更明显。替换模型、搜索服务或存储实现，可以变成各自边界上的工程任务。成本仍在，只是更容易定位由谁承担。

官方默认能力也能成为试验对象

工具清单、记忆注入、上下文压缩、任务停止条件，都会影响 agent 的表现。把它们做成独立组件，便于保持其他条件不变，只替换一个机制，检查效果。

例如，研究助手经常漏掉早先找到的反例。可以试验新的记忆检索规则；也可以试验减少压缩。要比较的是来源覆盖率、事实错误和完成成本。插件化提供实验入口，评估负责判断哪个方案值得保留。

小团队可以只负责自己的那部分

dshline 的终端界面复用 Harness 的模型、设置、凭据和授权服务，无须维护独立的模型提供商列表。于是作者可以集中处理终端输出、选择与滚动。dshline：Generic capability integration

创业上的对应关系是：团队可以复用通用运行时，把开发时间花在用户真正需要的工作规则和交付体验上。成立的前提是上游接口足够稳定，而且适配维护成本低于重复开发成本。

系统可以同时容纳不同工作方式

完整编码助手、只有少量工具的测试环境、专门制作新预设的工作台，各有用途。DSH 官网的模式展示说明，这些组合可以共享基础设施。官方模式说明

对产品团队的启发是：把稳定的共享能力留在公共层，把受众差异放进经过验证的组合。给普通用户提供少数明确入口；插件树可以留给开发和运维人员使用。

开发者已经怎样使用它

以下材料来自项目作者的仓库和上游讨论。调研核对了原文与公开结构，没有安装这些插件，也没有复跑作者的测试。仓库存在、文档描述功能，与已经通过企业生产验证，是不同的证据强度。

OpenViking：把记忆接入请求过程

Volcengine 的 OpenViking 仓库提供 DSH 记忆 bundle，包含自动召回、会话捕获、MCP 工具和 Skill。作者遇到一个实际问题：某些预设会覆盖其他系统提示词贡献，导致记忆消失。因此集成在 agent/pre-step 注入带来源的持久消息，让记忆进入会话记录。OpenViking：Design notes

这个插件让团队可以修改“每次工作前给模型什么资料”。对知识产品而言，这比只增加一个等待模型主动调用的搜索按钮更接近持续工作中的记忆需求。是否提高答案质量，仍要用真实问题比较。

Relay Codex：接入另一套会话后端

yangbobo2021/relay-dsh-plugin-codex 把 DSH 会话与 Codex App Server Thread 绑定，接入回答流、工具与审批。作者明确保留 Codex 对模型上下文和压缩的管理；DSH 保存展示记录与持久绑定。文档也说明，历史导入没有持续后台同步，部分输出仍有限制。Relay Codex：What Works 与会话导入

这展示了后端替换能走多深，也说明可组合系统需要明确状态归属。两个产品各自维护会话时，必须决定哪个记录是权威数据，以及中断、重复输入和审批回传如何处理。

dshline：终端界面共享运行能力

riesbri/dshline 通过 Harness 服务读会话、任务和设置。它的连接页面展示已装载适配器提供的模型与登录流程。新增提供者有机会同时出现在不同界面，减少为每个前端重复接入的工作。dshline 仓库

作者明确声明与 DeepSeek 无隶属或背书关系。这里能确认的是第三方实现及其设计，不能据此保证所有 DSH 版本都兼容。

Conversation Exporter：独立交付小功能

liuyuelintop/dsh-conversation-exporter 让用户导出完整对话或选定轮次的 Markdown。作者处理了未闭合代码块、未完成回答等细节，并有意省略工具过程、注入上下文和附件。文档注明 V0.3 面向 DSH 0.1.0-rc.6，后续版本可能需要适配。Exporter：Limitations 与 Compatibility

这类插件适合验证很窄的需求：用户要把对话交给另一套工具继续工作。可读导出有明确用途，完整审计仍应使用保留过程信息的会话记录。

dsh-market：热更新暴露了宿主边界

2026 年 8 月 18 日，维护者 fkysly 在 DSH 讨论区报告：在 0.1.0-rc.7 上，新装插件可以挂载，已加载的插件更新后却仍使用旧的服务端代码。作者追到 HMR 排除 node_modules 的行为，并指出浏览器与服务端版本可能因此不一致。这是指定旧版本上的作者实测报告，本次没有确认当前版本是否仍有该问题。讨论 #3056

当前官方客户端 HMR 文档另有清楚限制：重载会丢失该插件内的 React 状态；会话、工作区与连接状态保留；导入或装载失败不自动回滚。这项限制只指该客户端重载机制。客户端 HMR

有经验的构建者怎样看这些取舍

DeepSeek 研究人员：组合需要有边界

Cordis 论文 §6.1 区分可管理资源与对外发送的影响，§6.3 明确把不可信代码的隔离交给外部沙箱，§6.6 讨论依赖名称与接口版本兼容的缺口。作者给出了组合的形式基础，同时保留这些限制。论文第 70、72、75 页

工程上的对应要求：每个组件都要说明依赖、拥有的资源和退出行为；外部动作另行设计授权、事务与补偿。架构完整性必须在这些具体位置检验。

Mario Zechner：保持模型输入可理解

Pi 作者 Mario Zechner 在 2025 年 11 月 30 日记录了自己构建极简编码 agent 的经历。当时默认工具为 read、write、edit、bash；他尤其重视控制模型看到的上下文、检查会话记录和构建其他界面。他也记录了不同模型 API 在工具调用、取消和用量统计上的兼容工作。Mario 的构建记录

这提供了一个有用的选择标准：只启用能够解释用途的组件，并检查它实际给模型增加了什么。该文章是当时的 Pi 设计记录，早于 DSH，不能当成作者对 DSH 的评价，也不代表今天 Pi 的功能清单。

Harrison Chase：公司要掌握工作规则和改进资料

LangChain 创始人 Harrison Chase 在 2026 年 7 月 25 日主张，公司应掌握决定 AI 行为的模型选择、harness、上下文与记忆，以及成本、质量和风险。他把运行记录、用户反馈和评估视为持续改进的基础，同时支持购买通用基础设施。Harrison Chase 原文

由此可以推演：企业最值得自行控制的插件，往往承载自己的业务规则、数据检索和质量判断。Harrison 的文章没有推荐 DSH；LangChain 本身也销售 agent 基础设施，其观点有明确商业背景。

Anthropic 工程团队：分离后才能独立恢复

Lance Martin、Gabe Cemaj、Michael Cohen 在 2026 年 4 月 8 日介绍 Managed Agents 的经验：早期把会话、harness 和执行环境放在同一容器，会带来故障恢复、调试和客户私有网络接入问题。团队随后把持久会话、运行逻辑和沙箱分离，使各部分能独立恢复或替换。Managed Agents 工程记录

这支持“边界影响恢复能力”的判断。它来自 Anthropic 自己的系统，不能作为 DSH 的可靠性或性能实测。DSH 的插件边界还需要落实为实际的进程、存储与凭据边界，才能获得对应收益。

Anthropic Labs：组件的价值需要任务验证

Prithvi Rajasekaran 在 2026 年 3 月 24 日记录了规划、生成与评估 agent 的实验。他用具体评价标准和阶段验收来检查产出，并通过结构化资料在会话间传递进度。长期应用开发的 Harness 设计

这给插件化补上了使用方法：拆出评估器并不足够，还要定义评估标准。对一个只需简短回答的任务，增加规划和评审可能只增加等待；对复杂应用构建，它们可以承担必要的检查。选择应由任务结果决定。

优势成立的条件与代价

可卸载，不代表业务动作可撤回

卸载邮件插件可以移除它的工具和监听器。已经发出的邮件仍在收件人那里。停止数据库连接，也不会自动撤销已提交的数据。这是系统边界在业务中的直接含义；设计者需要单独安排确认、幂等键和补偿操作。论文 §6.1

可隔离服务，不代表隔离任意代码

Cordis 的 isolate 可以让不同组件组看到不同的同名服务实例，适合给不同会话配置不同提供者。组合教程

对恶意或有缺陷的插件，还需要操作系统、进程或远程环境层面的边界。官方明确提醒，DSH 能执行代码并访问获准的文件、凭据与网络，沙箱和审批不能保证免受损害。官方安全说明

能装载，不代表组合正确

一个服务依赖缺失，插件可以停留在 PENDING 而不报错。稳定的条目 id 也很重要：官方教程说明，没有显式标识的条目在配置重读时可能被当作删除后新增。生命周期让动态组合有规则，调试仍需查看实际运行树和依赖状态。组合与 HMR 教程

插件间也存在行为耦合。例如一个组件裁剪历史，另一个评估器依赖被裁掉的证据，两者单独工作都正常，组合后却得出错误结果。这里需要组合测试、清楚的数据约定和失败样例。

可替换，不代表迁移没有成本

接口之外还有历史数据、配置、Skill、审批状态和用户习惯。更换模型也会遇到消息和工具行为差异，Mario 的 API 适配经历已有直接记录。Mario：Context handoff 与 API 适配

因此，采购或自建时应检查能否导出业务知识与运行记录，能否重跑真实任务，以及替换某个组件后谁负责验收。只看到“支持插件”四个字，无法回答这些问题。

表格是本文的工程判断。插件边界、操作系统安全边界、业务责任边界需要分别设计。

可以应用到什么场景

以下是设计推演，均未实施，也不表示任何公司正在采用 DSH。

社群内容：有范围的研究助手

付费社群或论坛类产品可以组合“授权内容检索、来源记录、主题聚合、报告模板、人工审核”等能力。用户问某个社群最近在讨论什么，助手检索允许访问的内容，按问题聚合观点，再保留原帖出处与不同意见。

优先做只读研究：交付一份有来源的周报草稿。业务检索服务应在服务端限制成员身份、可见范围与删除内容，界面负责呈现来源和审核意见。公开发布可以成为独立动作，由操作者控制。

插件化的价值是让检索、总结规则与审核界面独立调整。验收关注漏掉了哪些重要讨论、引用是否可回查、是否越过访问范围，以及编辑完成一份周报需要多久。

阅读与笔记产品：从阅读到写作

稍后读或笔记类产品可以组合文章抓取、原文定位、知识检索、写作 Skill 与导出界面。读者读一篇文章后，助手找到相关旧笔记，提出关联，并生成保留原文位置的写作草稿。

最小实验可以限定在一个主题的一组文章。分别运行“仅当前资料”和“加入记忆检索”的配置，检查有没有找回有用的旧观点、有没有引用错误。记忆插件要遵守删除与更新规则，避免反复取出用户已放弃的判断。

这里可以借鉴 OpenViking 的介入方式和 Exporter 的小功能范围。用户得到的产品入口应是“找相关笔记”或“生成草稿”，插件组合留在产品内部。

公司内部：按岗位配置助手

客服需要产品知识与工单操作，工程团队需要代码与执行环境，经营分析需要只读数据和指标定义。可以共享会话、观测和身份基础设施，各自维护少数经过测试的能力组合。

平台负责人维护接口、升级和故障处置；业务负责人维护知识、动作范围与验收样例。换模型时，在这些样例上检查结果再切换。DSH 当前阶段适合把这当作隔离的技术验证，生产路线应另行完成可靠性与安全评估。

Harness 研发：比较上下文与循环策略

这是与 DSH 官方定位最接近的用途。用相同模型和任务输入，分别替换记忆召回、工具结果裁剪或继续执行策略，保留日志与配置，观察失败怎样变化。

例如，工程任务经常在测试失败后提前结束，可以评估一个新的继续规则：在明确预算内，根据测试结果决定是否继续。验收既看成功完成，也看多花的成本、无效重复和需要人接手的比例。

垂直产品：交付一套经过验证的组合

招聘研究、客户支持、行业资料整理等场景，都可以把专属知识、工具、流程和结果界面打包。插件是实现与分发方式，商业价值要落在任务结果上。

对小团队更有意义的起点是一个可重复的问题：谁会用、多久用一次、现在怎样解决、产出怎样验收。先用真实任务验证，再决定是否需要开放插件生态。公共插件市场还要承担发现、兼容、恶意包处理和客服，不能用“生态”代替这些具体工作。

不值得优先采用的情况

如果应用只有一个稳定的摘要流程，没有替换运行机制的需求，直接调用模型和少量工具通常更容易管理。若团队需要的是立刻可用的个人编码助手，也应先用现成产品；配置一个底层平台会增加学习负担。

当数据敏感、错误代价高、服务必须稳定运行时，不能把开发者预览状态忽略掉。可以研究其设计，是否采用其当前实现，应由独立验证决定。当前产品阶段与安全限制

怎样把这个理念学到手

从一个受管理的资源开始

建议按官方教程做本地练习：写一个插件、注册监听器或定时器、查看装载状态、卸载后确认资源消失。再添加一个依赖服务，移除提供者，观察消费者的状态变化。官方 Cordis 教程说明，基础例子不需要模型 API Key。Cordis 教程入口

完成后应能回答：插件什么时候运行？它依赖谁？它留下的资源归谁？需要顺序清理的工作应该放在哪里？当前教程指出，异步清理函数可能并发执行，需要严格顺序的清理应放进同一个函数并逐项等待。生命周期教程

用研究任务做一次替换实验

选择一个已经人工完成过的研究问题，保留原材料和可接受答案。固定模型与工具配置，只替换一个记忆或上下文组件。保存任务输入、插件版本、最终配置和完整运行记录。

这些是建议的实验指标，没有预设通过率或节省比例。跑过任务后再决定保留哪种组合。

从产品角度检查边界

当一个客户提出新要求时，先定位变化：只是写作规则变了，还是工具变了？要调整每一步的输入，还是执行地点？需要新的界面，还是新的审批责任？变化发生在哪里，就检查那里是否有独立且稳定的接口。

如果一次小需求必须改动大量互不相关的组件，值得重新检查职责划分。如果每个小函数都成为独立插件，理解依赖的成本又可能超过复用收益。合适的粒度是能够独立配置、验证和承担维护责任的一项能力。

方法与来源

证据范围与未解决的问题

资料访问日为 2026 年 9 月 8 日。由 DeepSeek 官网定位官方仓库与论文，阅读架构、生命周期、组合、执行与重载文档，再核对开发者仓库和创始人原文。

证据按用途处理：官方文档用于说明接口与产品状态；署名论文用于解释设计与边界；作者仓库和讨论用于说明开发经历；商业文章用于理解决策观点。本文提出的应用、优劣判断和实验方法均属于综合推演。

没有使用搜索聚合站的插件数、星标数或“已验证”标签证明生态成熟。没有找到可核验的 DSH 企业长期部署收益；没有采访作者，也没有执行社区插件。个人社交帖子存在访问限制，因此正文采用可读取的官方研究人员署名论文，未把无法直接读取的转述当成官方结论。

GitHub 链接多指向滚动分支，按访问日内容阅读；本文未取得可固定的统一提交快照。旧版问题保留报告日期和版本，不推定为最新版现状。论文已读摘要、引言和与边界相关的章节，未独立审计全部形式证明。

官方与标准

开发者与经营经验