第 5 卷

还要留意 complete 只管往上这半截：后代是把现有语料库扫一遍、按 parentSession 归出来的。没被收录的后代，服务压根不知道它存在，所以往下没有断链这回事。

还有更坏的一种：成环。正常世界里谱系是一棵树，但数据被改坏时（A 的父是 B、B 的父又是 A），顺着 parent 追会回到已经见过的会话。它不装作没看见，也不陷进死循环，而是直

接报错：错误码是 SESSION_QUERY_INVALID_LINEAGE。宁可喊停，也不给你编一条链。

顺带一提（不是本讲重点）：事件之间的关系不在这套谱系里——listEvents 只报得出某条消息 surface: shadowed，报不出谁顶掉了它；补这个缺口的是 traceEvent()

（拿关系）和 readEvent()（拿内容）。lineage-demo.ts 跑起来，谱系这两段之后还会多出压缩、traceEvent、readEvent 三段输出，跳过即可。

模型工具：五个工具与工作区边界

session_search——跨会话搜索（searchSessions()）；

session_event_search——会话内搜索（searchEvents()）；

session_trace——会话谱系（traceSession()）；

session_event_trace——事件关系（traceEvent()）；

session_event_read——读一条事件加前后窗口（readEvent()）。

后两个是事件级的，本讲不展开——上一节末尾已经顺带提过。

先定“查哪个会话”。工具都在某个会话里被调用：四个用 session_id，省略即“我自己”，也可填别人的 id；session_search 用 session_ids（复数，可选），不填就是整个工作

区，但结果里排除你自己——session_event_search 还再排除当前 step 写下的内容。

再过工作区这一关。要查别人，两边的 cwd 必须一模一样。过不了就是看不见：泛搜进不了结果，点名查直接抛 SESSION_QUERY_TOOL_UNAUTHORIZED；即便在谱系里撞见，也只留

一行占位（如 [outside workspace]）。自己没有 cwd 时，就只剩查自己这条路。

本讲小结

今天这一讲，我们把目光从一个会话转向一批会话：看它们怎么被读、被搜、被追。

读是四个入口：同一个 id 可能同时在内存里跑着、在磁盘上躺着，服务把两处合成一份逻辑语料库，内存优先，两边都没有才真查不到。四个方法各管一个问题：header、完整日志、事

件归属、当前表层，拿到的都是副本。

搜是两条腿。全文搜索按 token 匹配，快，但卡在 token 中间的子串搜不到；精确过滤补上这一块：元数据圈定范围，text 子句逐条扫字面子串兜底。

追谱系全靠 header 上那一个 parentSession：往上是链、往下是树，一次

末尾那件收尾的事：这套能力被包成五个模型工具，访问别的会话只认“同一个工作目录”这一条边界。

这背后真正的变化是：你不再只把日志当成会话自己继续跑要用的东⻄，而是把它看成能跨会话按问题去查的数据：能读、能搜、能追；让查询返回副本，另有一份可随时扔掉的派生索

引，日志一个字节不动。

这，就是会话查询的核心——查法可以很多，历史只有一份：同一份日志，谁都能按自己的问题反复去查，而它本身从不变动。

跨会话查询到这里就讲完了，但核心篇里还有最后一个我们尚未触及的重要问题。下一讲，我们来看上下文边界。

注：本讲 GitHub 链接

思考题

动手实操：打开 search-demo.ts，把第 50 行 searchSessions({ query: 'crash' }) 里的 'crash' 改成半截的 'cras' 重跑，FTS 预期命中 0 个（那行标签是写死的，仍

会印「crash」，忽略即可）。

在 search-demo.ts 里补一句 filterEvents(SessionId('sess-b'), [{ kind:

'text', text: 'cras' }])，对 sess-b 搜同一个词，预期拿到 1 条（seq 2，就是那句带 crash 的回答）。同样是半个词，一个 0、一个 1——差在哪？分界线不在中英文，而在

是否恰好是一个完整 token。

小改动：在 lineage-demo.ts 造完 sess-grandchild 那行（第 82 行）后补一句 ctx.sessions.fork(child, undefined, SessionId('sess-sibling'))，从

sess-child 再分出一个兄弟。别的代码都不用改，重跑 npm run