DSH 默认的心智模型是「一个会话一个助手」。DS-Bot 换了一种形状：装完之后你面对的不是更长的对话框，而是一支常驻小队——一个主 bot、若干专职 bot，以及把它们凑到一起的群聊。仓库是 Fei2411/DS-Bot，站内归「对话 / 记忆」，Apache-2.0，2026-10-07 建仓，到写这篇时 GitHub 实时 5,096 星（站内快照 5,084），最近一次提交 2026-11-02。
多智能体这个词被用得太泛，通常指「让一个模型假装开几个会」。这里不一样：每个 bot 有自己的模型、记忆、用量页，通信发生在群聊里，你看得见。所以这篇不列功能，只回答一个问题——这么多能动的东西，靠什么被约束住。
权限的形状：Chief 是唯一能改结构的角色
默认主 bot 叫 Chief。作者给它的定位是一句很朴素的话——「有问题，找 main bot」。这句话背后是一条结构性规则：只有 Chief 能管理其他 bot 与群聊。普通 bot 能干活、能派活、能在群里说话，但不能增删成员，也不能改群的配置。
主 bot 不是「更聪明的 bot」
Chief 的特别之处不在模型，而在它站的位置。你可以给它换模型，也可以收窄工具集，它的权限不来自能力清单，来自那个管理位。
于是有一个常见的误配：为了让 Chief 表现更好，把一堆 MCP 和技能都塞给它，结果它既当调度又当执行，群里所有活都要从它身上过一遍。更稳的做法是让它保持得相对轻，主要做分派与汇总。作者还有一条相关提示：一个 bot 长期用一个模型，只在必要时切换——频繁换模型会让行为边界变模糊。
管理员是群聊里的调度位
群聊必须设一个管理员。你不 @ 任何人的时候，消息默认由管理员接，由它决定调谁。这是围绕成本做的取舍：如果每条消息都触发全员，账单会很难看。
管理员和 Chief 不是同一个概念。Chief 管「有哪些 bot、有哪些群」，管理员管「这条消息谁来接」。同一个 bot 可以两样都占，但两个角色压在同一个身上，群的行为更难预测——它既决定谁干活，又是干活的人。
@ 派活的执行链
你在群里 @ 某个 bot，它接活，自己做，在群里同步进度，做完把结果发回群里，再由派活的那个 bot 接着回应你。链是闭合的：谁派的活，谁负责收尾。
一次点名多人会发生什么
v0.2.5 改了这里的行为。一条消息里 @ 多个成员，会同时启动所有被点名的人，发起呼叫的 bot 会等它们全部完成再往下走。另一个细节：只回一句「收到」的成员，会被直接继续调用工具——「收到」不算交付，系统不会把它当成任务结束。
所以群里的一次多人点名，等价于一次并行扇出。写指令要按这个前提写：交付物、边界、输出位置都说清楚，否则会出现几个 bot 同时改同一件事。
为什么并行任务给了其他 bot，而不是子代理
这是 v0.2.5 里信息量最大的一条变更：bot 把并行任务交给其他 bot，不再启动 DSH 子代理。
子代理是进程内的，你看不见它在做什么，也插不上话。交给另一个 bot 之后，这件事变成群里的一条可见消息流——谁在做、做到哪、卡在哪，都在同一个视野里。代价是更多 token，收益是可观测，作者显然认为后者更值。
群聊记忆是独立的一层
群聊有自己的记忆，群里交代的事留在群里，群外的 bot 与你的私人对话看不到。
它不是一个共享上下文，而是有边界的会话空间：群里的话不会漏进某个 bot 的私聊，私聊里的事也不会变成公共知识。想让信息跨过去，得显式说一次。
隐私 Bot 划出的可见性边界
v0.2.4 加了隐私 Bot：一个 bot 可以被标记为私有，其他 bot 读不到它的文件夹、记忆和聊天，要分享得你批准。
这是整套编排里唯一的硬隔离：群内记忆隔的是会话，隐私 Bot 隔的是存储。两层叠起来，一个群里才能同时放「可以互看的同事」和「不该被看见的东西」。群组详情页还有一键停止群内所有工作的按钮，是扇出过大时的止损阀。
能力不是装上就生效
「设置 → 能力」是团队共享的 MCP 服务、技能与能力包列表。在某个 bot 的设置里启用后，从该 bot 的下一条消息开始生效，也包括它参与的群聊。不是立刻，是下一条——这个时间差在调试时很容易被误判成「没生效」。
本地 MCP 命令的批准链路
bot 自己添加的本地 MCP 命令，需要你先批准才能运行。这条规则的意义是：能力清单共享，但「这台机器上到底跑什么命令」的点头权在你手上。
有别人在用的能力，改动权收敛
如果某个能力正在被别的 bot 使用，只有你或主 bot 能改、能删。这条防的是并行编辑：A bot 删掉 B bot 依赖的技能，B 会在下次调用时莫名失败，而失败点离原因很远。
安全扫描的结论也该摆在明面上：站内标记为「含敏感能力」，可执行外部命令、读写与删除本地文件、发起外部网络请求，尚无人工评估。作者也写明：bot 会消耗你自己的模型额度，也会按你的要求读写文件、运行命令。
成本是被设计进来的
作者在文档里写了警告：群聊「会带来非常明显的费用问题」。这是设计约束——管理员统一调度、默认不扇出、把并行任务摊在可见的群消息里，都围绕它做的取舍。成本大致来自三层：每个 bot 的常驻上下文、每次扇出被点名的成员数、以及「收到」这类空转。第三层最容易忽略，它在界面上只显示为一句话。
约束住这套系统的四样东西
回到开头的问题。撑住这套编排的不是某个功能，是四条规则叠在一起：角色收敛，管理权只在 Chief，调度权只在管理员；链式派活，谁派的活谁收尾，过程在群里可见；记忆分层，群聊、私聊、隐私 bot 各自独立；能力审批，共享清单加人工批准，改动权向主 bot 收敛。这四条都不新，少见的是它们同时被写进了一个能跑的实现。
版本上留意一处错位：站内快照是 0.2.5，npm 上 latest 是 0.2.6（2026-11-02 发布）。本站的实装验证在 dsh 0.2.1-rc.2 下做，针对插件 v0.2.3。站内综合分 71.1 / 100，npm 周下载 11,765，该数包含 CI 与镜像，不等于本站安装数。
总结
DS-Bot 的价值不在「能开很多 bot」，而在它把多 bot 的权限、派活、记忆与审批都落成了可观察的规则。想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单，那里按分类列了安装形态。
适合与不适合
适合：长期并行的多角色协作（写作、调研、校对各一个 bot）、要在群里让多个 bot 并行处理同一批任务、需要把某些工作单元的记忆与文件对其他 bot 隐藏、已经习惯看用量页并愿意为 token 付费。
不适合：只想一个人对着一个助手聊天、对成本敏感且不接受明显上浮、需要跨 bot 共享同一份上下文却不想手动转述、跑在 DSH Web 上又要求 bot 从头生成 Office 文件。
标签：DS Bot、DeepSeek Harness、多智能体协作、群聊、编排模型
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。