如何在2秒内浮现正确的笔记OpenOats实时建议三层并发架构设计全解析【免费下载链接】OpenOatsA meeting note-taker that talks back.项目地址: https://gitcode.com/gh_mirrors/op/OpenOatsOpenOats 是一款开源的 macOS 会议笔记助手A meeting note-taker that talks back它能实时转写会议双方对话并在关键时刻从你自己的笔记库中浮现相关建议。本文深入解析 OpenOats 实时建议引擎的三层并发架构设计它如何用不到 2 秒的延迟把最该说的数据点、客户反馈和定价依据推到屏幕边上的浮动面板中——让你在对方面前显得有备而来。为什么旧的 5 级串行管道不够快在重构之前OpenOats 的建议管道是5 级串行执行每一句话定稿后要串行完成 3 次 LLM 往返还带着一个 90 秒的冷却期端到端延迟高达5~10 秒以上。在真实的销售通话里对方问完问题 5 秒之后才弹出建议早就没人看了。新架构的核心目标只有一个从对话触发到建议可见控制在 2 秒以内。完整的设计动机与数据流图可以见官方设计文档 2026-03-26-realtime-suggestions-design.md。三层并发架构总览新引擎用一个统一的调度类 SuggestionEngine.swift 驱动三条并行工作、互不阻塞的层层职责触发时机延迟预算第一层持续上下文累积后台预取知识库 追踪对话状态会议全程持续运行不占用建议时间线第二层即时检索与门控本地启发式闸门 缓存命中检索任一方话语定稿时目标 100ms第三层流式 LLM 合成快速模型逐词流式生成洞察建议浮现后立即并行流式覆盖原始片段关键思想用户看到的第一眼永远不需要等待 LLM。原始知识库片段先上屏LLM 合成结果随后以流式方式原地升级它。第一层持续上下文累积让检索抢跑第一层是三个投机性工作的集合核心原则是任何工作都不阻塞建议交付。周期性知识库预取会议进行中引擎每隔约 4 秒preFetchIntervalSeconds可配置抓取当前滚动的部分转写文本取最近约 40 个词提前执行一次知识库检索并把结果存入指纹缓存。实现见 SuggestionEngine.swift 中的startPreFetching()与runPreFetch()。缓存本身是 PreFetchCache.swift 里的一个 Swiftactor线程安全规则很克制文本指纹小写化、取最后约 50 个词作为缓存键重复的文本窗口不会重复检索TTL 30 秒过期条目自动驱逐最多保留 20 条这意味着当第二层真正被触发时检索结果大概率已经在缓存里了命中耗时 0ms。后台对话状态跟踪器每隔 2~3 句定稿话语引擎会用你的主模型异步调用一次 LLM把ConversationState当前话题、简短摘要、未决问题、活跃分歧、近期决策、对方的目标更新到共享状态中SuggestionEngine.swift。其他层只读、不等待这份状态——它让第三层的合成提示词自带这场会聊到哪了的上下文。一个容易被忽略的前置工程为了让第一层抢跑转写层本身被改造为在说话进行中每 250~500ms 发出一次尽力而为的部分假设见 StreamingTranscriber.swift而不是只等整句定稿。第二层即时检索与本地启发式闸门当任何一方你的麦克风或对方的系统音频说一句完整的话第二层接管。它只做三件事全部是本地计算1️⃣ 本地启发式闸门RealtimeGate.swift——这是取代LLM 出场判断的关键设计把决策压到毫秒级触发类型识别通过关键词和标点启发式把话语归类为question提问/决策点、claim观点/异议、topic客户、定价、留存等主题词或general相似度门槛知识库最高分必须 ≥ 可配置阈值默认 0.35否则直接丢弃去重抑制用 Jaccard 相似度对比最近 3 条已展示建议相似度 0.7 判定为重复不再刷屏2️⃣ 缓存优先检索先用文本指纹查PreFetchCache命中则 0ms 拿到上下文包未命中才同步执行一次真实检索SuggestionEngine.swift。检索返回的不是干巴巴的文本块而是知识库上下文包KBContextPack见 KnowledgeBase.swift相对路径 文件夹面包屑 标题面包屑如sales/pricing.md Pricing Unit Economics命中片段的前后相邻章节来自同一文件保证片段可被理解嵌入时携带文档结构元数据让排序不依赖正文本身3️⃣ 爆发-衰减节流BurstDecayThrottle.swift——替代旧的 90 秒固定冷却burstScore 提问密度(近60秒) × 0.4 知识库相关度 × 0.6信号强度burstScore最小间隔替换所需分差高强度密集提问 强匹配 0.70 秒0.05中等强度 0.54 秒0.10低强度其余12 秒0.20候选只有三种命运立即浮现、替换当前、丢弃——不存在排队稍后展示。过期的候选宁可扔掉也不迟到这正是2 秒内浮现体验的最后一道保险。第三层流式 LLM 合成原地升级原始片段闸门放行的候选立即进入第三层SuggestionEngine.swift这里有一个精心设计的生命周期raw原始片段上屏→streamingLLM 逐词流入→completed/failed/superseded候选一过闸门原始知识库片段立刻可见此时延迟已经远低于 2 秒同时向快速模型realtimeModel默认是 gemini-2.0-flash 级别的小快模型发起流式请求按触发类型切换输出指令提问类建议给出可引用的具体答案观点类呈现支持或反驳的证据合成文本逐词覆盖原始片段如果 LLM 失败原始片段保留状态置为failed用户依然有东西可看如果流式期间来了更强的新候选旧建议被标记superseded并淡出新的立即顶上每个建议有稳定 ID贯穿整个生命周期并落盘SessionRepository.swift保证延迟写入日志时不会张冠李戴浮动的建议面板本身基于一个不抢焦点、屏幕共享中不可见的NSPanel实现OverlayPanel.swift SuggestionPanelContent.swift宽度约 250px可用CmdShiftO全局热键随时收起——对方在会议里完全看不到它。2 秒延迟预算是怎么算出来的把三层串成一条时间线你就能看清2 秒从何而来0ms 起某句话定稿部分假设甚至让第一层提前 2~4 秒就缓存好了检索结果100ms本地闸门 缓存命中检索 节流判定纯本地计算200ms原始 KB 片段已在浮动面板上屏 ✅——用户已看到建议后续 1~3 秒快速模型流式合成逐词替换原文建议从可用升级为好用对比旧架构串行 5 级、3 次 LLM 往返、90 秒冷却新架构把感知延迟和生成成本彻底解耦了感知延迟由本地层决定LLM 只是锦上添花。源码导航顺着这篇文章读代码想动手看实现按依赖顺序读这几个文件效率最高架构总设计与数据流图2026-03-26-realtime-suggestions-design.md分任务实施计划2026-03-26-realtime-suggestions.md三层调度中枢SuggestionEngine.swift本地闸门与触发识别RealtimeGate.swift爆发-衰减节流BurstDecayThrottle.swift指纹缓存actor 隔离PreFetchCache.swift上下文包检索KnowledgeBase.swift提问密度与滚动文本窗口TranscriptStore.swift部分假设增量输出StreamingTranscriber.swift面板 UISuggestionPanelContent.swift这套设计给初学者的三点启示先展示、后增强能用本地数据立刻给的答案绝不让用户等 AI。原始片段上屏 流式升级是把AI 慢变成AI 锦上添花的经典手法用启发式守门用 LLM 增值毫秒级的关键词/相似度判断负责要不要说LLM 负责说得更好成本与延迟都可控宁可丢弃、不可迟到实时场景里一条 5 秒后才到达的建议价值为零。浮现、替换、丢弃三选一无队列比智能排队更简单也更好用下次开会时不妨把自己过往的会议纪要、竞品分析、客户简报丢进一个文件夹指着它运行 OpenOats——2 秒内它会开始替你开口。【免费下载链接】OpenOatsA meeting note-taker that talks back.项目地址: https://gitcode.com/gh_mirrors/op/OpenOats创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考