参考：https://blog.csdn.net/qq_42869979/article/details/146226982

https://blog.csdn.net/gitblog_01417/article/details/150336713

Openai agent 调用时报错：

Error code: 400 - {‘object’: ‘error’, ‘message’: ‘“auto” tool choice requires --enable-auto-tool-choice and --tool-call-parser to be set’, ‘type’: ‘BadRequestError’, ‘param’: None, ‘code’: 400}

这个问题通常出现在使用 vLLM 或 Spring AI 等框架时，尤其是在尝试使用 "tool_choice": "auto" 时未配置必要的启动参数。

解决方法如下：

1. 启动 vLLM 服务时添加必要参数

如果你是通过 vLLM 启动服务，必须在启动命令中加入以下两个参数：

--enable-auto-tool-choice --tool-call-parser hermes 

• --enable-auto-tool-choice：启用自动工具选择功能
• --tool-call-parser hermes：指定使用Hermes格式解析工具调用

例如完整启动命令为：

nohup python -m vllm.entrypoints.openai.api_server \

--host 0.0.0.0 \

--port 3000 \

--model /data/Qwen/Qwen2.5-32B-Instruct-AWQ \

--tensor-parallel-size 2 \

--served-model-name Qwen25-32B-Chat-AWQ-A100 \

--quantization awq \

--gpu-memory-utilization 0.9 \

--trust-remote-code \

--enable-auto-tool-choice \

--tool-call-parser hermes \

--disable-log-request \

--enforce-eager \

--max-model-len 20000 \

>> /data/log/Qwen2.5-32B-Chat-AWQ.log 2>&1 &

2. 若使用 Spring AI 框架

确保在调用 AI 服务时，服务端已启用上述参数。如果使用的是 Spring 框架，还需检查客户端是否正确设置了工具调用逻辑，并确认服务端启动参数正确。

3. 模型选择要求

确保你使用的模型支持工具调用功能，如带有 Instruct 后缀的模型（例如 Qwen2.5-7B-Instruct），并避免使用不支持工具调用的模型（如 DeepSeek-R1 系列）。

4. 验证工具调用逻辑

确保客户端请求中使用了正确的 tool_choice 参数，如：

"tool_choice": "auto"

通过以上配置，可以有效避免因缺少必要参数导致的工具调用异常。

==========================================

可否在服务端不启用参数的其他解决办法

在服务端不启用 --enable-auto-tool-choice 和 --tool-call-parser 参数的情况下，依然可以实现工具调用功能，但需要在客户端进行相应的适配和处理。以下是几种可行的替代方案：

---

✅ 方案一：手动指定工具调用（而非使用 "auto"）

你可以通过在请求中显式指定要使用的工具，而不是依赖 "auto" 模式。例如：

{ "tool_choice": { "type": "function", "function": { "name": "get_weather" } } } 

这样，即使服务端未启用自动工具选择，也可以通过手动指定工具来完成调用。

---

✅ 方案二：使用支持工具调用的模型并自定义工具格式

如果你使用的是支持工具调用的模型（如 Qwen2.5 系列、Llama3 系列等），你可以：

• 在客户端构建符合模型要求的工具调用格式；
• 将工具定义和调用逻辑封装在请求中；
• 服务端仅需支持模型的推理能力，而不需要开启 --enable-auto-tool-choice。

这种方式适用于你对模型和工具调用逻辑有较强控制能力的场景。

---

✅ 方案三：通过中间件或代理层处理工具调用

你可以通过部署一个中间层（如 API 网关或服务代理）来处理工具调用逻辑。这个中间层：

• 接收客户端请求；
• 根据上下文判断是否需要调用工具；
• 构造符合模型要求的工具调用格式；
• 将请求转发给模型服务；
• 处理模型返回的工具调用结果并返回给客户端。

这种方式可以绕过服务端参数限制，同时保持逻辑清晰。

---

✅ 方案四：使用非工具调用模式（如返回 JSON 格式）

如果模型不支持工具调用，你可以通过以下方式实现类似功能：

• 让模型返回一个结构化的 JSON 字符串，描述需要调用的工具和参数；
• 客户端解析该 JSON 并调用实际工具；
• 将工具调用结果传回模型，作为下一轮对话的输入。

这种方式虽然不是真正的“工具调用”，但可以实现类似功能。

---

以上方案均无需在服务端启用 --enable-auto-tool-choice 和 --tool-call-parser 参数，可根据实际需求灵活选择。