DeepSeek Bot：把 DeepSeek Harness 变成一支会记事、能拉群的 AI Bot 团队

「一个人，也可以拥有一支会记事、能协作、会互相派活的 AI 同事团队。」

做 AI Agent 的开发者，大概率都撞过同一堵墙：每次新开一个对话，AI 就像第一天入职的新同事——项目背景、技术栈偏好、上次改到哪一步、当初为什么做那个取舍，全部要重新交代一遍。对话一长，上下文被自动压缩，昨天刚确认的细节说没就没，只能翻旧记录。更麻烦的是，当你真的想让「研究员、开发者、审核者」各司其职时，要么在一个对话框里让模型分饰多角，结果几个角色的上下文互相串味；要么自己用多 Agent 框架搭一套系统，消息路由、状态持久化、权限、记忆、成本，每一件都得从零造。

DS Bot 是 DeepSeek Harness（DSH）生态里的一个开源 Bot 插件，它把这件事直接做成了产品：每个 Bot 是一个长期存活的 dsh Session，有自己的名字、人格、模型、权限和记忆；一个主 Bot（默认叫 Chief）负责管理团队；群聊有管理员负责控制 token 预算；长对话的压缩与接续交给独立的「上下文管家」。你只需要像和同事聊天一样，把活派出去。

项目速览

⭐ 2,769 Stars ｜ 🍴 267 Forks ｜ 📄 Apache-2.0 ｜ 🔧 704 次提交 ｜ 🐛 54 个 Open Issues

项目在致谢部分非常坦诚：列了 AgentMemoryRepo、OpenAI Codex、OpenMausBot、Hermes Agent / Hermes Bot Mode、OpenCode、goose、pi、Gemini CLI、obelisk 等设计灵感来源，还专门注明「只借鉴思路，不含代码」。

阅读价值与前置知识

你将学到什么

「Bot 即 Session」的宿主复用架构：如何不在 DSH 之外另造一套 Agent 运行时，却拿到多 Bot 协作能力；
上下文管家的二选一决策：什么时候「原地压缩」，什么时候「换新会话」，以及交接包怎么保证不失忆；
群聊的「预算优先」轮转模型：管理员制、沉默权、独立隐藏会话与群记忆，如何把多 Bot 群聊的 token 从 O(N) 压到 O(1)；
一套可读、可改、可审计的 Markdown 记忆系统，以及它和 prompt 缓存之间的配合。

前置知识

了解大模型对话、上下文窗口、token 的基本概念；
用过任意一个 Agent 工具（DSH、Claude Code、Codex 等），知道「会话 / 工具调用 / 权限」大概是什么；
可选：了解 DSH 的插件机制或 MCP，读「核心特性」「深度设计剖析」部分会更顺。

项目档案

项目简介

DeepSeek Bot（DS Bot）是一个社区开源项目，由开发者 FeiZ（GitHub 账号 @Fei2411）维护。官方定位很直白：「一个基于 DeepSeek Harness 的 bot 插件，把 dsh 改造成 Bot 团队」。README 里同时写清了社区属性：它不是 DeepSeek 官方产品，与 DeepSeek 没有隶属、认可或赞助关系。2026 年，这类「常驻 AI Bot 团队」正在成为一个新品类，媒体也常把它和 Grok Bot 放在一起比较，称它是 DeepSeek Harness 生态里的「民间版本」。

技术上，它没有另起炉灶，而是作为 DSH 插件运行：每个 Bot 都活在 dsh 的 Session 里，用 dsh 的模型、工具与权限。2026 年 10 月 21 日发布的 0.2.0 版本，还带来了自带锁定版 DSH 的 Windows / macOS 独立桌面应用，把「插件」升级成了「产品」。

基础信息

项目	信息
包名	npm `ds-bot`（插件）；`deepseek-bot`（桌面应用）
开源协议	Apache-2.0
当前版本	v0.2.0（2026-10-21 发布，仍处于 0.x 快速迭代期）
构建与运行	插件端 Node.js ESM，前端用 esbuild 打包；桌面端 Electron 44 + Vite；Web / Docker 需 Node ≥ 22.19 与 pnpm
支持平台	Windows / macOS 桌面应用；DSH Desktop、DSH Web（Windows / macOS / Linux）；Docker（linux/amd64）
兼容版本	DeepSeek Harness 0.2.1-rc.2

项目数据

⭐ Stars：2,769
🍴 Forks：267
🔨 Commits：704（默认分支可达历史）
🐛 Open Issues：54
👥 Contributors：4（维护者 Fei2411 一人贡献 673 次提交）
📅 创建于 2026-10-07：两周内从 0 跑到 0.2.0，迭代节奏极快
📈 增长：上线首日 250+ Stars（量子位），两天后破 1.1k（智猩猩），两周后达到 2,769

数据截至 2026-10-21，对应 v0.2.0 版本；Star 增长数据来自公开报道与 GitHub API。

它解决什么问题

解决什么问题

多 Bot 协作的普遍痛点：

失忆：每开新对话都要重新交代背景；长对话被压缩后，关键细节丢失，还得翻旧记录。
单线程：想让多个角色分工，只能在同一个对话框里「扮演」，上下文互相污染；或自建多 Agent 框架，编排、状态、权限、记忆全部从零实现。
成本与边界失控：群聊里每个 Bot 都对每条消息回复，token 账单成倍上涨；私聊和群聊的上下文混在一起，隐私边界模糊。
数据与密钥：团队记忆、聊天记录托管在云端不放心；把 API Key 贴进聊天框，又有泄露风险。

DS Bot 的解法是分层的：先用「Bot 即 Session」解决身份与持久化，让每个 Bot 长期在线、有独立记忆；再用「主 Bot + 群聊」解决组织与协作，让谁组织、谁执行、谁审核有明确分工；最后用「上下文管家 + 三级记忆」解决长期工作的连续性与可审计性。三层叠起来，你不必自己写一个多 Agent 框架，就能得到一支能长期运转的团队。

使用场景

场景 1：个人长期助理。 一个 Bot 专门跟项目，记住你的技术栈偏好、命名习惯、历史决策，换对话、换电脑仍是同一个它；另一个 Bot 专门写文案，各自保留对应领域的偏好记忆，互不干扰。
场景 2：小型内容 / 产品团队。 研究员 Bot 查资料、写手 Bot 出草稿、审核 Bot 挑毛病，主 Bot 在群里接需求、派活、汇总。你在群里 @ 谁，谁回应，不需要全员刷屏。
场景 3：多角色开发协作。 设计 Bot 出方案、实现 Bot 写代码、审查 Bot 提意见，工作可以「设计 → 实现 → 审查 → 验收」多轮流转，结果自动回到发起者。
场景 4：隐私敏感的本地部署。 数据全部落在本机 ~/.dsh/bot/；NAS 或 Linux 服务器上可以用 Docker 运行，容器就是 Bot 的沙箱。

快速上手

前提：已经安装 DeepSeek Harness，并在其中配置好至少一个模型（DS Bot 直接复用 dsh 的模型与额度）；或者直接使用自带 DSH 的桌面应用。Web / Docker 方式还需要 Node.js ≥ 22.19 和 pnpm。

方式一：桌面应用（最省事）

在 Releases 下载对应安装包（Windows x64 的 .exe，或 macOS 的 arm64 / x64 .zip）。
安装并打开，首次启动时选择数据和 Bot 文件目录，可以从现有 DSH 导入已有团队（只读，不改原数据）。
在设置里配好模型，然后直接和默认的主 Bot「Chief」说话。

方式二：装进 DSH Desktop

侧栏进入「插件」→「添加插件」。
包名填 ds-bot（中国大陆可切换镜像源），点「安装」。
点「立即启用」；若提示下次启动生效，完全退出 DSH 再打开。

方式三：DSH Web

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

方式四：Docker（NAS / Linux 服务器）

docker/ 目录提供了带 DSH Web 与 DS Bot 的镜像构建，CI 会发布 linux/amd64 预构建镜像到 GHCR。

第一次进入时，团队里已经有一个叫 Chief 的主 Bot。不用先研究设置，直接对它说「帮我建一个写代码的 Bot 和一个写文案的 Bot，再拉个群」，它会带你完成配置——这也是作者在 README 里最推荐的上手方式。建议先只建一个成员 Bot，跑通一个边界清楚的小任务，再逐步加人：群聊里每多一个参与者，就多一份模型调用和 token 消耗。

核心特性

长期 Bot：一个 Bot 就是一位有工位的同事。 每个 Bot 有名字、角色标签、指令、模型、权限预设、工作目录和外观；它的对话是一个长期存活的 Session，今天聊不完的，明天接着聊。你可以随时换模型，但作者建议一个 Bot 长期固定一个模型，行为更稳定。
主 Bot（Chief）：团队的「Chief of Staff」。 主 Bot 拥有最高权限，可以创建、修改、删除其他 Bot，管理所有群聊。一个团队可以有多个主 Bot，也可以只有一个；新团队的第一个主 Bot 由插件自动创建。
群聊：多 Bot 协作的主场。 每个群有管理员，默认由管理员回复你的消息，并决定叫谁来；你也可以直接 @ 某个成员。成员按顺序发言，每次只看到「上次看过后新增的消息」；没有新内容就保持沉默（[PASS]）。0.2.0 起群聊还拥有自己的记忆，群里的信息不会漏给群外的 Bot。
Bot 间协作与工作回传。 message_bot 让 Bot 互相派活；list_bots 能看到每个同事此刻在做什么（在哪个群、跑了多久、等谁、等审批还是等回话）；一个 Bot 把活转包出去后，结果会自动汇总回到发起者，不用轮询、不用催。
三级记忆：Bot / 团队 / 群聊。 每个 Bot 有自己的记忆，团队有一份所有人可读的共享记忆，群聊还有一份只对群成员可见的记忆。记忆是纯 Markdown，可以翻看、修改、删除；每轮对话后还有一次自动「记忆审查」，不依赖 Bot 恰好想起调用工具。
能力库：MCP、技能与能力包共享。 在设置 → 能力里统一管理，挂到 Bot 上后从下一条消息起生效，也适用于它参与的群聊；Bot 自己添加的本地 MCP 命令需要你批准才能运行。另有一个 GitHub 连接器，通过 MCP 提供工具，Token 不会落到 Bot 的 shell 里。
上下文管理与聊天检索。 长对话由上下文管家接管（下一节细讲）；read_own_chat 可以在所有历史 part 里全文检索，连被压缩掉的内容也能查回来。
本地化、安全与用量。 团队数据存在本机 ~/.dsh/bot/，卸载插件不会删除；API Key 通过安全卡片输入，Bot 永远看不到明文，工具结果与模型请求都会自动脱敏；Desktop 端每个 Bot 有独立浏览器，只读页面、不保存登录；设置里的「用量」可以按时间、Bot、模型查看 token 消耗。

深度设计剖析

Bot 即 Session：多 Agent 框架最贵的那部分，它选择「不重写」

常规方案： 做多 Agent 系统时，常见做法是自建一套运行时：消息总线、Agent 状态机、工具调用循环、上下文管理、权限系统、持久化存储。LangGraph、AutoGen 这类框架解决了一部分问题，但你仍然要自己处理「会话怎么存、重启怎么恢复、模型怎么配、工具权限怎么控」。

DS Bot 的设计： 它没有发明新的 Agent 运行时，而是把每个 Bot 映射成 DSH 的一个普通 root Session。团队花名册、群聊、Bot 间往来记录集中放在 ~/.dsh/bot/state.json 一个 JSON 文件里（原子替换写入，带 schema 版本与迁移逻辑，state.lock 保证同一份数据只有一个 DSH 在写）；不新增 Session 事件类型，对话本身仍然由 dsh 的 Session 日志承载，运行中被打断的 turn 由 inflight.json 在下次启动时恢复。Bot 的模型、工具、权限预设、工作目录、附件、MCP 能力，全部复用 DSH 已有的机制。代码组织上分成两层：Node.js 侧的 host runtime（负责 turns、roster、capabilities、channel 等模块）和打包后的浏览器 client bundle，界面通过 POST /api/bot 通道与宿主通信——DeepWiki 的架构导读把它概括为「host runtime + client bundle」两层。

为什么这么做： 多 Agent 框架里最贵的从来不是「让模型说话」，而是外围那套基础设施。把 Bot 降维成宿主已有的 Session，等于把模型路由、工具生态、权限、日志、缓存这些能力全部「白嫖」了一遍；插件自己只需要专注 Bot 特有的部分——花名册、群聊轮转、记忆、上下文管家。

工程价值： 整个 npm 包解压后约 1.7 MB、48 个文件（前端打包产物占了大头），项目两周迭代到 0.2.0；升级 DSH 就能顺带获得新能力；数据格式稳定，用户换机器迁移成本低。代价是深度绑定 DSH——这不是一个能脱离宿主独立运行的多 Agent 框架，而是一层「产品化的组织层」。

上下文管家：把「该不该换新会话」交给一次模型判断

常规方案： 长对话的处理通常是「超过阈值就压缩」：让主模型把历史总结成一段摘要，继续往下聊。问题是：摘要会丢细节，摘要的摘要丢得更多；压缩过程本身消耗主模型 token；用户还会看到一个突兀的「已压缩」标记。更关键的是，压缩时机是机械的——不管当前任务做没做完，到点就压。

DS Bot 的设计： 它在每一轮结束后检查上下文是否越过「检查线」（默认是可用窗口的 80%）。越线后，它发起一个独立的小模型调用——上下文管家，预算约 6,000 token，只回答一个问题：当前工作到自然停顿点了吗？

到了停顿点 → 选择 switch：对话换到一个全新 Session，Bot 在空闲时写一份交接笔记，新 part 以「交接包」开场（笔记 + 最近原话 + 旧内容在哪）。
工作还在进行 → 选择 compact：原地生成 checkpoint，把旧消息压成摘要，但用户最近的消息逐字保留。

两种情况下，用户看到的始终是同一个聊天，没有突兀的标记；被压掉的内容仍然躺在 SQLite FTS5 索引里，随时可以用 read_own_chat 搜回来（trigram 分词，中文不需要额外分词）。

这个设计的关键在于： 把「上下文管理」从一个机械的 token 阈值问题，变成了一个关于「工作状态」的判断问题。小模型只做一次二元决策，成本低、不打断主模型；主模型永远在干净的上下文里工作；交接笔记复用同一段 prompt 前缀，命中 provider 缓存，用户几乎无感。它没有追求「一个会话永不结束」，而是承认「换会话」本身是长任务的一部分——只要交接做得好，换会话就不是失忆。

群聊的「预算优先」设计：让沉默也是一种回答

常规方案： 多 Agent 群聊最常见的实现是广播：用户说一句话，所有 Agent 都收到、都回复。上下文互相污染不说，N 个 Bot 就是 N 倍 token；如果共享一个会话，私聊内容也会被群里其他 Bot 看到。

DS Bot 的做法： 它把群聊当作一个「有成本的共享房间」来设计：

管理员默认回复：你的消息默认只由管理员处理，由它决定要不要叫其他人；也可以直接 @ 指定成员。管理员的发言额度更高，可以多叫几轮。
沉默权：成员按顺序发言，只看自己上次看过后新增的消息；没有新内容就 [PASS]，不为了刷存在感而说话。
独立隐藏会话：每个成员在每个群里都有一个自己的隐藏 Session，群聊永远不会读到它的私聊；群也有自己的记忆，群外成员看不到。
显式接力：@Name 是传递回合的明确动作；工作被转包后，结果会自动回到发起者。

带来的效果： 群聊的 token 消耗从「全员回复」的 O(N) 起步，变成「管理员先接」的 O(1) 起步；上下文边界清晰，私聊、群聊、群记忆各归各；讨论是有序的——同一时刻只有一个人说话，不会出现几个 Bot 同时抢答、互相打断。代价是群聊不像人类群聊那样「热闹」，但对按 token 计费的 AI 团队来说，这种克制恰恰是产品成熟度的一部分。

项目细节

致谢写得很坦诚。 项目明确列出 AgentMemoryRepo（记忆的 Markdown 格式）、OpenAI Codex（压缩时保留用户原话、消息锚点）、OpenMausBot（群聊轮流发言与 @ 接力）、Hermes Agent / Hermes Bot Mode（每成员每群一个会话）、OpenCode / goose / pi / Gemini CLI（何时压缩、交接笔记写什么）、obelisk（SQLite 全文索引）等设计来源，并强调「参考思路，不含代码」，第三方代码单独列在 NOTICE 里。这种把灵感来源摊开写的做法，在开源项目里并不多见。

社区热度起得很快。 项目上线首日就拿到 250+ Stars，两天后破 1.1k；据智猩猩整理，DeepSeek Harness 负责人崔天翼也在 GitHub 上给项目点了 Star。不管这算不算「官方认可」，它至少说明「把 DSH 变成多 Bot 团队」这个方向戳中了社区的痒点。

风险提示也很直接。 README 写明：Bot 会按你的要求读写文件、运行命令，会消耗你自己的模型额度，重要操作要自己检查；桌面应用目前未签名，Windows 会弹 SmartScreen，macOS 需要到「隐私与安全性」手动放行。

项目还在早期。 README 仍标注预览版，功能和数据格式都还可能变化；作者在公开介绍里提到，后续想支持接入本地 Agent、远程控制和 App。打算长期使用的话，建议先备份 ~/.dsh/bot/ 与 ~/.dsh/sessions/——卸载插件不会删数据，但升级或换机器前留一份副本更稳妥。

隐私边界设计得比较细。 数据默认全部留在本机；密钥存在 secrets.json（文件权限 600），Bot 只能通过环境变量使用，工具结果保存前和每次模型请求前都会把密钥替换成 [secret:NAME]；Desktop 端每个 Bot 有独立的浏览器分区，登录态只存在内存里；当两个 DSH 同时打开同一份数据时，先载入团队的那个可写，另一个自动变为只读，避免并发写坏团队状态。

记忆是「可审计的数据」，不是「模型的自由发挥」。 记忆是 Markdown，条目有长度上限（单条 300 字符，主文件 4,000 字符），每次变更都写进 journal.jsonl，保留修改前后的行；系统明确把记忆定义为「数据而不是指令」，并拒绝保存密钥、密码一类的条目。

同名项目提醒。 名字相近的还有一个 BotHarness/DeepSeekBot（npm deepseekbot），是另一个独立项目；本文写的是 Fei2411/DeepSeek-Bot（npm ds-bot），两者的重心不同，感兴趣可以对照阅读。

开发透明度。 仓库里有 CHANGELOG（Keep a Changelog 格式）、AGENTS.md、CONTRIBUTING、产品愿景文档 docs/vision.zh.md，CI 里还有一个叫「Leak scan」的任务，专门扫描提交里是否夹带密钥和个人数据。

资源汇总

官方资源

GitHub：Fei2411/DeepSeek-Bot
开源协议：Apache-2.0
更新日志：CHANGELOG.md
贡献指南：CONTRIBUTING.zh.md
安装包：Releases
npm：ds-bot
插件文档：ds-bot/README.md

媒体报道与延伸阅读

DeepWiki 架构导读：第三方自动生成的代码结构与子系统导读，适合配合源码阅读。
量子位：DeepSeek Bot 来了！民间版，DSH 装个插件就能用
智猩猩：DeepSeek Harness 负责人点赞，民间版 DeepSeek Bot 火了
Pandaily：Community-Built DS Bot Plugin Turns DeepSeek Harness Into a Team of Long-Lived Bots
七牛云：民间版 DeepSeek Bot 如何让多个 Bot 接力干活：偏上手指南的版本，含小团队试用建议。

总结

核心要点回顾

Bot 即 Session：不重造 Agent 运行时，把多 Agent 的基础设施成本交给宿主，插件只做组织层。
上下文管家：用一次小模型判断，在「原地压缩」和「换会话」之间二选一，让长对话既不失忆、又能被检索。
预算优先的群聊：管理员默认回复、成员沉默权、独立隐藏会话、群级记忆，把多 Bot 协作的成本和边界同时管住。
可审计的本地数据：Markdown 记忆、密钥脱敏、本地存储与只读锁，让「长期运行的 AI 团队」在安全和信任上站得住。

适合谁

想让 AI 长期记住自己、有固定分工的个人开发者；
需要多 Bot 协作，但担心 token 成本和上下文边界的团队；
正在研究多 Agent 编排、上下文管理、长期记忆的开发者——仓库里的 src/host/ 和 docs/plans/ 值得逐篇读；
想基于 DSH 做插件、学习「如何在宿主上做一层产品」的工程师。

一句话评价

DS Bot 没有发明新的多 Agent 框架，而是把「同事」这个产品概念拆成了 Session、记忆、群聊和上下文管家四块工程问题——每一块都不炫技，但拼在一起，AI 第一次有了「长期工位」的样子。