Open WebUI 工具调用实战指南5 分钟跑通第一个自定义工具【免费下载链接】open-webuiUser-friendly AI Interface (Supports Ollama, OpenAI API, ...)项目地址: https://gitcode.com/GitHub_Trending/op/open-webui你让 AI运行这段代码把结果给我它却只能礼貌地回你一段文字——代码并没有真的跑起来。Open WebUI 的工具调用系统就是为这个痛点而生的它让模型在对话中自己决定调用哪个函数由服务端执行再把真实结果塞回上下文继续对话。聊天没变但 AI 从此会干活了。AI 只会输出代码不会执行让工具调用接管执行说白了模型本身不碰任何真实系统。整个机制用一个类比就能说透模型是接线员工具系统是总机。接线员永远不亲自接线它只报一个分机号函数名和一句话参数总机负责真正拨出去然后把通话结果传回来。技术上对应的就是 native function calling模型输出一段结构化的函数调用JSON后端中间件拿到后找到对应的 Python 函数执行结果作为新消息追加回上下文模型第二次被调用时就能看到工具结果再产出最终回答。模型全程只报号执行全在后端。跟一次完整调用从输入框到工具返回的五个环节按时间顺序一次工具调用在 Open WebUI 里走过五步。第一步你在聊天框选中某个工具或依赖内置工具发出消息。第二步请求进模型之前聊天管道中间件backend/open_webui/utils/middleware.py组装本次可用的工具集把你选中的自定义工具按权限过滤、按模型能力和功能开关注入内置工具、再把 MCP 服务器工具合进来。第三步backend/open_webui/utils/tools.py把每个函数转成模型能懂的工具定义名字、参数、类型同时把用户身份、聊天文件这类模型不该看见的隐藏参数绑定到函数上。第四步模型决定调用返回函数调用结构中间件的tool_call_handler匹配到对应函数异步执行结果写回消息列表。第五步模型带着工具结果被再次调用给出最终答案。三个关键设计决策为什么工具是代码而不是配置决策一工具即源码存数据库、按请求编译。问题如果用户写个自定义工具就得改代码重启服务插件生态不可能存在。方案backend/open_webui/models/tools.py把工具整段 Python 源码存进tool表请求时由插件加载器编译成模块并在请求内按内容做缓存、内容变了自动重载。代价任意 Python 在服务端执行本质是信任关系所以整套机制被 ENABLE_PLUGINS 总开关和每个工具的 access grants 权限项双重把关。决策二规格从函数签名推导而不是手写。问题手写 schema 和真实函数代码一旦漂移模型就会用错误的参数调用。方案系统用 pydantic 直接根据函数的类型注解和 docstring 生成 OpenAI 风格函数定义代码是唯一事实来源。代价你的注解和 docstring 必须写干净含糊的注释会得到含糊的工具定义模型表现随之变差。决策三注入前按权限与能力三重过滤。问题把机器上所有工具塞给每个模型既烧 token 又让模型碰到不该碰的能力。方案中间件组装时逐层过滤——用户对工具是否有读权限、模型是否声明支持该能力、功能开关是否打开三者全过才注入。代价过滤逻辑分散在多层工具神秘消失时你得把三层都查一遍。5 分钟跑通第一个自定义工具最小上手路径✅ 最短体验路径如下四步走完。拉取代码git clone https://gitcode.com/GitHub_Trending/op/open-webui按 README 用 docker compose 或直接脚本启动。进入 Tools 页面新建工具粘贴下面这个最小示例。访问范围设为自己或 Everyone保存。在聊天输入框选中这个工具问帮我算 2 加 3你会看到模型调用add(2, 3)并返回 5。def add(a: int, b: int) - int: Add two numbers together and return the result. return a b从 API 注册到 MCP 接入扩展自定义工具的三个入口写一个函数存进 Tools 页面是最低门槛的扩展方式需要编程化管理时直接调backend/open_webui/routers/tools.py暴露的 create/update API 即可注册工具。函数需要管理员配置的运行时参数就在源码里声明一个 pydantic 的Valves类页面上会自动出现对应表单。已有 MCP 或 HTTP 工具服务器的场景走 Connections 页面注册即可不用写代码。工具调用不生效先查这三个高频坑问题工具已选中但模型从不主动调用。解法先确认模型是否支持 native function calling——小模型或部分 API 模型不支持这类模型下工具定义会被降级处理。问题改了工具代码行为还是旧的。解法模块缓存按内容变化失效正常保存即重载仍不对就先确认保存请求真的写库成功保存失败时响应是错误码而非 200。问题内置的代码执行工具不工作。解法检查 code interpreter 功能开关与沙箱执行环境是否启用这属于功能开关层的过滤不是权限问题。回到开头的场景脚本真的会跑了开头运行脚本给我结果的诉求现在由模型发起函数调用、服务端执行、结果回流上下文这条链路闭环解决。可以留意的前瞻点内置工具库正从文件、知识库检索向终端与自动化扩展配合 subagents 机制多工具协同编排是这套架构下一步最值得跟踪的方向。【免费下载链接】open-webuiUser-friendly AI Interface (Supports Ollama, OpenAI API, ...)项目地址: https://gitcode.com/GitHub_Trending/op/open-webui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考