mirror of
https://gitcode.com/JianFeeeee/ModelRouter.git
synced 2026-11-07 09:47:23 +00:00
2b8fcaf434
## 真实缺陷（我自己的会话被它打断过）
生产实测（2026-10-16）：
provider localzen: api error 400: Upstream request failed: [invalid_request_error]
The `reasoning_content` in the thinking mode must be passed back to the API.
审计文件里成串 502，紧跟在一个 prompt_tokens=139330 的成功请求之后。
根因：`transform_request` 里写着 `msg.reasoning_content = nil`，注释理由是
"Zen 免费池不接受回传（Go 侧相反）"。**该假设方向是反的** —— 上游要的就是它。
## ★ 为什么这个缺陷极难归因（值得记）
失败是**交替**出现的：只有当上一轮**真的产出了 reasoning**（thinking 模型 +
reasoning_effort 开启 + 长上下文）时，回放那段历史才会被拒；普通回合照常 200。
于是"同一个模型同一会话，成功与失败交替"——看起来像**上游抖动或限流**，
而客户端看到的 502 与"上一轮想过"这件事**毫无关联**。
我一开始也走了弯路：用简短的 curl 复现不出来（8/8 成功），因为那些请求的
历史里没有"模型自己产出的 reasoning"。**必须让上一轮真的产生思考**才复现。
参考实现的方向一致：`openai-compat.ts` 的 `serializeMessages`（opencode 适配器
直接复用）在 assistant 回合携带 reasoning 时**就带上**该字段：
`...reasoning.length > 0 ? { reasoning_content: reasoning } : {}`
即「有就回传」，无额外条件。
## 修法
保留 `reasoning_content`（只把**空串**丢掉 —— 多余字段部分上游会挑）。
不改成"仅当 thinking 开启才回传"：我们**无法**从请求可靠判定上游是否处于
thinking 模式（真正知道的是上游）。而"有就回传"是零风险方向 ——
上游不需要时忽略即可（实测传与不传同为 200），需要时缺了就是硬 400。
## ★ 顺带发现的第二处问题
提交 `6113924` 的说明声称
"Test: TestOpenCodeGoVsZenReasoning pins the Go-keeps / Zen-strips split" ——
**该测试在全仓不存在**（`git log -S` 全历史搜索为空）。也就是说这条行为
**从未被任何判据固定**，所以它反了也没人知道。本轮补上真正的判据。
## 判据（2 条 + 变异 1/1）
- `TestOpenCodeZenKeepsAssistantReasoningContent`：assistant 回合带 reasoning 时
出站体必须有它。**咬住"被剥掉"这个具体行为**，而不是"请求成功"——
后者在非 thinking 回合下永远为真，测不出本缺陷。
- `TestOpenCodeZenDropsEmptyReasoningContent`：空串必须丢掉（配对判据，
防"改成无条件保留"这类过度修正）。
变异：恢复 `msg.reasoning_content = nil` → 报红。
## 说明
`opencodezen.lua` 在仓库内，而 `deploy.sh` 的 `sync_adapters` 只覆盖
**与仓库同名**的适配器文件 ⇒ 本修复会自动生效（生产另有 opencodego/opencode/
agentrouter 三个仅存在于线上的文件，不受影响）。