DeepSeek Harness：一切皆插件，Agent基础设施开始重构

2026年8月13日，DeepSeek面向全球开发者开放了 DeepSeek Harness 开发者预览版 v0.1，并以 MIT 协议开源。它的命令行名称是 dsh，除了终端入口，还提供浏览器 Web UI。开发者可以运行：

npx @deepseek-ai/dsh web

启动服务，默认访问地址为 http://127.0.0.1:3080。

如果只看这些信息，很容易把它理解成又一个 Coding Agent。但 DeepSeek Harness 的重点不在于“帮用户写代码的成品应用”，而在于它把 Agent 运行时本身开放出来，让开发者重新组合模型、工具、文件系统、执行环境和用户界面。

可以用一句话概括它的定位：

模型负责推理，Harness 负责模型之外的一切。

这里的“一切”包括工具调用、上下文管理、权限控制、记忆、Agent 循环、子 Agent 调度、会话记录、沙箱和界面集成。模型只是其中一个可替换部件。

这也是 DeepSeek Harness 最值得观察的地方。它没有把 Agent 固定成某一种产品形态，而是试图提供一套可以拆开、替换和重组的基础设施。

Harness不是成品Agent，而是运行时底座

普通用户接触到的 Coding Agent，通常已经把很多决定做完了。

厂商选择模型，设计提示词，规定工具调用方式，安排 Agent 循环，决定上下文如何压缩，再配上一套固定界面。用户打开软件，输入任务，然后等待结果。这个过程简单，但可调整的空间很小。

Harness 把这些组件拆了出来。

在传统产品里，这些东西经常被打包成一个整体。想替换其中一层，通常只能等待官方更新，或者 Fork 源码后自行维护。

DeepSeek Harness 选择了另一条路：让这些能力通过插件组合起来。开发者可以替换模型适配器，也可以替换工具注册表、上下文策略、Agent Loop 或界面，而不必修改整个系统的核心代码。

这意味着它更像一台可以自行装配的电脑。模型像处理器，工具和上下文像内存与外设，Agent Loop像操作系统调度逻辑，界面则是用户与系统交互的入口。这个比喻不意味着各组件在技术上完全对应，而是帮助人理解 Harness 的设计重点：能力被拆分，接口允许替换。

“一切皆插件”具体怎样工作

DeepSeek Harness 基于 Cordis 插件元框架构建。Cordis 主要负责几件事：

• 加载和卸载插件；
• 管理插件依赖；
• 注册和发现服务；
• 处理插件之间的事件通信；
• 管理不同插件的作用域和运行关系。

一个插件可以声明自己提供哪些服务，也可以声明运行时需要哪些能力。框架根据这些声明完成组件连接。

例如，一个 Git 插件可能需要文件系统访问和 Shell 执行能力；一个浏览器插件可能需要网络访问和页面操作接口；一个新的 Agent Loop 可能需要模型服务、工具注册表和会话事件流。插件不必直接调用某个具体实现，而是依赖一组服务。

这样做的好处是降低耦合。

假设文件编辑器只认某个固定工具，换掉工具实现就要修改编辑器代码。采用服务和事件机制后，编辑器只关心“有没有文件读取服务”和“有没有文件写入服务”，至于服务由哪个插件提供，可以由运行时决定。

Agent Loop 也被放进了插件体系。这一点很关键。

许多 Agent 产品把循环逻辑写在内部：模型生成请求，系统执行工具，把结果塞回上下文，再次调用模型，直到任务结束。开发者通常只能调整少量参数。

在 Harness 中，开发者可以替换这套循环。例如：

• 让模型先制定完整计划，再执行工具；
• 让不同模型分别负责规划、编码和检查；
• 让高风险工具在执行前进入审批队列；
• 让多个子 Agent 并行处理不同目录；
• 让模型生成 TypeScript 程序，批量编排工具调用；
• 让某类任务使用短循环，另一类任务使用带评审节点的长循环。

这些变化不需要把整个 Harness 改造成另一套软件。开发者可以通过 Profile、Bundle 或 patch 挂载新的插件组合。

Harness 内部没有一个必须被修改或打补丁的“特权内核”。这让开发者可以从运行时外部改变系统行为，而不是先 Fork 一个版本，再面对源码合并和升级问题。

当然，插件化并不等于没有约束。插件仍然需要遵循接口、服务依赖和事件协议。只是约束从“你必须修改这段内部代码”转向了“你需要实现这组公开能力”。

四种运行模式，分别服务不同任务

DeepSeek Harness 当前提供四种运行模式。它们不是简单的界面主题，而是不同的运行时组合。

标准模式：完整的日常开发环境

标准模式加载较完整的工具集合，通常包含：

• 文件读取与编辑；
• Shell 命令执行；
• 信息检索；
• 技能调用；
• 计划和目标管理；
• 子 Agent；
• 工作流；
• 后台任务。

它适合常规软件开发。用户可以让 Agent 阅读项目、修改代码、运行测试、查看结果，再根据错误继续修复。

完整能力也意味着更复杂的权限和上下文管理。工具越多，Agent可采取的动作越多，调试和审计的要求也越高。

PTC模式：让程序编排工具调用

PTC 指程序化工具调用。它的思路是：不要让模型为每一步工具调用单独生成一轮自然语言请求，而是让模型生成 TypeScript 代码，由程序统一组合多轮调用。

举个简单例子。一个任务需要先扫描目录，再读取若干配置文件，最后根据内容生成报告。普通调用方式可能是：

1. 模型请求扫描目录；
2. 系统返回目录结果；
3. 模型选择文件；
4. 系统返回文件内容；
5. 模型继续分析；
6. 模型再请求写入报告。

PTC模式可以让模型直接生成一段程序，由程序完成目录扫描、文件读取和结果整理，再把汇总信息交给模型。

工具链越长，这种方式越有价值。它可以减少模型和工具之间的往返，也让条件判断、循环和批量处理交给程序执行。代价是，生成的程序本身需要受到权限控制，错误处理也要做得足够细。

极简模式：保留最小能力

极简模式只保留 Shell、文件编辑等基础能力，适合测试模型和 Agent 框架本身。

在做基准测试时，工具太多会引入额外变量。某个结果变好，可能是因为插件提供了额外技能，也可能是因为上下文策略发生了变化。极简模式可以减少干扰，帮助开发者观察模型在统一环境下的行为。

它也适合搭建小型自动化任务。任务只需要读写文件和执行命令时，完整运行时反而会增加复杂度。

创造模式：观察和改造运行时

创造模式是 Harness 最能体现其设计取向的入口。

开发者可以在这里检查当前运行时加载了哪些插件、哪些服务正在工作，再尝试加入或替换组件。实验完成后，可以把验证过的组合打包成 Bundle，挂载到某个 Profile 中。

Profile 可以理解为一套独立的插件与配置组合。Bundle 则是 Cordis 配置行和挂载代码的分发形式。两者共同组成了从实验到复用的基本路径：

1. 在创造模式中检查现有运行时；
2. 加入新的插件或替换某个服务；
3. 验证组件之间的依赖和事件通信；
4. 将可用组合整理为 Bundle 或 patch；
5. 挂载到 Profile，在其他任务中复用。

这套流程改变了 Agent 的使用方式。开发者不需要先设计一个完整产品，再把所有能力写死在里面，可以先从一个具体任务开始，边运行边调整。

轨迹视图：Agent终于可以被逐步检查

Agent 最难排查的问题，往往不是最后一句回答错了，而是它在中间某一步看到了错误的信息。

比如：

• 上下文压缩时丢掉了关键约束；
• 工具返回了错误格式，模型却继续执行；
• 子 Agent 的结果没有正确注入主 Agent；
• 模型调用了权限之外的路径；
• 某个工具反复失败，循环却没有及时停止。

只看最终对话，很难知道问题从哪里开始。DeepSeek Harness 用 append-only 会话日志记录运行过程。模型看到的关键内容都会进入日志，包括系统提示词、思维链、工具调用、工具结果、子 Agent 调度和上下文注入。

Trajectory 视图可以按 Turn 和来源查看原始记录。常见来源包括：

• USER
• CONTEXT
• ASSISTANT
• TOOL

开发者可以顺着时间线查看：模型在这一轮收到了什么，决定调用哪个工具，工具返回了什么，接着哪条信息进入了上下文。

这类记录还有三个实用作用。

第一是恢复。任务中断后，可以从已有会话继续执行。

第二是分叉。开发者可以从某个节点创建新分支，换一种提示词、模型或工具策略，比较不同路径的结果。

第三是回放。出现异常时，可以复现之前的事件流，而不是凭印象重新描述问题。

这实际上把 Agent 从“聊天工具”变成了一个可调试的执行系统。它更接近日志驱动的工作流引擎：每个动作产生事件，事件被保存，后续操作可以基于事件继续。

权限不是一个开关，而是一组边界

Agent 能执行 Shell、修改文件和访问网络后，权限控制就不能只依赖一条确认提示。

Harness 将沙箱和审批策略结合起来。常见的权限范围包括：

审批策略还可以设置为需要询问，或在特定条件下自动放行。比如，读取工作区内的文件可以自动执行，删除文件、安装依赖或访问外部网络则要求人工确认。

底层隔离机制会随操作系统变化：

• Linux 可使用 bwrap 或 Landlock；
• macOS 使用 Seatbelt；
• Windows 使用 ACL 受限令牌。

这些机制能限制文件访问、进程操作和部分系统能力，但不应被理解为自动消除了所有风险。网络访问范围、子进程行为、宿主机配置和第三方工具本身，都可能影响隔离效果。

尤其是在执行不受信任的代码、使用全系统访问权限，或让 Agent 自动安装依赖时，开发者需要明确知道它能做什么、不能做什么。

可观测日志让错误更容易追踪，审批系统让高风险动作更容易拦截，但两者都不能代替权限设计。把 Agent 放进生产环境前，仍然需要限制工作目录、固定依赖版本、区分开发和生产凭证，并对敏感操作设置人工确认。

插件生态会把Agent变成平台吗

插件化降低了参与 Agent 基础设施建设的门槛。

开发者可以只做自己熟悉的部分：

• 接入一个数据库；
• 封装某个企业 API；
• 增加浏览器自动化；
• 集成 Git 和代码审查；
• 提供终端界面；
• 设计多 Agent 协作策略；
• 接入任务管理系统；
• 编写新的上下文压缩方式。

用户不需要接受厂商固定的工具、界面和循环逻辑。如果不喜欢当前的终端界面，可以替换成 Web 工作台；如果觉得默认 Agent Loop 不适合长任务，可以挂载另一种循环；如果只想做基准测试，可以选择极简运行时。

一些实际展示已经出现了不同方向的尝试：有开发者把界面做成早期门户网站风格，也有人制作类似 Claude Code 的 TUI，还有工作台式界面，把文件管理、编辑和预览放在同一个窗口中。多 Agent 团队协作的插件也展示了另一种可能：多个角色分别负责规划、实现和检查，并通过事件传递任务状态。

这些案例未必已经成熟，但它们说明 Harness 的边界不只是一款编码助手。它可以成为不同 Agent 产品的共同运行层。

官方也预留了插件发现、加载、版本管理和依赖管理方向，并在仓库中留下 Plugin Store 的发展空间。假如生态逐渐形成，Agent 能力可能像应用一样被分发：开发者发布插件，用户按需安装，Profile 负责组合，运行时负责加载。

不过，插件市场不会自动带来高质量生态。它还要解决几个实际问题：

• 插件是否经过安全审核；
• 插件升级后是否破坏现有配置；
• 不同插件之间的依赖冲突如何处理；
• 插件出了问题，责任由谁承担；
• 企业是否能审计插件访问了哪些数据；
• 开发者如何维护长期兼容性。

v0.1 仍是开发者预览版，官方已经提示后续可能出现破坏兼容性的变化。因此，现在更适合把 Harness 当成实验平台和基础设施原型，而不是直接当作稳定生产依赖。

一次评测不能回答“谁更强”

已有视频评测使用 DeepSeek V4 Pro 加 DeepSeek Harness，对比 Codex 加 GPT-5.6。测试条件包括相同提示词、单次运行，并且不额外使用 Skills。评测覆盖五个项目：

• 南极电磁风暴；
• 手写数字识别器；
• 迷宫寻路实验室；
• 三维直升机；
• 音乐播放器。

从展示结果看，南极电磁风暴项目中，评测者认为 DeepSeek Harness 的视觉效果更好；手写数字识别器和迷宫项目大致打平；三维直升机项目中，DeepSeek Harness 的功能完成度相对更高；音乐播放器项目里，Codex 在界面细节层次上更丰富。

整体质量差距并不大。Codex 在部分视觉细节上更精致，DeepSeek Harness 在信息组织和亮点设计上更完整。

效率数据也很受关注。该视频声称，在这组任务中，DeepSeek Harness 平均耗时约为 Codex 的三分之二，Token 消耗量不到 Codex 的一半。这个结果只能归属于这次具体评测，不能直接推导出普遍性能结论。

影响结果的因素很多：

• 使用的模型版本；
• 提示词写法；
• 是否启用缓存；
• 工具调用方式；
• 网络和机器环境；
• 任务类型；
• 评测者对“完成度”的判断标准。

另一段体验展示提到，连续 31 轮、650 多个步骤的对话中，界面显示缓存率接近 100%。由于界面存在四舍五入，这里更稳妥的说法是“显示接近 100%”，不能把它当作精确统计值。

还要区分三件事：基础模型能力、Harness 的运行效率，以及插件提供的额外能力。一次测试把它们放在一起观察，适合了解使用体验，却无法单独证明是哪一层带来了结果。

目前更稳妥的判断是：DeepSeek Harness 已经具备进入 Agent 基础设施竞争的工程基础，但它仍需要第三方大规模复现，继续验证生产稳定性、成本、插件质量和兼容性。

DeepSeek正在押注Agent平台层

DeepSeek Harness 最值得关注的地方，不只是它能否生成更好的代码或界面，而是它把 Agent 的执行层、工具层和交互层开放给开发者重组。

模型、工具、上下文、权限、循环和界面被拆开后，Agent 不再只能以一个固定产品出现。开发者可以根据任务装配运行时：

• 基准测试需要极简模式；
• 日常开发需要标准模式；
• 批量工具处理可以尝试 PTC；
• 框架实验则进入创造模式；
• 高风险任务需要更严格的沙箱和审批；
• 多角色任务可以替换 Agent Loop，加入子 Agent 调度。

这条路线的价值，在于它把许多原本只能由厂商决定的环节交给开发者。对于开发者，当前最适合的用途是试验、基准测试、插件开发和运行时研究。用于生产部署时，应固定版本，审慎配置权限，保留完整日志，并持续检查插件和依赖的兼容性。

Agent 的竞争也因此出现了新的比较维度。过去人们常问哪个模型更聪明、哪个产品写代码更快。接下来还要看：执行框架是否可靠，工具能否自由替换，任务过程能否审计，插件是否容易开发，生态能否持续维护。

DeepSeek Harness 可能成为 Agent 时代的重要基础设施候选，但开发者预览版距离稳定平台还有一段距离。它能否真正建立起平台地位，最终取决于插件生态、开发体验、生产可靠性和第三方验证，而不只是“一切皆插件”这句架构口号。