[shadyrispy]

现象

客户端把 max_tokens 给到上游上限（比如 deepseek 的 393216）时，这一发必 400，重发也没用：

400 ModelArts.81001

根因

上游把 max_tokens 当「推理 + 正文」的总预算，我们为了防「HTTP 200 但正文空串」
（officeace/chat.rs 模块头的实测坑 1）会追加 1024。追加是加法，
apply_reasoning_allowance 把 393216 加成 394240，正好越过上游的参数范围。
「客户端顶格」和「我们追加」两件事叠在一起，就是确定性失败。

上游按模型族的参数范围（实测错误原文）：

• deepseek：max_tokens range is [1, 393216]
• glm：max_tokens参数非法：限制数值范围[1,131072]
• qwen：maximum context length is 131072 tokens. However, you requested 131081 tokens (9 in the messages, 131072 in the completion)

第三条要单独留意：它是 prompt+completion 合计的上下文限制，不是 max_tokens 的参数范围。

修法

新增 clamp_max_tokens，调用点放在追加之后——顺序反了夹的是客户端原值，加完照样越界。

• 只夹上限、不设下限。没给 model、没给 max_tokens、本就没超时，一个字节都不改；
  常规请求的出站体与改动前逐字节一致。
• 上限只收错误原文写明是参数范围的两族：deepseek 393216、glm 131072。
• qwen 故意不夹。它那条是合计限制，静态上限挡不住（prompt 大的时候照样 400），
  夹了只会让人以为防住了。没测过的族同样不夹，让上游的 400 原样透传。

社区件 officeace2api 的 d8ee830 独立测到了同一组数（错误原文逐字一致），两家实现互为印证。

验证

• 新增 2 条用例：顶格 + 追加 → 夹回（先断言「追加之后确实越界」，把故障形状钉住）；
  qwen / 未知族 / 缺 model / 缺 max_tokens 全部 fail-open。
• cargo test -p agent2api-server：基点（16b8855）581 条 → 583 条，0 failed，删 0 条。

影响面

只动 officeace/chat.rs 一个文件（+85）。max_tokens 在上限内的请求出站体逐字节不变；
只有「顶格或超限」的请求从必 400 变成按上游能给的上限发出。