musistudio
[Bug] DeepSeek-V3.1 Tool Execution Failure
Description (描述):
在使用 DeepSeek-V3.1 时，当 transformer.use 配置为特定值时，出现严重问题：
- 设置为
["tooluse"]时：弹出 API 错误API Error: 400，详细信息为Grammar error: Unknown format，类型为BadRequestError。 - 设置为
["enhancetool"]时：模型返回文字回应正常，但实际未执行任何工具代码功能，所有工具行为无实施且无结果。
此问题导致工具使用功能完全失效，影响生产环境中的自动化流程。
Steps to Reproduce (重现步骤):
- 配置 DeepSeek-V3.1 的
transformer.use为["tooluse"]或["enhancetool"]。 - 运行模型调用（例如，通过 API 或代码执行）。
- 观察错误或行为：
- 对于
["tooluse"]：立即返回400 BadRequestError。 - 对于
["enhancetool"]：收到正常文本响应，但工具未执行。
- 对于
Expected Behavior (预期行为): 应正常触发工具使用功能，实际执行工具代码，返回结果。
Actual Behavior (实际行为):
["tooluse"]：导致 API 错误，阻止任何操作。["enhancetool"]：工具功能静默失败，无执行或输出。
Environment (环境信息):
- Model: DeepSeek-V3.1
- Configuration:
transformer.useset to["tooluse"]or["enhancetool"] - Error:
BadRequestErrorwith messageGrammar error: Unknown formatfor["tooluse"] - Impact: All tool-related functionalities are broken.
Additional Context (附加信息):
- 问题可能源于配置解析或 API 请求格式错误。
- 需要紧急修复，因为工具使用是核心功能。
使用Anthropic Transformer直接透传呢，正常不
我测试了几个平台，发现是vllm的私有化部署DeepSeek会有这个问题，启动参数包括：
--enable-auto-tool-choice
--tool-call-parser deepseek_v3
--chat-template tool_chat_template_deepseekv31.jinja
并且transformer.use为[tooluse]时，vllm后端的错误是ValueError: Grammar error: Unknown format: uri .
但我比较倾向于问题点在['enhancetool']， 因为架构类似的模型Kimi-K2，在此模式下是正常可用的； 而DSV3.1在此模式下看似可能遇到了某个提前结束的符号，导致进度中断
经过多种途径的试验，现在大概率怀疑DeepSeek-V3.1的输出内容，在vllm和sglang得到的都是同样的结果（enhancetool）
@ianmage 请问vllm部署的Kimi-K2你这边能正常使用吗？我和你碰到一样的问题，都是enhancetool无法调用工具
经过多种途径的试验，现在大概率怀疑DeepSeek-V3.1的输出内容，在vllm和sglang得到的都是同样的结果（enhancetool）
@ianmage 请问vllm部署的Kimi-K2你这边能正常使用吗？我和你碰到一样的问题，都是enhancetool无法调用工具
我这边测试 vllm 跑Kimi-K2是可以调用工具的，--enable-auto-tool-choice --tool-call-parser kimi_k2你可以检查下启动有没开这两个参数
DeepSeek-V3.1不再需要任何
transformer另外vllm需要额外适配，因为v3.1是个混合模型，而推理的时候不支持工具调用
使用了vllm当前最新版本 ver 0.10.1.1，默认非思考模式（即未开启thinking=true），配置不使用transformer。 还是不能正确使用工具，表现都是回应了它要做的事情（比如读写文件），然后就停了，没有任何实际行动发生，无后续流程.
相似的参数跑Kimi-K2/GLM4.5都能正常执行，我看vllm官方的工具模板对DS-V3.1是单独提供的https://github.com/vllm-project/vllm/blob/main/examples/tool_chat_template_deepseekv31.jinja，这里与旧版v3的区别会不会在ccr这边导致工具流程的不同行为？
https://github.com/vllm-project/vllm/blob/main/examples/tool_chat_template_deepseekv31.jinja
ccr本质就是一个http client，你在使用vllm部署完模型后自己发个请求就知道是不是部署的问题了。 另外目前看起来deepseek v3.1三方的部署分为两派：
- 默认启用思考且不支持工具调用(比如魔搭)
- 默认不启用思考且支持工具调用(iflow) 具体你还是要找vllm的解决方案，经过测试，魔搭的deepseek v3.1不可用于claude code，但是iflow的和官网的表现都还可以。但是因为“极”的问题不推荐日常使用deepseek v3.1进行编码
经过多种途径的试验，现在大概率怀疑DeepSeek-V3.1的输出内容，在vllm和sglang得到的都是同样的结果（enhancetool）
@ianmage 请问vllm部署的Kimi-K2你这边能正常使用吗？我和你碰到一样的问题，都是enhancetool无法调用工具
我这边测试 vllm 跑Kimi-K2是可以调用工具的，
--enable-auto-tool-choice --tool-call-parser kimi_k2你可以检查下启动有没开这两个参数
你好，我是开启了的，我在CCR中使用kimi_k2也不是完全不能调用，而是调用了一两次或者不调用直接就停掉了。
下面是我的CCR配置，能否帮忙确认一下是否有问题？
"name": "xxxx",
"api_base_url": "http://xxx/v1/chat/completions",
"api_key": "token-xxx",
"model": ["kimi-k2"],
"transformer": {
"use": [
[
"maxtoken",
{
"max_tokens": 65536
}
],
"enhancetool",
"kimi_k2"
]
}
},```
经过多种途径的试验，现在大概率怀疑DeepSeek-V3.1的输出内容，在vllm和sglang得到的都是同样的结果（enhancetool）
@ianmage 请问vllm部署的Kimi-K2你这边能正常使用吗？我和你碰到一样的问题，都是enhancetool无法调用工具
我这边测试 vllm 跑Kimi-K2是可以调用工具的，
--enable-auto-tool-choice --tool-call-parser kimi_k2你可以检查下启动有没开这两个参数你好，我是开启了的，我在CCR中使用kimi_k2也不是完全不能调用，而是调用了一两次或者不调用直接就停掉了。
下面是我的CCR配置，能否帮忙确认一下是否有问题？
"name": "xxxx", "api_base_url": "http://xxx/v1/chat/completions", "api_key": "token-xxx", "model": ["kimi-k2"], "transformer": { "use": [ [ "maxtoken", { "max_tokens": 65536 } ], "enhancetool", "kimi_k2" ] } },```
你这个描述看起来可能是max_tokens截断了？
经过多种途径的试验，现在大概率怀疑DeepSeek-V3.1的输出内容，在vllm和sglang得到的都是同样的结果（enhancetool）
@ianmage 请问vllm部署的Kimi-K2你这边能正常使用吗？我和你碰到一样的问题，都是enhancetool无法调用工具
我这边测试 vllm 跑Kimi-K2是可以调用工具的，
--enable-auto-tool-choice --tool-call-parser kimi_k2你可以检查下启动有没开这两个参数你好，我是开启了的，我在CCR中使用kimi_k2也不是完全不能调用，而是调用了一两次或者不调用直接就停掉了。 下面是我的CCR配置，能否帮忙确认一下是否有问题？
"name": "xxxx", "api_base_url": "http://xxx/v1/chat/completions", "api_key": "token-xxx", "model": ["kimi-k2"], "transformer": { "use": [ [ "maxtoken", { "max_tokens": 65536 } ], "enhancetool", "kimi_k2" ] } },```你这个描述看起来可能是
max_tokens截断了？
试了一下去除掉maxtoken后，任务好像执行的顺畅了一些，但是还是没执行完就中断了 检查了一下vllm的日志，确实像是token超限了，你这边运行任务顺畅吗？可以完成复杂任务吗？
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:133] delta_token_ids: [8195]
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:261] Not enough token
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:132] delta_text: >
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:133] delta_token_ids: [29]
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:261] Not enough token
(EngineCore_0 pid=834) DEBUG 08-29 16:04:27 [core.py:728] EngineCore waiting for work.
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:132] delta_text:
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:133] delta_token_ids: [163586]
(APIServer pid=569) DEBUG 08-29 16:04:27 [kimi_k2_tool_parser.py:261] Not enough token
https://github.com/vllm-project/vllm/blob/main/examples/tool_chat_template_deepseekv31.jinja
ccr本质就是一个http client，你在使用vllm部署完模型后自己发个请求就知道是不是部署的问题了。 另外目前看起来deepseek v3.1三方的部署分为两派：
- 默认启用思考且不支持工具调用(比如魔搭)
- 默认不启用思考且支持工具调用(iflow) 具体你还是要找vllm的解决方案，经过测试，魔搭的deepseek v3.1不可用于claude code，但是iflow的和官网的表现都还可以。但是因为“极”的问题不推荐日常使用deepseek v3.1进行编码
大佬 iflow glm 4.6 使用 ccr 该怎么开启思考推理呢？ 试了下 cherry studio 中 是可以的
