WilmerAI：让大模型学会「分诊」的智能路由框架

当AI助手开始「挑医生」：一个想法如何变成开源生态

2023年末，Llama 2 刚刚发布，Chris Smith（GitHub ID: SomeOddCodeGuy）在自己的个人电脑上部署了第一个本地大模型。但他很快发现了一个痛点：不同类型的任务需要不同的模型——写代码需要推理能力强的，做摘要需要快的，查百科需要知识覆盖广的。手动切换模型太繁琐，但市面上的路由工具只能根据「最后一个词」判断意图，准确率感人。

于是他写下了 WilmerAI 的第一行代码。三年后，这个项目积累了 817 颗 GitHub Stars，成为了最早的一批 LLM 语义路由工具之一。

图1：WilmerAI 与 Open WebUI 的深度集成，用户可直接在模型下拉菜单中选择工作流

核心能力：三层路由体系

WilmerAI 的路由不是简单的「关键词匹配」，而是一个三层递进的决策体系：

第一层：入口语义路由。 当用户发起对话时，WilmerAI 会分析整个对话历史，而非只看最后一条消息。这解决了传统路由器最大的缺陷——无法理解「它」指的是前文提到的哪个实体。比如用户说「这个石头是什么意思」，Wilmer 能识别出「这个石头」是前文讨论的罗塞塔石碑文物，而非随机地质话题。

第二层：工作流内条件路由。 每个工作流节点可以包含 if/then 逻辑，根据前一步的输出动态选择下一个节点。这让复杂的 chain-of-thought 流程成为可能，而不需要依赖不可靠的自主 Agent。

第三层：跨模型编排路由。 一个请求可以同时调度多个不同的 LLM API——本地机器跑一个 3-8B 小模型做摘要，云端跑 Claude 做最终推理，Wikipedia 工具做事实核查。所有这些在一个 API 调用内完成，对前端应用透明。

图2：Wilmer 作为 API 网关，将请求分发到多个不同后端 LLM

节点引擎：JSON 驱动的工作流编排

WilmerAI 的所有能力都建立在 JSON 配置文件之上。每个工作流就是一个 JSON 文件，定义了节点序列和节点类型：

• LLM Node：调用指定的后端 API（OpenAI、Claude、Ollama、KoboldCpp）
• Tool Node：执行外部工具，如 Wikipedia API、MCPO（MCP 服务器）
• PythonModule Node：执行自定义 Python 脚本，灵活扩展
• Router Node：条件分支，驱动工作流走向

这种设计的精妙之处在于：你可以把一个完整的工作流封装成「子工作流节点」，嵌套到其他工作流中复用。比如把「搜索→摘要→引用」封装为一个 RAG 节点，在多个不同场景下调用。

图3：简化版编程工作流示例，Wilmer 调度多个模型协作完成开发任务

技术架构：Flask + scikit-learn + eventlet

从技术栈来看，WilmerAI 是一个典型的 Python 后端服务：

• Flask 3.1：提供 OpenAI 和 Ollama 兼容的 API 端点，主流前端（SillyTavern、Open WebUI）开箱即连
• scikit-learn 1.8：TF-IDF 向量化，用于向量内存搜索（RAG）
• eventlet / waitress：异步 WSGI 服务器，支持并发请求
• cryptography：Fernet AES 加密，可选对本地存储文件加密
• Pillow：图像格式检测，支持多模态（视觉模型）工作流

值得注意的是，作者在 2026 年 3 月新增了多用户支持和并发控制——通过 --User 参数为不同用户隔离配置和对话文件，通过 --concurrency 控制同时处理的请求数。这意味着 WilmerAI 从个人工具进化为小型团队共享网关。

图4：Wilmer 核心工作流引擎示意，节点按 JSON 定义顺序执行

隐私设计：无遥测、无追踪

作者 Chris 将隐私列为第一优先级。2026 年 3 月他请 Claude Code 做了一次端到端代码审计，确认：

• 无任何硬编码外部 URL
• 无遥测、追踪或自动更新机制
• 所有出站连接都是用户显式配置的 LLM 端点
• 敏感数据可选 Fernet 加密存储（AES-128-CBC + PBKDF2）

这是一个作者自己每天都在用的「日用品」，而非为了论文或 KPI 开发的实验项目。这种「吃自己的狗粮」的开发态度，让项目的实用性和稳定性都有保障。

上手体验：部署简单但有一定门槛

WilmerAI 本身不需要 GPU，因为它本身不做推理，只做路由和调度。推荐配置：

• 系统：Linux/macOS/Windows（提供三个平台的启动脚本）
• Python：3.9+
• 内存：2GB+（实际取决于所调度的本地模型大小）
• 网络：需要能访问 LLM API（本地 Ollama 或云端 API）

官方提供了与 Open WebUI 和 SillyTavern 的集成文档，但需要手动配置 prompt template。对于没有 API 使用经验的用户来说，有一定学习曲线。

图5：RAG 搜索工作流效果对比，展示 Wilmer 如何调用外部知识源

局限与争议

必须承认 WilmerAI 也有明显的局限性：

1. Token 追踪缺失：Wilmer 不记录 token 使用量，如果需要按量计费管理，必须依赖 LLM 提供商的仪表盘。
2. 工作流调试复杂：JSON 配置对开发者友好，但对非技术用户不直观，缺乏可视化编辑器。
3. SQLite 数据库未加密：即便开启了 Fernet 加密，SQLite 文件（向量内存、workflow locks）仍为明文存储。
4. 活跃度：项目仅由作者一人维护，周末才有时间更新，响应速度取决于作者工作外的时间。

行业意义

WilmerAI 代表了一种朴素的 AI 工程哲学：与其追逐「AGI 大一统」，不如在具体场景中用组合式工作流榨干现有模型的能力。它的路由理念影响了后续很多 Agent 框架的设计——让用户在 JSON 中定义 agent 行为，比让 AI 自主决策更可控、更可解释。

如果你在运营需要接入多个 LLM 的产品，或者希望让本地模型和云端模型协作工作，WilmerAI 是一个值得研究的参考实现。