模型使用 GPT5.4时报错，使用deepseek 和Qwen模型正常

Author: kaka008Created Apr 18, 2026Updated Apr 18, 2026

模型使用 GPT5.4时报错，使用deepseek 和Qwen模型正常，以下是我使用AI总结的报错信息，和修复方法

GPT5 Agent 兼容性报错修复指南

1. 问题背景

在 go-stock 的 AI 助手 / Agent 聊天功能中，部分 OpenAI 兼容模型可以正常使用，但在切换到 GPT5.4 时会出现如下报错：

❌ Agent 调用失败：[NodeRunError] this model has beta-limitations, temperature, top_p and n are fixed at 1, while presence_penalty and frequency_penalty are fixed at 0

该问题在 Qwen3.6 等普通 OpenAI 兼容模型下通常不会出现，因此很容易被误判为：

提示词问题
thinking 模式问题
工具调用问题
第三方平台兼容性问题

实际上，这个报错的核心原因是：

GPT-5 家族模型属于固定采样参数的 reasoning / beta-limitations 模型，不能像普通聊天模型那样自由传递 temperature、top_p、n、presence_penalty、frequency_penalty 等参数。

2. 典型现象

2.1 前端现象

AI 助手可以正常打开
发送消息后，普通模型如 Qwen3.6 正常返回
切换到 GPT5.4 后立即失败
错误通常显示在 Agent 聊天区域底部
报错中带有 NodeRunError
报错中带有 node path: [chat]

2.2 典型报错

this model has beta-limitations, temperature, top_p and n are fixed at 1, while presence_penalty and frequency_penalty are fixed at 0

3. 根因分析

3.1 直接根因

Agent 模型创建逻辑对所有 OpenAI 兼容模型统一传递了采样参数，尤其是：

temperature
max_tokens

但 GPT-5 家族模型不允许这种普通聊天模型的参数传递方式。

对于这类模型：

temperature 必须固定，不应显式传入
应优先使用 max_completion_tokens
某些默认参数即使业务代码没有主动设置，也可能被底层 SDK 默认带出并触发校验

3.2 为什么 Qwen3.6 正常

因为 Qwen3.6 这类普通 OpenAI 兼容模型通常支持：

temperature
max_tokens
常规工具调用参数

所以同一套代码在 Qwen 下可以工作，但在 GPT-5.4 下会被底层 SDK 拒绝。

3.3 真正出错链路

本项目中出错链路是：

前端 Agent 聊天 -> backend/agent/agent_api.go -> backend/agent/agent.go -> createChatModel(...) -> eino-ext OpenAI ChatModel -> go-openai 校验

关键文件：

backend/agent/agent.go
backend/agent/agent_api.go

底层依赖对 gpt-5 家族模型有明确的 reasoning model 参数限制校验。可以在本地依赖缓存中看到：

reasoning_validator.go

这个校验会把以下模型视为固定采样 reasoning 模型：

gpt-5*
o1*
o3*
o4*

一旦显式传入以下参数，就可能报错：

temperature
top_p
n
presence_penalty
frequency_penalty

4. 本次修复策略

4.1 修复目标

针对固定采样 reasoning 模型做参数分流，而不是继续对所有模型走统一配置。

4.2 修复原则

如果模型属于：

gpt-5
o1
o3
o4

则：

不显式传递 temperature
不使用 max_tokens
改为使用 max_completion_tokens
保留必要的 thinking 扩展字段

对于普通模型，继续保持原有逻辑：

传递 temperature
使用 max_tokens

5. 代码修改点

5.1 新增模型分流函数

在 backend/agent/agent.go 中新增：

buildOpenAIChatModelConfig(...)
isFixedSamplingReasoningModel(...)

职责如下：

isFixedSamplingReasoningModel(...)
- 判断模型名是否属于 gpt-5/o1/o3/o4 家族
buildOpenAIChatModelConfig(...)
- 为不同模型构造不同的 OpenAI ChatModelConfig
- 对 GPT-5 家族不传 temperature
- 对 GPT-5 家族使用 MaxCompletionTokens
- 对普通模型继续使用 MaxTokens + Temperature

5.2 修改 `createChatModel(...)`

在 backend/agent/agent.go 的 createChatModel(...) 中，不再直接硬编码：

MaxTokens: &aiConfig.MaxTokens
Temperature: &temperature

而是统一改为：

调用 buildOpenAIChatModelConfig(aiConfig)
再补充通用字段，如 Timeout
将结果交给 einoopenai.NewChatModel(...)

6. 本次实际修改摘要

本次修复已落地为以下行为：

6.1 对 `gpt-5.4` 等模型

不传 temperature
不传 max_tokens
改传 max_completion_tokens

6.2 对普通模型

继续传 temperature
继续传 max_tokens

6.3 thinking 模式

如果配置启用了 thinking，仍然通过 ExtraFields 保留：

json

{
  "thinking": {
    "type": "enabled"
  }
}

7. 回归测试

为避免后续再次把普通模型和 GPT-5 家族混用同一套参数配置，本次增加了回归测试：

backend/agent/agent_openai_config_test.go
backend/agent/model_config_test.go

覆盖点包括：

gpt-5.4 不应传 Temperature
gpt-5.4 不应传 MaxTokens
gpt-5.4 应传 MaxCompletionTokens
普通模型应继续保留 Temperature
普通模型应继续保留 MaxTokens

8. 验证命令

本问题修复后，建议至少执行以下验证：

powershell

go test ./backend/agent -run "TestBuildOpenAIChatModelConfig|TestBuildOpenAIChatModelConfig_" -count=1

以及最基本的编译验证：

powershell

go test ./backend/agent -run "^$" -count=1

说明：

第一条用于验证本次兼容性修复是否生效
第二条用于验证该包至少可以正常编译

注意：

powershell

go test ./backend/agent -count=1

当前仓库里可能仍会因为旧测试数据问题失败，这不一定代表本次修复失败。已知一个无关的存量问题是：

backend/agent/agent_test.go 直接读取 config.AiConfigs[0]
当本地数据库中没有 AI 配置时会发生数组越界

这属于测试健壮性问题，不是本次 GPT5.4 兼容性问题的根因。

9. 后续类似问题的通用修复模板

如果以后遇到：

某些模型正常
某些 GPT-5 / o1 / o3 / o4 模型异常
报错里出现 beta-limitations
报错里出现 temperature/top_p/n/presence_penalty/frequency_penalty

优先按以下顺序排查：

查看 Agent 模型创建代码是否统一传了采样参数
检查是否对 reasoning model 使用了 max_tokens
检查是否需要改为 max_completion_tokens
检查底层 SDK 是否对 gpt-5 家族做了额外校验
为该模型族单独分流参数配置

10. 给 AI 的修复指令模板

下面这段文字可以直接发给后续 AI，用来引导其快速定位并修复类似问题：

请按以下约束排查并修复 go-stock 中的 GPT-5 / reasoning model 兼容性问题：

1. 先检查 backend/agent/agent.go 中 OpenAI Agent 模型的创建逻辑。
2. 如果模型名属于 gpt-5、o1、o3、o4 家族，则不要显式传递 temperature。
3. 对这类模型不要使用 max_tokens，改用 max_completion_tokens。
4. 普通模型仍保持 max_tokens + temperature 的旧行为。
5. 不要只改前端提示词或错误文案，必须修正后端模型参数构造。
6. 修改后补充或更新 backend/agent 下的回归测试，至少覆盖：
   - gpt-5.4 不传 temperature
   - gpt-5.4 使用 max_completion_tokens
   - 普通模型仍保留 temperature
7. 运行：
   go test ./backend/agent -run "TestBuildOpenAIChatModelConfig|TestBuildOpenAIChatModelConfig_" -count=1
8. 输出时说明根因、修改文件、验证结果。

11. 简短结论

这类问题的本质不是“GPT5.4 不支持 Agent”，而是：

GPT-5 家族模型的请求参数约束更严格，不能复用普通聊天模型的参数模板。

正确做法是：

对 reasoning model 单独分流
避免传递固定限制参数
改用 max_completion_tokens
补充回归测试，防止后续回归

12. 补充兼容性问题：GPT-5.4 严格校验 Tool Schema

12.1 问题现象

在修复 temperature / max_tokens 兼容性问题之后，使用 GPT5.4 同样可能出现另一类 400 错误：

Agent 调用失败：[NodeRunError] error, status code: 400, status: 400 Bad Request, message: Invalid schema for function 'GetStockKLine': In context=('properties', 'stockCodes'), array schema missing items.

常见表现：

Qwen、DeepSeek 无问题
切换到 GPT-5.4 后立即报 400 Bad Request
错误里直接指出某个 tool/function 的 schema 无效
报错关键词是 array schema missing items

12.2 根因分析

这次不是模型采样参数问题，而是 OpenAI / GPT-5.4 对 function calling 的 JSON Schema 校验更严格。

本项目中某些工具参数把 stockCodes 声明成了：

type: "array"

但没有给出元素类型，也就是 JSON Schema 里缺少了：

items

对于这类 schema：

Qwen / DeepSeek 可能宽容处理
GPT-5.4 会直接拒绝，返回 400

也就是说，出错的根本原因是 tool schema 不符合 OpenAI 更严格的 JSON Schema 要求，而不是 tool 逻辑本身执行失败。

12.3 出错位置

关键文件：

backend/agent/tools/data_tools_wrapper.go

本次实际涉及的工具包括：

GetStockKLine
GetEastMoneyKLine
GetEastMoneyKLineWithMA

这三个 tool 的 stockCodes 参数最初都只有：

"stockCodes": {
    Type: "array",
}

这会导致最终生成的 JSON Schema 类似：

json

{
  "type": "array"
}

但合法的 schema 至少应该是：

json

{
  "type": "array",
  "items": {
    "type": "string"
  }
}

12.4 修复方法

修复方式是在 array 类型参数上补充 ElemInfo，使其生成出合法的 items.type。

实际修改为：

"stockCodes": {
    Type: "array",
    ElemInfo: &schema.ParameterInfo{
        Type: "string",
    },
    Desc:     "可选，多只股票代码列表",
    Required: false,
}

本次已经在以下位置补充该修复：

backend/agent/tools/data_tools_wrapper.go

具体是：

GetStockKLine.stockCodes
GetEastMoneyKLine.stockCodes
GetEastMoneyKLineWithMA.stockCodes

12.5 回归测试

为了防止后续又出现类似问题，本次新增了一个 schema 回归测试：

backend/agent/tools/data_tools_wrapper_test.go

新增的测试是：

TestArrayToolParamsIncludeItemsSchema

测试目标：

找到 GetStockKLine
找到 GetEastMoneyKLine
找到 GetEastMoneyKLineWithMA
将 tool 参数转成 JSON Schema
断言 properties.stockCodes.items.type == "string"

这样后续如果又把 ElemInfo 删掉，测试会立即失败。

12.6 验证命令

针对这条修复，可以直接运行：

powershell

go test ./backend/agent/tools -run TestArrayToolParamsIncludeItemsSchema -count=1

本次实际验证结果是：

修复前测试失败，提示 GetStockKLine.stockCodes items.type 缺失
修复后测试通过

如果需要做更完整的编译验证，可以继续执行：

powershell

wails build

12.7 问题总结

所以当你看到：

Invalid schema for function
array schema missing items
只在 GPT-5.4 下报错

优先不要去猜：

提示词是否太长
planning / reasoning 是否出问题
tool 执行是否超时

而是应该先检查 tool 参数 schema 是否对 array 完整声明了 items。

这类问题的本质是：

Qwen/DeepSeek 宽容
GPT-5.4 严格
根本修复应该在 schema 定义层完成

Source: ArvinLovegood/go-stock

View original on GitHub View discussion on GitHub

模型使用 GPT5.4时报错，使用deepseek 和Qwen模型正常

GPT5 Agent 兼容性报错修复指南

1. 问题背景

2. 典型现象

2.1 前端现象

2.2 典型报错

3. 根因分析

3.1 直接根因

3.2 为什么 Qwen3.6 正常

3.3 真正出错链路

4. 本次修复策略

4.1 修复目标

4.2 修复原则

5. 代码修改点

5.1 新增模型分流函数

5.2 修改 createChatModel(...)

6. 本次实际修改摘要

6.1 对 gpt-5.4 等模型

6.2 对普通模型

6.3 thinking 模式

7. 回归测试

8. 验证命令

9. 后续类似问题的通用修复模板

10. 给 AI 的修复指令模板

11. 简短结论

12. 补充兼容性问题：GPT-5.4 严格校验 Tool Schema

12.1 问题现象

12.2 根因分析

12.3 出错位置

12.4 修复方法

12.5 回归测试

12.6 验证命令

12.7 问题总结

5.2 修改 `createChatModel(...)`

6.1 对 `gpt-5.4` 等模型