ModelRouter

jianf/ModelRouter

Fork 0

mirror of https://gitcode.com/JianFeeeee/ModelRouter.git synced 2026-09-20 08:57:57 +00:00

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	c9c09b2ba2	fix(opencode): 采纳客户端真实会话 id + 超窗消息不再被限流措辞封杀两处都源于同一次排查：pi 到底有没有带会话标识、超窗为什么触发不了压缩。 ## 1) 客户端会话 id：pi 一直在发，只是被配置关掉了之前结论是「通用客户端不发会话 id」——只对了一半。pi 有会话 id，且能发： pi-ai 的 createClient 在 compat.sendSessionAffinityHeaders 为真时，会把平台会话 id（uuidv7，整个会话恒定）放到 x-session-affinity / x-client-request-id / session_id 上。该开关默认 false，而 llmsproxy 的 provider 配置里没开，所以此前一直收不到。现在网关按优先级采纳：x-session-affinity → x-session-id → session_id → body 的 prompt_cache_key，并把值经 types.ChatRequest.ClientSession 传到适配器 meta.client_session。适配器的会号种子优先级变为：客户端会话 id > 首条 user 消息指纹 > 按源固定。刻意不采纳 x-client-request-id：名字含 request，部分客户端每请求都换，拿它当会话会让上游前缀缓存永不命中（pi 总会同时发 x-session-affinity，够用）。实测：抓 127.0.0.1:8081 的真实 pi 请求，配置打开后收到 x-session-affinity = session_id = x-client-request-id = <子会话 uuid>。上游缓存确为会话级隔离（同前缀、不同会号：A 冷→命中，B 首次仍为 0），两个不同 header 值互不命中，反证网关确实采纳了客户端会话 id。 ## 2) 超窗消息必须「干净」，否则被同链的限流措辞反向封杀 pi 的 isContextOverflow 先查 NON_OVERFLOW_PATTERNS（/rate limit/、 /too many requests/、Bedrock 前缀），命中就直接判为「非超窗」——即使消息里已经有 context_length_exceeded，pi 也不会压缩重试。而 AUTO 链的失败消息天生是多 tier 原因的拼接，超窗 tier（gozen 400 maximum context length）常与配额/限流 tier（429 token plan exhausted、 cooling、no free slot）同时出现。此前把 tier 明细原样拼在归一化标记后面，等于让一条限流 tier 的措辞反过来封杀超窗识别。现在超窗走独立的干净消息： context_length_exceeded: context window is full; reduce the length of the messages (gozen/deepseek-v4.1-flash) 只留超窗措辞 + 超窗源名，不带任何其它 tier 的文本。测试：TestOverflowMessageSurvivesRateLimitedSiblingTier 用 pi 的完整判定顺序（先 NON_OVERFLOW 后 OVERFLOW）断言同链限流 tier 不再封杀超窗识别； TestClientSessionFromRequestHeaders / TestClientRequestIDIsNotUsedAsSession / TestOpenCodePrefersClientSessionID 覆盖会话采纳与优先级。	2026-09-11 16:54:31 +08:00
JianFeeeee	611e975456	fix(gateway): 上下文超窗错误归一化，客户端才能压缩重试问题：上游返回上下文超窗时，客户端（pi）既不压缩也不重试，只看到一条普通上游错误。链路两处叠加： 1. 措辞不在客户端识别列表里。pi 靠 @earendil-works/pi-ai 的 OVERFLOW_PATTERNS（25 条正则）判断超窗，而 justworker 返回的是「请精简对话历史…(Context window is full…)」——与那 25 条一条都不匹配（最接近的 /context window exceeds limit/i 也不命中，因为措辞是 "is full" 而非 "exceeds limit"）。 2. AUTO 链路的每条 tier 错误按 80 字节 OneLine 截断，而 "Context window is full" 这类短诊断词常出现在尾部，正好被按字节切掉（直连路径是 160 才保住）。修法： - 新增 overflowMarkers 识别超窗措辞（含中文写法），命中时把客户端可见错误归一化为 context_length_exceeded 前缀——它命中 pi 的 /context[_ ]length[_ ]exceeded/i，超窗因此可被发现并触发压缩重试。 - AUTO 链路每条 tier 错误宽度 80→160，短诊断词不再被截断。归一化只加前缀，原始诊断信息保留，便于定位是哪一层超窗。测试：internal/gateway/overflow_err_test.go（5 例，含「标记必须命中 pi 正则」、非超窗不得误标、80 vs 160 宽度的回归对比）。	2026-09-10 20:38:34 +08:00

Author

SHA1

Message

Date

JianFeeeee

c9c09b2ba2

fix(opencode): 采纳客户端真实会话 id + 超窗消息不再被限流措辞封杀

两处都源于同一次排查：pi 到底有没有带会话标识、超窗为什么触发不了压缩。

## 1) 客户端会话 id：pi 一直在发，只是被配置关掉了

之前结论是「通用客户端不发会话 id」——只对了一半。pi 有会话 id，且能发：
pi-ai 的 createClient 在 compat.sendSessionAffinityHeaders 为真时，会把
平台会话 id（uuidv7，整个会话恒定）放到 x-session-affinity /
x-client-request-id / session_id 上。该开关默认 false，而 llmsproxy 的
provider 配置里没开，所以此前一直收不到。

现在网关按优先级采纳：x-session-affinity → x-session-id → session_id →
body 的 prompt_cache_key，并把值经 types.ChatRequest.ClientSession 传到
适配器 meta.client_session。适配器的会号种子优先级变为：
客户端会话 id > 首条 user 消息指纹 > 按源固定。

刻意不采纳 x-client-request-id：名字含 request，部分客户端每请求都换，
拿它当会话会让上游前缀缓存永不命中（pi 总会同时发 x-session-affinity，够用）。

实测：抓 127.0.0.1:8081 的真实 pi 请求，配置打开后收到
x-session-affinity = session_id = x-client-request-id = <子会话 uuid>。
上游缓存确为会话级隔离（同前缀、不同会号：A 冷→命中，B 首次仍为 0），
两个不同 header 值互不命中，反证网关确实采纳了客户端会话 id。

## 2) 超窗消息必须「干净」，否则被同链的限流措辞反向封杀

pi 的 isContextOverflow 先查 NON_OVERFLOW_PATTERNS（/rate limit/、
/too many requests/、Bedrock 前缀），命中就直接判为「非超窗」——**即使
消息里已经有 context_length_exceeded**，pi 也不会压缩重试。

而 AUTO 链的失败消息天生是多 tier 原因的拼接，超窗 tier（gozen 400
maximum context length）常与配额/限流 tier（429 token plan exhausted、
cooling、no free slot）同时出现。此前把 tier 明细原样拼在归一化标记后面，
等于让一条限流 tier 的措辞反过来封杀超窗识别。

现在超窗走独立的干净消息：
  context_length_exceeded: context window is full; reduce the length of
  the messages (gozen/deepseek-v4.1-flash)
只留超窗措辞 + 超窗源名，不带任何其它 tier 的文本。

测试：TestOverflowMessageSurvivesRateLimitedSiblingTier 用 pi 的完整判定
顺序（先 NON_OVERFLOW 后 OVERFLOW）断言同链限流 tier 不再封杀超窗识别；
TestClientSessionFromRequestHeaders / TestClientRequestIDIsNotUsedAsSession /
TestOpenCodePrefersClientSessionID 覆盖会话采纳与优先级。

2026-09-11 16:54:31 +08:00

JianFeeeee

611e975456

fix(gateway): 上下文超窗错误归一化，客户端才能压缩重试

问题：上游返回上下文超窗时，客户端（pi）既不压缩也不重试，只看到一条
普通上游错误。链路两处叠加：

1. 措辞不在客户端识别列表里。pi 靠 @earendil-works/pi-ai 的
   OVERFLOW_PATTERNS（25 条正则）判断超窗，而 justworker 返回的是
   「请精简对话历史…(Context window is full…)」——与那 25 条一条都不匹配
   （最接近的 /context window exceeds limit/i 也不命中，因为措辞是 "is full"
   而非 "exceeds limit"）。
2. AUTO 链路的每条 tier 错误按 80 字节 OneLine 截断，而 "Context window
   is full" 这类短诊断词常出现在尾部，正好被按字节切掉（直连路径是 160
   才保住）。

修法：
- 新增 overflowMarkers 识别超窗措辞（含中文写法），命中时把客户端可见
  错误归一化为 context_length_exceeded 前缀——它命中 pi 的
  /context[_ ]length[_ ]exceeded/i，超窗因此可被发现并触发压缩重试。
- AUTO 链路每条 tier 错误宽度 80→160，短诊断词不再被截断。

归一化只加前缀，原始诊断信息保留，便于定位是哪一层超窗。

测试：internal/gateway/overflow_err_test.go（5 例，含「标记必须命中 pi
正则」、非超窗不得误标、80 vs 160 宽度的回归对比）。

2026-09-10 20:38:34 +08:00

2 Commits