DeepSeek Harness：把“插件化”做成主架构，这个开源仓库有什么不一样
一周拿下 42115 颗星，DeepSeek Harness 走的不是“多一个功能”，而是“一切皆插件”的工程化路线。它改变了什么，又有哪些现实门槛。
适合：需要长期维护AI后端、又希望保持架构灵活性的工程团队。
先说结论
DeepSeek Harness 不是一个新模型，而是一套把模型能力拆开再装回去的工程骨架。它的口号很直白：Everything is a Plugin。一周内 42115 颗星，说明开发者真正关心的，是怎么把AI系统“拆得动、改得快、接得稳”，而不是再加一个会聊天的页面。
真正的问题
大部分团队跑AI项目时，都会卡在同一处：模型、工具、数据、业务逻辑全部搅在一起。换个模型要改业务代码，加个新工具要改主流程，想做 AB 实验又得另搭一套。一旦上游升级，整条链路就要重测。
DeepSeek Harness 想解决的就是这件事。它用 TypeScript 写出一个轻量核心，把“模型调用”“工具接入”“上下文管理”这些动作一律抽象成插件。主框架只负责调度，具体能力交给插件去填。这样一来，谁的代码都不再压在同一个篮子里。
它和传统的“AI中台”思路也不一样。中台往往是“什么都替你做”，结果是个大而全的怪物；Harness 则是“什么都让你自己插”，主框架克制，扩展自由。开发者喜欢它，原因就在这里。
怎么做更省力
这套架构落地的关键，不是“把插件写得多”，而是“主核心保持薄”。
| 模块 | 主核心负责 | 插件负责 |
|---|---|---|
| 调度 | 任务路由、上下文拼装 | 不参与 |
| 模型调用 | 不绑定具体模型 | 接入自家模型或第三方 API |
| 工具接入 | 只暴露注册接口 | 真正实现工具逻辑 |
| 可观测性 | 提供统一埋点 | 输出业务级指标 |
按这张分工表推进，你会发现：替换模型，是换一个插件；接入企业知识库，是再加一个插件；做权限隔离，是在调用链上挂一道插件。主框架本身几乎不动，工程上的改动面被压到最小。
如果你的需求是“从零搭一套AI后端”，AI技能工作台 适合先收藏一批成熟的 GitHub 项目与提示词模板，作为后续插件开发的参考库；如果是把现有脚本整理成可复用的工程方案，则可以先用 Markdown 智能编辑器 把架构与接口规范落成文档，再交给团队照着写。
哪些坑要避开
“一切皆插件”听起来自由，代价也很现实。
第一，插件边界没划清，主核心就会被迫越来越胖。建议一开始就把“调度”和“能力”分干净，宁可插件啰嗦一点，也别让主框架知道业务细节。
第二，TypeScript 类型是双刃剑。插件之间靠接口约束，接口一旦设计粗糙，后续联调就会很痛。先把核心 TS 类型定义写完整，再谈扩展。
第三，仓库用了 cordis、dsh、dsh-plugin 这套标签体系，说明它本身依赖一个事件驱动的容器。如果你的团队不熟悉这类 IoC 框架，上手成本会比想象中高一截，最好先花半天读源码再动手改造。
第四，插件多到一定规模时，调试链路会变长。日志、链路追踪、错误隔离这三件事，必须在第一个插件落地时就做掉，不要等到第十个再补。
现在就能动手
不需要等所有需求想清楚再开始，按这三步走就够用。
第一步，用本地 Node 环境把仓库跑通，跑通默认插件链路，确认 cordis 容器和插件注册的基本节奏。这一步的目的不是交付，是建立对“主框架到底有多薄”的直观感受。
第二步，挑一个最小业务场景，比如“调用模型 + 调用一个搜索工具”，拆成两个独立插件，先实现再说结构对不对。重点观察主框架在这一过程中到底有没有被动到。
第三步，把团队现有的AI调用代码按“调度/能力”重新归类，能塞进插件的塞进插件，不能塞进的标记出来。这些标记点，就是后续真正值得重写的部分。
做AI工程的人，多数时间其实不在写模型代码，而在维护“谁调用谁、谁依赖谁”。DeepSeek Harness 真正的价值，是把这件事压回到一个可控范围里。一周 42115 颗星，是开发者对这种克制的一种集体投票。