ARTICLE · 1037420
一切皆插件,没有内核
一个裸模型只有两件事：吃 messages，吐文本。它没有手眼——不能碰文件、跑代码、上网、记住跨轮上下文。要让它干工程活，中间必须垫一层宿主，替它组装提示、执行工具调用、维持会话状态、守安全边界。Claude Code、Codex CLI 都卡在这个位置。
DeepSeek 的说法很直接：Model + Harness = Agent。2026 年 8 月 13 日，DeepSeek Harness（dsh）v0.1 以 MIT 协议开源，同天发布了一份 88 页的配套论文，署名北京大学与 DeepSeek（来源：《DeepSeek Harness (dsh) 架构与实现原理》）。
真正值得看的不是「又有一个 Agent 框架」，而是它把 Harness 这一层选了一种很硬的做法：整层拆成插件，不留内核。
底座只给插槽，不给能力
dsh 的底座是一个叫 Cordis 的元框架，范式叫「时空可组合性」——组件在空间上可组合（运行时插在一起），在时间上也可组合（生命周期、加载顺序、状态演化可预测）。落到工程上是三条规则。
第一条，无特权核心。Cordis 运行时只管插件的加载、卸载、依赖和可逆副作用，像主板一样只提供插槽和规则，自己不承载任何具体能力。模型适配、工具注册、会话持久化、提示装配、文件系统、Shell、沙箱、审批、界面，全部是插件。
第二条，可逆副作用。插件通过 context 注册的服务，在卸载时自动撤销；需要显式清理的资源交给 effect 返回 disposer。换句话说，插件的生命周期是受控的，而不是靠全局注册表里留下的残留。
第三条，契约面而非 import。框架固定一组公开服务槽，插件把服务挂到指定槽上、用时按 key 取，彼此不 import 代码——换掉槽上的 provider，不影响其他插件。这才是「可插可换」真正的落点。
这套东西不是突然冒出来的。它的作者史一凡此前做过 Koishi（QQ 聊天机器人框架，积累四千多个社区插件），2022 年把插件管理内核抽成独立的 Cordis，2023 年写过一篇《可逆的插件系统》，之后进入 DeepSeek。《可逆的插件系统》那句话，几乎就是 dsh 全部设计的伏笔。
连 Agent 循环都是插件，配置是一叠 patch
大多数 Agent 框架会固定几处扩展点，让你在框内做文章。dsh 把整棵树暴露出来。
它的控制脊柱由六个可替换的核心服务构成：会话日志、Agent 注册、循环驱动、工具注册、提示装配、模型适配注册。注意最后那项对立面——core/agent-loop 本身就是一个默认插件，可以用自定义调度逻辑整体替换掉（来源：《DeepSeek Harness (dsh) 架构与实现原理》）。
服务之间靠「能力缝」连接，一个完整的缝由三个角色构成：服务定义、服务提供者、消费者（通常是面向模型的工具）。一个包可以同时扮演多个角色，但三角色齐备才算完整；换掉缝上任何一环，全局生效。
配置模型也不是一份扁平 settings 文件，而是一叠有序的分层 patch：从空根出发，先加载 Profile 声明的 Bundle，再叠 Profile 自己的补丁、Harness home 的补丁、命令行传入的覆盖层。官方提供了一条命令 dsh --profile web --dump-config，把你机器上实际启动的完整配置树打印出来——里面任何一行，都能用一条用户 patch 替换。
这件事的意义比分层本身大。它把「能不能改这个行为」从提交 feature request，变成一次配置编辑。
图注：无特权核心的意思很直白——底板只给插槽和规则，能力全部来自插上去的模块
和 Pi 的分歧：复杂度放在谁身上
拿 dsh 和另一个开源 Agent 项目 Pi 对比，最容易犯的错是把一方说成可扩展、另一方不可扩展。按当前官方仓库，这个说法站不住（来源：《DSH vs Pi：两种不同的 Agent 构建哲学》）。
Pi 的扩展面已经很深：Extension 可以注册或覆盖工具、增加命令和快捷键、拦截模型与工具事件、注册 Provider、定制压缩、实现权限门和远程执行，连 read、bash、edit、write、grep 这类内置工具都能用同名注册覆盖。它的产品哲学反过来写得很清楚——核心不内置 MCP、子 Agent、权限弹窗、Plan Mode、Todo，理由是这些能力有多种实现方式，不该由核心替所有用户决定。
dsh 走的是统一那条路：让模型适配器、工具注册表、Session Log 和 Agent Loop 本身一起进入插件体系，再用 Service、Provider、Event、Effect、Profile、Bundle 组织运行时。
所以两者的差别不是开放与封闭，而是复杂度放在谁身上。Pi 把复杂度交给扩展作者：注册工具、监听事件就能开工，但扩展多了，状态、顺序和语义关系要自己扛。dsh 把复杂度交给框架：生命周期由框架管，代价是开发者得先学会 Cordis、服务注入、Effect、事件模式、Profile、Bundle，并为组件组合建起测试矩阵。
如果团队没有插件治理和组合测试的能力，dsh 的灵活性会先变成复杂度。
还有一件必须提的事：数据口径。开源后各路二手文章给出的 Star 数彼此矛盾，从三万多到二十多万不等，且多是一手推文的转述、没有独立核实。可靠的信息面只有官方 npm 包与 GitHub 组织，其他 registry 上已经出现过仿冒包。看一个新框架的热度，别把未经核实的数字当论据。
图注：六个核心服务里最反直觉的一条是循环驱动——连 Agent 的主循环都可以被整体替换
源势AI观点
对企业来说，dsh 这类框架真正的价值不在技术炫技，而在「换掉一个组件不用改另一个组件」这条工程约束。
我们给客户做智能体落地时，最常被问到的问题是：厂商的模型换了怎么办、工具升级了怎么办、审批策略要按部门分叉怎么办。传统做法是改代码、回归测试、再上线，周期以周计。插件化加分层配置的路子，把这些变成改配置。这是它值得研究的地方。
但反过来，别急着把生产系统搬上去。dsh 才到 v0.1，生态和成熟度都在早期，插件治理、版本兼容、组合测试这些活，最终是使用方自己的责任。选它的前提，是你有工程能力承接这份自由，而不是指望框架替你兜住。
工具越好用，越考验用的人知道自己在组装什么。
参考材料
源势AI · 企业智能化的推动者
最懂企业业务的 AI 全栈服务商
大模型 Token 聚合平台
企业 FDE 与智能体落地
AIGC 影视制作
官网 www.srcflow.cn ｜ 邮箱 contact@srcflow.cn
关注我们 · 获取更多 AI 前沿洞察
推荐阅读