前言¶
DeepSeek Harness（简称 dsh）是 DeepSeek 开源的 Agent 运行时。官方仓库把架构写成 Everything is a Plugin：模型、工具、会话、界面都以 Cordis 插件的形式组合。仓库目前仍标 developer preview，兼容性可能随时变。社区里已经有若干独立站点在收录带 dsh-plugin topic 的仓库；本文依据的 DeepSeek Harness 插件库 是其中之一，和 DeepSeek / 幻方没有官方从属关系，不要把它当成官方应用商店。
在这种架构里，一次「深度调研」如果只靠对话里堆提示词，很容易变成固定流水线：拆问题、搜一圈、写报告、收工。主题简单还好；主题一复杂，不是搜不够，就是搜到停不下来。dsh-deep-research 把这件事做成扩展插件：挂在官方 workflow 引擎上，按控制论和信息论的思路跑自适应研究闭环。本文按目录详情页、GitHub README 和仓库源码交叉核对后整理。
这是什么¶
dsh-deep-research 是一款工作流与自动化插件，由 GitHub 组织 omdsh-dev 维护。npm 包名是 @dsh-external/dsh-deep-research，仓库在 omdsh-dev/dsh-deep-research，许可证 MIT（版权声明为 2026 dsh2026）。目录页 2026-08-11 收录，主要语言 TypeScript，package.json 里的版本是 0.1.0。GitHub 在 2026-08-17 显示 14 stars；同一天社区目录页仍写 11 stars，星标以仓库页面为准。
它和 skill 体系是分开的：不注册进 ctx.skills，而是向模型暴露一个工具 deep_research。触发靠工具描述里的场景词（深度研究、调研、多源信息综合分析、研究报告、文献搜集），对话里直接说人话即可。编排走官方 workflow 引擎（ctx.workflows / @deepseek-ai/dsh-workflow-workerthread），搜索和抓取继续用内置的 web_search / web_fetch。README 的原话是：插件零网络逻辑、零自研编排。
GitHub 上还有名称相近的 dsh-deepresearch（少一个连字符），那是另一个项目，安装时不要混用。
核心功能¶
仓库 README 把设计写成「不是固定提示词流水线，而是活的、自适应的研究闭环」。源码 src/index.ts 里的 workflow 脚本按阶段执行，和文档一致。
规划：先定答案空间，再拆子问题¶
规划子代理不会一上来就搜。它先写 scope（这份研究要支撑什么判断或决策），再枚举信息维度，把每个子问题映射到一个维度，并给出验收标准 acceptance。覆盖不到的维度写进 coverage_gaps，作为待验证的盲区假设，而不是悄悄丢掉。
控制论里的说法是参考信号校准：目标设错了，后面闭环再勤奋也是白费。必要多样性定律对应的是：子问题集合覆盖不住主题空间，后面一定有盲区。
如果调用时已经传入 questions（每行一个，或 1. 2. 3. 编号），规划阶段会跳过，直接并行研究。
研究：按边际信息增益停下来¶
研究子代理维护三态证据：confirmed / uncertain / gaps。每一轮的动作是：针对高不确定性的点预测能新增什么 → 用 web_search / web_fetch 取证 → 更新证据 → 做边际增益验证。连续一轮没有新增，子代理自己停；整次运行还有轮次硬上限。
研究阶段是闭环再规划，不是一次扇出：
- 第 1 轮并行研究全部子问题（以及规划声明的盲区侦察）。
- 每轮结束收集 high-priority 缺口，自动派发下一轮补充研究。
- 简单主题一轮收敛，复杂主题自动扩展，直到某一轮边际增益约为 0，或达到轮次上限。
轮次上限由 depth 决定：1 初步最多 2 轮，2 深入（默认）最多 3 轮，3 穷尽最多 4 轮。源码里写成 depth + 1，且 depth 只能是 1、2、3。
每轮并发默认 maxParallel = 4。超出并发上限的子问题留在队列里后续处理，不会静默丢弃。
综合与可选审查¶
综合子代理默认开启（synthesize: true）。它按率失真的思路把证据压缩成最终报告：只保留对结论有区分度的信息，并保留置信度、矛盾和已验证盲区。synthesize: false 时只返回各子问题的三态证据，由主代理自己写报告。
review: true 时额外跑对抗性审查子代理：抽查引用（URL 可达性 / 是否真能支撑论断）、做覆盖度审计、标注矛盾和过度自信。默认关闭。
和官方引擎绑在一起的部分¶
源码把插件声明为 inject: ['tools', 'workflows']，工具执行时调用 ctx.workflows.start()。因此它会复用官方引擎已有的能力：worker 隔离、并发和总数上限、取消、进度事件、wf-runs 记录。exec.signal 会传入 workflow run，取消时子代理随之中止。单个子问题研究失败只在该节标注；规划失败则整个工具报错，主代理可以调参重试。
插件不碰 TUI：没有 tuiPrompt、overlay 或 system-prompt 注入。README 还保留了一份技能模板 .claude/skills/deep-research，和这个插件互相独立。
安装与启用¶
目录详情页给出的安装命令是：
dsh plugin add github:omdsh-dev/dsh-deep-research
需要可复现安装时，按目录页的写法固定 commit 哈希：
dsh plugin add github:omdsh-dev/dsh-deep-research#<commit>
把 <commit> 换成仓库里实际审核过的提交哈希，不要留占位符。
README 补充了按 profile 安装的写法。包声明了 dsh.bundle.patch（cordis.patch.yml），可以装进 tui / headless / web 或自建 profile；装完后重启对应 profile，工具 deep_research 才会注入：
dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-deep-research.git
dsh --profile <profile>
这里有一处需要对照仓库现状：README 仍写 GitHub 组织 dsh-external，当前访问 dsh-external/dsh-deep-research 会跳转到 omdsh-dev/dsh-deep-research，二者是同一仓库。安装时优先用目录页上的 github:omdsh-dev/dsh-deep-research。若本机 git 把 https 重写成 ssh（全局 insteadOf），README 建议改用上面的 git+https:// 形式。dsh plugin 提示需要 allowBuilds 时，按提示在 $DSH_HOME/profiles/<profile>/pnpm-workspace.yaml 加一行即可。
卸载用包名，不是仓库名：
dsh plugin --profile <profile> remove @dsh-external/dsh-deep-research
依赖方面：profile 的组合需要包含官方 workflow 引擎和内置 web 工具。README 写明 dsh 官方 base 组合自带，不必额外安装；peer 依赖（@deepseek-ai/dsh-tools、@deepseek-ai/dsh-workflow、cordis）由组合提供。package.json 要求 Node ^22.19.0 || >=24.0.0。
Profile 兼容性：请装进提供 workflows provider 的组合（README 举例 tui / headless）。部分 Web Profile 如果未声明该 provider，Loader 会保持 pending，需要先在 DSH Hub 登记关系，或改用提供该服务的组合。
典型用法¶
工具由模型按描述自动调用。下面几句来自仓库 README，可以按原样说：
深度调研一下 MCP 生态现状，重点对比几家主流实现，出一份带引用的报告
按这份问题清单做研究：1. ... 2. ...
已有清单时会跳过自动拆解，直接并行研究。
调研一下 A/B 方案，purpose 是决定我们选哪个
用途写得越清楚，规划阶段的答案空间越准。复杂主题会自动加轮次；想更严可以传 depth: 3，要引用纠错和覆盖度审计就传 review: true。
工具参数（以 README 和 src/index.ts 为准）：
| 参数 | 必填 | 说明 |
|---|---|---|
topic |
是 | 研究主题 |
purpose |
否 | 要支撑的判断或决策；缺省时规划代理会声明假设用途 |
questions |
否 | 已有问题清单；提供则跳过自动拆解 |
depth |
否 | 1 初步 / 2 深入（默认） / 3 穷尽 |
synthesize |
否 | 是否出最终报告，默认 true |
review |
否 | 对抗性审查，默认 false |
可选配置（装进 profile 后按插件配置填写，全部可省略）：
| Key | 默认 | 说明 |
|---|---|---|
subagentProvider |
引擎默认 spawn |
子代理 provider |
maxParallel |
4 |
每轮研究并发上限 |
maxTotalAgents |
引擎上限 | 整次运行子代理总数上限 |
plannerModel / researcherModel / synthesizerModel / reviewerModel |
继承父配置 | 按角色换模型 |
README 的成本建议是分层：规划、综合用强模型，研究用便宜模型。未配置的角色继承父路由。
适用场景与注意事项¶
比较适合这些情况：
- 需要多源交叉验证、带引用的调研报告，而不是单次搜索摘要
- 主题边界还不清楚，希望先定答案空间再拆维度
- 已经有问题清单，只想并行取证
- 愿意为严谨性打开
review，接受多一轮审查成本
需要先想清楚的限制：
- 插件以当前 dsh 进程的权限运行，安装时可能执行代码。目录页写明：安装前请检查源代码仓库和许可证；需要可复现安装时固定 commit 哈希。
- 它不是通用工作流引擎，只注册
deep_research这一个工具。 - 搜索能力完全依赖宿主内置的
web_search/web_fetch，插件自己不联网。 - 部分 Web Profile 缺 workflows provider 时不会真正加载。
- 深度研究必然消耗多轮子代理和检索；
depth: 3加上review: true会更贵。仓库建议用模型分层控制成本，本文没有独立评测数据。 - DeepSeek Harness 仍处于 developer preview，官方仓库声明会有破坏性变更。插件版本目前是
0.1.0，接口和 profile 组合都可能跟着宿主一起变。
小结¶
dsh-deep-research 做的事情很窄：把一次深度研究从「提示词流水线」换成挂在官方 workflow 引擎上的自适应闭环。规划先定答案空间，研究按信息增益停下来，综合保留不确定性，审查可选。社区目录和 GitHub 都能装，优先用目录页这条命令：
dsh plugin add github:omdsh-dev/dsh-deep-research
目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-deep-research/
GitHub：https://github.com/omdsh-dev/dsh-deep-research
