[Bug] 自定义渠道deepseek-reasoner请求错误

[ZeroDeng01]

📦 部署环境

Docker

📌 软件版本

v1.52.6

💻 系统环境

Windows

🌐 浏览器

Chrome

🐛 问题描述

自定义渠道（自建onehub转发）的deepseek-reasoner无法进行多轮对话

📷 复现步骤

使用自定义渠道的deepseek-reasoner模型进行多轮对话

🚦 期望结果

可以正常进行多轮对话

📝 补充信息

lobehub报错信息（实际为onehub返回的error message）

{
  "error": {
    "code": "invalid_request_error",
    "type": "invalid_request_error",
    "message": "Provider API error: The first message (except the system message) of deepseek-reasoner must be a user message, but an assistant message detected. (request id: 20250209111601357104478LnRciBLo)"
  },
  "endpoint": "https://ai.***.com/v1",
  "provider": "superai"
}

体现为请求报文不符合deepseek的message role要求

控制台调试信息(lobehub客户端请求报文)

{
  "model": "deepseek-reasoner",
  "stream": true,
  "frequency_penalty": 0,
  "presence_penalty": 0,
  "temperature": 1,
  "top_p": 1,
  "messages": [
    {
      "content": "你是一个专业的AI助理，你会回答用户一切问题帮助用户解决各种问题。回答用户问题的时候不需要恢复任何无关的内容，会直接给出答案，必要的时候会给出相关分析。请用中文回答我的任何问题!",
      "role": "system"
    },
    {
      "content": "你好！有什么我可以帮助你的吗？",
      "role": "assistant"
    },
    {
      "content": "你是谁",
      "role": "user"
    }
  ]
}

发现请求输入里面缺失了发送的user首条消息，以至于除了system消息之外的首条消息是assistant

截图

[lobehubbot]

👀 @ZeroDeng01

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible.
Please make sure you have given us as much context as possible.
非常感谢您提交 issue。我们会尽快调查此事，并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

[dosubot]

To resolve the "invalid_request_error" with the deepseek-reasoner model, ensure that the first message after any system message is a user message. The error occurs because the first message after the system message is from the assistant, which violates the model's requirements.

The code should automatically handle this by inserting a user message with empty content if the first message is from the assistant. Here's a relevant code snippet that demonstrates this logic:

it('should insert a user message if the first message is from assistant', async () => {
    const payloadMessages = [{ content: 'Hello', role: 'assistant' as LLMRoleType }];
    const expectedMessages = [
        { content: '', role: 'user' },
        ...payloadMessages,
    ];

    const payload: ChatStreamPayload = {
        messages: payloadMessages,
        model: 'deepseek-reasoner',
        temperature: 0,
    };

    await instance.chat(payload);

    expect(instance['client'].chat.completions.create).toHaveBeenCalled();
    const actualArgs = (instance['client'].chat.completions.create as Mock).mock.calls[0];
    const actualMessages = actualArgs[0].messages;
    expect(actualMessages).toEqual(expectedMessages);
});

Ensure your implementation follows this logic to handle the message sequence correctly before sending it to the chat completion API ^[1].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[ZeroDeng01]

是否和 #5601 有关或者类似原因呀

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Is it related to #5601 or similar reasons?

[Eventidus]

不止如此，DeepSeek API的要求是user和assistant要间隔出现，不能出现连续出现。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Not only that, the DeepSeek API requires that user and assistant appear at intervals and cannot appear continuously.

[sxjeru]

是否和 #5601 有关或者类似原因呀

把 onehub 的 baseURL 和 apikey 填到 deepseek provider 用吧，只有那里会对发送的消息进行处理。

[ZeroDeng01]

是否和 #5601 有关或者类似原因呀

把 onehub 的 baseURL 和 apikey 填到 deepseek provider 用吧，只有那里会对发送的消息进行处理。

我目前是这样的！但是在自定义渠道里面deepseek-reasoner的报文按理说如果不做处理应该在system后的内容是user,然后再是assistant,这个不确定是什么原因导致的内容缺失，目前我这边历史消息限制是8,也还没触发历史消息截断！不确定这个是什么原因导致的，如同前面我贴的log和截图，感觉客户端往后台推送报文缺失了一条消息。

我的对话内容完整如前面截图：
system设定->用户:你好->AI回复内容->用户:你是谁
但是log的报文是：
system设定->AI回复内容->用户:你是谁

用户第一句问好内容缺失了。这可能是一个相关问题或者新的问题。应为我看deepseek供应商下面R1的消息加工逻辑是当首条消息不是user的话会进行空消息插入的操作，而且这部分代码逻辑在自定义供应商里面也没有引用或者复用，所以很奇怪怎么会缺失首条user消息，也不排除是我这边其他设置相关问题。其他用户如果有类似问题或者可以复现更好。我这边也可以提供我这边onehub的key供测试（我这边复现率100%）。

另外，我在想是不是可以把deepseek-r1这种特殊消息规则单独抽象出来不限定只在deepseek provider下才会处理这类规则，因为短期来看deepseek官方的api很不稳定，多数用户在用三方的r1和各种满血版。大概思路就是不限定供应商以模型的name或者id来进行这个role检查和处理操作。

以上欢迎有类似问题的用户和贡献者一起讨论
感谢各位贡献者

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Is it related to #5601 or similar reasons

Fill in the baseURL and apikey of onehub into the deepseek provider and use it, only there will be processing the sent messages.

I'm currently like this! However, in the custom channel, the message "deepseek-reasoner" should be in theory if it is not processed, the content after system is user and then assistant. This is uncertain what causes the content loss. , At present, the limit on historical messages here is 8, and the truncation of historical messages has not been triggered! I'm not sure what caused this, just like the log and screenshot I posted earlier, I feel that a message is missing from the client pushing messages to the background. My conversation content is complete as shown in the screenshot system settings->user: Hello->AI reply content->user: Who are you, but the log message is system settings-> AI Reply Content->User: Who are you`. The user's first hello is missing. This may be a related issue or a new one. It is also not ruled out that it is related to other settings here. If other users have similar problems or can reproduce them better. I can also provide my onehub key for testing (my reproduction rate is 100%).

[arvinxx]

我目前是这样的！但是在自定义渠道里面deepseek-reasoner的报文按理说如果不做处理应该在system后的内容是user,然后再是assistant,这个不确定是什么原因导致的内容缺失，目前我这边历史消息限制是8,也还没触发历史消息截断！不确定这个是什么原因导致的，如同前面我贴的log和截图，感觉客户端往后台推送报文缺失了一条消息。

我的对话内容完整如前面截图： system设定->用户:你好->AI回复内容->用户:你是谁 但是log的报文是： system设定->AI回复内容->用户:你是谁

用户第一句问好内容缺失了。这可能是一个相关问题或者新的问题。应为我看deepseek供应商下面R1的消息加工逻辑是当首条消息不是user的话会进行空消息插入的操作，而且这部分代码逻辑在自定义供应商里面也没有引用或者复用，所以很奇怪怎么会缺失首条user消息，也不排除是我这边其他设置相关问题。其他用户如果有类似问题或者可以复现更好。我这边也可以提供我这边onehub的key供测试（我这边复现率100%）。

另外，我在想是不是可以把deepseek-r1这种特殊消息规则单独抽象出来不限定只在deepseek provider下才会处理这类规则，因为短期来看deepseek官方的api很不稳定，多数用户在用三方的r1和各种满血版。大概思路就是不限定供应商以模型的name或者id来进行这个role检查和处理操作。

以上欢迎有类似问题的用户和贡献者一起讨论 感谢各位贡献者

user 和 assistant 消息配对（pair）的这个限制除了 DeepSeek 以外其实很多 provider 也会存在。但是如果给所有 provider 都默认开启这个设置则会导致一些意料之外的情况（例如 https://github.com/lobehub/lobe-chat/discussions/categories/rfc-%E7%89%B9%E6%80%A7%E5%BC%80%E5%8F%91#discussioncomment-12333376 ），因此这个配置是不太可能给所有 provider 都加上的。

如果你使用 openai Compactiable 的渠道，从 LobeChat 角度来看就是一个完全兼容 openai 格式规范的一个地址，因此不可能在这里再去做个 message 的 pair，这件事需要渠道去解决。 而如果你是用 DeepSeek 的 provider ，那么在 LobeChat 这个层面就能感知到是 DeepSeek 的格式规范，那么我们会去在应用层去满足这个 pair 的要求。

而从更加长期的角度来看， OpenAI、 Claude、 Google 这三家的模型接口已经演进分化地不尽相同了，以及 DeepSeek、OpenRouter 等后起之秀开始有了自己专有的请求出入参设计。所以可能要接受未来要更加明确请求 sdk 这件事。

• [RFC] 090 - Uniform Model Runtime #6563

[lobehubbot]

✅ @ZeroDeng01

This issue is closed, If you have any questions, you can comment and reply.
此问题已经关闭。如果您有任何问题，可以留言并回复。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

I'm currently like this! However, in the custom channel, the message of deepseek-reasoner should be in the form of system if it is not processed, the content after system is user, and then assistant. This is uncertain why the content is missing. At present, my historical message limit is 8, and the historical message truncation has not been triggered yet! I'm not sure what caused this, just like the log and screenshot I posted earlier, I feel that a message is missing from the client pushing messages to the background.

**My conversation content is complete as shown in the previous screenshot: ** system settings->user: Hello->AI reply content->user: Who are you ** But the log message is: ** system settings->AI reply content->user: Who are you

The user's first hello is missing. This may be a related issue or a new one. It should be seen for me that the message processing logic of R1 below deepseek supplier is that when the first message is not a user, the empty message will be inserted, and this part of the code logic is not referenced or reused in the custom supplier, so it is strange why the first user message is missing, and it is not ruled out that it is related to other settings here. If other users have similar problems or can reproduce them better. I can also provide my onehub key for testing (my reproduction rate is 100%).

In addition, I was wondering if it could be abstracted separately from deepseek-r1, which is not limited to only handle such rules under deepseek provider, because in the short term, the official API of deepseek is very unstable, and most users are using three-party r1 and various full-blooded versions. The general idea is to not restrict the supplier from using the model's name or id to perform role checks and processing operations.

The above is welcome to discuss with users and contributors with similar questions Thank you all contributors

In addition to DeepSeek, this limitation of user and assistant message pairing (pair) actually exists many providers. However, if you enable this setting by default for all providers, it will lead to some unexpected situations (for example, https://github.com/lobehub/lobe-chat/discussions/categories/rfc-%E7%89%B9%E6%80%A7%E5%BC%80%E5%8F%91#discussioncomment-12333376 ), so this configuration is unlikely to be added to all providers.

If you use the openai Compactiable channel, from the perspective of LobeChat, it is an address that is fully compatible with the openai format specifications. Therefore, it is impossible to make a message pair here. This matter needs to be solved by channels. If you use the DeepSeek provider, then you can perceive that it is the DeepSeek format specification at the level of LobeChat, and then we will meet the requirements of this pair at the application level.

From a more long-term perspective, the model interfaces of OpenAI, Claude, and Google have evolved and differentiated, and rising stars such as DeepSeek and OpenRouter have begun to have their own unique designs for reference. So you may have to accept the matter of requesting sdk more clearly in the future.

• [RFC] 090 - Uniform Model Runtime #6563