DSH 原本是个会话工具：开一个窗口，问一句，答一句，关掉就结束。Fei2411/DeepSeek-Bot（下称 DS Bot）干的事，是把这套会话模型改造成"成员模型"——每个 bot 有自己的窗口、自己的记忆、自己的模型选择，长期驻留，彼此还能互相派活。仓库 2,686 星，Apache-2.0，npm 包名 ds-bot，当前版本 0.1.7（2026-10-16 发布），站点已在 dsh 0.2.1-rc.2 下完成 L4 真实安装。
先说清楚身份：README 有明确免责声明，这是独立社区项目，不是 DeepSeek 官方产品，与 DeepSeek 没有隶属、认可或赞助关系。
一个 bot 一个窗口：会话边界就是成员边界
这是整套设计的第一块基石。在 DSH 里，一个会话就是一段工作上下文；DS Bot 把它抬成"一个人"。每个 bot 独占一个窗口，窗口里能换模型、管记忆、看自己的用量。
作者在 README 里给了个很像经验之谈的建议：一个 bot 长期用一个模型，确有需要再换。原因不难推——记忆、压缩摘要、历史上下文都绑在这个会话上，频繁换模型等于让同一个人不停换脑子，前后风格和判断标准都会漂。
这个选择的代价是上下文成本随 bot 数量线性增长；收益是每个 bot 的上下文不会被别人污染。群聊不是所有人共享一个大上下文，而是多个独立会话之间传消息。理解了这一点，后面所有行为都能推出来。
Chief：一个默认存在的高权限主 Bot
第一次打开 DS Bot，团队里已经有一个 bot，叫 Chief。它是主 Bot，权限很高：能管理其他 bot，能管理群聊，也能改任意 bot 或群的工作文件夹。README 的说法很直白——有问题，找 main bot。
这是个务实的设计：插件刚装完配置项一大堆，与其让你读文档，不如给你一个已经知道怎么配的 agent，说一句话它就把 bot 和群聊建起来。
代价同样真实：Chief 的高权限不是提示词层面的礼貌，而是能实际改动其他 bot 的存在与群的结构。所以第一件该想清楚的事，不是"怎么用 Chief"，而是"谁有权碰 Chief"。
群聊：admin 是调度层，@ 是直连
每个群有一个 admin。你发的消息默认由 admin 回复，它替你调用其他 bot。想绕过调度，直接 @ 某个 bot 即可，输入 @ 会弹出列表；想让某个 bot 参考另一段对话，点输入框的 + → 引用对话。
于是群聊里其实并存两种拓扑：星型（全部经过 admin）和网状（@ 直连、bot 之间再互相 @）。星型省心，代价是 admin 多一层转发开销；网状省 token，代价是链路难追踪。
v0.1.6 起，群聊还能开一套统一权限预设（只读 / 工作区 / 完全访问）压住所有成员，替代各成员自己的预设；开启期间群详情会显示该预设，关闭后成员恢复各自设置。这等于把"群"本身当成一个权限边界，而不是把权限散在成员身上。
交接：@ 出去，回帖回来
任何 bot 都能用 @ 把活交给另一个 bot。被交的 bot 独立完成，过程中向群里同步进度，做完回帖，发起方再接着回应。v0.1.7 把这条链做成了"会回来的交接"：只有全部结果都回来之后才回复发起方，并且回复里带上返回的内容。同一个 bot 可以在同一项工作里被多次调用——一个设计、一个构建、第三个审查、第一个验收。
想中断，打开群详情。
这里有个容易忽略的点：交接是有上限的，而且上限一直在动。v0.1.6 明确 bot 消息到 40 条后 message_bot 与 post_to_group 会失败并要求 bot 向你汇报；v0.1.7 又取消了六条转发链、10 条未读、群内三轮、40 条未读这一批限制，唯一还会被拒的是"发给正在等待当前工作结果的 bot"，因为结果会自动送到它那里。所以别把某个具体条数当永久约束。
v0.1.7 同时补了长消息处理：超过 20,000 字符的消息或群帖会以文件形式发出，聊天里折叠成前几行加"显示全部"。这不是美化，是必需品——否则一个 bot 的大段输出会把所有下游 bot 的上下文一起撑爆。
能力库：共享资源，但改动要过你
设置 → 能力 是团队共享的 MCP 服务器、skills 和 packs 列表。给某个 bot 启用后，从它的下一条消息起生效，私聊与群聊都算。
这里的两条规则值得单独拎出来：bot 添加的本地 MCP 命令要你先批准才能跑；有其他 bot 正在使用某个能力时，只有你或主 Bot 能修改、删除。
两条规则其实是同一个思路——能力的"加入"可以下放给 agent，能力的"变更"不行。因为加入只影响自己，变更会影响正在跑着的别人。
用量：三个切片回答三个问题
设置 → 用量 里能按时间、按 bot、按模型看 token 消耗。三个维度对应三种提问：按时间看趋势，按 bot 看谁在烧，按模型看成本结构。README 自己承认群聊"明显更贵"，原因不神秘——不是群聊这个功能贵，而是每个成员都在各自调用模型，一轮协作等于 N 次推理。
数据：都在 ~/.dsh 下的两个目录
所有数据留本机，在 DSH home（默认 ~/.dsh）的 bot/ 与 sessions/ 里。卸载插件不会删除这些数据。这是好事——团队不会因为一次误操作蒸发；也是坑——你以为卸干净了，硬盘上还躺着完整的工作记录。
v0.1.5 修过一个相关口径：DSH_HOME 为空或以 ~ 开头时，数据放在 dsh 所用文件夹的 bot/ 下；更早的版本放的是相对 dsh 启动目录的文件夹。想保留按旧口径建成的团队，要关掉 dsh 后手动把那个 bot/ 移过去。
它到底处在什么水平
站点给的标签是常驻智能体 / 智能体互发消息 / 群聊，归类在 chat，综合分 70.9。安全方面，自动扫描的结论是 🔵「含敏感能力」，共 87 处证据，覆盖执行外部命令、读写删除本地文件、写入剪贴板（不计风险）、发起外部网络请求；但尚无人工评估，站点也没有对这个插件做风险分级。这份扫描是能力清单，不是危险判定——它说明插件能碰到什么，不说明它可靠不可靠。
总结
DS Bot 的价值不在"多了一个聊天框"，而在于它把会话级工具重构成了成员级系统：窗口是边界，Chief 是引导兼管理员，群聊是调度层，@ 是交接协议，能力库是共享资源池，用量页是成本仪表。要判断这套结构是否值得为你的场景付费，可以先在站内的插件总览里看看同类插件的分布，再决定要不要引入一个常驻团队。
适合与不适合
适合：需要长期驻留、带记忆的固定角色，比如一个常年维护文档的写手；多角色串行协作的流程，比如设计 → 实现 → 审查；希望数据完全留在本机、不接受上云的团队；已经在用 DSH、想亲手摸一摸多 agent 协作边界的人。
不适合：只是偶尔问几句、用不上常驻成员的人；对 token 成本敏感、无法接受一轮群聊 N 次模型调用的场景；需要官方支持与 SLA 的生产环境——它是社区项目，不是 DeepSeek 官方产品。
标签：DS Bot、DeepSeek Harness、多智能体协作、常驻智能体、插件架构
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。