open-webui-plugins
Classic298/open-webui-plugins加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象这样一个场景：你部署了 Open WebUI，和 Ollama 或者某个大模型 API 对接完毕，聊天功能正常，但总觉得差点什么——邮件要另开客户端、数据图表要粘贴到别的地方看、图片分析只能靠模型「猜」而不是真正「看」。这时候，open-webui-plugins 就是来解决这个问题的。
这是由开发者 Classic298 维护的一个 Open WebUI 插件精选仓库，目前收录了 9 个功能各异的插件，涵盖工具（Tool）、技能（Skill）、过滤器（Filter）、管道（Pipe）、事件（Event）五大 Open WebUI 扩展类型。所有插件均为单文件 Python 实现，BSD-3-Clause 开源许可，可直接在 Open WebUI 管理界面安装，无需额外部署服务。
Open WebUI（GitHub 14.7 万星）是最受欢迎的开源本地 AI 聊天界面，支持 Ollama、OpenAI API、Anthropic 等多种后端。它本身提供了基础的聊天、画图、历史记录功能，但这些只是「通用能力」。
当你的使用场景变得具体——比如每天要给客户写英文邮件、用 AI 分析股票K线图、想让文字模型通过 MCP 协议调用外部工具——光靠 Open WebUI 自身就力不从心了。Open WebUI 的解决思路是插件化：提供一套标准的扩展 API，让社区开发者可以针对特定场景做垂直功能，再像搭积木一样拼进来。
Classic298 的插件仓库就是这套插件生态中最活跃的精选集之一。截至目前已收录 9 个插件，覆盖了从界面增强、推理连贯性、到数据库维护的完整场景。
这是最重磅的插件——让你在聊天窗口里直接渲染交互式可视化图表，包括 Chart.js、D3、Vega-Lite、ECharts、Plotly、vis-network、Tone.js 等主流图表库的支持。
工作方式非常优雅：模型调用 visualize() 函数，聊天窗口内会出现一个沙箱 iframe，模型输出 SVG/HTML 内容流式渲染到 iframe 里，用户看到的就是实时更新的图表，没有任何页面跳转。
图1：Inline Visualizer 在聊天窗口内渲染交互式图表，支持 Chart.js、D3 等多种库
此外 v2 版本还引入了完整的设计系统：9 色 data-accent 调色板、主题感知颜色（自动适配 Open WebUI 的明暗模式）、预置样式的 HTML 组件（表单、表格、折叠面板），以及 6 个交互式 bridge，用于「对话式下钻」——用户可以直接和图表对话，询问数据细节。
图2：Inline Visualizer 渲染的股票仪表盘示例，支持实时交互
这是管理大规模 Open WebUI 实例必备的运维插件。长时间运行的 Open WebUI 实例会积累大量数据：旧对话记录、不活跃用户、孤立的上传文件、未清理的向量数据库记录。这些数据不仅占用磁盘空间，还拖慢检索和备份速度。
Prune 的设计理念是事件驱动 + 渐进式清理：它订阅 Open WebUI 的系统事件（system.startup.completed、chat.created、user.deleted 等），在后台缓慢地执行删除操作——不是为了快，而是为了不影响正在服务的实例。Valve 配置界面支持细粒度设置：对话保留天数、用户不活跃阈值、向量库清理范围等，干跑模式默认开启，管理员可以在 /prune 页面预览实际会删除哪些数据，确认无误后再开启真正删除。
这是最能体现开发者技术深度的插件之一，专门解决推理模型在工具调用场景下的上下文丢失问题。
当你用 DeepSeek-R1、Kimi、vLLM 等推理模型配合工具（Function Calling）时，Open WebUI 默认会在每次模型调用工具前，丢弃之前的 reasoning_content（思维链）。这导致模型在工具调用循环中「失忆」——不知道几分钟前自己为什么调用了这个工具。更糟糕的是，某些情况下会直接抛出 reasoning_content is missing 错误。
Keep Reasoning Content 通过猴子补丁（Monkey Patch）拦截 Open WebUI 中间件的 get_reasoning_format 函数，将推理模型的思维链保留并回传，使模型在工具调用循环内和多轮对话中都能引用自己的推理过程。唯一的注意事项是：需要在 Valve 中将 GPT-o 系列等「只返回推理摘要」的模型加入排除列表，避免将事后摘要误当成实时思维链喂回去。
MCP（Model Context Protocol）是 Anthropic 主导的 AI 工具调用协议，SEP-1865 定义了 MCP Apps 规范。MCP App Bridge 让 Open WebUI 能够直接渲染 MCP Apps 声明的 ui:// 资源，无需修改 Open WebUI 本身。
工作流程：模型调用 list_mcp_tools 发现工具 → 调用 call_mcp_tool 执行 → 如果工具声明了 _meta.ui.resourceUri，Bridge 获取 HTML 内容并注入服务器声明的 CSP 安全策略 → 在聊天窗口内嵌渲染。整个链路完全符合 MCP 协议规范，Bridge 只是一个透传层，不侵入 Open WebUI 核心。
图3：MCP App Bridge 在聊天窗口内渲染 MCP 服务器提供的图表类 App
图4：MCP App Bridge 渲染 KPI 仪表盘，支持模型与 UI 的双向交互
解决一个很实际的痛点：你想用某个优秀的文字模型（成本低、速度快），但它不支持图片。Vision Bridge 的解法是将图片从请求中移除，替换成文件 ID 标记，这样文字模型不会 404；然后提供一个独立的 analyze_image 工具，让模型在需要时向一个专门配置好的视觉模型提问，图片始终留在聊天中，可被多次重复分析。
在聊天窗口内撰写富文本邮件——To/CC/BCC、优先级、附件支持，生成的 .eml 文件可直接下载或通过 mailto: 协议唤起本地邮件客户端发送。
批量设置整个 Open WebUI 实例的「设置 → 界面」默认值，新用户注册（包括 OAuth 和 SCIM）自动应用这些默认值，支持向所有现有用户推送或工厂重置。
整个仓库采用单文件插件模式：每个插件目录下只有一个核心 Python 文件（tool.py/filter.py/event.py），附带一个 README 说明文档。依赖全部来自 Open WebUI 内置库（open_webui.*），无需额外 pip 安装。
插件类型与 Open WebUI 扩展 API 的对应关系：
主技术栈：Python（100%），依赖 Open WebUI 生态内部库，无外部 AI 框架依赖。
安装过程非常顺畅：进入 Open WebUI 管理面板 → 插件市场 → 粘贴仓库 URL → 安装目标插件 → 配置 Valves。无需克隆代码、无需运行脚本、不需要 SSH 登录服务器。
上手门槛取决于具体插件：简单的工具插件（如 Email Composer）5 分钟配置完毕；复杂的运维插件（如 Prune）需要理解 Open WebUI 的事件系统和数据模型，文档中有详细的 Valve 配置说明和截图，上手时间约 30 分钟。
版本强依赖：多个插件要求 Open WebUI >= 0.10.0 或特定版本范围（如 Keep Reasoning Content 仅支持 0.9.5）。升级 Open WebUI 后需同步检查插件更新，否则可能失效。
过滤器的猴子补丁风险：Keep Reasoning Content 通过修改 Open WebUI 内部函数实现，Open WebUI 每次升级都可能导致补丁位置偏移，需要作者及时更新。
非通用工具：每个插件针对特定场景，不具备通用性——你可能只需要其中 1-2 个，而不是全部安装。
无独立部署：作为 Open WebUI 插件存在，必须先有运行的 Open WebUI 实例，无法独立部署使用。
open-webui-plugins 的出现反映了一个趋势：本地 AI 聊天工具正在从「通用聊天界面」向「个人 AI 工作站」演进。Open WebUI 本身提供了开放接口，社区插件生态填补了从「能聊」到「能干活」之间的空白。
随着 MCP 协议的成熟和更多 MCP Apps 的出现，像 MCP App Bridge 这样的插件会变得越来越重要——它们让 Open WebUI 从一个聊天前端，变成了可以连接整个 AI 工具生态的统一入口。