为什么「一切皆插件」是智能体落地的关键?DeepSeek Harness 架构完整拆解

• DeepSeek Harness 架构深读：对比 Claude Code/Codex/LangGraph，企业落地全指南

• 一切皆插件：DeepSeek 把 Agent 的黑盒，彻底拆给企业看了

• 模型卷完卷底座：DeepSeek 的这步棋，戳中了企业 Agent 落地的核心痛点

过去两年，DeepSeek 靠开源模型出圈，话题大多集中在"模型有多强、训练有多省"。8 月 13 号它做了一件不一样的事：把"模型怎么真正跑起来干活"这套东西也开源了，项目叫 DeepSeek Harness。

这是一次开发者预览（v0.1，MIT 协议），发布才几天，社区讨论很热。企业管理者这几天最该关心的 AI 发布里，它排得上号，但原因不在它涨了多少 star。

它把"智能体到底怎么跑起来"这件事，做成了可以拆开看清、可以自己组装的架构。过去这类能力大多锁在封闭产品里，DSH 选择把它摊开给你看。

这篇文章写给正在评估 AI 智能体（Agent）该怎么落地的企业管理者和业务负责人。我们会先讲清 DSH 是什么、能做什么、原理是什么，再把它和 Claude Code、Codex、LangGraph 摆在一条线上对比。

最后落到企业怎么用、怎么避坑。文末附了完整的一手资料来源，所有事实都来自官方文档、仓库与论文。

DeepSeek Harness 是什么

DeepSeek Harness（简称 DSH，命令行叫 dsh）是 DeepSeek 在 8 月 13 号开源的一个智能体运行底座，目前是 v0.1 开发者预览，采用 MIT 协议，代码全公开。

大模型本身只会"接话"，不会"办事"。要让模型真正去读文件、跑命令、调接口、拆任务，中间需要一整套把模型和现实环境连起来的软件。DSH 就是这套软件，而且它选择把这套软件做成完全开放、可以自己组装的形态。

理解 DSH 处在什么位置，先借用行业里（以 LangChain 官方分类为准）的三层划分：框架、运行时、Harness。

框架解决"怎么调模型、怎么接工具"的基础问题。运行时负责"让智能体长周期、有状态地跑下去"，包括记忆、流式输出、人在回路。这两层是地基。

Harness 是其中最上层、最贴近业务的一层。规划、子任务拆解、文件操作、上下文管理，都在这个层打包好，你拿来就能当一个完整能干活的数字员工用。

Claude Code、OpenAI Codex 都归在这一层，LangGraph 属于更底层的运行时。这个分类，是后面所有对比的标尺。

那么 DSH 具体能做什么？对外，它不只是一个命令行，还提供网页界面、编程接口和可被集成的 SDK，意味着它能直接嵌进企业自己的产品里。

对模型，它接的是通用兼容协议，任意兼容模型都能挂进来；对工具，它支持行业通用的 MCP 标准。你们的私有模型、内部系统，理论上都能接上。

它还内置了四种运行模式。标准模式走常规智能体循环；PTC 模式用程序化工具调用省 token；极简模式把动作压到最少；创造模式放权给模型自由发挥。

不同场景选不同模式，是它面向工程落地的一个实打实的设计。

可以用 DeepSeek 自己的定义来概括：Agent = Model + Harness（智能体等于模型加 Harness）。模型是灵魂，Harness 是让灵魂能在真实业务环境里用工具、持续干活的身体和工作台。

这句话的潜台词对企业很关键：模型可以换，但 Harness 决定了你的模型"怎么干活"。DSH 的特别之处，是把这个"工作台"本身也做成了可拆可换的插件组合。

下一章就拆开看它怎么做到。

核心设计"一切皆插件"：对企业意味着什么

DSH 的仓库标语就是"一切皆插件"。口号谁都会喊，难的是工程上怎么兑现。下面从四个设计点拆开，每一点都说明它对企业意味着什么。

没有特权的内核

DSH 底层是一个叫 Cordis 的插件内核，从 Koishi 聊天机器人生态里长出来，已经稳定运行了四年，上面跑着 4000 多个社区插件。这一点对企业非常重要：DSH 的插件哲学有真实跑了四年的生态做后盾，不是凭空设计出来的。

Cordis 的核心思路是"无特权内核"。内核自己几乎不实现具体能力，只负责把插件按依赖关系组织成一棵树，提供插件之间协作的机制。你在配置层就能换掉任何一个能力，不用改源码。

换个方式理解，内核不比任何插件更高贵。模型适配器、工具、技能、会话、沙箱、存储、循环、调度、界面，全都是树上平等的节点。

对企业来说，这意味着不会被锁死在某个厂商写死的核心能力上。今天用 DeepSeek 的模型，明天换自研的模型，后天接一个新的内部工具，理论上都能在不改动底层的情况下完成。

能力接缝：把一项能力拆成三块

企业架构师尤其要留意这个设计。它把每一项能力拆成三部分：接口契约（只描述这个能力长什么样，不含实现）、具体实现（某种后端）、消费方式（把能力交给模型，表现为一个工具或一种策略）。

它的好处是：你换掉文件系统的实现，命令行、终端、代码编辑器会一起挪到远程沙箱里，而且不需要改动其中任何一个。

它和"改个配置字段"的区别在于：把能力切成契约、实现、调用三个正交维度，让每一维都能独立替换。这就是"模型可替换"的真正落地方式。

替换供应商时（比如把云上的工具换成自己机房的服务），你们要覆盖的影响面是可预期的、局部的，不会牵一发动全身，对合规和供应链安全很关键。

一条只追加的日志：天然的审计底稿

模型能看到的一切，包括系统提示、推理过程、工具调用与结果、子任务调度、每一次上下文注入，都写进一条只追加、不可篡改的会话日志里。恢复、分叉、检索、回放，全部从这条日志派生。

DSH 立了一条很强的不变量：模型看到的内容必须已被记录。在单用户本地场景这很好成立。但管理者要提醒自己：一旦用到多租户的企业环境，就要单独处理数据归属，不能把 A 部门的工具结果写进全公司共享的数据库。

所以这条"单一事实源"既是 DSH 最大的架构美感，也是它走向企业多租户时第一个要跨的坎。

对金融、医疗、政务这类强监管场景，这条日志天生就是可回放、可调取的审计链。前提是你们自己把日志隔离和权限这一层补上。

论文底座：这不是拍脑袋的设计

支撑上面一切的，是 DSH 发布当天同步公开、与北大合著的一篇论文，主题是"时空可组合性"（链接见文末）。

它把"插件能热插拔且干净卸载"抽象成两个维度：时间维度（卸载时回滚全部副作用）和空间维度（依赖变化时框架主动通知相关组件）。

论文还证明了五条关键性质，Koishi 是文中的案例。这套形式化的出发点很实际：它针对的就是"智能体会自己改装、动态加载工具"这种最极端的场景。

企业技术决策者应该把这篇论文当作评估 DSH 长期可维护性的重要依据，而不只是看它的 demo 多花哨。

项目库与正在生长的生态：是真生态还是一阵风

看一个开源项目能不能投，不能只看发布当天的热度，要看它的家底和周边。

项目库本身。deepseek-ai/deepseek-harness 是一个 TypeScript 单体仓库，以 npm 包形式发布，采用 MIT 协议，目前是 v0.1 开发者预览。Cordis 内核以内置形式打包在仓库里。

它对外暴露的接口不止命令行和网页界面，还包括编程接口，意味着它可以作为"被集成的底座"嵌进企业自己的产品里。模型侧接的是通用兼容协议，任意兼容模型都能挂进来；工具侧支持行业通用的 MCP 标准。

生态生长速度。这个项目 8 月 13 号才发布，但社区动作已经很快。一个典型例子是社区项目 deepseek-harness-desktop，发布当天就把 DSH 封装成了桌面应用。

仅仅3天，截至8月16日，开源社区就玩出了DeepSeek Harness的万物皆可插。Github上的dsh-plugin标签下显示的公共库已经飙升到6200+，工作、学习、娱乐、怀旧、技术补齐类的插件应用仅有。

这种"官方出内核、社区补体验"的节奏，正是 Cordis 那套插件哲学被验证过四年的延续。

对想采用它的企业，这里有个现实：生态快速生长是双刃剑，好处是你不用从零造轮子，坏处是早期插件质量参差，后面企业落地部分会专门讲治理。

具体怎么用：你的团队上手要几步

架构讲完，接下来看实际怎么上手。

标准路径，用 Node.js 就能跑起来。先在本机装好 Node.js（它会自带 npx 命令），这是唯一的前置依赖。

打开终端，执行官方提供的一行命令：

1
npx @deepseek-ai/dsh web

命令会直接拉起 Web UI，默认在 http://127.0.0.1:3080 这个本地地址打开。整个过程不用提前 clone 代码，也不用手动编译。

不会安装的话，可以把DSH的仓库地址：https://github.com/deepseek-ai/deepseek-harness 扔给你在用的Codex、workbuddy等工具，让它们帮你安装。

进入界面后，再配置一个兼容 OpenAI 协议的模型地址和密钥，智能体就能开始读写文件、执行命令、处理任务。

如果你们团队想做二次开发，仓库另给了一条从源头构建的路线：git clone 之后依次执行 pnpm install、pnpm run build、pnpm dsh web。这条路线更重，适合要改内核或写自有插件的场景。

四种模式怎么选，对应不同业务诉求。

标准模式是完整的编码智能体，文件编辑、命令执行、搜索、规划、子任务、工作流都在里面，默认用它。

程序化工具调用模式让模型写一段代码把多步操作在一个程序里编排完，中间数据留在运行环境，只有最终结果进上下文，适合长链路数据处理，能省下不少调用成本。

极简模式只保留最基础的工具，专门给模型做基准测试，也适合你想看清"最少工具下模型能走多远"时玩。

创造模式允许运行时自我改装、拼出新预设，是 DSH 最激进的模式，也是"智能体自我改装"那个极端场景的实操入口。

接外部模型和工具时的真实注意点。想把你们自己的模型或工具接进来，要留意两件事：工具调用默认不一定实时返回，涉及长工具链时要调高超时避免卡死；模型地址走通用兼容协议，配错了不会给友好提示，得看那条会话日志来排查。

这也侧面印证了"日志是单一事实源"不是空话，它是你唯一的调试抓手。

给小白的零配置方案。如果你或团队里的人被命令行门槛挡住，直接看社区项目 deepseek-harness-desktop（GitHub 可查，MIT，非官方）。它用桌面技术把官方 Harness 的网页界面打包成原生桌面应用。

仓库地址：https://github.com/hairyf/deepseek-harness-desktop

下载安装包、双击安装、打开应用，本地服务由桌面端自动启动和管理，无需装开发环境、无需敲命令，配好密钥和工作区就能用，系统托盘常驻后台。

它对业务人员的价值在补齐"用户体验最后一公里"：让对技术不熟的人也能在图形界面里体验智能体读写文件、执行命令、处理复杂任务的完整能力。

它的路线图上还有手机远程控制、内置插件市场（像应用商店一样发现、安装、更新插件），以及接入微信、飞书、Discord、WhatsApp 等聊天工具。这些能力让智能体直接进日常沟通软件。

这些功能目前标着"即将推出"，但方向很清楚：把 DSH 从一个开发者工具，推向普通人也能用的桌面入口。

正好我的deepseek账户中还有不到14块钱，就选用标准模式和DeepSeek-V4-Flash 模型。试了一个简单的需求：搜集整理当前比较火的DSH插件和技能。

DSH推理，派任务，选工具，还启动了智能体，一番操作之后，看任务操作步骤搜了很多插件，但是账户里的14块无法支持它完成这个任务执行，多烧了5.16元，共花了19块，没能执行完，最后还有3条分解任务在排队。

这个任务，到截断时跑了4轮41步，工具调用用时接近8分钟，API请求次数多达305次。

任务执行上确实很细，当然提价后的DeepSeek模型确实也很烧。

现在想用的企业，需要搞清楚它的运作原理和计费机制。最好等产品状态再完善一下，出正式版以后再入手，到时社区对它的研究和优化也会更完善。

最好与其他 Harness 的差别

要把 DSH 放进选型清单，得先看它和已经存在的几个 Harness 站在一起是什么样子。下面四个，覆盖了封闭产品、编码智能体、编排运行时和可组合运行时四种典型形态。

Claude Code 是本地命令行加多界面（终端、IDE、桌面、网页）共享同一引擎，扩展靠可复用工作流、动作前后钩子、并行子任务、MCP 标准。但它的内层循环不可改，你能加工具和改边缘行为，动不了核心，模型偏向自家的 Claude。

Codex 是 OpenAI 的本地编码智能体，终端、IDE、桌面、云多形态，Linux 下用沙箱隔离、用本地数据库存日志和状态、带钩子引擎和工具支持。同样是固定内核的产品，靠沙箱和本地执行保证安全，模型偏向 OpenAI。

LangGraph 不算 Harness，是运行时。用图的方式编排长时、有状态的智能体，能把确定性步骤和模型驱动步骤混在同一张图里，提供持久化、流式、人在回路、记忆。你在它上面搭自己的 Harness，强项是可控编排，不是开箱即用的产品。

WorkBuddy 走的是技能、代理、连接器可组合运行时，没有特权内核，能力来自组合而非封闭主体，和 DSH 一样不绑定模型。

差异在于 DSH 用 Cordis 把"接缝"形式化了，WorkBuddy 的架构来自运行时自身设计，没有公开白皮书。

用一句话来总结它们的差异：Claude Code 和 Codex 的扩展在边缘，DSH 的扩展在核心，连智能体循环和界面都是可换插件。

这条分界线不容易一眼看清，却决定了你能不能把 Harness 真正握在自己手里。

企业怎么落地：重点展开

前面讲的是架构，这一节讲怎么落地企业。

DSH 发布才两天，谈"某大企业已全面上线"既不真实也不负责任。

这一节分三块来讲：先给三个真实可验证的案例（都来自一手资料），再给多张企业落地场景蓝图（基于架构推导、明确标注面向未来），最后给出治理、路线图和决策清单。

三个真实可验证的案例

先说三个能在一手资料里查证的事实案例。它们不证明 DSH 已经被企业大规模采用，但能证明它的架构主张不是空谈，每一个都对应一种可以借鉴的落地姿势。

案例一：社区把内核变成桌面产品（deepseek-harness-desktop）。

已经有真实的仓库摆在那里。它证明了一件事：DSH 的"无特权内核加插件树"设计，让第三方能在不改一行官方代码的情况下，把整个 Harness 重新包装成另一种交付形态（桌面应用）。

对企业来说，这本身就是一种参考架构。你完全可以基于 DSH 内核，封装出符合自己内部规范的"企业版智能体客户端"，而不必从零造轮子。这是一种把开源内核变成自有产品的合规路径。

案例二：Cordis 与 Koishi 的四年生态是"一切皆插件"的先例。

4000 多个社区插件、跑了四年，这是 DSH 插件哲学被真实验证过的证据。它告诉企业：这套模式能撑住大规模、长周期的插件生态，不是纸面上的概念。

但它也同时提醒，Koishi 生态也经历过插件质量参差、维护者流失的问题，这正是下一节要谈的治理风险。

案例三：DeepSeek 自己就是第一个吃螃蟹的人。

官方把定位写成"智能体等于模型加 Harness"，以及其新系列模型明显增强的智能体能力，说明 DeepSeek 正在把自己的模型能力通过 DSH 这套 Harness 向外释放。

DSH 是 DeepSeek 把模型能力转成智能体生产力的主通道，分量远不止一个实验性副业。企业参考这个信号，可以判断：跟着 DSH 走，等于押注"模型可替换、Harness 标准化"这条路线。

三个案例串起来看，结论很清楚：DSH 的价值不在某一个炫技功能，而在于它把"内核可替换、生态可生长"变成了别人能低成本复用的现实。这为企业落地提供了三种可以直接借鉴的姿势，接下来展开。

企业落地场景蓝图

下面这些是基于 DSH 架构推导出的典型用法，明确标注为"如果一家企业现在要上 DSH，典型路径长这样"，不是已发生的客户案例。

蓝图一：私有模型加 DSH 做代码审查与自动化。

很多金融、政企客户有自己的私有模型，或因合规不能用国外模型。DSH 模型解耦的特性正好命中这个痛点。

把内部模型挂上兼容协议，用标准模式跑代码审查、持续集成自动化、知识库问答。相比被某些产品的模型绑定限制卡住，这是 DSH 最直接的差异化价值。

蓝图二：用程序化工具调用模式做省成本的数据管道。

长链路数据处理最怕把中间结果一股脑塞进上下文，既贵又容易丢。该模式让模型写一段代码，把多步操作在运行环境里编排完，只有最终结果回上下文。

对要跑大量批处理、报表、数据清洗的团队，这是实打实的成本优化。

蓝图三：用只追加日志做审计回溯的合规场景。

金融、医疗、政务对"智能体干了什么"有强审计要求。DSH 的会话日志是单一事实源，天然适合做可回放、可分叉、可调取的审计链。

但切记前文提醒：多租户下数据归属要单独处理，别把 A 部门的结果写进共享库。这条场景成立的前提，是企业自己把日志隔离和权限补上。

蓝图四：基于 DSH 内核封装自有企业智能体平台。

参考桌面端项目的做法，企业可以把 DSH 内核嵌进自己的内部系统，套上符合企业视觉和规范的前台，变成面向员工的"内部智能体工作台"。

这样既能享受开源生态，又能守住数据不出域、界面统一管控的要求。对有一定研发能力的企业，这是性价比很高的路径。

蓝图五：建一个受治理的内部插件市场。

DSH 哲学是"一切皆插件"，企业可以顺势建立自己的内部插件目录，把仓储、审批、报销、客服等各业务系统的能力做成受审核的插件，按部门授权安装。

这比每个部门各自接一套智能体工具要可控得多，也便于统一安全和审计。

五张蓝图是从架构能力推出来的合理方向，不代表已经实现。企业可以挑最贴近自己痛点的那一两张，先做成试点，别一上来就铺满。

企业治理蓝图：最容易栽跟头的地方

前面反复提的插件治理，是企业采用 DSH 成败的关键，这里专门讲一下。Cordis 的形式化能保证"插件卸载干净"，但解决不了"几千个插件里哪些还活着、谁来审"的问题。企业若采用，这一层大概率要自己建。建议至少补齐四件事：

建立插件审核机制。所有上线的插件经过安全与合规评审，明确维护责任人，不审核不上线。

版本固定与回归。生产环境锁定插件版本，升级走测试流程，避免某个社区插件一更新就拖垮你的业务。

数据隔离。多租户下保证各部门日志、工具结果物理或逻辑隔离，不能混写共享库。

安全边界不依赖单一机制。DSH 的安全设计是"返回拒绝字符串即拦截"，它只能拦、不能主动放行，沙箱隔离级别更多是诊断信息而非安全承诺。把它当生产安全边界是危险的，企业要自己叠加权限、网络、审计多层防护。

企业采用路线图

综合以上，建议分三步走：

评估期（现在）：读架构文档和那篇论文，用极简模式跑几个基准，在隔离环境试插件。别接生产。

试点期（三个月内）：选一个非核心但重复劳动多的场景，比如代码审查或内部知识库问答，做概念验证，验证模型解耦和程序化调用省成本的收益。

治理期（半年后）：等官方退出开发者预览、接口稳定后，再谈插件市场、多租户隔离、审计链这些企业级能力。重点投入插件治理，这是 DSH 最不确定的风险点，也是企业最容易栽跟头的地方。

决策清单：什么时候上，什么时候等

建议现在就投入评估的几个信号：企业受模型绑定或供应商锁定困扰；有私有模型或因合规不能用国外模型；团队具备一定研发与治理能力；有一个重复劳动多、适合做试点的非核心场景。

建议先别碰的情况有三种。

一是监管极严、要求供应商承担端到端安全责任的核心系统，DSH 当前安全模型撑不住。

二是团队没有插件治理能力又想直接上生产，这类项目往往死在第六个月的兼容性上。

三是追求今天装上明天见效的业务方，开发者预览的破坏性变更会让你反复返工。

局限与风险

先说清楚一个前提：DSH 才发布两天，现在谈全面生产化确实早了。下面几条是决策前必须掂量的现实约束。

开发者预览，破坏性变更警告。官方自己写明：核心插件和接口会演进，会有破坏性变更。现在拿去生产是冒险。

插件生态治理。所有靠社区插件提供功能的产品，头半年很香，之后就是不兼容、过时、缺治理的噩梦。企业若采用，治理层要自建。

基准数字都是厂商自报。各项分数是在 Harness 极简模式里跑出来的，不能直接等同你的生产场景。

安全模型。前文已说，拦截机制只能拦不能主动放行，沙箱隔离级别更多是诊断信息。把它当生产安全边界是危险的。

语言选型有争议。DSH 用 TypeScript 而非 Python，和"一切皆插件"自洽，类型系统适合描述插件契约，但企业技术栈若以 Python 为主，会有人才和生态的摩擦成本。

写在最后

DSH 最有意思的地方，在于它怎么管理"还没想清楚的答案"。

Claude Code 和 Codex 在卖一个好用的产品，LangGraph 在卖可控的编排，DSH 在卖一个组合面，你用它组装自己的智能体产品，模型可以换、工具可以换、循环可以换。

对管理者，下面三句话值得思考。

第一，值得反复强调的是：一切皆插件是一套工程纪律，核心在于让内核保持无特权、让能力保持可热插拔，它的合法性来自那篇论文，而非某个 demo 的演示效果。

第二，现在最该做的是读架构、跑极简、在隔离环境试插件，别急着接生产。

第三，对企业，押注 DSH 等于押注模型可替换、Harness 标准化这条路线，但请把它当成一个需要你自建治理层的技术底座，而不是开箱即用的 SaaS。

反过来，也有三类情况我建议先别碰：监管极严、要求供应商承担端到端安全责任的核心系统；没有插件治理能力又想直接上生产的团队；追求今天装上明天见效的业务方。

不是不行，是时候未到。

扩展资源

• DeepSeek Harness 官方页：https://www.deepseek.com/harness/en/
• GitHub 仓库：https://github.com/deepseek-ai/deepseek-harness

• Cordis 内核：https://github.com/cordiverse/cordis
• 论文：Yifan Shi, Wei Zhang, Tianyi Cui, A Programming Paradigm for Spatiotemporal Composability
  https://github.com/cordiverse/paper/blob/main/paper.pdf
• 社区桌面端（非官方，MIT）：https://github.com/anywhere-labs/deepseek-harness-desktop