WeClaw_91｜双引擎意图识别：一次「配置开了却没生效」的排查，揭开的链路真相

Hi带娃的我热爱AI 大模型应用落地、意识解码与 AI 开发工具链。 创业路上用技术换时间一起把 AI 变成生产力 WeClaw_91双引擎意图识别一次「配置开了却没生效」的排查揭开的链路真相系列文章第 91 篇- 双引擎架构 · 规则引擎兜底 · 链路分工 · 子开关灰度 · 首 token 延迟 专栏信息《从零到一构建跨平台 AI 助手WeClaw 实战指南》专栏专栏定位面向开发者和技术决策者的实战专栏用真实案例和完整代码带你理解如何构建生产级 AI 应用本文记录一次认知反转。配置文件里明明写着intent_mode llm我们却一度以为「意图识别已经用上大模型了」——直到一轮对话追问「现在的对话应该都是 chat_stream 吧」顺藤摸瓜才发现日常每一次交互走的流式链路意图识别仍然是纯规则引擎LLM 增强只惠及两个低频后台场景。这篇讲清楚双引擎架构的设计逻辑、chat 与 chat_stream 的真实分工以及为什么「开了配置却没生效」恰恰是这个架构做对了的证据。‍ 作者与项目作者简介翁勇刚 WENG YONGGANG新概念龙虾-WeClaw 开发团队负责人一群专注于跨平台 AI 应用的实践者理念“再复杂的技术也能用代码讲清楚” 项目地址https://github.com/wyg5208/weclaw.git 官网地址https://weclaw.link 作者 CSDNhttps://blog.csdn.net/yweng18⭐ 欢迎 Star⭐、Fork、贡献代码 摘要本文结构概览0.1ms 与 1.5s一次基准测试揭示的四个数量级鸿沟数据先行→ 为什么双引擎不是「过渡方案」而是终局架构设计哲学→ 一次排查intent_modellm为什么没有改变日常体验链路真相→ chat 与 chat_stream 的分工地图 → 子开关灰度把增强能力先放进配置里等数据说话渐进放开。核心结论规则引擎与 LLM 的延迟差距是四个数量级0.1ms vs 1.5s这个差距大到足以重塑架构——不是选哪个引擎的问题而是两个引擎各守一段链路「配置开了却没生效」不是 bug而是链路门控的设计结果配置项只决定「引擎可用性」调用链决定「引擎是否被允许上场」理解一个配置的真实作用域必须追到每一个调用点的 allow_llm 参数——配置文件的语义是由调用链共同定义的。一、一组让架构自己现形的数字在给流式链路接入 LLM 意图识别之前我们先跑了一组基准n30引擎单次意图识别耗时依赖规则引擎0.1ms均值最大值无纯内存LLM 分类正常1.51s网络 模型服务15,000 倍。这不是「快一点」是两个完全不同的时间物种。这组数字直接否决了一个诱人的想法——「干脆全链路切 LLM规则引擎退役」。因为意图识别在流式对话中位于首 token 之前串行执行它的耗时原封不动地加在用户等待第一个字的时间内。全量切换意味着每条消息凭空多等 1.5 秒——而规则引擎在 90% 的常见意图上已经足够准。于是架构选择变得清晰规则引擎是地基LLM 是可选的精装修。双引擎不是 LLM 成熟前的过渡态而是终局形态——因为两者的成本曲线永远不会收敛。二、双引擎的分工契约用户输入 │ ▼ _route_intent_detection(user_input, allow_llm?) │ ├─ allow_llmTrue 且 intent_modellm 且熔断器放行 │ │ │ ▼ │ LLM 分类6s 超时 / 1 次快失败重试 / 3 次熔断 │ │ │ ├─ 成功 ──────────────► 返回 LLM 意图更准 │ └─ 失败/超时/熔断 ─┐ │ ▼ └──────────────► 规则引擎0.1ms永远在场──► 返回规则意图契约只有三条但每条都是硬约束LLM 永远只是「增强」它的产出可以被整体放弃放弃后系统行为等价于没接 LLM规则引擎永远在场任何降级路径的终点都是它不存在「两个引擎都失败」的状态门控由调用点声明allow_llm是每个调用点自己决定的不是全局状态——这一点是后文排查的关键。三、排查实录配置开了为什么日常体验没变3.1 困惑的起点配置文件里白纸黑字intent_mode llm intent_llm_model deepseek-v4-flash intent_llm_timeout 6.0 intent_llm_in_stream false按直觉intent_mode llm应该让所有意图识别走 LLM。但日志里日常对话的意图识别耗时全是亚毫秒级LLM 调用记录寥寥无几。配置生效了吗最初的回答差点出错「chat 链路已开 LLM 意图识别」——这句话技术上没错但隐含了「日常对话受益了」的错误推论。一句追问戳破了它「我有点迷惑现在的对话应该都是 chat_stream 吧chat普通对话在哪个环节会发生」3.2 追调用点顺着两个入口函数搜调用方Agent.chat_stream流式—— GUI 主窗口的每一条消息都走这里打字输入、语音识别后的转写文本全部经由GuiAgent.chatUI 包装层最终落到Agent.chat_stream。它的门控是intent_resultawaitself._route_intent_detection(user_input,allow_llmself._intent_llm_in_stream,# ← 子开关默认 False)intent_llm_in_stream false——日常交互的意图识别就是纯规则引擎与 intent_mode 无关。Agent.chat非流式——allow_llmTrue确实享受 LLM 增强。但它的调用方只有两处调用点场景频率src/tools/cron.py定时任务执行让 Agent 跑一条预设指令每天几次src/remote_client/client.py远程 PWA 流式失败时的降级兜底极少数3.3 真相拼图配置 intent_mode llm → 决定「LLM 引擎是否可用」 调用点 allow_llm → 决定「这条链路是否允许使用」 实际行为 两者取交集 日常交互chat_streamintent_llm_in_streamfalse ∩ llm可用 规则引擎 定时任务chat allow_llmTrue ∩ llm可用 LLM 增强 远程降级chat allow_llmTrue ∩ llm可用 LLM 增强intent_modellm确实生效了——只是它惠及的是两个低频后台场景。配置没有撒谎是我们误读了配置的作用域。3.4 为什么没有「chat/stream 切换开关」排查中自然产生的下一个问题能不能配置让日常对话走chat从而用上 LLM 意图答案是没必要也不应该。chat 与 stream 的分工由场景天然决定——UI 交互必须流式用户要看着字逐个蹦出来后台任务只要最终结果没有人在盯着屏幕。把「用哪个引擎」耦合进「用哪条链路」会让两个正交的关注点互相绑架。正确的解耦方式就是现在的样子链路选链路引擎选引擎用子开关在交叉点做决策。四、子开关灰度这套架构里最新的一块拼图既然日常交互要不要上 LLM 是个开放问题我们给它配了专用的门intent_llm_in_stream默认 false。设计上有三个刻意的细节1. 默认关闭收益要用数据换。首 token 延迟实测基准写进了交付记录开关闭 0.1ms 基线不变G4 行为基线无需重建打开 1.5s 量级。要不要付出这个代价留给真实使用数据决定而不是架构讨论拍脑袋。2. 独立于 intent_mode语义单一。intent_mode管「引擎可用性」子开关管「流式链路是否放行」。两个配置正交互不覆盖——将来任何链路想单独试验 LLM只需要自己的开关不用动全局。3. 配置模板即文档。config/default.toml.example中子开关旁边就是注释说明延迟代价。配置文件是给六个月后的自己和接手的人读的每个布尔值都应该自带「翻转它会发生什么」的说明书。五、可复用的方法论延迟差超过两个数量级就值得改变架构。0.1ms vs 1.5s 不是选快慢的问题是「谁守在线路径、谁守在离线路径」的分工问题。兜底引擎必须永远在场。双引擎的价值不在 LLM 多准而在 LLM 挂了、慢了、熔断了的时候系统行为等价于从未接过 LLM。配置的语义由调用链定义。读懂一个配置要追完所有消费它的调用点只看配置文件会得出「全链路生效」的错误直觉。「没生效」可能是设计在保护你。本次排查的结局不是修 bug而是确认门控工作正常——默认关闭的增强项就该在显式打开前保持静默。链路和引擎正交解耦。场景决定链路UI 流式/后台非流式策略决定引擎规则/LLM交叉点用独立子开关——任何一方的演进都不牵连另一方。六、总结这次迭代最终交付的意图识别体系是一张三层的决策网底层是 0.1ms 的规则引擎永不停机中层是带全套保险的 LLM 增强6 秒超时、熔断、纯函数解析顶层是逐链路声明的门控策略chat 开、stream 配置化、deferred 永久关。intent_modellm打开了中层的能力但上层门控决定能力落在哪些链路上——这次排查最大的收获是把这张决策网画进了团队的共同认知里。架构的正确性有时不以「功能生效」来证明。一个默认关闭、按需放开的开关在打开之前安安静静地保持静默——这正是它被设计出来的样子。版权声明本文为 CSDN 博主「翁勇刚」的原创文章遵循 CC 4.0 BY-SA 版权协议转载请附上原文出处链接及本声明。