调用 AI 工具却提示缺少 MCP？LiteLLM 更新修复依赖加载

北京时间 11 月 10 日，LiteLLM 发布 1.108.4 LTS，将基础安装下工具调用误触发 MCP 依赖加载的修复纳入补丁。对直接使用 Python SDK 开发 AI 助手、接入函数工具的团队，这类报错可能让请求在发给模型之前就中断。本文结合订单查询助手，解释错误从哪里进入、修复如何分流，以及升级后应该验证哪些环节。

原创 AI 概念插画，用轨道分流表示工具路径检查。

[配图建议：一个工具请求先经过路径开关，再进入对应处理模块，突出检查先于依赖加载 + 深青与珊瑚色编辑插画]

1. 一个缺少 MCP 的报错，为什么会挡住普通工具调用

LiteLLM 提供统一的模型调用接口，既有供应用直接导入的 Python SDK，也提供网关产品。团队可以通过它对接不同供应商，并处理模型返回的工具调用信息。官方入门文档

此次 LTS 发布记录明确列出，基础安装下，completion()、responses() 和 Messages 工具调用可能遇到 No module named 'mcp'，相关回归源于 v1.106.0。版本发布时间为 UTC 2026 年 11 月 9 日 23:00，对应北京时间 11 月 10 日 07:00。1.108.4 LTS 发布记录

设想一个订单助手。应用向模型提供查询订单的函数定义，等待模型返回函数名与订单号，再由应用查询业务系统。开发者已经准备好普通函数工具，调用 SDK 时却在本地堆栈中看到缺少 MCP 的异常。排查应先落到依赖导入发生的位置。

对应修复把问题定位到网关处理器的导入链。原有路径在检查工具是否需要网关处理时，过早加载了带有额外依赖的处理模块。PR 还记录了固定某些 MCP 版本后遇到类型导入失败的情况，说明需要同时看包版本与调用路径。修复 PR #45961

有一个日期值得分清。原修复于 10 月 20 日合并到主分支，本轮新闻是它进入新的 LTS 补丁。对于跟随长期支持版本的团队，发布渠道里的修复是否已经到位，直接影响升级选择。PR 合并记录

[配图建议：订单助手的请求在SDK依赖导入处中断，后方模型和订单服务尚未执行，用箭头标明发生阶段 + 分层调用示意图]

2. 修复怎样工作，先看工具配置再加载处理器

1.108.4 标签中的源码新增了轻量的 tool_precheck.py。它先读取工具类型与 server_url，判断配置是否指向 LiteLLM MCP 网关。普通函数工具经过这一检查，可以继续走对应的模型调用路径。completion() 与 responses() 的入口都接入了这个判断。固定版本预检查模块、调用入口源码

工具列表里的配置决定后续路径。 官方配置参考说明，请求发给 LiteLLM 的模型接口、需要使用其已配置的 MCP 服务时，server_url 可以使用 litellm_proxy，也可以用带具体服务名的选择形式。这类字符串承担网关选择作用，实际 MCP 客户端连接则使用相应网络端点。MCP 配置参考

源码也处理了形如 /mcp/<name> 的网络地址，并结合网关注册模块能否加载来决定是否进入网关路径。因此，开发者阅读错误时，应把完整工具配置与部署形态一起保留，单看 URL 的末尾容易遗漏判断条件。固定版本路径判断

对订单助手，这带来的变化是普通函数工具可以先通过自身路径完成请求分发。真正使用 LiteLLM MCP 网关的应用，仍应按网关文档准备服务配置、依赖与访问条件。修复后的分流，让这两类应用各自进入所需的处理模块。

这个设计也给开发团队一个排错顺序。先确认调用的是哪个 SDK 入口，再检查工具的 type 和地址选择，随后观察加载了什么模块，最后核对模型供应商收到的请求。每一步都有具体证据可查。

[配图建议：函数工具、远程MCP和LiteLLM网关工具在检查节点分流，网关依赖只出现在相应分支 + 清晰的技术流程图]

3. 升级后的验收，要覆盖请求和业务结果

官方回归测试覆盖多个入口，并模拟网关处理器无法加载的情况，检查普通工具路径是否仍能向下执行。测试还保留了明确网关工具进入处理器，以及远程地址在相应环境下传递给供应商的用例。1.108.4 回归测试

对产品团队，可以沿着自己的真实工作流补上业务验收。订单查询助手至少应检查以下三步。

• 请求成功到达模型。 记录 SDK 异常、供应商返回状态和请求标识，确认导入阶段已经通过。
• 模型返回了可处理的工具调用。 核对函数名、参数格式与订单号，确认应用能够解析。
• 工具结果回到回答中。 检查查询是否执行、结果是否关联到正确请求，以及最终回答是否使用了结果。

三步分别暴露依赖、接口兼容和应用执行问题。例如，模型返回函数调用后，应用还要执行查询并提供结果。仅凭请求返回成功，难以判断订单助手是否已经完成工作。

使用远程 MCP 的团队，还应确认所选供应商与接口支持对应工具格式。该 PR 的验证记录显示，某条请求通过依赖加载后，仍会由供应商返回工具类型不支持的错误。这为后续排查提供了新的位置。PR 验证记录

这次更新更适合已遇到相关导入错误、使用基础 SDK 安装，或准备从主分支修复迁回 LTS 的团队。已经部署网关的团队，可以用现有请求做回归检查，观察实际工具执行是否保持完整。

[配图建议：依次展示请求到达模型、返回函数参数、业务查询结果进入回答，三个位置各有一项验收记录 + 教程式信息图]

4. 今天就能做的检查，在干净环境重放一个请求

先在独立测试环境确认目标版本，并保留原应用的依赖锁定记录。采用基础 litellm 分发包的项目，可以按下列方式安装本次版本，再查询实际安装结果。

python -m pip install "litellm==1.108.4"
python -c "from importlib.metadata import version; print(version('litellm'))"

随后使用同一模型配置与同一条测试需求，先运行文本请求，再运行普通函数工具请求。工具可以选择返回固定测试订单状态的查询函数，这样更容易判断错误来自调用链的哪一段。整个演练记录实际结果，方便团队复查。

若项目还使用其他工具路径，可以增加对应检查。下面是一份验证计划，按应用实际配置填写结果。

对于“开发机正常、部署后失败”的情况，还可以对照两边安装清单。开发机可能因其他项目装有额外包，干净环境更容易暴露隐含依赖。把最小可重放请求与完整错误堆栈留在问题记录里，下次 SDK 升级时就有现成回归用例。

[配图建议：同一请求分别在开发环境和干净测试环境运行，旁边对照安装版本与执行阶段 + 简洁的开发者检查图]

总结，先让最小工具请求完整跑通

LiteLLM 1.108.4 LTS 把依赖加载修复带到了长期支持版本，基础 SDK 用户可以据此核对自己的调用路径。今天先在独立环境重放一个普通函数工具请求，依次检查请求分发、参数解析和结果回传，再验证项目实际使用的 MCP 路径。你遇到的工具调用失败，停在依赖导入、接口接收，还是业务执行？先保存能定位这一阶段的证据。

[配图建议：一条最小工具请求贯穿检查、分发、执行和回答，终点留下一份可重复使用的回归记录 + 深青色极简编辑插画]

资料核查于 2026 年 11 月 10 日。本文依据官方 LTS 发布记录、PR、固定版本源码及文档编写，完成源码与回归用例阅读。PR 中的运行结果归属于贡献者验证，本站未执行模型请求。封面由内置图像工具原创生成，为概念插画。