2026 年 8 月，DeepSeek 开源了一个不是模型的东西：DeepSeek Harness（MIT 协议，TypeScript 实现，目前处于 developer preview）。官方给它的公式是——
Agent = Model + Harness
模型是 Agent 的灵魂，Harness 负责让 Agent 在真实环境里干活：理解环境、调用工具、持续工作。换句话说，它做的是 Claude Code 这一层的事情，而不是 DeepSeek 模型那一层的事情。
这个拆分对我们做企业 Agent 平台的人来说值得认真看。之前我在存量系统接入 Agent 的心智模型里聊过 API / MCP / Skill 三层的分工，在 Skill 薄壳化里聊过快照腐烂的问题——这些文章背后都隐含一个前提：宿主（Harness）是别人的，我们只能在能力层做文章。现在 DeepSeek 把宿主本身开源了，而且是用「可组合」的思路重新设计了一遍，这就改变了企业侧的可选项。
下面先拆它的架构，再逐一分析企业场景里能落地什么。
一、Harness 到底是个什么东西
先把概念掰清楚，因为「Harness」这个词最近被用得很滥。
狭义地说，Harness 是包裹在大模型外面的一层执行框架：
- 把模型接上文件系统、终端、网页、代码工具、其他 Agent；
- 管理上下文：每次往模型里塞什么、塞多少、什么时候压缩；
- 驱动循环：模型说「我要调工具」→ 执行 → 把结果喂回去 → 模型继续，直到任务完成；
- 划定边界：沙箱、权限、能碰什么不能碰什么。
一个直观的类比：模型是刚入职的聪明实习生，Harness 是他的工位——电脑、内网账号、门禁卡、操作系统、还有盯着他的合规部门。实习生的智力不变，但工位配置决定了他的产出上限和安全下限。
DeepSeek 内部在 2026 年 5 月组建了代码智能体团队做这件事，8 月开源。配套的动作挺有仪式感：单独开了微信公众号「DeepSeek Harness 团队」，标识是一只黑色鲸鱼——和 DeepSeek 模型产品的蓝鲸做了明确区隔，就是在告诉你这是两条产品线。
二、架构拆解：三个设计决策
官方页面上有三个关键词，每个都对应一个具体的设计决策。
1. Everything is a plugin
这是最核心的一条。DSH 构建在 Cordis 内核之上——Cordis 是一套插件系统内核，负责插件的挂载、卸载和依赖管理。在这个体系里：
模型、工具、技能、会话、沙箱、存储、循环调度、乃至 UI，全部以插件形式实现。
关键在后面半句：开发者通过配置就能选择、替换、扩展任何能力，不需要改 DSH 的源码。
这句话对企业用户非常重要。对比一下现状：想基于 Claude Code 做企业定制，主流做法是 fork 源码改，或者退而求其次用 hooks / skills 在外围打补丁。前者意味着每次上游更新都要合并冲突，后者意味着改不到骨架。而 DSH 把骨架本身做成了可插拔的，理论上你换掉它的模型接入层、沙箱实现、会话存储，都只是「换插件 + 改配置」的操作。
2. Every run is traceable
模型看到的所有内容都会写进一份 append-only 的会话日志：系统提示、推理过程、每次工具调用和结果、子 Agent 调度、每一次上下文注入。在 Trajectory 视图里可以按来源逐条检查，Resume / Fork / Search / Replay 全部基于同一份事件流。
注意「append-only」这个定语——只能追加不能篡改，这是审计日志的黄金标准。Agent 领域长期缺这个：大部分 Agent 产品的执行过程是个黑盒，出了 badcase 只能靠猜。DSH 把「运行即留痕」做成了框架层的默认行为，不是可选项。
3. 四种运行模式
| 模式 | 工具集 | 定位 |
|---|---|---|
| Standard | 文件编辑、shell、文件/网页搜索、skills、规划、子 Agent、工作流 | 完整编码 Agent |
| Code | 在 Standard 之上，通过 Code Mode SDK 让模型写 TypeScript 程序来编排多轮工具调用 | 复杂多步操作 |
| Minimal | 只保留 bash + str_replace_editor 两个工具 | 最小环境下评测模型 |
| Creator | Standard 全量能力 + 运行时检查、内存中测试插件、组合成新预设 | 制作自定义 Agent |
Minimal 模式的存在特别能说明这支团队的意图：把「模型能力」和「宿主加成」解耦。评测一个模型时用最小工具集，排除宿主差异的干扰——这是做严肃模型选型才需要的东西。
快速上手很简单：
# 启动 Web UI
npx @deepseek-ai/dsh web
# 或从源码安装
git clone https://github.com/deepseek-ai/deepseek-harness三、企业场景：能落地什么
架构讲完了，回到最实际的问题：企业拿 DSH 能干什么？我按「确定性从高到低」排了五个场景。
场景 1：私有化编码助手，替代 SaaS 编码工具
适用：对代码出境合规敏感的企业——金融、政企、有数据安全条款的 ToB 客户。
现在企业内推广 AI 编码工具只有两条路：买 GitHub Copilot / Claude Code / Cursor 的企业版，或者在开源宿主（Cline、Roo Code 等）里配私有模型。前者有数据出境和成本问题，后者长期缺乏一个「从第一性原理设计」的骨架。
DSH 提供了第三条路：MIT 开源、TypeScript 单一技术栈（前端团队就能维护）、模型层是插件——接 DeepSeek 官方 API、私有化部署的 DeepSeek 权重、还是公司统一网关，都只是配置项。配合 DeepSeek 模型本身的低成本（社区讨论里「单任务两毛钱」这个量级），自建一套全员可用的编码助手的总成本曲线和买 SaaS 完全不同。
落地动作：内网跑一个 DSH 实例 + 公司模型网关，先覆盖代码补全之外的重活——需求拆解、代码审查、测试生成、遗留系统改造——这些正是 Standard 模式 + 子 Agent + 工作流的能力范围。
场景 2：把内部系统能力封装成插件，做企业自己的 Agent 平台底座
适用：正在构建内部 Agent 平台的中间团队 / 平台工程团队。
这是我看到 DSH 时最先想到的场景。在薄壳化那篇里我说过，把业务流程写死在 Skill 里会腐烂，我们的解法是「薄壳 + 服务端能力目录 + 按会话下发的协议」。但那套方案有个隐含约束：宿主是 Claude Code 等第三方产品，能力下发只能通过 Skill / MCP 这几个固定的口子。
如果宿主换成一个可插拔的开源 Harness，平台团队的自由度大得多：
- 内部工具插件化：发布系统、工单、监控告警、权限系统，每个封装成一个 Cordis 插件，声明依赖关系，由内核统一挂载管理——而不是散落成一堆 MCP server 让每个 Agent 自己拼；
- 会话与存储可替换：企业通常要求会话落库、可检索、可归档，DSH 的 sessions / storage 是插件，直接替换成公司标准的存储方案；
- 沙箱可替换：默认沙箱不满足安全要求？换成自研的容器隔离方案，同样不动源码。
换句话说，企业 Agent 平台可以不再「构建在别人的宿主之上」，而是把 DSH 当作自己的底座，向上只暴露配置和插件生态。这改变了平台团队的谈判地位。
场景 3：审计与合规——append-only 会话日志是刚需
适用：受监管行业（金融、医疗、政务），以及所有需要回答「Agent 到底干了什么」的企业。
Agent 治理那篇里我们说过，Agent 进生产的合规底线是：每一次工具调用可追溯、每一次高危操作可回放。当时实现这套审计要自己埋点、自己设计事件模型。
DSH 把这件事做成了默认行为，而且事件流粒度到了「模型看到的每一个 token 注入」。对合规场景这意味着三件事：
- 取证：Agent 改坏了生产配置？从会话日志回放完整决策链——模型当时看到了什么、想了什么、调了什么工具、谁批准的；
- 复盘：badcase 分析不再靠截图和记忆，Trajectory 视图按来源检查每一步；
- Fork 调试：从事故发生的那一步 fork 出一条新会话，换参数重跑——这是传统日志体系做不到的「时间回溯调试」。
如果你们的安全团队正在为「AI Agent 操作留痕」写规范，这份日志的数据模型可以直接拿来当参考实现。
场景 4：模型选型评测——用 Minimal 模式做公平对比
适用：需要在不同模型间做采购 / 切换决策的团队。
企业选模型最大的坑是：评测结果里混进了宿主的加成。同一个模型在 Claude Code 里和在裸 API 里表现差很多，你不知道差距来自模型还是来自编排层。
DSH 的 Minimal 模式就是为了回答这个问题：只保留 bash 和文件编辑器两个工具，把宿主变量压到最低，让模型裸跑。配合它的 Resume / Replay 能力，可以做到同一组评测任务在不同模型上标准化重放。做模型选型报告时，「控制变量」这一栏终于有了像样的答案。
场景 5：Creator 模式做团队级 Agent 预设
适用：想给 SRE、测试、数据分析等不同工种定制专属 Agent 的组织。
Creator 模式支持运行时检查、内存中测试插件、把插件组合成新的预设（preset）。对企业的用法是：平台团队维护一批经过验证的插件（监控插件、工单插件、测试框架插件），各职能团队用 Creator 模式自助组合出自己的 Agent 预设——SRE 的 OnCall Agent、测试的用例生成 Agent、数据团队的取数 Agent。
注意这和「人人写 prompt」的区别：预设的组成单元是受治理的插件，每个插件有明确的权限边界和审计行为，组合是配置行为而不是开发行为。这是平台工程思路在 Agent 领域的自然延伸。
四、冷热水交替：现在别急着 All-in
说完能做什么，必须泼冷水。DSH 当前是 developer preview，官方自己写明「核心插件和 API 会持续演进」。这意味着：
- API 不稳定。基于它做深度二开，要接受跟进 breaking changes 的成本，短期别把核心生产链路压上去；
- 生态早期。社区插件数量、文档厚度、StackOverflow 答案存量，和 Claude Code 生态不在一个数量级。遇到问题大概率要读源码解决；
- 安全边界要自己加固。开源 ≠ 免责。沙箱逃逸、提示注入、工具滥用的防护，企业落地时仍然要做渗透测试和权限收敛——这一点上换成哪个宿主都一样；
- 需要 TypeScript 工程能力。二开团队要么是全栈/前端团队，要么做好跨团队协作的准备。
我的建议是分三步走：
- 现在：在内部创新项目 / 非关键链路上试点，重点验证插件机制和审计日志是否真的如宣传所述；
- 3-6 个月：如果 API 趋稳，把一个企业级场景（编码助手私有化是最稳的）做成正式项目；
- 长期：把它当作「Agent 宿主应该长什么样」的参考实现来研究——即便最终不用它，Everything is a plugin + Every run is traceable 这两条设计原则也值得吸收进自研体系。
五、结语
DeepSeek 用「Model + Harness」这个公式，把自己从模型供应商的角色往基础设施层又推了一步。对企业来说，真正值得关注的不是又一个开源项目，而是一个信号：Agent 宿主正在从「黑盒产品」变成「可组合的基础设施」。
当宿主可插拔、能力插件化、运行全留痕成为行业标配，「企业 Agent 平台」的护城河会进一步收窄到两块：一是企业私有的能力与数据（你的插件做得多好、接得多深），二是治理能力（权限、审计、质量运营）。前者我们在 Skill 薄壳系列里讨论过做法，后者是体检系列的主题。
工具在变便宜，编排在被标准化，剩下的竞争回到最朴素的两件事：你比别人的 Agent 更懂你的业务吗？你能证明它没干坏事吗？
