我最早知道 DeepSeek Harness，其实有点偶然。那天在看一个介绍 Pi Agent 的视频，评论区里有人反复提到 DSH，说它的设计理念和 Pi Agent 有不少相似之处。起初我以为只是又一个 Agent 框架，点进 GitHub 后才发现不太对劲：这是 DeepSeek 官方刚刚公开的新项目，而且 Star 增长速度几乎到了失控的程度。
评论区里关于它与 Pi Agent 关系的说法，也很容易让人产生一个印象：DeepSeek Harness 是不是“基于 Pi Agent 核心理念做出来的 DeepSeek 版 Pi”？
我随后把官方仓库、架构文档、Cordis 设计、Pi 相关适配器、社区讨论和使用教程都翻了一遍。结论是：这个说法抓住了两者的相似气质，但严格来说并不准确。
DeepSeek Harness 不是 Pi Agent 的 fork，官方底层也不是 Pi，而是 Cordis。但两者确实都在走“轻核心 + 可组合能力”的方向；更有意思的是，DSH 官方仓库里还直接提供了基于 @earendil-works/pi-ai 的多模型适配器，社区甚至已经出现 pi2dsh，尝试把 Pi 的 tools、commands、prompts、skills 和生命周期钩子映射进 DSH。
也正是从这里开始，我意识到 DeepSeek Harness 值得单独写一篇。因为它真正有意思的地方，不是“DeepSeek 又做了一个 AI 编程助手”，而是：DeepSeek 开始公开自己对于 Agent 应该如何被构建、组合、追踪和扩展的答案。
先看结论：DeepSeek Harness 到底是什么？
DeepSeek 官方给出的公式非常简单：
Agent = Model + Harness
模型负责理解、推理和生成；Harness 则负责让模型真正“在环境里干活”——访问文件、调用 Shell、搜索网页、使用工具、管理会话、调度子 Agent、控制权限、保存状态、恢复任务，以及把这些执行过程展示给人看。
所以，如果把大模型比作“大脑”，Harness 更像是它的神经系统、工具箱、执行环境和外骨骼的总和。
| 项目 | 信息 |
|---|---|
| 项目名称 | DeepSeek Harness（CLI：dsh） |
| 开发者 | DeepSeek AI |
| 首次公开 | 2026 年 8 月 13 日 |
| 当前阶段 | Developer Preview（开发者预览） |
| 许可证 | MIT |
| 主要技术栈 | TypeScript / Node.js / Cordis |
| 默认界面 | 本地 Web UI，默认 http://127.0.0.1:3080 |
| 快速启动 | npx @deepseek-ai/dsh web |
| GitHub 热度 | 截至 2026 年 8 月 23 日，多家实时同步源显示约 18.5 万 Star，仍在快速增长 |
它最核心的一句话只有五个字：
Everything is a Plugin —— 一切皆插件。
为什么它能在 10 天左右冲到 18 万+ Star？
GitHub Star 不能直接等于技术质量，但一个刚公开十天左右的开发者预览项目迅速进入 18 万级别，显然也不能只用“DeepSeek 品牌效应”解释。
我认为至少有六个因素叠加在一起。
1. DeepSeek 的品牌和时机
2026 年的 Agent 竞争已经从“谁的模型更聪明”进入“谁能让模型稳定完成真实工作”的阶段。Claude Code、Codex、OpenCode、Pi Agent 等产品已经教育了大量开发者：模型能力只是上限，真正决定日常体验的还有工具调用、上下文管理、权限、Agent Loop、子任务调度、会话持久化和 UI。
DeepSeek 在这个时间点公开 Harness，恰好击中了开发者对“模型之外那一层”的兴趣。
2. 它不是又一个只能换模型的聊天壳
很多所谓“开源 Agent 框架”实际上只开放了工具注册和模型接口，而 DSH 把可替换边界推得更深。按照官方架构文档，模型适配器、工具注册表、Session Log、Agent Loop 本身都属于插件。
DeepSeek 官方列出的可组合能力包括：模型、工具、Skills、会话、沙箱、存储、循环、调度、UI 等。
换句话说，你不是在一个固定 Agent 上装几个插件，而是连“这个 Agent 到底由什么组成”本身都可以重配。
3. 一条命令就能看到完整 Web UI
DeepSeek 没有把“高度可扩展”做成“必须先读半天文档”。安装 Node.js 后只需要：
npx @deepseek-ai/dsh web随后就在本机启动 Web UI。对于一个偏底层的 Agent Harness 来说，这个体验门槛非常低。
4. “运行有迹可循”解决了 Agent 的另一个痛点
Agent 越自主，黑盒问题就越严重：它为什么执行这个命令？调用了什么工具？某个错误从哪一步开始？恢复会话后上下文是如何重建的？
DSH 的 Session 采用仅追加事件日志的思路。官方说明，模型看到的系统提示、工具调用与结果、子 Agent 调度、上下文注入等信息都会进入同一事件流；Trajectory 视图可以按来源检查执行过程，而恢复、分叉、检索和回放也建立在这份事件流之上。
5. 插件化不是口号，连 UI 都是插件
Cordis 内核本身主要负责插件挂载、卸载和依赖关系，而真正的 Agent 能力由插件提供。官方架构甚至明确强调：没有一个“必须修改的特权核心”，扩展 DSH 的主要方式是把插件挂到现有组合旁边。
这意味着插件不只是“加一个命令”，还可以提供新的模型 Provider、Shell 后端、沙箱、长期状态、Agent preset、后台任务、上下文注入、会话 UI，甚至替换某些既有能力。
6. 它天然容易长出生态
一个项目真正形成生态，需要三个条件：可扩展、扩展边界稳定、安装和发现成本足够低。DSH 目前第三点进展非常快，官方鼓励第三方插件仓库使用 dsh-plugin topic，社区已经出现插件市场、桌面壳、UI 增强、记忆、视觉、工作流以及 Pi 生态兼容层。
当然，必须强调：现在还是开发者预览期，生态繁荣不代表 API 已经稳定。官方 README 明确警告未来会出现破坏兼容性的变更。
DSH 的核心设计：Cordis + “一切皆插件”
如果只是把 DeepSeek Harness 当成一个可以聊天、写代码的 Web UI，会低估它。
真正值得研究的是 Cordis。
在 DSH 中，一个正在运行的 Harness 本质上是一棵插件树。不同 Profile 由多个 Bundle 叠加组成，再通过配置 Patch 覆盖具体服务。官方提供 web 和 headless 等组合方式。
核心能力被拆成独立服务，例如：
- Session：维护追加式事件日志和会话状态；
- System Prompt：组装系统提示和工具 Schema；
- Tools：工具注册与受控执行；
- Agent：Agent 注册和生命周期；
- Agent Loop：默认执行循环；
- LLM：模型请求、流式输出以及 Provider 适配。
这套设计最大的价值不是“插件数量多”，而是不同能力的所有权和生命周期足够明确。插件卸载时，其注册产生的 effect 可以跟着撤销；事件与服务又能让不同插件协作，而不是全部耦合进一个巨大的 Agent 类。
四种运行模式分别适合什么场景？
标准模式 Standard
这是普通用户最应该先用的模式，提供文件编辑、Shell、文件和网页检索、Skills、Plan、Goal、子 Agent 和工作流等完整能力。
PTC / Code Mode
在标准能力之上，把工具通过 Code Mode SDK 暴露给模型，让模型用一段 TypeScript 程序组合多步操作。对于重复、批量、需要多次工具调用的任务，它可以把多轮“模型—工具—模型”交互压缩成一次更结构化的程序执行。
极简模式 Minimal
只保留持久 Bash 与 str_replace_editor 两个工具，更接近最小 Harness，适合做模型能力测试、Benchmark 或研究“究竟是模型强，还是 Harness 帮得多”。
创造模式 Creator
这是 DSH 很有辨识度的一部分：Agent 可以检查当前运行时、试验 Cordis 插件并帮助你组合新的 Agent preset。换句话说，它不仅是一个 Agent，也提供了让 Agent 参与构造 Harness 本身的实验场。
它和 Pi Agent 到底是什么关系？
回到文章开头那个评论区的问题。
“DSH 是基于 Pi Agent 做的”——这个说法不准确。
Pi Agent 自身也是一个强调轻量、扩展和多 Provider 的 Agent Harness，包含 pi-agent-core、pi-ai、Coding Agent CLI 和 TUI 等组件。DSH 则把可组合边界进一步细分成大量 Cordis service/provider。
但两者确实存在非常真实的连接：
- DSH 官方仓库包含
@deepseek-ai/dsh-llm-pi-ai，它直接使用@earendil-works/pi-ai提供通用多 Provider 模型适配； - GitHub 社区里有人专门讨论“DeepSeek Harness 与 Pi 是否正在收敛到同一种架构哲学”；
- 社区项目
pi2dsh已经尝试把 Pi 的 tools、commands、prompts、skills、provider registry 和生命周期 hooks 映射到 DSH。
一位参与相关讨论的开发者总结得很到位：两者不是简单的谁比谁好，而是抽象层级不同。 Pi 的扩展 API 更直接、开发成本更低；DSH 把 tool、session、subprocess、credentials、LLM adapter、skill 等拆成更独立的服务，替换和组合空间更大，但插件开发也更复杂。
| 维度 | Pi Agent | DeepSeek Harness |
|---|---|---|
| 核心气质 | 轻量、自扩展、开发者友好 | 微内核式、极致组合、Harness 基础设施化 |
| 扩展方式 | Extensions / Tools / Commands / Hooks | Cordis Service / Provider / Event / Plugin |
| 模型层 | pi-ai 多 Provider | DeepSeek 原生适配 + llm-pi-ai + 自定义适配 |
| 权限与沙箱 | 官方说明默认没有内建文件/进程/网络权限系统，建议外部容器化 | 基础 Bundle 中包含 sandbox、approval、permission policy 等能力 |
| 学习成本 | 更低 | 更高，但可替换边界更细 |
和 Claude Code、Codex、OpenCode 相比，它强在哪里？
这里最容易犯的错误，是把这些产品放到同一条 Benchmark 排行榜里，然后问“谁最强”。
事实上，它们的产品目标并不完全相同。
| 项目 | 更像什么 | 主要优势 | DSH 相比之下 |
|---|---|---|---|
| Claude Code | 成熟的 Agentic Coding 产品 | Claude 深度整合、终端/IDE/桌面/浏览器、工程体验成熟 | DSH 更开放、更适合改造 Harness 本身，但成熟度明显更低 |
| OpenAI Codex | OpenAI 的本地/云端编程 Agent 体系 | 终端、IDE、App、ChatGPT 账户体系整合，CLI 开源 | DSH 不绑定单一模型生态，插件边界更深入 |
| OpenCode | 成熟的开源、多 Provider Coding Agent | TUI/桌面/IDE、多模型、LSP、并行 Session，生态成熟 | DSH 更像“造 Agent 的底座”，而不仅是一个 Coding Agent 产品 |
| Pi Agent | 轻量、可扩展 Agent Toolkit | API 简洁、核心小、多 Provider、扩展开发方便 | DSH 服务边界更细、更强调运行时组合和可追踪性 |
所以，DSH 当前最强的竞争力并不是“同一个模型下写代码一定比 Claude Code 或 Codex 更快”。事实上，官方的 BENCHMARK.md 目前主要告诉开发者如何用 Python SDK 跑自己的基准，并没有发布一张“DSH 全面击败竞品”的官方分数表。
它真正不同的地方是：
如果 Claude Code、Codex、OpenCode 更像已经造好的高性能汽车，那么 DeepSeek Harness 更像是把底盘、发动机接口、电控系统和仪表盘都模块化之后，交给开发者重新组车。
模型并没有被锁死：DeepSeek 只是默认选项
虽然名字叫 DeepSeek Harness，但它并不是“只能用 DeepSeek 模型”。
官方有直接的 DeepSeek Adapter，同时提供基于 pi-ai 的通用 Provider Adapter。通过配置可以接入不同模型目录、自定义 OpenAI-compatible 网关以及新的 Provider。
这件事对 Harness 很关键。因为模型更新速度远高于普通软件框架，如果底层和单个模型 API 强绑定，Harness 很快会过时；把模型层做成 Service/Adapter，才有可能长期存在。
不仅有 Web UI：它还可以 Headless、Python SDK、JSON-RPC、ACP 和 MCP
官方仓库已经提供多个可运行示例：
- headless-agent：无交互界面执行一次任务，输出机器可读或人类可读结果；
- jsonrpc-agent：通过 Python SDK 和 JSON-RPC 驱动无人值守 Agent；
- ACP Agent：通过 Agent Client Protocol 暴露自动化服务，包含 Session、权限和取消支持；
- MCP memory：通过通用 MCP Client 接入第三方记忆服务；
- web-cordis：让 Agent 检查并修改当前内存中的 Cordis 插件树。
这说明 DSH 的目标并不是停留在一个 Web App，而是成为可以嵌入其他产品、自动化系统和 Agent 平台的运行时。
怎么安装？建议先走官方最短路径
网上已经出现了不少把 Homebrew、Node.js、后台运行和自动打开浏览器拼成一条命令的教程。比如 Tricontinental 的图文教程 对 Mac、Windows、模型配置、权限和插件都有非常细的截图，第一次接触的用户可以参考。
不过如果你已经具备基本开发环境，我更建议先用官方最简单的流程。
第一步：安装 Node.js
macOS 可以使用 Homebrew：
brew install nodeWindows 可以安装 Node.js LTS，Linux 则使用自己发行版的包管理器或 Node Version Manager。
第二步：启动 DSH
npx @deepseek-ai/dsh web默认会启动：
http://127.0.0.1:3080第三步：配置模型
打开 Settings → Models，填入 DeepSeek API Key 即可直接启用对应模型。官方用户指南明确说明：保存后模型路由会立即可用，不需要重启服务。
如果你使用其他 Provider，也可以新增相应模型配置或 OpenAI-compatible endpoint。
第四步：选择 Workspace
新 Web UI 默认还没有工作区。点击 Choose workspace，选择你希望 Agent 操作的项目目录。未选择 Workspace 时，Session 输入框不会进入正常工作状态。
第五步：先从 Workspace Write 权限开始
如果只是体验，不建议第一上来就给 Full Access。让 Agent 先限制在一个测试项目目录内，观察它的工具调用和执行轨迹，再逐步放开权限。
一个很适合作为首个任务的 Prompt 是：
请总结这个代码仓库的结构、主要 package、运行入口和最值得注意的设计，并给出一份不修改文件的分析报告。等你确认它能正确读取项目后，再让它执行修改、测试和 Git 相关操作。
从源码运行
如果你真正想研究 Harness，而不只是使用它，建议直接拉源码：
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web官方还提供：
dsh --profile web --dump-config用来查看本机实际启动的 Cordis 插件树。对于想开发插件、替换模型适配器、研究 Session 或 Agent Loop 的人，这比只看 UI 更有价值。
哪些人现在最值得试？
- Agent / AI 工具开发者：想研究模型之外 Harness 层如何设计；
- 做 AI SaaS 或开发者工具的人：需要一个可嵌入、可换模型、可自定义权限和 UI 的运行时；
- Pi Agent 用户：喜欢小核心、扩展式架构，但希望进一步探索更细粒度服务组合；
- 插件作者：希望围绕 Agent UI、记忆、工作流、沙箱、工具、Provider 做生态产品；
- 研究 Agent 可观测性的人：对事件日志、Trajectory、Session replay / fork 感兴趣。
哪些人暂时不适合把它当主力？
如果你的唯一需求是“今天就要一个成熟、稳定、少折腾的 AI 编程助手”，DSH 未必是当前最优解。
官方已经明确把它标记为 Developer Preview，并直接警告会有兼容性破坏。对于普通用户，Claude Code、Codex、OpenCode 这类产品化程度更高的工具可能更省时间。
另外，插件化越彻底，供应链和权限边界越值得警惕。社区已经出现针对早期 RC 版本的安全审计讨论。无论具体问题后来是否已经修复，原则都不会变：
- 不要在未审计插件上直接开放 Full Access；
- 不要在包含生产凭据和敏感资料的目录里首次测试；
- 第三方插件先看源码、维护者、依赖和权限；
- 开发者预览版本不建议直接充当关键生产基础设施。
我认为 DeepSeek Harness 真正有价值的地方
18 万 Star 很容易把讨论带向“又一个爆款 GitHub 项目”，但我认为真正值得关注的是另外一个变化。
过去两年，我们一直在讨论哪一个模型更强；现在行业开始越来越认真地讨论：同一个模型，被放进什么 Harness，最终可能表现成完全不同的 Agent。
System Prompt 怎么组织、工具如何暴露、上下文何时压缩、权限怎样审批、子 Agent 如何调度、执行失败如何恢复、Session 能否重放——这些“模型外”的东西，正在成为 Agent 产品真正的工程护城河。
DeepSeek Harness 的意义，是把这层工程从一个公司内部的“隐形魔法”变成了可以研究、替换和重新组合的开源对象。
它现在还不稳定，甚至因为过度模块化而显得比 Pi Agent、OpenCode 更复杂；但也正因为这种复杂度，它可能更适合那些不是只想“使用一个 Agent”，而是想构造自己的 Agent 系统的人。
如果 Pi Agent 的魅力是“保持简单，让 Agent 自己生长”，那么 DeepSeek Harness 更像是在追问：能不能把 Agent 的每一块骨架都做成可插拔零件？
发布十天左右就冲进 GitHub 18 万 Star，只能证明大家对这个问题极其感兴趣。真正决定 DSH 能不能从爆款项目变成长期基础设施的，仍然是接下来几个月的 API 稳定性、安全边界、插件质量、跨版本兼容和真实生产案例。
但至少从架构方向看，它已经是 2026 年最值得 Agent 开发者认真研究的新项目之一。
评论