跳到主要内容
dsh marketplace

dsh-consult

已验证

dsh-consult · v0.1.0 · MIT

Explicit, evidence-first multi-model consultation for DeepSeek Harness

安装

dsh plugin add dsh-consult

用 dsh --profile default --dump-config 确认 layer 已生效 —— 参见安装指南。

源码

标签

作者

说明文档

dsh-consult

npm 版本 CI 许可证

English · 简体中文

关键决策，多听几种真正不同的声音。

dsh-consult 是为 DeepSeek Harness 打造的多模型“专家会诊”插件，在主 Agent 真正需要判断的时刻，为它组织一场有边界的委员会咨询。

/consult 先完成实现和测试，再请多个独立模型评审这个方案是否适合发布。

主 Agent 仍然负责探索 workspace、修改代码和运行验证；到了决策关口，插件把同一份证据、同一个问题， 同时交给 2–5 个由你配置的模型。主 Agent 最后综合匿名意见，并对交付结论负责。

不是更多人干活，而是更多人帮助判断

很多 subagent 或 agent team 的工作方式，可以类比为同一个人戴上不同的帽子：一个关注架构， 一个检查测试，一个负责实现。它们从不同角度拆解任务，擅长扩大探索范围和执行吞吐。

dsh-consult 采用另一种思路：不同的人，看同一份材料，站在同一个决策关口，回答同一个问题。 顾问之间不分工、不共享讨论过程，也不互相说服；我们要保留的，正是不同模型独立判断后产生的差异。

Agent team / subagent dsh-consult
主要解决 怎么把工作并行做完 这个判断是否可靠
组织方式 不同角色、不同子任务 不同模型、同一问题
上下文 各取所需，持续探索 同一份精选证据包
工具权限 通常可以读写和执行 无工具、无 history、无 workspace 权限
最终产物 多份执行结果 多份独立意见，由主 Agent 综合
成本形态 随执行过程持续增长 只在显式咨询点产生

这并不是要替代 agent team，而是在区分两类问题：执行需要负责人，关键决策才需要委员会。 以现在的 Agent 能力，方向确定后，编码、修改、测试和验收通常可以由一个主 Agent 连贯完成； 如果把委员会也做成一组拥有工具、持续协作的 Agent，往往会额外支付上下文、工具调用和协调成本。 dsh-consult 因此只把多模型能力用在最有价值的地方——挑战判断，而不是重复劳动。

哪些时刻值得咨询？

  • 两种架构都说得通，但长期维护成本不同；
  • 安全、隐私或数据边界可能被忽略；
  • 改动已经完成，需要一次独立的发布前评审；
  • 失败模式复杂，单一模型可能对自己的方案过于自信；
  • 取舍涉及性能、复杂度、兼容性与用户体验，无法只靠一个指标决定；
  • 你想确认当前结论是否只是某个模型的偏好。

对于改文案、修明确的小 bug、执行已经确定的步骤等日常任务，通常没有必要咨询。咨询应当是一个 高价值、低频率、由用户决定的检查点，而不是每轮对话的默认开销。

一次咨询如何发生

flowchart LR
    U["用户指定咨询任务"] --> A[主 Agent 探索、实现、验证]
    A --> P[整理同一份证据与问题]
    P --> C1[模型 A 独立判断]
    P --> C2[模型 B 独立判断]
    P --> CN[模型 C–E 独立判断]
    C1 --> S[主 Agent 比较并综合]
    C2 --> S
    CN --> S
    S --> R[给出最终结论]

这条流程有几个刻意设置的边界：

  • 显式发起：只有用户输入 /consult <task> 才会创建咨询；
  • 先做功课：主 Agent 必须先完成必要的探索和验证，再准备证据；
  • 公平比较：每个顾问收到完全相同的 prompt 和 evidence packet；
  • 独立作答：顾问并行调用，不辩论、不投票，也看不到彼此的答案；
  • 匿名综合：主模型只看到 Consultant A/B/...，避免品牌和模型名称影响判断；
  • 主 Agent 负责：意见不是证明，最终取舍、执行和验收仍由主 Agent 完成；
  • 成本可控：顾问数量、模型、超时、输出长度和意见大小均由部署方限制。

快速开始

需要 Node.js >=22.19.0、一个兼容的 DeepSeek Harness 版本，以及至少两组已经在 DSH 中配置好的 模型服务（每组由 provider 和 model 共同确定）。

1. 安装

把 bundle 安装到你使用的 profile（通常是 web）：

dsh plugin --profile web add dsh-consult

如果你通过包执行器启动 DSH，也可以直接运行：

pnpm dlx @deepseek-ai/dsh plugin --profile web add dsh-consult

2. 选择顾问模型

插件安装后默认休眠，不会产生任何模型调用。在 ~/.dsh/profiles/web/cordis.patch.yml （或 DSH_HOME 下对应的 profile 文件）加入下面的最小配置：

- id: consult
  config:
    consultants:
      - provider: "<provider-id-a>"
        model: "<model-id-a>"
      - provider: "<provider-id-b>"
        model: "<model-id-b>"

请把 <...> 占位符替换成 DSH 中的实际 ID：provider-id 是模型服务的标识， model-id 是该服务下的模型标识。两个 provider-id 可以相同，例如可以从同一个模型服务选择 两个不同模型；真正不能重复的是完整的 provider + model 组合。上面是两位顾问的最小配置， 你也可以按相同格式继续添加，最多配置五位顾问。API key 仍由 DSH 的 settings 与 credentials 机制管理，dsh-consult 不读取也不保存密钥。其余选项均可省略，插件会使用默认值；需要调整时 再显式填写。完整配置见配置指南。

检查配置并启动：

dsh --profile web --dump-config
dsh web

3. 在关键节点发起咨询

/consult 评审当前缓存失效方案。先检查实现和测试，再判断是否适合发布。

主 Agent 会照常工作，并在证据准备好后调用一次 consult。仍处于等待状态的咨询可以用 /consult off 取消。

你仍然掌握控制权

  • 顾问来自你配置的 provider/model，可以为不同模型指定不同 reasoning effort；
  • 2–5 个顾问并行执行，总等待时间通常取决于最慢的 route，而不是所有耗时相加；
  • 所有顾问成功时结果为 complete，至少一份有效意见时为 partial；
  • provider、model、用量、耗时和原始失败仅写入 model-hidden 诊断事件；
  • 咨询状态与交付过程会持久化，恢复 session 时不会悄悄重复已经开始的外部调用；
  • Native Tool、Code Mode 和 ctx.consult.run(...) service API 均受同一套显式 intent 约束。

数据与安全边界

证据包会被完整发送给每一个已配置的顾问模型，同时写入 DSH session event log。 当前版本不会自动探测、裁剪或脱敏 secret。请求咨询前，请分别确认：

  1. 这些内容适合发送给所有顾问 provider；
  2. 这些内容适合随 session 日志在本地持久化、导出或备份。

顾问无法自行读取 workspace，也不能调用工具；证据帧会被标记为不可信数据。但这些隔离措施并不能 让原本不应外发的秘密变得安全。生产部署前请阅读安全与数据流指南。

已验证的兼容版本

DeepSeek Harness 仍处于 developer preview，RC 之间可能发生不兼容变化。因此本项目不笼统承诺 一个开放式预发布范围，而是明确列出并持续测试：

  • 0.1.0-rc.7
  • 0.1.0-rc.8
  • 0.1.1-rc.1
  • 0.1.1-rc.2

开发基线为 0.1.1-rc.2。CI 在 Node 22.19 上覆盖全部四个版本，并在 Node 24 上复测当前基线； 另有非阻塞任务监控 DSH next。通过 next 监控并不会自动扩大支持范围，详情见 兼容性说明。

进一步了解

文档 适合什么时候阅读
Configuration 配置顾问、超时、大小限制与 reasoning effort
Usage 了解 intent 生命周期、Code Mode 与 service API
Security 上线前检查外发、留存和信任边界
Architecture 理解 fan-out、匿名结果、事件结算与恢复
Compatibility 查看 Node/DSH 支持矩阵和验证方式
Releasing 维护者准备 npm 与 GitHub Release

深层技术文档目前以英文维护，避免两套实现说明随版本演进而产生偏差。

开发与贡献

pnpm install
pnpm check

测试使用真实 Cordis service composition、fake LLM adapter 与 fake Code Runtime bridge，不需要 任何模型凭据。pnpm verify:compat 会在临时环境中运行完整兼容矩阵，不改写当前 checkout。

欢迎阅读 CONTRIBUTING.md 参与贡献。安全问题请按照 SECURITY.md 私下报告。

dsh-consult 目前是面向快速演进中的 DSH developer preview 的早期公开版本。生产环境请固定 使用已验证的 DSH 版本，并在升级前阅读 CHANGELOG.md。

许可证

MIT