聚焦 AI Agent 全链路工程实践：RAG 检索、记忆系统、Agent 编排、Next.js 产品落地与 AI 协作工程化。下方为当前写作方向；首页文章列表仅展示本阶段内容。
说明：下文来自 MemoryOS 一次真实 Chat SSE「假死」排查与修复。症状、时间线与改法均基于生产级调试日志；不是框架 bug 公告，而是 长连接 + Depends 生命周期 + 流式背压 三类常见坑叠在一起的故事。
用户问：「2022 世界杯射手榜前 10 名」。终端里 SQL 已经 COMMIT，memories 表也在更新——聊天框却停在「正在生成分析…」，只吐出几个字；刷新页面，完整答案却在。
这不是 LLM 慢，也不是 Redis 挂了。这是一次典型的 假死：数据其实写进库了，但 SSE 管道某一截没有把字节送到浏览器。
Query路由的核心本质是对用户问句做分类后，动态切换不同的系统组件/链路，在保障效果的前提下平衡成本、延迟、精度。4大类路由按「前置程度、成本高低」分层部署，其中LLM分类路由是维度最丰富的核心大类，下含模板、模型、检索链路、工具调用4类细分路由。
说明：本文是 MemoryOS 聊天 / RAG 安全实现对照，与 《LLM 聊天与 RAG 安全怎么落地》 互补——那一篇讲方法论，本篇讲本系统在哪一层、用什么包、防什么、还缺什么。文中 DeSyntax 指 EntropyShield 包的打碎句法 mask，见第一节末「DeSyntax 是什么」。
回顾顺序：第一节总表与 DeSyntax 说明 → 分层图 → 时序图
说明：下文是 RAG 聊天场景的安全思路 + MemoryOS 里真实做过的取舍。不是现网配置承诺，规则阈值与 Prompt 原文不公开。
落地对照（分层、包名、时序）：MemoryOS 聊天安全一张图
做 AI 聊天应用时，安全往往被排在「能跑起来」之后。但真正上线后，Prompt 注入、RAG 间接注入、工具链滥用和成本失控会一起找上门。最近在 MemoryOS 里梳理聊天/RAG 安全方案，把内部工程文档整理成一篇可发布的总结，方便对照和迭代。
核心结论先说：
先梳理四种 RPC 流模式的能力边界（务必区分「服务端程序」和「浏览器」），再按真实业务拆分「该用什么、为什么、别用什么」，覆盖 Unary、Server Stream、Client Stream、Bidi 四类需求。
协议层对比与架构图见姊妹篇：gRPC、tRPC、Connect-RPC 怎么选？
做全栈或 AI 应用时，gRPC、tRPC、Connect-RPC 名字常一起出现，但浏览器能不能直连、流式能支持几种、存量 gRPC 要不要改——边界很容易混。下文用对比表和两套架构图说明各自适合什么场景，并单独标出 浏览器 Fetch 的流式能力上限。
在 AI 流式聊天里，用户点 停止生成，表面往往只是一次 AbortController.abort()。在 BFF + FastAPI SSE + LangGraph 架构下，MemoryOS 落地的是 「双发 abort」：两套能力并行、各司其职。
做 AI 聊天客户端时，常会碰到两个相近的问题：SSE（Server-Sent Events，服务端推送事件）和 WebSocket 怎么选？ 以及 明明后端已经是 SSE，前端为什么不用浏览器自带的 EventSource，而用 fetch + ReadableStream 自己解析？