fix: wexin _split_text_for_weixin_delivery

[weedge]

What does this PR do?

Fixes WeChat message truncation for long assistant responses. The old _split_text_for_weixin_delivery function split content into one API call per top-level line (each table row, separator ---, header, etc.), producing 70 separate API calls for a typical long markdown response. WeChat's rate limiter silently drops messages sent in rapid succession, causing the user to see only the first few chunks.

This PR packs small delivery units together (up to MAX_MESSAGE_LENGTH per message) and adds a 0.3s inter-chunk delay to stay within WeChat's rate limits.

Related Issue

Fixes message truncation on WeChat when the assistant produces long markdown responses with tables, headers, and code blocks.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• gateway/platforms/weixin.py — _split_text_for_weixin_delivery(): Pack delivery units together into messages up to max_length instead of emitting each unit as a separate message. For the real-world test case (4619-char markdown with 6 sections, tables, and ASCII art), this reduces API calls from 70 → 2 with zero content loss.
• gateway/platforms/weixin.py — WeixinAdapter.send(): Add 0.3s asyncio.sleep between chunks to avoid triggering WeChat's rate limiter when multiple chunks are still needed.

How to Test

1. Send a question to the WeChat bot that produces a long response (multiple markdown tables, headers, code blocks — aim for 4000+ characters)
2. Verify the full response is delivered without truncation
3. Verify content integrity: all sections, tables, and code blocks are present

Automated verification (inline test with the actual truncated message):

Original content: 4619 chars → Normalized: 4972 chars
OLD: 70 chunks (70 API calls) → NEW: 2 chunks (2 API calls)
Content integrity: 5007 chars in both (identical)

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 15 (darwin 25.3.0)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Before (70 API calls, message truncated after first few chunks):

OLD: 70 chunks (= 70 API calls)

After (2 API calls, complete delivery):

NEW: 2 chunks (= 2 API calls)
Chunk 1: 3512 chars (intro through benchmarks)
Chunk 2: 1493 chars (ASCII diagram + comparison table + summary)

[weedge]

{"role": "assistant", "content": "综合前面从论文 HTML、子代理研究和多次搜索中获取到的全部信息，我已经可以给出完整的相关研究梳理了。以下是基于论文实际引用和讨论的所有相关研究：\n\n---\n\n#    # 📚 LPM 1.0 论文相关研究梳理\n\n论文 43 页，引用了大量文献。根据论文内容，相关研究可归纳为 **6 大方向**：\n\n---\n\n### 一、🎭 音频驱动的说话头像生成（Audio-Driven Talking Head）\n\n这是
    与 LPM 1.0 最直接相关的研究领域，论文将此类方法统称为 \"Talking Head\" 方法，认为它们只关注了表演的子集（唇形同步）。\n\n| 工作 | 年份 | 机构 | 核心方法 | 与LPM关系 |\n|------|------|----    --|---------|----------|\n| **SadTalker** | 2023 (CVPR) | — | 从音频学习 3DMM 运动系数（头部姿态+表情），隐式3D感知渲染 | 经典基线，仅做\"说话\" |\n| **VASA-1** | 2024 | 微软 | 扩散模型在
    面部运动潜在空间中生成整体面部动力学和头部运动 | 早期实时方向探索 |\n| **VASA-3D** | 2025 | 微软 | 3D高斯溅射 + VASA-1 运动潜在空间，自由视角说话头像 | 3D方向拓展 |\n| **Diffused Heads**     | 2024 (WACV) | — | 扩散模型替代GAN做说话人脸生成 | 证明了扩散模型在talking head的可行性 |\n| **GeneFace++** | 2023 | — | 泛化稳定实时3D说话人脸生成 | 实时3D方向 |\n| **VividTalk** | 2023     | — | 单样本说话头像，基于3D混合先验 | 单样本设置 |\n| **IF-MDM** | 2024 | — | 隐式面部运动扩散模型，高保真实时说话头像 | 实时扩散方向 |\n| **FLOAT** | 2024 | — | 流匹配做音频驱动人像动>    画 | 流匹配替代扩散 |\n| **PortraitTalk** | 2024 | — | 可定制单样本说话人脸生成 | 可定制方向 |\n| **JoyVASA** | 2024 | — | 基于扩散的面部动力学与头部运动生成 | 扩散talking head |\n| **Edi    tYourself** | 2026 | Pipio AI / Amazon | DiT驱动的说话头像生成+编辑，支持长时长缓存策略 | 长时生成方向 |\n| **READ** | 2025 | — | 实时高效异步扩散做说话头像 | 实时优化方向 |\n| **ACTalker    ** | 2025 | — | 掩码选择性状态空间建模的自然说话头像 | 新架构探索 |\n\n**LPM 的超越**：这些方法基本只做\"说话时的唇形同步+头部运动\"。LPM 1.0 额外建模了**倾听反应**（点头、眼神偏移、微表>    情），实现了**全双工对话表演**。\n\n---\n\n### 二、👤 音频驱动的实时流式数字人（Real-Time Streaming Avatars）\n\n这是 LPM 1.0 的直接实验对比对象。\n\n| 工作 | 机构 | 核心方法 | 与LPM关系     |\n|------|------|---------|----------|\n| **Kling-Avatar-2** | 快手 | 离线高质量头像视频生成 |   实验基线（离线质量），LPM 以 64.3% 偏好率胜出 |\n| **OmniHuman-1.5** | 字节跳动 | 认知模>    拟驱动的头像，\"赋予头像活跃心智\" |   实验基线（离线质量），LPM 以 42.5% 略优 |\n| **LiveAvatar** | — | 算法-系统协同设计框架，无限长头像流式生成，5×H800 达 20fps |   实验基线（实时流式>    ），LPM 以 82.5% 大幅胜出 |\n| **SoulX / SoulX-LiveTalk** | — | 自纠正双向蒸馏实现实时无限流式音频驱动头像 |   实验基线（实时流式），LPM 以 64.1% 胜出 |\n| **Livatar-1** | — | 定制流匹配>    做实时说话头像生成 | 相关方法，实时方向 |\n| **AvatarForcing** | — | 实时头像控制方法 | 实时控制技术 |\n| **Knot Forcing** | — | 实时控制技术 | 实时控制技术 |\n\n---\n\n### 三、🎬 基础视>    频生成模型（Foundation Video Generation）\n\nLPM 的 Base LPM 基于 Wan2.1-I2V 构建。\n\n| 工作 | 机构 | 角色 |\n|------|------|------|\n| **Wan2.1-I2V** | 阿里 | Base LPM 的基础架构，图生>    视频扩散 Transformer |\n| **Wan 2.1/2.2 MoE DiT** | 阿里 | MoE 版本的扩散 Transformer 视频生成 |\n| **Open-Sora** | 开源社区 | 开源视频生成模型，低成本训练范式 |\n| **Stable Video Diffusi    on (SVD)** | Stability AI | 图像到视频扩散模型先驱 |\n| **DiT (Diffusion Transformer)** | Sora 团队 | 扩散 Transformer 基础架构 |\n\n---\n\n### 四、🧠 多模态大模型（Multimodal LLMs）\n\n>    用于数据管线和评估。\n\n| 工作 | 机构 | 用途 |\n|------|------|------|\n| **Qwen3-VL / Qwen3-Omni** | 阿里 | 数据管线中的语义验证（判断\"假倾听\"） |\n| **Gemini 2.5** | Google | 基础能力    参考 |\n| **GVHMR** | — | 数据管线中的3D人体恢复，用于多视角参考提取 |\n\n---\n\n### 五、🔧 推理优化与长序列技术（Efficient Inference）\n\nOnline LPM 的关键技术依赖。\n\n| 工作 | 用途 |\n    |------|------|\n| **Ulysses-style Context Parallelism** | 长序列（>50K token）训练的上下文并行策略 |\n| **Attention Sinks** | KV Cache 中的固定 sink token，保存全局身份信息 |\n| **Stream    ingLLM** | KV Cache 滑动窗口管理，使模型可无限推理 |\n| **Hunyuan-DiT** | 腾讯的扩散Transformer，长视频训练参考 |\n| **Selective Activation Checkpointing (SAC)** | 仅对重型算子做检查点节>    省显存 |\n\n---\n\n### 六、📝 评测基准（Benchmarks）\n\n| 基准 | 覆盖范围 | 不足 |\n|------|---------|------|\n| **VBench++** | 通用视频生成质量 | 不评估交互表演 |\n| **Video-Bench** | 通    用视频理解 | 不覆盖倾听/对话转换 |\n| **LPM-Bench** ⭐ (本文提出) | 首个交互式角色表演评测，1000例，5场景 | — |\n\n---\n\n### 📊 相关研究全景关系图\n\n```\n                    视频生成基>    础\n                  ┌──────────────┐\n                  │  Wan2.1-I2V  │ ← Base LPM 基础架构\n                  │  DiT / SVD   │\n                  └──────┬───────┘\n                             │\n          ┌──────────────┼──────────────┐\n          │              │              │\n    说话头像生成    实时流式头像     多模态理解\n    (Talking Head)  (Streaming)     (VLM)\n              │              │              │\n    SadTalker     LiveAvatar      Qwen3-Omni\n    VASA-1        SoulX           (语义验证)\n    Diffused Heads Kling-Avatar-2   GVHMR\n    GeneF    ace++    OmniHuman-1.5   (多视角提取)\n    JoyVASA       Livatar-1\n    EditYourself\n          │              │\n          └──────┬───────┘\n                 │\n          ┌──────┴───────    ┐\n          │   LPM 1.0    │ ← 统一\"表演\"视角\n          │  (本文)       │    全双工 + 实时 + 无限长\n          └──────────────┘\n                 │\n          ┌──────┴───────┐\n              │  LPM-Bench   │ ← 新评测基准\n          │  (本文提出)   │\n          └──────────────┘\n```\n\n---\n\n### 💡 LPM 1.0 相对相关研究的本质区别\n\n| 维度 | 现有研究 | LPM 1.0 |\n|------|-    --------|---------|\n| **任务定义** | Talking Head（说话头像） | Performance Model（表演模型） |\n| **输入** | 单一音频 → 视频 | 音频 + 角色 + 文本 → 全双工视频 |\n| **倾听建模** | ❌ 忽>    略 | ✅ 专门建模（交错音频注入） |\n| **身份一致性** | 短时还行，长时漂移 | 多参考条件化 + Attention Sinks 无限稳定 |\n| **实时能力** | 高质量模型慢，快的质量差 | 两阶段：离线720P + 实时4    80P流式 |\n| **评测** | 唇形同步 + 画面质量 | 全维度：说/听/对话/动作/泛化 |\n\n**一句话**：现有工作把问题定位为「让头像会说话」，LPM 1.0 把问题重新定义为「让角色会表演」——这涵盖了说话、>    倾听、反应、情感表达和时间维度上的身份维持。", "reasoning": null, "finish_reason": "stop", "timestamp": "2026-04-11T22:53:25.550690"}

---

FIXED:

[weedge]

[teknium1]

Merged via salvage PR #7903. Your contribution — inter-chunk delay for rate-limit protection — was incorporated into the combined fix. All six PRs addressing this issue were synthesized into a single implementation that takes the best aspects of each. Thank you @weedge for the contribution!