【解决】Dify接入MCP服务报错: PluginInvokeError: {“args“:{“description“:“[models] Error: ‘description‘“}

说在前面

大家在使用dify接入mcp服务时可能会遇到类似报错:

Exception: read llm model failed: request failed: [tongyi] Error: req_id: 
db6c8ce0bb PluginInvokeError: {"args":{"description":"[models] Error: 
'description'"},"error_type":"InvokeError","message":"[models] Error: 'description'"}

目前dify mcp智能体策略使用最多的就是
dify-plugin-agent-mcp_sse
假如你使用的是插件的Function Calling策略,可能就会出现这种报错。

开门见山

问题最终定位是由于我本地启动的mcp服务,没有给参数设置description,导致dify后台直接报错。无关插件,无关大模型。

历程

大模型问题

遇到这个问题之后,根据提示,我以为是大模型报错了,还有req_id信息,我直接联系了百炼的官方技术支持,最终得到的反馈是,这个请求并没有发送到他们那边,言外之意,这个错误是dify发出的。

更换ReAct策略

当策略更换之后,报错信息消失了,整个智能体是可以完成从工具的判断到调用再到最终结果的返回的,只不过消息的回复没办法做到流式返回,这个在之前的文章有解释过原因。
但是单凭这点信息也没办法定位到具体原因。

调试

目前其实已经没有更好的办法了,因为dify和插件都是封装好的,没有办法看到内部更详细的日志信息。
具体的过程不多说了,官网都有详细的介绍,直接说一下最后的结果。
我打印了能成功调用的工具描述:

{'name': 'weekday', 'description': '计算指定日期为星期几的工具。', 'parameters': 
{'type': 'object', 
'properties': 
{'year': {'type': <ToolParameterType.NUMBER: 'number'>, 'description': ''}, 
'month': {'type': <ToolParameterType.NUMBER: 'number'>, 'description': ''}, 
'day': {'type': <ToolParameterType.NUMBER: 'number'>, 'description': ''}}, 
'required': ['year', 'month', 'day']}}, 

这是从本地mcp server获取的工具描述(报错):

{'name': 'get_book_info', 'description': '获取图书信息', 'parameters': {
'properties': {'book_name': {'title': 'Book Name', 'type': 'string'}}, 
'required': ['book_name'], 
'title': 'get_book_infoArguments', 'type': 'object'}}

通过数次调试,最终问题定位在了这里,经过分析,我感觉应该是2个可能。

  • 自己定义的mcp-server没有成功传递参数的description
  • 参数的type信息必须要是dify官方提供的,比如用'type': <ToolParameterType.NUMBER: 'number'来代替type: 'number'

第一个解决起来比较简单,通过修改插件,给不存在description的情况加默认赋值空字符串,问题到此也就解决了。
因为中间解决思路有点离开主线,所以整个过程耗时将近3天。

问题解决思路

添加参数描述信息

这个是最简单的办法,需要对mcp服务进行改造。

修改插件

strategies\function_calling.py _init_prompt_mcp_tools方法,遍历parameters,当
description 不存在时设置为空字符串

for tool in mcp_tools: 
	parameters = tool.get("inputSchema") 
	for key, value in parameters['properties'].items(): 
	   if 'description' not in value: value['description'] = ""

说到最后

问题解决了,请你思考一下,为什么使用ReAct策略时不会报错?
可以尝试看下源码,思考思考,答案见评论区。

<think>好的,用户遇到了Dify知识库创建时的PluginInvokeError,具体错误是RuntimeError: can't start new thread。首先,我需要分析这个错误的原因。RuntimeError通常与程序运行时的环境或资源有关,而“can't start new thread”提示无法创建新线程,可能涉及线程数限制或资源耗尽的问题。 接下来,我需要考虑可能的解决方案。常见的线程问题可能包括系统级别的线程限制、Python中的线程池配置,或者代码中存在线程泄漏。用户提到Dify知识库创建时发生错误,可能是在处理插件时触发了多线程操作,导致资源不足。 首先应该检查系统的线程限制。在Linux系统中,可以通过ulimit -u查看用户可用的最大进程数,而每个线程可能被视为一个进程。如果这个值过低,可能需要调整。此外,Python的线程池默认大小也可能影响,特别是在使用大量并发任务时,超出限制会导致错误。 然后,检查代码中是否存在线程泄漏或未正确关闭线程的情况。确保在使用线程池时正确管理资源,比如使用with语句或显式关闭。此外,异步任务的处理是否正确,比如是否使用了适当的异步库或配置。 另外,服务器资源如内存或CPU过载也可能间接导致无法创建新线程。需要监控系统资源使用情况,确保有足够的资源可用。 可能还需要查看Dify的文档或社区,看看是否有其他用户遇到类似问题,是否有特定的配置建议或补丁。同时,升级Dify和相关依赖库到最新版本,可能修复了已知的问题。 最后,如果以上方法无效,联系Dify的技术支持团队,提供详细的日志和错误信息,以便进一步诊断。</think>关于Dify知识库创建时遇到的`PluginInvokeError: RuntimeError can't start new thread`错误,以下是系统性解决方案: ### 1. 检查系统线程限制 错误直接表明线程创建失败,需先检查系统级限制: - **查看当前用户线程限制**: ```bash ulimit -u # 显示max user processes ulimit -a # 查看所有限制 ``` 若数值过低(如默认1024),可通过`ulimit -u 4096`临时调整或修改`/etc/security/limits.conf`永久生效[^1]。 ### 2. 优化Python线程池配置 Dify的插件系统可能依赖Python多线程,需检查: - **限制并发线程数**:在调用插件时显式设置`max_workers` ```python from concurrent.futures import ThreadPoolExecutor with ThreadPoolExecutor(max_workers=10) as executor: # 根据系统能力调整 executor.map(your_function, tasks) ``` - **关闭闲置线程**:确保线程池使用后调用`shutdown()` ### 3. 排查资源泄漏 - **监控线程数量**: ```python import threading print(len(threading.enumerate())) # 实时输出活跃线程数 ``` 若持续增长,可能存在未释放的线程 - **检查异步任务处理**:确保Promise和async/await异常被正确捕获,避免未处理的拒绝导致线程挂起[^1] ### 4. 服务器资源扩容 - 升级实例配置:当处理大规模知识库时,建议: - CPU核心数 ≥4 - 内存 ≥8GB - 设置交换空间`swappiness=10`避免OOM ### 5. 特定环境修复方案 对于Dify v0.3.5+版本: ```bash # 修改Docker部署参数 docker run --ulimit nproc=1024:4096 -e MAX_THREADS=50 -d your_dify_image ``` Kubernetes部署需添加: ```yaml securityContext: privileged: true procMount: Default ``` ### 6. 替代方案 若持续出现错误,可尝试: - 改用多进程模式(需修改代码) - 使用异步IO替代线程池 - 分批处理知识库文档(单次<1000页) ---
评论 9
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值