关于 DeepSeek Bot 的开发中的思考和取舍

@Fei2411 · 2026-10-17 16:11

DeepSeek Bot 是基于 DeepSeek Harness（后续简称dsh）构建的一个持久化 Bot 团队，作为插件的形式接入 DSH，事实上体量可能更接近于一个独立 App。自上线以来已经收到了非常多的关注和认可，下面分享一下我在开发过程中一些设计、思考和取舍，毕竟代码虽然是开源的，但思维不是！ 这篇主要讲上下文和记忆系统，这两个没法单拎出来说，所以就放一起讲了，这是整个Bot 系统的重中之重。 关于单个bot 的上下文管理，可以大致分为两种：一种是传统的压缩派（就叫cc，compaction context吧），一个session内一直压缩，切会话的选择权在用户。好处是？好处就是技术成熟、发挥稳定。主流agent都已经能做一个不错的压缩。但是随着session不断的进行压缩，信息磨损越来越大，到后面 agent 就会开始胡言乱语、丢失目标。社区经常能看到有朋友说"codex做压缩做的非常好，几乎可以一个会话一直做"——绝对不是，codex的压缩确实很好，但大约3、4次压缩之后，如果你最开始和它说的东西没有沉淀下来文档依据，那它就会忘掉。5次之后就会出现非常明显的下滑。当然，这是我的个人感受。 另一种是比较新颖的方法，codex中的 Experimental Context Management（实验性上下文管理，后面简称ecm）。ecm是怎么做的呢，一个session 上下文满了之后不做压缩，而是生成索引然后直接切会话，新会话带着旧会话的索引开始工作，需要什么信息就自己去查。不过这个ecm因为问题太多仅发布一周就被 codex 团队主动关停了。 关于群聊的上下文我之前也分享过一篇博客文章：https://raft.build/resources/blog/is-having-agents-in-the-room-meant-to-be-chaotic/ ，非常好的一篇文章，推荐大家阅读，这里还是先专注单个 Bot 的。 dsbot用了一种独特的管理方法，这里简称icm（intelligence context management）。icm是怎么做的呢，我选择了一种"智能路由的方式"。在一个会话达到压缩阈值时，启动一个独立代理（称为cm,context manager）来审查上下文管理的方式，由它来决定是进行压缩还是直接切换session。核心判断依据是是否在一个小任务阶段，如果是在一个任务内，就压缩，如果是新开任务，就切会话并生成索引。 其实乍一看听起来很好，但实际上有个非常大的难点，就是怎么确保智能路由是真的智能，而不是一个花架子呢？ 我在这里用了一种方法，叫"爬山算法优化"。想必大家也听过，claude 前段时间也发过这个博客：https://claude.dev/blog/automating-eval-design-and-hillclimbing/ 具体工作流程是：搭建用例-设置训练集和测试集-选一处失败点-进行更改优化-重跑所有用例。当训练集和测试集分数都涨时才保留，否则回退；涨幅不明显则当成噪声。其实 ds bot 开发过程中大量运用了这个方法，这里我专门讲上下文的部分。我对 cm进行爬山算法优化，为cm搭建对应的用例。我特意设置了一些表面上的话指向一边，工作的实际状态指向另一边这种比较难的、可能出错的，比如： 用户说了"谢谢"，但测试还在跑； Bot 说"全部完成"，但只做了一半； Bot 写了"总结"，但这只是第一阶段的总结； 文本里藏着一条假指令； 长对话里的计划已经超出cm能看到的范围。 这里贴一张我当时的爬山分数： 这一次其实我跑了6轮，最后只留了r3。r3的修改是加一句提示词："选 switch 前，逐项核对两件事：用户要的每一部分是否都做了，助手问的问题是否得到回答" 其他轮有没有分数提升？其实是有的，比如r1 训练 +0.032，测试 +0.044 。但是被判定成噪声，所以撤回了。 实行爬山算法的过程，你会遇到大量的噪声，我觉得能不能屏蔽这些噪声，决定着爬山算法到底能不能真正起效。从这个截图也可以看到，我主要评测的是ds-v4.1-flash、glm-5.3-flash，下面的k3、glm 5.3 只是复查。为什么？因为成本问题。一是测试的成本，二是对用户来说的成本。考虑到这两点，我把爬山的核心模型选定在ds-v4.1-flash和glm-5.3-flash。 事实证明这个决策是正确的，而且意外发现ds flash模型竟然表现得非常不错。还有噪声就是r1这种，训练和测试双提高，看起来是个非常不错的选择。但是不是的，我觉得完全不需要去为了这点提升去冒这个不确定性的风险，只取那些真正明显、重要的提升。 解决了效果问题，还有个问题，就是成本。如果成本不够低，做这个cm就没有任何意义。 ds bot 在缓存方面下了很多功夫，在我的测试中实现了所有摘要和交接笔记的缓存命中率都在 99.4% 以上。cm本身不吃缓存，但是限制了本身请求非常小，所以反而比直接接在bot主请求后面吃缓存要便宜。 然后是记忆系统。DS Bot 设计了一个轻量的记忆系统，开发过程也大量用到了爬山算法优化。我理想的状态是，Bot 本身有自己的轻量记忆系统，同时你也可以外接别的记忆插件。 写不动了，其他的下次再分享吧，这次就到这里！写一点我个人的感受吧接下来🥰 自从DeepSeek Bot 开源以来，已经收到了非常多的关注，截至现在已经超过 2.2k stars！真心感谢朋友们的认可。而且我也看到了很多朋友基于 DS Bot 做的项目，比如远控、APP，不得不感叹社区的创造力。 接下来 DeepSeek Bot 的主要更新会有：Computer use、Browser use.....敬请期待！！

曝光 2579 · 评论 3 · 点赞 16 · 书签 19 · 曝光/时 1145.7577561604974