一个可拆装的智能体框架！帮你快速了解DeepSeek Harness

一、全文速览图

二、从一个开源项目说起

8 月 14 日，DeepSeek 开源了 DeepSeek Harness。官方给它的定位很简洁：智能体的外层运行框架，负责模型之外的一切——记忆、工具、权限、执行环境。这样一个"拆得开、装得回"的智能体框架，值得从头看一遍。

三、模型与 Harness：分工从哪里划

理解 Harness，先从一个类比说起：模型是发动机，Harness 是发动机之外的整辆车。推理和决策由模型完成，而把决策安全、稳定地落到真实环境里——记忆、工具、权限、沙箱，这些是 Harness 的事。

一个具体场景可以说明两者的差距。同样是修一个登录 Bug，放在粗糙的 Harness 里，模型可能只会反复调命令行，在一大段输出里大海捞针；换到一个精心设计的 Harness，它会先搜索、定位文件，精准读取后做出修改，运行测试，再把失败信息带回下一轮决策，如此循环直到验证通过。模型没变，结果天差地别。

同一个模型、同一个 Bug，两条完全不同的收敛曲线

模型决定能力上限，Harness 决定这上限能兑现几成。

数字也能佐证这一点。官方公布的模型跑分，正是用自家 Harness 跑出来的。由于运行时与模型同源，聊天记录中不变的部分无需重算，缓存命中率可以超过 98%——会话越长，命中率越高，长期使用的成本随之显著下降。

四、"一切皆插件"，彻底到什么程度

插件化在智能体领域早已是共识：今天搭的脚手架，明天模型一变强可能就得拆，所以用插件来组织扩展能力，几乎是默认选项。DeepSeek Harness 的不同在于，它把这件事做得更加彻底。

彻底到什么程度？不止工具、技能、界面是插件，连智能体"想一步、做一步"的那个主循环本身，也是一个插件，作为可替换的实现注册在系统里。在大多数框架中，主循环是内核，外部最多只能在它固定的节点前后挂钩子；而在 Harness 里，主循环和任何其他模块处在同一层级，随时可以被替换。

外面两层全部可替换，主循环就住在中间那一层

一组数字更直观：整个内核约 2,700 行，其余 10 几万行代码——界面、会话记录、循环本身——全部以插件形式存在，不可动的部分，只占约 2%。这带来的直接效果是热插拔：能力可以在运行中增删替换，无需停机。内测中"有人把核心循环整个拆下来换成自己写的"，并非宣传话术，而是这套设计自然产生的结果。

五、为什么拆得干净：Cordis 与那篇论文

热插拔说起来简单，真正的难点在于"拆了不留残留"。要讲清楚这一点，得从 Harness 内核 Cordis 的来历讲起。

2019 年，开发者 Shigma 想给自己写一个聊天机器人，结果发现插件一多就相互冲突，卸载一个还得重启进程。为了解决这个问题，他写了一套插件引擎，取名 Cordis——拉丁语里"心脏"的意思。多年后，智能体在运行中需要动态地装组件、卸组件，碰上了同一道题。DeepSeek 没有另起炉灶，而是把这颗内核直接引入了自己的仓库。

它的核心机制可以这样理解：插件每做一次改动，都必须同时提供一份"如何撤销"的说明；卸载时，系统把这些说明按注册顺序的反序逐一执行——最后装上的最先拆掉。之所以必须逆序，是因为后面的改动往往依赖前面建立的资源，只有先拆掉后建的，才能安全地拆掉先建的，就像拆一件组装家具，最后装上去的零件要最先卸下来。与此配套的，是依赖的自动联动：某项能力出现时，依赖它的组件自动启用；能力被移除时，相关组件自动停用并撤销关联。

像拆家具：最后装上的零件，必须最先卸下来

这套思想被整理进了论文《A Programming Paradigm for Spatiotemporal Composability》（北京大学与 DeepSeek 合作，2026 年 8 月预印本），概括为两个维度——时间可组合性与空间可组合性：前者回答"改过的东西能不能撤干净"，后者回答"依赖变了，系统能不能自己重新连起来"。

"撤销"的用处不止于卸载。插件初始化中途出错时，已完成的改动会按相反顺序自动退回，不会留下半初始化的残留；热更新时若新代码加载失败，框架会整体回退到上一个可用版本，不会卡在半加载状态。这正是"装坏了能回滚"的底层保障。

论文也坦诚地指出了局限：框架保证"改动被追踪、撤销被有序执行"，但撤销逻辑本身写得对不对，仍取决于插件作者；而对系统边界之外的事，比如已经发出去的消息，谁也回滚不了。

六、Skills：存在感最低，却决定可靠性

要看这套设计的产品化程度，可以挑一个具体子系统来展开：Skills，也就是技能。

Skills 借鉴了 Claude Code 的做法：把技能写成一份文档，需要时加载，内容进入会话记录。会话本身就是一份可追溯的记录，技能因此天然支持恢复、回放与审计。这有点像微信的草稿恢复或支付系统的交易流水——平时几乎感觉不到它们的存在，出了故障才知道有多重要。

官方仓库里目前有 14 个项目级 Skill，大致分为四类：

这套机制的完整度，已经足以回答一些真实的产品问题：能不能自动触发发布流程？用户修改 Skill 之后什么时候生效？Skill 加载途中用户取消了任务怎么办？这些细节平时不显眼，却决定了它能不能真正进入生产环境。

当然也有两点保留。其一，对于只有一个 Agent、使用固定 Skill 的团队来说，Provider、Scope、缓存与动态刷新这整套机制可能超出实际需要，简单扫描目录或许就够了。其二，权限管控目前仍以人工判断为主——能不能访问网络、能不能调用子 Agent、是否限定在特定项目内——这些约束在 Skill 层面尚未得到充分覆盖。

七、四种运行模式

Harness 用四种模式来控制"给模型多少能力、以何种方式提供"。

标准模式是默认形态，功能完整，具备文件编辑、Shell、检索、Skill、计划、目标、子 Agent 与工作流等全套能力。

极简模式只保留持久 Shell 和文本编辑器两项能力，目的是在最少辅助下观察模型的真实水平，常用于建立评测基线。

Code Mode（PTC 模式）针对的是传统工具调用的效率瓶颈。传统方式下，模型每次发出一个工具调用、等待结果、再发下一个，多步任务的上下文成本很高。Code Mode 允许模型把多步操作写成一段程序，一次提交给运行时执行，由运行时分发到各工具并汇总结果，将多次往返压缩为一次。这段代码运行在独立的工作线程中，与主进程隔离，可被强制终止——安全边界是显式划定的。值得一提的是，这一"用代码编排工具调用"的思路并非 DeepSeek 独有，OpenAI 的 Codex 也独立得出了相同判断，只是在隔离方案上走了不同的路。

同样四步操作，从四段断续的往返压成一次连贯执行

创造模式让智能体检查当前运行时里已有哪些插件，尝试不同组合，并生成新的预设。用户说一句"给我一个数据分析 Agent"，它就能自己拼出一套配置。这已经指向了论文中"自进化 Agent"的方向——不过论文明确写道，这是待验证的未来方向，而非已经解决的问题。

八、底座已就绪，缺口还在哪

综合来看，Harness 已经搭好了底座：发现、路由、加载、更新与会话记录这套机制，适合多项目、多 Agent、有团队规范约束的场景。而安全审核、权限管控、版本治理与效果评估，仍需结合具体场景做二次开发。

不同规模的用户，面对的取舍也不同。对只有一个 Agent、用固定 Skill 的团队来说，全套动态机制反而是负担，简单扫描目录就够了。对个人开发者来说，以前要分别搭前端、后端和智能体框架三层，如今三层都是插件，挂进同一个运行时，从想法到原型的距离明显缩短。

此外还有一道现实门槛绕不开：当前仍需安装 Node 环境、在终端里敲命令启动，离"面向普通开发者"还差一步。不过，架构上已经为后续简化这一步预留了空间。

九、一颗种子的长成

Cordis，拉丁语里"心脏"的意思。这颗 2019 年为聊天机器人种下的种子，如今撑起了 DeepSeek Agent 的底座。

去年，R1 把"聪明"打到了平价；今年，Harness 想做的是把"整车"也打到平价。而"失败时可以回滚"，正是让人放心拆、大胆装的前提。

💬 如果智能体能够在运行时为自己装配并替换组件、且失败时可以回滚——你最希望它先补上哪一项能力？

文中示意图为笔者根据公开信息绘制插图为社区创作的 DeepSeek 鲸鱼娘梗图，版权归原作者。