已知待探索的问题
架构层面
1. 索引颗粒度
- 索引到消息级别还是块级别？
- ES 是文档级索引，轻量化方案（SQLite FTS？内存 trie？）能否满足？
- 关键字抽取后，是否要做同义词归并（“React” = “React.js” = “ReactJS”）？
2. 压缩触发条件
- 按消息数？（每 N 条）
- 按时间？（每天凌晨）
- 按上下文窗口水位？（LLM 上下文接近上限时）
- 还是组合策略？
3. 冷备存储与回溯
- 原始消息冷备用什么存储（SQLite 归档？文件系统？）
- 回溯时是人工介入还是自动比对？
- 压缩后可信度怎么标记？是否要存储”置信度/压缩率”元数据？
4. 倒排索引增量更新
- 新消息 → 实时更新索引，一致性如何保证？
- 压缩后 → 原子替换旧索引条目还是批量重建？
- 索引膨胀后的清理策略（低频关键词是否淘汰？）
路由层面
5. 懒加载时机
- 当前输入中提取到关键字 → 查索引命中 → 加载。但：提取关键字本身就需要一定的上下文理解，是先过一轮 LLM 提取关键字，还是用轻量方法（NER / TF-IDF）？
- 效率和准确率的平衡点在哪？
6. 关联上下文加载量
- 命中索引后，加载多少上下文？整条消息？整个块？还是只加载匹配的那几段？
- 加载的内容如何注入到当前对话的上下文中（优先级、插入位置）？
7. 多个 channel 同时引用同一实体
- channelB 问张三的 React 项目，channelC 也在同时问到 → 都命中倒排索引 → 各自加载
- 同时加载的上下文总量可能很大，怎么控制？
8. 写入冲突
- 张三在 channelA 说了”项目用 Vue”，转头在 channelC 说”不用 Vue 了换成 React”
- 倒排索引里”张三 → 项目”那块应该反映最新状态，但 channelA 的历史仍记录 Vue
- 压缩时需要处理这种矛盾信息吗？
实现层面
9. 存储选型
- 倒排索引：SQLite FTS5 / 内存 HashMap / 引入 Tantivy / 自研？
- 上下文块存储：SQLite / 对象存储 / 文件系统？
- 冷备：SQLite 归档表 / 压缩存储？
10. 实体/关键词提取方案
- 轻量：jieba / HanLP 分词 + TF-IDF
- 中等：spaCy NER + 关键词抽取
- 重量：LLM 做实体提取和关系抽取
- 在 GenericAgent 中走哪条路线最合适？
11. 压缩的具体方式
群聊场景独有问题
12. 输入流分拣
- 同一 channel 的交错消息，如何判定每条消息属于哪个话题/谁？
- 前置做一个轻量分类器（规则+模型）还是直接走 LLM 理解？
13. 话题权重设计
- 时间衰减系数怎么定？线性还是指数？
- 参与度如何量化（发言次数、引用次数、@次数）？
- 话题热度是全局热度还是针对当前 agent 的局部热度？
- 权重需要实时更新吗？更新的触发条件？
14. 话题逻辑顺序维护
- 同一话题的消息可能被其他话题的消息物理隔断，逻辑上如何重组？
- 重组后的上下文块给到 LLM 时，是否要保留”时间戳”元数据？
- 一个话题中断 5 分钟后恢复，是续接还是新开？
15. 第三方中途加入
- 王五中途插入话题 A，他的上下文和历史参与度如何初始化？
- 第三方加入是否影响话题 A 的权重？
- 第三方加入前后的上下文块是否要标记”参与人变更”？
16. 分拣错误恢复
- 话题分拣错了怎么办？消息路由到了错误的上下文
- 是否需要一个”纠错机制”（用户纠正后，重新索引该条消息）
安全与隐私
17. 权限与可见性边界
- channelA 的张三说了私密信息，channelB 的李四提到张三时，哪些信息可以被路由加载？
- 不同 channel 之间是否有访问控制？同一用户的不同 channel 能否全通？
- 是否需要设计”上下文可见性”标签（public / channel-only / private）？
18. 用户身份解析
- channelA 的”张三”(Telegram id: 10086) 和 channelB 的”张三”(微信 id: wx_abc) 是同一人吗？
- 实体索引命中前，需要先做用户身份融合
- 跨平台身份映射机制如何设计？
运维层面
19. 冷启动
- 新 channel 刚建立时倒排索引为空，路由直接 pass through
- 但新 channel 聊到”React”时，历史索引已有大量 React 相关内容
- 首次触发的懒加载量可能过大 — 需要控制首次加载的上限
20. 可观测性
- 路由决策出错（加载了不该加载的上下文），如何追踪和复盘？
- 需要路由日志：触发关键字 → 命中索引 → 加载了哪块上下文 → 最终回答质量
- 日志格式和存储方案
21. 上下文生命周期
- 倒排索引和冷备数据是否持久化？agent 重启后能否恢复？
- 跨了三个月的话题，索引条目是否自动过期删除？
- 上下文冷备的保留时长策略
跨领域交叉
22. 缓存友好度作为路由参数
- 路由设计是否将 LLM 缓存命中率作为一个可调节的优化维度？
- 固定前缀区（system + 高频压缩知识）+ 差异化后缀区（懒加载块）的 prompt 结构
- 路由策略参数化：缓存友好度 vs 上下文精确度 之间的 trade-off 调节
- 增量倒排索引中记录的”高频引用片段”可作为缓存候选
- 极端情况：针对具体模型的缓存机制做路由适配
- DeepSeek：前缀 KV cache 缓存 → 路由倾向固定 prompt 前缀
- Claude：Prompt Caching（分段缓存）→ 路由可输出结构化分段
- 不同模型的缓存策略不同，路由可做成模型感知的
实现层面
9. 存储选型
- 倒排索引：SQLite FTS5 / 内存 HashMap / 引入 Tantivy / 自研？
- 上下文块存储：SQLite / 对象存储 / 文件系统？
- 冷备：SQLite 归档表 / 压缩存储？
10. 实体/关键词提取方案
- 轻量：jieba / HanLP 分词 + TF-IDF
- 中等：spaCy NER + 关键词抽取
- 重量：LLM 做实体提取和关系抽取
- 在 GenericAgent 中走哪条路线最合适？
11. 压缩的具体方式
- 摘要类压缩还是关键信息抽取？
- 同一 topic 的多轮对话，每轮独立抽取还是合并压缩？
- 压缩后丢失的信息（语气、时间细节）是否影响后续路由准确度？