终于搓完发布了 #dsh #dsh-gitea-search 欢迎试用、提建议
[b]项目地址[/b]： https://github.com/offzen/dsh-gitea-search
[b]开发的动机[/b]：token 不够烧的，还经常因为重复的任务延长等待，无数的 429 限流...原理上很多任务可以在本地加速。
DSH 的插件机制很适合自己改造，只有一个搜索框显然是太弱了；手动去输脚本使用上不现实。
[b]跨会话检索和长期记忆[/b]：用 SQLite 全文索引加快关键词查找，再用向量副库做语义相近内容的检索，方便找回以前的方案、命令和报错等片段。（你通常记得的就只有片段信息，如果让 AI 检索会很慢）大量代码和信息本来就在本地，不必整包丢给云端模型去耗时间和 token 。本地先找出来，再只把命中的上下文交给模型，交互会更快，也更省上下文。模型看到的是筛过的历史方案、命令和报错，而不是整份会话，回答也会更准。
原理部分：见链接
[size=5]增强 dsh 的搜索-引入 SQLite FTS 索引+向量记忆副库[/size]
在 DSH （ DeepSeek Harness ） 及大模型 Agent 架构中，保存会话、上下文并解决“文件保存难以搜索”的问题，通常有两类存储需求：
会话状态与事件回放（ Session State & Event Replay ）：要求保证上下文完整性、严格时序、确定性重放与分支（ Fork ）。上下文检索与长期记忆（ Context Retrieval & Memory/RAG ）：要求能够跨会话精准定位历史方案、命令、错误记录或语义相似内容。
[size=4]术语解释：rg 逐次扫描 SQLite FTS 索引 向量记忆副库 Qdrant[/size]
见链接 以后再放到 github 文档里
在大模型 Agent （代理）架构中引入了 [b]SQLite FTS (全文索引)[/b] 与 [b]向量记忆副库[/b]，并将检索功能与本地的 Gitea （私有代码托管平台）以及本地历史会话进行了深度绑定。
[size=4]🛠️ 它解决了什么核心问题？[/size]
在重度依赖大模型进行开发的场景下，随着会话和代码的积累，AI 往往会面临“失忆”或响应缓慢的问题。该项目针对性地解决了以下三大痛点：
[list=1]
[*][b]Token 浪费与交互高延迟[/b]以前大模型处理代码时，往往粗暴地将整个文件或多个文件直接丢给云端。该插件通过本地化检索预检，先在本地筛出相关的历史方案、命令或代码段，[b]只将精确命中的上下文片段交给大模型[/b]。这大幅减少了 Token 消耗，并极大提升了响应速度。
[*][b]海量会话中的“搜索盲区”[/b]DeepSeek Harness 的原生内置搜索依赖 rg (ripgrep) 进行逐次扫描，当会话数据攒积过多时，速度会显著变慢。引入 SQLite FTS 完美解决了大量文本历史的毫秒级全文检索问题，使得 Agent 能够跨会话迅速捞出曾经遇到的报错或历史方案。
[*][b]分离“会话状态”与“长期记忆”[/b]它在架构上将两类不同的存储需求剥离开来：“会话状态”负责保持代码操作的严格时序，支持确定性的分支 (Fork)；而“记忆副库”则负责像人类的长期记忆一样，通过语义和向量进行跨维度的关联与 RAG （检索增强生成）。
[/list][size=4]⚖️ 架构解题思路对比：dsh-gitea-search vs Codex vs Google AI[/size]
面对海量代码资产和 AI 辅助编写，这三者的解题思路截然不同：
[table][tr]评估维度dsh-gitea-search (本地增强)Codex (典型的本地 CLI/基础 IDE)Google AI (Gemini / Code Assist)[/tr][tr][td][b]核心机制[/b][/td][td][b]“四两拨千斤”[/b]：本地极速切片检索，过滤出最相关的碎块再进行推理[/td][td][b]实时上下文流[/b]：主要依赖当前打开的文档或编辑器传递的可见上下文[/td][td][b]“力大砖飞”[/b]：超大上下文窗口（如 200 万 Token ），直接在云端全量解析工程[/td][/tr][tr][td][b]跨会话持久记忆[/b][/td][td]极强。通过常驻系统的 SQLite+向量库构建持续跨时间的个人知识库[/td][td]弱。属于每会话进程（非常驻），重启或关闭进程后通常就丢失了上文[/td][td]强，但依赖云端的对话历史、项目缓存以及全托管的云端 RAG 方案[/td][/tr][tr][td][b]隐私与控制权[/b][/td][td][b]极致本地化[/b]。建库、向量化均在本地服务器，无关代码坚决不出境[/td][td]中等。高度依赖云端 API 进行处理，受限于具体的服务隐私条款[/td][td]中/高（企业级合规）。代码资产必须上传到 Google Cloud 闭环中进行计算[/td][/tr][tr][td][b]极客魔改潜力[/b][/td][td]极高。作为声明式插件，无需深入编译源码即可低成本改造出专属本地引擎[/td][td]低。一般为闭源产品或黑盒调用，普通用户很难干涉其底层检索和拼接逻辑[/td][td]低。开箱即用但缺乏底层架构的透明度，与大厂生态深度绑定[/td][/tr][/table]实际执行效果：[img]https://tof.cloudns.ch/usr/uploads/2026/10/2383904717.png[/img]
⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉