ARTICLE · 1152797
深度解读:开发者把 DSH 插件底座 Cordis 当库复用踩坑;直接用 DSH 的用户问题较少
V2EX 长文盘点 Cordis 的坑与账
10 月 7 日，开发者 riceball 在 V2EX 发表长文，标题为《Cordis 的坑与账-DeepSeek Harness 运行时拿它当底座》，到 10 月 10 日全楼有 9 条回复。他在开篇界定全文的两个关键词：「坑是陷人的地方，账是未来要承担的后果」。
长文盘点的对象 Cordis，是 Koishi（聊天机器人框架）的内核，后来成为 DeepSeek 的 DSH（DeepSeek Harness，智能体运行时）的插件底座。发帖人写道：「类型上是插件元框架：本身不含任何业务能力，只管插件怎么装进一个长期运行的进程、怎么互相依赖、怎么卸载。Koishi 社区插件 4000+，DSH 第三方索引收录 6000+」。DSH 的仓库 deepseek-ai/deepseek-harness 在 10 月 10 日有 246,480 个 star。
关于时间线，他写道：「2020 年 Koishi 先跑起来，Cordis 是后来从它内核剥离出的独立包，论文出现在 DSH 采用之后——工程在前，理论在后」（帖内所指论文编号为 arXiv 2608.25512）。
在 DSH 上做扩展的团队，插件的装卸、依赖与清理机制来自这个底座；把 Cordis 单独当库复用的团队，则要直接面对这个底座的成熟度问题。
机制拆解：一个函数栈负责装卸和清理
按长文的拆解，Cordis 解决四件事：
插件能装进长期运行的进程；
插件能卸载且不留垃圾；
清理不能乱序，后创建的先释放；
插件之间有依赖，依赖失效时下游跟着拆除。
实现是一个函数栈：注册时 acquire 立即执行，返回值和清理函数成对入栈；卸载时从栈顶往下弹出，逆序释放。
顺序为什么不能错，他用定时器和连接池举例：先关闭连接池、后停止定时器，在「池已关、定时器还在」的几毫秒里，定时器可能再触发一次查询，用一个已关闭的连接池执行，必然报错；先停止定时器、再关闭连接池，则不会出错。后进先出的逆序释放恰好符合依赖关系的要求：代码里先定义的资源总是先注册，注册顺序因此就是依赖顺序。
对这层机制，他的评价是「这一步有价值，没有更多了」：把「谁后获取谁先释放」从写在代码里的 try/finally，变成运行时可组合的栈，互相不依赖的插件各自把资源和清理函数压进同一个栈。他同时承认 Cordis 在一些地方做了实在的加固：注册命令、添加监听器、启动定时器这些产生副作用的 API，内部统一使用同一个 effect 原语；只要原语正确，全部 API 的卸载行为自动正确。
复用当库遇到的坑
riceball 的用法与聊天机器人无关：他不直接用 DSH，只想复用 Cordis 构建自己的可扩展应用，计划支持 P2P 和远端/本地自适应插件。他在回帖里写：「本想着敢提一切皆插件，应该是有良好分层的，没想到用起来全是坑」。
长文第 5 节列出五条坑，其中三条与当库复用直接相关。
第一条，没有故障隔离：所有插件运行在同一个 Node.js 进程里，一个插件陷入死循环，整个进程失去响应，插件不能单独部署、单独伸缩。
第二条，没有远程方案：ctx.database 永远是进程内对象，没有传输层抽象，服务不能透明地换成远程实现，这与 P2P、远端/本地自适应的目标直接冲突。
第三条，拦截能否生效取决于别处的派发代码：黑名单插件在监听器里返回 true 表示拦截，框架内部用 emit 派发事件时返回值全部丢弃，机器人照常回复被禁用户；TypeScript 编译通过，运行不报错，单元测试通过，只有端到端行为不对。
DSH 对第三条做了部分修复，官方文档把派发模式列入事件的公共契约；写错派发模式不会被类型检查拦下。
作为对照，长文引入 isdk 组织名下的一组小库：
tool-func 是函数注册表，让函数能自描述、能被其他代码发现；
tool-rpc 把注册的函数暴露到网络上，本地调用和远程调用对使用方透明；
tool-event 把实时事件也当作一个工具。
长文用这组小库展示「同一个需求，另一种长法是什么样子」。发帖人自己写的 web-searcher.js 与 web-fetcher.js 也在同一组织名下；对照方案的一部分出自批评者本人之手，评估这份批评时需要把这一点考虑在内。
回帖里的直接用户
回帖呈现出另一种用法的结果。coefu 从 v0.1.0 开始直接用 DSH，原话是：「我一共就搞了 2 个插件，一个 searxng 联网搜索，一个 hindsight 记忆。除了每次升级要重新 build，我觉得都还好，有时候确实有 bug，但是一想到免费的，还要什么自行车，忍忍也能接受了」。
nextone 在回帖里给出 Cordis 进入 DSH 的社区说法：「cordis 的作者进了 DS 团队，为了这点醋，包的 DSH 这盘饺子」。Cordis 作者加入 DeepSeek 一事未获官方确认。
riceball 随后说明分歧出在用法：「如果你是直接用 dsh，那自然问题少很多。如果你是像我一样，只用它的底层 cordis 作为库，开发自己的可扩展应用……那就是满地坑」。
直接用与复用的判断条件
长文第 8 节给出两张账单。用 Cordis 的账单里，影响决策的有三项：API 无法收回，4000 多个存量插件建立在现行接口上；当前版本 4.0.0-rc.10，API 未冻结，每次 rc 更新要做全量回归；退出成本与停留时长成正比，所有用到 ctx.* 的代码都要重写。自己组合小库的账单里，主要代价是缺少框架层的强制约束，纪律靠代码评审和守卫测试维持，需要嵌套作用域等能力时要自己实现。
DSH 文档站 deepseek-harness.github.io 收录 cordis-primer 与 cordis-tutorial 两份文档。直接用 DSH 写插件，有官方教程和第三方插件索引承接；按照发帖人的澄清，这条路「问题少很多」。按长文的盘点，把 Cordis 单独当库复用、构建自己的可扩展应用，缺少故障隔离与远程能力，目前支撑不了这类用法。需要 P2P、远端/本地自适应这类能力时，长文建议自行组合 tool-func 系列小库作为替代。
主要事实来源为 V2EX 帖《Cordis 的坑与账》（t/1246841，2026 年 10 月 7 日发布，主帖与全部 9 条回复）、Cordis 仓库 cordiverse/cordis、DSH 文档站；正文派发模式公共契约一句已对照文档站 cordis-primer 原文核实。Koishi 4000+ 与 DSH 6000+ 的插件数为发帖人帖内提供的数字，未独立清点；deepseek-harness 的 star 数为 10 月 10 日快照；Cordis 作者加入 DeepSeek 一说来自回帖，未获官方确认；tool-func 系列的作者归属无法从公开信息确认。