企微智能机器人适配器逐 chunk 推送导致长回答流式被拉长数倍，建议内置节流合并

[zylong0549]

企微智能机器人适配器逐 chunk 推送导致长回答流式被拉长数倍，建议内置节流合并

[Smilewithoutfalling]

I'd like to take this one.

The report has no repro, so I traced the WS path myself before claiming it. What I could verify in the code:

• WecomBotWsClient.push_stream_chunk emits a frame whenever the content changed. There is dedup against the previously sent content, but no pacing.
• Every frame must carry the complete snapshot (the method comment says so, and the long-connection docs likewise have no server-side refresh callback, so pacing is entirely client-side). Total bytes on the wire therefore grow with roughly the square of the answer length: a 3000-character answer pushed in 20-character chunks is 150 frames and about 226,000 characters uploaded, ~75x the answer itself. That 20-character figure is an illustration, not a measured chunk size.
• To be precise about what I am not claiming: the public docs do not document any push rate limit, so I could not substantiate a server-side throttle. The byte volume above is what is actually derivable from the code.
• ws_client.py has no interval logic, while two sibling paths in this repo already handle the same class of problem: the Discord adapter paces edits (_STREAM_EDIT_INTERVAL), and the webhook path in api.py coalesces a slow consumer. WS mode is the one that was left out.

Plan — small, single file, no new abstraction:

1. src/langbot/libs/wecom_ai_bot_api/ws_client.py: a module-level minimum interval (0.3s) between intermediate frames, tracked per msg_id.
2. The first frame of a reply and the final chunk always go out, so replies never terminate late and short replies are unaffected.
3. Dropping an intermediate frame loses nothing, since the next frame carries the full snapshot — so the existing content-dedup logic is left untouched rather than layered on top of.
4. Tests: a new regression file, plus an explicit throttle opt-out in test_ws_stream_sends_cumulative_snapshots_to_wecom. That test (added in feat: add supports for dify hitl #2226) asserts one frame per chunk, which pins exactly the behaviour being changed. I keep its cumulative-snapshot intent and opt out of throttling locally rather than weakening the assertion.

No public API change, no config change, no new dependency. pytest tests/unit_tests/platform and ruff are clean locally.

Two things I would rather flag up front than get wrong:

• If there is a server-side push limit that is not in the public docs, give me the number and I will align the interval to it.
• 0.3s is a judgement call, not a measured constant. If you would prefer it configurable, say so and I will move it into the adapter config.

I'll open a PR shortly.

AI assistance: I used an LLM to help draft the patch and this comment; I read every line, ran the tests, and verified each claim above against the source or the docs myself.