AccessAI：本地多模型对话的上下文与历史管理实战

AccessAI 这个开源项目，我断断续续维护了不短时间。起因并不复杂——我自己的工作日常离不开多模型并存：写代码时习惯调用代码理解能力强一些的模型，改文档时换长文本处理顺手的，头脑风暴又会想切到表达风格更松弛的另一个模型。过去在这几个服务之间来回跳，最累的从来不是等回答，而是每次切换工具都要把前因后果重新给模型讲一遍。AccessAI 最早的版本就是从这里长出来的：把多个模型收进同一个入口，把对话上下文留在自己能掌控的本地，把历史记录整理成随时能翻回来的资产。

这次更新的标题里四个词没有一个是虚的：新界面、多模型、对话上下文、历史管理。我按实际开发的顺序把这四条主线拆开讲，再把开发过程中踩过的那几个大坑一并交代清楚。如果你也在做同类聚合类 AI 工具，或者只是对“怎么把多个模型服务真正用顺手”这件事感兴趣，这篇内容应该能给你省不少试错时间。

1. 为什么会有 AccessAI：不是模型不够，而是会话上下文散了

1.1 我原来的多模型工作流，乱在哪

在动手写 AccessAI 之前，我的工作状态是典型的“多标签页流浪”。一个浏览器窗口里开着多个模型服务的对话框，每个对话框都有一段独立的故事线。比如上午在 A 模型里讨论某段代码的重构方案，下午要换到 B 模型去让它做 Code Review，问题就来了：B 模型根本不知道上午讨论了什么。

那时候唯一能做的，就是把 A 模型会话里的关键代码、约束条件、已经讨论过的结论手动复制出来，重新贴到 B 模型里。一次两次还能接受，次数多了你会明显感觉到思路被打断。更难受的是历史记录分散在各家手里：几天后想回忆当时为什么那么设计，得先回忆当时用的是哪个服务、大概在哪个日期，然后一个页面一个页面翻。

这种“上下文断裂”其实是很多 AI 工具使用者的常态，不一定是因为模型能力不行，而是会话本身没有一个统一归属地。

1.2 为什么没有直接选现成全家桶

市面上并不是没有一站式聚合产品，但我要的不是一个多入口套壳，而是几个更具体的东西：

第一，数据要留在本地。聊天记录包含大量项目细节甚至草稿，我不太想每一次思考都默认沉淀到别人服务器上。

第二，能自由接不同模型。今天大家说 A 模型最强，明天可能 B 模型在某些任务上反超，如果工具本身把模型写死，升级成本很高。AccessAI 要做的是“随时换引擎”，而不是“选定一辆车”。

第三，界面交互要按自己习惯长。多模型工具最大的价值，是让人把注意力放在对话内容而非工具本身。现成产品总是有些交互不符合直觉，小到切换模型的点击次数，大到历史记录的组织方式，自己维护一个开源项目的自由度完全不一样。

所以 AccessAI 不是想把所有模型能力“包一层皮”给你，而是想做一个本地优先、支持多模型、带完整会话和历史的对话基础设施。

1.3 这次更新具体动了哪四块

这里可以先给一个全景，后面每个章节再展开：

• 新界面：把主界面从“功能型控制台”改成“对话型工作台”，把会话、消息、模型状态之间的层级理顺。
• 多模型：新增统一的模型接入抽象，不再每个模型单独写一套调用逻辑，同时支持同一会话内快速切换模型。
• 对话上下文：解决多轮对话真正“接得上”的问题，包括 token 预算控制、超长会话压缩、切换模型后上下文完整性处理。
• 历史管理：引入结构化存储与会话索引，支持搜索、导入导出、清理策略，重构记忆归属感。

这四条线看起来互不相关，实际动手做以后会发现它们深度耦合：界面要显示上下文占用，就得从对话上下文模块拿数据；对话上下文要组装历史，又依赖历史管理存储的消息；多模型 Provider 的能力差异又会反向影响上下文压缩策略。这也是我为什么坚持把这些事完整讲一遍，而不是只发一个 Release Notes。

2. 新界面：把“管理工具”改成“能安心聊天的桌子”

2.1 旧版为什么到了必须改的时候

AccessAI 早期版本的功能并不少，但界面的底层思维是“配置管理”。主窗口有一个巨大的设置区，模型参数、Prompt 模板、历史列表全都挤在一起。功能确实能用，问题也很显眼：每次想发起一次对话，得先经过一堆配置项的“审视”，而多数情况下我只是想快速开口问一句。

界面设计上有一个我一直认同的评价标准：一个工具如果让用户频繁进行无意识的状态整理，那它就不是在工作，而是在制造工作。旧版的会话列表、消息正文、模型参数之间缺少清晰主次，尤其当会话变长以后，用户很难一眼看出当前对话处在什么状态、用的是哪个模型、上下文还剩多少。

这次改版本质上不是“换皮肤”，而是把内容层级重新划了一遍。

2.2 新主界面怎么布局

新界面采用的是一个非常克制的三栏结构：

• 左侧是会话历史栏，宽度默认可折叠，用来做会话列表、搜索和新建会话入口。
• 中间是主对话流，所有的消息渲染、流式输出、代码块交互都集中在这里。
• 右侧是当前对话的上下文检查器，展示当前使用的模型、上下文占用估算、临时总结状态等实时信息。

这套结构和很多代码编辑器的布局逻辑是一致的：左侧管“文件”，中间管“编辑”，右侧管“状态”。会话历史对应“文件树”，对话流对应“编辑器”，右侧则像一个集成终端和问题面板。好处是，用户找到某一会话就像在 IDE 里打开历史文件，切换成本明显降低，不会在多个窗口里迷路。

中间主对话流设计上只有一个核心原则：消息必须连续、可追溯。同一会话的消息按时间顺序单向滚动，每条消息带上模型标签和相对时间，不用刻意强调“这是 A 模型回答的”，而是把它当成对话流中的一个自然组成部分。如果某条回答你用了另一个模型重新生成，旧消息仍然保留，不覆盖，只把新的结果追加进去，方便后续对照。

2.3 快速切换模型与上下文占用提示

多模型界面最大的交互难点是“切换模型的成本”。旧版里切换模型需要进入设置面板，改完以后再回到会话，来回耗掉不少注意力。新版把模型切换器直接做到输入框上方，按下快捷键就能弹出候选模型列表，选完直接在当前会话中生效，不需要新建会话。

这里有一个很容易被忽略的细节：切换模型不只是换一个“发送者”，还涉及上下文窗口大小的变化。比如当前会话的完整历史在旧模型下占用 60K token，切换到窗口只有 32K 的新模型后，历史直接超出限制。如果工具不管不顾地把完整消息发过去，服务端大概率直接报错。

我们的处理是把这一步放到模型切换动作里同步完成。切换前会对历史做一次 token 估算，若超出目标模型的可用预算，先弹出上下文压缩确认面板，让用户决定是缩小历史范围、触发自动摘要，还是单独开启一个新会话。界面右下角的上下文占用条也实时显示当前估算值，到不同颜色的阈值时有视觉提醒，避免把问题拖到请求失败的最后一刻。

2.4 界面背后的状态同步设计

界面改版做得再好看，底层状态如果还是散落的，用几天就会原形毕露。AccessAI 这次把界面状态管理收敛成三个核心边界：

• 会话列表状态：只关心有哪些会话、每个会话的标题、最后活跃时间。
• 当前会话状态：关心消息流、正在发送状态、上下文估算、模型选择。
• 连接器状态：关心每个 Provider 是否可用、当前网络请求的状态、取消信号。

这三个边界之间通过明确的订阅接口通信，而不是所有的组件都去直接读写同一个全局对象。这样做的直接收益是，流式输出时左边历史列表的“最后更新时间”和中间消息流可以分别刷新，不会因为一句消息就整页重绘。对于长会话，中间消息区我同时用了虚拟滚动，上千条消息时滚动依然能保持稳定帧率。界面做到这一步，才算是配得上“能安心聊天”这个目标。

3. 多模型接入：做一层 Provider 抽象，比对接十个 SDK 更值

3.1 Provider 抽象层应该长什么样

多模型接入最忌讳的事情，是在业务代码里到处写 if (model === 'xxx')。今天加一个新模型要动十几个文件，明天切一个模型还得保证所有分支都改对了，这种代码维护三个月就会变成事故现场。

AccessAI 在接入多家模型服务时，核心思路是定义一个足够小但覆盖全部差异的 Provider 接口，所有上层业务只面对这个接口编程。简化后的 TypeScript 接口大致长这样：

typescript复制export interface Provider {
  id: string
  label: string
  models(): Promise<ModelDescriptor[]>

  chat(req: ChatRequest, signal?: AbortSignal): Promise<ChatResponse>
  stream(req: ChatRequest, signal?: AbortSignal): AsyncIterable<StreamDelta>
  countTokens(text: string): number
}

这里的几个方法都对应多模型场景里的现实需求：models() 用来拿到这个 Provider 当前支持哪些模型；chat 和 stream 分别处理非流式和流式请求；countTokens 是本地上下文预算的关键依赖，所以接口里必须显式暴露。

各家模型服务的 API 格式不尽相同，但绝大多数差异可以通过适配器模式挡在 Provider 内部。例如某些服务是 OpenAI 兼容协议，Adapter 层可以直接做协议映射；另一些服务参数差异较大，则单独写一个适配器对齐到统一接口。核心目标是从业务层视角看，所有模型都只是“一个能聊天的对象”，而不是一个又一个需要特殊对待的 SDK。

3.2 模型能力清单不能只有名字

很多聚合工具的模型列表只是一个个字符串，但实际场景里，不同模型的能力差异很大。有的模型上下文窗口长，有的模型支持视觉输入，有的模型工具调用能力强，如果不把能力建模出来，上层做界面和上下文策略就会很吃力。

AccessAI 给每个模型维护一份能力描述，关键字段包括：

这些字段有两个重要用处。第一，界面层输出上下文占用时，不是按照拍脑袋的比例算，而是基于 Provider 返回的真实预算；第二，当用户上传图片或开启工具调用时，模型列表里不支持这些能力的模型会被灰掉，并在旁边给出原因。这种做法能去掉大量“选了又不能跑”的尴尬。

3.3 并发请求、取消与失败重试

接入多家 Provider 后，最容易翻车的不是“聊天能通”，而是请求生命周期管理。

首先是取消。用户在界面等得不耐烦，点了停止生成，这不只是 UI 上一个状态变化，而是必须向底层网络发出真正的 AbortSignal。否则后端请求还在继续烧 token，用户却以为自己已经取消了。AccessAI 在整个 Provider 接口里都带上了 signal，停止按钮会触发一次真正的 abort 级联。

其次是失败重试。不同模型服务商的错误类型差异很大：有的是限流、有的是临时网络波动、有的是内容审核拦截。重试逻辑不能一概而论，对不可重试的错误类型一律不重试，否则会放大消耗。可重试的错误通常会做指数退避，第一次等 1 秒，第二次 2 秒，最多重试三次，并且每次重试之间界面上有明确提示。

最后是同一模型并发多个请求的问题。用户可以在一个会话里点重新生成的同时又发起新问题，也可能在多个会话间快速切换。每个请求都必须有一个唯一 request ID，收到流式分片后先按 ID 归组，再更新对应会话的消息流，避免两个请求的数据写进同一条消息里。

3.4 API 密钥与本地保密

多模型接入必然涉及 API 密钥管理。AccessAI 的原则是：密钥只存放本机，不进入项目配置公开区域，不写入日志，不上报到任何统计服务。项目配置目录统一用运行时提供的用户级数据路径，同时给不同操作系统做对应的权限处理。如果你要 fork 这个项目，我也强烈建议不要把多云密钥硬编码在任何示例文件里。

这里插一个容易踩的坑：在调试流式输出时，日志里打印请求体，很容易不小心把 Authorization 头里的密钥打出来。AccessAI 的开发环境日志层做了统一脱敏处理，凡是包含 Authorization、api_key、access_token 的字段一律打上掩码，这样在公开 issue 里贴日志也不会泄露敏感信息。

4. 对话上下文：想让模型“记住”，背后是一套精打细算

4.1 上下文的三层来源

所谓“对话上下文”，不是一个简单的消息数组。AccessAI 在向模型发起请求时，实际上要把三层内容组装成一个请求体。

第一层是系统指令。这包括用户在设置里维护的长期 Prompt，也包括项目自动注入的一些行为规范，例如“你是 AccessAI 里的代码助手，回答尽量简洁”。系统指令优先级最高，通常不能因为上下文过长而被压缩掉。

第二层是动态摘要。当会话非常长时，早期细节会被提取成一到两段“先前的会话总结”，作为压缩后的背景信息。这让模型不必看到全部原始历史，也能大致接上上下文。

第三层是最近的若干条原始消息。这是真正影响模型接下来回答质量的关键部分，需要尽量原样保留。

这三层缺一不可：没有系统指令，对话会失去基础设定；没有动态摘要，窗口很快会被塞满；没有近期原始消息，摘要粒度太粗会让回答失去细节。

4.2 会话消息怎样组装成请求

很多人在做多轮对话时，只是简单地把 messages 数组一股脑发给模型。AccessAI 的做法复杂一些：每次发送前先经过一个上下文构建函数，而不是直接把数据库里的原始记录发出去。

下面是一段简化后的组装逻辑思路：

ts复制function buildRequestContext(session, selectedModel) {
  const budget = selectedModel.contextWindow - selectedModel.maxOutput

  // 无论如何都保留系统指令
  let used = estimateTokens(session.systemPrompt)
  const parts: MessagePart[] = [
    { type: 'system', content: session.systemPrompt }
  ]

  // 如果存在动态摘要，紧跟系统指令一起注入
  if (session.summary) {
    const summaryText = `以下是更早之前对话的摘要：${session.summary}`
    const consumed = estimateTokens(summaryText)
    if (used + consumed < budget) {
      parts.push({ type: 'system', content: summaryText })
      used += consumed
    }
  }

  // 从后往前挑选最近消息，直到预算边界
  for (const msg of [...session.messages].reverse()) {
    const cost = estimateTokens(msg.content)
    if (used + cost >= budget) {
      break
    }
    parts.unshift({ type: msg.role, content: msg.content })
    used += cost
  }

  return { parts, usedTokens: used }
}

这段代码的细节不一定要照抄，但有两个思想值得保留：第一，组装顺序是“系统指令优先、摘要次之、最近消息兜底”，顺序颠倒会让模型对优先级产生误判；第二，预算不是简单的“超过就截断”，而是从尾部往前选，保证最近的内容永远有最高优先级。

4.3 Token 预算与上下文压缩的四种策略

本地估算 token 数，本质上不可能做到和每个模型服务完全一致。不同模型使用不同 tokenizer，中英文混合场景下字符和 token 的换算比差异很大。AccessAI 的做法是本地先用近似算法估算，把估算值当作“配额参考”，请求真正返回以后再用响应里的 usage 字段更新真实计量。这样长期使用下来误差会被持续修正，不会越偏越远。

当会话超过目标模型预算时，光靠截断是不够的。AccessAI 实现了四种递进式压缩策略：

自动摘要这个策略我尤其想多说一句。它不是在每次请求前都触发，而是在一条新消息即将超出预算时才异步运行。触发后，把最早一部分历史消息发送给摘要模型，生成一段精炼的背景总结，然后存成会话的 summary 字段。这个过程不能让用户等太久，也不能阻塞主对话流，所以实现上是走后台任务，完成后通过更新会话状态通知界面。

4.4 流式输出场景下，上下文保存的时序陷阱

上下文更新的时序问题，是这次开发中反复复现的一类 bug。多模型服务大多支持流式输出，模型是一个字一个字往外蹦的，如果每收到一个分片都去更新数据库里的消息内容，会出现很多奇怪问题。

例如用户中途点了停止生成，但此时已经收到的分片需要作为一个不完整的 assistant 消息保存下来。如果不保存，界面下一次重开会话时消息就丢了；如果保存，需要给这条消息打上一个“生成中断”的标记，避免系统把它当作完整答复继续构建上下文。AccessAI 的处理方式是：流式过程中只在内存里做增量拼接，一条消息收到结束事件后，才把完整文本写入历史存储。如果流被撤销，则写入已完成部分，并标记为 interrupted。后续请求组装上下文时会跳过这些中断消息，不让半截话进入模型输入。

另一个时序问题是并发响应乱序。用户在等 A 模型回答时又切换模型重新生成，两个请求同时在流式输出。若没有请求 ID 做隔离，很容易出现后响应把先响应的内容覆盖的问题。AccessAI 在消息流组件里维护了一张“正在流式响应”的表，任何分片只有通过请求 ID 找到对应占位消息后才会渲染，来源不明的分片直接丢弃并记日志。

5. 历史管理：本地数据层怎么设计，才经得住长时间用

5.1 历史消息的存储结构

AccessAI 早期版本把历史记录存在一个 JSON 文件里。会话少的时候没问题，用到两三个月后，文件体积上去，每次写入都是整文件覆盖，不仅慢，还有很大的概率在进程异常退出时把整个历史文件写坏。

这次历史管理重构，直接换成了 SQLite。选用 SQLite 的原因很直接：单文件、免部署、事务能力强，对本地优先的桌面工具极度友好。历史记录不再需要手动管理多个互相引用的 JSON 文件，一次事务可以同时更新消息和会话元数据，不用担心写到一半断电导致数据错乱。

简化的表结构大致是这样：

sql复制CREATE TABLE sessions (
  id TEXT PRIMARY KEY,
  title TEXT NOT NULL DEFAULT '新会话',
  model TEXT,
  system_prompt TEXT,
  summary TEXT,
  created_at INTEGER NOT NULL,
  updated_at INTEGER NOT NULL
);

CREATE TABLE messages (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  session_id TEXT NOT NULL,
  role TEXT NOT NULL,
  content TEXT NOT NULL,
  provider TEXT,
  model TEXT,
  tokens INTEGER,
  interrupted INTEGER DEFAULT 0,
  created_at INTEGER NOT NULL,
  FOREIGN KEY (session_id) REFERENCES sessions(id)
);

CREATE INDEX idx_sessions_updated ON sessions(updated_at DESC);
CREATE INDEX idx_messages_session_time ON messages(session_id, created_at);

sessions 表里特意放了 summary 字段，这就是对话上下文模块生成的动态摘要。把它放在会话级别而不是塞在某一类特殊消息里，好处是读历史列表时不需要跑到每条消息里翻摘要；生成和读取摘要都可以通过一次简单查询完成，不干扰正常消息流。

5.2 会话检索、改标题与删除策略

历史数据一旦积累起来，最核心的需求是“能找到”。会话列表默认按照 updated_at 倒序排，这是绝大多数人翻历史时的心理模型：越近用的越靠前。搜索框不仅搜标题，也会对消息内容做匹配，这样很多时候只记得某句话的碎片，也能把对应会话捞出来。

会话标题默认取第一条用户消息的前十几个字符。这条规则简单，但实际效果不错：大多数情况下，第一条消息确实能代表这轮对话主题。如果用户不满意，也可以手动改名，改名后会加一个标记，自动标题逻辑就不会再覆盖它。这个小设计避免了“每次回到旧会话名字都变掉”的挫败感。

删除策略上，我们没有把删除做成彻底抹除。AccessAI 在数据层做了软删除：被删除的会话先进入一个“回收站”状态，保留 7 天后才真正物理清除。这样做的好处不止是给误删留了后悔药，更关键的是它支持用户在一个会话里“删除某些消息”时，背后可能还需要保留 session 元数据供上下文模块使用。很多刚开始做历史管理的开发者会忽略这个细节，一旦用户删除关键消息，整个会话的摘要信息也一起没了，后续对话就彻底断片。

5.3 导出与导入，不只是 JSON 倒腾

本地优先的工具如果做成了数据孤岛，等于把用户关进笼子。AccessAI 的导入导出功能在设计时定了一个原则：所有长文本内容都可以无损还原到任何环境。

导出格式提供 JSON 和 Markdown 两种。JSON 面向完整备份，包含会话内所有元数据，方便迁移；Markdown 面向“我想把某段对话直接贴进文档”的轻量场景，按会话结构逐条渲染，代码块保留语言标注。导入时兼容同名会话的合并：如果导出的会话 ID 已存在，默认创建一个副本而不是覆盖，避免用户在切换电脑时把原本的对话冲掉。

很多人会忽略导出文件本身的体积。如果某个会话里贴过大量长文档，Markdown 导出可能有几百 KB，对于人类阅读倒没什么，但 JSON 导出时要统一处理换行和 Unicode 转义，避免在 Windows 上导出后出现奇怪的乱码。AccessAI 在导入模块里对编码做了显式 UTF-8 校验，文件头带 BOM 的情况也会自动剥离。

5.4 一个测试了很久的边界：空会话与失败消息

历史管理里有些边界场景不测试是发现不了的。

空会话——用户新建了会话但一句话都没发过。这种 session 在历史列表里算不算数？AccessAI 的处理是：创建后如果在 5 分钟内没有任何消息，自动不进入活跃列表；但用户手动命名过标题的空会话除外，因为它可能是用户有意准备的草稿。这条规则看着小，却很影响历史列表的整洁度。

失败消息——网络超时、模型接口报错、用户主动取消，都会产生“不完整的消息”。如果这些消息直接进入历史存储，后续翻聊天记录会看到一排红叉，既误导又占空间。AccessAI 的做法是把请求失败的 message 存储为独立错误记录，不进入正常上下文组装路径，但在界面上以可折叠错误条展示，点击后能看到具体错误信息。这样用户知道刚才那次失败发生过，却又不会被失败消息污染后续对话。

6. 更新路上的几个大坑和留给贡献者的交接笔记

6.1 模型切换后上下文翻倍计费的问题

这次重构中我最早遇到的一个严重 bug，是模型切换后 token 消耗莫名翻倍。排查了半天，根因出现在“消息组装被调用了两次”：用户点击切换模型时，界面为了预览新模型下的上下文占用，提前调用了一次上下文构建函数；那个函数无副作用倒还好，但在当时的实现里，它会顺手把已组装的消息缓存写回临时状态。等用户真正点发送，组装函数又基于缓存的半成品跑了一次，结果历史消息被重复注入。

解决方法是把“估算”和“组装”彻底拆成两个纯函数，估算过程绝不写状态。这个教训对所有做类似的界面预览功能都适用：不要在一个应该只读的计算里偷偷做写入，哪怕当时觉得“顺手”。

6.2 多模型并发请求导致消息乱序

另一个印象深刻的 bug 和并发写入有关。用户在会话 A 里请求 GPT 类模型，又切到会话 B 请求另一个模型，两边都在流式返回。问题出在消息持久化层：我一开始写入时直接依赖 SQLite 的自增 ID 作为排序依据，但两个会话共享同一个表，自增 ID 只能反映写入顺序，不能反映会话内的先后顺序。一旦某一方网络延迟，另一方的写入会先落库，导致同一个会话里消息时间线偶尔出现前后颠倒。

修复方式是彻底放弃用自增 ID 做业务排序，所有查询都强制走 created_at 时间戳，并且时间戳统一由应用层生成而不是依赖数据库默认值。为了兼容历史版本已经错误落库的数据，迁移逻辑里会做一次会话内按时间戳重排。

6.3 消息量大时，界面的“假死”与内存泄漏

历史消息一旦到了几千条，直接渲染所有 DOM 节点会让界面明显卡顿，甚至滚轮都开始发飘。AccessAI 的解法是在消息流区域引入虚拟列表，只渲染视口附近若干条消息。但这里有个新问题：消息内容很多是长代码块，虚拟列表对不定高内容的处理很麻烦，如果每行都做高度估算，滚动时会频繁跳动。

我们最后采用“二分高度缓存”方案：每条消息渲染后把实际高度记录到内存缓存，滚动时先用缓存高度做占位，等真正进入视口再按真实高度修正。应对几十万条消息数据时不至于瞬间耗尽内存。另一个隐藏很深的内存泄漏来自流式输出事件监听器：用户反复切换会话时，旧会话的监听器没有及时移除，导致内存里堆积了大量游离分片。修复很简单：所有流式订阅都走统一的订阅管理器，在会话切换时统一 unsubscribe，而不是每次新建一个监听。

6.4 中文搜索为什么这么难

历史管理的搜索框，在中文场景下远比英文复杂。SQLite 自带的 FTS5 分词器对中文支持不友好，默认按 Unicode 字符边界处理，搜索“对话上下文”时，用户输入“上下文”不一定能精确命中，因为分词并不是基于语义的。直接拿 LIKE 做全表扫在数据量一大之后又会很慢。

AccessAI 最终的搜索实现是“混合检索”：搜索框先匹配会话标题，这个过程走普通索引；再匹配消息正文，这里用 FTS5 建立支持 Unicode 的索引，同时把连续 CJK 字符当成一个整段输入分词；另外再做一层简单的拼音首字母索引，虽然初期覆盖不到全部消息，但至少能帮用户从标题里快速定位会话。中文全文检索是个很深的坑，没有银弹，但先把标题搜索做好已经能解决大部分“翻历史”的需求。

6.5 给想参与贡献的人几句实在话

如果你打算 fork 或者给 AccessAI 提 PR，我会建议你先从“多模型”或者“历史管理”这两个模块入手，而不是上来就改界面。原因是界面部分涉及大量状态同步和视觉细节，没有充分了解交互模型前很容易好心办坏事；而 Provider 适配器和数据迁移逻辑都有清晰的边界，顺着现有接口加一个适配器，可以很快提交一个完整且有价值的贡献。

提交 PR 前请一定跑一遍已有的数据迁移测试，尤其是模拟旧版本 JSON 历史导入新版本数据库的场景。历史数据一旦损坏很难人工修复，这是整个项目里最需要谨慎对待的地方。如果不知道怎么上手，可以先尝试 mock 一个新的 Provider 并补上对应测试，这一步能帮你快速理解整个上下文组装链路。

AccessAI 目前还在快速迭代阶段，里面有不少设计是我在实际使用中反复摩擦之后才定下来的。写到这里回头看，新版真正解决的不只是“支持更多模型”，而是把一个散的流程收拢成了一个完整的记忆环：界面负责当下，Provider 负责连接，上下文负责连续性，历史负责沉淀。这四个环节缺一个，所谓的多模型工作流都只是一堆功能开关的拼盘。