技术

[dsh-gitea-search 发布] DSH+Gitea 引入 SQLite FTS 索引+向量记忆副库

2 1

终于搓完发布了 #dsh #dsh-gitea-search 欢迎试用、提建议
项目地址： https://github.com/offzen/dsh-gitea-search
开发的动机：token 不够烧的，还经常因为重复的任务延长等待，无数的 429 限流...原理上很多任务可以在本地加速。
DSH 的插件机制很适合自己改造，只有一个搜索框显然是太弱了；手动去输脚本使用上不现实。
跨会话检索和长期记忆：用 SQLite 全文索引加快关键词查找，再用向量副库做语义相近内容的检索，方便找回以前的方案、命令和报错等片段。（你通常记得的就只有片段信息，如果让 AI 检索会很慢）大量代码和信息本来就在本地，不必整包丢给云端模型去耗时间和 token 。本地先找出来，再只把命中的上下文交给模型，交互会更快，也更省上下文。模型看到的是筛过的历史方案、命令和报错，而不是整份会话，回答也会更准。
原理部分：见链接
增强 dsh 的搜索-引入 SQLite FTS 索引+向量记忆副库

在 DSH （ DeepSeek Harness ）及大模型 Agent 架构中，保存会话、上下文并解决“文件保存难以搜索”的问题，通常有两类存储需求：
会话状态与事件回放（ Session State & Event Replay ）：要求保证上下文完整性、严格时序、确定性重放与分支（ Fork ）。上下文检索与长期记忆（ Context Retrieval & Memory/RAG ）：要求能够跨会话精准定位历史方案、命令、错误记录或语义相似内容。
术语解释：rg 逐次扫描 SQLite FTS 索引向量记忆副库 Qdrant

见链接以后再放到 github 文档里
在大模型 Agent （代理）架构中引入了 SQLite FTS (全文索引) 与 向量记忆副库，并将检索功能与本地的 Gitea （私有代码托管平台）以及本地历史会话进行了深度绑定。
🛠️ 它解决了什么核心问题？

在重度依赖大模型进行开发的场景下，随着会话和代码的积累，AI 往往会面临“失忆”或响应缓慢的问题。该项目针对性地解决了以下三大痛点：

Token 浪费与交互高延迟以前大模型处理代码时，往往粗暴地将整个文件或多个文件直接丢给云端。该插件通过本地化检索预检，先在本地筛出相关的历史方案、命令或代码段，只将精确命中的上下文片段交给大模型。这大幅减少了 Token 消耗，并极大提升了响应速度。
海量会话中的“搜索盲区”DeepSeek Harness 的原生内置搜索依赖 rg (ripgrep) 进行逐次扫描，当会话数据攒积过多时，速度会显著变慢。引入 SQLite FTS 完美解决了大量文本历史的毫秒级全文检索问题，使得 Agent 能够跨会话迅速捞出曾经遇到的报错或历史方案。
分离“会话状态”与“长期记忆”它在架构上将两类不同的存储需求剥离开来：“会话状态”负责保持代码操作的严格时序，支持确定性的分支 (Fork)；而“记忆副库”则负责像人类的长期记忆一样，通过语义和向量进行跨维度的关联与 RAG （检索增强生成）。

⚖️ 架构解题思路对比：dsh-gitea-search vs Codex vs Google AI

面对海量代码资产和 AI 辅助编写，这三者的解题思路截然不同：
评估维度dsh-gitea-search (本地增强)Codex (典型的本地 CLI/基础 IDE)Google AI (Gemini / Code Assist)核心机制“四两拨千斤”：本地极速切片检索，过滤出最相关的碎块再进行推理实时上下文流：主要依赖当前打开的文档或编辑器传递的可见上下文“力大砖飞”：超大上下文窗口（如 200 万 Token ），直接在云端全量解析工程跨会话持久记忆极强。通过常驻系统的 SQLite+向量库构建持续跨时间的个人知识库弱。属于每会话进程（非常驻），重启或关闭进程后通常就丢失了上文强，但依赖云端的对话历史、项目缓存以及全托管的云端 RAG 方案隐私与控制权极致本地化。建库、向量化均在本地服务器，无关代码坚决不出境中等。高度依赖云端 API 进行处理，受限于具体的服务隐私条款中/高（企业级合规）。代码资产必须上传到 Google Cloud 闭环中进行计算极客魔改潜力极高。作为声明式插件，无需深入编译源码即可低成本改造出专属本地引擎低。一般为闭源产品或黑盒调用，普通用户很难干涉其底层检索和拼接逻辑低。开箱即用但缺乏底层架构的透明度，与大厂生态深度绑定实际执行效果：