DeepSeek Harness:当 Agent 的一切都能拆成插件

2026 年 8 月 13 日,DeepSeek 打了一套组合拳。
很多人只注意到了当天开源的 DeepSeek Harness(简称 dsh)——一个智能体(Agent,也就是能自己动手干活的 AI)运行时框架。但把最近的时间线摆在一起看,会发现这不是一次孤立的发布:
7 月 31 日,V4-Flash-0731 正式版发布,API 公测、开源权重同步放出;
8 月 12 日至 13 日,V4-Pro-0813 正式 GA,从预览版转为正式版;
8 月 13 日,DeepSeek Harness v0.1 开发者预览版发布。
模型刚刚完成正式版升级,框架紧跟着开源,这两件事是配套的。打个比方:模型是 Agent 的灵魂,Harness 是让灵魂动起来的那副身体——工具、记忆、执行环境、界面,全归它管。DeepSeek 这次不只是升级了灵魂,是连身体一起交了出来。

模型升级还算常规操作,把 Harness 整个开源,就是大多数模型公司不会做的动作了。笔者觉得,这可能是 DeepSeek 今年走得最远的一步棋。为什么这么说?先看一场实验。

一、同一个大脑,换个身体就换个命运

就在 Harness 发布前几天,做 Agent 工具的公司 Composio 搞了一场对比测试:同一款 DeepSeek V4-Flash 模型,分别接进 8 个不同的 Harness,去完成 30 项真实任务。

结果挺扎心。表现最好的 Harness 通过了 20 项,最差的只过了 14 项;每成功完成一次任务的成本,最好和最差之间差了 4 倍。

同样的大脑,同样的考题,就因为身体不一样,成绩天差地别啊。笔者看完这个测试的第一反应是:这两年大家盯着模型跑分较劲,关注点可能并不全面。Agent 能不能落地,瓶颈不只在模型里,也在模型外。

二、Harness 到底是个啥?

Harness 直译过来大概叫“驾驭层”,这个翻译有点玄乎。笔者的理解很朴素:除了模型之外,让 Agent 跑起来的所有东西——工具从哪儿调、对话记在哪儿、命令在什么环境里执行、用户对着什么界面操作,统统归它管。

再说得接地气一点:模型像发动机,Harness 就是整台车剩下的部分——底盘、变速箱、车身、方向盘。光有发动机,你是上不了路的。

以前这副身体各家自己做,各做各的,水平参差不齐。Composio 测出来那个 4 倍的成本差,就是这么来的。

三、一切皆插件,而且是彻头彻尾的那种

把一个 Agent 拆开,里面到底有什么?DeepSeek Harness 给出的答案就五个字:一切皆插件

这个“一切”不是宣传话术。在它里面:

  • 模型适配器是插件
  • 工具注册是插件
  • 会话管理和存储是插件
  • 沙箱(隔离的执行环境)是插件
  • Agent 的决策循环是插件
  • 调度编排是插件
  • 连你看到的那个 Web 界面,也是插件

框架本身就是个近乎空壳的底座,底下垫着一个叫 Cordis 的元框架,只管三件事:装插件、卸插件、管插件之间的依赖。插件和插件之间,靠服务和类型化事件来协作,在配置层自由组合。

这么设计图什么?图的是你可以不动一行源码,就把其中任何一块换掉。想换模型?把模型适配器插件换了。想把执行环境从本机挪到远程沙箱?换掉对应的插件,bash、终端这些工具会跟着一起搬家,不用 fork 一份代码出来改。

官方管这种设计叫“能力接缝”。笔者更愿意拿乐高来比喻:每一块都是标准件,最后拼出什么作品,看的是玩的人。当 Agent 被拆到这个份上,框架本身就“隐身”了——剩下的只有接缝和标准件。

四、内置四种模式,各有各的算盘

针对不同用法,DeepSeek Harness 内置了 4 种模式,每种加载不同的插件组合:

模式定位说人话
标准模式完整编码 Agent文件编辑、Shell、搜索、规划、子 Agent、工作流,全套配齐
Code 模式(PTC)程序化工具调用工具封装成 TypeScript SDK,模型直接写代码,一次编排多轮工具调用
极简模式基准测试只留 bash 和文本编辑器两样工具,环境剥到最干净,测的就是模型裸实力
创造模式自定义模式创作继承标准模式全部能力,外加运行时检查、内存中的插件实验和预设创作指导

笔者单独拎出 Code 模式说两句。传统 Agent 干活是一轮一轮磨:调一次工具,回一次模型,一来一回都是延迟和 token(大模型计费的词元单位)。Code 模式换了个思路——让模型直接生成一段 TypeScript 程序,把好几步工具调用一次性串起来,原本 5 轮交互压缩成 1 轮。

这个思路和笔者一直的看法对得上:Agent 用着贵、用着慢,一大半是“来回跑”跑出来的。

创造模式的野心则更大一些。它不光是给用户用的工具,更是给开发者“发明新工具”用的工具——DeepSeek 想要的显然不止自己下场,还有生态。

五、一分钟上手,社区已经动起来了

上手门槛很低。装好 Node.js,一行命令:

npx @deepseek-ai/dsh web

浏览器打开 http://127.0.0.1:3080 就能用,全程跑在本地,不用内测资格,不用排队等邀请。

想从源码构建也行:

git clone https://github.com/deepseek-ai/deepseek-harness
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

社区的热度也能说明问题。发布几个小时,GitHub 仓库就收了 3.3 万多个 star,到现在已经差不多 7.7 万多个 star 了。这个生态起步速度,在 Agent 框架圈子里可不常见。

六、笔者的一点判断

当然,v0.1 开发者预览版,毛边不少,后面八成还会有重构,这些都是早早期项目的常态吧。

但笔者的态度很明确:方向是对的,而且难得地坦诚。V4 系列的升级说明 DeepSeek 不缺模型,Harness 的开源则说明,他们想聊点比模型更大的事。如果你也相信 Agent 是接下来几年的主线,那么现在就上手参与、定义它的基础设施,比等它成熟了再用,有意思得多。

当 Agent 的一切都能拆成插件,框架最后剩下的是什么?笔者认为是三样东西:接缝、标准,还有交还给每个开发者的定义权。

当然,当下 Agent 市场竞争火热,不确定性也很大。你觉得 Agent 的这副“身体”,最终会长成什么样?

从 Oracle 到 AI Agent:笔者亲历的数据分析二十年

二十多年前,笔者刚接触企业数据分析那会儿,Oracle 数据库、数据仓库还是很多大型企业项目绕不开的基础设施。那时候我们谈数据分析,首先想的往往不是“我要问什么问题”,而是:数据在哪?怎么抽出来?格式统一了吗?主数据整理过吗?
那时候做一个数据仓库项目,动辄一两年。最大的成就是什么?企业终于能把分散在 ERP、CRM、财务系统里的数据组织起来了。但代价也大——业务要一张报表,IT 排期一周。数据只能回答“昨天卖了多少”,至于“为什么卖了这么多”,得靠人自己猜。
二十多年过去了,笔者最近重新琢磨这个问题,突然发现:我们跟数据打交道的方式,正在发生一次比 Hadoop、云计算甚至自助 BI 更大的变化。
以前,是人学习怎么用数据库和分析工具。现在,开始变成机器学习怎么理解人的业务问题。
这个变化来得太快了,快到笔者发现很多 CIO 朋友其实还没完全意识到——他们的数据团队还在写 SQL、搭看板,而业务部门已经开始把 Excel 扔给 ChatGPT 问“帮我看看这里有什么问题”了。你说这事儿刺不刺激?

一、先把数据整理好——那个 Oracle 称王的年代

这就是数据仓库和 ETL 的时代。Oracle、Sybase 等是主角,核心工作就三件事:建模型、做清洗、统一口径。

笔者那会儿参与过一个移动运营商的数据仓库项目,光是对数据标准就开了两个月的会。财务口径和业务口径对不上,同一个“销售额”三个部门算出来三个数。你说 AI 来了能怎么办?数据先得是一家人,才谈得上“分析”这两个字。

二、数据突然太多了——Hadoop 来了,可业务人员使用数据有难度

互联网和移动互联网一爆发,日志、点击、设备、行为数据涌进来,传统数据库装不下了。Hadoop、数据湖应运而生。

这个阶段最大的变化是什么?数据分析的对象从“订单、客户、财务凭证”扩大到了“一切数据”。日志也能分析,图片也能存,行为轨迹也能查。

但麻烦也来了——这些技术门槛太高,只有数据工程师能玩得转。业务人员离数据反而更远了。笔者见过不少企业,花了几百万搭了数据湖,结果业务部门连怎么取数都不知道,最后还是把 Excel 发给 IT 帮忙导出。

这事儿说起来,有点讽刺吧:数据多了,能用的人少了。

三、看板满天飞,洞察呢?——自助 BI 有黄金点也有陷阱

PowerBI、FineBI 一来,自助分析成了。业务人员可以自己拖拽、钻取、做 Dashboard,不用再等 IT 写 SQL。

这个阶段最大的进步是“数据民主化”。看板铺天盖地,每个部门都有自己的驾驶舱。

但新的问题也冒出来了:看板越做越多,洞察依然稀缺。大家忙着做报表,却很少有人真正回答“所以呢?我们应该做什么?”笔者见过一个零售企业,BI 系统里躺了 300 多张看板,老板每周一看的还是那几张 Excel 表。

从一个极端走向另一个极端,数据分析这事儿,好像一直没找到最舒服的姿势。

四、2023 年那个瞬间——机器开始听懂人话

2023 年笔者第一次用 ChatGPT 分析 Excel 数据时,有一种很强烈的感受:自然语言,第一次真正成为分析界面。

以前是你去适应工具——学 SQL、学拖拽模型、学写公式。现在是工具来适应你。你直接问“上个月哪个品类利润下滑最严重”,它理解意图、定位数据、给出分析。

这不是自动化,这是交互方式的根本改变。数据分析不再是少数人的专业技能,变成了人人可用的对话能力。笔者当时跟一个做 BI 做了十年的朋友聊,他说了一句话:“我们这行,门槛没了。”

五、从“看”到“做”——AI 的下一步不是回答,是行动

到了 2026 年,笔者在上一篇《中国中小企业 AI 升级的五大风险与挑战》里也提过——AI 智能体正在从“回答问题”走向“主动发现并推动行动”。

以前的分析终点是一张 Dashboard,人看了之后自己去发邮件、开会、走流程。现在 AI Agent(智能体)开始具备规划、调用工具、分析验证、给出建议、触发后续动作的能力。

数据分析的真正终点,可能不再是“看到”了什么,而是业务行动被直接触发。

一张图把这条线串起来

笔者把这条演进路径画成了一条链:Database → 存好数据 → Data Warehouse/BI → 看懂数据 → Big Data/Data Lake → 分析更多数据 → Self-Service BI → 让更多人分析 → GenAI → 直接和数据对话 → AI Agent → 让 AI 主动分析 → Process/Action → 推动业务行动。

前四个阶段,本质上都在解决“让人类更好地看数据”。而从 GenAI 开始,我们进入了一个全新的领域——让机器理解人类的业务问题,并推动解决。

这个转折啊,笔者觉得比当年从 Oracle 到 Hadoop 的跨越还要大。因为前面的变化都是“工具升级”,这一次是“交互方式的重置”。

最后,留三个问题给正在思考数字化转型的 CIO等管理者

第一,你公司的数据基础,真的准备好让 AI 使用了吗? 如果数据还在 Excel 里、口径还不统一、质量还有问题,AI 再聪明也没用。关于这一点,笔者在上一篇《五大风险》里专门写了“基础风险”这一节,就不再展开了。

第二,如果员工以后不再打开十几个 Dashboard,而是直接问 AI,你现有的数据平台和 BI 体系应该如何变化? 这不是技术问题,是架构和治理问题。

第三,如果 AI 已经发现问题、分析原因并给出建议,下一步为什么还要靠人手工发邮件、找人、建任务、发起流程?

第三个问题是笔者最近想得最多的。笔者越来越觉得,AI 时代的数据分析终点可能不再是一张 Dashboard。它真正的终点应该是:Data → Insight → Decision → Action → Process → Feedback。

数据产生洞察,洞察辅助决策,决策触发行动,行动进入流程,流程执行结果重新成为数据。

如果这个闭环真正形成,数据分析、AI Agent 和 BPM 之间原本清晰的产品边界,也许会越来越模糊。这件事,可能才是 CIO 们在未来三年真正需要关注的方向。