WilmerAI

"如果语言模型能够完美地路由所有推理呢？"

免责声明：

本项目仍在开发中。软件按“原样”提供，不提供任何形式的担保。

本项目以及其中所表达的观点、方法论等，均由维护者及贡献者在业余时间、使用个人硬件完成，不应被视为代表其任何雇主的意见。

本项目的维护者 SomeOddCodeGuy 目前未从事任何合同、自由职业或合作工作。

---

WilmerAI 是什么？

WilmerAI 是一款用于高级语义提示路由和复杂任务编排的应用程序。它的诞生源于对一种能够理解完整对话上下文、而不仅仅是最新消息的路由器的需求。

与仅根据单个关键词对提示进行分类的简单路由器不同，WilmerAI 的路由系统可以分析整个对话历史。这使得它能够真正理解诸如“你觉得它是什么意思？”这样的问题背后的意图：如果该陈述之前有关于罗塞塔石碑的讨论，那么它会被识别为历史查询，而非单纯的日常对话。

这种上下文理解能力得益于其核心——基于节点的工作流引擎。如同 Wilmer 的其他部分一样，路由本身也是一个工作流，通过 JSON 文件中定义的一系列步骤（即“节点”）来进行分类。选定的路由会启动另一个专门的工作流，而这个工作流又可以进一步调用其他工作流。每个节点都可以编排不同的大语言模型、调用外部工具、运行自定义脚本、调用其他工作流，以及其他多种操作。

对于客户端应用而言，这一整套多步骤流程表现为一次标准的 API 调用，从而在无需修改现有前端工具的情况下实现高级后端逻辑。

---

维护者注记补充 - 更新于 2026 年 4 月 12 日

在最初提出这一需求的一年半之后，我终于在此实现了工具调用支持。由于添加这项功能极具挑战性，我一直将其搁置。

这意味着什么，以及我在过去两周中的使用方式——你可以将 Wilmer 插入到 OpenCode 和 Llama.cpp 之间。我一直在利用 Qwen 27B 和 122B 提升 OpenCode 的质量，通过创建 OpenCode 调用经过的工作流来实现。虽然这样做会显著降低整体速度，但结果是我不再需要频繁干预，因为系统能够在更少的尝试中给出正确的答案。

我计划再花大约一个月时间优化这些工作流，随后便会将其分享给社区。接下来的工作将是更新此处的工作流。

另外还有一个重大变化：我终于为标准节点添加了图像直通功能。当初引入 ImageProcessor 时，视觉模型还非常新颖。如今它们已广泛应用，因此我对 ImageProcessor 进行了重新设计，使其更加贴合长期效率提升的目标；与此同时，标准节点则可用于像往常一样直接将图像传递给模型。

维护者注 - 更新于 2026-03-29

近期我一直在对 Wilmer 进行大规模改进，这次的改动可能是自工作流引擎重构以来最大的一次。简而言之：你不再需要运行多个 Wilmer 实例了。

这一直是我对 Wilmer 工作方式最不满的地方。你会看到一堆正在运行的实例，每个实例都有自己的配置文件，管理起来非常麻烦。所以我终于坐下来彻底解决了这个问题。

现在的新功能包括：

• 多用户支持。 你现在可以使用 --User alice --User bob 参数启动 Wilmer（可以根据需要添加任意数量的用户），每个用户都会拥有独立的配置文件、对话文件、记忆存储和日志目录。Wilmer 会自动识别请求来源，并将所有内容路由到对应的用户目录中。

• 并发控制。 在启动服务器时，你可以使用 --concurrency 和 --concurrency-timeout 标志来限制同时处理的请求数量。默认情况下，每次只处理一个请求（这在大多数本地 Mac 环境下是理想设置），其他请求会排队等待，而不会相互干扰。如果你的后端硬件足够强大，比如配备了 NVIDIA 显卡，也可以适当提高并发数。

• 用户文件隔离。 讨论 ID 文件以及其他与会话相关的数据现在都存储在用户专属的目录中。这样一来，即使在一个实例上有多位用户，他们的文件也不会混杂在一起。

• API 密钥支持。 如果请求中包含 Authorization: Bearer 密钥，Wilmer 会根据该密钥将文件分组存储到独立的目录中。这是第二层文件隔离机制。

• 实验性：可选加密功能。 你可以为每个 API 密钥启用 Fernet 加密功能，用于保护存储的文件。一旦开启，Wilmer 会使用你的 API 密钥对生成的文件进行加密。此外，还提供了一个密钥轮换脚本，方便你在需要时更换密钥。（注意：目前尚未应用于 SQLite 数据库）

• 更多记忆和上下文管理选项。 我新增了几项工具来更好地管理长对话——一个基于文件的记忆自动压缩层，以及一个基于 Token 的对话压缩工作流节点 ContextCompactor。关于这些功能的详细说明请参阅文档，其中记忆压缩器在处理长时间对话时非常有用。它的原理是：当积累到一定数量的记忆条目时，它会将这些条目合并成一条新的记忆，然后继续重复这个过程。例如，如果你设置了每 10,000 个 Token 生成一条记忆，那么原本可能产生 6 条记忆的内容，最终会被压缩成 2 条较小的记忆（每条约 500–1,000 个 Token）。这样，60,000 个 Token 的内容就被浓缩成了两份简洁的小型记忆。

• 图像处理优化。 我修复了 Wilmer ImageProcessor 中长期存在的设计问题，现在图像从进入系统开始，直到发送给 LLM 处理的整个流程都会被逐条消息追踪记录，确保它们始终与生成它们的对话回合保持关联。这一改进还让我能够在图像处理器中引入缓存机制（当讨论 ID 处于活动状态时），从而避免重复处理相同的数据。

在之前的版本中，我还增加了 共享工作流集合以及通过 API 模型字段选择工作流的功能。 /v1/models 和 /api/tags 端点现在会返回你可用的工作流列表，这意味着像 Open WebUI 这样的前端界面可以直接在模型下拉菜单中显示这些工作流。你只需像选择模型一样，直接挑选所需的工作流即可。共享工作流文件夹（_shared/）允许多个用户指向同一套工作流，而无需在各处重复配置；同时，单个用户也可以在其下管理多套工作流。这样一来，你就不再需要为不同用户分别设置编码工作流、通用工作流等，而是可以让一个用户拥有多种可用的工作流。

随 Wilmer 一起提供的示例用户和工作流已经很久没有更新了，接下来我会对其进行相应调整。

-Socg

工作流的强大之处

半自主工作流让你掌控工具及其使用时机

以下展示了 Open WebUI 连接到两个 Wilmer 实例的情形（录制于多用户支持功能加入之前；实际上，单个实例现在就可以服务多个用户）。第一个实例直接调用了 Mistral Small 3 24b 模型，而第二个实例则先调用了 Offline Wikipedia API，然后再向同一个模型发起请求。

点击图片即可播放 GIF，若未自动播放

迭代式 LLM 调用以提升性能

LLM 的零次提示可能无法给出理想结果，但后续的追问通常能显著改善效果。如果你经常在执行诸如软件开发之类的任务时重复同样的追问步骤参考我的个人指南：如何借助 AI 辅助进行软件开发，那么创建一个自动化这些步骤的工作流将会带来极大的收益。

分布式 LLM 网络

借助工作流，你可以在一次调用中整合任意数量的 LLM，只要你的硬件设备能够支持即可。例如，如果你手头有一些旧电脑，能够运行 3–8B 规模的模型，那么完全可以将它们作为工作节点中的 LLM 使用。无论是在自家硬件上还是通过专有 API，你能接入的 LLM 接口越多，你的工作流网络就越强大。根据你的工作流设计，向 Wilmer 发出的一个提示就有可能同时触达 5 台甚至更多的计算机，包括各种专有 API。

一些不太美观但有助于理解其功能的示意图

使用提示路由器的简单助手工作流示例

路由功能的应用示例

向不同 LLM 发送群聊消息

用户请求网站设计的 UX 工作流示例

核心特性

• 高级上下文路由 WilmerAI 的核心功能。它使用复杂的、基于上下文的逻辑来引导用户请求。这一过程由两种机制处理：

  • 提示路由：在对话开始时，分析用户的输入提示，以选择最合适的专用工作流（例如“编码”、“事实性”、“创意性”）。
  • 工作流内路由：在工作流执行过程中，提供条件性的“如果/那么”逻辑，使流程能够根据前一个节点的输出动态选择下一步。

  关键的是，这些路由决策可以基于整个对话历史，而不仅仅是用户最后几条消息，从而实现对用户意图更深层次的理解。

---

• 核心：基于节点的工作流引擎 路由及其他所有逻辑的基础。WilmerAI 使用工作流来处理请求，这些工作流是定义步骤序列（节点）的 JSON 文件。每个节点执行特定任务，其输出可作为下一个节点的输入，从而实现复杂的链式思维过程。

---

• 多模型与多工具编排 工作流中的每个节点都可以连接到完全不同的大模型端点，或调用不同的工具。这使得你可以为任务的不同部分编排最适合的模型——例如，在单个工作流中，使用小型快速的本地模型进行摘要生成，再用大型强大的云端模型完成最终推理。

---

• 模块化与可重用的工作流 你可以为常见任务（如数据库查询或文本摘要）构建独立的工作流，然后将其作为单个可重用节点嵌入到更大的工作流中。这样可以简化复杂智能体的设计。

---

• 有状态的对话记忆 为了在长时间对话中提供必要的上下文并实现精准路由，WilmerAI 使用三部分记忆系统：按时间顺序记录的摘要文件、持续更新的整段聊天“滚动摘要”，以及用于检索增强生成（RAG）的可搜索向量数据库。

---

• 适应性强的 API 网关 WilmerAI 的“入口”。它暴露兼容 OpenAI 和 Ollama 的 API 端点，允许你无需修改即可连接现有的前端应用和工具。

---

• 灵活的后端连接器 WilmerAI 的“出口”。它通过一套简单但强大的配置系统连接到各种大模型后端（OpenAI、Ollama、KoboldCpp），该系统包括端点（地址）、API 类型（架构/驱动程序）和预设（生成参数）。

---

• 使用 MCPO 集成 MCP 服务器工具：一项新的实验性功能，支持在工作流中调用 MCP 服务器工具。特别感谢 iSevenDays 在此功能上的出色工作。更多信息请参阅 ReadMe。

---

• 隐私优先开发：从根本上讲，Wilmer 始终秉持完全隐私的原则进行设计。Socg 持续使用这款应用，他和其他人一样，不希望自己的信息被随意泄露到网络上。因此，每一个决策都围绕着这样一个理念：Wilmer 中唯一进出的数据流，都应该是用户期望并主动配置的内容。

---

隐私检查 — 2026年3月29日

为了确保自己没有无意中添加任何可能损害 Wilmer 隐私保护措施的内容，我有时会请 Claude Code 对代码库进行全面检查，查找任何对外的网络请求或其他数据泄露行为。虽然这不如正式的代码审计，但能让我安心一些。现将检查结果附上。

2026年3月29日，我请 Claude Code（Claude Opus）扫描了代码库，并报告其中发现的所有对外网络请求、遥测数据，以及其他可能涉及隐私的行为。以下列出检查结果，供参考，但这并不构成保证——如果你的部署对隐私非常敏感，请务必自行进行分析。

检查内容
----------------
搜索了 Middleware/ 和 Public/ 源码树、顶层入口文件（server.py、run_eventlet.py、run_waitress.py），以及所有 Shell/批处理启动脚本（run_macos.sh、run_windows.bat、Scripts/rekey_encrypted_files.sh、Scripts/rekey_encrypted_files.bat），寻找对外 HTTP 请求（requests.get、requests.post、requests.Session、requests.request）、原始套接字使用、子进程调用、动态导入、硬编码的外部 URL、与遥测相关的关键词（analytics、telemetry、phone-home、tracking、metrics），以及环境变量读取。入口文件和启动脚本中未发现任何对外网络请求；run_eventlet.py 在本地监听套接字上设置了 TCP_NODELAY，但并未建立任何外部连接。

对外网络请求
----------------------
代码库中发现的所有对外 HTTP 请求位置：

1. Middleware/llmapis/handlers/base/base_llm_api_handler.py（第223、373行）
   - session.post() 发送到用户配置的大模型端点（endpoint config 中的 self.base_url）

2. Middleware/workflows/tools/offline_wikipedia_api_tool.py（第45、80、117、153、192行）
   - requests.get() 发送到用户配置的主机；默认为 127.0.0.1:5728
   - 仅在 activateWikiApi 被设置时启用

3. Public/modules/mcp_service_discoverer.py（第55行）
   - requests.get() 发送到用户配置或环境变量指定的 MCPO 服务器；默认为 localhost:8889

4. Public/modules/mcp_tool_executor.py（第235行）
   - requests.request() 发送到与上述相同的 MCPO 服务器

未发现任何遥测、分析、回传数据、自动更新或硬编码的外部 URL。所有对外连接的目标都是用户明确配置的端点。

数据存储
------------
- JSON 对话/记忆文件：当启用 encryptUsingApiKey 时，可选地使用 Fernet 加密（AES-128-CBC 加 HMAC，PBKDF2 迭代 10万次）进行静态加密。
- SQLite 数据库：用于向量记忆和工作流锁。即使启用了加密功能，这些数据库也未加密。
- 日志文件：在 DEBUG 级别下，日志可能包含完整的提示和大模型响应，除非用户配置中启用了 redactLogOutput 或 encryptUsingApiKey。
- 配置文件：可能包含明文 API 密钥。这些文件不会被 Wilmer 加密。

第三方依赖
------------------------
requirements.txt 中的所有运行时依赖项：

  requests 2.33.0        - 用于大模型 API 和工具调用的 HTTP 客户端
  urllib3 2.6.3           - requests 的传输层
  scikit-learn 1.8.0      - 用于记忆搜索的 TF-IDF 向量化
  Flask 3.1.3             - HTTP 服务器框架
  Jinja2 3.1.6            - 用于工作流提示的模板渲染
  Pillow 12.1.1           - 图像格式检测和处理
  eventlet 0.40.4         - 异步 WSGI 服务器（可选）
  waitress 3.0.2          - 生产级 WSGI 服务器（可选）
  cryptography 46.0.5     - 用于存储数据的 Fernet 加密

在 Wilmer 使用的所有这些包的初始化路径中，均未发现遥测或分析代码。
  
动态代码加载
--------------------
- PythonModule 工作流节点会以 Wilmer 进程的全部权限执行用户提供的、来自配置脚本目录的 Python 脚本。这些脚本不会被沙箱隔离，也不会经过 Wilmer 的验证。
- API 处理器发现（Middleware/llmapis/handlers/）仅限内部使用，并且只从应用程序内的 handlers 目录加载。

图片 URL 处理
------------------
当对话消息包含通过 HTTP URL 引用的图片时，该 URL 会原样转发给配置的 LLM 提供商。Wilmer 不会自行下载该图片。

局限性
-----------
1. 这是一项由 AI（Claude Opus）执行的静态源代码搜索，而非正式的第三方安全审计。
2. 第三方库的源代码并未在字节码级别进行检查。结果仅确认 Wilmer 自身的代码似乎不会发起意外连接。
3. PythonModule 脚本由用户提供，可以执行任意代码。其行为不在本次检查范围内。
4. 未进行运行时网络监控（例如数据包捕获）。
5. 用于向量记忆的 SQLite 数据库即使在其他情况下启用了加密功能，也未进行加密。
6. 日志文件可能包含完整的对话内容，除非明确启用了内容脱敏功能。

虽然我并没有工具能够百分之百保证不存在第三方库在执行我意料之外的操作，但我希望强调这一点对我来说非常重要。如果您有任何疑虑，强烈建议您自行对代码库和应用程序进行分析。如果您发现了任何我遗漏的内容，请随时提交问题。

用户文档

用户文档可在 /Docs/User_Documentation/ 找到。

开发者文档

有用的开发者文档可在 /Docs/Developer_Docs/ 找到。

快速设置

YouTube 视频

指南

WilmerAI

请参阅 用户文档设置入门指南，获取关于如何快速设置 API 的分步说明。

Wilmer 与 Open WebUI

您可以点击此处查看关于将 Wilmer 与 Open WebUI 配合使用的书面指南

Wilmer 与 SillyTavern

您可以点击此处查看关于将 Wilmer 与 SillyTavern 配合使用的书面指南

---

为什么创建 WilmerAI？

Wilmer 项目于 2023 年底启动，正值 Llama 2 时代，旨在通过路由机制最大化微调模型的应用效果。当时现有的路由器大多无法很好地处理语义路由——它们往往仅根据单个关键词以及最后一句话来分类；然而，有时单个词并不足以准确描述一个类别，而最后一句话可能包含过多的隐含信息，或者缺乏足够的上下文，从而难以进行恰当的分类。

几乎在 Wilmer 启动后不久，人们就意识到仅仅依靠路由是不够的：尽管微调模型的效果尚可，但远不及专有 LLM 的智能水平。然而，当 LLM 被反复要求针对同一任务进行迭代时，其响应质量往往会提升（前提是提示词编写得当）。这表明，最佳方案并非简单地将请求路由至单一 LLM 一次性完成响应，而是将提示词发送给更为复杂的系统。

因此，Wilmer 没有依赖不可靠的自主代理，而是专注于半自主的工作流设计，赋予用户对 LLM 执行路径的精细控制权，并最大限度地利用用户的领域知识和经验。这也意味着多个 LLM 可以协同工作，由工作流本身进行编排，共同得出最终解决方案。

与仅将请求路由至单一 LLM 不同，Wilmer 会通过完整的工作流将请求分配给多个 LLM。

这种设计使得 Wilmer 的分类能力比大多数路由器更加复杂且高度可定制。分类过程由用户自定义的工作流负责，用户可以根据需要添加任意数量的节点和 LLM，逐步拆解对话内容，精确判断用户的需求。这意味着用户可以尝试不同的提示词风格，以优化路由器的表现。此外，路由规则不仅仅是关键词，而是对整个路由流程的完整描述，几乎不留给 LLM 任何“想象”的空间。其目标是，一旦 Wilmer 的分类出现不足，只需调整分类工作流即可解决。而一旦确定了分类方向，请求就会进入下一个工作流。

最终，Wilmer 的核心逐渐从单纯的路由转向工作流设计，并提供了可选的绕过机制，允许用户直接跳过路由步骤。由于其占用资源较少，用户可以同时运行多个 Wilmer 实例——有些直接执行特定的工作流，而另一些则先经过分类和路由流程。

尽管 Wilmer 可能是同类项目中的首创，但此后已涌现出许多其他的语义路由器，其中一些甚至可能速度更快、性能更好。然而，该项目仍将持续维护很长一段时间，因为项目的维护者本人至今仍在将其作为日常工具使用，并计划为其开发更多功能。

Wilmer API 端点

如何连接到 Wilmer？

Wilmer 在前端暴露了多种不同的 API，使大多数 LLM 相关应用都能与其对接。

Wilmer 支持以下 API，可供其他应用连接：

• OpenAI 兼容 v1/completions（需使用 Wilmer 提示模板）
• OpenAI 兼容 chat/completions
• Ollama 兼容 api/generate（需使用 Wilmer 提示模板）
• Ollama 兼容 api/chat

Wilmer 可以连接哪些服务？

在后端，Wilmer 能够连接多种 API，并将提示词发送至相应的 LLM。目前，Wilmer 支持以下类型的 API：

• Claude API（Anthropic Messages API）
• OpenAI 兼容 v1/completions
• OpenAI 兼容 chat/completions
• Ollama 兼容 api/generate
• Ollama 兼容 api/chat
• KoboldCpp 兼容 api/v1/generate（非流式生成）
• KoboldCpp 兼容 /api/extra/generate/stream（流式生成）

Wilmer 同时支持流式和非流式连接，并已在 Sillytavern 和 Open WebUI 上进行了测试。

维护者注：

本项目是在我的个人硬件上，利用业余时间进行维护的。由于工作原因，我无法在工作日的正常工作时间内参与开发，因此我只能在周末以及部分工作日晚上进行代码更新。

如果您发现了 bug 或其他问题，修复可能需要一到两周的时间才能发布。如果确实如此，我在此提前致歉，但请不要因此认为我没有认真对待该问题。实际上，我可能要到下一周的周五或周六才有时间查看并处理该问题。

-Socg

重要提示：

请注意，工作流的本质决定了它们可能会根据您的配置对 API 端点发起多次调用。WilmerAI 不会跟踪令牌使用情况，也不会通过其 API 报告准确的令牌使用量，更不提供任何可行的方式来监控令牌使用情况。因此，如果您出于成本考虑需要跟踪令牌使用量，请务必通过 LLM API 提供给您的仪表板来记录您使用的令牌数量，尤其是在刚开始使用本软件时，以便熟悉其操作。

您所使用的 LLM 直接影响 WilmerAI 的质量。这是一个由 LLM 驱动的项目，其流程和输出几乎完全依赖于所连接的 LLM 及其响应。如果您将 Wilmer 连接到一个生成质量较低模型，或者您的预设设置或提示模板存在缺陷，那么 Wilmer 的整体质量也会相应降低。在这方面，它与代理式工作流并没有太大区别。

---

联系方式

如需反馈、请求或只是打个招呼，您可以通过以下邮箱联系我：

WilmerAI.Project@gmail.com

---

第三方库

WilmerAI 在其 requirements.txt 文件中引入了多个第三方库，并通过 import 语句直接导入这些库；它并未扩展或修改这些库的源代码。

这些库包括：

• Flask : https://github.com/pallets/flask/
• requests: https://github.com/psf/requests/
• scikit-learn: https://github.com/scikit-learn/scikit-learn/
• urllib3: https://github.com/urllib3/urllib3/
• jinja2: https://github.com/pallets/jinja
• pillow: https://github.com/python-pillow/Pillow
• eventlet: https://github.com/eventlet/eventlet
• waitress: https://github.com/Pylons/waitress
• cryptography: https://github.com/pyca/cryptography

有关这些库的许可信息，请参阅 ThirdParty-Licenses 文件夹中的 README 文件，其中包含了每种许可证的完整文本以及相关的 NOTICE 文件（如有），并注明了各自的最后更新日期。

Wilmer 许可证与版权

WilmerAI
版权所有 © 2024–2026 克里斯托弗·史密斯

本程序是自由软件：您可以重新分发它，并按照自由软件基金会发布的 GNU 通用公共许可证条款对其进行修改，
无论是第 3 版本，还是您选择的任何后续版本。

本程序以“按原样”提供，不附带任何担保，包括但不限于适销性或特定用途适用性的隐含担保。详细信息请参阅 GNU 通用公共许可证。

您应当随本程序收到一份 GNU 通用公共许可证的副本。如果没有，请访问 <https://www.gnu.org/licenses/> 查阅。

WilmerAI 快速上手指南

WilmerAI 是一款专为高级语义提示路由和复杂任务编排设计的开源应用。其核心是一个基于节点的工作流引擎，能够理解完整的对话上下文（而不仅仅是最后一条消息），从而智能地将请求路由到最合适的 LLM 或工具链。它兼容 OpenAI 和 Ollama API，可无缝集成到现有的前端工具（如 Open WebUI）中。

注意：本项目目前仍处于开发阶段，软件按“原样”提供，无任何形式的担保。

环境准备

在开始之前，请确保您的系统满足以下要求：

• 操作系统：支持 Linux、macOS 或 Windows (WSL2 推荐)。
• Python 版本：Python 3.10 或更高版本。
• 依赖管理：推荐使用 pip 或 conda 进行环境管理。
• 后端模型服务：需预先部署好至少一个 LLM 后端（如本地运行的 Ollama、vLLM，或拥有 OpenAI/Azure 等 API Key）。
• 内存建议：由于涉及多步工作流和上下文记忆，建议至少 8GB 可用内存；若运行本地大模型，需根据模型大小增加显存/内存。

安装步骤

1. 克隆项目仓库

git clone https://github.com/SomeOddCodeGuy/WilmerAI.git
cd WilmerAI

(注：如果国内访问 GitHub 较慢，可使用镜像源加速，例如：git clone https://ghp.ci/https://github.com/SomeOddCodeGuy/WilmerAI.git)

2. 创建并激活虚拟环境

建议使用 Python 虚拟环境以避免依赖冲突：

python -m venv venv
source venv/bin/activate  # Linux/macOS
# 或在 Windows 上: venv\Scripts\activate

3. 安装依赖

pip install -r requirements.txt

(注：若下载速度慢，可指定国内镜像源：pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple)

4. 配置初始文件

复制示例配置文件并根据需要修改（主要是后端 API 地址和密钥）：

cp config.example.json config.json

编辑 config.json，填入您的 LLM 后端信息（如 Ollama 地址 http://localhost:11434 或 OpenAI Key）。

基本使用

启动服务器

WilmerAI 支持多用户模式和并发控制。以下是几种常见的启动方式：

单用户默认模式（适合本地测试）：

python main.py

多用户模式（为不同用户隔离配置和记忆）：

python main.py --User alice --User bob

启用并发控制（适合高性能后端，如 NVIDIA GPU 集群）：

python main.py --concurrency 4 --concurrency-timeout 300

说明：默认情况下，服务器一次只处理一个请求以保证本地稳定性。--concurrency 参数允许同时处理多个请求。

连接前端工具

WilmerAI 启动后，默认会暴露兼容 OpenAI 格式的 API 端点（通常为 http://localhost:8000/v1）。您可以直接将其配置到任何支持 OpenAI API 的客户端中。

示例：使用 curl 测试路由功能

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "coding-workflow", 
    "messages": [
      {"role": "user", "content": "帮我写一个 Python 脚本，用于抓取网页标题。"}
    ]
  }'

• model 字段：在此处填写您在 Wilmer 配置中定义的工作流名称（如 coding-workflow、general-assistant）。Wilmer 会根据该名称加载对应的 JSON 工作流定义。
• 上下文感知：如果您在同一个会话 ID（Session ID）下连续发送消息，Wilmer 会自动读取历史记忆和滚动摘要，实现基于完整上下文的智能路由。

简单工作流概念

Wilmer 的核心在于 workflows 目录下的 JSON 文件。一个简单的路由逻辑如下：

1. 输入：用户发送消息。
2. 路由节点：分析整段对话历史，判断意图（是写代码？还是查资料？）。
3. 执行节点：根据判断结果，调用特定的 LLM（如用 Qwen-72B 写代码，用 Mistral-7B 做总结）或外部工具（如搜索维基百科）。
4. 输出：将最终结果返回给客户端，整个过程对前端透明。

您可以根据需求自定义这些 JSON 工作流，实现复杂的自动化任务编排。