复现步骤：
- 单独用deepseek配置到虚拟模型里没有任何问题。
- deepseek + 小米plan 的轮询模式，没有任何问题。（姑且认为和国内的厂商结合都没问题）
- 小米plan + 中转站API（new-api调用opus模型），没有任何问题。（姑且认为国内的厂商和new-api结合都没有问题）
- deepseek + 中转站API（new-api)，多轮的时候提示400，报错内容是the content[].thinking in the thinking mode must be passed back to the api
昨天有新闻说deepseek修了一个第三方agent调用api的400报错，今天测试发现没变化，说明修复的不是我遇到的这个问题。也可能我这个问题不是它的bug，而仅仅是我自己程序的bug。
问题点大概是多轮调用，尤其是用了tools的时候，tools的上下文里需要包含thinking标签的内容，每轮都要带，不然deepseek就会报错400，如果都带就没问题，都不带就400。还有不能传think=false之类的，因为claude code默认给传think effort，这时候deepseek要求必须think=true。所以路就都走死了。
所以deepseek和new-api混用的时候报错400的问题，我暂时不想修复了。
解决办法，我的使用建议是（下边任选一种都没问题）：
- 只用deepseek自己。
- 只用deepseek + 国内正规大模型厂商（如小米）
- 中转站（opus） + 国内其他正规大模型厂商（如小米）
其他还有问题欢迎补充。
复现步骤：
昨天有新闻说deepseek修了一个第三方agent调用api的400报错，今天测试发现没变化，说明修复的不是我遇到的这个问题。也可能我这个问题不是它的bug，而仅仅是我自己程序的bug。
问题点大概是多轮调用，尤其是用了tools的时候，tools的上下文里需要包含thinking标签的内容，每轮都要带，不然deepseek就会报错400，如果都带就没问题，都不带就400。还有不能传think=false之类的，因为claude code默认给传think effort，这时候deepseek要求必须think=true。所以路就都走死了。
所以deepseek和new-api混用的时候报错400的问题，我暂时不想修复了。
解决办法，我的使用建议是（下边任选一种都没问题）：
其他还有问题欢迎补充。