Context Mode
Context Mode 架构：内容检索与时间线检索走的是不同路径
沿 searchAllSources 理解 ContentStore、SessionDB 与自动记忆，辨认部分失败、时间戳假设及项目过滤边界。
你将学会
- 相关性与时间线模式查询不同来源组合。
- 升序后限量不是最新 N 条时间线。
- 回退时间戳与部分结果需要明确解释。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- 相关性与时间线模式查询不同来源组合。
- 升序后限量不是最新 N 条时间线。
- 回退时间戳与部分结果需要明确解释。
从真实搜索入口开始
src/search/unified.ts 提供 searchAllSources，它总会尝试 ContentStore 搜索。在默认 relevance 排序下，本函数处理的就是这个来源，不会额外查询 SessionDB 和自动记忆。使用 timeline 排序时，它才尝试另外两个来源并合并结果。当读者疑惑某个历史决定为何没有出现在相关性检索中，这个区别非常关键。
ContentStore 内部用 SQLite 全文索引做词法匹配与排名，这不同于通过嵌入模型召回语义相似段落。会话数据库和适配器感知的记忆搜索是额外信息源，不是同一张表的别名。架构图应把存储与查询分支分开，让各自的失败行为和保留策略保持可见。
先理解顺序，再称其为历史
时间线结果会将 SQLite 风格时间戳规范为类似 ISO 的字符串，按升序排列，再按请求上限截取。因此，这个实现的有界时间线并不自动等于最新 N 条。如果候选中有很多带日期的匹配项，较早条目可能占满返回窗口。应结合问题检查排序，而不是把第一项理解为最近事件。
缺少时间戳的 ContentStore 条目会得到本次搜索开始时记录的时间。变量虽然叫 sessionStartTime，但赋值使用函数内的当前时间，因此不能证明原始事件或索引发生时间。审计界面应区分真实时间戳与这种回退值，不能把每一行都呈现成精确计时的历史记录。
谨慎解释部分结果与项目范围
每个来源的搜索都有独立错误捕获，因此一个来源失败时其他来源的结果仍可返回。这提高可用性，却意味着看似合理的答案仍可能不完整。所查代码仅在开启相应调试标记时把这些捕获错误写入 stderr。生产评估应测试来源失败并寻找不完整证据，而不只是检查结果列表非空。
当提供字符串 projectScope 和 SessionDB 时，函数会解析允许的会话 ID 集合，用于过滤 ContentStore。存储层有意保留会话 ID 为空的旧块；若解析允许集合失败，局部变量保持 undefined。这些源码现象提示应在其他层验证严格隔离：仅此辅助函数并非租户安全保证，也不代表所有调用方的完整保护。
实施步骤
- 1
分别追踪 relevance 和 timeline 调用。
- 2
构造带日期样例并比较限量结果顺序。
- 3
让一个测试来源不可用并检查诊断。
- 4
用有归属与旧版无归属样例验证项目边界。
可复制示例
relevance -> ContentStore -> 排名结果
timeline -> ContentStore + SessionDB + 自动记忆
-> 规范时间戳 -> 升序 -> 限量
缺失来源时仍可能返回部分结果。常见问题
相关性模式总会检查历史会话吗？
所查 searchAllSources 中不会：SessionDB 和自动记忆调用位于 timeline 分支内。
所有时间线时间戳都能用于审计吗？
不能。ContentStore 结果缺少时间戳时，会回退为当前搜索调用时间。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07