Appearance
常驻 AI 问答服务的延迟预算：内存检索、分档模型、禁工具、流式回执
第二部 · Agent 实践 · 第32章
撰写日期：2026-07-13
结论
一个常驻的问答 bot，第一版又慢又飘：每条消息都冷启一个通用 Agent，注入大体量人设和索引，再让模型自主 Read / Grep 盲搜整个语料库。实测一次问答能从个位数秒飙到上百秒。
延迟的大头不是网络收发，是每条消息重复注入的固定上下文 + 模型自主检索的多轮工具回合。提速的方向是把检索前移到进程内、砍掉 Agent 回合、按置信度分档、用流式先给回执。
延迟是可以预算的：先量出每一段耗时，再逐段砍，别一上来就换模型。
1. 延迟从哪来
| 来源 | 对策 |
|---|---|
| 每条消息冷启一个通用 Agent | 常驻进程 + 进程内检索，不每次起 Agent |
| 固定注入大体量人设 / 全量索引 | 只喂检索到的少量相关片段 |
| 模型自主 Read / Grep 多轮盲搜 | 检索前移到进程内，去掉工具回合 |
| 全程走大模型 | 按置信度分档，简单问题走小模型 |
2. 内存检索取代自主盲搜
进程启动时一次性把语料建成内存索引，每次请求只做一次进程内检索，把命中的少量片段喂给模型。实测千余条材料的索引加载在亚秒级（几百毫秒）。这一步直接切掉了"模型自己多轮翻库"这段最不可控的串行开销。
3. 分档模型 + 禁工具
| 档 | 路由条件 | 模型 |
|---|---|---|
| 快 | 高置信（检索命中明确） | 小模型 + 低推理档 |
| 慢 | 其余 | 大模型，但只给检索到的材料 |
两档都禁用工具调用——材料已经在进程内检索好塞进上下文了，不需要模型再自己去取。
4. 流式先回执
不要"想完了再一次性回包"。先发一张"正在处理"的卡片，再增量更新同一张卡。这把用户感知到的首字节延迟从"整段等待"降到亚秒级。对常驻 bot，感知延迟比总耗时更影响体验。
5. 关掉无关的默认上下文
CLI 型模型常默认加载一堆插件 / 钩子 / 项目上下文，headless 跑问答时全是负担。用安全 / 精简模式把额外上下文从约 10k token 降到百量级 token——这部分是纯浪费，砍掉零损失。
6. 通用推论：本地能力优先、远端兜底、按意图分流
同一套思路适用于任何"某段处理端到端过慢"的场景。以"读截图里的文字"为例，第一性拆解各段耗时后发现瓶颈是"每张图都走远端多模态模型"（一次往返可达十几秒）：
| 路径 | 触发条件 | 手段 | 量级 |
|---|---|---|---|
| 快 | 内容是文字截图 | 本机原生 OCR | 亚秒（暖态约 0.25 秒） |
| 慢 | 本机为空 / 低置信，或问题本身需要视觉理解（配色、布局） | 回退远端多模态模型 | 十几秒 |
配套三条：按内容哈希做结果缓存避免重复识别；渐进卡片让首个可用结果尽早可见；把耗时任务移出事件主循环、按会话有序排队，别阻塞主链路。用"意图"（读字 vs 看视觉）决定路由，能在不牺牲识别完整性的前提下把常见路径提速一个数量级。