为何 Command Code Go 反代出来的思考和一般 API 调用的思考模式不同

[sakura-madoromi]

1. 一些请求不会返回思考，而是直接输出一句话或直接输出工具调用

2. 一些思考被包含在 content 中而不是 thinking 中

请问这是正常现象吗？CommandCode Goat 会出现此类现象吗？还是说这是反代导致的？

[sakura-madoromi]

升了 Goat 试了一下，应该就是反代导致的。OmniRoute 内置了两套协议，当且仅当 OpenAI Chat Completions 协议不可用时回退到 Command Code API 协议，但是此项目全部使用 Command Code API 那个构食协议，导致 think 块解析有问题

[sakura-madoromi]

参考 OmniRoute 的实现，可以在 chat completion 接口 403 的时候 fallback 到 Command Code API（OmniRoute 是每个请求尝试一次，这样会增大 TTFT，我的想法是用 Plan 类型来判断并加入缓存）。 如果 Maintainer 同意我可以发一个 PR

[Mars-Sea]

感谢分析！欢迎提 PR。

一些实现上的建议，供参考：

• Plan 类型缓存的思路很好，可以显著避免每次请求的双重 TTFT。建议把协议选择结果（按 model 或按 account）持久化到一个轻量缓存里，命中时直接走首选协议，失败时再降级并更新缓存。
• 两个协议的消息转换逻辑建议拆成独立的 converter，避免 adapter 主流程里堆太多条件分支。
• 如果测试层面能补上 reasoning 块解析的回归用例就更好了——覆盖 thinking 正常输出、thinking 混入 content、无 thinking 三种情况。

期待你的 PR，有任何问题随时在 issue 里讨论！

[sakura-madoromi]

另，我还发现了 Command Code 的 API 的一个特殊兼容性问题，仅在 DeepSeek V4 Flash 上出现，稍后我会提一个新的 Issue 说明情况

[sakura-madoromi]

@Mars-Sea 您这边使用 deepseek-v4-flash 的时候有出现上述的情况吗？能否帮忙确认一下，我怀疑这个问题出在 Command Code 提供的 Chat Completion API 上

[sakura-madoromi]

我这边做了一些缓解工作，但是上述问题仍然存在（频率有所减轻）

[Mars-Sea]

@Mars-Sea 您这边使用 deepseek-v4-flash 的时候有出现上述的情况吗？能否帮忙确认一下，我怀疑这个问题出在 Command Code 提供的 Chat Completion API 上

我仔细看了看确实出现了这样的情况

[sakura-madoromi]

@Mars-Sea 您这边使用 deepseek-v4-flash 的时候有出现上述的情况吗？能否帮忙确认一下，我怀疑这个问题出在 Command Code 提供的 Chat Completion API 上

我仔细看了看确实出现了这样的情况

那这个问题应该就是上游 Command Code 的问题了，到时候去给官方提 issue 吧，后续我考虑几个缓解方案看看能不能放到 PR 里

[sakura-madoromi]

而且我这边修复解析之后，感觉模型的行为更像是把 reasoning 放到了 content 中，而不是 think 块中（排除解析错误的可能）。真是看不懂 Command Code 到底在搞什么鬼

[sakura-madoromi]

不知为什么给我一种在用 codex desktop 的感觉（

[Mars-Sea]

不知为什么给我一种在用 codex desktop 的感觉（

我看了看其它模型，好想没有出现这样的情况，只有v4有，你测试看看longcat，目前这个模型免费

[sakura-madoromi]

不知为什么给我一种在用 codex desktop 的感觉（

我看了看其它模型，好想没有出现这样的情况，只有v4有，你测试看看longcat，目前这个模型免费

对，这个东西就是 V4 特有的 bug，太神人了

[sakura-madoromi]

合并 PR #22 后我会提一个新的 PR，包括对于 DeepSeek 思考问题的缓解方案，具体如下：

1. 使用流式输出调用 Chat Completions API 中的 deepseek-* 模型时
2. 如果第一个返回的是 contend 块而非 reasoning 块
3. 则立即终止此请求，并插入一条新的 user 信息提醒模型要进行推理

此方案最坏情况下可能造成 2*TTFT 的延迟，但是随着轮次的增长，由于上下文惯性，模型会更倾向于输出 reasoning，对平均 TTFT 的影响并不大（并且相较于模型未推理造成的性能损失，我认为这是可接受的）。并且，我为此功能设计了一个开关（默认关闭），用户如果有需求可以自行开启。

实测结果表现良好，具体的对话数据我稍后上传。

[sakura-madoromi]

合并 PR #22 后我会提一个新的 PR，包括对于 DeepSeek 思考问题的缓解方案，具体如下：

1. 使用流式输出调用 Chat Completions API 中的 deepseek-* 模型时
2. 如果第一个返回的是 contend 块而非 reasoning 块
3. 则立即终止此请求，并插入一条新的 user 信息提醒模型要进行推理

此方案最坏情况下可能造成 2*TTFT 的延迟，但是随着轮次的增长，由于上下文惯性，模型会更倾向于输出 reasoning，对平均 TTFT 的影响并不大（并且相较于模型未推理造成的性能损失，我认为这是可接受的）。并且，我为此功能设计了一个开关（默认关闭），用户如果有需求可以自行开启。

实测结果表现良好，具体的对话数据我稍后上传。

此问题似乎是 DeepSeek 系列模型的固有问题，我在官方 API 中也发现了类似的情况，只不过 Command Code 的 TTFT 较大所以我只注意到了它。上述引用的问题为误报，此 Issue 的主要问题已经解决完毕，我将关闭它。