DeepSeek Harness 深度测评：它真正改变的，不是模型，而是 Agent 的运行方式

DeepSeek Harness 最近引起关注，并不是因为它又发布了一个聊天机器人，而是因为它试图重新定义 Agent 的基础设施。

DeepSeek 官方给出的表达很直接：

Model + Harness = Agent

模型负责理解、推理和生成，Harness 负责让模型接触文件、终端、工具、工作区和真实任务。也就是说，DeepSeek Harness 关注的不是“模型能回答什么”，而是“模型能否持续、可控、可恢复地完成一件事”。

我的判断是：DeepSeek Harness 更像是一套 Agent 运行时和组装框架，而不是 Claude Code、Codex 这类开箱即用的编程助手。它最大的价值在于可替换性和可观察性，但目前仍然处于 Developer Preview 阶段，适合开发者研究、二次开发和内部试验，不适合直接作为唯一的生产基础设施。

一、DeepSeek Harness 到底是什么

DeepSeek Harness，也称 DSH，命令行入口是 dsh，npm 包为 @deepseek-ai/dsh。

它主要负责把以下能力组合起来：

• 模型适配器
• Agent 循环
• 文件系统
• Shell 和终端
• 工具注册与调用
• 会话记录
• 权限审批
• 沙箱隔离
• 子 Agent
• 任务计划
• Web UI
• Python SDK、JSON-RPC 和 ACP 接口

传统的 Agent 项目往往把这些能力写在一个相对固定的框架里。想替换模型、上下文管理方式或 Agent Loop，通常需要修改源码。

DeepSeek Harness 的思路完全不同：它认为模型、工具、会话、循环、UI 甚至沙箱都应该是可以替换的插件。

这就是它反复强调的：

Everything is a Plugin

二、它最核心的设计：一切皆插件

DeepSeek Harness 建立在 Cordis 插件系统之上。

Cordis 本身并不负责调用大模型，也不负责执行具体工具。它主要负责：

• 插件加载
• 插件卸载
• 依赖管理
• 服务注册
• 事件分发
• 生命周期管理

这让 Harness 的业务能力被拆成了很多相对独立的模块。

例如，模型调用不是写死在 Agent Loop 里面，而是通过模型能力接口提供。文件系统、Shell、沙箱和工具也遵循类似的结构。

这样做的好处是，消费者只依赖稳定的能力接口，而不是某个具体实现。比如工具只需要知道如何使用 Shell 能力，并不需要关心底层到底是本地 Shell、沙箱 Shell，还是远程执行环境。

从架构角度看，这比简单地增加几个配置项更彻底。它不是在一个大框架上不断打补丁，而是试图让框架本身成为一个可以重新组装的系统。

三、可逆副作用，是它最值得关注的技术点

很多项目都宣称自己支持插件，但真正困难的是插件卸载。

一个插件可能注册事件监听器、创建定时器、打开连接、注册服务，甚至挂载其他插件。如果插件被替换或卸载，而这些副作用没有被清理，就会出现：

• 事件重复触发
• 旧服务残留
• 内存泄漏
• 状态不一致
• 新旧 Provider 同时生效

Cordis 的解决方案是“可逆副作用”。

插件在注册资源时，同时记录对应的撤销操作。插件卸载时，框架按照后进先出的顺序执行这些撤销操作，把插件产生的影响逐步撤回。

它带来的实际价值包括：

1. 插件初始化失败时，可以清理已经完成的部分。
2. 父插件卸载时，可以连带清理子插件。
3. 替换某个能力时，不需要手动维护复杂的清理逻辑。
4. 动态切换 Provider 时，更不容易留下旧状态。

这也是 DeepSeek Harness 能够支持热插拔和动态组合的基础。

不过，这种机制也提高了框架的理解门槛。开发者不仅要理解“怎么注册一个插件”，还要理解插件的生命周期、依赖状态和副作用回滚。

四、会话日志不是普通聊天记录

DeepSeek Harness 对会话的处理，也和普通聊天应用不同。

它使用追加式事件日志保存运行过程。模型看到的内容、工具调用、工具结果、上下文注入、子 Agent 调度等，都应该能够从会话事件中重新构建。

这意味着它保存的不只是最终对话，而是一次 Agent 执行过程中的完整轨迹。

这种设计特别适合以下场景：

• 恢复中断任务
• 回放 Agent 行为
• 分叉已有会话
• 分析工具调用过程
• 审查模型为什么做出某个决定
• 定位任务失败的具体步骤

官方页面也强调了 Trajectory 视图，用户可以按时间线查看系统消息、用户输入、模型输出、工具调用以及工具结果。

对复杂 Agent 来说，这一点非常重要。传统聊天记录只能告诉你“最后说了什么”，而事件日志更接近“整个系统到底做了什么”。

它的代价是数据结构更复杂，存储和兼容性问题也更难处理。官方仓库目前明确提醒，项目仍处于 Developer Preview，未来可能存在兼容性破坏。

五、四种运行模式，分别适合什么人

DeepSeek Harness 当前提供了几种不同的运行模式。

Standard：完整工作模式

Standard 模式提供完整的编码 Agent 能力，包括：

• 文件读写
• Shell
• 计划
• 工具调用
• 子 Agent
• 工作流
• 权限审批

如果只是想把 Harness 当作本地编程助手使用，通常从这个模式开始。

PTC：编程式工具调用

PTC 的全称是 Programmatic Tool Call。

普通 Agent 可能需要多轮调用工具：

1. 获取文件列表
2. 读取文件
3. 分析结果
4. 再读取其他文件
5. 修改文件
6. 运行测试

PTC 模式允许模型生成一段代码，通过代码在执行环境里连续组合多个工具调用。

它可能带来两个好处：

• 减少模型和工具之间的往返
• 减少中间数据进入上下文的数量

这对长链路任务尤其有吸引力。但它也让安全边界更加重要：模型不只是调用工具，而是在生成一段可以组合调用工具的程序。

Minimal：最小化基准模式

Minimal 模式只保留最基础的 Shell 和文件编辑能力。

它适合：

• 测试模型本身的能力
• 对比不同模型
• 构建最小 Agent 环境
• 排查复杂插件对结果的影响

如果在完整模式中遇到问题，Minimal 模式也有助于判断问题究竟来自模型，还是来自工具和插件组合。

Creative：实验性模式

Creative 模式允许开发者检查当前运行时并尝试动态组合插件。

它更像是一个实验场，而不是普通用户模式。适合研究 Harness 自修改、插件实验和自定义 Agent preset。

由于它的权限和可变性更高，使用时需要更加谨慎。

六、上手并不复杂，但它不是“安装完就能用”

官方给出的快速启动方式是：

npx @deepseek-ai/dsh web

启动后，通常还需要完成以下步骤：

1. 打开 Web UI。
2. 在 Settings → Models 中配置 API Key。
3. 添加并选择工作区。
4. 创建会话。
5. 发送第一条任务指令。

官方文档特别提到，没有选择工作区时，会话输入框不会启用。

第一个任务可以从简单的仓库分析开始：

Summarize this repository and identify its main packages.

之后 Agent 才会开始读取文件、维护计划、调用工具或请求权限审批。

从使用流程看，Harness 的门槛主要不在启动命令，而在于理解工作区、Provider、权限策略、运行模式和插件配置。

对熟悉 Node.js、TypeScript 和 Agent 开发的用户来说，这个门槛可以接受。对只想打开软件聊天的普通用户来说，它显然不是最简单的选择。

七、它真正强的地方

1. 可替换性很彻底

很多 Agent 工具允许替换模型，但很难替换 Agent Loop、会话存储或权限系统。

Harness 的目标是让这些部分都能被替换。它更像是为 Agent 开发者准备的底层平台。

2. 运行过程可观察

Trajectory 和追加式会话日志，让 Agent 的行为不再完全是黑盒。

对于调试长任务、分析工具误用和审查自动化操作，这一点很有价值。

3. 同一套能力覆盖多个入口

从当前仓库结构和文档来看，Harness 不只提供 Web UI，还包括：

• Headless CLI
• Python SDK
• JSON-RPC
• ACP
• 插件开发接口

这说明它的目标不是只做一个网页工具，而是建立多个运行入口共享的 Agent 基础设施。

4. 适合企业和研究场景定制

如果企业希望统一管理模型、工具、审批、沙箱、会话和审计，Harness 的插件化结构具有一定吸引力。

它也适合用来研究：

• Agent Loop 如何替换
• 工具权限如何控制
• 子 Agent 如何编排
• 运行轨迹如何回放
• 不同模型如何共享一套执行框架

八、它目前的问题

1. Developer Preview 的稳定性风险

官方仓库明确写着：

THERE WILL BE COMPATIBILITY-BREAKING CHANGES

这意味着配置格式、命令、包结构和接口都可能继续调整。

因此，目前不适合直接把它作为唯一生产系统，也不建议在没有锁定版本和备份机制的情况下升级。

2. 抽象层较多，学习成本不低

“一切皆插件”带来了灵活性，也带来了复杂度。

开发者需要同时理解：

• Cordis
• 插件生命周期
• Bundle
• Profile
• Patch
• Capability Seam
• Scope
• Session Event
• Host / Client 分离

对于只想自定义一个工具的人来说，这套架构可能显得过重。

3. 插件生态仍在早期

官方已经开放了社区插件入口，但社区插件的质量、维护周期、安全性和兼容性仍然需要单独评估。

不要因为插件可以被安装，就默认它值得在生产环境使用。

4. 安全不能只依赖沙箱

Harness 提供权限审批和沙箱相关能力，但 Agent 仍然可能执行具有破坏性的操作。

实际部署时仍然需要：

• 限制工作区范围
• 使用最小权限
• 对 Shell 和文件操作设置审批
• 固定依赖版本
• 审查第三方插件
• 保留会话和工具调用日志

尤其是在 PTC 或自动执行模式下，权限边界必须先设计好。

九、它适合替代 Claude Code 或 Codex 吗

我认为不能简单地用“替代”来描述。

如果你的目标是：

• 尽快完成编码任务
• 少配置
• 直接开始使用
• 依赖成熟的交互体验

那么成熟的编程 Agent 产品可能更合适。

如果你的目标是：

• 自定义 Agent Loop
• 替换工具和执行环境
• 管理多个模型 Provider
• 设计企业内部 Agent 平台
• 研究会话、权限和插件运行时
• 让同一套 Agent 能力同时支持 Web、CLI 和 SDK

那么 DeepSeek Harness 的方向更值得关注。

它不是把一个固定的 Agent 做得更完整，而是试图把 Agent 拆成一组可以重新组装的基础设施。

十、最终评价

DeepSeek Harness 最有价值的地方，不是它能不能完成一个普通的代码任务，而是它把 Agent 的“运行时”本身开放出来了。

它提出的核心问题是：

如果模型、工具、上下文、循环、权限和界面都可以替换，Agent 是否可以像操作系统一样被重新组装？

从当前公开资料来看，DeepSeek Harness 已经给出了相对完整的答案：

• Cordis 负责插件生命周期和依赖关系。
• Capability Seam 负责抽象可替换能力。
• Session Log 负责记录和恢复运行过程。
• Profile、Bundle 和 Patch 负责配置组装。
• Web、CLI、Python、JSON-RPC 和 ACP 负责不同的使用入口。

但它现在仍然是一套快速迭代中的开发者预览版。它的架构值得研究，代码值得阅读，插件机制值得尝试，但在稳定性、生态成熟度和生产兼容性上，还需要继续观察。

我的建议是：

• 普通用户：先把它当作实验性的本地 Agent 工具。
• 独立开发者：可以用它研究插件和自定义 Agent。
• 企业团队：先做隔离环境和内部 PoC，不要直接替换现有生产系统。
• Agent 框架开发者：重点关注 Cordis、事件日志、Capability Seam 和 PTC 的实现方式。

DeepSeek Harness 目前未必是最适合所有人的 Agent 产品，但它很可能会推动更多开发者重新思考：Agent 的竞争重点，或许不再只是模型能力，而是模型之外那一整套执行基础设施。

参考资料

1. DeepSeek Harness 官方介绍
2. DeepSeek Harness GitHub 仓库
3. DeepSeek Harness 官方开发者文档：使用 Web UI
4. 知乎：DeepSeek Harness（dsh）详细架构报告
5. CSDN：DeepSeek Harness 深度分析：用途、问题、架构原理与使用指南
6. 腾讯云开发者社区：从架构层面解读 DeepSeek Harness
7. 百家号：DeepSeek Harness 全面解读：功能、架构与上手指南

注：文中涉及版本状态、命令和功能时，以官方仓库和官方文档为准。第三方文章发布时间不同，部分内容可能对应较早的预发布版本。本文中所有动态图片均由在线动图工具站制作并压缩得到