[Bug] 反代给chatgpt使用得时候，遇到浏览器得操作就报错

[kuaile1993]

版本 / Version

3.9.6

部署方式 / Deployment

自建服务器 / Self-hosted

问题描述 / What happened?

复现步骤 / Steps to reproduce

subapi 反代 windsurfapi

然后本地使用codex

大模型使用GLM-5-2-NONCE

每次要使用工具得时候，都停掉了，不继续执行 （已搜索网页 ：github dwgx WindsurfAPI repository）

客户端和版本 / Client and version

No response

请求路径 / API route

None

工具信息 / Tool information

No response

日志 / Logs

模型 / Model

glm-5-2-none

环境 / Environment

No response

[dwgx]

尽然你都用GLM了 为什么不考虑别的工具 OpenCode什么的呢 claudecode也行吧

[wangergou777]

GLM好像不支持调用工具吧。。。我也想调用出来，之前我用cascade那套就不行，但是devin这套还没试

[dwgx]

查了一轮,有结论 —— 而且和上面两条猜测都不一样,记在这里。

不是"GLM 不支持工具调用"

@wangergou777 那个猜测我实测了,不成立。glm-5-2-none 走的是提示词模拟(connect
路径没有原生 function-calling 槽位),而模拟本身对 GLM 是通的:

A  模型输出纯文本声明意图、不发 markup  -> finish=stop        tool_calls=0   ← 停滞
B  模型输出带 markup                    -> finish=tool_calls  tool_calls=1   ← 正常

B 说明整条链路(注入工具描述 → 模型输出 markup → 解析回 tool_calls)是工作的。
坏的是 A:模型说它要用工具,但没按约定格式发出来,于是代理只能返回
finish=stop + 零 tool_calls,客户端读成"模型选择用文字回答",循环就停在那儿。

也不是 selector 没登记

我原本怀疑 glm-5-2-none 不在 SELECTOR_MAP 里(它确实不在),但实测所有变体都
能解析:

glm-5-2-none / glm-5.2-none / glm-5-2-max / glm-5-2-1m / glm-5-2-none-1m  → 全部 mapped=true

走的是归一化后的目录存在性检查,不需要补别名。这条我自己的怀疑推翻了。

与 #237 是同一族,但当前的修复覆盖不到

刚随 v3.9.7 合并的 #238 修的是同一个失效家族:模型声明了工具意图却不发出调用。
但它的触发条件是 reasoning-only(推理通道有内容、文本通道没有),而你这个是
模型在文本通道里说的 —— 条件不匹配,rescue 不触发。

所以要不要把 A 这一支也救,是个明确的待定项。它的修法方向和 #238 一样(检测到
"有 tools、finish=stop、零 tool_calls、而文本里像是在描述工具意图"就追加纠正指令
重试),但我不想在没有真实复现的情况下就上 —— 判据比 #238 那条模糊得多,容易把
"模型真的只想用文字回答"误判成失败。

需要你配合一下

你的复现路径是 codex + subapi 反代,而我们这边把验收基准定在 OpenCode。方便的话
用 OpenCode 直连(不经反代)跑一次同样的任务,告诉我:

1. 是 A(模型回了一段文字,内容像是在说它要做什么)还是干脆空回复
2. 服务端日志里有没有 ToolRoute[...] 那行,effective= 后面是几个工具

如果是空回复,那 v3.9.7 可能已经修好了(#238 的 rescue + reasoning 提升),先升级
再看。如果是 A,把那段文字贴出来 —— 我需要看模型到底输出了什么形态,才能定一个不会
误判的判据。

顺带一句:GLM-5.2 目前免费是动态促销(见 #235),而我们代码里的 credit 是硬编码
常量。那条已经在修,会连同 #234 一起处理 —— 上游其实一直在给逐模型费率表,解码器
也早就写好了,只是没人接。

[warelik]

实测三轮, same setup family as #238/#237 — tried hard to reproduce form A on a live instance (glm-5-2-none, free pool, direct connection, no intermediary):

• Round 1 — single-turn direct tool tasks (read_file/bash, 4 prompt shapes ×4): 16/16 clean tool calls (form B).
• Round 2 — multi-turn agent loops (4 tools, synthetic tool results fed back, 6 sessions × up to 8 turns): 13 tool-call turns + 6 legitimate final text answers, 0 form A.
• Round 3 — codex-shaped environment (~1.5KB agentic system prompt, 11 tools, plan-heavy tasks, temperature 0.7): all working turns clean tool calls again. 60+ turns total, 0 form A.

结论: through this proxy alone GLM-5.2 emits tool markup reliably — 和你测的 B 形态一致. The reporter's path had subapi between client and windsurfapi; since form A never appeared in any direct trap, the likely trigger sits in the intermediary hop (prompt/tool-def mangling, history rewrite, stop-sequence handling) — not the model, not this proxy's emulation. 需要的话 can re-run the same trap set against a subapi-style intermediary config, but we'd need to know what subapi actually rewrites.

不建议 now shipping an A-rescue on this evidence: 判据比 #238 模糊得多 — without a real capture of an A-text, the false-positive risk ("model legitimately answering in prose") is unquantified. Probe harness (prompts + classifiers) is reusable the moment a real A-capture shows up.

[dwgx]

标题说的和正文说的不是一回事，正文这个我能查

先把问题重述一遍，因为标题（「遇到浏览器操作就报错」）会把人带偏：

subapi 反代 windsurfapi → 本地用 codex → 模型 glm-5-2-none → 每次要用工具的时候
就停住不往下走（截图里是"已搜索网页"之后卡住）

所以这不是"浏览器操作报错"，是工具调用停滞：模型表示要用工具，而 tool call 没真的发出来，
客户端就一直等。这和 #237 / #238（swe-1-7 整轮停在 reasoning 里声明工具意图但不发出调用）
是同一族的症状，只是模型不同。

我已经查掉的部分

1. 模型名解析正常。 glm-5-2-none → selector glm-5-2-none，映射成功，不走静默降级。

2. 工具方言对你这个名字是正确的。 GLM-5.2 必须用 gpt_native（function_call JSON），
因为 v2.0.72 的探测发现它会忽略 glm47 那套 XML markup、改用纯文本回答 —— 而纯文本回答
就意味着不发 tool call，客户端一直等，正是你看到的现象。你的 glm-5-2-none 命中了正确分支。

3. 但我在旁边发现了一个真缺陷，已修。 裸写 glm-5-2（不带后缀、用破折号）三条匹配条件
全不中，会落到 glm47 —— 也就是错的方言，症状和你报的一模一样。glm-5.2、
glm-5-2-none 等其它写法都对，所以它一直藏着。修了，随下个版本发。

如果你除了 glm-5-2-none 还试过裸的 glm-5-2，那一次的卡住就是这个缺陷。

需要你提供的，按能区分的顺序

你这个名字走的是正确方言，所以剩下的候选机制需要数据才能分开。按信息量排序：

① 代理日志里 tool call 的原始形态（这一条最关键）

在 windsurfapi 上开 debug 日志，跑一次卡住的请求，然后贴出模型返回的原始文本（token 已
自动脱敏，但贴之前请自己再确认一遍不要带 session token）：

LOG_LEVEL=debug

要看的是：模型到底吐了什么。三种结果指向三个不同的缺陷：

你看到的	说明	归属
有 function_call JSON，但客户端没收到 tool_calls	解析或流式转译丢了它	代理的缺陷，我能修
只有纯文本描述"我要搜索网页"，没有任何 markup	模型没按 gpt_native 格式发	需要给 GLM 加一层救援（同 #238 的做法）
有 markup 但格式和 gpt_native 不同	方言判断错 / 上游换了格式	方言表要改

② 直连一次，绕开 subapi

同一个请求，不经过 subapi、直接打 windsurfapi：

curl -N http://127.0.0.1:3003/v1/chat/completions \
  -H 'Authorization: Bearer <你的 API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"model":"glm-5-2-none","stream":true,
       "messages":[{"role":"user","content":"搜索一下 github dwgx WindsurfAPI 这个仓库"}],
       "tools":[{"type":"function","function":{"name":"web_search",
                 "parameters":{"type":"object","properties":{"q":{"type":"string"}},"required":["q"]}}}]}'

直连不卡 = 问题在 subapi 那一层（SSE 缓冲、或者它对 tool_calls 增量的处理），那我这边改不了
但可以告诉你查什么。直连也卡 = 在代理或模型侧，配合 ① 就能定位。

③ 换个模型对照一次

同样的 codex 请求换成 swe-1-6-slow（免费、任何账号都能调）或 claude-4.5-sonnet。只有 GLM
卡 = 模型侧行为（那 #238 那套"纠正性 nudge"救援大概能覆盖，只是当前的触发条件是
sawReasoning && !sawText，而 -none 意味着 reasoning effort 为 none，很可能压根没有
reasoning 可言 —— 那条判据对你这个 case 结构上就不成立）。全都卡 = codex 接线问题，与模型
无关。

④ 顺带一问：你写的 GLM-5-2-NONCE 是笔误还是真的这么填的？NONCE 那个拼法解析不到任何
selector，会被当未知模型名处理（默认 400，WINDSURFAPI_STRICT_MODEL=0 时静默降级到免费
selector —— 后者会让你以为在用 GLM 而实际跑的是 swe-1-6-slow，那也会让工具行为变得莫名其妙）。

为什么不先猜着改

我可以从代码倒推出四五个可能的机制，但那会变成一份猜测清单：这个仓库有过按错误归因改代码、
后来发现改的不是那个地方的记录，成本比多问一轮高得多。上面这四项每一项都能排除掉至少一个
候选，所以拿到 ① 和 ② 我基本就能定位了。

bug 标签保留，先不关。谢谢你附了截图和复现路径 —— 「每次要用工具的时候都停掉」这句话比标题
准确得多，我是照它查的。