[Bug]:v4f和v4.1f都会在延续的对话中stop

[riverai]

Version or commit

2026-09-15 07:59

Installation method

Other

Runtime environment

11

Steps to reproduce

上次其实就写过这个问题，但是修复了一定部分。但当时我也发现有后续。

就是在harness调用v4f ，第一次调用通常可以完整跑完整个工具循环，但是到了后来就不然，无法跑完整个循环，就会用stop停止。
现在的v4.1f也是这样。

但是呢，我发现了个神奇的现象，就是glm5.2永远可以顺利调用工具，不会碰到这种事情。

在上个月的修复之前，用v4f，也是第一次会正常调用，但是第二次，就会变成一问一答：用户说修复下，模型就说好的它会修复下，然后就没然后了。
当时修复之后，现在的情况比以前好，会变成“好的继续”，然后执行工具调用一小会儿，然后又会触发stop 。

我不知道这神奇的现象是什么原因，上次的修复好像是有效果的，但是没完全有效果。而且glm则一直都工作很好。

我怀疑难道是限流？难道是tpm超标了？

Expected behavior

1

Actual behavior

1 这是初次调用，可以完整跑完所有流程。

2 这是延续调用 会中途stop停止

Redacted logs

Confirmations

• I searched existing issues for the same problem.
• I removed all credentials, tokens, API keys, account data, request content, and personal information.

[riverai]

[wicm84266964]

之前遇到过openai的系统提示词会被workbuddy识别并拦截，拒绝返回回复，所以我们创建key的时候，选接入codex的key是要做提示词清洗的。还有之前有反映过的zcode也有类似系统提示词被workbuddy拦截的问题。由于我一直是在自己编写的智能体上使用，没有遇到类似问题，我会下载个dsh试一下是否能复现的。

[wicm84266964]

上次修的是「好的继续然后什么都不干」。你现在这个是延续对话里跑一会儿工具再 stop，而且 glm-5.2 一直正常，更像 v4 系列在长上下文里提前收工。

v2.1.9 又加了一层：流式工具循环如果 stop 且没调工具，会用 tool_choice=required 再打一次。我们自己用强制继续调工具的长会话把 prompt 堆到二十多万，没有复现你那种中途 stop，所以还不能说这个问题已经修好。

可以再试一下特别长的翻译续聊。Codex 提示词清洗和这次不是同一条。

[riverai]

更新之后我做了多个改变。

1: 首先完成了buddy2API更新。

这时候我立即进行了一轮翻译任务，用了三分多时间跑完了一轮。

这时候立即跑第二轮就能见证奇迹了，我可以知道到底是啥情况。

果然，其实还是会中途停止。

在运行第二轮14秒之后就自动停止了。

这时候，我又做了一些新的改变。

1 ： 我设置了一个限流器，专门将rpm限制到了10左右。
2 ： 我给模型都设置了思考强度。之前dsh给第三方模型都不会设置任何思考强度，完全依赖网关自带——网关自带思考就返回思考，网关不自带思考强度就没有思考返回。
这个我之前写过反馈，不过当时你的改进是注意透传，所以这次我用插件专门给第三方加了合适各自的思考强度。

我估计应该是限流器很有用。
现在已经连续又跑了三轮，都还没出现中途调用几次工具之后就stop的问题。

[wicm84266964]

更新之后第一轮能跑完、立刻第二轮 14 秒就 stop，说明 v2.1.9 那层停转重试没盖住你这个 case。那层只处理「这一跳 stop 且完全没调工具」；你这边是已经调了几次工具再停，网关会当成正常收工，不会再打 tool_choice=required。

后面连续三轮没再停，有参考价值，但现在还不能把功劳算给限流器：

1. RPM≈10 和思考强度是一起改的，分不开。思考开高以后每轮变慢，等效也是把请求打稀。
2. 这条链路是 WorkBuddy 的 v4f / v4.1f（和一直正常的 glm-5.2 同一家），不是 TraeWork。TraeWork 这边还没有 OpenAI 工具循环。
3. 同通道里只有 Flash 会停、GLM 不停，不太像整条 WorkBuddy 的并发墙。更像 Flash 又快、续聊里又爱自己 stop。DSH 确实能并行拉子代理，但 14 秒停掉、以及 RPM 压到 10 就好转，还不够证明已经打满上游频控。

网关日志里如果是 429，我们会当限流跟；如果是 200 + finish_reason=stop，那就还是模型自己收工，客户端限 RPM 只是把节奏打稀了。

方便的话再补这三样，我们才能判断要不要动网关：

1. 失败那 14 秒的 Buddy2api 请求日志：status、finish_reason、有没有 [tool stall]、是不是 429、prompt_tokens。
2. 拆开试：只开 RPM≈10，或只加思考强度，立刻第二轮还停不停。
3. 停下来时模型回了什么字，还是 DSH 界面自己标了 stop。

issue 先开着。v2.1.9 对「好的继续、什么工具都不调」仍然有用，你这个续聊中途停还没闭环。

[riverai]

更新之后第一轮能跑完、立刻第二轮 14 秒就 stop，说明 v2.1.9 那层停转重试没盖住你这个 case。那层只处理「这一跳 stop 且完全没调工具」；你这边是已经调了几次工具再停，网关会当成正常收工，不会再打 tool_choice=required。

后面连续三轮没再停，有参考价值，但现在还不能把功劳算给限流器：

1. RPM≈10 和思考强度是一起改的，分不开。思考开高以后每轮变慢，等效也是把请求打稀。
2. 这条链路是 WorkBuddy 的 v4f / v4.1f（和一直正常的 glm-5.2 同一家），不是 TraeWork。TraeWork 这边还没有 OpenAI 工具循环。
3. 同通道里只有 Flash 会停、GLM 不停，不太像整条 WorkBuddy 的并发墙。更像 Flash 又快、续聊里又爱自己 stop。DSH 确实能并行拉子代理，但 14 秒停掉、以及 RPM 压到 10 就好转，还不够证明已经打满上游频控。

网关日志里如果是 429，我们会当限流跟；如果是 200 + finish_reason=stop，那就还是模型自己收工，客户端限 RPM 只是把节奏打稀了。

方便的话再补这三样，我们才能判断要不要动网关：

1. 失败那 14 秒的 Buddy2api 请求日志：status、finish_reason、有没有 [tool stall]、是不是 429、prompt_tokens。
2. 拆开试：只开 RPM≈10，或只加思考强度，立刻第二轮还停不停。
3. 停下来时模型回了什么字，还是 DSH 界面自己标了 stop。

issue 先开着。v2.1.9 对「好的继续、什么工具都不调」仍然有用，你这个续聊中途停还没闭环。
无视

[riverai]

真的有速率限制，我连续运行了一整晚，直接达到了。
但是我没想到速率限制会直接报错然后提示。