[Question] zocde调用子智能体的时候，子智能体有概率出错，导致子智能体停止工作

[zzzzzzzzzzzzzzzzzzzzzzzzzzy]

具体的报错：
[acp-proxy: upstream stream truncated (no completion event; round 1, 0 text chars + 90789 reasoning chars received)]
只修改了下面的设置
"modelContextLimit": 300000

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

先说结论：这条报错本身不是 bili 的 bug，而是上游模型在生成中途断流（没有发完成事件）；而它与 modelContextLimit: 300000 的强相关指向一个高概率根因——这个值超过了模型的真实上下文窗口。下面是完整分析。

报错含义

upstream stream truncated (no completion event; round 1, 0 text chars + 90789 reasoning chars received) 出自 src/loop/core.ts:606：上游 SSE 流在没有 finish/[DONE] 的情况下结束了。当时 bili 已收到约 9 万字符的思考内容（约两三万 thinking token）、0 字符正文。这种情况下 bili 无法重试（#413 的重试只在"客户端尚未收到任何内容"时生效），只能向流内注入错误并结束本轮 → 子智能体收到一个断裂的半截回合，于是停止工作。

为什么改 modelContextLimit 会引发它

1. 该配置是使用率计算的分母（usage = tokens / modelContextLimit），决定何时触发压缩；它不是截断上限。
2. 它让 bili"相信"窗口是 300k：放在 compress 块里（全局/provider/模型任一层）时优先级最高，直接覆盖 models.dev/内置表自动探测到的原生窗口（src/server.ts:1144、src/compress-settings.ts:261）；放在顶层时则是自动探测失败时的默认值。
3. 相信的窗口高于真实窗口 → 压缩触发点整体后移 → 请求输入长过真实上限。不少后端对超大 prompt 不返回 400，而是接受并开始生成、等 KV/总 token 超出真实容量时生成中途死掉（正是 高 usage 下的非 400 失败（流截断/超时）无任何 overflow 兜底 —— 会话直接死 #498 记录的 weak-overflow 特征）。只有输入越过真实窗口的请求才会死，小请求照常成功——所以表现为"有概率出错"。
4. 为什么子智能体尤其明显：子智能体会话从零快速膨胀（任务描述 + 大量文件读取/工具输出），更容易越线；另外如果 ZCode 的子智能体用的是另一个（窗口更小的）模型，全局的 modelContextLimit 同样会套在它头上。

为什么 bili 的自愈没有救回来（分析中发现的设计缺口）

bili 有 weak-overflow 自愈机制（#498/#570）：15 分钟内出现 3 次"高使用率 + 断流"后，把失败时的输入规模学成保守窗口并触发紧急压缩。但它的"高使用率"门槛要求失败输入 ≥ 相信窗口的 90%（src/weak-overflow.ts:45、:139）。你把窗口设成 300k、真实窗口若只有 200k，那么 ~210k 输入的失败请求相对 300k 只有 ~70% 使用率 → 永远不算高使用率 → 自愈永不触发 → 会话持续卡在断流循环里不自愈。即：把窗口设得比真实值大，恰好在这个最需要安全网的场景把安全网关掉了。 此缺口记录在本帖；是否修复（例如把"高使用率"基准从"相信的窗口"改为"近期成功回合的最大输入"）由你拍板。

请帮忙确认（日志取证）

日志文件 ~/.local/state/billion-context/bili.log，找这几行：

• [window] model=... source=... effective=... —— bili 实际采用的每个模型的窗口（每模型记一次）；
• 报错前的 [acp-usage] round N input=X cached=Y —— 把 X 和该模型的真实窗口对比；
• 有没有出现过 weak overflow signal ...（按上面的推断应该没有）；
• 另外请告知：主智能体和子智能体分别用的什么模型？

建议处理

1. 删掉或回退 modelContextLimit: 300000，让 bili 从 models.dev/内置表自动探测原生窗口（默认行为）。
2. 如果想低于原生窗口留余量，用百分比字符串，如 "modelContextLimit": "80%"（= 原生窗口的 80%）——避免硬编码超过真实值的绝对数。
3. 主/子智能体若用不同模型、窗口不同，按模型分别声明：providers.<url>.models.<model>.context（原生窗口声明）或按模型 compress.modelContextLimit。
4. 如果你的模型确实有 ≥300k 窗口（请以服务商文档为准核实），以上解释不成立，需要按上面日志行再查另一条线（备选假设：网关对超长单次生成断连——9 万字符纯思考确实很长）。但既然报错与这次改配置时间强相关，前三项是第一嫌疑。

审核结论：代码路径已逐一核验（错误产生点 core.ts:603-609、重试条件 core.ts:334-341、高使用率门槛 weak-overflow.ts:45/139、operator 配置优先级 server.ts:1144）。你描述的是表面现象（子智能体停止工作），根因层是"配置窗口 > 真实窗口 → 超大请求被上游中途杀死"，且自愈门槛在高估窗口下失效使其变成持续性问题；建议方案（回退/自动探测/百分比/按模型声明）针对根因，可以先按第 1 条验证。

[ranxianglei]

有没有可能是bili退出了导致的 就是死了

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

基本可以排除"bili 死了"，而且这条报错本身就是证据：

1. 这段文字是 bili 活着时自己生成并写进响应流的。 [acp-proxy: upstream stream truncated (...)] 这个字符串由 src/loop/core.ts:606 拼装、经 src/loop/adapter-openai.ts:469 以 \n[acp-proxy: ${message}]\n 的形式注入到返回给客户端的流里。如果 bili 进程当时已退出，客户端看到的会是裸的连接断开（ECONNRESET / 空流 / 下一轮 connection refused），而不可能收到这样一条结构完整的、bili 内部格式的错误文本。能发出这句话，说明那一刻 bili 正在正常运行、正在读上游流，并观察到上游（模型服务商）那边的流在没有完成事件的情况下结束了——死的是上游连接，不是 bili。

2. 日志可以直接验证。 在 ~/.local/state/billion-context/bili.log 里搜 upstream stream truncated：

   • 该行存在且前后仍是正常的请求处理行 → bili 全程没死；
   • 如果是 bili 崩溃/退出，日志会在那一行之前或之后出现未捕获异常/stack trace/OOM 痕迹，或者出现一段空白后重新打印启动横幅（acp-proxy listening on ...）；
   • 顺带看同一时刻有没有 weak overflow signal 行（按前面的推断应该没有）。

3. 相关性也对不上。 如果是 bili 随机崩掉，报错应该和请求内容无关、各会话均匀出现；而现在的现象与 modelContextLimit: 300000 强相关、只在上下文长大的子智能体会话里出现，这符合"输入越过真实窗口 → 上游中途断流"的解释，不符合进程崩溃的特征。

所以建议还是先按上一条回复的第 1 条做验证：回退/删掉 modelContextLimit: 300000 跑一段时间看是否还复现；同时在日志里确认上面第 2 点的连续性。如果你翻日志时真的发现了崩溃痕迹（异常栈、重启横幅），把那段贴出来，我再往进程方向查。

[zzzzzzzzzzzzzzzzzzzzzzzzzzy]

主智能体用的是deepseek v4.1 flash，子智能体用的是glm 5.3 flash

2026-09-16T14:20:54.767Z [info] [51855500-e4ea-4eb0-8ff4-283042078227] [acp-usage] round 1 input=41535 cached=40448 (cache hit 97%)
2026-09-16T14:20:55.809Z [info] [51855500-e4ea-4eb0-8ff4-283042078227] processTurn: 43 msgs, renderTags=text-only, 11 text tagged, 0 tool tagged (should be 0 with text-only)
2026-09-16T14:20:55.809Z [info] [51855500-e4ea-4eb0-8ff4-283042078227] nudge idle: usage=18% (41535/235000), growth=30121/22500 (ref=11414, interval=50000), pendingT1=28264/50000 model=z-ai/glm-5.3-flash, reason="max compressible 28264 < threshold 50000"
2026-09-16T14:20:55.811Z [info] forward POST → https:///v1/chat/completions
2026-09-16T14:21:02.692Z [info] [update] running from a source checkout (F:\my_prj\fpag_av1\bili-src) — skipping auto-update (use npm install -g billion-context)
2026-09-16T14:23:43.293Z [info] [5c005d94-2e56-4719-8726-01bfe3bebe7d] [acp-loop] round 1: upstream stream truncated (no completion event; round 1, 0 text chars + 90789 reasoning chars received)
2026-09-16T14:23:43.987Z [info] [51855500-e4ea-4eb0-8ff4-283042078227] [acp-loop] round 1: upstream stream truncated (no completion event; round 1, 0 text chars + 25071 reasoning chars received)
2026-09-16T14:23:45.670Z [info] [9495a862-796c-426f-a153-015afcf7d786] processTurn: 101 msgs, renderTags=text-only, 23 text tagged, 0 tool tagged (should be 0 with text-only)
2026-09-16T14:23:45.670Z [info] [9495a862-796c-426f-a153-015afcf7d786] nudge INJECT T1: usage=46% (108519/235000), growth=37292/22500 (ref=71227, interval=50000), pendingT1=73044/50000 model=deepseek/deepseek-v4.1-flash:free, reason="T1 effective 73044 >= 50000, growth 37292, usage 46%"
2026-09-16T14:23:45.677Z [info] forward POST → https:///v1/chat/completions
2026-09-16T14:24:02.701Z [info] [update] running from a source checkout (F:\my_prj\fpag_av1\bili-src) — skipping auto-update (use npm install -g billion-context)
2026-09-16T14:24:14.225Z [info] [9495a862-796c-426f-a153-015afcf7d786] [acp-usage] round 1 input=29502 cached=20636 (cache hit 70%)
2026-09-16T14:24:14.227Z [info] [9495a862-796c-426f-a153-015afcf7d786] [acp-proxy: compress requested 2 range(s): m01068–m01155, m01157–m01157]
2026-09-16T14:24:14.227Z [info] [9495a862-796c-426f-a153-015afcf7d786] [acp-proxy: ctx has 101 message(s), state has ? ref(s) mapped]
2026-09-16T14:24:14.227Z [info] [9495a862-796c-426f-a153-015afcf7d786] [acp-proxy: first msg ids: acp_summary_b9(10082c), h_decc262b8194a9b0(6609c), h_769071046632508f(2722c), h_beb64b19f5ca2323(197c), h_ddb423114564a27c(113c), h_45d67cf51bef51f9(113c), h_80d205b4be357676(1175c), h_a5aaee44a26c27be(736c), h_0b52927fc50e5d70(5751c), h_e370af28a7a744d5(190c)]

[zzzzzzzzzzzzzzzzzzzzzzzzzzy]

另外，我让ai看了一下，它把 core.ts:362 的重试条件从 !forwardedAny 放宽到「只转发了 reasoning、没有可见文本和 tool call」的情况——这正是 core.ts:393 那个 #732 degenerate-turn 重试已经承认的「reasoning 对宿主不可见」的事实。既然 reasoning 转发被认为是安全的（#821 的注释明确说了），那 !forwardedAny 就不该把 reasoning 计入「副作用」；会不会导致其它的问题；

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

先说结论：这个放宽方向是对的，而且和已合并的 PR #822（9/16，#821）对 #732 degenerate-turn 重试做的改动完全同类——当时 #413 截断重试保持严格 !forwardedAny 是出于保守，不是原则。前提在截断场景同样成立，甚至更干净。但有几个具体边界要处理，列在下面。

为什么是安全的（机制层面）

• fix: make degenerate-turn auto-retry reachable on openai/anthropic wires (#821) #822 的前提已经立住："thinking 前缀对宿主 turn 语义不可见，且转发的 chunk 不带 finish_reason，往同一条流里追加内容是安全的"（现 master src/loop/core.ts 的 workbuddy报错Empty stream: upstream gateway sent only placeholder chunks without any model output (chunks=0, bytes=0) #821 注释原文）。截断场景比 [BUG] In some cases, with Codex's auto model + DeepSeek, it will suddenly terminate automatically. #732 更彻底：完成事件根本没到过，客户端必然没看到任何终止信号。
• 机制现成：fix: make degenerate-turn auto-retry reachable on openai/anthropic wires (#821) #822 之后 fwd(chunk, visible) + forwardedVisible 标志已存在，启动横幅硬编码 raw-HTTP-capture(on) 而真开关是 ACP_DUMP_BODY(默认关):日志永远撒谎,取证被带偏过 #413 的门只需把 !forwardedAny 换成 !forwardedVisible（保留 calls.length === 0——tool call 是缓冲到轮末才下发的，这个条件已覆盖工具可见性）。meta 块和原始 reasoning 字节就不会再误挡重试；textProtocol 路径本来就不转发 reasoning，行为不变。
• 重试仍应原样重取 roundBody（不要加 nudge——nudge 是给 [BUG] In some cases, with Codex's auto model + DeepSeek, it will suddenly terminate automatically. #732"已完成但零可见输出"用的；截断应该重做被打断的那次生成，原 body 也保住缓存前缀）。

可能带来的副作用（回答"会不会导致其它的问题"）

1. 确定性失败的代价翻倍 —— 最主要的真实成本。如果断流是因为输入越过真实窗口（本帖前面定位的根因），重试会重发同样的超大请求，大概率再跑一整段思考后再次死掉（~2× token + 延迟才最终报错）。有 one-shot 标志兜底、不会循环；也不影响 weak-overflow 计数（noteWeakOverflow 每请求只在最终放弃时调用一次，core.ts:595-601）。
2. 重试间隙的流静默：第一次尝试结束到第二次首个字节之间是 prefill 静默（大上下文可达分钟级）。多数宿主把静默当"还在生成"；若某宿主有自己的响应 idle 超时并断开，signal.aborted 已有守卫会停掉流程。与 [BUG] In some cases, with Codex's auto model + DeepSeek, it will suddenly terminate automatically. #732 重试间隙同性质。
3. 重试链：两个 one-shot 标志相互独立，理论上单请求最多 3 次 fetch（截断重试 → 第二次响应恰好又是纯思考 completed 轮 → [BUG] In some cases, with Codex's auto model + DeepSeek, it will suddenly terminate automatically. #732 重试，或反过来）。这个上界今天就已存在，放宽只是新增一条能到达它的形态，不会无界。建议补一个链式场景测试把这个上界锁住。
4. Anthropic 签名 thinking 边界：若第一次尝试死在 think 块中间，那段部分 thinking 没有 signature，严格宿主下一轮回传不完整的 thinking 可能被上游 400。注意该风险今天就存在（不管重不重试，不完整 reasoning 都已经到了客户端手里），此改动不使其变差，值得知晓即可。
5. 它不解决 [Question] zocde调用子智能体的时候，子智能体有概率出错，导致子智能体停止工作 #862 的根因：窗口设过大的场景下重试大概率再失败，回退配置（让 bili 自动探测原生窗口）仍是正解；此改动针对的是瞬时网络/网关抖动——正是 启动横幅硬编码 raw-HTTP-capture(on) 而真开关是 ACP_DUMP_BODY(默认关):日志永远撒谎,取证被带偏过 #413 的原始目标。

实现建议（如果你拍板做）

• src/loop/core.ts 的 启动横幅硬编码 raw-HTTP-capture(on) 而真开关是 ACP_DUMP_BODY(默认关):日志永远撒谎,取证被带偏过 #413 门：!forwardedAny → !forwardedVisible，同步更新注释（说明 reasoning/meta 转发不再视为副作用，引用 workbuddy报错Empty stream: upstream gateway sent only placeholder chunks without any model output (chunks=0, bytes=0) #821 的既有论证）；
• 补测试：OpenAI wire round-1 纯 reasoning 截断 → 恰好重试一次、内容追加进同一条流且顺序正确；已转发可见文本的截断 → 不重试；链式场景锁定 ≤3 次尝试；
• 基于当前 master（forwardedVisible 已在），diff 收敛在 core.ts + 一个测试文件。

这是一条来自外部用户的改动提议，按流程是否实施由你拍板；确认后我直接提 PR。

[zzzzzzzzzzzzzzzzzzzzzzzzzzy]

在去掉"modelContextLimit": 300000的配置，加上我的ai的修改，让子智能体完成同一个任务，重复4次，也没有出现类似的问题了

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

好，4/4 通过，和前面的定位对上了：去掉 modelContextLimit: 300000 后 bili 恢复自动探测原生窗口（你日志里 glm-5.3-flash 解析到 235k），压缩触发点回到真实窗口之内，请求不再越过上游容量，断流自然消失——根因闭环。

两点收尾建议：

1. 你的本地改动目前只存在于你的 source checkout（日志显示 running from a source checkout）。如果想让它进正式发布、惠及所有遇到"reasoning-only 断流"的用户，我可以按上一轮列的方案提一个正式 PR：启动横幅硬编码 raw-HTTP-capture(on) 而真开关是 ACP_DUMP_BODY(默认关):日志永远撒谎,取证被带偏过 #413 门 !forwardedAny → !forwardedVisible + 注释更新 + 三个单测（纯 reasoning 截断恰好重试一次 / 已转发可见文本不重试 / 链式 ≤3 次上界），diff 收敛在 core.ts + 一个测试文件，跑完 typecheck/test/build 预检。你点头我就开工；不想做也没关系，配置回退本身已经解决你的问题。
2. 一个小验证（可选）：如果这 4 次里其实发生过瞬时断流但被你的重试救回来了，日志里会有 [acp-loop] round N: upstream truncated before any content reached the client; retrying fetch once 之类的行——grep 一下能确认新路径确实生效过还是压根没再断流。不影响结论，只是把两个变量的贡献分开。

另外把之前发现的设计缺口再挂一下账（供你决定是否处理）：weak-overflow 自愈的"高使用率"门槛相对相信的窗口计算（src/weak-overflow.ts:45,139），一旦有人把窗口配置得比真实值大，该安全网恰好失效——本次事件就是活例。候选方向是把基准换成"近期成功回合的最大输入"。要修的话另开 issue/PR 走流程。

[ranxianglei]

这个是估算窗口错误导致的吗?

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

不是——你贴的日志恰好推翻了"窗口估算/配置过大"这个解释，我需要修正第一轮的分析。

日志里的三个反证

1. glm-5.3-flash 的窗口解析是对的。 你设置里还有 modelContextLimit: 300000 时，日志分母是 235000（usage=18% (41535/235000) ... model=z-ai/glm-5.3-flash）。说明自动探测对这个模型生效了（235k 是它的原生窗口），那个 300000 并没有套在 glm 头上——它要么在顶层（只是探测失败时的兜底，glm 有原生值所以用不上），要么……如果是放在 compress 块里，分母应该显示 ~300000（减去 maxOutput 后不会是这么整的 235000）。
2. 失败请求离溢出差得远。 被截断的 glm 会话输入只有 41535 token = 窗口的 18%。溢出类断流要求输入贴着或越过真实窗口，18% 直接排除。
3. 两个会话在 0.7 秒内先后断流（14:23:43.293 和 14:23:43.987）——这是典型的共享上游侧事件特征（网关/风控/服务商侧波动同时掐掉多条并发流），而不是与每个请求自身大小相关的行为。

另外两个受害回合形状一致：100% reasoning、0 可见文本、跑了约 3 分钟（POST 14:20:55 → 断流 14:23:43）。glm 那条是纯思考跑了近三分钟被掐。

修正后的判断

当前证据指向上游侧对"长纯思考流"的切断（风控启发式、含 thinking 的生成时长/token 预算、或部署波动），而不是 bili 的窗口估算错误。我第一轮基于"只改了这一个配置就出事"做的溢出推断，被这份日志否定了——抱歉绕了一步。

至于"去掉配置 + 加重试后 4/4 通过"：两个变量同时变了，n=4 不足以归因。其中重试放宽是直接对症的（一次性抖动被第二次尝试救回，客户端看到完整回合）；而去掉 300000 只对"没有原生窗口条目"的模型有影响（比如 deepseek-v4.1-flash:free 若不在注册表里）——如果断流的都是 glm 子智能体会话，去掉配置可能根本没起作用。

要把归因钉死，还差这几行日志

1. [window] model=... source=... effective=...（每模型一行）→ 确认 300000 到底作用在哪个模型上；
2. 会话 5c005d94（90789 chars 那条）的 [acp-usage]/nudge 行 → 它的模型和输入规模；
3. 去掉配置之后多跑一些次，看是否还会偶发同样的截断（如果还会，就坐实上游侧原因，与配置无关）；
4. 4 次成功运行的日志里 grep retrying fetch once → 若有，证明重试路径确实救过场。

你的重试修改对这一类问题（长纯思考流被上游掐断）正是正确的代理层缓解手段；它救不回来的是确定性失败（如真溢出），但本案已排除后者。

[ranxianglei]

为什么 @zzzzzzzzzzzzzzzzzzzzzzzzzzy 说,以下修复就正常了 如何解释

另外，我让ai看了一下，它把 core.ts:362 的重试条件从 !forwardedAny 放宽到「只转发了 reasoning、没有可见文本和 tool call」的情况——这正是 core.ts:393 那个 https://github.com/ranxianglei/billion-context/issues/732 degenerate-turn 重试已经承认的「reasoning 对宿主不可见」的事实。既然 reasoning 转发被认为是安全的（https://github.com/ranxianglei/billion-context/issues/821 的注释明确说了），那 !forwardedAny 就不该把 reasoning 计入「副作用」；会不会导致其它的问题；

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

一句话解释：这个修复不是让上游停止断流，而是把"断流 = 子智能体死亡"变成了"断流 = 自动重取一次，第二次成功则客户端看到完整回合"。上游侧的切断事件大概率还在发生，只是从"每次可见的失败"变成了"被静默救回的事件"。

机制对照

• 改之前：他的失败形态恰好是旧门控永远救不了的那一类。round 1 的 reasoning 是原样透传的（src/loop/core.ts:298-304，ev.raw 无条件 fwd()），所以纯思考流一旦断掉，forwardedAny 必为 true → 启动横幅硬编码 raw-HTTP-capture(on) 而真开关是 ACP_DUMP_BODY(默认关):日志永远撒谎,取证被带偏过 #413 重试被挡 → 只能向流内注入错误、回合结束 → 子智能体停摆。也就是说：上游每抖一次（哪怕频率很低），用户就看到一次子智能体死亡——这就是"有概率出错"的来源。
• 改之后：同样的断流事件触发一次性重取原请求。若断流是瞬时的（日志证据指向这一类：共享上游侧事件、非溢出），第二次尝试成功，客户端在同一条 SSE 流里收到 [部分 thinking A][thinking B+正文][完成]，回合完整，子智能体无感继续。可见失败概率从 P(断流) 降为 P(断流) × P(第二次也断)，对瞬时抖动后者很小。
• 边界：它只救瞬时失败。确定性失败（比如真溢出）两次都会死，照样报错浮出——所以这个改动不会掩盖真问题，这也和本案"已排除溢出"的结论自洽。

如何验证这个解释（决定性实验）

在他那 4 次成功运行的日志里 grep 重试行（原文措辞是 retrying fetch once，若他 AI 改了日志文案就按新文案搜）：

• 搜到了 → 机制坐实：这 4 次里其实发生过断流，只是被新路径静默救回；去掉配置那条变量基本可以排除。
• 没搜到 → 说明 4 次运行里压根没再发生断流（时间上运气好），此时无法排除去掉配置也有贡献——需要补 [window] model=... source=... effective=... 行确认 300000 当时到底作用在哪个模型上（若断流会话全是 glm 且窗口一直是 235k，那去配置就是无关变量）。

n=4 本身不足以做统计归因，上面这一步能把两个变量的贡献分开。如果方便让他把那 4 次的日志段发上来，我可以直接替他查。

[zzzzzzzzzzzzzzzzzzzzzzzzzzy]

重启zcode之后，还是出现了类似的问题，下面是问题前后的日志；不过都是glm 5.3 flash在最高思考程度下出的，不知道跟模型有没有关系

2026-09-16T15:39:06.799Z [info] forward POST → https:///v1/chat/completions
2026-09-16T15:39:07.747Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] [acp-usage] round 1 input=59452 cached=58112 (cache hit 98%)
2026-09-16T15:39:08.013Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] processTurn: 97 msgs, renderTags=text-only, 17 text tagged, 0 tool tagged (should be 0 with text-only)
2026-09-16T15:39:08.013Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] nudge idle: usage=6% (59452/935000), growth=28365/22500 (ref=31087, interval=50000), pendingT1=35158/50000 model=z-ai/glm-5.3-flash, reason="max compressible 35158 < threshold 50000"
2026-09-16T15:39:08.013Z [warn] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] reasoning-pair-violated: 5 assistant tool-call message(s) lack reasoning_content while 19 carry it — strict-echo upstreams (DeepSeek thinking mode) will reject the request (#684)
2026-09-16T15:39:08.016Z [info] forward POST → https:///v1/chat/completions
2026-09-16T15:39:11.178Z [info] [9495a862-796c-426f-a153-015afcf7d786] [acp-loop] round 1: upstream stream truncated (no completion event; round 1, 0 text chars + 14307 reasoning chars received)
2026-09-16T15:39:14.379Z [warn] [tag-echo] stripped model-emitted render tag:
2026-09-16T15:39:14.380Z [info] [c163be61-d208-4994-9a4c-b5eba7b798e3] [acp-usage] round 1 input=44588 cached=43200 (cache hit 97%)
2026-09-16T15:39:14.652Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] [acp-usage] round 1 input=60676 cached=59392 (cache hit 98%)
2026-09-16T15:39:16.049Z [info] [c163be61-d208-4994-9a4c-b5eba7b798e3] processTurn: 67 msgs, renderTags=text-only, 16 text tagged, 0 tool tagged (should be 0 with text-only)
2026-09-16T15:39:16.050Z [info] [c163be61-d208-4994-9a4c-b5eba7b798e3] nudge idle: usage=5% (44588/935000), growth=11988/22500 (ref=32600, interval=50000), pendingT1=21643/50000 model=z-ai/glm-5.3-flash, reason="max compressible 21643 < threshold 50000; growth 11988 < floor 22500"
2026-09-16T15:39:16.050Z [warn] [c163be61-d208-4994-9a4c-b5eba7b798e3] reasoning-pair-violated: 2 assistant tool-call message(s) lack reasoning_content while 13 carry it — strict-echo upstreams (DeepSeek thinking mode) will reject the request (#684)
2026-09-16T15:39:16.054Z [info] forward POST → https:///v1/chat/completions
2026-09-16T15:39:16.239Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] processTurn: 99 msgs, renderTags=text-only, 17 text tagged, 0 tool tagged (should be 0 with text-only)

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

这份新日志信息量很大，先说三个直接结论：

1. 窗口因素可以彻底出局了

• 这次 glm-5.3-flash 的窗口自动解析成了 935000（之前那份日志里是 235000——应该是注册表异步命中替换了低置信度兜底值），而失败前后各会话的使用率只有 5%~6%（44588/935000、59452/935000）。就算按 235k 算也只有 25%。溢出解释至此完全死亡。
• 去掉 modelContextLimit: 300000 之后问题依然复现 → 配置这个变量也洗清了。剩下唯一持续存在的变量就是上游侧的切断行为本身。

2. 先确认两件决定性的事

a. 改完 core.ts 后，bili 重新 build 并重启了吗？ 你只重启了 ZCode——ZCode 是客户端，bili 是独立进程，跑在 source checkout 里的代码改动必须 npm run build + 重启 bili 才生效。如果 bili 还在跑旧代码，重试放宽根本没上线，这次复现完全符合预期，不能说明修复无效。判别方法：看 15:39:11 前后会话 9495a862 的完整日志段里有没有重试行（原文案是 retrying fetch once，你 AI 若改了文案就按新文案搜）——有 = 新路径生效过但第二次也失败；没有 = 新路径没触发（门控没放宽或 bili 没更新）。

b. 这次断流的 9495a862 未必是 glm。 你上一份日志里（14:23:45）这个会话明确是 model=deepseek/deepseek-v4.1-flash:free。"都是 glm 5.3 flash 最高思考"的印象可能不准——请在新日志里找 9495a862 的 nudge/[window] 行确认它 15:39 时用的模型（除非你重启后改过路由）。

3. 新模式：断流都发生在多会话并发流式生成期间

把三次失败摆在一起看：

• 14:23:43.293 和 14:23:43.987：两个会话在 0.7 秒内先后被掐；
• 15:39:11 9495a862 被掐的同一时刻，c163be61 和 4e96d5b1 都在活跃出流（15:39:14 各自有 usage 行）。

受害者的共同形状是长纯思考流（0 可见文本），且大小不一（14k~90k 字符），排除固定 token 阈值；但每次都有其它并发流在场。高概率根因升级为：GLM 编程套餐的并发流限制/削峰——ZCode 主智能体 + 多个子智能体并行生成时超过并发上限，网关不返回 429 而是直接掐掉已存在的长连接（通常是占资源最久的那条，即纯思考流）。这也同时解释了"为什么偏偏是子智能体场景高发"（子智能体扇出 = 并发度上升）。

可立即验证的实验：把 ZCode 的子智能体并发数调到 1（或最低），重复同一任务若干次。断流消失 → 坐实并发上限；仍出现 → 再往下查。另外建议直接问 GLM 支持：编程套餐是否有并发请求数限制、超限时网关的行为是什么（拒绝还是断连）。

4. 为什么重试放宽在这种场景下救不回来（即使已生效）

截断重试是原样重发同一个请求。如果切断原因是"此刻并发已满"，第二次尝试撞上的还是饱和状态，大概率再死；如果是确定性 kill 条件（同请求同形状），同样再死。重试可靠救回的只有单发网络抖动——所以 4/4 通过可能恰好是那段时间没有并发碰撞，而不是修改本身保证了结果。

顺带记录（非本次病因）

• 日志里有 reasoning-pair-violated ... (#684) 警告：部分 assistant tool-call 消息缺 reasoning_content。这只对 DeepSeek strict-echo 类上游致命（会 400），GLM 这些请求都正常接受了，不是本次原因；但如果之后切回 deepseek thinking 模型要留意这条。

请把这三样发上来，就能把归因钉死：① 15:39:11 前后 9495a862 的完整日志段（含有没有重试行）；② bili 是否已 build+重启；③ 并发数调 1 后的实验结果。

[zzzzzzzzzzzzzzzzzzzzzzzzzzy]

没有找到retrying fetch once这类的log；
bili是zcode唤起的，所以ai说，重启zcode就可以；我关闭了zcode之后，bili的本地网页确实就打不开了

2026-09-16T15:39:06.798Z [warn] [c163be61-d208-4994-9a4c-b5eba7b798e3] reasoning-pair-violated: 2 assistant tool-call message(s) lack reasoning_content while 12 carry it — strict-echo upstreams (DeepSeek thinking mode) will reject the request (#684)
2026-09-16T15:39:06.799Z [info] forward POST → https:///v1/chat/completions
2026-09-16T15:39:07.747Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] [acp-usage] round 1 input=59452 cached=58112 (cache hit 98%)
2026-09-16T15:39:08.013Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] processTurn: 97 msgs, renderTags=text-only, 17 text tagged, 0 tool tagged (should be 0 with text-only)
2026-09-16T15:39:08.013Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] nudge idle: usage=6% (59452/935000), growth=28365/22500 (ref=31087, interval=50000), pendingT1=35158/50000 model=z-ai/glm-5.3-flash, reason="max compressible 35158 < threshold 50000"
2026-09-16T15:39:08.013Z [warn] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] reasoning-pair-violated: 5 assistant tool-call message(s) lack reasoning_content while 19 carry it — strict-echo upstreams (DeepSeek thinking mode) will reject the request (#684)
2026-09-16T15:39:08.016Z [info] forward POST → https:///v1/chat/completions
2026-09-16T15:39:11.178Z [info] [9495a862-796c-426f-a153-015afcf7d786] [acp-loop] round 1: upstream stream truncated (no completion event; round 1, 0 text chars + 14307 reasoning chars received)
2026-09-16T15:39:14.379Z [warn] [tag-echo] stripped model-emitted render tag:
2026-09-16T15:39:14.380Z [info] [c163be61-d208-4994-9a4c-b5eba7b798e3] [acp-usage] round 1 input=44588 cached=43200 (cache hit 97%)
2026-09-16T15:39:14.652Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] [acp-usage] round 1 input=60676 cached=59392 (cache hit 98%)
2026-09-16T15:39:16.049Z [info] [c163be61-d208-4994-9a4c-b5eba7b798e3] processTurn: 67 msgs, renderTags=text-only, 16 text tagged, 0 tool tagged (should be 0 with text-only)
2026-09-16T15:39:16.050Z [info] [c163be61-d208-4994-9a4c-b5eba7b798e3] nudge idle: usage=5% (44588/935000), growth=11988/22500 (ref=32600, interval=50000), pendingT1=21643/50000 model=z-ai/glm-5.3-flash, reason="max compressible 21643 < threshold 50000; growth 11988 < floor 22500"
2026-09-16T15:39:16.050Z [warn] [c163be61-d208-4994-9a4c-b5eba7b798e3] reasoning-pair-violated: 2 assistant tool-call message(s) lack reasoning_content while 13 carry it — strict-echo upstreams (DeepSeek thinking mode) will reject the request (#684)
2026-09-16T15:39:16.054Z [info] forward POST → https:///v1/chat/completions
2026-09-16T15:39:16.239Z [info] [4e96d5b1-3654-4005-adc7-b75288ec4ce4] processTurn: 99 msgs, renderTags=text-only, 17 text tagged, 0 tool tagged (should be 0 with text-only)