DeepSeek Harness 装哪个 Bot 插件?90% 的人第一步就选错了
DeepSeek Harness 生态中 DS Bot 和 dsh-agent-teams 两个多 Agent 插件思路迥异:前者以群聊方式常驻多 Bot,强调持久记忆与自然对话;后者以 Captain 为核心进行任务拆解与依赖调度,内置质量门禁与 Web UI 监控。二者在协作模式、任务管理、Token 消耗及目标漂移风险上存在本质差异,需按场景选择。
DS Bot:群聊里的常驻团队

DS Bot 的核心思路是「把 Bot 当成群里的成员」。
装完插件后,你可以在 DSH 里创建一组长期存在的 Bot——比如 Chief(总管)、Coder(程序员)、Writer(写手)。它们有自己的运行状态、上下文和记忆,不用每次重新创建。
其中 Main Bot 相当于总管家,你可以直接说:
"给我建一个写手和一个程序员,再拉个群。"
它会帮你创建 Bot、配置角色,再组一个群聊。群聊里设一个管理员 Bot,由管理员决定什么时候调用谁,避免所有 Bot 同时回复把 Token 烧飞。你也可以直接 @ 某个 Bot 对话。

常驻 Bot 群聊协作 持久记忆 模型解耦 Apache 2.0
dsh-agent-teams:项目经理式调度

dsh-agent-teams 的思路完全不同——它是「用 Captain 带一队 Agent 做项目」。
你给出一个目标,Captain(队长)自动拆解任务、分配给不同的 Member Agent,按依赖关系调度执行。每个任务经过分析 → 实现 → 验证三道质量门禁,不是直接一步到位。
它还提供了一个实时 Web UI 仪表盘,可以在浏览器里监控各 Agent 的进度、手动干预任务执行。
适合场景:「帮我重构这个模块,先做分析,再写代码,最后跑测试验证。」
支持任务依赖图、并行执行、失败自动重试、YAML 配置 profiles,更像一个工程项目管理工具。
Captain 调度 依赖图调度 质量门禁 Web UI 监控 自动重试

核心差异一览
| 维度 | DS Bot | dsh-agent-teams |
|---|---|---|
| 协作模式 | 群聊式,多 Bot 常驻 | Captain 调度,任务驱动 |
| 任务管理 | 无显式任务图 | 依赖图 + 并行调度 |
| 质量保障 | 无明确机制 | 分析→实现→验证 门禁 |
| 监控方式 | 群聊界面 | 独立 Web UI 仪表盘 |
| 交互风格 | 自然对话 + @指定 | 斜杠命令 + 自然语言 |
| 模型支持 | 自定义 API Key + 订阅复用(规划中) | YAML 配置多模型 |
| 成熟度 | v0.1 Preview | v0.1.23,迭代较多 |
| 开源协议 | Apache 2.0 | 开源 |
Token 消耗:钱袋子问题
💰 DS Bot:可控的持续消耗
群聊模式下,由管理员 Bot 路由消息,不会所有 Bot 同时回复。你 @ 谁才谁响应,Token 消耗相对可控。但因为是常驻 Bot,长期跑会有持续消耗。
🔥 dsh-agent-teams:集中爆发式消耗
多 Agent 并行执行 + 分析/实现/验证三道门禁,一个任务可能跑 3-5 轮 Agent 调用。复杂任务跑一次,Token 消耗可能是 DS Bot 的数倍。但好处是任务完成后就结束,不会持续占用。
省钱建议:日常轻量协作选 DS Bot;复杂项目用 dsh-agent-teams,但建议配置便宜模型跑子任务,只在 Captain 用贵模型做决策。
警惕:目标偏移的扩大性
多 Agent 协作有个共性问题:任务链越长,目标越容易漂移。
你原本让 Agent 重构一个函数,结果它分析完说「这个模块架构有问题」,然后开始重构整个模块,最后可能把不相关的代码也改了——目标从「改函数」膨胀成「改架构」。
dsh-agent-teams 风险更高:Captain 拆解任务后,子 Agent 各自执行,如果某个 Agent 对目标理解有偏差,错误会沿着依赖链放大。
DS Bot 相对可控:群聊模式下你可以随时插话纠正,单轮对话为主,漂移了容易拉回来。
✅ 防漂移建议
- 明确边界:任务描述里写清楚「只改 X,不要动 Y」
- 分阶段验收:复杂任务拆成多步,每步确认后再继续
- 用 dsh-agent-teams 时:开启质量门禁的验证环节,让它自检是否偏离目标
按场景选插件
💬 场景一:日常内容创作 + 多角色协作
你需要一个 Bot 写初稿、一个 Bot 做审校、一个 Bot 出配图方案,平时在群里随时对话调整。选 DS Bot。群聊模式天然适合这种非结构化、高频交互的场景。
📋 场景二:软件工程项目开发
你要重构一个模块,需要先分析代码、再写实现、再跑测试,任务之间有严格依赖关系。选 dsh-agent-teams。依赖图调度 + 质量门禁能保证每一步都到位。
🤝 场景三:长期个人助理
你想要几个一直记得你偏好和上下文的 Bot,随时能聊、不用每次重复背景信息。选 DS Bot。持久记忆是它的核心优势。
📊 场景四:需要实时监控和干预的复杂任务
你同时跑多个并行任务,需要看进度面板、随时调整优先级、处理失败重试。选 dsh-agent-teams。Web UI 仪表盘让一切可视化。
🤔 场景五:两个都想要?
不冲突。DS Bot 走的是 DSH 插件系统的 "持久化 Bot" 路线,dsh-agent-teams 走的是 "任务编排" 路线。理论上可以同时安装——日常用 DS Bot 群聊,遇到复杂项目用 dsh-agent-teams 拉团队。
怎么装?
DS Bot 安装
# DSH Desktop 插件页搜索 "ds-bot"
# 或 Web 版:npx @deepseek-ai/dsh@0.2.1-alpha.1 plugin --profile web add ds-botdsh-agent-teams 安装
# npm 安装
npm i @nanmicoder/dsh-agent-teams@0.1.23
# 或从 GitHub 源码安装
dsh plugin add NanmiCoder/dsh-agent-teams一句话总结
DS Bot = 在 DSH 里养一支常驻聊天团队,适合内容创作、个人助理、轻量协作。
dsh-agent-teams = 用项目经理模式调度 AI 干活,适合软件开发、复杂任务编排、需要质量保障的场景。
JOTO 企业落地观察
- 企业若计划将多 Agent 协作纳入研发流程,需明确区分「对话型协作」与「工程型编排」两类需求,避免因混淆使用导致交付失控。
- DS Bot 的常驻 Bot 设计对 RAG 知识工程提出新要求:每个 Bot 需绑定独立知识域与权限边界,否则群聊中易出现跨域信息泄露或指令误响应。
- dsh-agent-teams 的依赖图与质量门禁机制,为企业构建可审计的 AI 工作流提供了基础结构,但需配套定义各环节的验证标准与人工介入阈值。
- 两类插件均未内置企业级安全治理能力(如输出过滤、敏感词拦截、操作留痕),实际部署前必须叠加统一 AI 安全网关层。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


