一天一个开源项目（第237篇）：DeepSeek Bot —— 把 DeepSeek Harness 变成一个有记忆、能群聊、会互相派活的 Bot 团队

引言

"DS Bot 把 DSH 变成一群 Bot——你创建自己的 Bot，然后和它们对话、一起工作。"

这是"一天一个开源项目"系列的第 237 篇。今天的项目是 DeepSeek Bot(简称 DS Bot)。

单个 AI 会话用久了会遇到一个共同的问题:上下文窗口会满,会话一关记忆就没了,想要专门负责某类任务的"专家"角色,只能每次重新建立上下文。更麻烦的是,如果想让多个"专家"协作完成一件复杂任务,目前大多数工具并没有提供现成的"多个长期存在的角色互相对话、互相派活"的机制。

DeepSeek Bot 作为 DeepSeek Harness(DSH)的插件,直接把这件事产品化:每个 Bot 本质上是一个独立的 DSH 会话,但拥有跨会话持久的记忆;多个 Bot 可以组成群聊协作,互相用 @ 提及派发任务;还有一个拥有管理权限的 Main Bot("Chief")负责统筹其他 Bot 和群聊,甚至能带着新用户走一遍配置流程。

1.9k Stars,Apache-2.0 协议,280 次提交。项目在致谢部分非常坦诚地列出了设计思路的多个灵感来源——包括 OpenAI Codex、OpenCode、Hermes Agent 等项目,明确说明是借鉴理念而非复制代码。

你将学到什么

• Bot / Main Bot / 群聊三层架构如何协作,解决"专家角色各自为战"的问题
• 跨会话持久记忆机制,以及它和临时上下文窗口的本质区别
• 群聊里的管理员 Bot 默认应答机制,以及 @ 提及如何绕过默认流程直接派活
• Capabilities 共享能力库:MCP 服务器、Skills、Packs 如何在多个 Bot 之间复用
• 项目如何坦诚致谢多个外部项目的设计理念借鉴,而不掩盖灵感来源

前置知识

• 了解 DeepSeek Harness(DSH)插件系统的基本概念
• 熟悉 AI Agent 会话(Session)的基本工作方式
• 可选:使用过群聊式协作工具(如 Slack Bot)会更容易理解群聊协作部分

---

项目背景

项目简介

DeepSeek Bot 的官方定位是:"DeepSeek Harness(DSH)的一个 Bot 插件。它把 DSH 变成 Bot——你创建自己的 Bot,然后和它们对话、一起工作。"仓库描述更直接:"面向 DeepSeek Harness 的一支长期存活 Bot 团队,支持 main bot、bot 之间消息传递和群聊。"

项目明确声明自己是独立社区项目:"DS Bot 是一个独立的社区项目。它不是 DeepSeek 的官方产品,也与 DeepSeek 没有隶属、认可或赞助关系。"

团队与项目信息

• 包名:ds-bot
• 协议:Apache License 2.0
• 当前状态:v0.1_preview,目标适配 DSH 0.2.0-rc.2
• 构建工具:esbuild(用于打包插件界面代码)
• 支持平台:DSH Desktop(Windows、macOS)、DSH Web(Windows、macOS、Linux,需 Node.js 22.19+ 和 pnpm)

项目数据

• ⭐ GitHub Stars:1,900+
• 🍴 Forks:180
• 👀 Watchers:7
• 🐛 Open Issues:45
• 🔀 Open PRs:3
• 📊 提交次数:280
• 📄 协议:Apache-2.0

---

主要功能

解决什么问题

单个 AI 会话长期使用的痛点：
  上下文窗口有限 → 会话越长越容易"遗忘"早期信息
  关闭会话 → 之前积累的偏好/习惯全部丢失
  想要多个"专家角色"协作 → 没有现成机制让它们互相对话、派活

DeepSeek Bot 的做法：
  每个 Bot = 一个独立 DSH 会话 + 跨会话持久记忆
  ↓ 记忆保留用户偏好，应用到未来的任务中
  ↓ 多个 Bot 组成群聊，通过 @ 提及互相派活协作
  ↓ Main Bot 拥有管理权限，统筹其他 Bot 和群聊
  ↑ "专家角色"不再是一次性的上下文，而是长期存在、能协作的团队成员

使用场景

1. 想要专门负责某类任务的长期助手

   • 比如一个专门写文案的 Bot、一个专门写代码的 Bot,各自保留对应领域的偏好记忆

2. 需要多个"专家"协作完成复杂任务

   • 通过群聊让不同 Bot 各自负责任务的一部分,互相用 @ 派发子任务

3. 新用户想要快速上手多 Bot 配置

   • 直接和 Main Bot 对话,由它引导完成 Bot 和群聊的初始设置,而不是啃文档

4. 需要在多个 Bot 之间共享工具能力的用户

   • 通过 Capabilities 共享库,把同一组 MCP 服务器、Skills 挂载到不同 Bot 上复用

5. 需要追踪多 Bot Token 消耗的用户

   • 在 Settings → Usage 里按时间、Bot、模型维度查看 Token 消耗情况

快速开始

前提条件:已安装 DSH 并配置至少一个模型。

DSH Desktop 安装(Windows、macOS):

1. 侧边栏 → Plugins → Add plugin
2. 输入包名 ds-bot（中国大陆用户可选择"大陆镜像"源）
3. 选择 Install，然后 Enable now（如有提示则重启 DSH）

也支持下载 .tgz 发布包或通过 GitHub 路径引用安装(需要 Git)。

DSH Web 安装(Windows、macOS、Linux,需 Node.js 22.19+ 和 pnpm):

npx @deepseek-ai/dsh@0.2.0-rc.2 plugin --profile web add ds-bot
npx @deepseek-ai/dsh@0.2.0-rc.2 web

核心特性

1. Bot(单个机器人)

每个 Bot 对应一个独立的聊天/工作窗口,可以单独选择和切换使用的模型。底层上,"每个 Bot 本质上是一个 DSH 会话,使用 DSH 的工具和模型"——用户不需要关心底层会话细节,只需要和一个固定的 Bot 窗口交互。

2. Main Bot(主管 Bot / "Chief")

拥有更高权限的管理型 Bot,首次启动时预装,负责管理其他 Bot 和群聊,并引导新用户走一遍配置流程。官方建议:"有问题?问 Main Bot。"

3. 群聊(Group Chats)

多个 Bot 在同一个对话里协作。每个群聊有一个默认应答的管理员 Bot,可以把任务委派给其他 Bot;用户也可以直接 @ 提及某个具体 Bot,绕过管理员直接对话。

4. 任务派发(Handoff)机制

任意 Bot 都可以用 @ 提及语法把任务委派给另一个 Bot。接收任务的 Bot 独立工作,期间群聊对话可以继续;进度会同步显示在群聊、侧边栏和该 Bot 自己的聊天窗口里。任务完成后,结果发回群聊,发起方 Bot 做出响应。用户可以通过群聊详情面板中途终止任务。

5. 持久记忆系统

Bot 会跨会话保留用户偏好的记忆,应用到未来的任务中。记忆可以通过 Bot 详情页编辑,也可以直接在对话里口头要求修改。

6. Capabilities 共享能力库

位于 Settings → Capabilities,是 MCP 服务器、Skills、Packs 的共享仓库。能力通过设置挂载到具体 Bot 上,从该 Bot 的下一条消息开始生效(单聊和群聊场景都适用)。本地 MCP 命令执行前需要用户明确批准。编辑或删除一个正被其他 Bot 使用的能力,操作权限仅限于用户本人或 Main Bot。

7. 用量追踪

Settings → Usage 按时间、Bot、模型维度展示 Token 消耗情况。

8. 本地数据存储

所有数据本地存储在 DSH 主目录(默认 ~/.dsh)下的 bot/ 和 sessions/ 中,即使卸载插件,数据依然保留。

---

深入剖析

"Bot = 会话 + 记忆"的组合,解决了什么本质问题

DeepSeek Bot 架构里最核心的一句话是:"每个 Bot 本质上是一个 DSH 会话,使用 DSH 的工具和模型。"但如果只是这样,它和普通会话没有区别——真正的区别在于持久记忆层叠加在会话机制之上。

普通会话模式：
  会话 = 临时上下文 + 工具调用能力
  ↑ 关闭会话 = 上下文清空
  ↑ 想要"专家角色"持续存在，只能靠用户自己重复输入背景信息

DS Bot 的 Bot 模式：
  Bot = DSH 会话（临时上下文 + 工具调用能力）+ 跨会话持久记忆
  ↓ 记忆独立于单次会话的上下文窗口存在
  ↓ 用户偏好、历史习惯被记录，应用到未来任务
  ↑ "专家角色"从一次性上下文升级为长期存在的团队成员

这个设计选择的关键在于:它没有试图扩大上下文窗口来解决"遗忘"问题,而是把"记忆"从"上下文窗口的一部分"剥离出来,变成一个独立的、持久化的数据层。这是一个更务实的工程选择——上下文窗口终究有限,但结构化的记忆文件可以无限增长(只受磁盘限制),检索效率也更可控。

群聊里的"管理员默认应答"模式:降低多 Bot 协作的认知负担

群聊协作设计里有一个值得注意的细节:每个群聊有一个默认应答的管理员 Bot,用户发消息默认由它处理,它可以自行决定是否委派给其他 Bot;只有当用户主动 @ 提及某个具体 Bot 时,才会绕过这个默认流程。

如果没有默认管理员，群聊里的每条消息都需要用户显式指定接收者：
  用户每次都要想清楚"这条消息该发给谁"
  ↑ 认知负担随 Bot 数量线性增长

DS Bot 的管理员默认应答模式：
  用户正常发消息 → 管理员 Bot 接收并判断是否需要委派
  ↓ 用户不需要每次都想清楚该找哪个 Bot
  ↑ 只有在用户明确知道该找谁时，才用 @ 提及绕过管理员

这个设计把"多 Bot 协作"的默认复杂度压到了接近"单 Bot 对话"的水平——大多数时候用户只需要像平时一样说话,管理员会处理路由问题;只有需要精确控制时才需要用 @ 显式指定。项目文档也坦诚指出群聊比单 Bot 对话的开销更大,这正是设置管理员委派模式的直接动机——用委派机制来管理多 Bot 协作带来的额外成本,而不是要求用户手动编排每一个 Bot。

用对话完成配置,而不是让用户啃文档

项目在设计理念部分有一句直白的建议:"我强烈建议你直接和一个 Bot 对话来设置你的其他 Bot 和群聊。"这意味着 Main Bot 本身承担了"配置界面"的角色——用户不需要去翻阅复杂的配置项说明,而是通过自然语言对话,让 Main Bot 引导完成设置。

这个设计选择值得注意的地方在于:它把"配置复杂的多 Bot 系统"这件事,转化成了"系统本身的核心能力"的一次具体应用——既然 Bot 系统本身就是用来对话协作的,那么"配置 Bot 系统"这件事也应该用对话来完成,而不是跳出到一个传统的表单式配置界面。这是一种"吃自己的狗粮"式的设计一致性。

坦诚的致谢:理念借鉴,而非代码复制

DeepSeek Bot 在致谢部分列出了一份相当详细的清单,说明哪些设计理念借鉴自哪些项目,并明确强调是"理念"而非"代码":

灵感来源	借鉴的设计理念
AgentMemoryRepo	Markdown 记忆格式
OpenAI Codex	Checkpoint 和消息锚点概念
OpenMausBot	群聊轮次结构和 @ 提及中继设计
Hermes Agent / Hermes Bot Mode	按成员分配会话和任务交接设计
OpenCode、goose、pi、Gemini CLI	对话压缩和任务交接笔记设计
obelisk	SQLite 全文搜索灵感

这种做法在开源社区里值得肯定——很多项目在设计上明显受到其他项目启发,却很少在文档里系统性地列出"借鉴了谁的什么想法"。DeepSeek Bot 把这份"思想谱系"摆在明面上,既是对原创者的尊重,也让用户更容易理解这个项目在多代理协作设计空间里的具体定位——它不是凭空发明,而是站在多个项目已验证过的设计模式之上做的综合与落地。

明确的免责声明:用户自己的模型配额,自己核实关键操作

项目文档也直接提醒用户:Bot 的操作会消耗用户自己的模型配额,并且能够读写文件或执行命令——"请自己核实重要操作"。这种直白的风险提示,配合"独立社区项目,非 DeepSeek 官方产品"的声明,体现了一种对用户负责的透明度,而不是用模糊的措辞淡化潜在风险。

---

项目地址与资源

官方资源

• 🌟 GitHub:github.com/Fei2411/Dee…
• 📄 协议:Apache License 2.0
• 📝 更新日志:仓库内 CHANGELOG.md
• 🤝 贡献指南:仓库内 CONTRIBUTING.md / CONTRIBUTING.zh.md

相关资源

• DeepSeek Harness(DSH) —— DeepSeek Bot 所依赖的底层插件系统和会话/工具/模型框架
• esbuild —— 插件界面代码的打包工具

---

总结与展望

核心要点回顾

1. "Bot = 会话 + 持久记忆"的组合是核心创新:把记忆从有限的上下文窗口中剥离,变成独立持久化的数据层
2. 群聊管理员默认应答机制降低多 Bot 协作的认知负担:大多数时候像单 Bot 对话一样简单,需要精确控制时用 @ 提及
3. 用对话完成系统配置,而非传统表单界面:Main Bot 本身承担引导配置的角色,体现设计一致性
4. 坦诚列出设计理念的多个灵感来源:从 OpenAI Codex 到 Hermes Agent,明确区分"借鉴理念"与"复制代码"
5. 直白的风险提示和社区项目声明:不掩盖"消耗用户自己配额"和"非官方产品"这两个关键事实

适合谁

• DeepSeek Harness 用户想要长期存在的专家角色:而不是每次重新建立上下文的一次性会话
• 需要多个 AI 角色协作完成复杂任务的用户:通过群聊和任务派发机制实现分工
• 想要通过对话而非配置文件完成系统设置的用户:Main Bot 的引导式配置体验更友好
• 关注多代理协作架构设计的开发者:可以参考其管理员委派、记忆持久化、能力共享等具体设计模式

一句话评价

DeepSeek Bot 没有试图让单个 AI 会话变得更聪明,而是通过持久记忆和群聊协作,把"一次性对话"升级成了"长期存在、能互相派活的团队"——这或许是比"更大上下文窗口"更贴近实际协作需求的解法。

---

欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，欢迎访问我的个人主页