将 $0 成本的 Agentic RAG 助手升级至 Llama 4 Scout 17B MoE

如果您最近和我的 AI 助手聊过天，您可能会发现它的速度和智商都得到了极大的提升。我已经正式将 Agentic RAG 架构的核心“大脑”从笨重的 Gemma 26B 和 Llama 3 8B 模型升级到了 Cloudflare Workers AI 上全新的 Llama 4 Scout 17B MoE (混合专家) 模型。

这里为您深度剖析这次架构升级的前因后果以及最终成果。

问题所在：“快”与“聪明”的取舍困境

在上一版的架构中，我陷入了一个令人沮丧的取舍困境：

Gemma 26B & Llama 3 70B：这些稠密（Dense）模型非常聪明。它们能毫不费力地驾驭复杂的多工具 ReAct 循环。但它们实在太慢了。在边缘计算节点上，使用 Gemma 26B 生成一次回复通常需要 ~16 秒。在实时聊天的用户界面中，16 秒的首字节时间（TTFB）对用户体验来说是灾难性的。
Llama 3 8B：为了解决延迟问题，我尝试将流量路由到一个更小的 8B 模型。它确实很快（低于2秒的延迟），但它却遭受着严重的幻觉和错误的工具调用（False Positives）。例如，因为我的名字叫 "Elvis"，如果用户问一些刁钻的问题，这个 8B 模型有时候会完全无视它的系统设定指令（System Prompt），开始幻想并自称是传奇音乐人“猫王”（Elvis Presley）。

我迫切需要一个既有 8B 的极速，又具备 70B 逻辑推理能力的解决方案。

解决方案：Llama 4 Scout 17B MoE

终于，@cf/meta/llama-4-scout-17b-16e-instruct 横空出世。

这是 Cloudflare Workers AI 原生支持的 混合专家 (MoE) 架构。与那些在每个 token 生成时都要激活全部参数的稠密模型不同，MoE 模型会将 token 路由到特定的“专家”子网络。尽管这个模型总共有 17B 个参数（分布在 16 个专家上），但它每次只需要激活其中一小部分的参数。

结果是什么？它拥有一个庞大模型才具备的逻辑推理能力，却只消耗微型模型的算力和延迟。

架构数据流图

下面是更新后的 RAG 数据流向：

graph TD
    User([用户]) --> UI[Next.js 前端]
    UI --> Worker[Cloudflare Worker 后端]
    Worker --> Cache{D1 语义缓存}
    Cache -- 命中 (余弦相似度 >= 0.93) --> Return[即时返回缓存答案]
    Cache -- 未命中 --> Agent[ReAct Agent 智能体循环]
    
    subgraph Llama 4 Scout 17B MoE
        Agent --> Router[MoE 路由器]
        Router -.-> E1[专家 1: 搜索]
        Router -.-> E2[专家 2: 代码]
        Router -.-> E3[专家 3: 逻辑]
    end
    
    Agent <--> Vectorize[(Cloudflare Vectorize 向量库)]
    Agent <--> Tools[系统工具: get_site_map 等]
    Agent --> Final[生成最终的 RAG 答案]

成果与验证

我运行了一个详尽的自动化测试套件 (vitest-pool-workers) 来对新架构进行基准测试。

100% 测试通过率：完美通过了所有 5 项核心边界测试。
零幻觉 (Zero Hallucination)：当被明确问及“Android 应用”（我根本没开发过）或“我是不是歌手”时，模型完美地基于 RAG 上下文进行了后退防守并否认了这些说法，而不是胡编乱造。
低于4秒的延迟：整个 ReAct 循环（包括嵌入提示词、查询 Vectorize、运行工具并生成最终回复）现在稳定在 ~3.5 秒 左右。

通过充分利用 Cloudflare 的边缘推理网络和 MoE 的效率，这个企业级的 Agentic RAG 系统完全保留在免费层内（$0 成本），同时为您提供了零卡顿的高端用户体验。