mirror of
https://gitcode.com/JianFeeeee/ModelRouter.git
synced 2026-11-07 09:47:23 +00:00
## 真实缺陷 ①:glm-5.1 恒 400(用户报"这个模型不可用")
上游回 `400 {"code":11150,"msg":"the reasoning effort value is not supported
by the current model"}`。探针逐字对照实验(body 完全由探针给定):
glm-5.1 裸(无该字段) → 400 11150 ✗
glm-5.1 + reasoning_effort:medium → 200 ✓
glm-5.1 空串 → 400 11150 ✗
**任何非空档位都被接受**(low/medium/high/xhigh/max/minimal 逐个 200);
而其余 15 个 buddy 模型裸跑全 200(多带该字段也无害)⇒ 这是 glm-5.1 **独有**要求。
参考 product.ts:237 声明它只有 `['medium']` 一档。
## 真实缺陷 ②:流式请求缺 Accept: text/event-stream → 空回复
不发该头时上游**接受请求(200)但只回一帧空内容**(completion_tokens=0、
finish_reason 直接 stop),既不报错也不产出正文 —— 表现是"模型不回答",
极易误判成模型坏了或额度不足。同 body 加该头 → 39~43 帧正常 SSE。
参考 buddy-adapter.ts 的 send() 固定发它。
## 实现:内置 `buddy.lua`(不是插件自装)
**为什么不用插件自装适配器**(channels-zcode/qoder/cline 那条路):
`channels.lua` 的**主 chunk 已 248 个 local**,Lua/LuaJIT 上限是 200 ——
超出的 local 会**静默退化为全局**(`luac -p` 通过,运行时才 `attempt to call
global 'x' (a nil value)`)。实测证据:`adaptersDir` 是第 208 个 ⇒ 调用点拿到 nil
⇒ `loadAnthropic` 静默返回 nil ⇒ **zcode 适配器从来没有基座**
("复用 anthropic"的意图从未生效,只是它自写了全部转换所以能用)。
我第一版就是这么写的,结果适配器装不上(`adapter channels-buddy not loaded`),
且 `hy3`/`glm-5.3`/`kimi-k3-1` 全被打成空回复 —— 只有 `glm-5.2` 因多源兜底
"看起来正常",症状再次指向错误方向。
⇒ 改走内置适配器(与 trae/sensenova/opencodezen 同性质,`deploy.sh` 自动同步),
`channels.lua` 只改**一行** `adapter = "buddy"`,不再触碰那个已贴上限的文件。
## ★ 排查中发现的沙箱事实(值得记)
**适配器运行在另一个沙箱 VM**:那里 `__llmsproxy_plugin_dir` 与
`LLMSPROXY_PLUGIN_DIR` **都不存在**(实测均为 nil),**也没有文件系统访问**。
故任何"在适配器里读兄弟适配器源码"的写法都拿不到基座且静默降级。
判据 `TestBuddyAdapterDefinesAllTransforms` 咬住这条。
## 顺带修:hy4-preview-x 从目录剔除
实测它对上游**恒回 11102**(`model service info not found`,加/不加
reasoning_effort 都一样 ⇒ 与 effort 无关,是后端未开放)。它被服务端 agents
引用,于是 `agentRef` 例外把它放回目录 ⇒ 用户选中必 400 而错误指向模型。
参考用**白名单重建**达到同样效果(其兜底表里没有它)。本仓加等价的精确黑名单
(只放实测确认的,不做猜测),并在两处兜底目录里一并剔除。
## 验证
buddy **15/15 模型全部可用**(含 glm-5.1),逐一实测无失败;
`hy4-preview-x` 已从源目录消失(16 → 15)。
## 判据(3 条 + 变异 2/2)
- `TestBuddyAdapterEffortAndHeaders`:glm-5.1 补 medium / hy3 不补 /
调用方给的档位被尊重 / Accept 必须是 SSE + 身份头齐备
- `TestBuddyAdapterKeepsOpenAIWire`:协议转换与 openai 一致(只是补两个字段)
- `TestBuddyAdapterDefinesAllTransforms`:**四个转换函数都存在** ——
咬"静默降级"而非"某模型能回话"(后者会被多源兜底掩盖,本会话已栽两次)
- 变异:删 stream_chunk / 不补 effort → 均报红
## 一起提交的其它独立缺陷(均在本次调查中发现)
- buddy 目录过滤(四类判据)与 hy4-preview-x 剔除
202 lines
9.0 KiB
Lua
202 lines
9.0 KiB
Lua
local adapter = {}
|
||
|
||
adapter.name = "buddy"
|
||
adapter.version = "1.0.0"
|
||
adapter.endpoint = "/chat/completions"
|
||
adapter.headers = {}
|
||
|
||
-- Claude-behind-OpenAI upstreams (tabitoken, 扇贝, …) convert /chat/completions
|
||
-- to the Anthropic Messages API internally, so they inherit Anthropic's
|
||
-- tool id rule: ^[a-zA-Z0-9_-]{1,64}$, enforced by rejecting the WHOLE request
|
||
-- with "Invalid tool use format" / "tool_use.id: String should match pattern".
|
||
-- Plain OpenAI has no such rule, so an OpenAI-compatible model can mint an id
|
||
-- like "bash:0" (observed from moonshotai/kimi-k3). In a fan-out router that id
|
||
-- is replayed to every other source, so one such id kills every Claude slot at
|
||
-- once and an AUTO request falls through all tiers.
|
||
--
|
||
-- safe_tool_id is pure and deterministic, so a tool_calls entry and its
|
||
-- matching tool_call_id are rewritten identically within one request. A
|
||
-- rewritten id keeps an 8-hex digest of the ORIGINAL id, without which two
|
||
-- distinct ids could collapse into one ("a:b" and "a_b") and become an
|
||
-- unpaired/duplicate tool call. Already-legal ids are returned untouched, so
|
||
-- well-behaved traffic is byte-identical to before.
|
||
-- (anthropic.lua carries the same helper; Lua adapters have no shared prelude.)
|
||
local TOOL_ID_MAX = 64
|
||
|
||
local function safe_tool_id(id)
|
||
if type(id) ~= "string" or id == "" then return id end
|
||
local clean = string.gsub(id, "[^A-Za-z0-9_-]", "_")
|
||
if clean == id and #clean <= TOOL_ID_MAX then
|
||
return clean
|
||
end
|
||
local digest = string.sub(sha256_hex(id), 1, 8)
|
||
local keep = TOOL_ID_MAX - #digest - 1
|
||
if #clean > keep then clean = string.sub(clean, 1, keep) end
|
||
return clean .. "_" .. digest
|
||
end
|
||
|
||
-- 需要补 reasoning_effort 的模型 → 补哪个档位。
|
||
--
|
||
-- 唯一出处:参考 product.ts:237 声明 glm-5.1 的 reasoningEfforts 只有 ['medium']。
|
||
-- 但实测**任何非空档位都被接受**,故这里取 medium(与参考声明一致)。
|
||
local NEED_EFFORT = {
|
||
["glm-5.1"] = "medium",
|
||
}
|
||
|
||
-- OpenAI /chat/completions format (pass-through, strip provider-specific fields)
|
||
function adapter.transform_request(raw_body)
|
||
local ok, req = pcall(json.decode, raw_body)
|
||
if not ok then return raw_body end
|
||
-- The gateway's private control fields are GONE from the body (v2): the
|
||
-- neutral `thinking` field carries that intent and each adapter maps it in
|
||
-- its own protocol terms. These upstreams have no thinking switch at all,
|
||
-- so the field is simply dropped here — which is what the nil-ing below
|
||
-- used to do, except the field being dropped is no longer the kernel's
|
||
-- private one.
|
||
req.thinking = nil
|
||
req.extra_body = nil
|
||
-- ★★ buddy 的 glm-5.1 **要求请求体里有非空的 reasoning_effort**,
|
||
-- 否则上游回 400:
|
||
-- {"code":11150,"msg":"the reasoning effort value is not supported
|
||
-- by the current model"}
|
||
-- 实测(2026-10-16,逐字对照实验):
|
||
-- glm-5.1 裸(无该字段) → 400 11150 ✗
|
||
-- glm-5.1 + reasoning_effort:medium → 200 ✓
|
||
-- glm-5.1 空串 → 400 11150 ✗
|
||
-- 任何**非空**档位均可(low/medium/high/xhigh/max/minimal 逐个 200)
|
||
-- 而其余 15 个 buddy 模型裸跑全 200(多带该字段也无害)—— 即这是
|
||
-- glm-5.1 **独有**的要求。
|
||
-- ⚠️ 只对**已实测需要**的模型补(而不是一律补):一律补会把"某个模型的
|
||
-- 特殊要求"扩成"全平台行为",将来上游若对某些模型收紧就会一次性弄坏
|
||
-- 所有模型。
|
||
if NEED_EFFORT[req.model or ""] and
|
||
not (type(req.reasoning_effort) == "string" and req.reasoning_effort ~= "") and
|
||
req.reasoning_effort == nil then
|
||
req.reasoning_effort = NEED_EFFORT[req.model]
|
||
end
|
||
if req.messages then
|
||
for _, msg in ipairs(req.messages) do
|
||
msg.reasoning_content = nil
|
||
if msg.tool_call_id ~= nil then
|
||
msg.tool_call_id = safe_tool_id(msg.tool_call_id)
|
||
end
|
||
if type(msg.tool_calls) == "table" then
|
||
for _, tc in ipairs(msg.tool_calls) do
|
||
if type(tc) == "table" and tc.id ~= nil then
|
||
tc.id = safe_tool_id(tc.id)
|
||
end
|
||
end
|
||
end
|
||
end
|
||
end
|
||
return json.encode(req)
|
||
end
|
||
|
||
function adapter.transform_response(raw_body)
|
||
-- 非流式 OpenAI 响应 → 统一信封。此前在 openai/groq/kimicode/mistral/github
|
||
-- 五个适配器里**逐字节相同**(各 2206B,diff 为空),已抽到共享前导。
|
||
return __prelude.openai_response(raw_body)
|
||
end
|
||
|
||
function adapter.transform_stream_chunk(raw_chunk)
|
||
local ok, chunk = pcall(json.decode, raw_chunk)
|
||
if not ok then return "" end
|
||
|
||
-- OpenAI-style streams may attach usage to a chunk with empty choices
|
||
-- (the final usage chunk). Keys must match Go's TokenUsage json tags
|
||
-- (prompt/completion/total); the gateway re-emits standard *_tokens.
|
||
local uses = nil
|
||
if type(chunk.usage) == "table" then
|
||
uses = {
|
||
prompt = chunk.usage.prompt_tokens or chunk.usage.prompt or 0,
|
||
completion = chunk.usage.completion_tokens or chunk.usage.completion or 0,
|
||
total = chunk.usage.total_tokens or chunk.usage.total or 0,
|
||
}
|
||
if type(chunk.usage.prompt_tokens_details) == "table" and chunk.usage.prompt_tokens_details.cached_tokens ~= nil then
|
||
uses.prompt_tokens_details = { cached_tokens = chunk.usage.prompt_tokens_details.cached_tokens }
|
||
elseif (chunk.usage.prompt_cache_hit_tokens or 0) > 0 then
|
||
uses.prompt_cache_hit_tokens = chunk.usage.prompt_cache_hit_tokens
|
||
uses.prompt_cache_miss_tokens = chunk.usage.prompt_cache_miss_tokens or 0
|
||
uses.prompt_tokens_details = { cached_tokens = chunk.usage.prompt_cache_hit_tokens }
|
||
end
|
||
end
|
||
|
||
if not chunk.choices or #chunk.choices == 0 then
|
||
if uses ~= nil then
|
||
-- usage-only chunk is not a content/finish signal; the gateway
|
||
-- emits its own terminal stop chunk and merges this usage.
|
||
return json.encode({ usage = uses, done = false })
|
||
end
|
||
return ""
|
||
end
|
||
local delta = chunk.choices[1].delta or {}
|
||
local fr = chunk.choices[1].finish_reason
|
||
|
||
local finish = (type(fr) == "string" and fr ~= "") and fr or nil
|
||
|
||
local unified = {
|
||
content = delta.content or "",
|
||
done = (finish ~= nil)
|
||
}
|
||
if finish then
|
||
unified.finish_reason = finish
|
||
end
|
||
if uses ~= nil then
|
||
unified.usage = uses
|
||
end
|
||
if delta.reasoning_content then
|
||
unified.reasoning_content = delta.reasoning_content
|
||
end
|
||
if delta.tool_calls then
|
||
-- Sanitize on the way OUT too: an id this upstream happily minted (it
|
||
-- does not validate them) becomes a landmine once the client replays
|
||
-- it to a Claude upstream. Only the first fragment of a streamed call
|
||
-- carries an id; later argument fragments have none and are untouched.
|
||
for _, tc in ipairs(delta.tool_calls) do
|
||
if type(tc) == "table" and tc.id ~= nil then
|
||
tc.id = safe_tool_id(tc.id)
|
||
end
|
||
end
|
||
unified.tool_calls = delta.tool_calls
|
||
end
|
||
return json.encode(unified)
|
||
end
|
||
|
||
-- 错误收敛:标准 OpenAI 信封 {error:{message,...}}
|
||
function adapter.transform_error(status, body)
|
||
-- OpenAI 风格错误体抽消息。此前在 deepseek/github/groq/kimicode/
|
||
-- openai/sensenova 六个适配器里逐字节相同(各 293B),已抽到共享前导。
|
||
return __prelude.openai_error(status, body)
|
||
end
|
||
|
||
|
||
-- ★ build_headers:buddy 要求客户端身份头 + 流式的 Accept。
|
||
--
|
||
-- 实测(2026-10-16):不发 `Accept: text/event-stream` 时上游接受请求(200)
|
||
-- 但只回一帧空内容(completion_tokens=0),既不报错也不产出正文 —— 表现是
|
||
-- "模型不回答",极易误判成模型坏了或额度不足。
|
||
-- 参考 buddy-adapter.ts 的 send() 固定发该头。
|
||
--
|
||
-- 身份头照参考 credentialRequestHeaders + CODEBUDDY 产品配置:
|
||
-- X-Domain 用产品域(不用凭据里的 domain 快照,那是登录时的区域,
|
||
-- 跨产品迁移后会指错区);X-Product 是**部署类型**(SaaS);X-Product-Code
|
||
-- 是产品码(codebuddy)。
|
||
function adapter.build_headers(meta)
|
||
local h = {
|
||
["Accept"] = "text/event-stream",
|
||
["Content-Type"] = "application/json",
|
||
["X-Domain"] = "copilot.tencent.com",
|
||
["X-Product"] = "SaaS",
|
||
["X-Product-Code"] = "codebuddy",
|
||
["User-Agent"] = "CodeBuddyIDE/1.106.1",
|
||
}
|
||
-- Authorization 由内核在 buildHeaders 之后补(值为源的 api_key)——
|
||
-- 这里显式给出同一份,保证与其它 buddy 请求形态一致。
|
||
if type(meta) == "table" and type(meta.api_key) == "string" and meta.api_key ~= "" then
|
||
h["Authorization"] = "Bearer " .. meta.api_key
|
||
end
|
||
return h
|
||
end
|
||
|
||
return adapter
|