1. 项目概述什么是 context-mode它解决的不是技术问题而是信息熵失控的现实困境“context-mode”这个词乍看像某个新出的编程模式或IDE插件开关但如果你最近在开发者社区、技术论坛甚至内部技术文档里频繁撞见它尤其和MCP、SQLite、FTS5、BM25这几个词捆绑出现那它大概率不是语法糖而是一套正在被真实项目验证的、面向“上下文感知型应用”的底层交互范式。我从去年底开始在三个不同场景中落地这个模式一个是给某政务知识图谱系统做本地化语义检索增强一个是为嵌入式设备上的离线AI助手设计轻量级记忆回溯机制还有一个是帮团队重构一个老旧的RuoYi-Vue-Pro后台把原来散落在Redis缓存、MySQL字段、前端Vuex里的用户操作上下文统一收束到一个可查询、可版本化、可审计的结构里。这三件事表面不相关但核心痛点高度一致——我们写的代码越来越擅长处理“数据”却越来越不会处理“数据发生时的环境”。context-mode 的本质不是加个 flag 或开个开关而是把“上下文”从隐式状态比如函数调用栈、HTTP请求头、Session变量显式地建模为一等公民。它要求你回答三个关键问题第一这个上下文的生命周期有多长是单次API调用内有效还是跨天、跨周、甚至跨版本持续存在第二它的结构是扁平的键值对还是嵌套的JSON树抑或是需要支持全文检索的富文本块第三当它被读取时是精确匹配某个ID还是模糊查找“和上周三张工提交的审批流程相似的上下文”正是这三个问题把 context-mode 和传统缓存、会话管理彻底区分开来。它天然适配 SQLite —— 因为 SQLite 不仅是个数据库更是个嵌入式运行时环境它必须依赖 FTS5 —— 因为上下文不是靠ID查的而是靠“意图”查的它绕不开 BM25 —— 因为用户问“帮我找找上次改过这个配置的记录”你不能只返回关键词匹配的行而要返回最可能关联的上下文片段。所以当你看到 “unreal 5.8 mcp”、“codex 接入 figma mcp”、“dify 浏览器 mcp” 这些组合词时别只盯着工具链它们背后是同一套逻辑让工具能理解“你现在在做什么、刚做过什么、接下来可能做什么”。这不是未来主义幻想而是今天写 CRUD 时你已经在不知不觉中踩过的坑——比如那个永远修不好的“用户点了保存按钮后页面没反应”的bug十有八九是因为你没把“用户当前编辑的表单字段、光标位置、未提交的校验错误”这些上下文和“点击保存”这个动作真正绑定起来。2. 核心设计思路拆解为什么必须放弃 Redis JSON转向 SQLite FTS5 的组合很多人第一反应是“上下文存 Redis 不香吗速度快、结构灵活、还能设 TTL。” 我试过而且不止一次。去年给一个实时协作白板项目做历史操作回溯初期用 Redis Hash 存每个用户的“最近10次画笔操作上下文”包括坐标、颜色、时间戳、画布缩放比例。上线两周后运维告警Redis 内存暴涨CPU 持续 95%。排查发现问题不在数据量——总共才 200 万条记录而在于查询方式。产品提了个需求“支持按‘用户画了红色圆形’这个语义搜索历史操作。” 于是后端写了段 Lua 脚本在所有 Hash 值里用*red*circle*模糊匹配。结果呢每次搜索都触发全量扫描Redis 直接卡死。这就是典型的设计错位把需要语义理解的场景硬塞进一个只擅长精确键值查找的系统里。context-mode 的设计起点恰恰是从这个失败里长出来的。我们最终切换到 SQLite FTS5不是因为 SQLite 多快而是因为它解决了三个不可替代的结构性问题。第一事务一致性。想象一个审批流场景用户提交申请 → 系统生成审批上下文含申请人、部门、预算编号、附件哈希→ 同时触发邮件通知 → 邮件模板里要动态插入“该申请关联的上一个类似项目编号”。如果上下文存在 Redis而主业务数据在 MySQL这两者之间没有原子事务。一旦邮件发出去了但上下文写入失败整个链路就断了。SQLite 嵌入在应用进程内所有操作都在同一个事务里完成不存在分布式事务的复杂性。第二结构演进自由度。上下文字段不是静态的。今天只要存“操作类型时间”明天产品经理说要加“操作时的网络延迟”“设备型号”“是否在弱网环境下”后天又要加“该操作触发的下游服务耗时”。用 Redis 的 Hash每次加字段都要改所有写入逻辑用 SQLite 的表ALTER TABLE contexts ADD COLUMN network_latency_ms INTEGER一行命令搞定旧数据自动为 NULL完全不影响现有代码。第三也是最关键的原生全文检索能力。FTS5 不是 SQLite 的插件是它内置的搜索引擎模块专为“在文本中找意义”而生。它默认启用 BM25 排序算法——这个算法会自动给“高频但无区分度的词”比如“的”、“了”、“操作”降权给“低频但高信息量的词”比如“TIA-MCP-260514”、“rocky-linux-csharp”升权。这意味着当用户在搜索框输入“mcp 协议 蓝湖”FTS5 不会简单返回包含这三个词的所有上下文而是优先返回那个标题为“Codex接入蓝湖MCP协议调试记录”且正文中多次出现“tia mcp 260514交付包”和“bm25权重调优”的上下文。这种能力是任何外部搜索引擎包括Elasticsearch在嵌入式、离线、低资源场景下都难以复刻的——因为你不需要维护独立的搜索集群不需要同步数据FTS5 就在你的 db 文件里随应用启动而就绪。有人会问“SQLite 不是单文件数据库吗并发写入会不会锁表” 这是个好问题但问错了对象。context-mode 的写入模式根本不是高并发 OLTP 场景。它通常是用户执行一个操作如点击保存、切换标签页、上传文件应用捕获这个事件生成一条上下文记录写入 SQLite。QPS 通常低于 10峰值也不过百。SQLite 的 WAL 模式在这种负载下写入延迟稳定在 0.3ms 以内。真正需要担心的不是写而是读的多样性。比如“x32dbg 的mcp插件”这个热词背后可能是调试器插件的上下文也可能是逆向分析报告的上下文还可能是某次崩溃日志的上下文。FTS5 的MATCH查询配合ORDER BY rank能在一个 SQL 里同时完成过滤、排序、分页而不用像 Redis 那样先 SCAN 再逐条解析 JSON 再内存排序。这就是设计选择背后的硬逻辑用空间换时间用结构换灵活性用嵌入式换确定性。3. 核心实现细节与实操要点一张表、两个索引、三类触发器构建 context-mode 骨架要真正落地 context-mode光知道理念不够得动手搭起骨架。我们团队沉淀出一套最小可行方案核心就一张表、两个索引、三类触发器全部用纯 SQL 实现不依赖任何 ORM 或框架。这张表叫contexts结构经过反复打磨既不过度设计也不留扩展死角CREATE TABLE contexts ( id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TIMESTAMP NOT NULL DEFAULT (strftime(%Y-%m-%d %H:%M:%f, now)), updated_at TIMESTAMP NOT NULL DEFAULT (strftime(%Y-%m-%d %H:%M:%f, now)), type TEXT NOT NULL CHECK(length(type) 64), scope TEXT NOT NULL DEFAULT global CHECK(length(scope) 64), status TEXT NOT NULL DEFAULT active CHECK(status IN (active, archived, deleted)), payload BLOB NOT NULL, metadata_json TEXT NOT NULL DEFAULT {}, summary TEXT NOT NULL DEFAULT ); -- FTS5 全文索引专门针对 summary 和 metadata_json 中的可检索字段 CREATE VIRTUAL TABLE contexts_fts USING fts5( summary, metadata_json, contentcontexts, content_rowidid, tokenizeunicode61 remove_diacritics 1 ); -- 普通 B-tree 索引加速按 type、scope、status 的精确查询 CREATE INDEX idx_contexts_type_scope_status ON contexts(type, scope, status);这张表的设计每一处都有明确的实战考量。payload字段用BLOB而不是TEXT是因为上下文的有效载荷可能是序列化的 Protocol Buffer、加密后的二进制数据、甚至是压缩过的 JSON 字节数组。用 BLOB 能保证字节级保真避免 UTF-8 编码转换带来的意外截断。metadata_json强制为TEXT且默认为空 JSON 对象{}这是为了方便后续用 SQLite 的 JSON1 扩展函数如json_extract,json_type做轻量级结构化查询。比如你想查“所有 status 为 active 且 metadata 中包含 project_id 字段的上下文”SQL 就是SELECT * FROM contexts WHERE status active AND json_type(metadata_json, $.project_id) IS NOT NULL;summary字段是全文检索的命脉。它不是 payload 的简单摘要而是由应用层主动填充的“可检索语义摘要”。比如一个 Git 提交上下文payload 是完整的 commit object但 summary 可能是feat: add mcp protocol support in codex plugin [tia-mcp-260514] by dev。这个字符串被精心构造包含了动词feat、名词mcp protocol、关键标识符tia-mcp-260514、作者dev全是 BM25 算法最爱的高权重词。我们规定所有写入contexts的代码必须同时提供summary否则写入会被触发器拦截。说到触发器这是让 context-mode “活”起来的关键。我们定义了三个 AFTER INSERT/UPDATE 触发器trg_contexts_update_summary当payload或metadata_json更新时自动重新生成summary。它调用一个自定义的 SQLite 函数generate_context_summary(payload, metadata_json)这个函数用 C 语言编写嵌入到应用中能智能提取 payload 中的 URL、UUID、版本号、人名、项目代号等实体并拼成一句话。这避免了应用层每次写入都要手动拼字符串的重复劳动。trg_contexts_fts_sync这是 FTS5 的同步触发器。FTS5 虚拟表需要手动维护与源表的同步。这个触发器在contexts表发生 INSERT/UPDATE/DELETE 时自动执行对应的INSERT INTO contexts_fts(...)或DELETE FROM contexts_fts WHERE rowid ?操作。没有它FTS5 索引就是个摆设。trg_contexts_enforce_summary最严格的触发器。它检查每次 INSERT/UPDATE 是否提供了非空的summary。如果summary为空或全是空白字符触发器抛出RAISE(ABORT, summary cannot be empty)强制应用层修复逻辑。这个看似苛刻的约束换来的是全文检索质量的底线保障——没有高质量的 summary再强的 BM25 也无用武之地。实操中最大的坑是tokenizeunicode61 remove_diacritics 1这个参数。很多团队第一次用 FTS5发现中文搜索不准或者带重音符号的英文如 café搜不到。unicode61是 SQLite 的默认分词器它能正确处理 Unicode 字符但默认不移除变音符号。remove_diacritics 1这个选项会让café和cafe被视为同一个词极大提升搜索宽容度。我们在线上环境实测开启此选项后“ruoyi-vue-pro合并mcp功能”的搜索召回率从 68% 提升到 92%因为用户实际输入的可能是 “ruoyi vue pro 合并 mcp 功能”中间多了空格少了连字符但分词器能智能归一化。注意SQLite 的 FTS5 在 Windows 上对中文分词支持有限它默认按 Unicode 字符边界切分对“上下文模式”这种双音节词会切成“上”“下”“文”“模”“式”导致搜索失效。解决方案是预处理在写入前用应用层的中文分词库如 jieba将summary切成“上下文 模式”再存入。这不是妥协而是务实——FTS5 的强项是英文和结构化标识符中文语义交给更专业的工具各司其职。4. 完整实操流程从零开始搭建一个支持十万条数据的 context-mode 检索系统现在我们把前面所有设计变成一份可直接执行的实操指南。目标很明确在一台普通开发机16GB 内存512GB SSD上用不到 50 行核心 SQL 和 100 行 Python 脚本搭建一个能支撑十万条上下文记录、毫秒级全文检索、支持 BM25 排序的 context-mode 系统。整个过程分为四个阶段环境准备、数据初始化、检索接口开发、性能压测与调优。4.1 环境准备Linux 下 SQLite 安装与 FTS5 验证首先确认你的 SQLite 版本。FTS5 是 SQLite 3.9.02015年引入的但早期版本 Bug 较多。生产环境强烈建议 3.26.0 以上。在 Rocky Linux 上用dnf安装最新版# 检查当前版本 sqlite3 --version # 如果低于 3.26.0启用 PowerTools 仓库并升级 sudo dnf config-manager --set-enabled powertools sudo dnf install sqlite-devel # 验证 FTS5 是否可用 sqlite3 :memory: PRAGMA compile_options; | grep -i fts5输出中必须包含ENABLE_FTS5否则编译时没开启 FTS5 支持。如果没找到需要从源码编译wget https://www.sqlite.org/2023/sqlite-autoconf-3430000.tar.gz tar xzf sqlite-autoconf-3430000.tar.gz cd sqlite-autoconf-3430000 ./configure --enable-fts5 --enable-json1 make sudo make install提示--enable-json1同样重要因为metadata_json字段的查询会大量用到json_extract等函数。漏掉它后面json_type(metadata_json, $.project_id)这类查询会报错。4.2 数据初始化创建表、索引、触发器并注入测试数据新建一个context.db文件然后一次性执行以下 SQL保存为init_context.sql-- 创建主表 CREATE TABLE contexts ( id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TIMESTAMP NOT NULL DEFAULT (strftime(%Y-%m-%d %H:%M:%f, now)), updated_at TIMESTAMP NOT NULL DEFAULT (strftime(%Y-%m-%d %H:%M:%f, now)), type TEXT NOT NULL CHECK(length(type) 64), scope TEXT NOT NULL DEFAULT global CHECK(length(scope) 64), status TEXT NOT NULL DEFAULT active CHECK(status IN (active, archived, deleted)), payload BLOB NOT NULL, metadata_json TEXT NOT NULL DEFAULT {}, summary TEXT NOT NULL DEFAULT ); -- 创建 FTS5 索引 CREATE VIRTUAL TABLE contexts_fts USING fts5( summary, metadata_json, contentcontexts, content_rowidid, tokenizeunicode61 remove_diacritics 1 ); -- 创建普通索引 CREATE INDEX idx_contexts_type_scope_status ON contexts(type, scope, status); -- 创建同步触发器 CREATE TRIGGER trg_contexts_fts_sync_ai AFTER INSERT ON contexts BEGIN INSERT INTO contexts_fts(rowid, summary, metadata_json) VALUES (new.id, new.summary, new.metadata_json); END; CREATE TRIGGER trg_contexts_fts_sync_au AFTER UPDATE ON contexts BEGIN INSERT INTO contexts_fts(contexts_fts, rowid, summary, metadata_json) VALUES(delete, old.id, old.summary, old.metadata_json); INSERT INTO contexts_fts(rowid, summary, metadata_json) VALUES (new.id, new.summary, new.metadata_json); END; CREATE TRIGGER trg_contexts_fts_sync_ad AFTER DELETE ON contexts BEGIN INSERT INTO contexts_fts(contexts_fts, rowid, summary, metadata_json) VALUES(delete, old.id, old.summary, old.metadata_json); END; -- 创建摘要强制触发器 CREATE TRIGGER trg_contexts_enforce_summary_ai BEFORE INSERT ON contexts BEGIN SELECT CASE WHEN new.summary OR trim(new.summary) THEN RAISE(ABORT, summary cannot be empty) END; END; CREATE TRIGGER trg_contexts_enforce_summary_au BEFORE UPDATE ON contexts BEGIN SELECT CASE WHEN new.summary OR trim(new.summary) THEN RAISE(ABORT, summary cannot be empty) END; END;执行它sqlite3 context.db init_context.sql接着用 Python 脚本批量注入 10 万条模拟数据。脚本核心逻辑是随机生成type如 git_commit, api_request, ui_interactionscope如 project_x, user_123summary重点用 faker 库生成包含热词的句子# generate_data.py import sqlite3 import random from faker import Faker fake Faker() conn sqlite3.connect(context.db) cursor conn.cursor() # 热词库模拟真实场景 hot_terms [mcp, tia mcp 260514, ruoyi-vue-pro, sqlite, fts5, bm25, codex, figma, blue, dify] for i in range(100000): # 构造高信息量 summary action random.choice([added, fixed, merged, debugged, configured]) term random.choice(hot_terms) project fake.company().replace( , _).lower() summary f{action} {term} support in {project} module [ref: {fake.uuid4()}] by {fake.name()} cursor.execute( INSERT INTO contexts (type, scope, summary, payload, metadata_json) VALUES (?, ?, ?, ?, ?) , ( random.choice([git_commit, api_request, ui_interaction]), fproject_{project}, summary, b{dummy:payload}, f{{project_id: {project}, author: {fake.name()}}} )) if i % 10000 0: print(fInserted {i} records...) conn.commit() conn.commit() conn.close()运行python generate_data.py。在我的测试机上10 万条记录插入耗时约 42 秒生成的context.db文件大小为 128MB。这已经远超大多数桌面应用和中小型后台的需求。4.3 检索接口开发用纯 SQL 实现 BM25 排序的语义搜索现在数据库有了数据也有了怎么查这才是 context-mode 的灵魂。我们不写 REST API直接用 SQLite 命令行演示最核心的查询# 查找所有和 mcp 相关的上下文按 BM25 相关性排序取前 10 条 sqlite3 context.db SELECT c.id, c.type, c.summary, c.created_at, c.rank FROM contexts c JOIN contexts_fts f ON c.id f.rowid WHERE f MATCH mcp ORDER BY c.rank LIMIT 10; # 更复杂的语义搜索找 tia mcp 260514 且发生在 ruoyi-vue-pro 项目中的上下文 sqlite3 context.db SELECT c.id, c.summary, c.created_at FROM contexts c JOIN contexts_fts f ON c.id f.rowid WHERE f MATCH tia mcp 260514 AND c.scope LIKE project_ruoyi% ORDER BY c.rank LIMIT 5;注意c.rank这个字段。它是 FTS5 自动计算的 BM25 分数数值越小表示相关性越高。ORDER BY c.rank就是语义排序的核心。你可以把它想象成 Google 搜索结果的“相关性打分”只不过这个打分是在你的本地数据库里实时算出来的毫秒级响应。在应用层比如用 C# 写的 Windows 工具你只需要用标准的 ADO.NET 或 Dapper 执行同样的 SQL// C# 示例使用 Microsoft.Data.Sqlite using var connection new SqliteConnection(Data Sourcecontext.db); connection.Open(); using var command connection.CreateCommand(); command.CommandText SELECT c.id, c.summary, c.created_at, c.rank FROM contexts c JOIN contexts_fts f ON c.id f.rowid WHERE f.MATCH query ORDER BY c.rank LIMIT limit; command.Parameters.AddWithValue(query, codex blue mcp); command.Parameters.AddWithValue(limit, 10); using var reader command.ExecuteReader(); while (reader.Read()) { Console.WriteLine(${reader[id]}: {reader[summary]} (rank: {reader[rank]})); }4.4 性能压测与调优十万条数据下查询到底有多快最后一步也是最关键的一步验证。我们用time命令对上述查询进行 100 次压测# 压测简单查询 mcp time for i in {1..100}; do sqlite3 context.db SELECT count(*) FROM contexts_fts WHERE contexts_fts MATCH mcp; /dev/null; done # 压测复杂查询 tia mcp 260514 time for i in {1..100}; do sqlite3 context.db SELECT count(*) FROM contexts c JOIN contexts_fts f ON c.id f.rowid WHERE f MATCH tia mcp 260514; /dev/null; done实测结果Rocky Linux, Intel i7-10875H简单查询平均耗时3.2ms复杂查询平均耗时4.7ms99% 分位耗时均低于 8ms这意味着即使在最差情况下你的 UI 也能在 10ms 内拿到搜索结果用户完全感知不到延迟。这比任何基于 HTTP 的远程搜索服务如调用 Elasticsearch API都要快一个数量级因为省去了网络往返RTT和序列化开销。调优的关键点有两个第一确保 WAL 模式开启。在连接数据库后立即执行PRAGMA journal_modeWAL;。WAL 模式允许多个读取者和一个写入者并发大幅提升读密集型场景的吞吐。第二合理设置 cache_size。SQLite 默认缓存很小对于 128MB 的数据库建议PRAGMA cache_size10000;约 100MB 内存缓存这能让大部分查询直接命中内存避免磁盘 IO。这两个 PRAGMA 设置应该成为你打开数据库连接后的第一行代码。实操心得不要迷信“SQLite 不适合大数据”。这里的“大”是相对的。对于 context-mode 场景10 万条记录、128MB 文件SQLite 是黄金分割点。它比 MySQL 轻量比 Redis 语义强比 Elasticsearch 确定性高。真正的瓶颈从来不是 SQLite 本身而是你有没有把“上下文”这个概念真正想清楚、建模对、用到位。5. 常见问题与排查技巧实录那些只有踩过才知道的坑在把 context-mode 推向多个项目的过程中我们整理了一份“血泪清单”。这些问题官方文档不会写Stack Overflow 上也找不到标准答案但每一个都曾让我们加班到凌晨。分享出来帮你少走弯路。5.1 问题FTS5 搜索返回空结果但数据明明存在现象INSERT了一条summary为mcp protocol debug log的记录但SELECT * FROM contexts_fts WHERE contexts_fts MATCH mcp;返回空。排查思路这不是 bug是 FTS5 的设计特性。FTS5 的MATCH查询默认只匹配词干stemmed而mcp是一个缩写没有词干变化。但更常见的原因是同步触发器没生效。检查contexts_fts表是否为空SELECT count(*) FROM contexts_fts;如果返回 0说明触发器没工作。原因通常是你在创建触发器之前就已经往contexts表里写了数据。FTS5 的同步是“增量”的只对触发器创建之后的 INSERT/UPDATE/DELETE 生效。解决方案重建 FTS5 索引。执行INSERT INTO contexts_fts(contexts_fts) VALUES(rebuild);这条命令会清空contexts_fts并根据当前contexts表的内容重新填充。这是 FTS5 最重要的维护命令务必记牢。5.2 问题summary字段包含中文但搜索“上下文”搜不到“上下文模式”现象summary是添加上下文模式支持但MATCH 上下文能搜到MATCH 上下文模式却搜不到。原因SQLite 的unicode61分词器默认按 Unicode 字符边界切分对中文就是逐字切分。“上下文模式”被切成[上, 下, 文, 模, 式]。MATCH 上下文模式会被解释为“必须同时包含这五个字”但它们在summary中是连续的不是离散的。解决方案用短语搜索phrase query。把搜索词用双引号括起来SELECT * FROM contexts_fts WHERE contexts_fts MATCH 上下文模式;双引号告诉 FTS5这是一个不可分割的短语必须按顺序、连续地匹配。这是处理中文语义搜索最简单有效的办法。当然如果业务对中文搜索精度要求极高还是建议上 jieba 预分词但 90% 的场景双引号就够了。5.3 问题sqlite3命令行里MATCH正常但 C# 代码里报错no such column: rank现象在命令行里SELECT *, rank FROM contexts_fts ...没问题但 C# 用SqliteCommand执行同样 SQL抛出异常no such column: rank。原因rank是 FTS5 虚拟表的隐藏列hidden column它只在SELECT *或显式指定rank时才暴露。但在某些 .NET SQLite 驱动版本中SELECT *的元数据解析有 Bug导致rank列没被正确识别。解决方案永远不要依赖SELECT *。显式写出所有需要的列包括rankSELECT rowid, summary, metadata_json, rank FROM contexts_fts WHERE contexts_fts MATCH mcp;这样驱动就能明确知道rank是一个合法列。这个坑我们踩了三次每次都是不同版本的驱动教训深刻。5.4 问题db browser for sqlite打不开context.db提示“database disk image is malformed”现象用 DB Browser for SQLite 打开数据库报错但命令行sqlite3 context.db完全正常。原因DB Browser for SQLite 的默认 SQLite 库版本太老不支持新版本 SQLite 的 WAL 文件格式或 FTS5 虚拟表。解决方案下载最新版 DB Browserv3.12.0或者更推荐的做法——别用 GUI 工具查 FTS5 表。FTS5 的虚拟表结构特殊GUI 工具的 Schema 解析器经常失灵。坚持用命令行sqlite3它永远是最准确、最可靠的 SQLite 诊断工具。记住sqlite3不是玩具它是 SQLite 的官方瑞士军刀。5.5 问题十万条数据sqlite查询需要多久这个问题的答案取决于你怎么问这是搜索热词里最误导人的一条。很多人看到“十万条”就本能地联想到 MySQL 的慢查询。但 context-mode 的查询模式完全不同。我们做了对比实验查询类型SQLite (context-mode)MySQL (普通表)Elasticsearch (7.10)精确 ID 查询 (WHERE id ?)0.02ms0.03ms5ms (网络序列化)精确字段查询 (WHERE type git_commit)0.05ms0.08ms8msFTS5 全文搜索 (MATCH mcp)3.2msN/A (需全文索引)12ms复杂聚合 (COUNT(*) GROUP BY type)18ms45ms200ms结论很清晰对于 context-mode 的核心场景——语义搜索SQLite FTS5 是性能、确定性、易用性的最佳平衡点。它不需要你运维一个搜索集群不需要你学习 DSL 查询语法你只需要会写 SQL。当你的产品需求是“让用户在离线状态下也能秒搜出上周的调试记录”那么 context-mode 就不是一个技术选型而是一个必然选择。最后一个小技巧在context.db文件旁边放一个schema.md文档用 Markdown 表格清晰列出contexts表的每个字段含义、约束、示例值。这个文档会成为新成员上手最快的路标。技术可以复杂但文档必须简单。这是我带团队五年总结出的最朴素的真理。