快速结论:当你通过 API 或前端发送补全请求时,如果请求体中没有携带 tool_ids,即使在模型编辑器中已经为工作区模型配置了工具(meta.toolIds),这次请求也会在没有任何工具的情况下静默执行。优先排查客户端是否发送了 tool_ids,以及模型配置的工具是否被前端状态正确同步。
适用环境:Open WebUI v0.11.3(Docker);缺陷同样存在于 2026-09-19 的 dev 分支(commit 881f7c940087,复现基线 043784c2d0e1)。宿主机 Linux x86_64(Docker host),浏览器 Brave 1.95.102(Chromium 153.0.8010.48),Ollama 本地 0.3.22 并配合 ollama.com 云连接,模型通过云连接提供。
最快修复方案:暂无确认的一步修复方案。Issue 最终被维护者判定为“预期行为(intended behaviour)”,不会在服务端静默合并 meta.toolIds。
注意事项:按维护者说明,模型上配置的工具是聊天 UI 的默认值,而不是强制绑定;用户在 Integrations 菜单中把某个工具关掉后,请求里就是“该工具不在 tool_ids 中”,如果服务端强行把模型工具合并回来,这个开关会失效,OAuth 2.1 工具的文档化绕行方案也会失效。API 调用的契约是调用方发送 tool_ids;若要实现该行为,需要模型上一个独立的显式设置,而不是静默合并。此外,模型自造它并未拥有的工具调用、并把原始标记泄漏到消息内容中,属于另一个问题,与本次讨论无关。
问题场景
在 Open WebUI 中使用工作区模型(workspace model),并在模型编辑器的 Tools 选择中配置了工具服务器(例如 MCP 工具服务器或 OpenAPI 工具服务器),保存后对应 meta.toolIds,例如 ["server:mcp:forgejo"]。
此时通过 API 或前端发送一次补全请求:如果请求中带有 tool_ids,工具服务器的完整工具列表会正常到达后端,Open WebUI 也会按预期建立 MCP 会话;如果同一个请求省略 tool_ids,后端收不到任何 tools,本次对话就在没有工具的情况下运行。Issue 报告者在生产环境中遇到过:一个配置了 MCP 工具服务器的模型连续两轮静默地没有工具可用,模型输出了它并不拥有的工具的调用标记,原始标记直接泄漏进了消息内容,而日志中没有任何说明。
作为对照,技能(Skills)的处理方式不同:客户端发送的 skill_ids 会在服务端与模型的 meta.skillIds 合并,因此模型的技能总能生效;报告者认为工具也应当如此。
报错原文
issue: Model profile pinned tools (meta.toolIds) are not enforced server-side — requests silently run without pinned tools
[tool_ids sent] tools=['forgejo_add_issue_dependency', 'forgejo_add_issue_labels', … , 'forgejo_update_wiki_page'] (120 tools)
[tool_ids absent] tools=NONE
原因分析
根据 Issue 中的复现结果,最直接的原因是:服务端不会主动读取模型配置中的 meta.toolIds。这些工具只有在客户端请求携带 tool_ids 时才会被应用;请求省略 tool_ids 时,服务端不会回退到模型配置,也不会给出错误或警告。服务端调试日志在同一时刻仍显示已解析的模型带有 meta.toolIds: ["server:mcp:forgejo"],即配置存在但未被使用。
该缺陷在工具解析阶段触发,发生在联系任何模型之前,因此与具体后端(Ollama、vLLM、OpenAI 等)无关;Issue 中用了一个约 60 行的 OpenAI 兼容记录端点来精确记录 Open WebUI 发送的内容。
维护者在后续回复中明确说明这属于预期行为:模型上配置的工具是聊天 UI 的默认值而非硬性绑定,用户可以在 Integrations 菜单中逐次开关;关闭即“该工具不在 tool_ids 中”。若服务端把模型工具合并回来,这个开关就会失去作用,OAuth 2.1 工具的文档化绕行方案也会随之失效。API 的契约是调用方发送 tool_ids。
环境排查
- 确认 Open WebUI 安装方式与版本:Issue 中为 Docker、v0.11.3;同时确认是否在 dev 分支(
881f7c940087)上仍可复现。 - 确认宿主机系统:Linux x86_64(Docker host)。
- 确认浏览器版本:Brave 1.95.102(Chromium 153.0.8010.48),用于判断前端工具状态是否陈旧。
- 确认 Ollama 版本与连接方式:本地 Ollama 0.3.22 +
ollama.com云连接,模型经由云连接提供。 - 确认工具服务器类型:Admin → Settings → External Tools 中注册的 MCP 工具服务器(Issue 中为约 120 个工具的 Forgejo 实例),以及模型编辑器中是否已选中该工具服务器。
- 确认请求体中是否包含
tool_ids,以及其值与meta.toolIds是否一致。
解决步骤
- 先在 Admin → Settings → External Tools 中注册好工具服务器。
- 创建一个工作区模型,在模型编辑器的 Tools 区域选中该工具服务器并保存,使其写入
meta.toolIds(例如["server:mcp:forgejo"])。 - 发送一次带
tool_ids的请求,确认工具服务器完整工具列表能够到达后端:{"model": "tools-model", "messages": [{"role": "user", "content": "hi"}], "tool_ids": ["server:mcp:forgejo"]} - 发送同样但不带
tool_ids的请求:{"model": "tools-model", "messages": [{"role": "user", "content": "hi"}]} - 开启服务端调试日志,观察已解析模型是否仍带有
meta.toolIds、以及后端是否收到tools数组。 - 若确认请求省略了
tool_ids,按当前设计请由客户端显式补上tool_ids;不要把“服务端自动合并模型工具”当作可用方案,维护者已明确表示这属于预期行为,需要的是模型上一个独立的显式设置。 - 如果前端出现工具状态与模型配置不一致(例如从 pinned 侧边栏模型开始聊天时沿用上一个模型的
tool_ids/skill_ids),可参考相关 Issue #29090、#29050、#29199、#21760 一并排查客户端状态同步问题。 - 如果遇到的是“模型自造工具调用、标记泄漏进消息内容”,请单独开一个新 Issue,并在能正确附带工具的情况下复现后再提交。
验证方法
在相同模型、相同消息内容下对比两次请求:带 tool_ids 时后端应收到完整的 tools 数组并建立 MCP 会话;不带 tool_ids 时后端收到的 tools 为空或不存在。同时检查服务端调试日志,确认已解析模型仍携带 meta.toolIds,但该配置未被使用、也没有任何警告输出。如果修复行为是在配置了工具的情况下必须让工具生效,则应在不带 tool_ids 的请求中也能观察到工具被应用——但请注意,这并非本 Issue 结论所支持的行为。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。

![[Bug]: Qwen3.5 structured output doesn't work](https://www.chat-gpts.plus/wp-content/uploads/2026/09/35700-bd9ee480-768x403.jpg)
![[Model Support] DeepSeek-V4.1 Tracking Issue](https://www.chat-gpts.plus/wp-content/uploads/2026/09/56400-8f0f3572-768x403.jpg)