哔哩哔哩技术

哔哩哔哩B-UP顶尖技术人才项目火热招募中！

Fri, 31 Jul 2026 16:36:00 +0800

等你投简历的 2026-07-31 16:36 上海

CVPR 2026 Highlight 丨用“几何感知”把扩散 Transformer 采样做成免训练加速器

Fri, 24 Jul 2026 12:00:00 +0800

原创 AI 2026-07-24 12:00 上海

扩散采样不是在平直空间里走直线，而是在模型学到的弯曲特征流形上前进。

前言

扩散模型已经成为图像生成和视频生成中最重要的一类基础模型。从 DiT 到 FLUX，再到 HunyuanVideo，越来越多的高质量生成系统都依赖扩散 Transformer 来逐步完成从噪声到图像、从噪声到视频的生成过程。

但一个非常现实的问题是：扩散模型很慢。

这种慢并不是因为单次前向传播特别复杂，而是因为生成过程通常需要很多轮连续去噪。每一步都要调用一次大模型，几十步甚至上百步串行执行下来，推理延迟和计算成本都会变得很高。对于交互式图像生成、视频生成、移动端部署或大规模内容生产来说，这种成本很难忽视。

一个很自然的问题于是出现了：

既然扩散模型慢在采样步数多，那能不能直接少采几步？

直觉上，这似乎是最直接的加速方式。但在实际系统中，粗暴减少采样步数往往会带来明显的质量下降：图像结构变形、语义不稳、细节丢失，视频中还可能出现闪烁和运动不连续。

也就是说，扩散模型加速并不是简单地“少算几步”。真正困难的是：

如何在大步采样时，仍然让生成轨迹沿着模型学到的正确方向演化？

我们的论文 GeoRK2: Geometry-Guided Runge-Kutta Integration for Diffusion Transformer Acceleration 正是围绕这个问题展开。目前文章已被CVPR2026收录为HIGHLIGHT。GeoRK2 是一个免训练、可插拔的扩散 Transformer 加速框架。它把数值积分中的二阶 Runge-Kutta 方法和深度特征空间中的几何结构结合起来，使扩散采样在更少计算下仍然保持稳定的生成质量。

简单来说，GeoRK2 的核心思想是：

扩散采样不是在平直空间里走直线，而是在模型学到的弯曲特征流形上前进。加速采样时，必须尊重这个几何结构。

^{图片 1 - 多种方法在多个提示词下生成图像的可视化结果。在高加速比下，FORA 和 TaylorSeer 等方法会出现不同程度的图像质量下降，而 GeoRK2 仍能保持更优的性能。}

动机：为什么扩散模型一加速就容易“跑偏”？

传统扩散采样器通常把去噪过程看成一个普通的数值积分问题。给定当前噪声状态，模型预测下一步应该往哪里走，然后采样器沿着这个方向推进。

在 DDIM、DPM-Solver 以及很多后续加速方法中，一个隐含假设是：

扩散状态的演化发生在一个近似平直的欧氏空间中。

如果这个假设成立，那么大步采样就可以被理解为在平直空间中做更大的跳跃。只要数值积分公式足够高阶，采样轨迹就应该能够保持稳定。

但扩散 Transformer 的内部特征并不是这样工作的。

我们在 DiT-XL/2 和 FLUX.1-dev 的中间激活上观察到一个非常明显的现象：模型的特征变化高度集中在少数主方向上。换句话说，虽然特征向量位于一个高维空间中，但真正承载主要变化的方向其实很少。

论文中的激活谱分析显示，前 64 个主方向已经能够解释超过 99% 的特征方差。这说明扩散 Transformer 的去噪过程更像是在一个低维、弯曲的特征流形上运动，而不是在整个高维欧氏空间中自由移动。

^{图片 2 - 主导方向解释的方差。针对 (a) DiT-XL/2 和 (b) FLUX.1-dev 的热力图显示，前 64 个主成分方向解释了超过 99% 的方差。}

这带来一个关键问题：

当采样步长变大时，如果仍然使用普通欧氏空间中的直线外推，轨迹就可能逐渐偏离模型真正学到的特征流形。我们把这种现象称为：

manifold drift，流形漂移。

直观来说，模型知道一张图像应该如何从噪声中逐步成形，但这个过程发生在它内部学到的特征几何结构上。普通加速方法只看到“往前走”，却没有看到“应该沿着哪条弯曲的路走”。当步子迈得很大时，轨迹就容易切过流形曲率，而不是贴着流形前进。

^{图片 3 - (a) GeoRK2 遵循内在流形几何结构，相比忽略曲率的欧氏空间预测方法，能够生成更平滑且更忠实的特征轨迹。 (b) 在大步长条件下，GeoRK2 仍保持稳定，而与几何无关的预测器会因误差快速累积而性能受损。}

最终表现出来的就是：

图像结构开始扭曲；
语义条件逐渐变弱；
局部纹理和全局布局不一致；
视频生成中出现帧间闪烁和运动不连续。

因此，扩散 Transformer 加速的核心矛盾可以概括为：

我们想减少采样步数，但不能让采样轨迹偏离模型学到的特征流形。

GeoRK2 的出发点，就是把这个被忽略的几何问题显式建模出来。

方法：GeoRK2 = 几何感知预测 +

流形校正 + 自适应稳定

^{图片 4 - GeoRK2 通过将黎曼积分嵌入 Transformer 推理流程，实现具有几何感知能力的扩散采样。（左）预测阶段利用缓存的激活值，在较大时间间隔上外推潜在动态；校正阶段则在局部构建的几何流形上细化轨迹。（右）在每个 Transformer 块内，GeoRK2 引入轻量级的预测-校正模块，用曲率感知的二阶积分替代现有采样器（如 DDIM、DPM-Solver）的默认数值更新，从而在无需重新训练的情况下实现稳定且加速的生成。}

GeoRK2 的方法设计可以用一句话概括：

在 RK2 二阶积分的基础上，用模型内部激活估计局部特征几何，并用这个几何结构约束大步采样。

从整体上看，GeoRK2 包含三个核心模块：

1. 几何感知的 RK2 预测；

2. 低秩度量预条件校正；

3. 自适应稳定机制。

下面分别来看。

1. 几何感知 RK2：不是直接外推，

而是沿主特征方向外推

Runge-Kutta 方法是经典数值积分中的一类高阶方法。普通的一阶方法只看当前位置的速度，而 RK2 会额外估计一个中点，从而更准确地预测下一步状态。

在扩散采样中，这意味着：

不要只根据当前一步的方向前进，而是先估计中间位置，再用中间位置的方向来决定大步更新。

但 GeoRK2 并不是直接把标准 RK2 套到扩散 Transformer 上。原因在于，高维特征空间中并不是所有方向都同样可靠。很多方向可能只是噪声，或者并不位于模型真正使用的特征流形上。

因此，GeoRK2 在做中点预测时，会先把更新投影到主导特征子空间中：

h_mid = Projection(h_t + step / 2 * v_t)

这里的 Projection 不是任意设计的，而是来自模型中间激活的低秩主方向。也就是说，GeoRK2 会先问模型：

当前这个阶段，哪些特征方向才是真正重要的？

然后只在这些方向上进行大步预测。

这样做的直观效果是：

保留模型最有信心的主要变化方向；
抑制偏离流形的噪声方向；
避免大步采样时轨迹漂到不可靠区域。

可以把它理解成：普通 RK2 是“往前走得更准”，而 GeoRK2 是“沿着模型认为可靠的路往前走”。

2. 低秩几何校正：用激活协方差

估计模型内部的局部度量

只做投影还不够。因为扩散模型的去噪过程并不是一条直线，而是在不同噪声阶段经历不同曲率的轨迹。特别是在高噪声向低噪声过渡时，特征空间的几何结构会发生明显变化。

为了解决这个问题，GeoRK2 会从模型的中间激活中构造局部协方差矩阵：

G_t = covariance(H_t) + epsilon * I

这个矩阵可以理解为当前特征空间的一个局部“几何度量”。大特征值方向表示模型在这些方向上变化强、结构敏感，更新时需要更加谨慎；小特征值方向则表示变化较平坦，可以更放心地加速。

但直接使用完整协方差矩阵代价很高。对于扩散 Transformer 的中间层来说，完整矩阵求逆会带来明显计算开销。

GeoRK2 的关键工程设计是：只保留低秩主方向。

由于论文中观察到 top-64 主方向已经解释超过 99% 的方差，GeoRK2 使用截断 SVD 来近似这个几何度量。这样既保留了最重要的特征几何，又把复杂度控制在可接受范围内。

在得到低秩几何度量之后，GeoRK2 会对预测结果做一次 metric-preconditioned correction：

geometry correction = - lambda * G_inverse * prediction_error

直观来说，这一步是在问：

当前预测结果和模型真正希望的去噪方向之间还有多少偏差？这个偏差应该按照特征流形的几何结构如何修正？

这就是 GeoRK2 中的“几何校正”。

它不是重新训练模型，也不是额外学习一个校正网络，而是直接利用预训练模型内部已有的激活统计来完成校正。

为了进一步降低开销，GeoRK2 还使用 Woodbury identity 来高效计算低秩矩阵逆，并且每隔若干步更新一次 metric，而不是每一步都完整重算。

3. 自适应稳定：

遇到剧烈阶段切换时及时刹车

扩散采样过程并不是平稳的。

在早期高噪声阶段，模型主要决定全局布局和大致语义；在后期低噪声阶段，模型开始细化纹理、边缘和局部细节。不同阶段之间的过渡往往会带来速度和加速度的突变。

如果加速方法在这些位置仍然激进外推，就可能出现不稳定。

因此，GeoRK2 加入了一个非常简洁的自适应稳定机制。它会监测当前采样轨迹的加速度方差：

ifVar(a_t) suddenly increases:
    use conservative fallback
else:
    use geometry-aware RK2 prediction

当检测到状态变化过于剧烈时，GeoRK2 会暂时退回到更保守的两点外推，避免错误被快速放大。最后还会使用 momentum mixing 对输出进行平滑：

h_out = rho * corrected_prediction + (1 - rho) * h_t

这一步的作用不是让方法变复杂，而是让几何积分在真实模型中更加稳健。

论文中也观察到，这个 rollback 机制主要在高加速设置下的关键时间段触发，例如 FLUX 中从概念布局转向细节 refinement 的阶段。它带来的额外开销很小，但可以显著降低发散风险。

工程上是否可落地？

GeoRK2 的一个重要特点是：它不需要重新训练模型，也不需要修改模型结构。

它更像是一个轻量级 PyTorch wrapper，在推理时拦截中间激活，估计局部几何结构，然后替换或增强原本的采样更新。

从复杂度上看，GeoRK2 的额外开销主要来自三部分：

主特征方向投影；
低秩 metric correction；
周期性截断 SVD。

论文中的 profiling 显示，在 DiT-XL/2 上，当截断秩取 64 时：

projection step 约 0.014 TFLOPs；
metric-preconditioned inversion 约 0.022 TFLOPs；
amortized truncated SVD 每步约 0.011 TFLOPs；
总额外 FLOPs 约 5.1%；
实测每步 wall-clock overhead 约 3.8%。

考虑到 GeoRK2 能够带来 4-5 倍级别的整体采样加速，这个额外开销是很小的。

更重要的是，它的超参数并不敏感。论文中使用同一组配置：

lambda = 0.1
rho = 0.85
beta = 0.9
rank = 64

就可以在 DiT-S/2、DiT-B/2、DiT-XL/2 等模型上稳定工作。这说明 GeoRK2 不是依赖精细调参的特定技巧，而是利用了扩散 Transformer 特征几何中的普遍结构。

实验结果：

4-5 倍加速下保持高质量生成

为了验证 GeoRK2 的效果，论文在三个代表性场景上进行了实验：

ImageNet-256 上的 class-conditional image generation，使用 DiT-XL/2；
DrawBench 上的 text-to-image generation，使用 FLUX.1-dev；
VBench 上的 text-to-video generation，使用 HunyuanVideo。

对比方法包括传统采样器 DDIM、DPM++，以及多种扩散 Transformer 加速方法，例如 FORA、TaylorSeer、ToCa、SmoothCache、TeaCache、DBCache 等。

1. ImageNet-256：

高加速下仍保持较低 FID

在 ImageNet-256 + DiT-XL/2 上，GeoRK2 在多个加速档位下都取得了较好的速度-质量权衡。

例如：

GeoRK2(N=2) 将延迟从 8.38s 降到 4.42s，达到 1.95x 加速，同时 FID 为 2.41；
GeoRK2(N=3) 在 2.70x 加速下取得 FID 2.67；
GeoRK2(N=8) 在 4.92x 加速下仍保持 FID 3.32。

相比之下，很多方法在类似高加速设置下 FID 会明显上升。这说明在 aggressive acceleration 下，几何感知积分能够更好地保持采样轨迹稳定。

_{表格 1 - 使用 DiT-XL/2 在 ImageNet-256 上的定量比较。结果为 5 次运行的平均值。Speed表示相对于 DDIM-50 的加速倍数。}

2. FLUX.1-dev：

复杂文本条件下保持语义一致性

在 FLUX.1-dev + DrawBench 上，GeoRK2 的优势尤其体现在语义一致性上。

在 NFE=50 设置下：

GeoRK2(N=5) 达到 3.52x latency speedup，ImageReward 为 0.9889，CLIP Score 为 34.963；
GeoRK2(N=7) 达到 4.06x latency speedup，仍保持 ImageReward 0.9792；
GeoRK2(N=8) 达到 4.39x latency speedup，CLIP Score 仍保持在 33.476。

这一点很重要。因为文本到图像生成不仅要求图像清晰，还要求模型正确理解 prompt。部分缓存类方法虽然也能加速，但在复杂文本条件下更容易损失语义一致性。

GeoRK2 通过几何约束保持中间特征轨迹稳定，因此在大步采样时更不容易偏离文本条件所对应的生成方向。

_{表格 2 - 在 FLUX.1-dev 上的比较。结果为 5 次运行的平均值。Speed 表示相对于 50 步参考方法的加速倍数。}

3. HunyuanVideo：

视频生成中的时序稳定性

视频生成比图像生成更难加速。因为模型不仅要保证单帧质量，还要保证帧与帧之间的运动连续性。

在 HunyuanVideo + VBench 上，GeoRK2(N=8) 达到：

latency 从 323.89s 降到 69.44s；
latency speedup 为 4.66x；
FLOPs speedup 为 6.77x；
VBench Score 为 80.73。

相比其他加速方法，GeoRK2 在高加速下更好地保持了时间一致性。论文中也指出，一些方法虽然单帧质量尚可，但会出现可见 flickering，而 GeoRK2 的几何度量估计能够更自然地适配时空注意力特征。

_{表格 3 - 在 HunyuanVideo 上基于 VBench 的比较。结果为 5 次运行的平均值。Speed 表示相对于 50 步基线方法的加速倍数。}

消融实验：每个组件都在发挥作用

为了验证 GeoRK2 的设计是否必要，论文还做了系统消融。

在 DiT-XL/2 上：

完整 GeoRK2 的 FID 为 2.31；
去掉 geometry correction 后，FID 上升到 3.02；
去掉 RK2、改用 Euler 后，FID 上升到 2.87；
去掉欧氏预测相关设计后，FID 上升到 3.41。

这说明 GeoRK2 的优势不是来自某一个单独 trick，而是来自三个部分的协同：

二阶预测负责更准确地大步前进，几何校正负责把轨迹拉回流形，自适应稳定负责避免阶段切换时发散。

DiT-XL/2 上的受控消融实验（N=3）。FID degradation 表示相对于完整 GeoRK2 的 FID 相对增加幅度。

_{表格 4 - DiT-XL/2 上的受控消融实验（N=3）。FID degradation 表示相对于完整 GeoRK2 的 FID 相对增加幅度。}

论文还分析了截断秩的影响。结果显示，从较低 rank 增加到 64 时质量明显提升，但继续增加到 128 后收益变小。这与前面的谱分析一致：主导特征方向已经覆盖了大部分有效几何信息。

^{图片 5 - 截断秩对特征重建的影响。散点图比较了在 1/64、1/32、1/16、1/8 比例下的原始特征与低秩特征，结果显示较高秩时与恒等线的对齐更紧密，并在 1/64–1/32 处趋于饱和，这与 FID 饱和以及捕获 99\% 谱能量的现象一致。}

总结

GeoRK2 的核心贡献，并不是简单提出一个新的采样器，而是把扩散 Transformer 加速中的一个关键问题讲清楚：

高倍采样加速失败的原因，往往不是数值阶数不够，而是采样轨迹偏离了模型内部学到的弯曲特征流形。

从这个视角出发，GeoRK2 做了三件事情。

第一，从现象上，它指出了 aggressive acceleration 下的 manifold drift 问题：普通欧氏空间外推会让去噪轨迹逐渐偏离模型真实的特征几何。

第二，从方法上，它把二阶 Runge-Kutta 积分和 Riemannian feature geometry 结合起来，用激活协方差估计局部度量，并通过低秩投影和 metric correction 保持采样轨迹稳定。

第三，从工程上，它保持了非常克制的设计：不重新训练、不修改模型结构，只作为 plug-and-play 推理模块接入现有扩散 Transformer，并在 DiT、FLUX、HunyuanVideo 上实现 4-5x 级别加速。

对于正在做图像生成、视频生成或扩散模型推理优化的团队来说，这项工作的启发是：

扩散模型加速不只是减少采样步数，而是要让每一次大步更新都沿着模型学到的几何结构前进。

当我们把特征流形的几何信息纳入采样器设计时，大模型生成就可以在更低成本下保持更稳定的质量。

-End-

作者丨五角场打工王、争气尾流

https://vowel-bagging-tweed.ngrok-free.dev/?token=acl2026caster

B站技术团队邀您共赴 ACL 2026｜携 FATE系列新作&B-UP岗位亮相圣地亚哥

Wed, 01 Jul 2026 14:12:00 +0800

哔哩哔哩技术 2026-07-01 14:12 上海

B站技术团队在展台等候各位同仁与青年技术人才，共同交流前沿技术成果和行业发展！

ACL 2026

ACL 2026（Annual Meeting of the Association for Computational Linguistics）——作为计算语言学和自然语言处理领域的国际顶级学术会议，ACL 被中国计算机学会（CCF）推荐会议列表列为 A 类国际学术会议，被 Core Conference Ranking 评为 A类会议，同时也是国际计算机学科排名 CSRankings 列表中的顶级会议。

本届会议将于 2026 年 7 月 2 日至 7 月 7 日在美国加利福尼亚州圣地亚哥（San Diego, California）举行，由国际计算语言学协会（ACL）主办。

来自哔哩哔哩大语言模型团队、推荐算法团队的研究员，将和参会的从业者和技术天才们共同交流 AI 时代下的前沿技术成果和行业发展，同时也给大家带来「B-UP 顶尖技术人才项目」的相关校招、实习岗位，欢迎大家来展台投递简历 & 打卡交流！

Fate 系列第一篇：SABER

让模型学会「何时深思考，何时直接答」

SABER

AAAI 2026

早在今年 1 月的 AAAI 2026 会议上，我们大语言模型团队推出 FATE 系列首作 —— SABER（Switchable and Balanced Training for Efficient LLM Reasoning），一经展出便收获大量关注，一举拿下当日 Best Photo 奖项，团队成员还惊喜抽中显卡大奖。

现有的推理增强大模型（如 CoT / Long-Chain Reasoning）常面临过度思考（Overthinking）问题——即便是“1+1=?”这样简单的问题，也会机械地生成冗长推理链，造成响应延迟高、推理成本大。

SABER 聚焦长思考大模型训练难题，探索如何强化大模型的链式推理能力，让 AI 具备更长的逻辑思考链路，大幅提升复杂任务下的分步求解效果，也是我们 FATE 技术系列的开篇之作。提出了一种可切换、受 Token 预算约束的混合思考训练范式，基于 GRPO 强化学习直接优化（无需 SFT 预热），让同一模型支持四种离散推理模式。

实验表明，SABER 在 MATH / GSM8K / MBPP 及逻辑推理任务上，FastThink 模式可在推理长度减少 65%~80% 的同时保持甚至提升准确率，且 NoThink 模式相比基座模型性能退化极小。

*该论文已被AAAI 2026收录，链接：https://arxiv.org/abs/2508.10026

*项目开源链接：https://github.com/bilibili/saber_rl

*具体成果介绍：https://mp.weixin.qq.com/s/AfN7ON2PPjN5MuFm327FEA

Fate 系列第二篇：CASTER

让AI像真实用户一样评价UGC内容

CASTER

ACL 2026

继 SABER 之后，我们 Fate 系列的第二篇成果 CASTER（Community-Aware Assessment of Social Textual Engagement and Resonance） 已被 ACL 2026 Main Conference收录，并将于 7 月 5 日在 San Diego Poster Session B 进行现场 Poster 展示！

*论文链接：https://arxiv.org/abs/2606.01897

*代码链接：https://github.com/bilibili/medea_rl

*模型链接：https://huggingface.co/IndexTeam/MEDEA

*DEMO链接：

*数据集链接：https://huggingface.co/datasets/IndexTeam/CASTER-Bench

让AI学会「站在观众角度思考」

传统视频质量评估（VQA）看的是画面清不清晰、有没有压缩失真。但在B站社区里，一条视频好不好，靠的从来不是画质。一段画质普通但极具创意的手书，可能获得百万播放和满屏弹幕；一段4K高清的vlog，也可能因为内容空洞而无人问津。

UGC质量的本质是社区共识，而不是像素质量。

CASTER做的事情是：给定一条视频的多模态信息（封面、关键帧、标题、标签、ASR等），让AI模拟不同类型观众的反应，然后从这些模拟反应中推断出这条内容能不能获得社区认可。

Social-CoT：

不是逻辑推理，是社会认知推理

Social-CoT是我们提出的核心推理机制。与传统CoT进行逻辑推理不同，Social-CoT进行的是社会认知推理：

第一步：实例化多元观众人设

模型需要想象不同类型的观众：资深爱好者、偶然路过的用户、对该领域感兴趣的新人、挑剔的老用户等。每个人设代表了社区中的一种典型视角。

第二步：模拟情感反应路径

对于每个观众人设，模型需要推理：这个人看完视频后会有什么感受？会被哪个片段打动？会想发什么样的评论？这不是简单的情感分类，而是深入的共情推理。

第三步：汇聚社区心智

综合所有模拟的观众反应，通过统计共识机制（Skellam Scoring）判断：这个内容是否能在社区层面产生正面共鸣？

这种"先模拟再判断"的结构，确保了最终的质量判断是从模拟的社区动态中因果推导出来的，而不是黑盒分类。下面是一个具体的Social-CoT示例：

MEDEA框架

更进一步，我们把Social-CoT落地为可训练的系统，设计了MEDEA（Multimodal Engagement-Driven Evaluation Architecture）框架：

阶段一：挖掘真实社区智慧

基于B站生态用教师模型 (Gemini) 将社区智慧转换成结构化的Social-CoT推理路径，最终构建了54K条标注样本。

阶段二：SFT让模型学会Social-CoT的结构

通过监督微调，模型学会将视觉线索（光线、剪辑节奏）和文本信息（标题、标签）与社会解读对齐。

阶段三：RL对齐人类社区标准

使用GRPO算法 + 四维复合奖励：

格式奖励：输出遵循结构化格式
标签奖励：预测正确性
认知多样性约束：防止模型生成重复评论，必须探索完整分布
社会对齐奖励：模拟评论与真实高赞评论的语义相似

其中社会对齐奖励是关键创新，没有它，模型会退化为生成「好美啊」「太棒了」这样的空泛模板；有了它，模型能生成具体且富有共情的解读，比如将冰岛vlog中风吹发丝的画面解读为「原始自然力量的震撼」。

CASTER-Bench：社区共鸣基准

为支持CASTEaR任务，我们发布了CASTER-Bench：

1485条UGC视频，覆盖30个主要内容品类（生活、知识、游戏、美食、科技、舞蹈等）
平均时长442秒（总时长182.5小时），远超现有VQA数据集的8-10秒短片
多模态信息完整：视频内容、封面图、标题、标签、分区、ASR

实验：全面超越GPT-5.2和

Claude-4.5-opus

在CASTER-Bench上，MEDEA全面超越所有四类基线方法。

高质量类别（最关键指标）：

MEDEA：F1 = 0.650，精确率 = 0.603，召回率 = 0.705
最强基线（GPT-5.2 reasoning）：F1 = 0.555
提升幅度：+17.1%

各类基线的失败模式分析：

传统VQA方法（FastVQA、DOVER、MaxVQA等）：

高质量F1仅0.33-0.41，几乎完全失效
原因：它们评估的是画面质量而非内容质量，信号层面的分析无法捕捉社区共鸣

标准大模型（GPT-5.2、Claude-4.5-Opus）：

召回率极高（>90%）但精确率极低（~30%）
原因："慷慨偏差"：通过长上下文推理能在任何视频中找到优点，但缺乏区分"还行"和"真正优秀"的社会判断力

推理增强大模型（开启reasoning模式）：

有所改善但仍不够（最高F1=0.555）
原因：逻辑推理能力不等于社会认知能力

Social-CoT提示的旗舰模型：

直接用Social-CoT提示词（不微调）：F1=0.508
说明推a理模式本身有帮助，但需要专门的训练才能真正内化"社区标准"

已在B站落地：更早发现优质内容

CASTER不只是一篇论文，它已经在B站的内容生态中实际部署运行。

通过将CASTER接入内容分发链路，系统能够在视频发布后的极早期（甚至在评论区形成之前），就识别出具有高社区共鸣潜力的优质稿件。这使得优质创作者的内容能更快地获得曝光，不再需要等待漫长的自然传播周期。

正如电话会议中提到："我们花了很多时间让AI理解什么是高质量内容，并在更早的阶段识别这些高质量内容。" CASTER正是这一愿景的技术实现。

现场见！技术交流 + 招聘专项

ACL 2026 现场，B 站技术团队将携带 SABER / CASTER 相关技术细节与大家深度切磋，展台还将发放哔哩哔哩精美周边，欢迎来聊！

同时，「B-UP 顶尖技术人才项目」的校招与实习岗位在现场开放咨询与简历投递 👇

● 热招方向：大语音模型、推荐算法、搜索算法、视频生成、视频理解、语音算法、AI Infra、高性能计算、大数据架构、模型工程

● 招聘人群：

应届生：2027届海内外本硕博毕业生（2026年9月-2027年8月期间毕业）

实习生：2027届及之后毕业的海内外本硕博在校生（2026年9月及之后毕业）

7 月美国圣地亚哥

哔哩哔哩技术团队在展台等候各位同仁与青年技术人才，共探大模型技术未来！

[6] https://grouplens.org/datasets/movielens/1m/

B站特征选择算法LeAP：模型的“精准瘦身”实践

Wed, 17 Jun 2026 12:00:00 +0800

原创 AI 2026-06-17 12:00 上海

在深度学习推荐系统中，想要自动化地筛选特征，并没那么简单。

论文arxiv：https://arxiv.org/abs/2606.01111（作者：bilibili搜索团队。已被ECML-PKDD 2026录用）

一、现状与挑战

在深度学习推荐系统中，想要自动化地筛选特征，并没那么简单。现有的特征选择方法在真实的工业场景下，目前依然存在以下挑战：

挑战1 维度异构问题

工业模型的输入极其复杂，既有 1D 的连续统计特征，也有高达 128D 甚至 256D 的用户行为序列 embedding。用统一的惩罚项来约束所有特征，这就导致高维特征天然能产生更大的梯度来对抗惩罚；而有用的 1D 特征更容易被稀疏化。

挑战2 稀疏特征问题

真实场景中存在长尾特征，99%以上的样本在这个特征上都是默认值。现有的特征选择算法常把这种“低激活频次”误认为是“毫无用处的噪音”，从而施加重罚直接剔除，导致模型丢失了关键的个性化长尾信号。

挑战3 排列（Permutation）方法的算力问题

什么是 Permutation [1] ？它的核心思想是：如果想知道某个特征到底重不重要，就把这一列特征的样本数据彻底打散（Shuffle），人为制造噪声以切断它与真实标签之间的关联，然后看模型的预测性能掉了多少。性能掉得越惨，说明特征越关键。

虽然这种方法直观、客观且具有很强的模型无关性，但它要求对成百上千个特征依次、孤立地进行打乱和重新前向推理。这种次推理的计算复杂度，在动辄几十上百亿样本的大规模数据流中，面临严峻的算力问题。

挑战4 掩码门控（Mask-Gate）的权重代偿与不极化困境

业界主流的深度学习特征选择通常基于掩码门控机制 [2,3,4]，但在端到端联合训练时，门控变量与网络下游权重存在严重的代偿效应。当正则化项施压迫使门控值缩小时，为了维持原有特征的信息传递量，模型会自动放大该特征对应的下游网络参数进行补偿。这种代偿机制使得特征得分往往停留在非零的模糊区间，无法实现向 0 或 1 的极化收敛。由于门控分数的绝对值无法直接反应特征真实贡献，特征保留的阈值划定退化成了繁复的阈值试错过程，大幅增加了验证成本。

挑战5 超参调节问题

工业级特征选择模块应当具备极简的超参空间。部分现有方法（如 LPFS [2]）为了强制特征重要性收敛到0，引入了复杂的极化函数，额外增加了多达5个以上的超参数，不同超参数组合产出的特征重要性又不一致，导致实际使用的困难。

二、LeAP: 把“特征打散”做成

端到端可学，并采用自适应

梯度去偏的正则稀疏

为了推翻这五个挑战，LeAP (Learnable Adaptive Permutation)放弃了传统的离散打乱验证，将计算密集型的特征打散过程改造成了一个复杂度的端到端可学习模块。

核心网络架构与公式化表述

理论上，我们可以将门控网络插入到模型的任何位置，但在工程实践中，为了方便和通用性，LeAP 通常在模型的特征拼接层之后插入一个轻量级的门控模块。

在每一次 batch 训练中，我们通过算法在 batch 内部对第 i 个特征进行独立洗牌，生成服从原始边缘分布的“伪造噪声”。为了让大家更直观地理解这个过程，这里贴一段精简后的 TensorFlow 核心代码：

# shuffle all feature
# hidden is the feature concat representation
def shuffle_all_features(hidden, fea_dim_range_dict):
    """
    对 hidden(形状 [B, D]) 的所有特征做样本间行洗牌。
    不同的特征使用不同的随机排列。

    fea_dim_range_dict: 类似 {
        fea_0: {'dim_start':0, 'dim_end':3},
        fea_1: {'dim_start':3, 'dim_end':7},
        fea_2: {'dim_start':7, 'dim_end':10},
        ...
    }
    返回: shape=[B, D] 的张量，逐特征完成洗牌。
    """
    # 先把特征 ID 排序，确保按原顺序拼接回去
    sorted_keys = sorted(fea_dim_range_dict.keys())

    shuffled_blocks = []
    for f in sorted_keys:
        d_start = fea_dim_range_dict[f]['dim_start']
        d_end   = fea_dim_range_dict[f]['dim_end']

        # 切出这个特征的列区间
        mid_part = hidden[:, d_start:d_end]  # [B, (d_end - d_start)]

        # 对该特征单独生成一个随机行排列 perm_f
        B = tf.shape(mid_part)[0]
        perm_f = tf.random.shuffle(tf.range(B))  # [B], 每行打乱

        # 对 mid_part 行洗牌
        mid_part_shuffled = tf.gather(mid_part, perm_f, axis=0)

        shuffled_blocks.append(mid_part_shuffled)

    # 把所有洗牌后的分块按列拼回 [B, D]
    hidden_shuffled = tf.concat(shuffled_blocks, axis=1)
    hidden_shuffled.set_shape([None, hidden.shape[1]])
    return hidden_shuffled

接着，引入一个特征专属的可学习门控变量（通过 Sigmoid 函数参数化），将原始特征与噪声特征进行无缝的融合组合：

这里使用了一个至关重要的操作——。这个操作的作用是确保反向传播时，梯度不会通过噪声分支传回去污染上游。

为了促使特征走向稀疏，我们在模型的总损失（Total Loss）中加入了正则项约束：

很明显，如果一个特征是冗余的，用噪声替换它后模型的并不会受到影响。那么在正则化的持续施压下,就会被压向0。

当时，模型完全依赖真实的原始特征；
当时，模型则倾向于完全使用打散后的噪声。

对比掩码门控（Mask-Gate），LeAP 的核心机制转变在于，将特征层面的“幅度缩放”（Masking）替换为了“信息替换”（Noise Substitution）。 面对按比例混入的真实打散特征，由于洗牌操作直接切断了该维度与 Label 之间的互信息，下游网络即使试图通过放大权重来进行代偿，也只会成比例地放大纯噪声的方差，进而导致模型整体的 Task Loss 迅速恶化。这种结构设计从根本上阻断了网络的代偿退路：对于核心特征，模型必须顶着正则压力维持其门控值。

【自适应梯度去偏正则】

为了解决异构维度和极度稀疏问题，LeAP 抛弃了统一惩罚（如全局 L1 正则），创新性地提出了 基于特征打散差异（Shuffle Divergence）的自适应正则化。

我们在每次 batch 训练中，实时计算原始特征与其被打乱版本之间的 L2范数差异：

为了防止常数特征的 Shuffle Divergence 计算为 0 导致惩罚项失效，LeAP 会对其设置一个下界截断。

通过指数移动平均（EMA）在整个训练周期内平滑这个散度得到后，特征 i 的自适应正则化权重被定义为：

这里的是我们在全局设定的稀疏项超参数，这也是 LeAP 中唯一需要调参的变量。

为什么这个设计能解决上述的异构与稀疏难题？这背后隐藏着非常巧妙的梯度动力学机制。损失可以拆分成任务损失和正则损失。根据链式法则，任务损失对门控变量的偏导数最终可以推导并解耦成如下两部分的乘积：

正如公式所示，任务梯度的更新力度本质上由两项决定：

（1）真实敏感度（Sensitivity）：模型任务本身对该特征表征的敏感程度，这才是我们真正想要的“特征重要性”指标。

（2）打散差异（Shuffle Divergence）：特征被打散前后的物理距离偏差，高维特征或稠密特征的物理差异天生就很大，这导致它们的梯度是被严重放大。这其实是一种不公平的“特征梯度偏差（Bias）”。

而 LeAP 的精妙之处在于，我们将正则化惩罚项设置成了与正相关的。在反向传播中，总损失等于任务损失+正则损失。任务损失对门控产生的梯度本质上是，而正则损失的梯度则是。当任务损失与正则损失进行对抗时，这个偏差项就被抵消了！

最终的梯度方向，变成了特征的真实敏感度期望（特征重要性）与我们设定的全局稀疏化超参之间的纯粹较量。

这套设计在数学上带来了一个极其优雅的特性：高可解释性与天然的极化趋势。

在这里，“高可解释性”有着明确的物理意义：在设定了当前正则系数的前提下，门控分数直接反映了该特征能否被随机打散的噪声安全替换的概率。

同时，正因为优化的核心变成了与的直接拉扯，对于绝大多数特征而言，其敏感度与设定的之间存在明确的强弱差异：如果有用特征的敏感度压过了，它就会在梯度驱动下坚定地奔向 1；反之，若敏感度不足以抗衡，冗余特征则会被快速压向 0。

上图是一个真实业务模型产生的特征重要性频数分布图，如图所示，LeAP 学出的特征重要性呈现出非常清晰的两极分化。这意味着算法工程师不需要像以前那样反复调参、设置多个阈值。在实际业务中，我们通常直接设定 0.5 作为分界线，就能干脆利落地“一刀切”，大大提升了特征筛选的确定性和迭代效率。

三、真实的工业落地：

在复杂业务中实现降本增效

在公开数据集（Criteo [9] , Avazu [7] , ML-1M [6] , AliCCP [8] ）上，LeAP 在不同剪枝率下的表现均达到了现有的 SOTA（State-of-the-Art）水平。

在实际的真实业务生态中，目前，LeAP 已经在B站内的多个核心业务场景中成功落地应用。

为了验证 LeAP 在业务场景下的能力，我们在一个包含 12,000+ 维特征、checkpoint大小高达 2TB 的排序模型上进行了离线验证。LeAP 成功识别出超过 3,600 个（占比超 30%）冗余特征维度，且离线评估指标没有任何降低。这充分证明了它在应对大规模工业模型时的有效性与稳健性。

LeAP 带来了：

推理提效，降本增效： 在各个业务线的多种模型场景中，LeAP 初次使用普遍有效删减了 15%~50% 的冗余特征。在保持线上核心业务指标（如播放量、互动量等）稳定的前提下，单模型的线上推理资源消耗直接降低了 5%~20%。
加速日常特征迭代： 当算法团队引入一批新特征时，不再需要“盲人摸象”。先让模型训练收敛一段时间，随后接入 LeAP 跑一遍，可以直接客观评估新特征的实际价值，从而进行针对性筛选。这种“白盒化”的迭代体验，大幅缩短了实验验证周期，避免了无效特征对计算资源的无谓消耗。

综上所述，LeAP 通过将离散的特征打乱过程转化为端到端的可学习门控网络，并结合优雅的自适应梯度去偏机制，成功解决了工业界特征选择中的维度异构与长尾稀疏难题。这套方法不仅在理论和公开数据集上得到了验证，更在 B站复杂的真实业务生态中实现了真正的降本增效。

引用

[1] Fisher, A., Rudin, C., Dominici, F.: All models are wrong, but many are useful: Learning a variable’s importance by studying an entire class of prediction models simultaneously. Journal of machine learning research: JMLR 20 (2019)

[2] Yi Guo, Zhaocheng Liu, Jianchao Tan, Chao Liao, Daqing Chang, Qiang Liu, Sen Yang, Ji Liu, Dongying Kong, Zhi Chen, et al. 2022. LPFS: Learnable Polarizing Feature Selection for Click-Through Rate Prediction. arXiv preprint arXiv:2206.00267 (2022).

[3] Yejing Wang, Xiangyu Zhao, Tong Xu, and Xian Wu. 2022. AutoField: Automating Feature Selection in Deep Recommender Systems. In Proceedings of the ACM Web Conference.

[4] Yejing Wang, Zhaocheng Du, Xiangyu Zhao, Bo Chen, Huifeng Guo, Ruiming Tang, and Zhenhua Dong. 2023. Single-shot Feature Selection for Multi-task Recommendations. In Proceedings of the 46th International ACM SIGIR Conference on Research and Development in Information Retrieval. 341–351.

[5] Jia P, Wang Y, Du Z, et al. Erase: Benchmarking feature selection methods for deep recommender systems[C]//Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 2024: 5194-5205.

[7] https://www.kaggle.com/competitions/avazu-ctr-prediction

[8] https://tianchi.aliyun.com/dataset/408

[9] https://ailab.criteo.com/ressources/

-End-

作者丨r小黑、芯艺、飞戈、ylin、海忻、问天

B站 Index LLM 团队论文开源：170亿次真实用户交互背后的UGC视频评估新范式

Fri, 12 Jun 2026 12:00:00 +0800

原创 AI 2026-06-12 12:00 上海

这项工作已被 ACL 2026 Main Conference 收录，是bilibili Index LLM Team在UGC内容理解方向的最新成果。

“我们知道B站之所以能够产生这么多好的作品，重要的原因就是社区里的用户有着对内容的热爱，并且有着对内容极高程度的审美。AI是可以放大B站社区这种识别优质内容的能力，现在社区每个月有170多亿次的真实用户的交互，这些数据在AI时代其实都是非常珍贵的真人标注，而且这些真人是整个中国对内容最有热情和最有审美鉴赏能力的人。”

哔哩哔哩2026年Q1财报电话会提到了上述内容。那么问题来了：能不能让AI学会像B站用户一样，在视频发布的第一时间就判断出它是否会获得社区共鸣？

今天我们介绍的 CASTER，就是在回答这个问题。这项工作已被 ACL 2026 Main Conference 收录，是bilibili Index LLM Team在UGC内容理解方向的最新成果。

论文链接：https://arxiv.org/abs/2606.01897

代码链接：https://github.com/bilibili/medea_rl

模型链接：https://huggingface.co/IndexTeam/MEDEA

数据集链接：https://huggingface.co/datasets/IndexTeam/CASTER-Bench

让AI学会「站在观众角度思考」

UGC质量的本质是社区共识，而不是像素质量。

Social-CoT：

不是逻辑推理，是社会认知推理

Social-CoT是我们提出的核心推理机制。与传统CoT进行逻辑推理不同，Social-CoT进行的是社会认知推理：

第一步：实例化多元观众人设

模型需要想象不同类型的观众：资深爱好者、偶然路过的用户、对该领域感兴趣的新人、挑剔的老用户等。每个人设代表了社区中的一种典型视角。

第二步：模拟情感反应路径

第三步：汇聚社区心智

综合所有模拟的观众反应，通过统计共识机制（Skellam Scoring）判断：这个内容是否能在社区层面产生正面共鸣？

这种"先模拟再判断"的结构，确保了最终的质量判断是从模拟的社区动态中因果推导出来的，而不是黑盒分类。下面是一个具体的Social-CoT示例：

MEDEA框架

更进一步，我们把Social-CoT落地为可训练的系统，设计了MEDEA（Multimodal Engagement-Driven Evaluation Architecture）框架：

阶段一：挖掘真实社区智慧

基于B站生态用教师模型 (Gemini) 将社区智慧转换成结构化的Social-CoT推理路径，最终构建了54K条标注样本。

阶段二：SFT让模型学会Social-CoT的结构

通过监督微调，模型学会将视觉线索（光线、剪辑节奏）和文本信息（标题、标签）与社会解读对齐。

阶段三：RL对齐人类社区标准

使用GRPO算法 + 四维复合奖励：

格式奖励：输出遵循结构化格式
标签奖励：预测正确性
认知多样性约束：防止模型生成重复评论，必须探索完整分布
社会对齐奖励：模拟评论与真实高赞评论的语义相似度

CASTER-Bench：社区共鸣基准

为支持CASTER任务，我们发布了CASTER-Bench：

1485条UGC视频，覆盖30个主要内容品类（生活、知识、游戏、美食、科技、舞蹈等）
平均时长442秒（总时长182.5小时），远超现有VQA数据集的8-10秒短片
多模态信息完整：视频内容、封面图、标题、标签、分区、ASR

实验：全面超越GPT-5.2和

Claude-4.5-opus

^{在CASTER-Bench上，MEDEA全面超越所有四类基线方法。}

高质量类别（最关键指标）：

MEDEA：F1 = 0.650，精确率 = 0.603，召回率 = 0.705
最强基线（GPT-5.2 reasoning）：F1 = 0.555
提升幅度：+17.1%

各类基线的失败模式分析：

传统VQA方法（FastVQA、DOVER、MaxVQA等）：

高质量F1仅0.33-0.41，几乎完全失效
原因：它们评估的是画面质量而非内容质量，信号层面的分析无法捕捉社区共鸣

标准大模型（GPT-5.2、Claude-4.5-Opus）：

召回率极高（>90%）但精确率极低（~30%）
原因："慷慨偏差"：通过长上下文推理能在任何视频中找到优点，但缺乏区分"还行"和"真正优秀"的社会判断力

推理增强大模型（开启reasoning模式）：

有所改善但仍不够（最高F1=0.555）
原因：逻辑推理能力不等于社会认知能力

Social-CoT提示的旗舰模型：

直接用Social-CoT提示词（不微调）：F1=0.508
说明推理模式本身有帮助，但需要专门的训练才能真正内化"社区标准"

已在B站落地：更早发现优质内容

CASTER不只是一篇论文，它已经在B站的内容生态中实际部署运行。

正如电话会议中提到："我们花了很多时间让AI理解什么是高质量内容，并在更早的阶段识别这些高质量内容。" CASTER正是这一愿景的技术实现。

开发者交流

CASTER将于2026年7月5日在美国San Diego进行Poster展示，现场还会发放MEDEA精美无料，欢迎大家来交流！

-End-

作者丨bilibili Index LLM Team

我们如何用 A2UI + Vue，让大模型长出“可交互界面”

Wed, 27 May 2026 12:00:00 +0800

原创大前端 2026-05-27 12:00 上海

本文围绕一个核心问题展开：如何让AI助手从“输出文字”进化到“生成界面”？

导读

本文围绕一个核心问题展开：如何让AI助手从“输出文字”进化到“生成界面”？我们基于Google A2UI协议，自研了Vue渲染器和 Agent 完整工具链，形成了一套完整的生成式UI体系。文章将详细阐述Runtime Schema装配、双重校验机制、SSE双通道输出、Wrapper组件扩展等关键设计，为构建标准化、可复用的AI交互界面提供参考。

引言

在 B 站商业广告业务中，我们开发了统一的 AI 助手框架，创建不同业务的知识库，以 markdown 渲染的形式输出内容，实现了不同业务中 AI 助手的快速应用。

但是，随着时间的推移和 AI 在业务中的快速应用，当大模型的能力从“聊天”走向“办事”时，如何让 AI 稳定、可靠地生成真正的“可交互界面”，提高信息传达和交互的效率，成为越来越多公司和业务关注的方向，从而带来了大模型生成 UI 的发展趋势。

关于这一点，我们内部的 AI 助手框架已经支持在 Markdown 中通过自定义语法嵌入组件，例如 ::: ProductCard :::，具有直观、轻量的特点，能在对话流中快速引入可交互元素。但在多业务、复杂任务的规模化落地中，它的局限性逐渐显现，例如前端、后端、Agent 耦合严重，需要 Agent 严格配合前端的特定格式来填充内容。这种方案的本质是 Agent 按前端预定义的模板填充数据，而非让 Agent 自主描述 UI 结构，不符合生成式 UI 的核心思想。

如何快速和我们的 AI 助手框架结合，形成完整的生成式 UI 体系？

在探索这个问题的过程中，我们发现这不是一个单纯的前端渲染问题，而是一个涉及大模型生成、协议标准、后端校验、前端渲染、多业务治理的系统工程。基于此，本文将完整拆解我们的实践路径。

一、B站商业广告的 AI 助手框架

在展开生成式UI的方案之前，有必要先回顾一下我们的起点。

1.1 统一 AI 助手框架

在B站商业广告业务中，我们面对的是多个差异化的业务场景：

广告投放助手：帮助广告主理解投放数据、优化投放策略
产品帮助助手：介绍广告产品功能、引导操作流程
数据分析助手：生成广告数据报表、提供洞察分析

为了快速响应各业务场景的AI需求，我们构建了统一的 AI 助手框架：

统一前端框架：标准化的对话接口、视觉样式，业务方只需实现对应的接口，并按需实现自定义功能
Markdown 渲染：前端统一支持Markdown格式输出，快速实现内容呈现

1.2 从“可读”到“可交互”的需求演进

随着业务深入，纯文本/Markdown的局限性开始显现：

场景一：广告投放诊断

用户问：“帮我看看最近三天某计划的投放效果？”
AI返回一段文字描述：“曝光量xx，点击率xx%，消耗xx元，建议优化素材...”
用户需要：一个包含关键指标卡片、趋势图表

场景二：意图识别

用户问：“我要下单，目标是xxx...”
AI返回：“您提供的缺少xxx参数...请您补充参数重新告知我下单。”
用户需要：一个结构化表单，可以直接在对话中修改并重新提交

这些场景的共同需求是：从“告诉用户怎么做”升级为“让用户在对话中直接完成操作”，这就引出了生成式UI的核心命题。

我们固然可以使用模板填充的方式：

::: ProductCard {"name":"手机","id":1}
:::

这种方案可以快速实现大部分简单场景——前端预定义好各类卡片组件，Agent按约定格式输出，前端匹配渲染。

它的优势很明显：

实现简单，短期内快速上线
卡片样式可控，符合设计规范
适合场景固定、UI形态稳定的业务

但随着场景复杂化，其局限性也逐渐暴露：

本质问题：模板填充方案让Agent扮演的是“填表员”角色，而非“设计师”角色，Agent无法根据上下文动态决定UI形态。

二、生成式 UI 的思路

2.1 为什么选择 A2UI

在协议选型上，我们调研了多种方案，最终选择 Google 的 A2UI 协议，原因如下：

标准化：大厂提出，业界规范，有社区支持，避免自研协议的技术债务
声明式：JSON Schema 描述UI，天然适合大模型生成
可增量：支持 dataModelUpdate / surfaceUpdate，实现细粒度更新
框架无关：同一份 UI 描述可在 Vue / React / 小程序等多端渲染
安全可控：组件基于组件库白名单，Agent 自由选择，客户端负责渲染

2.2 整体架构

三、后端 + Agent 设计

3.1 请求入参设置

每个业务请求需要携带能力边界声明：

3.2 Runtime Schema 装配

根据业务标识和白名单，动态装配该业务可用的组件和动作集合。

装配流程举例：

这样设计的价值在于，一是能力隔离，不同业务在统一协议下安全、独立地演进；二是动态扩展，新增业务只需要补充组件包，不改核心逻辑；三是输出可控，白名单机制限制了模型输出的边界。

3.3 双重校验机制

尽管我们通过能力隔离，已经生成了安全的 Prompt，但是由于模型输出可能不稳定，因此针对大模型产出的 A2UI JSON，必须经过严格校验才可放行。我们设计了双层校验机制：

第一层：结构校验

消息类型是否合法，符合 A2UI 协议结构（beginRendering / surfaceUpdate / dataModelUpdate）
组件类型是否在白名单
组件属性是否完整
动作名称是否在白名单

第二层：过渡校验

Surface 是 A2UI 中一个独立的 UI 实例载体，每个 Surface 有唯一的 surfaceId，代表一个独立的界面区域，具备从“未创建”→“已创建”→“可交互”的状态转换。我们需要确保这个过程合法有序，避免出现更新不存在的界面、重复初始化等异常。为此，我们维护了每个 Surface 的状态机：

校验规则：

不能更新未创建的 Surface
对于同一个 Surface，不能重复产出 beginRendering
更新时 SurfaceId 必须匹配当前会话

3.4 SSE 双通道输出

传统方案中，前端需要从文本流中正则匹配和解析JSON，链路脆弱。我们将文本流和结构化数据分离，两条通道独立传输，互不影响。若 a2ui_message 通道出现数据丢失，前端可依据 message_stream 中的文本内容降级展示，或通过 finish 事件中的完整消息进行重试补发，确保 UI 渲染的可靠性。

四、前端通用渲染器 SDK

4.1 整体结构

我们基于 Google 官方开源的 A2UI 协议、React 渲染器等，自研实现了 Vue 渲染器，以 npm 包的形式交付，业务方安装即可使用：

4.2 消息处理器

我们实现了消息处理器，为同一个 Surface 的每条 A2UI JSON 消息生成唯一签名。已处理过的消息会被识别并跳过，不再重复执行，保证逻辑的幂等性。另外，由于网络传输延迟、历史会话回放等场景，消息可能出现乱序或倒序到达，我们也设计了相应的处理机制。极端情况下，有极小概率会出现个别消息丢失，但仅会导致 Surface 的 UI 状态短暂不一致（比如，没有回显已经填写过的字段），不会引发严重渲染问题。

消息处理器链路如下：

4.3 DataModel 设计

统一状态存储，支持 path 级别读写和数据绑定：

DataModel结构示例：
{
  "/form/name": "张三",
  "/form/email": "zhang@example.com",
  "/cart/items": [{"id": 1, "name": "商品A"}],
  "/ui/loading": false
}

组件通过path引用数据，任一数据变化，所有绑定组件自动更新。

4.4 Wrapper 组件体系

业务方新增自定义组件时，只需遵循统一规范，无需理解渲染器内部逻辑。

接入流程：

编写业务组件（普通Vue组件）
使用 SDK 提供的 Wrapper 组合函数包装
注册到组件映射表（组件类型名 → 业务组件）
Agent 即可使用

Wrapper提供的能力：

自动解析 node 中的属性
自动绑定 DataModel 数据（通过 path 引用）
自动构建动作回调函数
统一处理 loading、error 等通用状态

4.5 动作闭环

组件提交的 action，分为前端处理和后端处理，业务方可自定义 action 处理方法，SDK 提供的默认有以下2类：

前端处理的事件比较简单。对于后端处理的事件，会经历以下流程：

用户交互触发动作
动作冒泡到业务层
业务层通过HTTP接口回传后端
后端返回dataModelUpdate或surfaceUpdate
前端执行增量刷新（原位更新）

这样，我们便实现了从 Agent 到前端 SDK 的、可复用的完整链路。

五、与现有框架的集成

我们并非将现有业务中已经实现的 AI 助手推倒重来，而是进行了扩展。Agent 返回的 finish 事件中，包含了 SDK 提供的标准组件 A2UIMessage.vue，业务方可直接将其作为模板组件使用：

::: a2ui-message {"message": [...]}
:::

业务方的接入成本也非常小，只需要三步：

前端实现业务组件，并接入 SDK
前端注册组件包
业务方后端或者业务方 Agent 调用接口，生成 A2UI 消息

至此，我们完整阐述说明了 A2UI 实践的完整框架和流程。可以看到，它具备以下价值：

对业务方：

无需关心UI实现，聚焦业务逻辑
新场景接入周期从天级缩短到小时级

对 Agent：

从“记忆数据格式”转向“理解UI描述语言”
具备真正的“界面生成”能力

对整体架构：

前后端解耦，协议标准化
多业务可复用同一套基础设施

六、DEMO 示例

我们已经实现了完整的可复用工具链，以下是一些 demo，展示了从用户输入 Prompt 到产出组件的过程。实际使用中，由业务方的后端或者 Agent 调用 A2UI 的 Agent 服务获取真实的 A2UI JSON，再交给业务方的前端渲染。

注意：以下为简化示例，实际 JSON 结构以 A2UI 协议为准。

6.1 图表示例

用户在对话框中输入：“我想查看最近12个月某5个车企（化名）的销量变化趋势图”
Agent 生成 A2UI JSON：

{
  "sessionId": "session-xxx",
  "messages": [
    { "createSurface": { "surfaceId": "surface-xxx" } },
    {
      "updateComponents": {
        "surfaceId": "surface-xxx",
        "components": [
          { "id": "root", "component": "Card", "child": "chart-container" },
          {
            "id": "sales-chart",
            "component": "Charts",
            "type": "line",
            "title": "近12个月车企销量趋势",
            "options": {
              "xAxis": { "data": ["1月", "2月", ...] },
              "series": [
                { "name": "车企A", "data": [12500, 13200, ...] },
                { "name": "车企B", "data": [10200, 10800, ...] },
                ...
              ]
            }
          }
        ]
      }
    }
  ]
}

渲染结果：

6.2 表单示例

用户在对话框中输入：“生成一个用户报名信息的填写表单”
Agent 生成 A2UI JSON：

{
  "sessionId": "session-xxx",
  "messages": [
    { "createSurface": { "surfaceId": "surface-xxx", "root": "root" } },
    { "updateDataModel": { "surfaceId": "surface-xxx", "value": { "userName": "", "userEmail": "", "userPhone": "" } } },
    {
      "updateComponents": {
        "surfaceId": "surface-xxx",
        "components": [
          { "id": "root", "component": "Card", "child": "form-column" },
          { "id": "form-column", "component": "Column", "children": ["title-text", "name-field", "email-field", "phone-field", "submit-btn"] },
          { "id": "title-text", "component": "Text", "text": "用户报名信息填写" },
          { "id": "name-field", "component": "TextField", "label": "姓名", "placeholder": "请输入姓名" },
          { "id": "email-field", "component": "TextField", "label": "邮箱", "placeholder": "请输入邮箱" },
          { "id": "phone-field", "component": "TextField", "label": "手机号", "placeholder": "请输入手机号" },
          { "id": "submit-btn", "component": "Button", "text": "提交报名", "action": { "name": "marketing.submitLead" } }
        ]
      }
    }
  ]
}

渲染结果：

用户填写并点击提交后，前端将表单数据回传至后端：

// 发送消息示例：后端读取注释中的数据作为结果
用户提交了数据

后端处理完成后，再次调用 A2UI 服务，返回更新界面的指令：

{
  "sessionId": "session-xxx",
  "messages": [
    { "updateDataModel": { "surfaceId": "surface-xxx", "value": {} } },
    {
      "updateComponents": {
        "surfaceId": "surface-xxx",
        "components": [
          { "id": "success-icon", "component": "Text", "text": "✓" },
          { "id": "title-text", "component": "Text", "text": "报名成功" },
          { "id": "message-text", "component": "Text", "text": "感谢您的报名，我们会尽快与您联系。" },
          { "id": "form-column", "component": "Column", "children": ["success-icon", "title-text", "message-text"] }
        ]
      }
    }
  ]
}

前端接收消息，并处理 UI 更新：

七、总结

目前，我们的 A2UI 方案已在部分业务中接入，正在快速迭代中。由于 A2UI 协议仍处于早期阶段，大模型能力也在持续演进，尚无法支持全部复杂组件的自主生成。因此，我们目前采用 A2UI 实现通用交互、业务自行实现复杂组件的混合模式。

但可以预见，随着协议和大模型能力的成熟，生成式 UI 必将释放更强大的能力和更丰富的应用场景。接下来，我们将继续探索 A2UI 在移动端、小程序等架构上的应用，期待在不远的未来做出更优质的成果。

-End-

作者丨Nie

bili-fe-workflow —商业化智能开发工作流实践

Fri, 15 May 2026 12:02:00 +0800

原创 AI 2026-05-15 12:02 上海

我们从 prompt 工程演进 Harness Engineering，做了一系列智能开发工作流，让AI能够帮助我们执行跨越整个研发生命周期的长任务。

背景

AI发展迅速，曾经 AI 只能帮我们补全下一行代码，到现在 AI 几乎已经可以在我们工作的各个阶段都提供帮助。创建需求、分析需求、分析技术方案、编写代码、调试bug、测试、性能优化等等，几乎都有了AI的介入。

但这些零散的节点，都需要开发者去自行选择使用，有的开发者可能还停留在传统编码，不同开发者用的不同 AI 方案。没有一个统一的工具将从TAPD到提测整个链路串起来，没有标准化的流程能够推动所有人都高效的利用 AI。

对于一些简单工作，如果没有开发者的介入，AI 是否可以自己从头到尾完成。
对于一些复杂的工作，如果有标准化的流程，开发者可以在固定的节点使用 AI，充分利用 AI 加速需求完成。

因此，我们从 prompt 工程演进 Harness Engineering，做了一系列智能开发工作流，让AI能够帮助我们执行跨越整个研发生命周期的长任务。

工作流总览

整体架构

详细设计

智能知识库

为什么需要项目知识库？

AI 虽然能够理解代码，但它缺少对项目整体的结构化认知：

缺乏项目全貌：AI 每次对话都是全新开始，不知道项目的技术栈、目录结构、编码规范
无法复用经验：之前的分析结果无法持久化，每次都需要重新分析
上下文受限：无法一次读取所有项目文件来建立完整认知
规范不一致：生成的代码可能与项目现有风格不一致

`.workflow` 知识库正是为了解决这些问题。它是一套结构化的项目元信息文档，让 AI 能够：

快速了解项目的技术栈和架构
遵循项目现有的编码规范和命名约定
复用已有的组件和工具函数
按照项目惯例进行 API 调用

.workflow 知识库架构

目录结构

知识库与开发流程的协作

`.workflow` 知识库是整个 AI 辅助开发流程的基础设施，与其他命令形成完整的协作链路：

协作流程详解

具体协作方式

1. prd-preprocess 如何使用知识库

prd-preprocess 命令:
  │
  ├─→ 读取 knowledge/business.md
  │     └─→ 理解业务模块划分，识别涉及模块
  │
  ├─→ 读取 knowledge/components.md
  │     └─→ 了解现有组件，避免重复开发
  │
  ├─→ 读取 rules/tech-stack.md
  │     └─→ 确认技术栈约束
  │
  └─→ 输出: 结构化 PRD + 技术可行性分析

2. dev-workflow-plan 如何使用知识库

dev-workflow-plan 命令:
  │
  ├─→ 读取 knowledge/api.md
  │     └─→ 遵循 API 调用规范生成代码
  │
  ├─→ 读取 knowledge/components.md
  │     └─→ 复用现有组件，遵循 CSS 变量
  │
  ├─→ 读取 rules/code-style.md
  │     └─→ 生成符合项目规范的代码
  │
  ├─→ 读取 rules/naming.md
  │     └─→ 遵循命名约定
  │
  ├─→ 读取 template/ (如有匹配模板)
  │     └─→ 基于模板生成代码
  │
  └─→ 输出: 符合项目规范的代码

3. archive 如何使用知识库

archive 命令:
  │
  ├─→ 读取 tech/ 目录
  │     └─→ 收集该需求的所有技术方案
  │
  └─→ 输出: 整合到 archive/ 目录
        │
        └─→ 归档文档成为知识库的一部分
              可被 RAG 搜索用于后续开发

命令介绍

1. workflow-init：知识库初始化

作用：

深度分析项目，生成完整的 `.workflow/` 知识库

使用方式：

# 基本用法
mcp__bgent__bili-fe-workflow-init


# 强制覆盖已有知识库
mcp__bgent__bili-fe-workflow-init forceOverwrite=true

执行流程：

支持的项目类型：

单项目：标准的单页应用
多项目：Monorepo、Vue 多页应用

2. knowledge-update：知识库更新

作用：

当项目代码变化后，增量更新指定的知识库文件

使用方式：

# 更新 API 文档
mcp__bgent__bfw-knowledge-update knowledgeFile=".workflow/knowledge/api.md"


# 更新组件文档
mcp__bgent__bfw-knowledge-update knowledgeFile=".workflow/knowledge/components.md"


# 更新全部知识库
mcp__bgent__bfw-knowledge-update knowledgeFile=".workflow/knowledge/index.md"

执行流程：

更新策略：

内置知识库：使用特定的分析指令，确保分析质量一致
自定义知识库：使用通用更新流程，根据文档内容确定分析范围

差异对比示例：

## 差异对比报告


### 新增内容 (New)
- [API] 新增接口: `GET /api/v2/user/profile`
- [组件] 新增业务组件: `UserAvatarUploader.vue`


### 修改内容 (Modified)
- [API] 修改响应结构: `getUserList` 返回数据路径从 `response.data` 改为 `response.result`


### 删除内容 (Removed)
- [API] 废弃接口: `GET /api/v1/user/old-list`


### 保持不变 (Unchanged)
- [API] 基础架构: Service Layer 模式保持不变

需求文档澄清

为什么需要预处理？

我们知道光有一个 PRD 是不足以直接开始需求的。原因有下：

PRD 是以产品角度对需求的描述，无法直接映射到代码模块
PRD 需要经过需求评审来进一步澄清补充
PRD 如果涉及到多个项目，前端PC、H5、后端，我们需要提取出当前项目的改动
前端开发还需要交互稿和视觉稿
前端开发需要后端的技术方案
其他问题

因此，只拿到一份 PRD 是完全不够的，我们还需要进行二次处理。当然，人工整理是完全ok的，但这需要花费我们较多的时间。相比人工，AI 可能更具以下优势：

AI 分析文档、分析代码的速度更快
据粗略统计，AI 编写的文档长度是人写的 >=7 倍，更加适合拿来作为 prompt
AI 能检测到一些人会忽略的模块

模仿我们自己开发需求的流程，产品出TAPD -> 需求评审对齐 -> 技术方案对齐 -> 写代码。其中需求评审是非常重要的，通过评审去明确一些不确定的需求点、对齐产品和技术上的理解差异。但问题是，往往需求评审讨论的内容，我们并不会落实到文档里，而是口头上的信息传递。为了让这一部分信息能让AI获取到，需要 prd-preprocess 命令。

命令介绍

命令的大致流程是：

需求文档、设计稿、接口文档收集 -> 代码涉及模块匹配 -> 代码现状和需求对比 -> 澄清 -> 落实文档。这其实是对产品出TAPD -> 需求评审对齐这一个步骤的AI化模仿，即通过拆分更加详细的步骤，让AI模仿真实开发的流程。

核心作用

/prd-preprocess 是一个需求文档预处理工具，帮助开发者将原始的产品需求文档（PRD、设计稿、技术方案）转换为结构化、可执行的开发 PRD 文档。

减少需求理解偏差
自动分析涉及的代码模块
提前发现需求中的问题和歧义
生成标准化的开发文档

使用示例

# 基本用法
/prd-preprocess


# 指定需求目录
/prd-preprocess prd/20251217-new-feature/


# 通过 @ 选择文件（自动识别父目录）
/prd-preprocess @prd/20251217-new-feature/original-prd.md

执行后生成的文件结构：

prd/20251217-new-feature/
├── README.md                           # 需求概览
├── clarification.md                    # 澄清记录
├── 20251217-new-feature-module-a-prd.md   # 子需求1
├── 20251217-new-feature-module-b-prd.md   # 子需求2
├── images/                             # 设计稿截图
│   ├── design-1.png
│   └── design-2.png
├── backend-api.md                      # 后端接口文档
└── original-prd/                       # 原始文档
    └── document.md

prd-preprocess 命令使用介绍

前置条件: 先安装 mcp tool @bilibili-business/mcp-server-sdk, 或者安装 Claude Code 插件 Fugue

在 Claude Code 中输入 /prd-preprocess 会出现命令选项，下图中：

第一个是我自己在当前项目下创建的命令：.claude/commands/prd-preprocess.md
第二个是我发布在 Claude Code 插件 Fugue 上的 command
第三个是我发布在 mcp 工具的 prompt

哪一个更好？这三个目前来说效果是一样的，我们也在对比探索 mcp vs plugin 的效果那个更好。目前，建议大家使用 mcp 的版本。如果大家看到前缀跟我的 'mcp-router:workflow' 不一样，不用担心，因为我本地安装了 mcp-router 来托管。有关 mcp-router 的使用见（todo）

阶段一：prd、技术方案、设计稿的资源获取

我们可以不带任何参数直接执行，工作流没有接收到任何的需求文档，会询问用户需要使用的需求应该存放在哪个目录。这个目录会作为工作流执行过程中，prd、技术方案、预处理生成最终文档的存放地址。默认情况下，会在项目/prd/20251217-xxx/ 目录下进行：

工作流会询问你是否有设计稿链接、技术方案文档：

我们再把准备好的技术方案贴过来，这里的演示没有 figma 设计稿。然后工作流就可以进入到下一步了：

阶段二：分析需求和代码

提取需求

工作流会先提取需求中与前端相关的功能点并整理出来。提取需求时，会按照以下四个方向进行：

界面改动：新增页面、修改现有页面、删除页面
功能改动：新增功能、修改功能、删除功能
交互改动：用户操作流程、状态变化、动画效果
数据改动：新增接口、修改接口参数、数据格式变化

这四个方向也是我们平时自己开发需求的时候，会从前端考虑的点。这符合工作流的两个原则模仿和拆解。

分析涉及代码

分析会从两个方向下手：

一个是会使用 mcp tool rag-knowledge-search 进行知识库的查询，如果此前有相同模块的需求改动，并且通过工作流生成过相关的 prd\tech\archive 文档，那么 rag search 能够快速定位到涉及模块。工作流和知识库可以互补完善。
使用 Explore Glob Grep 等工具直接进行代码筛查

同样的，生成最终模块时，也会拆分成不同的方向。这些方向基本上会涵盖到一个前端需求所需要的所有代码了。

主页面
相关组件
路由配置
API 接口
工具和类型定义

阶段三：需求澄清

在这一步中，工作流会对比 prd 和项目的代码现状，分别从：

完整性
一致性
明确性

三个角度来进行需求的澄清，这是非常重要的一步。我们需求将在需求评审时口头讨论的内容，明确的告知给 AI，只有这样，才能消除模糊，减少AI的幻觉产生。并且，AI 也能发现一些此前需求评审时没有讨论到的问题，通过澄清来补全。

其实站在前端的角度，有非常多的交互细节，产品都不会再prd里描述的，往往是我们自己哼哧哼哧开发完了，然后产品一看发现不好，然后再返工改。通过AI澄清明确性，能更早的把问题暴露出来，比如，下图中提到的，基本上全都是prd未明确的细节。

选择"自定义"后输入 X 天，X 的取值范围是多少？是否有最小值/最大值限制？
当用户从"等于"切换到"匹配"或"为空"时，已选择的枚举值如何处理？保留还是清空？

阶段四：需求拆解

整理澄清内容，生成 https://clarification.md 文档，并且拆分子需求。就像我们自己开发的时候，也不会一次性就把整个需求写完，而是会先写一块，再写另一块。对于AI来说也是一样，由于上下文的限制AI也不能一次性就将整个需求写完，通过将一整个大需求拆分成几个小型需求，能够让 AI 生成的更加准确。这也属于模仿和拆解的思路。

当然，我们可以自行修改拆解的范围，比如说我认为维度条件配置和指标条件配置可以一起实现，那么可以手动调整。

生成多份 prd 文档，并整理各个模块的依赖关系，给出后续开发建议。

智能开发工作流

在上一步需求文档澄清中中，我们将原始的 prd 整理拆分，一共拆分出了多个子需求 prd。接下来需要开始开发。

我们常规的一个开发流程一般是： prd -> 技术方案选型 -> 技术方案设计 -> 代码编写。一般来说，我们都是自己项目的负责人，对项目的很多细节比较熟悉，因此我们经常不会将技术方案选型 -> 技术方案设计落实成文档，而是在头脑风暴直接开始写代码。按照模仿+拆解的思路，我们将这个流程拆解成 AI 可以执行的流程，编排了智能开发工作流。

智能开发工作流主要是一个顶层工作流调度器，负责分析需求文档中的 Figma 解析策略，分三条路径执行，如下图所示

两大Skill的定位非常清晰，并且通过 d2c-logic-hints-generator进行衔接

D2C = 视觉驱动，设计稿 → UI 代码→ 逻辑补全提示
Dev = 逻辑驱动，需求 → 完整可运行代码

整体调用的Skill列表如下

D2C

核心理念

“设计驱动代码” — 从 Figma 设计稿自动生成高还原度的 UI 代码，将视觉还原工作自动化。

传统工作流分析

技能组成（6 个 Skill）

对于传统工作流进行拆解，实现设计稿分析和UI还原

七步流水线

这个阶段的产出是两样东西：可运行的 UI 代码和一份 logic-hints.md。UI 已经还原，但按钮点击事件是空的、接口调用是 mock 的、表单校验还没写——这些都被精确地标记在 logic-hints.md 中。

关键设计点

1) 并行 MCP 调用：所有 Figma API 调用在单条消息中并行发起，大幅缩短总耗时

2) 单 Task 批处理：组件识别和图标匹配各用一个 Task（子代理）完成全部项目，避免逐个启动子代理的开销

3) 预计算样式映射：figma-design-analyzer 在提取阶段生成 tw-to-css.json，code-generator 直接查表，不重复解析 Tailwind

4) 渐进式数据持久化：

.workflow/temp/d2c/[需求名]/
├── manifest.md          # 步骤5 确认后生成（防止上下文压缩导致丢失）
├── raw/                 # 原始 Figma JSON（完整备份，用于追溯）
├── extracted/           # 提取后的结构化数据（代码生成时按需读取）
│   ├── code.html, styles.json, components.json
│   ├── assets.json, tw-to-css.json
└── screenshots/

5) 子代理上下文隔离：D2C 在独立子代理中运行，完成后上下文自动释放，不污染主代理的上下文窗口

Dev

核心理念

“需求驱动，动态编排” — 分析 PRD 复杂度和特征，自动规划最优的 Skill 执行序列。

技能组成（7 个 Skill）

动态规划

Dev 的核心设计是 Step 0 的动态计划生成：对需求特征和其他输入进行分析-> Skill 选择 -> 用户确认，具体 SKill 动态选择规则如下

技术要点提取→学习→方案的三级流水线

这是 Dev 最核心的设计 — 三个 Skill 形成递进式知识构建：

设计精髓：

需求驱动过滤：只提取与当前需求相关的技术点，不过度学习
三级优先级（🔴🟡⚪）从提取阶段贯穿到学习阶段，控制学习深度
覆盖度校验：tech-architect 验证方案中使用的所有技术是否都已被学习，发现缺口则补学

3大执行策略

在full模式的执行策略下，两大子系统的协作关系如下

D2C Phase 1 生成 logic-hints.md 内容如下：

logic-hints.md 内容:
├── 已生成文件列表
├── 已完成项（UI骨架/组件配置/样式）
├── 待补全清单（API调用/事件处理/数据源/路由）
├── 已使用组件列表
└── 补全建议

Dev 根据logic-hints.md 内容进入逻辑补全模式，各个Skill的行为调整如下：

layout-only / none 策略下直接进入 Dev 标准模式，动态规划 Skill 执行序列。

自动化测试

使用流程概览

实现方案

完整工作流设计

Step1：调用测试工作流

调用测试工作流有多种方式(输入/找到 /bili-fe-test-workflow )，自然语言输入，可按需调整: 根据用户输入生成规范且详细的测试计划，包括frontmatter基本信息、执行要求、每个测试用例的基本信息（ones caseid(如果有的话)，初始URL, 前置条件(包含3A造数信息)，测试步骤(越详细越好，小学生也能按照步骤一步步点下去🤔)，预期结果等），常见使用举例：

商业部门需求正常可直接贴ones链接或者onesid, 如：

或者说："onesid:16751"
可额外 "@xxx-prd.md", "tech.md" 等
随意添加自定义要求，简单的需求也可以直接tapd/企微复制过来贴给工作流
第一遍生成后可按需调整修改，人工Review一遍，避免开始测试时ai走偏或找不到实际内容，以免浪费大量时间和Token

Step2：运行测试计划

当你觉得测试计划修改的比较详细且完善后，就可以让ai继续开始测试了:

Step3：生成测试报告

AI测试完可以让AI生成详细的测试报告以供校验追溯

Step4：生成Playwright测试脚本

然后可以基于之前的测试上下文生成playwright测试脚本, 项目playwright初始化可使用我们MCP里的"/bili-fe-test-workflow-setup"来快速初始化

Step5：测试脚本修复

生成脚本后，需要先本地运行测试脚本，AI调试/人工调试，跑通后就可以提交git了

Step6：UI自动化平台重复跑测试

代码提交后可以在UI自动化平台上跑跑看能不能通过，后续的需求、回归用例就可以定时重复的跑了

Step7：CI流水线配置

UI自动化平台接入成功后，就可以开始配置CI流水线，以便于在release前发MR时进行回归测试，提升上线稳定性

🔄 完整AI交互流程：

可选工作流程

以上为走完一个完整的测试工作流的过程，当然我们也可以根据实际情况按需跳过某些步骤，不同情况的适合场景（Ai在生成测试计划后，下一步之前会提示使用哪种模式）:

完整流程(传统)：适合用例在15个以内的场景，基本可以在可接受的范围内执行完
渐进式：AI测试完一个用例，立即生成测试脚本，并验证可运行性；以此循环进入下一个用例(一定程度上减少第一种方式的上下文丢失)
代码优先(适合vibe coding者)：基于plan直接生成完整的测试脚本代码，然后一个个运行并修复
对于50+用例的场景，建议跑一部分测试，生成脚本，调通后让AI依葫芦画瓢

复杂用例场景处理

1. 登录态解决

a. 本地

b. 平台

2. 用例前置数据准备

a. 已支付订单相关行为测试(3A造数)

后续迭代方向

基于上面的Plugin & Skill 探索分发测试工作流的各部分
减少AI测试的等待时间，提升生成测试脚本的准确性以及减少过程中的token消耗

AI Mock工作流

实现方案

核心优势

AI帮你完成配置：调用"/bili-fe-mock-workflow-setup"即可
无需额外代理软件配置，集成在你的前端项目里，且不影响业务代码
与你本地的AI Agent无缝集成，任意Mock逻辑(mock本身即代码)
3种模式任选：AI通过MCP动态添加(不改本地文件)，AI修改本地custom-handlers(gitignored), 基于Swagger

使用场景

适合在开发过过程中无实际接口时Mock
已有接口，但需要调整不同的数据返回来测试不同的UI场景
本地UI测试时，临时Mock一下
减少AI操作浏览器消耗的token
发挥你的想象力...🤯

使用方式

调用"/bili-fe-mock-workflow-setup"初始化
mcp_server_sdk 配置 "--enable-mock" arg，以及额外可选选项(刷新页面保留添加arg: "--mock-persist-handlers")
首次可以调用"/bili-fe-mock-workflow 你的mock需求", 不明确时AI会引导你使用哪种mock方式：

前2个直接开始mock, 当选择swagger时，会引导你使用定制的"/bili-fe-swagger-mock-workflow" 来完成swagger mock
后续的mock或者你已经很了解要怎么mock, 可以直接告诉AI要求，无需每次都调工作流

总结思考

过去一年的实践验证了方法论的有效性，但这只是开始。AI 时代的前端正在经历根本性的范式变革。过去我们依赖个人经验推动需求落地，未来则会更多依赖规范化的工作流、可复用的上下文资产，以及人与 AI 的协同生产机制。Harness Engineering 的意义，不只是提供一套更高效的开发流程，更是在团队内部建立一种新的工程共识: 先定义清楚问题，再约束生成过程，最后通过标准化验证确保结果可交付、可维护、可复用。

这意味着，前端工程师的价值正在从“单点编码产出”转向“问题抽象、方案设计、规则沉淀与质量把控”。谁能更好地组织需求、编排上下文、制定约束、验证结果，谁就能更有效地放大 AI 的能力。工作流的价值也不只体现在一次提效上，而在于它是否能够沉淀为团队能力，帮助更多同学以更低门槛、更稳定质量完成复杂交付。

因此，这份文档的目标不是给出一套固定答案，而是提供一个可实践、可迭代的起点。希望大家在使用的过程中，持续补充案例、沉淀模板、优化规则，把零散的个人经验逐步升级为团队共享的智能开发体系。这套体系一旦建立，提效就不再是偶发结果，而会成为组织层面的稳定能力。

-End-

作者丨梦园、远书

[4]https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html（https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html）

GPU隔离技术的分析与改进

Wed, 29 Apr 2026 12:00:00 +0800

原创通用工程 2026-04-29 12:00 上海

本文基于NVIDIA场景，通过分析阐述业内隔离技术方案，引出他们的优势与缺陷，进而提出B站在隔离技术上的改进思路。

一背景

随着AI技术的快速发展，对GPU的需求也日益增加；但是，在实际生产环境中，受限于业务的模型特点及SLA等，GPU利用率普遍比较低，硬件算力被严重浪费。在这种情况下，GPU隔离能力对于最大化利用硬件资源就至关重要，本文基于NVIDIA场景，通过分析阐述业内隔离技术方案，引出他们的优势与缺陷，进而提出B站在隔离技术上的改进思路。

二隔离思路

2.1 两种维度

如图1所示，假设有A、B、C这3个不同模型大小的任务在GPU上混跑。在空间维度上，一次调度上GPU运行的任务，并不能充分利用全部的GPU资源，GPU资源的饱和度利用不高。在时间维度上，多个任务之间交替运行，存在切换和等待开销，所以在实际使用时，为了保障业务的SLA，对于延迟敏感的高优业务就需要独占GPU资源，GPU利用率就会比较低下。

^{图1 GPU运行示意图}

为提升 GPU 资源利用率，可以从空间和时间两个维度切分GPU算力资源来实现多任务的高效并行与资源复用。

在空间维度上切分算力，即空分方案，该方案着眼于在GPU资源核心的极致挖掘，通过实现多个任务并行运行，目的是充分利用图1中的idle部分的算力，提升GPU资源的饱和度利用。这种方案往往由硬件厂商实现，通常为各种虚拟化方案，这类切分往往是静态的，不同虚设备之间无法共享资源，容易出现资源浪费，并且实现通常是黑盒的，难以根据业务实际需求进行适配。

在时间维度上切分算力，即时分方案，该方案聚焦于任务的时间管理，通过对时间片的拦截，有效地减少任务切换所需要的等待时间，从而保障业务Qos的高标准。由于弹性特质，相对于空分方案，能更好的利用空闲资源，但官方往往不提供这类解决方案，或提供的方案很难产品化，因此，业界通常需要自主开发相应的解决方案。

2.2 CUDA计算软件栈

为了理解下文业界隔离方案是怎么实现的，我们需要先掌握整个资源分配过程中，都会涉及哪些软件栈。

^{图2 cuda计算软件栈}

如图2所示，CUDA计算主要包括以下几个方面：从顶层的应用程序开始，依次经过CUDA库（包括CUDA RUNTIME和CUDA DRIVER层），再到底层的内核驱动，最终到达GPU硬件本身。在此架构中，

用户层：包括应用程序和CUDA库，其中CUDA API细分为两个主要层次^[1][2]：

CUDA Runtime API: higher-level抽象层，通过cudart动态库提供，其所有入口点都以cuda为前缀，易于使用，为CUDA开发者在编程时提供了便利。
CUDA Driver API: low-level，通过 cuda 动态库提供，其所有入口点都以 cu 为前缀，提供了更精细的控制，尤其是对上下文和模块加载的控制。

内核层：主要就是NVIDIA GPU的驱动程序，负责管理GPU资源，处理与操作系统的交互，并提供基本的硬件抽象；
硬件层：主要就是NVIDIA的GPU硬件，它提供了并行处理能力。

从API库到最终的GPU硬件，每一个阶段的转发都有被拦截的可能性，于是，业界基于上述的计算软件栈，实现了各式各样的GPU隔离共享方案。

三业界方案

目前空分方案主要是NVIDIA提供的MPS和MIG方案，时分方案主要是以CUDA劫持方案和内核拦截方案为主，以下简要介绍下几种方案上的区别。

3.1 NVIDIA官方

NVIDIA提供了一些黑盒逻辑的隔离功能，其中，针对容器共享GPU的技术，以MPS和MIG相对比较常见。

3.1.1 MPS

通常在GPU上执行多个任务时，采用的是”单任务”的工作模式，即同一个时刻只有一个任务（用不同的context区分）在GPU上执行。MPS技术则通过整合多个任务的CUDA context至一个CUDA context，这些任务共享GPU算力，共同使用显存，据此充分利用GPU资源。原理示意如图3所示^[3]：

^{图3 MPS原理示意图}

但是，由于是多个任务context的整合，一个任务失败，不免会影响到其他任务，存在故障传播的问题，并且由于是黑盒逻辑，故障诊断也是一个难题。

3.1.2 MIG

自NVIDIA A100系列GPU起，引入了MIG（Multi-Instance GPU）技术，它实现了硬件级别的空间分割复用和隔离。如图4所示^[4]，MIG允许将单个GPU分割成多个独立的实例，每个实例拥有自己的资源配额，从而在硬件层面上实现了资源的隔离。

^{图4 MIG原理示意图}

然而，这项技术存在一定的局限性，首先，并非所有型号的GPU都支持这一功能，仅在一些高端的GPU上提供支持；其次，MIG最多仅支持7个独立实例的创建，这限制了MIG在更多实例数量的场景中的应用；并且，GPU资源的切分是静态的，一旦GPU资源被分配给某个任务，就无法在运行时更改这些资源的分配，缺乏灵活性。

3.2 CUDA 劫持

CUDA劫持方案发生在CUDA Runtime和CUDA Driver之间，通过劫持对CUDA Driver API的调用来做到资源隔离，例如，腾讯早期开发的GaiaGPU方案^[5]^[6]。这类方案在算力隔离方面，在launch kernel时，会评估这次内核发射对GPU使用率的影响。如果发现该kernel会使得GPU使用率超标，则推迟下发kernel运行的API，直到 GPU 使用率下降至允许本次 CUDA kernel 的运行之后，据此达到算力隔离的目标。

^{图5 GaiaGPU架构图}

由于API的功能是公开的，通过劫持特定调用，可以简单的拒绝或延后任务对于资源的申请行为，但这里存在两个问题，一是算力消耗缺乏反馈机制，依赖轮询造成浪费，二是申请下发后便失去了控制权，容易超算力配额引入误差。

3.3 内核拦截

内核拦截发生在Cuda driver API和Nvidia Driver之间，也是业界比较成熟的方案。不管是腾讯的qGPU^[2]、阿里的cGPU^[7]、还是百度的GPU隔离方案^[8]，在实现上基本是类似的。如图6，以百度的隔离方案为例：

^{图6 百度双引擎GPU虚拟化内核态原理图}

具体拦截设计如下：

在没有拦截驱动的时候, 用户程序APP->CUDA RUNTIME->CUDA DRIVER，底层库通过设备文件来访问真实的设备驱动；如图6，是通过GPU驱动的提供的设备如/dev/nvidia0来访问驱动的。
做了拦截之后，可以提供假的设备文件（/dev/gpu0)。有了假的设备文件，APP调用时会进入到拦截驱动里，拦截驱动就会把对GPU的访问进行一个拦截，解析信息，然后再把访问发给真实的GPU驱动，GPU处理完之后，再做一次拦截，把信息做解析和修改，注入给APP。

该方案需要深入理解CUDA和GPU之间交互的方式，并对其中的关键参数进行修正，但该交互行为本身是黑盒，版本迭代后还可能会失效，并不易于维护。

四内核隔离方案

在分析了B站的业务场景后，我们发现具备弹性能力的时分方案最为合适。然而纵观业内，官方没有提供这类手段，非官方的劫持方案又由于黑盒问题，存在各种隐患，一度让我们陷入困境，最终NVIDIA驱动的开源为我们打开了新的思路。

相对于各类劫持，直接在驱动层进行参数和结果的修正，无疑是更加透明和高效的。通过分析驱动代码，结合GPU运行原理知识，我们验证了这条路径是可行的，并基于此设计实现了一套内核隔离方案，完美契合了B站业务场景的需求。

接下来我们将从NVIDIA开源驱动出发，解析GPU运行机制，并和大家分享一下我们内核隔离方案的设计思路。

4.1 驱动视角

根据驱动代码及相关文献^[10][11][12]，我们可以从驱动角度上展示CUDA任务到GPU上运行的详细过程，如图7所示：

^{图7 多个GPU程序混跑运行机制}

GPU 内部由多个功能单元组成，在驱动中称为 Engine，主要包含：

Compute/Graphics Engine：包含通用处理核心，负责 CUDA 计算和图形渲染；
Copy Engine：专门处理 GPU 与 CPU 之间的异步数据拷贝；
NVENC/NVDEC Engine：用于视频编解码等特定任务等。

GPU Host 是 CPU 与 GPU 之间的桥梁，由 runlist processor 和 context switcher 组成：

runlist processor 负责扫描 runlist，选择下一个待运行的 channel
在选择 channel 后，如果该 channel 的 context 与当前正在运行的 context 不同，就需要 context switcher 执行上下文切换操作。

具体调度流程如下：

1) 从驱动角度看，为了向 GPU 提交计算或数据拷贝等请求，会为每个程序创建一个或多个 channels；

2) 这些 channels 被组织到 TSG（Time Slice Group）中，同一 TSG 内的 channels 共享相同的 GPU context 信息；

3) TSG会根据分配的Engine type找到自己的runlist

4) GPU Host 通过读取runlist以查找下游Engine要完成的工作，具体地，GPU HOST识别到有待处理命令的channel，会从相应runlist上按照时间片轮转的方式摘取一个TSG，再从TSG选择相应的channel，将其调度到特定的Engine上运行。

5) Engine 执行 channel 中提交的命令，完成计算或数据拷贝任务。

根据我们在x86_64的A10机器上的trace结果来看，会为一个常见的CUDA程序默认创建共16个channels，3个TSG以及3个runlist。其中，8个计算的channels会被加到一个TSG，这个TSG默认分配Compute/Graphics Engine；8个用于数据拷贝的channels会被分别加到两个TSG中，分别对应两种COPY Engine。A10卡上默认的映射如表1所示：

_{表1 A10机器CUDA程序映射关系}

每种Engine会被绑定到一个runlist，在A10机器上，CUDA程序用到的Engine和runlist的对应关系，通常如表2所示：

_{表2 A10机器上Engine类型和runlist对应关系}

在表2中，Timeslice指代了runlist中每个条目（即TSG）一次调度默认最多可执行的时间。以runlist0上的TSG为例，时间片为2ms，即在不发生抢占的情况下，runlist0上一个TSG调度到Compute/Graphics Engine上，默认最多可运行时间为2ms。这意味着，只有TSG用完了2ms的时间片或者TSG在2ms以内就执行完了，TSG之间才会发生调度切换。

由此可知，在单个GPU上跑混多个任务时，TSG之间的切换以及上下文切换是影响任务延迟的主要因素。

4.2 隔离设计

4.1节主要阐述了驱动在算力资源方面是如何进行管理的，在定位到驱动代码的具体实现后，就可以对下发到设备的显存和算力请求做出调整。我们引入bilibili GPU Manager（以下简称BGM）内核模块来联动Cgoup子系统和显卡驱动实现隔离。

显存隔离的设计原理框图，如图8所示：

^{图8 bilibili gpu manager显存隔离设计框图}

具体地，显存隔离步骤如下：

1）用户通过cgroup接口配置显存信息，用于限制业务可用的显存上限，记为limit；

2）当驱动在获取设备可用的显存总量信息时，会调用BGM模块的显存限制API获取用户配置的limit，得到一个假的显存总量；

3）在获取设备剩余可用显存信息时，会调用BGM模块显存剩余API，更新limit在不断分配之后的剩余显存量，记为left；

4）在驱动分配显存时，会先判断剩余显存量left是否满足本次分配size要求，满足要求则进行分配，不满足则报NO MEMORY;

5）每次显存的分配和释放，都将通过分配统计和释放统计API计入任务组的显存使用，记为used。

基于此，达到显存隔离以及cgroup统计显存使用的目标。

算力隔离的设计原理框图，如图9所示：

^{图9 bilibili gpu manager算力隔离设计框图}

具体地，算力隔离步骤如下：

1) 用户通过cgoup接口中配置算力（slice）信息；

2) CUDA程序运行时，经驱动调用相关方法设置TSG的时间片时，会调用BGM模块的时间片限制API获取用户通过cgoup接口配置的slice，用这个slice替换默认的时间片，作为TSG的时间片；

于是，用户通过配置slice，就可以控制TSG调度上Engine一次可执行的时间片上限，据此达到算力隔离的目的。

举个例子说明本隔离方案在算力隔离方面可以达到的效果，假设存在3种业务在一张GPU卡上混跑，并且业务对应的TSG都能跑满2ms。那么，不同时间片配置下的业务切换示意如图10所示：

^{图10.1 默认2ms业务切换示意图}

^{图10.2 时间片1ms业务切换示意图}

^{图10.3 不同时间片业务切换示意图}

^{图10 不同时间片配置下应用切换示意图}

如图10.1所示，在默认（无算力隔离）情况下混部多个业务，一个任务用完了2ms的时间片，才会切换到另一个任务。计入上下文切换损耗的时间，那么，APP0业务至少要等4ms才能再次被调度执行。如果GPU上混部更多个业务，等待的时间将会更长。

如图10.2所示，同样是均分算力，但是通过隔离手段限制TSG的时间片为1ms，即这些应用一次调度最多可运行1ms，那么，相较于默认情况，APP0业务得到再次调度的等待时长将会减半。

如图10.3所示，不均分算力，通过隔离手段，限制APP0对应TSG时间片为4ms，APP1和APP2的为1ms，即APP0一次调度最多可运行4ms，APP1和APP2最多可运行1ms。通过给高优任务大的时间片，低优任务小的时间片，一方面可以实现让高优任务尽可能在一个时间片完成任务；另一方面，也可以减小高优任务等待切换的时间；这样，可以有效地提升高优任务的性能，并减小受干扰程度。

这样，用户可以根据实际需求合理分配不同业务的时间片，达到切分算力和保障高优的目标。

4.3 效果验证

针对TensorFlow的一个benchmark^[13]，resnet50模型，我们在A10卡上对不同的batchsize，做了如下测试：

混跑2pod

算力比为1:3，两个pods的吞吐比如图11所示：

^{图11 不同算力2pods混跑的Qos表现}

混跑4pod

算力比为1:2:3:4，不同算力pods的吞吐信息如图12所示：

^{图12 不同算力4pods混跑的Qos表现}

如图11和图12所示，配置2个不同算力的pods(1:3)进行混跑，吞吐比在不同batchsize的情况下，基本都在理论值3附近；配置4个不同算力的pods(1:2:3:4)进行混跑，吞吐比在不同batchsize的情况下，表现和算力配置基本一致。

在后面做了平台化适配之后，我们也上实际业务进行了相关验证，总体可以满足GPU混部隔离的需求。

五总结与展望

本文探讨了NVIDIA GPU结合CUDA计算在实际生产中面临的利用率低下问题，并介绍了一系列基于CUDA软件栈的隔离共享解决方案。特别地，bilibili GPU Manager项目借助NVIDIA驱动开源的优势，通过BGM模块联动Linux内核和NVIDIA驱动，成功实现了算力和显存的精细隔离。通过调整Time Slice Group的时间片配置，可优化多业务场景下的任务等待时间，保障多个业务在GPU上混部的运行性能。

bilibili GPU Manager虽然在内核层实现了隔离，但该方案本质上还是时分复用，高优任务对离线业务的抢占，还是会有所受限，同时不同任务的切换也存在损耗。然而，一方面，随着NV驱动的进一步开放，在抢占模式以及interleave Frequency等细节上可以继续深挖，做到更细致的隔离；另一方面，如果对延迟实在比较敏感，也可以同时在用户态同时做一些调度策略上的调整，做到更好的隔离效果。

通过该项隔离技术，我们希望在GPU混部中能够做到更可控、更灵活的应对不同的业务环境。由于CUDA内部的某些逻辑并不透明，文中阐述不当之处，欢迎业界专家提出宝贵意见和纠正，也请大家继续关注我们的进展~~

六参考文献

[1] CUDA Toolkit Documentation 12.4 Update 1（https://docs.nvidia.com/cuda/index.html）

[2] GPU虚拟化，算力隔离，和qGPU - 知乎（https://zhuanlan.zhihu.com/p/377073683）

[3]Multi-Process Service :: GPU Deployment and Management Documentation（https://docs.nvidia.com/deploy/mps/index.html）

[5] J. Gu, S. Song, Y. Li and H. Luo, "GaiaGPU: Sharing GPUs in Container Clouds," 2018 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Ubiquitous Computing & Communications, Big Data & Cloud Computing, Social Computing & Networking, Sustainable Computing & Communications (ISPA/IUCC/BDCloud/SocialCom/SustainCom), Melbourne, Australia, 2018, pp. 469-476, doi: 10.1109/BDCloud.2018.00077.

[6] GitHub - tkestack/vcuda-controller（https://github.com/tkestack/vcuda-controller）

[7] GPU容器共享技术cGPU的优势及架构_GPU云服务器(EGS)-阿里云帮助中心（https://help.aliyun.com/zh/egs/what-is-cgpu）

[8] https://xie.infoq.cn/article/64df7b9a6606c139753658758

[9] https://github.com/NVIDIA/open-gpu-kernel-modules

[10] https://nvidia.github.io/open-gpu-doc/manuals/ampere/ga100/dev_ram.ref.txt

[11] J. Bakita and J. H. Anderson. Demystifying NVIDIA GPU Internals to Enable Reliable GPU Management[J].

[12] S. H. Duncan, L. V. Shah, S. J. Treichler, D. E. Wexler, J. F. Duluk Jr, P. B. Johnson, and J. S. R. Evans, “Concurrent execution of independent streams in multi-channel time slice groups,” U.S. Patent 9,442,759, Sep.,2016

[13] GitHub - tensorflow/benchmarks: A benchmark framework for Tensorflow（https://github.com/tensorflow/benchmarks）

-End-

作者丨糖冬青

世界知识产权日 | 2026年度哔哩哔哩技术专利评选结果出炉！

Fri, 24 Apr 2026 12:05:00 +0800

原创哔哩哔哩技术 2026-04-24 12:05 上海

10项优秀技术专利火热出炉！

哔哩哔哩技术

2026年4月26日是第24个世界知识产权日，每年4月20日-4月26日是全国知识产权宣传周。

在这期间，哔哩哔哩公司内部发起了2026年度哔哩哔哩技术专利投票活动。最终根据票选结果决出10个优秀技术专利。

我们希望可以通过本次活动加强B站同学对于知识产权的认知和投入，同样B站也会在中国向知识产权强国迈进的征程中，勇担使命，发掘潜能，创造不凡。

2026年度哔哩哔哩技术专利评选

直播互动玩法面板热更新

将第三方互动程序的更新面板发送至开放平台，生成地址并进行更新通知，观众端通过刷新页面获取更新面板，在主播不重启直播间的情况下动态更新互动玩法面板内容。

基于时间片分割统计违规时长

存储多个主播各自关联的违规时间点，根据主播标识和时间区间计算违规时长，减少服务器维护历史违规数据的负担，支持主播实时查询违规时长以及任务实时进度。

AI经纪人资源匹配系统

通过多智能体的分工协作，自动完成资源匹配请求的意图识别、候选筛选、交互谈判和进度监控全流程，实现AI驱动的经纪人业务自动化，大幅提升资源匹配效率与准确性。

结合异常指标与观众反馈的直播间巡检

根据秒退率、互动量等指标的趋势，筛选出潜在异常直播间，根据潜在异常直播间的观众反馈信息（如弹幕、问卷）进一步确定异常直播间，提高了异常直播间的处理效率和准确性。

代码知识图谱构建系统

在代码提交中绑定需求文档URL，自动解析产品需求文档并进行语义匹配，构建代码知识图谱，解决了代码与需求文档的语义隔离问题，提升了研发效率和上下文理解，支持需求变更影响分析和历史记录推荐。

智能服务快速封装与跨端调用

获取待接入服务的服务描述内容，基于结构化规范信息注册交互封装接口，并利用大语言模型进行自动化调用，支持对用户自然语言请求的解析和响应，实现快速、安全的服务接入和调用。

多模态大语言模型检测广告

获取视频的图像帧和音频数据，提取文字内容、音频文本信息和画面内容的文本摘要，利用预设学习模型进行时间对齐后输入前述信息以识别广告，从而实现结合场景切换点进行准确切分并通过大语言模型进行语义级广告识别。

RAG检索增强的测试用例自动生成

从待测需求中提取功能点和特征，通过多维度检索词召回相关历史测试用例，结合业务目录匹配的测试模板自动生成目标测试用例，显著提升RAG检索召回率和测试覆盖率。

多模态回归模型的封面质量评估

融合封面图像内容、用户观看行为及上传者与观看者关联度，通过多模态动态回归模型生成综合评分，引入关联度修正因子，实现视频封面质量的客观评估。

基于ASR与LLM的视频搜索方法

通过获取查询文本，基于查询文本和预设视频库中视频的元信息和文本内容，利用ASR和LLM进行稀疏密集检索，生成相关性高的搜索结果，快速提供精准的搜索结果，提升了用户体验。

*注：以上排名不区分先后顺序。

以上是2026年度哔哩哔哩技术专利评选活动中获奖的十组专利项目，你pick哪一组呢？

哔哩哔哩技术一直致力于提升公司技术氛围，鼓励公司员工进行技术创新，期待下一年有更多的专利项目大放异彩。

ICLR 2026 ｜用“信息增益-冲突惩罚”把数据选择做成可控的大模型微调加速器

Tue, 14 Apr 2026 12:06:00 +0800

原创 AI 2026-04-14 12:06 上海

指令微调（Instruction Tuning）已经成为大语言模型落地前的“最后一公里”。

前言

指令微调（Instruction Tuning）已经成为大语言模型落地前的“最后一公里”。在这一阶段，我们通常使用大量 (指令，回复) 样本对模型进行再训练，让模型更擅长对话、执行任务，并更符合人类偏好。

但一个越来越常见、也让算法团队颇为头疼的现象是：数据并不是越多越好。

在真实的指令数据池中，冗余样本、噪声数据、格式不一致以及任务类型混杂都非常普遍。更反直觉的是，越来越多的研究发现：只使用 10%–20% 的训练数据，模型效果就可以接近甚至超过使用全部数据训练的结果。这意味着一件非常重要的事情：更大的微调数据规模，并不一定带来更好的模型效果。相反，当数据规模不断扩大时，训练成本迅速上升，而样本之间的相互干扰反而可能拖慢模型学习。因此，一个非常自然的问题出现了：如果我们能从大数据池中挑选出一小部分“最有价值”的样本，是否可以用更少的数据训练出更好的模型？

近年来，学术界提出了一条非常优雅的思路：利用 Fisher 信息矩阵（Fisher Information Matrix, FIM） 来衡量每个样本能够为模型参数提供多少“信息量”。直观来说，如果一个样本的梯度能够为参数更新提供更多独立信息，那么它就更值得被选入训练集。

基于这一思想，可以通过最大化

这样的信息体积指标来选择数据子集。这个目标函数具有一个非常漂亮的性质——次模性（submodularity）：意味着即使使用简单的贪心算法，也能获得接近最优解的理论保证。

然而，在实际工程中，我们经常会看到另一面。当仅依据 Fisher 信息进行贪心选择时，边际信息增益往往会非常快地衰减：随着选择过程继续进行，新加入样本带来的信息越来越少，最终导致数据子集的质量不稳定，下游模型效果也会出现波动。

进一步分析后，我们发现，一个被忽略的重要因素是：样本之间的梯度冲突（gradient conflict）。简单来说，不同样本在训练时会产生不同方向的梯度更新，如果这些更新方向彼此不一致，甚至互相对抗，那么即使每个样本单独来看都“信息量很高”，它们组合在一起时，也可能互相抵消，从而加速信息增益的衰减。

从更广义的角度看，数据选择其实包含两个层面的关系：

一是 样本与模型之间的关系——每个样本能为模型参数带来多少有效信息；

二是 样本与样本之间的关系——不同样本在训练过程中是相互协同，还是彼此冲突。

过去的大多数方法主要关注第一点，而我们的工作则尝试把这两个关键因素联系起来：在最大化样本信息量的同时，显式建模样本之间的梯度冲突。

我们的论文 SPICE（Submodular Penalized Information-Conflict Selection） 正是为了解决这个问题。该论文已被 ICLR 2026 接收（arXiv:2601.23155）。

SPICE 的核心思想是：在保持 Fisher 信息最大化 这一理论框架的同时，把 样本之间的梯度冲突（gradient conflict） 也纳入数据选择目标。

这样一来，算法在选择样本时不仅考虑“信息量有多大”，还会考虑“这些信息是否彼此一致”。

最终的效果是：在不牺牲 次模贪心算法效率 的前提下，我们能够选出 信息量更高、冲突更低 的数据子集，让 10% 的数据真正训练出接近甚至超过全量数据的效果。

^{图1：边际信息增益 Δ 衰减越慢，同等预算下累计信息越大；实证上低冲突子集往往衰减更慢，信息更“耐用”。}

动机：为什么 Fisher 贪心

会越选越没用？

在 Fisher 视角下，数据选择可以理解为一个非常直观的问题：每个样本都会产生一个梯度信号，告诉模型参数应该往哪个方向更新。

设第 i 个样本产生的梯度为：

如果我们选择一个数据子集 S，那么对应的经验 Fisher 信息矩阵可以写成：

直观来说，这个矩阵描述的是：这些样本一共为模型参数提供了多少“可学习的信息方向”。

常见的数据选择目标是最大化以下信息量：

这个目标函数具有一个非常好的性质：次模性（submodularity）。简单理解就是——越往后选择新样本，能够带来的新增信息通常会越来越少。因此，使用简单的贪心算法逐步选择样本，理论上就能得到接近最优的结果。但在真实的指令微调数据上，我们却经常观察到一个现象：

边际信息增益并不是“平滑下降”，而是会出现“断崖式掉速”。换句话说，在选择到某个阶段之后，新加入的样本几乎不再提供新的有效信息，对模型训练的帮助也变得非常有限。

这显然超出了经典次模理论所描述的“渐进递减”行为。

针对这种实践问题：SPICE 的关键观察是：这种“边际信息断崖式衰减”，往往会与 gradient conflict（梯度冲突） 同步出现。所谓梯度冲突，指的是不同样本在参数空间中产生方向不一致甚至相反的更新信号。当这种情况发生时，就会出现一种现象：单个样本的信息量看起来很大，但它们提供的新方向却很少。结果就是：Fisher 信息仍在增长，但真正可累积的有效信息却越来越少。于是，贪心算法的边际增益会被迅速“消耗”，导致后续选择的样本对训练几乎没有帮助。

基于这一观察，我们重新审视了 Fisher 数据选择的机制，并提出了三个关键问题：

Fisher 的边际信息增益到底由哪些项决定？
其中哪些项在实际数据中会被梯度冲突放大，从而导致增益快速衰减？
如果冲突确实是关键因素，能否把它做成一个可测量、可控制的惩罚项，并直接加入到贪心选择中？

回答这些问题，正是 SPICE 方法设计的出发点。

方法：SPICE = 信息增益 − 冲突惩罚

SPICE 的核心思想其实非常简单：在 Fisher 信息最大化的基础上，引入一个“梯度冲突惩罚项”。

这样，算法在选择样本时不仅会考虑 信息量有多大，还会考虑 这些信息是否彼此一致。

从方法设计的角度看，SPICE 的思路可以概括为三步：

把 Fisher 的边际信息增益拆解，找出真正导致增益衰减的因素；
用一个工程上可计算的指标度量梯度冲突；
在原有 Fisher 贪心算法上加入一个“软惩罚”，并配合自适应早停和 proxy 选择机制。

下面我们依次来看。

1.边际增益的分解：衰减来自交互项

在 Fisher 贪心选择中，我们关心的是每个候选样本的边际信息增益：

SPICE 的第一步，是把这个增益拆解为两部分：

直观理解：

第一项（base）只反映这个样本本身的梯度强度，也就是它单独能提供多少信息。第二项（interaction）描述这个样本与当前已选集合 S 的交互影响。

关键在于：真正导致信息增益快速衰减的，其实是这个交互项。

当当前集合已经覆盖了相似的梯度方向，或者不同样本之间存在方向冲突时，新样本能够提供的“新方向信息”就会迅速减少。

2.冲突度量：用平均梯度方向做代理

既然交互项与梯度方向有关，一个自然的问题是：如何高效度量样本之间的梯度冲突？

如果直接计算所有样本两两之间的关系，计算成本会非常高。

SPICE 采用了一种更工程友好的近似方法。我们维护当前集合的平均梯度方向：

然后用余弦相似度衡量新样本与当前更新方向的对齐程度：

冲突则定义为：

这个度量非常直观：

同方向（对齐）：不惩罚
反方向（冲突）：产生惩罚
计算复杂度低：只需要对每个候选样本计算一次

因此在大规模数据池中也可以高效运行。

^{图2：论文展示冲突统计量与边际增益衰减/交互项之间存在系统相关性，为“用冲突解释掉速”提供证据。}

3.冲突感知贪心：不丢信息，只降低冲突

在得到冲突度量之后，SPICE 对原有 Fisher 贪心做了一个非常克制的修改：

其中：

●：信息增益

●：梯度冲突

●：冲突惩罚强度

我们特别强调，这是一种软惩罚（soft penalty）。

这意味着：

如果一个样本信息量很大，即使存在冲突，仍然可能被选中
算法只是降低冲突样本的优先级，而不会直接删除

这是因为在真实数据中，确实存在一些信息量很高但梯度方向不稳定的困难样本。如果简单过滤掉它们，反而会损失数据覆盖度。

4.自适应早停：边际增益不值得时就停止

传统数据选择通常会预先设定一个固定预算 k，比如选 10% 数据。

SPICE 则采用一种更灵活的策略：根据边际增益的衰减情况自动停止选择。

具体来说，当第 t 步的最优边际增益满足：

算法就会停止。

直觉上，这相当于在：“新增样本的性价比已经明显下降”时及时刹车。

这样可以避免把预算浪费在信息增益很低的尾部样本上。

5.Proxy 选择：让选择成本可控

最后一个工程问题是：在大模型上计算所有样本的梯度本身就很昂贵。

SPICE 的解决办法是：

使用同架构的小模型作为 proxy 来计算梯度
用合理的更新间隔来减少重复计算

这种方法利用了一个经验观察：数据选择模式在不同规模模型之间往往具有可迁移性。

因此，我们可以在小模型上完成数据选择，再把选出的子集用于大模型训练，从而实现：

选择成本可控，同时保持效果。

实验结果：只用约 10% 数据，

也能匹配甚至超过全量微调

为了验证 SPICE 的效果，我们在约 97.5K 条指令数据上进行了系统实验。数据覆盖多个典型场景，包括：

数学推理任务
代码生成任务
通用指令跟随任务

在模型设置上，我们使用 LLaMA2-7B 和 Qwen2-7B 作为基座模型，并与多种主流数据选择方法进行了对比实验。

实验结果可以总结为两个核心发现。

1. 梯度冲突确实解释了信息增益“掉速”

实验分析发现，当数据选择序列中的 梯度冲突更低 时，会出现两个明显变化：

边际信息增益衰减更慢
累计 Fisher 信息更大

换句话说，如果样本之间的梯度方向更加一致，新的样本就更容易提供“真正的新信息”。

而当冲突较高时，不同样本会在参数空间中产生相互抵消的更新，导致信息增益被快速消耗，从而出现我们在实践中常见的 “越选越没用” 的现象。这一观察与 SPICE 的理论分析高度一致。

2. SPICE 让“小数据”真正变强

在仅使用 约 10% 的训练数据 时，SPICE 选出的数据子集在多个 benchmark 上：

能够匹配甚至超过全量数据微调的效果
同时 显著降低训练成本

这意味着，通过合理的数据选择，小规模高质量数据集可以替代大规模原始数据，从而实现 更高的数据效率和更低的训练成本。

^{表1（Qwen2-7B/LLaMA2-7B）：在仅用 10% 指令数据时，SPICE 在 GSM8K/MMLU/IFEval/HumanEval 等多类基准上整体优于多数选择基线，平均分也超过 Full/Random 等对照}

一个有意思的现象出现在训练动态中：

SPICE 选出的数据子集往往“起点更难”（初始 loss 更高），但训练下降得更快、也更稳定。

这与 SPICE 的选择机制非常一致——它更倾向于选择 信息量更高、同时彼此不发生梯度冲突的样本序列。这些样本虽然更具挑战性，但能够为模型提供更加一致和有效的学习信号。

总结

SPICE 的核心贡献，并不是再提出一个复杂的数据选择算法，而是把一个长期存在却常被忽视的问题讲清楚，并给出一个简单而可落地的解决方案。

具体来说，这项工作做了三件事情：

从理论上，我们指出 Fisher 次模目标中常见的“边际信息增益快速衰减”，实际上来自样本之间的交互项，而不仅仅是经典次模理论中的“递减收益”。
从经验上，我们进一步发现，这个交互项与 梯度冲突（gradient conflict） 之间存在稳定的统计关联——当样本之间的梯度方向冲突更少时，信息增益的衰减也会明显变慢。
从算法上，SPICE 用一个非常克制的方式改造了传统的 Fisher 贪心选择：通过在目标函数中加入 “信息增益 − 冲突惩罚” 的简单结构，并配合 自适应早停 和 proxy 选择机制，使这一方法能够在真实的大规模指令微调场景中高效运行。

对于正在进行 指令微调加速 或 数据治理 的团队，这项工作带来的启发是：数据选择不仅要挑“信息量大的样本”，还要避免选择那些彼此“互相拆台”的样本。当我们把样本之间的冲突关系也纳入选择目标时，小规模的数据子集也能够更加稳定地把信息转化为真正的训练收益。

-End-

作者丨争气尾流、zbw

使用Compose Navigation3进行屏幕适配

Fri, 03 Apr 2026 12:02:00 +0800

原创大前端 2026-04-03 12:02 上海

这篇文章将介绍B站是怎么使用 Compose Navigation3 进行页面的宽屏适配，并解决其中遇到的问题的。

本文所涉及到的 Compose 页面均已完成了 CMP 跨平台化适配，内容中基于安卓习惯所提的 “Activity” 如无额外说明均代表各平台的页面容器，即可以直接替换为iOS的UIViewController理解。

Navigation3 简介

Navigation3 是 Google 在 2025 年推出的全新 Compose 导航库，与之前的 Navigation Compose 有本质区别。它不再内置导航图（NavGraph）和 NavHost，而是将导航栈的管理权完全交给开发者，框架只负责"根据栈内容渲染 UI"，将 f(data)=UI 的理念扩展到了页面导航栈上。得益于这新的精简的框架概念，使得 Navigation3 能很轻松地跟现有大型app的路由系统搭配整合使用，不像之前的 Navigation 库那样需要将现有路由完全迁移到导航图（NavGraph）声明上。开发者完全可以在单模块内进行 Nav3 的接入使用，同时保持整体的路由声明方式。

虽然使用Compose编写的页面，因其声明式的特性，已经有良好的响应屏幕宽度变化的能力。但是近期出现的超宽、折叠屏手机，包括鸿蒙平台的平板、桌面等设备，会让仅支持响应式布局的页面在超宽显示模式下给用户带来不好的视觉和交互体验。与Navigation3 库同时提出的“WindowSizeClass”中，将屏幕根据宽度划分为小、中、大等各个档位。这种“断点式”的屏幕划分可以指导我们知道在怎么样的情况下将应用的界面显示编排成全屏页面还是分屏页面的形式，显著提高在折叠屏、平板、桌面等“非传统手机”屏幕下的用户呈现能力。

为什么需要纯Compose的导航框架

在b站深入推进业务 CMP 跨平台化的过程中，我们发现缺少一个适配 CMP 属性的页面导航框架是深入业务使用的一大阻碍。

在先前的页面方案中，我们仿照安卓原生实现，选择了为每个导航节点嵌套一个原生window容器，即每打开一个个 Composable 页面都对应一个安卓 Activity 、iOS UIViewController 和鸿蒙 entry 的创建与展现。这个方案能让我们快速地将 Compose 页面集成到现有工程中，但随后带来了更多其他的问题。

首要面临的问题是内存压力。在 iOS 和鸿蒙中，每打开一个新的原生容器来承载Compose页面，都意味着一个 CAMetalLayer/NativeWindow 被创建，对应3倍大小的render buffer也会被创建在内存中，内存占用就会相应提升。根据我们测算，使用三缓冲区渲染的 iOS，每一个 CAMetalLayer 都会占用约40M的内存。随着接入Compose的页面越来越多、用户打开的页面越来越多，内存压力会不断增长，影响我们的CMP推进进程。

另一个问题是，Compose 上下文内使用的 Lifecycle 系统是基于安卓生命周期概念设计的，在 iOS 和鸿蒙系统中多少有些水土不服，需要 ComposeView 的宿主层进行额外的配置工作，例如将 UIViewController 的 willAppear didAppear等回调桥接到 androidx 生命周期的相应事件上。在“标准容器”无法满足页面展现需求，需要做业务定制的时候，这些额外配置将成为开发过程的摩擦，在接入者不熟悉/没有意识到需要做这些配置的时候，将严重拖慢review和交付进度。

并且，这样的桥接总会丢失准确信息，特别是在页面切换的时候，总会错过准确的生命周期回调，导致在后台执行了额外的工作，引起卡顿、发热等问题；

同时，不正确的生命周期事件会让开发有不正确的预期，这一点会在本文后面详细描述。

基于以上问题的考量，我们得出结论，至少在纯Compose世界内的页面导航切换范围内，我们需要一个纯Compose的导航框架。而刚刚推出正式版、其结构思想契合现代代码开发思路的Navigation3成为我们的首选方案。

路由与导航的区别和联系

在之前的开发理念中，我们往往将"路由"和"导航"混为一谈：一个 URI 既是页面的标识，也是跳转的触发方式。我们将URI标注在一个 Fragment/Activity 上之后，调用“路由”跳转这个URI将直接打开这个页面实例。

@Route("bilibili://some/page")
class SomePageActivity: Activity()


Router.routeTo("bilibili://some/page") // == startActivity(SomePageActivity.class)

然而，在后续的开发和迭代过程中，我们逐渐意识到，这一次跳转动作应当分为两个具体步骤：使用“路由”寻找这个 URI 对应的页面信息，然后使用“导航”组件将这个页面展现在用户面前。

在我们的项目 CMP 化推进过程中，基架团队已经将这个理念应用到了b站的 CMP 版路由组件中，允许业务方在复用公共路由表的查找逻辑和结果的前提下，根据不同页面需要自定义自己的“路由结果导航”行为，为这次的 Nav3 快速接入提供了合适切入点。

数据驱动的声明式导航栈展现

Navigation3 的核心理念是：导航栈就是一个普通的 List，UI 是这个 list 的函数。

class MyBackStack<K : NavKey>(private val list: SnapshotStateList) : SnapshotStateList by list {
    override funadd(item: K){
        // 可以在这里提前处理冲突元素的清理
        list.add(item)
    }
}


@Composable
funNavPage(modifier: Modifier = Modifier){
    val backStack = remember {
        mutableStateListOf(HomeNavKey)
    }


    NavDisplay(
        backStack = backStack,           // 数据：当前栈内容
        sceneStrategy = ...,             // 策略：如何将栈内容映射为布局
        entryDecorators = listOf(...),   // 装饰器：为每个 entry 注入能力
        entryProvider = entryProvider {   // 注册：NavKey → Composable 的映射
            entry { key -> SomePage(key) }
        },
    )
}

开发者只需要按照自己的页面逻辑操作 backStack ，例如添加、移除，或者“在特定页面入栈时清除其他页面”用来实现“最多只有一个详情页被打开”的情况。NavDisplay 会自动响应变化并重新计算布局。不需要手动调用 navigate()、popBackStack() 等命令式 API，更加贴合 Compose 生态中的开发习惯。

在实际业务中接入使用

在实际的业务场景中使用 Navigation3 ，当然不像其他网络示例那样简单调用。我们将需要深入使用 Nav3 库提供的各种 api ，定制自己的业务功能。

NavKey 与路由发现

在 Nav3 中，NavKey 是描述页面的最小独立元素，每一个 NavKey 类型都跟一个页面绑定，描述了期望被打开的页面的基础信息，例如请求这个页面所需的唯一ID：

@Serializable
@Route("bilibili://some/nav3/page/with/id/{id}")
data class SomeIdPageNavKey(
    val id: String,
    val paramFromQuery: String,
) : NavKey


@Route("bilibili://some/page/with/id/{id}")
@Composable
funSomePage(id: String, modifier: Modifier = Modifier, paramFromQuery: String = ""){}

因为一个 NavKey 可以跟一个路由严格对应，所以以上这段声明代码完全可以交给路由的 KSP 处理器自动生成。在子页面发起正常的路由跳转请求时，通过拦截器模式拦截此次路由的查找过程，如果找到匹配的 NavKey 类型，则将一个实例添加到backStack栈顶，将普通的导航行为桥接到 Nav3 的导航中。

// 路由拦截器：将普通路由请求桥接到 Nav3 的 backStack
class Nav3RouteInterceptor<KEY : NavKey>(
    private val onNavKeyFound: (KEY) -> Boolean,
) : Interceptor {
    override funintercept(chain: Interceptor.Chain): Response {
        val originUri = chain.uri
        // 将原始 URI 转换为 Nav3 专用的查找格式
        // 例如 bilibili://some/page/123 → bilibili://some/nav3/page/123
        val navUri = convertToNav3Uri(originUri) ?: return chain.proceed()


        // 在路由表中查找这个 URI 对应的 NavKey 工厂函数
        val target = chain.find(navUri) as? SomeIdPageNavKey


        returnif (key != null && onNavKeyFound(key)) {
            Response.Done  // 拦截成功，阻止后续的默认导航行为（如 startActivity）
        } else {
            chain.proceed() // 未匹配，交给下一个拦截器或默认处理
        }
    }
}


// 在 Nav3 宿主页面中组装拦截器
@Composable
funNav3HostPage() {
    val backStack = remember { mutableStateListOf(HomeNavKey) }


    // 创建拦截器，拦截成功时将 NavKey 推入栈
    val interceptor = remember {
        Nav3RouteInterceptor { key ->
            backStack.add(key)
        }
    }
    // 在原有 Router 上叠加拦截器，生成新的 Router 实例
    val localRouter = LocalRouter.current
    val nav3Router = remember(localRouter, interceptor) {
        localRouter.newBuilder().addInterceptor(interceptor).build()
    }


    NavDisplay(
        backStack = backStack,
        entryDecorators = listOf(
            // 通过 Decorator 将带拦截器的 Router 注入到所有子页面
            // 这样子页面内发起的路由请求也会经过拦截器
            remember { Nav3RouterDecorator(nav3Router) },
            ...
        ),
        ...
    )
}


// Decorator 实现：通过 CompositionLocal 注入 Router
class Nav3RouterDecorator(
    private val router: Router,
) : NavEntryDecorator(
    onPop = {},
    decorate = { entry ->
        CompositionLocalProvider(LocalRouter provides router) {
            entry.Content()
        }
    },
)

NavKey 需要支持序列化（用于 backStack 的保存/恢复），因此都标注了 @Serializable；当然，也可以选择统一保存原始跳转链接的string内容，在需要恢复时重新走一次路由查找。

NavKey 与 entry 注册

NavKey 仅能表示“有一个页面”，在 Nav3 中，还需要通过 entryProvider 的方式将“这个 NavKey 对应的页面如何显示” 注册到当前的 NavDisplay 中：

NavDisplay(
    backStack = backStack,
    entryProvider = entryProvider {
        entry<SomeIdPageNavKey>(metadata = BiliListDetailSceneStrategy.detailPane()) { key -> SomePage(key.id, Modifier, key.paramFromQuery) }
    },
 )

当然，这一段注册代码也可以抽象为 EntryProviderScope.() -> Unit 的函数，由路由 KSP 处理器统一生成，页面只需要按需注册即可。

SceneStrategy 与 Scene

SceneStrategy 是 Navigation3 中最关键的扩展点。它接收当前 backStack 中所有 entry，返回一个 Scene 来描述如何布局。

在我们的宽屏适配实践中，我们实现了 BiliDetailSceneStrategy：

class BiliDetailSceneStrategy<K : NavKey>(
    val windowSizeClass: WindowSizeClass,
) : SceneStrategy {
    override fun SceneStrategyScope.calculateScene(entries: List<NavEntry<K>>): Scene? {
        if (windowSizeClass.isAtLeastMedium(...)) {
            // 宽屏：从栈中找到最后一个 List entry 和最后一个 Detail entry
            val listEntry = entries.findLast { it.metadata.containsKey(LIST_KEY) }
                ?: return null
            val detailEntry = entries.findLast {
                it.metadata.containsKey(DETAIL_KEY)
            }
            return BiliListDetailScene(
                listEntry = listEntry,
                detailEntry = detailEntry,
                listWidth = if (windowSizeClass.widthLargeCompat()) 375.dp else300.dp,
            )
        }
        return null  // 非宽屏的情况：返回 null，表示当前 Strategy 不处理这个情况，NavDisplay 将使用默认单页 Strategy
    }
}

BiliListDetailScene 的布局结构：

Row(modifier = Modifier.fillMaxSize()) {
    // 左栏：列表
    Box(modifier = Modifier.width(listWidth)) {
        listEntry.Content()
    }
    VerticalDivider(...)
    // 右栏：详情或占位图
    Box(modifier = Modifier.weight(1f)) {
        if (detailEntry != null) {
            CompositionLocalProvider(LocalBackIconVisibility provides false) {
                detailEntry.Content()
            }
        } else {
            DefaultDetailPlaceholder()
        }
    }
}

每个 entry 通过 metadata 标记自己属于哪个区域。metadata 在注册 entry 时通过 BiliListDetailSceneStrategy.listPane() / detailPane() 设置：

companion object {
    funlistPane()= mapOf("BiliListDetailScene-List" to true)
    fundetailPane()= mapOf("BiliListDetailScene-Detail" to true)
}

SceneStrategy 的 calculateScene 在每次 backStack 变化时都会被调用。如果设备发生折叠/展开，windowSizeClass 变化会触发 BiliListDetailSceneStrategy 的重建（通过 remember(windowSizeClass)），从而自动切换单栏/双栏布局。

踩过的一些坑

从原生导航模式迁移到 Nav3 ，页面的导航方式将发生重大变化，其中有不少在往常开发过程中注意不到的地方。

生命周期、页面重入、状态保存

首先最大的一个变化，是之前每一次导航到一个 Composable 函数页面，都将打开一个全新的 Activity 来承载这个函数体，因此开发们会有一个错误认知：Compose Scope = Activity Scope = ViewModel Scope，在副作用处理上容易出现错误和遗漏，例如：

// ViewModel 中，将 toast 信息作为 State 的一部分暴露
data class PageState(
    val items: List = emptyList(),
    val toast: ToastContent? = null,  // 一次性事件，混在持久状态中
)


class SomeViewModel : ViewModel(){
    val state: StateFlow = ...


    funonAction(action: Action) {
        // 某些操作会产生 toast
        _state.update { it.copy(toast = ToastContent("操作成功")) }
    }
}


@Composable
funSomePage(viewModel: SomeViewModel) {
    val state by viewModel.state.collectAsState()
    val toaster = LocalToaster.current


    var otherState = remember { mutableStateOf("") }


    // 通过 snapshotFlow 监听 state 变化来显示 toast
    LaunchedEffect(Unit) {
        snapshotFlow { state.toast }
            .filterNotNull()
            .distinctUntilChanged()
            .collect { toaster.showToast(it.content) }
    }


    // 或者直接判断内容进行显示，都会引发同样的问题。
    // LaunchedEffect(state.toast) {
    //    state.toast?.let { toaster.showToast(it.content) }
    // }


    // ... 页面内容
}

在独立的 Activity 中，这段代码运行起来不会有问题；但是在 Navigation3 的单Activity导航栈模式下，从这个页面跳转到其他页面之后，这个页面将暂时“退出组合”，在返回这个页面之后，重新“进入组合”。

在这个过程中，并不算一次“重组”，而是一次全新的组合事件，上面的代码将会出现：

1. 不管 LaunchedEffect 的key是什么，都会进入一次执行，snapshotFlow中记录的前值也将被清空，导致 toast 被重复显示；

2. 通过 remember 保存的状态也被清空，依赖 remember 做的逻辑将回到空态。

针对以上问题，修复思路其实很简单。

对于第一个问题，首先需要开发者确认什么内容该属于“状态”，什么内容该属于“事件”。

在示例代码中，val items: List 属于需要在页面上一直显示的内容，属于业务状态的一部分，使用 StateFlow 和 collectAsState 是很恰当的；而对于 toast 来说，已经显示过一次的toast内容在任何情况下都不该重新出现，因此它该属于“事件流”的一部分，每次消费后都不再重放，因此可以使用 sharedFlow 承载toast的传递，或者每次显示完主动将这个字段清空。

而第二个问题则更简单了，首先区分被 remember 的数据是否能接受丢失，如果是可以丢失的状态（例如，播放中的动画进度）则完全可以不处理；对于真正需要保存的数据，可以通过实现自定义 Saver 使用 rememberSavable 的方式，或者将数据委托给 ViewModel 中保存。

data class PageState(
    val items: List = emptyList(),
    val toast: ToastContent? = null,
)


class SomeViewModel : ViewModel(){
    private val _state = MutableStateFlow(PageState())
    val state: StateFlow = _state.asStateFlow()


    // 将 state 中的 toast 字段转换为事件流（replay=0，重新订阅不重放历史事件）
    val toastEvent: SharedFlow = state
        .map { it.toast }
        .filterNotNull()
        .shareIn(viewModelScope, SharingStarted.Eagerly, replay = 0)


    funonAction(action: Action) {
        _state.update { it.copy(toast = ToastContent("操作成功")) }
        // 也可以选择显示后立即清空，确保 toast 状态不会被持久持有
        // _state.update { it.copy(toast = null) }
    }
}


@Composable
funSomePage(viewModel: SomeViewModel) {
    val state by viewModel.state.collectAsState()
    val toaster = LocalToaster.current


    // 需要跨页面跳转保留的状态，改用 rememberSaveable
    var otherState by rememberSaveable { mutableStateOf("") }


    // 消费事件流：重新进入组合时重新订阅，replay=0 保证不会重放已消费的事件
    LaunchedEffect(Unit) {
        viewModel.toastEvent.collect { toast ->
            toaster.showToast(toast.content)
        }
    }


    // ... 页面内容
}

Navigation3使用额外依赖中的 rememberViewModelStoreNavEntryDecorator() 来提供“页面在pop时清空相应viewmodel”的能力。并且在未来这个依赖和ViewModelStore的能力和api将会发生变化，带来更加强大的定制能力。

屏幕状态感知与返回按钮

宽屏模式下，右栏的页面不需要显示返回按钮（因为左栏始终可见）。可以通过自定义 LocalBackIconVisibility 这个 CompositionLocal 控制：

val LocalBackIconVisibility = compositionLocalOf { true }


// 右栏渲染
if (detailEntry != null) {
    CompositionLocalProvider(LocalBackIconVisibility provides false) {
        detailEntry.Content()
    }
}

子页面中通过读取这个值来决定是否显示返回图标：

val showBackButton = LocalBackIconVisibility.current

窄屏模式下 LocalBackIconVisibility 保持默认值 true，页面正常显示返回按钮。

状态栏的控制

在单 Activity 页面导航框架中， SystemUI 配置（如状态栏颜色）如果允许每个页面、每个组件自由控制，将很容易出现UI闪烁等情况。我们通过 SystemUiConfiguration 收集机制解决：每个 entry 通过 collectSystemUiConfiguration Modifier 上报自己的配置，NavDisplay所在的宿主页面取栈顶 entry 的配置应用到宿主：

// ① 定义：持有状态栏配置的可观察容器
@Stable
class StableSystemUiConfiguration {
    var statusBarDarkIcons: Boolean? by mutableStateOf(null)
}


// ② 宿主：为每个 NavKey 分配一个 config 对象，并将"锚点 modifier"传给 entry
val configurationMap = remember { mutableStateMapOf() }
val topConfiguration by remember {
    derivedStateOf { backStack.lastOrNull()?.let { configurationMap[it] } }
}


val getCollectorModifier: (MyNavKey) -> Modifier = { key ->
    val config = configurationMap.getOrPut(key) { StableSystemUiConfiguration() }
    // collectSystemUiConfiguration 在 modifier 链中埋入"锚点"，持有 config 的引用
    Modifier.collectSystemUiConfiguration(config)
}


NavDisplay(
    // 将栈顶 entry 的配置应用到 Window（状态栏颜色等）
    modifier = Modifier.applySystemUiConfiguration(topConfiguration),
    entryProvider = entryProvider {
        // 在构建 entryProvider 时将 collector modifier 传入页面
        entry { key ->
            SomePage(modifier = getCollectorModifier(key))
        }
    },
    ...
)


// ③ 子页面：将自己期望的状态栏配置追加到 modifier 链上
@Composable
funSomePage(modifier: Modifier = Modifier) {
    val isDarkTheme = LocalDarkTheme.current
    Box(
        // statusBarDarkIcons 会沿 modifier 链向上查找"锚点"，找到后将值写入宿主的 config 对象
        // 节点 attach 时写入，detach 时自动清空，生命周期安全
        modifier = modifier.statusBarDarkIcons(darkIcons = !isDarkTheme)
    ) {
        // 页面内容
    }
}

而 NavDisplay 本身所在的页面中，框架已经传入了一个collectSystemUiConfiguration，并且将实际在 window 中生效。通过显式传递控制链条的方式，我们将状态栏的配置权限限制在页面宿主层级，在这一层让业务根据自己的实际逻辑决定内部组件的生效范围。

返回事件的处理

与 Navigation3 库同时推出的，是 androidx.navigationevent 库，用来响应和发送页面导航事件。Nav3 库默认已经使用了这个依赖库来响应返回事件，其行为是将现有的 backStack 的最新一个元素推出。如果我们需要定制返回事件的处理，可以通过包装 backStack 实现。

需要注意的是，androidx.navigationevent 库会将系统返回手势、系统导航栏返回键、应用顶部导航栏返回按钮或其他主动调用 backHandler.backCompleted() 处的返回事件一同给出，现有的注册层级结构关系不能区分出返回事件的来源行为和来源页面。因此，暂时无法实现“分栏页面各有一个返回按钮，各自控制其栏位的页面pop”交互。

原生页面嵌入

在需要进行宽屏适配的模块中，部分页面仍然是 Android Fragment 实现，尚未迁移到 CMP。我们选择通过 BiliNativePage 将 Fragment 嵌入 Navigation3 体系：

@Composable
internal funBiliNativePage(url: String, modifier: Modifier){
    val showBackButton = LocalBackIconVisibility.current
    // 1. 通过 Router 解析 URL，获取 Fragment Class
    val routeInfo = Router.newCall(url).find()
    val clazz = routeInfo?.clazz


    // 2. 使用 AndroidFragment 嵌入 Compose
    if (clazz != null) {
        // 3. 因为 AndroidFragment 尚不支持响应state变化主动更新参数，因此选择一个key主动进行重组，通过切换fragment的方式将新的 showBackButton 传入
        // 也可以选择使用 ViewModel 传递 showBackButton 的更新，避免fragment的重建
        key(showBackButton) {
            AndroidFragment(
                clazz = clazz as Class<out Fragment>,
                modifier = modifier,
                arguments = createRouteExtraForFragment(routeInfo).also {
                    it.putBoolean("show_back_button", showBackButton)
                },
            )
        }
    }
}


// Fragment 侧：从 arguments 读取 show_back_button 控制返回按钮显隐
class SomePageFragment : Fragment(R.layout.fragment_some_page) {
    private val showBackButton get() = arguments?.getBoolean("show_back_button", true) ?: true


    override funonViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        binding.btnBack.isVisible = showBackButton
        binding.btnBack.setOnClickListener { parentFragmentManager.popBackStack() }
    }
}

原生页面的注册可以通过 expect/actual 机制来声明，或者使用依赖注入框架来实现页面注册。

showBackButton 的变化会触发 Fragment 重建（通过 key(showBackButton)），确保 Fragment 能响应宽屏/窄屏切换时返回按钮的显隐变化。

Scene 中的小发现

在尝试在Nav3框架内添加页面切换动画过程中，我调研了官方示例 nav3-recipes 中关于动画切换的部分，结果看到了一段让我始料未及的代码：

override val content: @Composable (() -> Unit) = {
    Row(modifier = Modifier.fillMaxSize()) {
        Column(modifier = Modifier.weight(0.4f)) {
            listEntry.Content()
        }
        ...


        Column(modifier = Modifier.weight(0.6f)) {
            AnimatedContent(
                ...
            ) { entry ->
                entry.Content()
            }
         }
     }
}

其中的 entry.Content() 让我产生了“这能正常触发重组吗？”的疑问🤔。在通常的开发惯例中，Composable 函数一般都是独立于Kotlin class的顶层函数，而不是某个实例的成员函数来被调用，这样 Compose 框架可以通过分析入参是否变化来决定是否重组；如果函数本身是一个类对象的成员函数，那类实例的改变会不会产生类似于key改变的作用、从而触发了这个Composable函数的完全重组呢？

带着这个疑问，我构造了一段测试代码：

@Immutable
data class TestClass(val data: String){
    @Composable funContent(modifier: Modifier = Modifier){
        Text(data)
    }
}

然后使用 jadx 查看它编译后的产物，看到了关键信息：

public final classTestClass{
    public static final int $stable = 0;
    private final String data;
    /* JADX INFO: Access modifiers changed from: private */
    public static final Unit Content$lambda$0(TestClass testClass, Modifier modifier, int i, int i2, Composer composer, int i3) {
        testClass.Content(modifier, composer, RecomposeScopeImplKt.updateChangedFlags(i | 1), i2);
        return Unit.INSTANCE;
    }
    public TestClass(String data){
        Intrinsics.checkNotNullParameter(data, "data");
        this.data = data;
    }
    public final String getData(){
        returnthis.data;
    }
    public final void Content(Modifier modifier, Composer $composer, finalint $changed, finalint i){
        Composer $composer2;
        final Modifier modifier2;
        Composer $composer3 = $composer.startRestartGroup(507862195);
        ComposerKt.sourceInformation($composer3, "C(Content)N(modifier)160@6025L10:ListDetailScene.kt#qpkuy4");
        int $dirty = $changed;
        if(($changed & 48) == 0) {
            $dirty |= $composer3.changed(this) ? 32 : 16;
        }
        if(!$composer3.shouldExecute(($dirty & 17) != 16, $dirty & 1)) {
            $composer2 = $composer3;
            $composer2.skipToGroupEnd();
            modifier2 = modifier;
        } else {
            Modifier modifier3 = (i & 1) != 0 ? Modifier.INSTANCE : modifier;
            if(ComposerKt.isTraceInProgress()) {
                ComposerKt.traceEventStart(507862195, $dirty, -1, "com.example.nav3recipes.scenes.listdetail.TestClass.Content (ListDetailScene.kt:159)");
            }
            $composer2 = $composer3;
            TextKt.m4145TextNvy7gAk(this.data, null, 0L, null, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, 0, null, null, $composer2, 0, 0, 262142);
            if(ComposerKt.isTraceInProgress()) {
                ComposerKt.traceEventEnd();
            }
            modifier2 = modifier3;
        }
        ScopeUpdateScope scopeUpdateScopeEndRestartGroup = $composer2.endRestartGroup();
        if(scopeUpdateScopeEndRestartGroup != null) {
            scopeUpdateScopeEndRestartGroup.updateScope(new Function2() { // from class: com.example.nav3recipes.scenes.listdetail.TestClass$$ExternalSyntheticLambda0
                @Override // kotlin.jvm.functions.Function2
                publicfinal Object invoke(Object obj, Object obj2) {
                    return TestClass.Content$lambda$0(this.f$0, modifier2, $changed, i, (Composer) obj, ((Integer) obj2).intValue());
                }
            });
        }
    }
}

会发现，这样一种成员Composable函数的产物跟顶层函数没什么区别，都是使用一个生成的数字key作为restart group的标记，在其中判断参数是否变化时，额外进行了 this 对象的判断，也就是说，可以简单将这个函数定义等价为：

data class TestClass(val data: String)


@Composable
funContent($this: TestClass, modifier: Modifier = Modifier)

基于这一层理解，就能确认，在nav3-recipes示例工程中，scene发生实例变化的时候，也等价于一个普通的Compose重组，其中可以依靠普通的重组、跳过和remember实现动画播放了。

总结

Navigation3 库的出现，极大地减轻了现有 app 在既存路由框架中接入使用的负担，让我们能快速地将现有的 Compose 页面接入其中，完成宽屏适配；同时也推动开发者在编写 Compose 页面的时候更加深入地思考该如何去适配它的生命周期与状态保存，提示代码的交付质量。

-End-

作者丨肖志康

从特效 SDK 到 AI 动效平台：Neon Vibe Motion 的技术演进之路

Tue, 31 Mar 2026 12:05:00 +0800

原创大前端 2026-03-31 12:05 上海

多媒体中台在B站主要负责剪辑、拍摄、直播等业务场景的动效渲染，开发维护的SDK在后文统一称为特效SDK。

多媒体中台在 B 站主要负责剪辑、拍摄、直播等业务场景的动效渲染，开发维护的 SDK 在后文统一称为特效 SDK。

传统的视频特效生产一般分三条链路：

三条链路存在一个困境：效果丰富度、实时可交互、生产效率，三者不可兼得。

那么能不能让 AI 直接生成可实时预览并支持调参的动效？

"用自然语言描述需求、AI 生成可控动效"的模式我们称之为 Vibe Motion。我们沿着这个方向做了 Neon Vibe Motion：一个开源的基于 LLM 动效生成与实时控制平台。用自然语言描述你想要的效果，LLM 生成可执行的渲染代码和可调参数声明，在 HTML5 Canvas 上实时预览，调到满意后导出视频或独立网页。Neon 不绑定特定模型，支持任何兼容 OpenAI Chat Completions API 的 LLM。

相关工作

这个方向上已有很多人同时在探索，有同样困境的不止我们一家。

总结下来AI 驱动的动效生成目前有两条路线。

像素生成——文生视频，以 Sora、Veo、Seedance 等 AI 视频生成模型为代表，输入文本或图片，输出视频文件。这类模型擅长写实画面和影视级内容，但产出的是像素数据，生成完就不可编辑。
代码生成——LLM 输出可执行的渲染代码，产出的是可编辑、可参数化的动效程序。Neon 属于后者。

代码生成MG路线上，值得讨论的有两个产品：

Higgsfield Vibe Motion 是一个商业产品，与 Anthropic 合作，基于 Claude 模型，通过对话生成渲染代码来制作动效。支持实时编辑和参数调整，按 credit 付费。

Remotion 是一个开源的 React 视频框架，用 React 组件定义视频的每一帧。Remotion 官方已经提供了完整的 AI 集成方案：面向 LLM 的 system prompt、模块化的 skills 系统、以及一个"Prompt to Motion Graphics"的 SaaS 模板。

一、范式选择：结构化生成而非视频生成

AI做动效，第一个要回答的问题是：AI 应该输出什么？

最直觉的答案是让 AI 直接输出视频文件。然而当前的文生视频模型生成的视频动效存在明显的可控缺陷，视频生成完就固化了——颜色不对、速度太快、文字想改，都得重新抽一遍，没有任何迭代的连续性。而且贵。

我们选了另一条路：让 LLM 生成动效程序，而非视频文件。

但"动效程序"本身也有不同的形态。从我们当时的视角看，素材包至少有三种存在方式：

第一种：声明式配置包。 这是我们特效 SDK 链路二的做法。素材包是一份 JSON 配置，描述用哪些渲染节点、怎么连接、参数是多少。SDK 内部有一组预置的渲染能力（粒子发射器、模糊、色彩变换等），JSON 负责调度它们的组合。表现力的上限等于预置能力的并集——SDK 没有的能力，JSON 再怎么写都做不出来。

第二种：引擎脚本 + 自定义 Shader。 这是 Unity、Unreal、Cocos 等游戏引擎的做法。用户可以写脚本控制渲染逻辑，写 shader 控制像素级表现。理论表现力的上限等于 GPU 的上限。但代价是 API 面很复杂——脚本要遵守引擎的生命周期约定（OnUpdate、OnRender），shader 要遵守渲染管线约定（顶点格式、uniform 绑定、pass 定义）。写出正确代码的门槛很高。

第三种：可执行渲染代码。 这是 Neon 的做法。素材包里的 code 字段是一段完整的渲染函数，直接操作 HTML Canvas 2D context。没有预置原子的边界限制，也没有引擎管线的约定束缚。一个函数，一块画布，LLM 想怎么画就怎么画。

我们选可执行渲染代码，原因很务实：LLM 写 Canvas 2D 的成功率远高于写引擎脚本 + shader。我们最初尝试过后者，结果不理想——渲染代码能成功执行的比例很低，而且 LLM 难以建立画面与代码之间的对应关系，它能写出语法正确的 shader，但不知道渲染出来长什么样。相比之下，LLM 训练数据中有大量 Canvas 2D API 示例，对"这行代码画出来是什么"有先天明确的认知。

这是当下验证方向的务实选择：先把链路跑通，验证可行性，再去搭建符合业务需求并且 AI friendly 的脚本引擎 + shader 脚手架。

同样走代码生成路线的还有 Remotion，但架构重心不同：

两者不互斥。Remotion 擅长的时间线编排恰好是 Neon 目前的短板，未来有可能引入 Remotion 做时间线编排层，底层保留图形管线。

顺着这个方案走下来，还有一个额外收获：素材包本身变成了自包含的。传统素材包离开 SDK 无法运行；Neon 的 MotionDefinition 自带渲染逻辑，一个 HTML 文件浏览器打开就能独立运行。

具体来说，MotionDefinition 包含：

code — 可执行的 Canvas 2D 渲染代码。这段代码接收当前时间和参数，在每一帧绘制画面。
parameters — LLM 根据效果语义声明的可调参数。比如一个赛博朋克风格的柱状图动效，LLM 会声明 primaryColor（主色）、barCount（柱子数量）、speed（动画速度）等参数，每个参数都有类型、默认值和取值范围。
duration / durationCode — 动效时长。可以是固定值，也可以是一段表达式（比如根据视频素材的实际长度动态计算）。
postProcessCode — 可选的 WebGL 后处理 shader 代码，用于叠加全屏效果（发光、模糊、色彩校正等）。

这个选择带来了几个直接好处。

实时可调。 用户拿到的是一个可运行的程序。拖动滑块改颜色，Canvas 上的画面立刻变化。

确定性输出。 在同一设备和浏览器环境下，相同的参数和相同的随机种子，产出逐帧一致的渲染结果。预览看到什么，导出就是什么。
多格式导出。 同一份 MotionDefinition，可以导出为 MP4 视频、零依赖的独立 HTML 网页、或包含完整对话和参数快照的 .neon 会话归档。一份代码，多种交付形态。

Neon 后续的架构——渲染引擎、参数系统、导出流水线——都围绕这个前提展开。

二、渲染引擎的演进

渲染引擎后面的几次演进，本质上都在平衡两件事：LLM 现在能稳定写出什么，和我们真正想要什么效果。

起步：Canvas 2D

第一版渲染引擎选了 Canvas 2D API，选型理由在上一章已经讲过。

对于我们的目标场景——扁平动效、数据可视化、文字动画、粒子系统——Canvas 2D 完全够用。更重要的是，生成的代码，设计师或前端开发者可以直接理解逻辑、手动微调，不需要图形学背景。

渲染循环的实现用 requestAnimationFrame 驱动，逐帧渲染，每帧调用 LLM 生成的渲染函数renderframe，传入当前时间戳、可调参数值和 Canvas Context。

后处理层：WebGL Shader

然而 Canvas 2D 的实际视觉表现力存在明显的天花板。例如纯 2D 绘图很难做出发光（bloom）、运动模糊、色彩分离这类全尺寸后处理效果。我们的方案是在 Canvas 2D 之上再叠加一层 WebGL 进行后处理。

此方案流程是：Canvas 2D 先画完一帧的内容，然后把整个 Canvas 作为纹理传给 WebGL，跑一遍全屏 shader 链（bloom、blur、色彩校正、畸变等），最终输出到用户可见的 Canvas 上。

至于后处理 shader 怎么来，我们探索过两条路：

两种方案都支持用户拖动参数面板实时修改效果。随着 LLM 的 coding 能力持续增强，方案二的稳定性问题逐步缓解，最终保留了该方案。

3D 探索：Three.js

Canvas 2D 实践之后表现力天花板越来越明显。我们尝试引入 Three.js 来支持 3D 动效。

采用双 Canvas 方案——一个 Canvas 跑 2D 渲染，一个跑 Three.js 的 3D 渲染，最后 blend合成到一起。MotionDefinition 的格式可以保持不变，渲染函数的签名也一致，3D 场景只是多了一种渲染模式。

从我们目前的效果来看，3D 仍处于玩具水平。Three.js 本身能力很强，但尝试下来 LLM 生成的 3D 场景代码质量并不高——灯光、材质、相机角度的配合需要很强的美术直觉、设计感，这恰恰是纯文字的 LLM 的短板。

3D 是一个值得继续探索的方向，但目前还不是 Neon 的核心竞争力。如果要认真做 3D 动效，可能需要投入更多人力去搭建一套对 AI 更友好的 3D 脚手架、更丰富的渲染效果抽象层——降低 LLM 生成 3D 场景代码的门槛。

三层叠加后的完整渲染管线如下：

三、让 LLM 生成"能用"的代码

实践下来，单次 LLM 调用，一次产出代码能运行的概率在～90%，效果符合预期的概率在～20%。

动效代码对"能用"的定义很苛刻，不仅语法要对、运行不能报错、视觉效果要符合用户预期、性能不能太拉不然拖垮浏览器。任何一个环节出问题，给用户看到的就是开天窗，一个空白 Canvas 或一个无响应的页面。

要提升成功率，关键不在写更复杂的system prompt，而是在生成链路上加了多层质量门控。

澄清：生成前先问清楚

用户说"做个炫酷的动画"，LLM 怎么办？猜什么样的算炫酷。猜错了用户不满意，重新生成，再猜，再重试。这样几轮下来体验是很差的。

我们加了一个设计需求澄清环节。LLM 收到用户模糊需求 prompt 后，不马上生成代码，而是先提出 1 到 5 个定向问题，每个问题附带 3 个以上的预设选项。比如：

“主色调想要什么？” — 选项：赛博朋克蓝 / 暖金色 / 渐变彩虹 / 自定义
“动画节奏？” — 选项：缓入缓出 / 弹性 / 匀速
“元素数量？” — 选项：少量（3-5） / 中等（10-20） / 密集（50+）

用户点选或自定义回答之后，LLM 基于明确的需求再生成代码。预设选项降低了用户的输入成本——不需要精确描述，选一个最接近的就行。

自动纠错：生成后自动修

LLM 生成的代码经常有 bug。例如JavaScript语法错误、引用未定义的变量、Canvas API 调用参数错误等等。

一个方案是让用户看到报错信息，然后手动修改代码或重新描述需求。但我们的用户很大是不懂代码的设计师，看到红红的报错 TypeError: Cannot read properties of undefined 并不能帮助他们解决问题。

Neon 的方案是自我感知自动修复：检测到运行时异常后，把出错的代码和错误信息一起发回给 LLM，让它自己修。最多会尝试 3 轮。多数情况下，LLM 能在 1 到 2 轮内修好问题。在给足错误的具体位置和原因，修bug比写容易多了。

3 轮之后仍然失败的，就向用户展示错误信息和"重新生成"按钮。不无限重试，因为如果 3 轮修不好，大概率是一开始生成的代码方案本身有问题，需要用户换一种描述。

帧耗时检测：运行时兜底

还有一类问题是渲染卡顿。

LLM 偶尔会生成计算量爆炸的代码——循环嵌套太深、每帧创建大量对象、在 requestAnimationFrame 里做同步的cpu密集计算。单帧渲染耗时几秒甚至十几秒，页面完全卡死，用户只能强制刷新。

于是加了帧耗时检测：单帧渲染超过 100ms 就自动暂停，弹 toast 告诉用户渲染代码太卡。用户可以调参数降低复杂度，或者让 LLM 重新生成。

不同模型的生成效果

Neon 不绑定特定模型，支持任何兼容 OpenAI Chat Completions API 的 LLM。以下是不同模型对同一 prompt 的生成效果：

“Create a parallax timeline using floating glass cards. Glide smoothly through 3D space, bringing each milestone into sharp focus with a depth-of-field effect.”

不同模型对 “parallax”（视差）、“depth-of-field”（景深）等空间效果的理解和实现程度不同，这也是我们前面提到增加了澄清环节的原因。

小结

三层门控各司其职：澄清收窄需求、纠错修复问题、性能检测兜底。与其追求"一次做对"，不如接受 LLM 会出错，用工程手段快速纠正。

但三层门控只能保证"代码能跑"，短板是分阶段渲染的缺失。Neon 目前生成的动效大多"所有元素同时动"，而好的动效有清晰的阶段——进场、变换、退场。LLM 很难自发产生这种概念。

我们计划在 MotionDefinition 中增加 phases 显式定义，让 LLM 先规划阶段结构，再填充渲染逻辑。这与剪辑软件中 Clip 的概念类似。

四、描述规则而非画面

上一章解决的是"代码能不能跑"的问题。但还有一个更前置的问题：用户应该怎么写 prompt？

直觉上，动效的 prompt 和文生视频差不多——描述画面就好。但 Vibe Motion 的产出物是代码而非像素，这决定了 prompt 要传达的信息本质不同。

文生视频的 prompt 描述的是画面应该长什么样——构图、色调、光影、镜头运动。模型的任务是把文字翻译成像素。一个典型的文生视频 prompt：

“金色粒子在深色背景上爆炸，电影感，景深模糊”

它描述的是视觉结果。用户不关心粒子怎么运动，只关心最终画面好不好看。

Vibe Motion 的 prompt 描述的是动效背后的运动规则——元素怎么出现、怎么移动、怎么消失，受什么力、以什么速度衰减。因为 LLM 生成的不是像素，而是一段可执行的渲染程序，prompt 需要传达的是程序的行为逻辑：

“粒子从画面中心向外发射，初速度快然后逐渐减速，有轻微随机偏转，生命周期末尾透明度渐隐，整体受一个向下的重力影响”

它描述的是运动系统的物理规则：发射源、速度衰减、随机扰动、生命周期、外力。

这个差别直接决定了产出物能不能调参。文生视频的 prompt 描述外观，模型输出像素，像素没有"系数"可言，结果不可调。Vibe Motion 的 prompt 描述规则，LLM 把规则写成代码，代码里是数学公式——比如用户说"粒子向外扩散，逐渐减速"，LLM 写出的大概是：

velocity = initialSpeed * Math.pow(damping, t)

这行公式里的 initialSpeed 和 damping 就是天然的可调参数。不是后加的，是公式本身的一部分。LLM 把它们声明到 MotionDefinition 的 parameters 里，用户拖滑块改的就是这些系数。

参数可调并不是后面硬加上的能力，而是这套范式顺出来的结果。既然 prompt 描述的是规则，代码里自然会落成公式；公式一旦出现，可调参数也就跟着出来了。

这也解释了第三章的澄清环节为什么会问"节奏"“数量”"速度"这类问题——它们不是在收集画面描述，而是在收集运动规则的关键变量。

Prompt 工程的方向也因此不同。文生视频的 prompt 工程围绕"描述力"——怎么用语言精确描述画面（加 negative prompt、加风格词、加镜头术语）。Vibe Motion 的 prompt 工程围绕"规则表达力"——怎么高效地传达运动规则。从实践来看，几类表述对 LLM 的代码生成质量影响明显：用物理直觉词汇（“弹性碰撞”“阻尼振荡”）比用感性描述（“看起来有弹性”）精确；用阶段性描述（“先聚集，再爆炸，最后飘散”）比单一描述（“粒子爆炸”）能产出更有节奏的动效；用约束（“速度不超过 200px/s，粒子数量 50-100”）比用形容词（“密集的快速粒子”）更可控。

五、参数系统与实时控制

上一章讲了因果链：规则 → 公式 → 系数 → 参数。这一章看具体实现。

LLM 在生成 MotionDefinition 时，会根据效果的语义自动声明一组可调参数。我们支持 10 种参数类型：

参数的流转路径很直接：LLM 在 MotionDefinition 的 parameters 字段中声明参数的名称、类型、默认值和取值范围；前端根据声明自动生成对应的 UI 控件；用户在参数面板修改值后，新值立即注入渲染函数的 params 对象，Canvas 在下一帧就反映变化。

很多动效的时长不是固定的。比如一个视频转场效果，总时长取决于用户上传的视频有多长。如果在 MotionDefinition 中写死 duration: 5000，用户上传一个 10 秒的视频就会被截断。

我们的方案是 durationCode——一段在运行时求值的表达式。LLM 可以生成类似 Math.max(params.video1.videoDuration, params.video2.videoDuration) 的表达式，时长随素材变化自动调整。静态 duration 作为 fallback，durationCode 求值失败时兜底。

六、导出体系：从预览到交付

设计师最终需要一个可以交付的产物——视频文件、可嵌入的网页、或者能分享给同事的项目归档。

视频导出

视频导出是最直接的需求。我们在浏览器端完成编码，无需上传服务器。

导出流程是：创建一个离屏 Canvas，按目标帧率（24 / 30 / 60 fps）逐帧调用渲染函数，每帧提取像素数据送入编码器。确定性渲染在这里发挥作用——同样的参数和种子保证导出结果和预览完全一致。

我们还支持 Alpha 通道导出。输出是一个 ZIP 包，包含 RGB.mp4 和 Alpha.mp4 两个文件，设计师可以直接拖进 After Effects 或 Premiere 做合成。分辨率支持 720p、1080p 和 4K。

HTML 资产包

一键导出一个零依赖的单个 .html 文件，里面内嵌了渲染代码、资源文件和一个简单的参数面板。

用户可以选择暴露哪些参数。导出后这个 HTML 可以直接在浏览器打开、部署到 CDN、或者发给开发者做集成。不需要安装任何依赖，不需要搭建环境，双击就能跑。

实际场景中，设计师做完效果导出 HTML，丢给前端同事，前端看到实时效果后直接把代码集成进项目。这比传统的"设计师出设计稿 → 前端还原"流程更顺畅。

会话归档

Neon 的对话过程本身也是有价值的——prompt 怎么写的、LLM 做了什么澄清、参数调了几轮。这些上下文对复现和迭代都很重要。

.neon 会话归档文件把完整对话、当前 MotionDefinition、所有参数快照和附件打包成一个 JSON 文件。可以跨设备迁移、团队内共享，也可以做版本备份。支持批量导出多个对话到一个文件。

七、动效复刻：从视频到可编辑程序

设计师经常会遇到一个场景：看到一个喜欢的动效，想做一个类似的。传统做法是肉眼分析运动规律，然后在 AE 里手工重建——费时费力，而且重建出来的只是视觉上的近似，没有参数化的调整能力。

我们尝试用 VLM 自动化这个过程：用户上传一段参考视频，系统分析画面内容，生成可编辑的动效代码。这个方向经历了两个版本的探索。

第一版：全自动流水线

最初的思路很直觉——让 VLM 看视频帧，直接生成渲染代码，然后自动跑 5 轮迭代优化，每轮对比参考帧和渲染帧、修改代码、再对比。用户等着拿结果就行。

问题出在第一步。VLM 的分析质量不稳定，有时候对运动方向、元素数量、时间节奏的理解是错的。但这个错误对用户不可见——系统拿着错误的理解直接生成代码，然后在错误的基础上迭代 5 轮。迭代确实在"优化"，但优化的方向是错的。5 轮 API 调用花出去了，结果和用户想要的效果毫无关系。

核心问题是：VLM 的分析质量不确定，全自动流水线放大了这个不确定性。

第二版：用户参与的分阶段流程

我们把"分析"和"生成"拆开，中间插入用户确认环节。

抽帧。 用户上传视频后，浏览器端从视频中均匀采样 16 个关键帧。

结构化分析。 16 帧发给 VLM，从 10 个维度提取特征：视觉元素的形状和数量、运动轨迹和缓动函数、时间阶段划分、背景类型、色彩方案、模糊和发光效果等。

核心特征精炼。 初次分析容易泛泛而谈——“有一些粒子在移动”。我们加了一轮精炼：VLM 从初次分析中识别出 1 到 3 个定义这个效果身份的核心视觉特征，评估初次描述是否足够精确，不够的就补充具体数值。比如"粒子"会被精炼为"约 80 个圆形粒子，半径 2-5px，从画面中心向外扩散，速度先快后慢，带高斯模糊拖尾"。

用户确认。 分析结果展示给用户。用户可以确认，也可以补充修正——比如"这不是粒子扩散，是烟花爆炸，先上升再炸开"。修正内容会和分析结果一起传给后续的代码生成环节。第一版没有这个环节，VLM 理解错了用户无从纠正，后续迭代全在错误方向上浪费算力。

代码生成与迭代优化。 确认后，系统基于分析结果和参考帧生成 Canvas 渲染代码，然后自动进入迭代优化——VLM 对比参考帧和渲染帧，找出差异最大的 2 到 3 个问题，针对性修改代码。每轮只修最突出的几个问题，不是全部，避免改一处坏三处。如果某轮迭代的分数下降，自动回退到最佳版本重新尝试；如果连续多轮分数持平，说明陷入了局部最优，系统会尝试更大幅度的改动来跳出当前方案。

两版的核心差异

从我们的尝试来看，第二版在简单动效（粒子、渐变、几何变换）上的复刻效果还不错，时间线排布上也有明显好转——元素的进场、变换、退场节奏更接近原始效果。复杂动效仍然差距明显。

另外我们也意识到：逐像素复刻在现阶段是ROI很低的目标。就目前的模型能力而言，LLM 没有像素级的视觉精度，高保真复制不是它擅长的事。批量生成多个变体再从中挑选，才应该是它的主要发力点。

八、Neon Skill：从 GUI 到 Agent Skill

Neon Lab 是面向设计师的交互形态——对话、预览、调参、导出，全在浏览器里完成。但我们希望动效生成能力也能脱离 GUI 使用。

我们把 Neon 的动效生成能力封装成了 Claude Code 的 Skill。核心动机有下面两个。

一个是复用 Claude Code 的工程能力。Neon Lab 里的Agent设计比较简单， LLM 调用是孤立的，每次对话只有用户的 prompt 和系统预设。但在 Claude Code 里，LLM 能看到整个动效项目的文件结构、读取相关代码、理解当前环境上下文。比如用户说"给这个 dashboard 做一个数据加载动画"，Claude Code 可以先读 dashboard 的代码，理解数据结构和配色方案，再生成风格匹配的动效。这种上下文感知能力，我们在浏览器里的 Neon Lab 很难做到。

更关键自我迭代能力。多轮对话中，LLM 能关注到用户之前的偏好：“不要紫色”“动画速度偏快”“粒子数量不要太多”。生成动效后，Claude Code 会调用渲染工具输出视频，自己看效果，不满意就改代码、再渲染、再比对，多轮迭代直到符合预期。

第二个是面向 Agent 的工具接口。比如你让养的🦞(OpenClaw)为某个视频添加动效时，直接调用这个 Skill 就行，不需要通过繁琐的 GUI 交互。动效生成的消费者从设计师逐渐扩展到AI Agent。

同一个渲染引擎，两个前端

Neon Lab 通过网页内的 LLM 调用生成渲染代码，Neon Skill 通过 Claude Code 这类Coding Agent生成渲染代码。目标和结果一致，过程不同。

整个系统拆成三个独立产物：

渲染 bundle — 从 Neon Lab 的渲染模块独立打包出来的一份 HTML + JS。包含 Canvas/WebGL 渲染器、H.264 编码器等所有运行时依赖。
CLI 渲染工具 — 一个 Node.js 命令行工具，内置渲染 bundle。通过 Playwright 启动 headless Chrome，加载渲染 bundle，注入 MotionDefinition，逐帧渲染并编码输出 MP4。
Skill 指令文件 — 指导 Coding Agent 怎么生成 `.neon` 文件、调用 CLI 渲染。

其中 `.neon` 文件是通用草稿。GUI 里生成的效果可以导出 `.neon`，在 CLI 里渲染；CLI 产出的 .neon 也可以拖进 GUI 里预览和调参。

Skill 的组成：不只是一段 prompt

Neon Lab 的 system prompt 是一段很长的提示词，把渲染规范、参数格式、示例代码全揉在一起。这在WebUI 对话框里勉强能用，但对 Claude Code 来说并不是好的做法。 Skill 应该是模块化的参考文档，Coding Agent按需加载。

于是我们把 system prompt 拆解成了几份独立的参考文档：

SKILL.md — 入口文件，定义 Skill 的触发条件和工作流程
CANVAS-GUIDE.md / WEBGL-GUIDE.md / POSTPROCESS-GUIDE.md — 三种渲染模式的代码编写规范
PARAMETERS.md — 10 种参数类型的声明格式
EXAMPLES.md — 完整可运行的动效示例

Claude Code 在生成动效时，先读取 SKILL.md 理解整体流程，再按需加载对应的渲染规范。不需要每次都把所有prompt指令塞进上下文。这在长对话中尤其重要，避免 context window 被无关的规范文档占满，影响LLM的注意力，提升模型性能。

CLI天生适配动效复刻的需求

第七章讲的动效复刻，在 GUI 里依赖浏览器端抽帧和 VLM 对话。我们在 CLI 端也做了一套复刻 Skill，思路一致但交互方式不同。

CLI 复刻的流程是：用 FFmpeg 从参考视频中抽取key帧，Claude Code 分析后为每个动画阶段提取"灵魂特征"。提取的特征不是像素级别描述文本，而是可量化的运动指标（例如运动方向、缓动曲线、空间变化幅度等）。在生成初版 .neon 后渲染出视频文件，把原始key帧和渲染帧拼成对比图，喂给 Claude Code进行逐阶段比对，每轮只改差异性最大的问题。

和 GUI 复刻相比，CLI 的优势在于 Claude Code 能直接读写文件、调用脚本、管理多轮迭代的目录结构。

写在最后

这些技术选型其实都可以换掉：Canvas 2D、WebGL、Three.js、h264-mp4-encoder，那 Neon 的核心是什么？

我们认为平台核心是 MotionDefinition，以及围绕它的上游能力：自然语言 → 运动规则 → 可执行代码 → 可调参数。其中渲染链路和导出格式可以看作适配层，可插拔不同的技术选型。

未来工作的重点：回到特效 SDK 本身，把它改造成更 AI Friendly 的脚本引擎 + shader 体系。

MotionDefinition 不变，变的只是下游渲染链路。不只是渲染后端可以换。

前面章节讲的澄清、纠错、分阶段复刻等环节，本质上都是在补偿当前模型能力的不足。随着基础模型持续迭代，这些 workflow 中的一部分必然会变得冗余。我们对此有预期，也乐见其成，workflow 越精简，其实用户体验越好。

Vibe Motion 作为一个品类才刚起步，天花板在哪，我们也不知道。

Neon 的基础版本已在 GitHub 开源，如果你也在探索类似的方向，欢迎一起交流～

项目地址：https://github.com/S1mpleSonny/neon-vibe-motion

-End-

作者丨森破

往期精彩指路

哔哩哔哩26春招&27暑期实习正式启动！

Fri, 13 Mar 2026 15:19:00 +0800

等你投简历的 2026-03-13 15:19 云南

算法、AI相关岗位机会多多！

从“截图大法”到真实交互：B站专栏视频卡的技术革命

Thu, 12 Mar 2026 12:04:00 +0800

原创大前端 2026-03-12 12:04 上海

回望B站富文本编辑器的演进史，我们经历了一个从“无”到“有”，再从“有”到“优”的过程。

背景：从“伪造”卡片到真实交互

回望 B 站富文本编辑器的演进史，我们经历了一个从“无”到“有”，再从“有”到“优”的过程。在 UEditor 时代，我们解决了基本的文本编辑需求；在 Quill 时代，我们引入了 Delta 数据模型。

然而，在 Quill 时期，面对视频卡等复杂卡片，受限于 Quill 对 BlockNode 缺乏完善的支持，被迫采用“ Canvas 绘图伪造卡片” 的障眼法。今天，拥抱 ProseMirror 生态，这套“ 截图大法” 终于画上句号，取而代之的是支持真实交互的卡片渲染系统。

这场从“伪造”到“真实”的革命，不仅是一次技术栈的迁移，更是一次对技术债的降维打击。今天就带大家深入代码底层，看看我们是如何填平这个深坑的。

第一章：旧世界——那些年，

我们用 Canvas “画”出来的视频卡

1.1 用户视角的“灵异”体验

你可能经历过这样的场景：在专栏里粘贴了一个视频链接，然后看着 Loading 转圈圈，心里默数两秒，“啪”的一下，编辑器里出现了一个视频卡片。

看起来很美？别急着夸。当你试图点击播放时，发现它毫无反应；当你试图修改标题时，发现根本选不中文字。这哪里是视频卡片，这分明就是一张死图！

是的，这就是我们不得不采用的“Canvas 截图大法”。

1.2 技术黑幕：Canvas 的“障眼法”

为了在 Quill 这个不支持复杂 Block Node 的编辑器里塞进一个视频卡，我们当年可是绞尽脑汁，最终设计了一套后续发现极其痛苦的 `html2canvas` 截图链路：

1. 隐式渲染：在浏览器可视区域外（看不见的地方），用 HTML 偷偷画一个临时的卡片 DOM。

2. Canvas 截图：调用 `html2canvas` 咔嚓一下，把这个 DOM 变成 Canvas。为了保证清晰度，通常需要设置 `scale: 4`。

3. 图片生成：将 Canvas 导出为 Base64 图片。

4. 上传替换：把图片上传到 CDN,最后在编辑器里插一个静态的 `` 标签。

1.3 无法回避的四大痛点

说实话，每次写这段代码时，我的内心都是崩溃的。这种做法虽然暂时解决了跨平台兼容问题，但代价是沉重的：

交互性丧失（Interactive Loss）：这仅仅是一张死图。所谓“所见即所得”其实是“所见即图片”。
性能黑洞：整个“API请求 → 绘制 → 截图 → 上传”的链路平均耗时 2秒以上。严重打断写作心流。
数据死锁：卡片上的播放量、弹幕数永远停留在插入的那一刻。如果视频后续爆火，卡片信息也不会更新，甚至误导读者。
存储浪费：每一张生成的卡片图片都需要占用 CDN 空间，随着文章数量增长，这是巨大的隐形资源浪费。

第二章：病根诊断——

当 Quill 遇上视频卡

为什么 Quill 做不好视频卡？这得从它的底层基因说起。

2.1 Delta 像“收银小票”，

ProseMirror 像“乐高积木”

Quill 使用的是 Delta 数据模型。Delta 本质上是一个线性的操作记录，就像一张长长的收银小票🧾。

// Quill Delta: 扁平的线性记录
[
  { "insert": "Hello " },
  { "insert": { "video": { "id": "BV1xx..." } } }, // 强行插入一个对象
  { "insert": "
" }
]

你想在这张薄薄的小票中间塞进一个立体、复杂的“视频播放器盒子”？太难了！Delta 天生就是扁平的，它很难描述复杂的嵌套结构。我们被迫使用的“截图大法”，其实就是在小票上画了个电视机的图案，而不是真的放了个电视机。

而 ProseMirror 使用的是 Document Model（文档树），它就像是乐高积木。

// ProseMirror Tree: 结构化的树形数据
{
  "type": "doc",
  "content": [
    { "type": "paragraph", "content": [{ "type": "text", "text": "Hello" }] },
    {
      "type": "videoCard", // 独立的块级节点
      "attrs": { "bvid": "BV1xx..." },
      "content": [] // 可以继续嵌套其他节点
    }
  ]
}

你可以搭建一个名为"视频卡"的积木块,然后在里面随意嵌套"标题积木"、"封面积木"甚至"播放器积木"。这种树状结构天然就支持复杂的 Block Node(块级节点)。

2.2 技术对比表：为什么我们要换枪?

2.3 选型博弈: 为什么是TipTap+ProseMirror?

在决定彻底抛弃 Quill 之前，我们对市面上的富文本技术方案进行了一次深度摸底。从底层技术演进来看，Web 富文本编辑器主要经历了三个维度的跃迁：

Level 0（强依赖 DOM）：完全基于原生的 contenteditable，典型如 UEditor。技术门槛低，但跨端表现极其不可控。
Level 1（视图即数据）：拥有自身抽象的数据模型，但依然依赖原生 DOM 渲染。典型如 Quill、Slate、Draft.js 及 ProseMirror。
Level 2（自排版自渲染）：彻底抛弃 contenteditable，利用 Canvas/SVG 自研排版引擎，典型如 Google Docs。

从 B 站图文生态（专栏、动态）的实际业务诉求出发，L2 方案属于严重的性能与研发成本过剩，而 L0 方案早已无法满足现代组件的交互需求。因此，我们的主战场锁定在了 L1 级别的抽象数据模型方案。

在 L1 的终极对决中，面对生态优秀的 Lexical 和老牌的 Draft.js（往往强绑定 React），以及底层极其强大但 API 学习曲线陡峭的 ProseMirror，我们最终选择了 Tiptap + ProseMirror 的组合拳。

Tiptap 作为基于 ProseMirror 构建的 Headless（无头）框架，完美继承了其强大的文档树（Document Tree）和 Schema 规范，同时提供了一层极其优雅的 API 封装。这套“底层稳健兜底，上层开发丝滑”的设计，斩断了特定 UI 框架的强依赖，成为我们完成这次降维打击的最优解。

第三章：ProseMirror 核心实战

——架构重组

既然痛点找准了，那就开干。我们设计了全新的“编辑器-组件分离”架构，利用 ProseMirror 强大的 NodeView 机制，彻底重构了卡片系统。

3.1 架构革新：编辑器与组件的“分家”

在这个架构中，编辑器不再负责具体的 UI 渲染，而是专注于文档结构的管理。NodeView 充当了“桥接”的角色。

3.2 核心设计 I:Schema 定义(给积木定规矩)

首先，我们需要告诉编辑器，“视频卡”这个积木长什么样，有什么属性。

// schema/video-card.ts
const VideoCard = Node.create({
  name: 'videoCard',
  group: 'block',     // 声明我是块级节点
  atom: true,         // 💡 关键点：原子化
  draggable: true,    // 可拖拽

  // 定义数据属性
  addAttributes() {
    return {
      card_style: { default: CardStyle.NORMAL },   // 卡片风格
      info: { default: {} },             // 业务数据
      status: { default: 'loading' }          // loading | loaded | error
    }
  },

  // 解析规则：怎么从 HTML 读出来
  parseHTML() {
    return [{ tag: 'div[data-type="video-card"]' }]
  },

  // 渲染规则：怎么存成 HTML
  renderHTML({ node }) {
    return ['div', { 'data-type': 'video-card', 'data-bvid': node.attrs.bvid }, 0]
  }
})

🧐 Code Review:

`atom: true` 是这里的神来之笔。它告诉 ProseMirror：“这个节点是一个整体，光标不能跑进去，要么选中整个卡片，要么不选”。这完美符合卡片的交互逻辑，避免了光标在卡片内部乱窜的尴尬。
`addAttributes` 定义了卡片的数据模型，这些数据会直接映射到 UI 组件的 Props 中。

3.3 核心设计 II：NodeView

（连接两个世界的桥梁）

接下来是重头戏 —— NodeView。它是连接 ProseMirror 数据层和 UI 渲染层的桥梁。我们要在这里把 UI组件挂载上去。

// NodeView：编辑器节点 ↔ UI 组件的桥接层
abstract classBaseCardNodeView {
  // ProseMirror 调用生命周期方法
  constructor(node)  // 节点创建 → 初始化组件
  update(node)       // 节点更新 → 同步组件数据
  destroy()          // 节点销毁 → 清理组件资源


  // 子类实现具体卡片类型
  abstract createCardComponent()  // 创建对应的业务组件
}


// 视频卡片实现
class VideoCardNodeView extends BaseCardNodeView {
  createCardComponent() {
    // 🚀 核心动作：挂载真实组件
    returnnew VideoCard({
      data: this.node.attrs,      // 编辑器数据
      isInEditor: true            // 标识编辑器环境
    })
  }


  // 事件监听：组件 → 编辑器
  setupEventListeners() {
    // 监听组件内部的状态变更，同步回编辑器
    this.cardComponent.on('statusChange', (status) => {
      this.updateNodeAttributes({ status })  
    })


    this.cardComponent.on('delete', () => {
      this.deleteFromEditor()  // 从文档删除
    })
  }
}

🧐 Code Review:

这段代码实现了真正的“所编写即所得”。你在编辑器里看到的组件，就是发布后读者看到的组件，连代码都是同一份！
通过事件监听，组件内部的操作（如点击删除、重试加载）可以反向控制编辑器的数据状态。

第四章：硬核填坑——从“能用”到“好用”

重构之路从不平坦，为了让这个系统真正“好用”，我们解决了不少棘手的工程问题。

4.1 隐秘的代价：插入极速，但运行态呢？

技术世界没有银弹。当我们为“极速插入”和“真实交互”欢呼时，隐秘的代价也随之而来——展示态（运行时）的性能崩盘风险。旧方案虽然插入慢，但在运行时只是一张死图，文章里塞入 50 个卡片依然能丝滑滚动。但新方案的每一个视频卡，都是一个包含了复杂 DOM 树、状态机、播放器的真实组件。如果放任不管，十几个播放器同时驻留内存，浏览器会直接崩溃。

为了兜住这层底线，我们在架构上设计了两大“降落伞”：

4.2 把播放器“装”进编辑器

（CardPlayer 管理器）

我们引入了双视图自由切换模式与 CardPlayer 实例池：

NORMAL 模式：普通小卡，仅展示封面和元信息，不播放视频。
ADVANCED 模式：点击后直接展开内嵌播放器，通过改变 card_style 属性无缝切换，受 `CardPlayer` 管理器控制。

// CardPlayer：全局播放器资源管理
classCardPlayer {
  static MAX_PLAYERS = 3  // 🚦 最大实例数限制


  // 互斥机制：播放时暂停其他
  static play(playerId) {
    pauseOthers(playerId)    // 暂停其他播放器
    startPlay(playerId)       // 启动当前播放器
  }


  // 资源回收：超限时销毁最早的实例
  static enforceLimit() {
    if (count > MAX_PLAYERS) {
      destroyOldest()         // LRU 策略回收
    }
  }
}

4.2 极致性能优化（批量解析 + 三级缓存）

如果用户一次性粘贴 50 个链接怎么办？发 50 个 API 请求？服务器会报警的！我们重构了链接解析层，引入了批量验证和共享缓存 。

// 三层缓存：验证结果 + 类型 + 卡片数据
const cache = {
  validation: Map"">,
  type: Map"">,
  card: Map"">
}


// 批量验证：防抖 + 队列合并
async function validateLink(url) {
  // 1. 缓存命中 → 立即返回
  if (cache.has(url)) {
    return cache.get(url)
  }


  // 2. 加入验证队列（防抖 100ms）
  addToQueue(url)
  await waitBatchProcess()


  // 3. 批量请求完成后从缓存读取
  return cache.get(url)
}

🧐 Code Review:

这里基于防抖，100ms 内的粘贴操作会被合并为一个请求（Batch API）。
缓存是全局共享的。当用户在编辑器内反复撤销、重做或拖拽卡片时，直接命中缓存，实现 0 延迟渲染。

第五章：核心创新点总结

5.1 智能链接解析与双向转换

我们不仅支持从“链接”变“卡片”，还支持完美的逆向转换。通过 `resource_url` 字段保存用户原始输入信息，确保数据 100% 完整。

// 核心数据结构：保存原始链接实现双向转换
interface CardAttrs {
  resource_url: string    // 🔑 关键：保存原始链接
  info: object            // 业务数据
  status: State           // 加载状态
}


// 链接 → 卡片
onPaste(url) {
  insertCard({ resource_url: url, status: 'loading' })
}


// 卡片 → 链接
convertToLink(card) {
  replaceWith(card.resource_url)  // 恢复原始链接
}

5.2 模板策略模式

我们抽象了 `BaseCard` 基类，利用策略模式处理不同类型的卡片渲染。无论是视频卡、专栏卡还是投票卡，都复用了同一套生命周期管理逻辑（mount → load → update → destroy），代码复用率提升了 60%。

// 抽象基类：定义统一的卡片生命周期
abstract classBaseCard {
  // 状态机：合法的状态转换路径
  stateTransitions = {
    LOADING → [LOADED, ERROR],   // 加载中 → 成功或失败
    ERROR → [LOADING],            // 失败 → 可重试
    LOADED → [LOADING]            // 已加载 → 可刷新
  }


  // 子类必须实现的抽象方法
  abstractrenderContent(): void// 渲染内容
  abstract getCardClassName(): string   // 返回样式类名


  // 数据更新：触发状态转换和重新渲染
  async updateData(newData) {
    if (newData.status !== this.currentState) {
      if (!this.isValidTransition(newData.status)) return
      this.currentState = newData.status
      this.updateUI()
    }
    this.renderContent()
  }
}

5.3 历史包袱的优雅着陆：旧专栏兼容

新架构固然强大，但对于一个拥有海量存量数据的平台来说，绝不能以牺牲历史数据为代价。同时，新编辑器生产的内容也必须完美融入现有的内容分发基建。为此，我们围绕 Opus 协议(B站图文统一发布协议) 设计了一套向下兼容历史、向上打通分发的全局策略：

战略锚点：基于 Opus 图文统一发布协议的链路闭环

Opus 是我们内部定义的图文统一发布协议。为了无缝接入现有的动态分发渠道，确保高质量图文能够高效流转，新版编辑器在最终发布时，会将所有文档树数据全量转换为 Opus 格式。这不仅统一了底层标准，也让生产端到分发端的链路彻底打通。

首选路径：历史专栏优先转出 Opus 无损还原

针对过去沉淀的千万级历史专栏，我们已经在服务端优先尝试将其向 Opus 格式进行转出与迁移。由于 Opus 是我们的标准协议，当这些转换成功的数据进入新版编辑器时，能够通过 Schema 的精准映射，100% 无损还原为内部的 Document Tree，让老文章直接享受最纯粹的组件化编辑体验。

柔性兜底：不支持迁移场景的 H5 动态解析

然而，总有一些极其古老（例如夹杂着 UEditor 时代“野生标签”）且无法安全迁移为 Opus 格式的富文本黑盒。面对这些“硬骨头”，我们并没有采用高风险的“强洗数据”，而是让新版编辑器利用加载 H5 内容的方式进行动态兜底。通过触发节点中预设的 `parseHTML` 规则，在浏览器端实时将陈旧的 HTML 代码“翻译”成全新的规范化 Block Node，确保再老的专栏也能在新编辑器中顺利“复活”并进行二次编辑。

第六章：效果实测与总结

通过这次架构升级，我们将“插卡”这一高频操作的体验提升到了新的维度。但在亮眼的数据背后，我们也完成了一次经典的工程性能博弈。来看一组真实的对比数据：

结论：走向“应用级”文档

从 Quill 到 ProseMirror 的迁移，不仅仅是更换了一个编辑器内核，更是我们对文档理解的一次升级。

文档不再只是静态内容的载体，而是动态应用的容器。

通过 Tiptap + ProseMirror 的现代化技术栈，我们成功将“低保真”的绘图式卡片，进化为具备完整生命周期、状态管理和复杂交互的“应用级”组件。这不仅解决了当下的性能痛点，更为未来引入投票、互动游戏等更复杂的业务卡片奠定了坚实的基础。

我们终于可以说：在 B 站的专栏编辑器里，你看到的，就是真实的 🎉（WYSIWYG）

-End-

作者丨泯泷

往期精彩指路

游戏数据分析Agent的全栈架构演进

Fri, 06 Mar 2026 12:02:00 +0800

原创 AI 2026-03-06 12:02 上海

本文章主要聚焦于最核心的如何落地Agent。

前言

写在前面，由于现在LLM生成内容千篇一律，作者尽量自行撰写核心内容，LLM仅限于润色优化，争取把整个开发迭代历程完整呈现出来供学习交流。

一、背景与挑战

游戏业务随着持续深化，各个岗位对数据的诉求也越来越深入，但游戏数据分析需要结合极强的领域知识和数分技能，具备较高的门槛。

伴随着LLM的能力增强，如果能结合个人多年游戏业务的分析沉淀，将较为通用的分析方法论融入其中，从而帮助到部门同事深化对数据的理解和使用。

实际立项以后，发现也有诸多的挑战和难点等待被攻克。

主要技术挑战和难点

游戏业务日常具备海量的‘黑话’、‘术语’、‘概念’等等，如何真实理解部门业务同事的独有诉求？
LLM 生成的‘不确定性’与数据查询对‘确定性’的高要求之间的矛盾，如何保障查询结果的准确性？
探索游戏数据问题往往需要多种技能，如何让agent自行实现游戏数据分析？
粒度的权限管控挑战，如何在 Agent 中通过自然语言处理复杂的企业级数据安全要求？

二、架构演进之路

整个开发过程中，前前后后实际作者上做了完全不同的3版方案，整个演进过程如下：

v1.0 (LangChain Chain)：线性执行的

局限性，无法处理追问和复杂错误恢复。

初步实现的效果如视频所示（备注：视频演示为测试数据）

需求目标：单一固定场景--实现SDK转化漏斗的自动异动分析

技术选型：基于LangChain(0.x版本)

开发工具：Cursor（Claude 3.7 Sonnet）

选型理由：

异动分析是一个较为固定的开发流程，考虑到实现，最终参考大模型给出的技术选型建议，采用了 LangChain 的链式编排。当时设计了6个步骤：

1. 最新数据读取 → 2. 直接分析(简报) → 3. 分析方案制定 → 4. 分析代码生成 → 5. 代码执行 → 6. 结合产物做深度分析(报告)

主要卡点：

整个链路成功率每一步成功率都不高(产物传递和使用与预期不符)，修改困难，彻底重写了3次也未解决(如下图第三版PRD.md），受限于当时的模型能力和框架能力，即使使用TDD开发也无济于事。

失败总结：

1. 对Agent定制开发的工程化工作量严重低估且当时对Vibe Coding盲目自信，误以为Vibe Coding可以实现一切需求，自身忽略对实现代码的关注

2. 缺乏对LLM相关框架库的深入了解，无法人工debug，且不知道LangChain(0.x版本)自带的框架范式已经落后

（备注：官方于2025.10.22发布重写后的1.0版本，只是名字沿用但已彻底重构）

最新现状：

此场景已经在v3架构上重写并运用于线上重点游戏转化率和指标监控

v2.0 (Dify Workflow)：低代码的瓶颈，

业务逻辑定制化困难。

需求目标：实现一个基于LLM的数据部对话机器人，实现简单的知识问答和直接的搜索查询

技术选型&开发工具：Dify（发音为"滴菲"）

选型理由：自带Rag和权限管理模块，开发简单迅速，快速上线MVP，其他同事也可以共同协作（甚至包括非技术同事）

主要卡点：随着持续迭代，工程项目复杂度已经难以维护（均在海量硬编码，复杂逻辑支持麻烦），调试困难（缺乏详细日志，同时Dify黑盒了不少逻辑），且开发自由度高度受限（部分上下文框架自采集，难以定制修改），基本已达项目诉求的瓶颈

失败总结：

1. 由于Dify是低代码可视化节点编程，项目复杂度过高时，节点编程边际收益逐渐走低

2. Dify也是比较新的项目，bug和功能也不够完善，开发过程中遇到了多次问题还提了git issues

3. 仍有比较有价值的收获，掌握了Dify的插件开发能力（甚至帮友商优化了官方开源插件）

最新现状：

由于方便上手的特性，目前部门其他同事会针对一些简单场景使用Dify开发落地，比如落地上线一些简单的Agent归因分析产品

v3.0 (LangGraph)：直面底层设计，

图与状态的引入与定制。

技术选型：LangGraph + Dify(知识库&前端包装)

开发工具：Cursor(IDE) + CC + CodeX 三持

选型理由：

目前Agents框架主要分为两大类：

选取LangGraph的主要考量：

1. 个人层面：通过了官方的LangGraph认证，理解其核心代码实现，对其能力上下限有一定把握

2. 框架层面：由于之前的教训，对框架的“可控性”和“观测性”有较高的优先级，LangGraph自带企业级3件套（开发、调试、部署平台）

3. 应用层面：知名科技大厂使用LangGraph开发生产级应用，比如Uber、LinkedIn、Elastic、Google等

最终执行实现的效果：

三、核心工程实践

首先明确几个LangGraph概念，这里作者就从更方便理解的角度去描述，更具体的可以查看官方文档：

➢ Graph - 图，本质就是一个Agent/Agents的执行流图，或者说状态转移图

➢ State - 状态，它是一个随执行流转而不断演变的共享数据结构

➢ Node - 节点，实际的逻辑执行

➢ Edges - 边，决定了信息(State)的流向

➢ Threads - 会话线程，就是用户的一个对话窗，可能包含多次与AI的交互（也就是多个Runs）

➢ Runs - 一次Graph的执行，也就是与Agent的单次交互

接下来将详细开展工程化细节

1.整体Graphs设计(Agent)

先来看下Multi Agent的常见架构：

^{(图片取自LangGraph官方文档)}

其实Multi-Agent本质上就干两件事：上下文隔离 与 控制权转移

所以本项目采用的方案更像是Custom自定义的模式。

当前本项目的Graph架构设计是：

Graph整体上分为几块：

初始主控路由分配器，会基于任务类型来做不同粒度的Agent分发（实际上有3条线）
第一条线-简单回复和HITL（最右侧）：简单的追问回复、信息查询、知识库读取等小任务（不涉及实际数据查询，单次tool_call），快速响应
第二条线（中间）：固定式数据查询任务，整体流程上是基于单次查询即可得出的简单任务（比如B游戏上个月的DAU情况），整体分为“找所用表->查询”两步
第三条线（最左侧）：基于Agent Loop的数据分析Agent，用于处理探索性数据分析任务。

其中第三条线是本项目最关键的上下文工程落地案例，整体上这个SubGraph的结构为：TODO 规划 + ReAct 循环。

这么设计主要考虑到tokens和时间消耗的折中，同时对各个环节进行解耦，方便后续持续的重新调整组合。

2.领域知识的“动静结合”

由于数据分析业务场景一定包含了大量的私有领域知识，所以知识的录入对上下文来说非常重要。这里知识来源主要分为两类 静态知识 和 动态知识 。

静态知识：

针对查询的基础通用知识，比如ODPS SQL写法等内容，作为长期不变的内容，目前是通过硬编码在相关LLM请求的SystemPrompt中，更新迭代随着版本再变化。

这类知识目前采用“结构化提示词(Structured Prompt)”方式进行撰写，关于结构化提示词：

1. 不同的模型针对Markdown和XML等结构会有额外的微调，比如claude官方表示他们针对XML做过微调。
2. 结构化提示词就是为利用更加具有逻辑结构的描述，来提高LLM的生成效果，实践效果经过海量的认证。
3. 结构化提示词示例（参考LangGPT）：
'''
# Role: 你是一个游戏数据分析师


## Profile
- Author: 小B
- Version: 1.0
- Language: 中文
- Description: 清晰的角色描述和核心能力


### Skill-1
1. SQL查询
2. 具备查询公司数仓表的能力


## Rules
1. 在任何情况下都不要编造不是查询结果的数据
2. 严格遵循Hive SQL的语法逻辑


## Workflow
1. 分析用户输入并识别意图
2. 系统性地应用相关技能
3. 提供结构化、可操作的输出


## Initialization
作为 <Role>，你必须遵守 <Rules>，你必须用默认 <Language> 与用户沟通，你必须严格遵循 <Workflow> 流程来完成用户需求。请先介绍一下自己的能力范围。
'''

动态知识：

1. RAG-专有知识库

由于已经上线了Dify平台，知识库则正好可以依托于的已经部署完成的Dify来共同管理。

项目所用的知识库主要分为以下几类：

1. 游戏别名：由于同一游戏在业务侧有非常多的叫法，所以对齐游戏称谓是最重要的一件事

2. 游戏基础信息：游戏相关信息的完整表，包括game_id、上线时间，渠道id等关于该游戏的一切基础信息（通过上游多张表预加工合成，定期更新）

3. 指标规则解释：针对日常数分领域常用的指标，对应的介绍、计算方式、维度等信息

专业术语解释：一些额外的游戏业务专业术语、黑话

5. 历史查询案例：数分同学的经典任务case，包含简要描述和对应的SQL语句

知识预处理：

项目的知识库本身都是经过结构化预处理的，主要有以下几步，整体上类似特征工程：

1. 数据清洗(Data Cleaning)，一些异常值剔除、缺省值处理等，比如移除没有上线的游戏，或者已经下线的游戏信息

2. 重聚重塑(Data Reshaping)，比如游戏A不同地区在原始表中是有多条记录，可以对内容做Pivot（如下图将渠道进行降维）

3. 数据格式化(Data Formatting)，合理切分知识内容并转换为表格，从而做到对文档分块时0冗余

实测经过处理以后的知识库，响应的召回率和准确率都有显著上升，比尝试单纯优化Embedding/召回算法带来的收益高得多

2. 注入-场景独有知识

基于场景进行设定的一组Prompt集合，根据不同的key来主动注入给Agent运行的上下文，从而作为追加的Prompt内容，选择性的替换，以应对不同业务下分析路径差异。比如SDK漏斗分析Agent，就是通过配置对应的场景内容，实现了自动深度分析功能。

场景知识主要分为这3个类型：

该场景探索的补充知识 - 对应业务独有的数据分析探索路径，比如先细拆a维度，或者先看同环比等
该场景SQL执行注意事项 - 针对特定业务可能存在一些独有编写注意事项，比如分区格式、时区要求等
该场景的常用表 - 给与Agent一些对应业务相关表信息，避免其发散式的探索。

3.状态管理

Agent开发的设计哲学，就是把一切“必须稳定保存且可被模型读取”的信息抽象成结构化State，并且随着Agent执行进行“有序累积”。

State承担了Agent运行时的上下文核心关键，记录了运行过程中的所有原始信息，并能够随时修改合并，每一次请求的Prompt构成均基于State中存在的信息进行提炼，从而确保了可以每轮对话根据实际需求动态拼接应有的完整Prompt。

LangGraph对State的设计非常巧妙，每一个节点实际上都是一个独立的State实例，节点到下一个节点时，又copy(或合并)了一遍所有参数，从而实现了Checkpointer快照，也解耦了Node之间的上下文，这会带来好几个好处，后续将展开讲解。

本项目的State主要由以下几类构成：

权限与身份：记录当前运行的角色权限模型实例相关
查询上下文：数据分析执行的各种上下文原始数据，包括查询语句及对应的查询结果dataframe等
业务知识注入：前述场景RAG结果和领域知识的原始文本
任务/TODO管理：Agent执行过程中的TODO管理
执行约束：执行计数情况
报告拼装：撰写报告用的提炼内容
SubAgent上下文：SubAgent启动时的上下文及结果返回

针对State处理有2个关键机制实现：

1. 自定义合并函数 由于LangGraph默认的State是采取覆盖的方式，所以针对一些复杂结构需要编写自定义合并函数，以处理上下文传递时的State合并事件，比如任务列表会根据'task_id'进行覆盖或添加操作。

2. 上下文转字符串 State字段均编写了快速转换为String的函数，以便开发时迅速拼接所需的Prompt。

4.上下文工程详细展开：

基础知识

很多没有真实做过Agent开发的朋友是否想过一件事，就是大模型如何知道你的追问的？

其实很简单，就是在Prompt中增加关于历史对话的描述，比如发送给LLM的伪代码示例：

dialogue_prompt = """
你与用户的历史对话为：
Human：你好，我叫小B。
AI：小B你好，很高兴认识你。
Human：我叫什么？
"""


# 这里在最新的用户对话前面追加了关于历史对话的说明
response = llm_client.invoke(
            HumanMessage(content=dialogue_prompt + human_prompt)]
        )
print(response.content) # AI由于已经知道了之前说的内容，所以能正确回复出“小B”。

这就是最基础的Context Engineering例子，仅仅加了一段“历史对话”的文本内容，从而实现了‘多轮对话’的能力！

Context Engineering说白了就是在 合适的时机 传入 恰到好处的上下文内容，从而引导出 正确的响应内容。

Prompt构成

由于分析Agent部分基于Agent Loop，实际上是在进行内部的多轮对话（HumanMessage、AIMessage、ToolMessage等），因此先来看一下本Agent的Prompt构成（每轮对话的Prompt构成）。

User Prompt主要通过XML进行结构化分区设计（这里的User Prompt并不是真的用户，而是每轮loop时给llm的动态Prompt内容，区分于SystemPrompt），主要有以下几个分区：

<用户问题背景> - 包含用户最新的对话问题、历史对话等信息
<已有的游戏信息> - 提前查询到的问题相关游戏基础信息，包含最关键的game_id等枚举值
<指标规则参考> - 对于本次问题的指标解析信息
- 管理todo list，包含todo内容、todo状态和结果摘要
<当前历史执行情况> - 过去的SQL查询执行情况
<最近反思> - 对于过去一段时间的自我反思内容
<同期运营活动调研> - 游戏对应的同期运营活动信息

出于对tokens的最大节约且执行的任务类型偏固定，所以在整体设计上采用每轮对话重新整理Prompt，所以上述User Prompt会在每一次Agent Loop时进行生成，但一般更常见的方式为Messages队列达到特定阈值时进行一次内容压缩。

ReAct架构实现

针对每轮Agent Loop的设计，整个执行架构使用的是中间件模式去处理

1 - 用户问了一个问题，request一次请求进来
2/3/5/7 - 分别的执行生命周期切入点，其中2/7只会执行一次，Middleware包装可以重写任何生命周期函数从而对State进行逻辑编写。其中当5的最新一条消息不为tool_call时则会跳转到7的结束环节，准备返回给用户信息。
4/6 - 分别是AIMessage和ToolMessage响应前的包装器，可以完全控制调用时的参数（包括修改请求时的Prompt）和返回的结果
8 - 返回给用户的AIMessage信息

允许编写任意多个Middleware（每个Middleware可选实现一些生命周期函数），比如一个MiddlewareA和MiddlewareB都可以实现'before_model'和'after_model'函数，然后会根据传入的Middleware顺序根据洋葱模型执行：

1. MiddlewareA.before_model

2. MiddlewareB.before_model

3. model

4. MiddlewareB.after_model

5. MiddlewareA.after_model

^{(图片取自网络)}

从而实现不同Middleware专注于特定的逻辑任务，实现了良好的可扩展可维护性。

Tools设计

实际上Context Engineering很大程度上是对工具调用的结果做信息压缩和筛选。

主要包括工具本身的调用设计和工具结果的信息提炼，基本是每个工具都有对应的一个或者多个Middleware。

另外作者设计工具的大原则是只设计必要的工具，控制工具数量和控制参数，工具名之间避免歧义，从而减轻llm认知负荷。

另外根据langchain官方的实验结论：

- Llama 3.18b fails with 46 tools but performs better with 19 tools
- Dynamic tool selection improved Llama 3.18b performance by 44%

让我们先来看本项目的 工具设计选择 及对应 上下文工程细节，这里选择比较重要的展开：

search_available_tables_tool

说明：表搜索工具，基于表名、表描述等信息的文本匹配搜索

State包含：无State长期留存内容，属于临时查询

上下文工程：

- 自动适配三种权限场景：game_auth 本地白名单、用户自带 ak/sk、默认管理员全表模式。

- 会自动从知识库、数据地图(封装OpenAPI)分别搜索命中的表，会将表名和简述加工成Markdown列表告知模型

table_info

说明：表明细信息查询工具

State包含：当前thread历史查询表的详细信息

上下文工程：

- 提取关键信息表结构+分区+注释+上游任务名

- 会附上最新分区的 3 行预览作为参考（实测有预览数据情况下，SQL生成成功率会显著提高）

- Prompt 注入时统一拼成 `` XML

table_lineage_relationships

说明：指定表的上游血缘表和ETL SQL信息

State包含：无State长期留存内容，属于临时查询

上下文工程：

- 封装数仓OpenAPI相关血缘查询接口

- 原始 ETL SQL 会做压缩，随后由 LLM 提炼为“上游表关系”的摘要信息。

sql_tool

说明：查询能力，兼容用户aksk，多区域自动识别，还支持临时表的DDL

State包含：当前thread每一次查询的任务名、SQL语句、查询结果、查询总结、对应datalayer变量名

上下文工程：

- SQL查询后，会先对语句做语法级压缩后再保存到State，然后结果交由 LLM 生成“详细总结 + 一句话总结”。

- 结构化写入：`description/sql_code/sql_result/summary/summary_one_line/datalayer_variable`。

- Prompt 侧采用分层回放：最近 3 条包含完整结果；4-10 条仅 summary；更早仅 one_line，避免上下文爆炸。

- 支持 `get_sql_task_detail_tool` 按需拉取历史完整结果。

- SQL查询结果的DataFrame，会自动注册到datalayer，仅传变量名而不是整表内容。

think_tool

说明：No-op函数，工具描述会引导AI强制自我反思一次

State包含：最近一次反思的内容

上下文工程：

- 强制“思考-反思”节点，逼迫模型在继续执行前进行决策复盘，参考开源的OpenDeepResearch的实现。

- 上下文工程：写入 `recent_reflection`，仅保留最近一次反思并在下一轮 Prompt 注入，随后自动清空。

notebook_tool

说明：跨Runs关键点记忆（数据库记录），用于Agent记录阶段性结论或重要线索

State包含：当前thread的notebook记载的所有内容

上下文工程：

- 根据配置（支持 memory/db/file 后端），保存当前的存储记忆信息

- 支持对notebook进行增删改查

code_utils

说明：代码执行器模块，用于执行python代码级数据分析动作

State包含：当前thread每一次执行的任务名、代码文件名、执行结果

上下文工程：

- 内置Python沙盒环境，并支持常用数据分析库

- 有datalayer数据层设计，用于沙盒环境与外部的数据交换

- 前述SQL查询结果会自动注册查询结果到Datalayer，并告知变量名

research_subagent

本身其实是一个极简易的ReAct Agent包装为Tool，整体设计如下图：

主要有2个特殊设计：

1. 实现了基于 `(场景, 主题, 问题)` 的内存级 TTL 缓存，对于相同的游戏查询实现毫秒级响应。这在多次重复测试时很有帮助。

2. 针对不同场景挂载不同工具集。针对游戏官方动态、游戏官网的新闻获取，都做了定制化的信息获取工具，以服务于公司发行的各个游戏，同时也是高频分析对象。

Middlewares执行顺序

1. BaseAnalysisMiddleware：构建 Prompt / 执行次数控制 / 处理 AI 响应

2. 工具中间件（N个）：对每类 Tool 的行为做结构化状态更新

3. MessageCleanupMiddleware：清理工具调用的中间消息，避免 context 污染

Tokens优化

实际上对于tokens使用的优化也是需要持续迭代的一件事，项目初步使用了以下技术进行优化：

全链路 Token 可观测性：集成日志级的 Token 消耗计数与追踪，以便评估每一次请求的tokens开销。
语法级 Token 压缩：细扣节省，例如将MD表格语法从"| :--- | ---: |"优化为最简形式"|-|-|"，由于有大量的表格内容，这项就能实际获得约20%的节省。
上下文剪枝：Messages 流精简，在每轮Loop后都会自动清理历史中间状态消息（如 ToolMsg），确保消息流的干净。
混合压缩策略：基于时间衰减与内容语义的上下文压缩，会根据执行轮数对内容做不通程度的压缩。
动态上下文重构：每轮对话根据当前状态重新拼接 Context，也就是前文Prompt构成中提到的每次请求均重新构建完整Prompt。
前缀缓存优化：保持 Prompt 头部尽可能静态，最大化利用 LLM API厂商的响应缓存。
自适应计算预算：硬性限制执行轮数，并根据 TODO List 复杂度动态计算最大步数。
非对称 I/O 优化：利用 Input Token更快的特性，在部门场景上减少Output Token，以提升响应速度，比如问题分类。

回复内容优化

这块其实没有太多建设内容，主要就是采用拼接形式（固定查询&结果）+ LLM分析总结部分，从而确保查询结果的精准性与LLM不确定思考共存。

5.开发效能

俗话说得好，磨刀不误砍柴工。由于LLM输出具备高度的随机性，而且很多bug只会在超长流程后面呈现，所以开发调试能力也是Agent长期迭代的重要保障，接下来讲述围绕本项目相关的内容。

Graphs可视化

良好的可视化对于 Graph 类编程来说不可或缺。虽然 LangGraph 自带绘图功能，但在处理复杂嵌套子图时视觉效果一般，且依赖外部在线服务。

因此，作者基于`pygraphviz`定制了离线可视化引擎`BeautifulGraphDrawer`，核心是通过递归解析节点ID（如`group:subgroup:node`）自动构建`cluster`嵌套结构，并精心调优`ranksep`/`nodesep`等布局参数以实现高密度信息展示，彻底解决了多级Agent从属关系无法直观呈现的痛点。

备注：对应的效果见前文Graph架构设计的渲染图

追踪装饰器

执行自动追踪 - 专门编写了@track_node @track_tool等装饰器，快速实现链路追踪（自动关键日志记录），解耦逻辑编写与debug代码

主要会自动打印以下内容：

track_node：执行的Node名、checkpoint_ns、checkpoint_id、当前的config、执行剩余步数

track_tool：工具名、工具调用参数、调用耗时、调用结果

CompositePromptTemplate

自写CompositePromptTemplate模板类（实现2套API），支持Prompt模版自由组合

额外有个小技巧：因为python代码缩进的关系，建议prompt与逻辑文件分离，从而能更方便的组合Prompt、管理代码逻辑，以及节省少量制表符的tokens

Traditional usage:
    >>> templates = {"greeting": "Hello, {name}!", "question": "How can I help you with {topic}?"}
    >>> prompt = CompositePromptTemplate(templates, "{greeting}\\n{question}")
    >>> result = prompt.format(name="Alice", topic="Python")


Fluent API usage:
    >>> greeting = CompositePromptTemplate("Hello, {name}!").with_name("greeting")
    >>> question = CompositePromptTemplate("How can I help you with {topic}?").with_name("question")
    >>> prompt = greeting.add(question).compose("{greeting}\\n{question}")
    >>> result = prompt.format(name="Alice", topic="Python")

专用日志查看器

由于前述动作诞生了海量日志，为此专门研发了用日志分析工具LogViewer（兼容python的logging日志格式）

主要特性：

支持数亿行超大日志解析
支持实时日志的自动刷新及强制重构
日志标记以及多种过滤模块（模块、级别、时间、正则）
支持不同级别日志及关键词着色
支持多种日志结构预览:PlainText/PythonObject/SQL/Markdown（且支持互相嵌套打开）

Time Travel

前面讲到每一次Node执行实际上都有对应的一个State实例（checkpointer）会保存到数据库，如果能针对性的修改对应的实例并基于修改的实例或者新代码从中途继续执行，能极大加快开发效率，这里就涉及到2项重要的调试技巧：

Replaying：使用新代码重试，使用方式如下：

# 直接以当时的断点处重新开始执行
result = graph.invoke(
    input=None,    # 无需新的输入，不然会开启新的一轮Run
    config={
        'configurable': {
            'thread_id': '1',    # 需保持原先的线程
            # 目标状态的checkpoint_ns和checkpoint_id，已经由 @track_node 装饰器自动输出日志，只需找到填入即可
            'checkpoint_ns': 'info_collection:e21930aa-f8ca-1b78-442a-9a755527f50c',
            'checkpoint_id': '1f071b4d-146b-65e2-8002-fb2b835b828c'}
    })

Fork：修改State实例，使用方式如下：

# 换一种方式获取前一个状态
all_states = [s for s in graph.get_state_history(config)]
to_replay = all_states[-2]
# 这里通过config更新State以后就自动创建了fork
fork_config = graph.update_state(
    to_fork.config,
    # 这里传入替换的State字段
    {
        # 比如这里使用id来实现覆盖对应的历史消息
        'messages': [HumanMessage(content='查询游戏B的LTV数据', id=to_fork.values['messages'][0].id)]     
    },  
)

Model动态配置框架

既然可以快速重放，实际上很多时候简单的修改为更强的模型就能提高执行的成功率，所以作者也简单写了一套快速修改模型的配置框架，实现对使用的模型的一键替换。先设计了多级语义化模型，然后通过配置文件设置实际的使用模型，路由层会根据配置映射不同的Provider实例，从而方便随时进行切换和重新组合Agent各处使用的model。

多级模拟测试环境

都知道本地执行和线上总会有细微差异，所以在推进公司上线流程前，作者会在不同的环境进行测试，分别是：

Jupyter模式：用于验证Agent所有的代码执行逻辑，相关数据均存在本地sqlite，便于修改调试

langgraph dev模式：用于验证Agents的API、异步调用、流式响应输出等能力

本地docker模式：用于验证docker环境下的执行情况，尤其是和环境还有数据库相关的内容

结合以上内容基本可以实现较为快速的开发迭代工作

额外备注

官方提供了企业级的调试平台LangSmith（支持调试本地图，但仍需联网加载框架本身），但具有一定的学习成本且较多功能和云平台绑定，本人开发过程中仅辅助使用。

6.Agent安全：Prompt 层的权限控制

由于是数据分析Agent，关于如何限制AI查询或吐出的数据超过使用者的权限，作者针对这一块的设计做了较多设计

首先支持两种自由度：

1. 基于 认证用户：基于 RBAC权限模型，自动判断当前登录会话用户的对应权限列表（和现有的OLAP平台共享，包括可用表和可用游戏限制）

2. 基于 aksk：由于业务分析师申请过权限更高的个人aksk，所以允许传入私人的aksk，查询时优先使用该aksk创建的client进行查询

关于认证用户的实现也分为两个部分：

1.Agent对用户的身份识别

实际上每一个用户识别是通过上游可信服务进行请求时注入（通过调用graph时设置config参数），Agent自身默认完全信任该身份认证，从而解耦的认证与Agent执行能力。

本项目是第一个python调用游戏权限管理系统的服务，为此专门编写了python版sdk实现，以便后续的开发工作。

# 获取权限管理器单例
auth_mgr = get_auth_manager()


# 查询用户权限
perms = auth_mgr.fetch_user_permissions("username")


# 权限检查
if perms.has_table("biligame_dc.ads_table"):
    print("✓ 有表访问权限")
if perms.has_game_base("23"):
    print("✓ 有游戏基础ID权限")
if perms.has_game("4368"):
    print("✓ 有游戏ID权限")
if perms.has_role("dataDev"):
    print("✓ 有dataDev角色")


# 访问权限列表
print(f"表权限: {perms.tables}")
print(f"游戏基础ID: {perms.game_base_ids}")
print(f"游戏ID: {perms.game_ids}")
print(f"角色: {perms.role_tags}")


# 基于现有权限直接校验 SQL
sql_result = perms.evaluate_sql("SELECT * FROM biligame_dc.ads_table;")
print(sql_result.is_allowed)

2.查询时的动态控制

可以通过前述实例代码中看到，实际上有个基于权限的动态校验SQL能力（见上文最后2行调用）。

这里作者设计取了个巧，对Agent来说实际上并不知道自己的权限，而是采用了一种启发式的探索策略。也就是会有一个权限校验AOP，任何SQL执行前均会进行判断，如果发现权限不足，会模拟查询工具的response，告知查询失败的原因，及用户所拥有的权限。从而让llm根据情况动态调整查询语句，或探索可用表，以及引导用户申请权限。

另外在执行层为最大程度发挥Agent的探索能力，对于查询表信息、元数据等内部执行流程环节，则会统一使用数仓管理员级别账号，仅在实际查询表明细数据时进行动态权限判断。

SQL权限判断实现

这里作者摒弃了传统的正则匹配方案，采用 AST（抽象语法树）语法分析技术，构建了深度防御体系：

1. 语义级的精准解析

引入 sqlglot 库并将方言严格配置为 ODPS/MaxCompute 模式，消除“解析器差异”带来的安全隐患。这使得我们不再是在“字符串”层面“猜”意图，而是在“语义”层面“读”逻辑。无论是 CTE、嵌套子查询还是复杂的 Union 结构，都能被精准递归遍历。

2. 深度逻辑校验

解析后的 AST 会经过一系列严格的检测器：

- 表级权限围栏：标准化提取所有涉及表名（自动处理 odps. 前缀、Alias 别名映射），与用户的 RBAC 权限列表进行比对。

- 数据行级隔离：强制检查是否包含必需的 game_id 过滤条件。针对多表 Join 等复杂场景，采用“最小特权原则”，若无法确定过滤条件是否能通过传递性约束所有敏感表，则直接拒绝执行。

- 逻辑漏洞防御：专门检测能够绕过权限的 SQL 模式，如 OR 1=1（永真式）、OR game_id = 'unauthorized'（逻辑或绕过）、以及对权限字段使用 LIKE/BETWEEN 等模糊匹配操作，一经发现立即拦截。

3. 安全的自动改写

对于权限不足但结构合法的简单查询（如 SELECT * FROM table），Guard 组件支持 Enforce 模式。它直接操作 AST 节点，在 WHERE 子句中构建强类型的表达式对象（Expression Object）注入 game_id IN (...) 条件。

防注入设计：由于全程不涉及字符串拼接，从根源上杜绝了改写过程中的二次注入风险。

4. 基于白名单的防御策略

不同于传统的黑名单拦截（容易被生僻语法绕过），对 Agent 生成的 SQL 还采用“AST 模式白名单”策略。

- 只允许有限的、可被完全语义理解的 SQL 结构通过。

- 任何包含不确定性的语法结构（如复杂的非等值 Join、未知的 UDF 调用、特殊的 Hint 注入）都会触发“解析不确定”警报并回退，迫使 Agent 重新生成更标准的查询语句，或干脆换一种写法。

5. 完善的单元测试覆盖

同时为了验证这套防御体系的健壮性，编写了数十个覆盖各种边界情况的单元测试。这种基于编译器前端技术的安全方案，将原本脆弱的“文本匹配”升级为了坚固的“语义验证”，在保障 Agent 灵活性的同时，也能最大化的避免安全风险。

四、落地与可观测性

内网部署思考

实际上很多网上的方案只有“如何做出Agent”，而没有“如何内网落地”的完整方案，而本项目在Agent开发完后，落地存在2个限制需要考虑：

1. 需要支持公司内网的鉴权登录

2. 存在主动提供ak/sk等定制的场景

结合当前实际的部署情况以及业务使用场景进行了分析：

最后决定基于现有的Dify开源WebUI做二次开发来满足后续的迭代需要，有几个好处：

1. Dify作为长期迭代的开源项目，在整个前后端链路上的协议建设会比作者临时自己搭建思考更全面和完善

2. 屏蔽了LangGraph这类底层服务的直接对外API的不确定性风险（实际上正好避开了后来爆出的比如CVE-2025-64439远程执行漏洞等）

3. 客户端可以复用于部门其他同事创作的DifyAgents

整体架构设计

图中对应关系：

1. Agents实例服务

2. Dify - 提供知识库服务、简易Agent搭建、Agent服务的APP化包装

3. BFF层 - 接入公司权限系统等鉴权服务，从而绕过了外部框架难以集成公司鉴权的问题

4. 自研运维管理服务台 - LangGraph的Agent线程实例监控管理台

5. 自研Cron调度服务 - 一个简易的专用调度服务，以处理定时触发类服务，比如日志、数据巡检

6. Langfuse - 开源LLM运维仪表盘

7. Nginx - Docker内的统一网关，管理不同path对应的服务，以及仅允许前端类服务外部暴露

8. 公司OA系统 - 提供内网认证服务

9. 游戏权限管理系统 - 提供'用户'与'游戏/表'权限的管理

10. 公司LLM网关 - 提供大模型接口调用服务

11. ChatUI - 与Agent交流的对话界面，能够通过iFrame嵌入到其他服务内，从而实现在不同的地方提供用户服务

12. 企业微信智能Bot - 提供用户在企业微信中直接沟通的方式

网络设计

考虑到场景调用量，整个网络拓扑架构未对分布式做过多设计，主要服务于单机配置，安全方面遵守了以下几个限制：

所有服务仅服务于公司内网环境
Agents服务不暴露端口到宿主机，和Dify在同一docker内，从而实现通信的内外隔离
由BFF层负责所有API的用户鉴权管理
docker内建专用Nginx网关，从而确保不同服务的共存

关于nginx的配置，有一些注意点：

# 客户端上传文件大小限制(根据需要调整)
client_max_body_size 100M;


# SSE/流式传输关键配置 - 禁用所有缓冲
proxy_buffering off;              # 禁用响应缓冲
proxy_cache off;                  # 禁用缓存
proxy_request_buffering off;      # 禁用请求缓冲
chunked_transfer_encoding on;     # 启用分块传输编码


# 超时设置(AI 响应可能需要较长时间)
proxy_connect_timeout 60s;
proxy_send_timeout 3600s;
proxy_read_timeout 3600s;

补齐开源短板

Dify通信插件

Dify和LangGraph Agents的链接是通过自研的通信插件实现的

实现的关注点：

协议转换：将 LangGraph 的复杂 Event Stream 实时转换为 Dify 标准 SSE 流。

线程转换：通过 thread_mapping 工具，动态处理LangGraph的thread_id与Dify的conversation_id的转换关系，从而实现两边历史会话记录绑定。

隔离安全：隔离了原生 api 可能吐出过多metadata的问题，因为Dify最后只会返回消息部分了。

全功能运维台

痛点：由于官方开源版本未提供任何运维管理功能，加上Agent的线上运行极有可能需要干预，因此需要自行建设管理台

解决方案：封装 @langchain/langgraph-sdk 全量接口的嵌入式管理台。

核心能力：

- State热修复：支持 patchState，在 Agent 卡死时手动修正变量并恢复运行。

- 记忆可视化：直接查看和清理 KV Store，治理被污染的长期记忆。

- 无状态安全：管理台采用无状态设计，兼容性极佳

自研分布式调度系统

痛点：开源版缺乏Cron支持（企业版是通过官方云LangSmith实现，开源版API是空实现），定时类任务（如日报巡检等）难以落地。

架构设计：基于 Node.js Worker + Postgres 的轻量级调度器。

关键特性：

- 状态保持任务：支持复用 Thread 上下文的连续任务（如“基于昨日分析继续生成今日日报”）。

- 逻辑线程映射：设计 (logical_id, api_url) -> actual_thread_id 映射机制，解决多实例部署下的状态保持问题。

- 可靠性：支持优先级设定、多种并发策略及企微告警闭环。

WebUI设计

由于产品最终还是需要面向用户，所有针对WebUI做了一些专门产品化的设计

1.思维链可视化：前端深度解析 SSE 流，可以选择折叠/展开过程。联动了代码中写的一个便捷函数"emit_thinking"，从而产生实时反馈，缓解用户等待焦虑。

2.可选深度分析：给用户一个选择，可以强制激活深度分析链路。

3.快速用户反馈：作者认为获得真实的bad case对于迭代属于重中之重，所以专门设计了一个快速用户反馈功能，方便用户数秒内完成反馈。

4.更新日志提醒：考虑到很多版本的变动对用户感知不强，用户难以知道产品是否有在持续迭代，所以专门做了版本更新提醒模块。

5.自定义启动：由于允许用户填入自有aksk（会话级记忆），制作了专门的启动填入UI。

6.结构化渲染：会自动拦截 Agent 生成的 CSV 数据，动态渲染为 ECharts 可交互图表。

7.全屏水印：出于安全考虑，WebUI集成了全屏水印，以防数据泄露等情况。

最后的FAQ

关于打包

对于LangGraph编写的Agents，主要有3种打包方式：

如果使用langgraph build担心数据未经许可的上报，可以在环境变量内加入：

LANGSMITH_PROJECT=xxx
LANGSMITH_API_KEY=xxx               # 填入自己申请的Key，官方仅用来做build记录，不会上报其他数据
# 加入以下配置
LANGCHAIN_TRACING_V2=false          # 关闭 LangSmith tracing，避免对话数据上报
LANGSMITH_TRACING=false
LANGSMITH_DISABLE_SAAS_RUNS=true    # 强制 CLI 运行在本地/离线模式

经过作者抓包实测和源码解析，如上配置后不会上报到官方SaaS运维平台LangSmith。

打包注意事项：

1. 使用langgraph build构建报错 `requires LANGSMITH_API_KEY`是因为强依赖该Key，必须填入。

2. 如果构建时修改了一些关联开源库，可以引入wheel包，同时注意“构建时 `relative path` 错误：`uv` 和 `pip` 处理相对路径行为不同”。可以在 `pyproject.toml` 中引用本地 wheel 包时，务必在 Docker 环境中使用绝对路径（如 `file:///deps/DataChat/wheels/...`）

其他注意事项

1. 记得优化模型的RPM、TPM限制，不然可能会出现意料之外的报错

2. 公司内网的SLB可能有单独的超时限制，需要调大，不然Dify的SSE会存在难以排查的timeout

3. 如果有使用到matplotlib库，在Docker无头环境中，务必设置 `matplotlib.use('Agg')`，否则会因为找不到GUI后端而crash

五、总结与展望

过去的2个月整个Agent行业也发生了翻天覆地的变化，但这个项目其中很多经验具备长期价值，所以依旧撰写了此文。

本文章主要聚焦于最核心的如何落地Agent，受限于篇幅，一些较大篇幅的内容并未详细开展描述，比如“Vibe/Spec Coding”、“记忆体系”、“评估器”、“HITL(Human-in-the-loop)设计”等内容，感兴趣的读者可以自行进一步了解。

对本项目未来的规划：

1. 使用最新的架构和方法论重写一遍

2. 进一步降低使用门槛，允许Agent查询敏感权限数据但是最终报告脱敏，只给调研结论（现在被权限卡住的人太多）

3. 丰富Skills，沉淀更多业务分析技能

4. 完善共享记忆，能够实现跨项目知识能力提升

5. 优化HITL流程

等等

相关资料：

LangGraph官方文档：https://docs.langchain.com/

LangGPT结构化提示词：https://LangGPT.ai

推荐一个UP主：沧海九粟 https://space.bilibili.com/28357052

-End-

作者丨小B

往期精彩指路

视频生成推理加速实践：基于全局时间索引的序列并行 3D 位置编码优化

Fri, 13 Feb 2026 12:01:00 +0800

原创 AI 2026-02-13 12:01 上海

本文分享B站在视频生成模型推理优化中的一系列实践，重点围绕分块自回归视频模型在序列并行场景下的计算与通信优化展开。

一、Self-Forcing：

从 Wan2.1 到因果视频推理

Wan2.1：全帧并行的视频扩散模型

Wan2.1 是阿里巴巴团队开源的大规模视频生成基础模型，基于主流的扩散 Transformer（DiT）架构，并采用 Flow Matching 作为训练框架，在多个视频生成评测基准上展现了领先的生成质量。

在模型设计上，Wan2.1 采用典型的全时空并行建模思路。模型使用 Full Spatio-temporal Attention，使得所有视频帧在时间和空间维度上完全互相可见，从而实现双向的信息流动与全局一致性建模。视频首先通过 3D Causal VAE 被压缩到 4×8×8 的时空比例，latent 维度为 16，文本侧则使用 umT5 编码器，将中英文输入映射为 512 tokens、4096 维的语义表示，并通过 Cross-Attention 注入到生成过程中。

从规模上看，Wan2.1 同时提供了面向效率和质量的不同版本：1.3B 模型采用 1536 维隐藏层、30 层 Transformer 和 12 个注意力头，更适合资源受限场景，14B 模型则扩展到 5120 维隐藏层、40 层 Transformer 和 40 个注意力头，以追求更高的生成上限。

在推理阶段，Wan2.1 会一次性处理所有视频帧，通过 40–50 步去噪迭代生成完整视频。这种全帧并行的生成方式在中短视频场景中能够有效保证时序一致性，但其设计假设也直接决定了模型在更长视频和实时推理场景下会遇到不可回避的瓶颈。

全局扩散模型在长视频推理中的瓶颈

随着视频长度的增加，基于双向全注意力的扩散模型逐渐暴露出结构性问题。首先是显存和计算复杂度的快速膨胀。自注意力的复杂度为 O(N²)，其中 N 为 token 序列长度。以 Wan2.1 生成 5 秒、16 FPS、832×480 分辨率视频为例，经过 VAE 压缩后仍然会形成约 3 万级别的 token 序列，当视频长度翻倍时，注意力相关的显存需求将增长至原来的四倍，这使得单卡生成更长视频变得困难。

其次，全局并行注意力隐含了固定长度假设。由于所有帧必须同时参与计算，模型在训练阶段通常就需要设定最大帧数，当推理阶段希望生成更长的视频时，只能通过滑动窗口或分段拼接来变通处理，而这往往会带来明显的时间接缝和长程一致性退化，模型本身并不具备自然向更长时间轴扩展的能力。

更重要的是，这种双向依赖的建模方式使得模型无法进行流式推理。由于当前帧的生成会受到未来帧的反向影响，系统必须等待整个视频生成完成后才能输出结果，首帧延迟往往达到数十秒甚至更长。这种“离线式”的推理模式显然无法满足实时交互、在线生成或视频续写等应用需求。

这些问题并非简单的工程优化可以解决，而是源自全局扩散模型在时间建模上的基本假设。

Self-Forcing：用因果生成重构视频扩散推理

Self-Forcing 提出了一种因果自回归的视频扩散训练与推理方式，其核心思想是将 Wan2.1 这类全帧并行模型，改造为只依赖历史信息的逐步生成模型，同时避免传统自回归模型中常见的误差累积问题。

在模型结构上，Self-Forcing 引入因果注意力约束，使当前帧只能关注历史帧而无法“看到”未来信息。这一约束通过 Block Mask 施加在注意力计算中，并配合 Flex Attention 实现高效计算。由于满足因果性，模型在推理时可以安全地复用历史帧的 Key / Value，从而引入 KV 缓存机制，避免在每一步生成中重复计算已经确定的上下文。

在此基础上，Self-Forcing 采用逐块生成策略，将视频按帧或按小段 latent 分块生成。每一块完成去噪后，其结果会被写入 KV 缓存，作为后续生成的上下文；当缓存达到上限时，通过 Rolling KV Cache 自动淘汰最早的 tokens，从而在有限显存下支持任意长度的视频生成。这种设计将注意力的峰值复杂度从 O(N²) 降低到 O(B×N)，其中 B 为单次生成的块大小。

从工程实现上看，Self-Forcing 使用 CausalWanModel 替代原始 WanModel，并在注意力层中系统性地引入因果掩码、KV 缓存以及编译级优化。在保持训练与推理一致性的前提下，模型在生成质量上与 Wan2.1 基本持平，VBench 指标甚至略有提升，同时将首帧延迟降低到亚秒级，并在单卡 H100 上实现了接近实时的视频生成速度。

总体而言，Self-Forcing 并不是对 Wan2.1 的局部加速，而是一次从全局扩散范式向因果推理范式的结构性转变，为长视频生成、流式推理和实时交互提供了可行的技术路径。

二、推理优化工作详解

序列并行实现

官方的 Self-Forcing 实现并未支持序列并行（Sequence Parallelism, SP），这在单卡显存受限、尤其是长视频推理场景下，成为扩展模型能力的主要瓶颈。为了解决这一问题，我们的算法团队在 Self-Forcing 因果注意力的基础上，参考 Megatron 以及 Ulysses 的设计，引入了对 SP 的完整支持。

在 SP 模式下，序列维度被均匀切分到多个并行 rank 上，每个 rank 仅持有长度为的局部序列。整体的计算流程如下所示：

在实际的性能分析中，我们注意到两个关键问题：一方面，RoPE 在整个自注意力模块的计算中占据了显著的时间比例；另一方面，现有 Causal RoPE 的实现需要完整序列信息，其计算依赖于前面的三次 all-gather 通信，导致 RoPE 无法与通信阶段重叠执行，从而进一步放大了通信带来的性能损耗。

在 Self-Forcing 的分块自回归生成中，时间位置需要通过全局偏移来编码，这使得 RoPE 的计算逻辑相比传统实现有所不同。为了保证 KV Cache 与因果注意力的一致性，我们需要在序列分片内部正确应用全局时间索引，实现 Causal-RoPE 的局部化计算。

分块自回归下的旋转位置编码

Wan2.1 使用的 3D Rotary Positional Encoding 与 Qwen2.5-VL 中的多模态 RoPE（M-RoPE）在设计上是一致的：将旋转频率在维度上拆分为时间（temporal）、高度（height）和宽度（width）三部分，从而对视频 token 的三维空间位置进行编码。

在具体实现上，Qwen2.5-VL 采用传统的 cos/sin 形式，并通过 rotate_half 实现旋转：

q_embed = (q * cos) + (rotate_half(q) * sin)

而 Wan2.1 则直接使用复数形式来表达旋转操作，将 RoPE 显式建模为复平面上的乘法：

# freqs 在 rope_params 中已通过 torch.polar 转换为复数
freqs = freqs.split([c - 2 * (c // 3), c // 3, c // 3], dim=1)
x_i = torch.view_as_complex(x[i, :seq_len].to(torch.float64).reshape(
    seq_len, n, -1, 2))


freqs_i = torch.cat([
    freqs[0][:f].view(f, 1, 1, -1).expand(f, h, w, -1),
    freqs[1][:h].view(1, h, 1, -1).expand(f, h, w, -1),
    freqs[2][:w].view(1, 1, w, -1).expand(f, h, w, -1)
], dim=-1)


x_i = torch.view_as_real(x_i * freqs_i).flatten(2)

这种实现方式更贴近 RoPE 的数学本质，其核心等价关系可以写为：

在 Self-Forcing 框架下，为了支持分块因果推理与 KV Cache，引入了额外的

start_frame 参数，用于显式指定当前生成块在全局时间轴上的起始位置：

def causal_rope_apply(x, grid_sizes, freqs, start_frame=0):
    freqs_i = torch.cat([
        freqs[0][start_frame:start_frame + f].view(f, 1, 1, -1).expand(f, h, w, -1),
        freqs[1][:h].view(1, h, 1, -1).expand(f, h, w, -1),
        freqs[2][:w].view(1, 1, w, -1).expand(f, h, w, -1)
    ], dim=-1)

通过这一改动，3D RoPE 被自然地扩展为适用于分块自回归生成的因果形式。对于时间–空间位置为

的 token，其位置编码可以形式化表示为：

其中，全局时间索引定义为：

这里为块索引，为块大小。以 chunk-wise（每块 3 个 latent 帧）为例，不同生成块对应的 start_frame 分别为 0、3、6 …，依此类推。

如果仅使用局部时间索引，不同块中处于相同相对位置的 token 将获得完全相同的位置编码，从而导致全局时间顺序混淆，并使 KV Cache 中的位置信息失真。通过显式引入全局时间偏移，Causal-RoPE 保证了位置编码与自回归生成顺序之间的一一对应关系。

局部计算的可行性

在序列并行设置下，序列维度被划分到个并行 rank 上。对于 rank ，其负责的序列区间为，其中。由于 token 在序列中按照"帧优先"的顺序排列，序列切分在效果上等价于对时间维度的近似划分。对于 rank 中局部索引为的 token，其对应的全局序列位置和全局时间索引分别为：

其中为当前块的 start_frame。可以看到，对每个 token，Causal-RoPE 的计算仅依赖其自身特征、全局时间位置以及共享的频率参数。在分块自回归 + SP 的组合下，我们通过在每个 rank 内应用正确的全局时间索引，实现了 RoPE 的完全局部计算，无需额外跨 rank 通信，同时保持了因果一致性。

这一结论为后续的优化提供了理论基础。

实现方案与性能对比

基于上述分析，我们将 RoPE 的计算下沉到序列分片内部，先在本地完成 Causal-RoPE 的计算，再通过一次融合的 all-to-all 通信，同时完成序列维度与注意力头维度的重排，从而替代原始实现中的三次 all-gather 和一次 split 操作：

在第一阶段优化中，我们进一步缓存 RoPE 所需的 sin/cos，并基于 TileLang 实现算子融合，相比社区常见的 Triton 实现获得了约 10% 的性能提升，整体优化方案的 profile 结果如下所示：

在一次典型的 5s 480P 视频推理中，会触发 920 次的自注意力计算，整体耗时降低约：

相比优化前 8.86s 的端到端耗时，整体推理性能实现约 1.48× 无损加速（≈47.5% speedup），与实际的实验结果高度一致。后续我们在做计算图优化的时候，注意到 RoPE 的缓存逻辑对整图优化不友好，进一步将动态的缓存逻辑改成了预计算逻辑，并将结果存储在连续张量中，绕过 Host Op，在推理过程中直接在 GPU 上进行寻址，使用预计算的 cos / sin 对输入张量进行旋转编码计算，优化了 CUDA 的计算流，实现了计算性能的进一步提升。

三、总结与展望

本文分享了我们在视频生成模型推理优化中的一系列实践，重点围绕分块自回归视频模型在序列并行场景下的计算与通信优化展开。除上述工作外，我们还在低比特量化、计算图优化等方向持续探索，为后续更大规模、更低延迟的视频生成系统打下基础。

-End-

作者丨storyicon、在喝可乐的派派

往期精彩指路

视频生成推理加速实践：基于 torch.compile 的整图编译优化

Wed, 28 Jan 2026 12:03:00 +0800

原创 AI 2026-01-28 12:03 上海

视频生成模型的推理优化是一个多层次、系统性的工程挑战。

一、引言：从算子级优化到计算图级优化

视频生成模型的推理优化是一个多层次、系统性的工程挑战。在模型推理的早期阶段，优化重点通常集中在算子层面，例如通过优化卷积、注意力等核心算子的计算效率来直接提升浮点运算性能。然而，随着单算子性能逐渐逼近硬件极限，计算图层面的优化便成为释放更大潜力的关键。计算图优化关注的是算子之间的调度、内存复用以及控制流开销，其核心在于提升整体执行图效率。一个高效的执行图能够最大限度地减少框架与硬件的交互开销，避免不必要的内存搬运，并使得更激进的算子融合与内存规划成为可能。

本文将聚焦于推理执行流程本身，探讨如何借助 torch.compile 对 Self-Forcing 的推理流程进行整图编译（full graph compilation），以系统性地降低 Python 解释与调度开销，并为后续更深层次的图级优化奠定基础。

二、Self-Forcing 推理特性

与整图编译的挑战

Self-Forcing 是一种将 Wan2.1 等全帧并行扩散模型改造为因果注意力架构的训练与推理范式。与传统双向扩散模型在推理阶段需要同时处理全部视频帧不同，Self-Forcing 采用逐块（block-wise）的自回归生成策略：每次生成一小段 latent（通常为 3 帧），并通过 KV Cache 复用历史上下文。

在这种设计下，注意力计算的复杂度由传统扩散模型的下降为，其中 B 表示单次生成的 block 大小。这一特性使得 Self-Forcing 在低延迟、流式视频生成等应用场景中具备显著优势。

从编译优化的角度看，Self-Forcing 的实现同时具备“适合编译”和“难以编译”的双重特性。一方面，其推理过程高度结构化，计算模式在每个 step 内基本固定；另一方面，原始实现中广泛存在以下问题：

1）依赖张量值的 Python 控制流；

2）通过 .item()、tolist() 等方式将张量退回 Host 端；

3）KV Cache 的动态索引与切片操作；

4）Python 层缓存与调试逻辑的混入。

上述因素都可能会在 torch.compile 过程中触发 Graph Break，使编译器只能生成多个碎片化的子图，从而难以获得实质性的性能收益。

三、整图编译策略与实现选择

在具体实现上，我们采用了一种渐进式的优化策略：首先对关键模块使用 torch.compile 进行局部封装，以评估其潜在收益；随后，在此基础上系统性地识别并消除 Graph Break，逐步推进至整图编译（Full Graph Compilation）。

我们最终选择在注意力模块（CausalWanAttentionBlock）的 forward 方法上使用如下配置：

@torch.compile(dynamic=True, fullgraph=True)

其中，dynamic=True 允许编译器以符号形状（symbolic shapes）的形式表示部分运行期才能确定的维度，从而在不触发额外 graph break 或重新编译的前提下，支持一定范围内的输入形状变化。这一特性在进行前期优化的时候比较重要：尽管单次推理的视频分辨率和总帧数通常是固定的，但序列在多卡之间的切分方式、以及 KV Cache 在不同 step 中的有效长度与写入区间，都可能会引入运行期的形状差异，通过符号化这些维度，可以避免因形状变化而频繁触发重新编译，从而提升整体推理稳定性与性能。

fullgraph=True 则是实现整图优化的关键。该选项要求整个函数必须被编译为单一 FX 计算图，一旦遇到无法追踪的操作便直接报错并中止编译。虽然这一“严格模式”显著提高了工程改造的难度，但它能够在编译阶段完整暴露所有潜在的 Graph Break 点，避免隐式的子图切换开销，并为后续的算子融合和 CUDA Graph 捕获提供必要前提。

在实践中，fullgraph 模式的价值不仅体现在最终性能上，更体现在其对代码结构与数据流设计的“约束”作用。

四、Graph Break 的成因分析与消除方法

在本章节中，我们的代码示例基于 Self Forcing 的 官方实现（https://github.com/guandeh17/Self-Forcing），部分提及的序列并行代码基于内部工程实现。

控制流与标量提取

在 torch.compile 中导致图断开的最常见原因之一是 Python 端语义依赖于运行时张量值。在 Self-Forcing 的原始实现中，大量逻辑通过 .item() 将张量转换为 Python 标量，用于计算序列长度、帧索引以及 KV Cache 的读写位置，例如：

frame_seqlen = math.prod(grid_sizes[0][1:]).item()
local_end_index = kv_cache["local_end_index"].item() + current_end

在 fullgraph=True 模式下，这类代码会直接触发如下错误：

Unsupported Tensor.item() call with capture_scalar_outputs=False

尽管 PyTorch 提供了 capture_scalar_outputs=True 来支持此类用法，但该方案会引入额外的 Host-Device 同步和标量封装开销，并削弱编译器对数据流的静态分析能力。因此基于性能考虑，我们选择彻底消除 .item() 调用，而不是依赖该选项。

核心思路是：只要某个量可以在 GPU 上以张量形式计算，就应避免将其退回 CPU。例如，上述代码可以改写为：

frame_seqlen = torch.prod(grid_sizes[0][1:])
current_start_frame = current_start // frame_seqlen

更加概括的说，我们在推理热路径上系统性地移除了所有张量到 Python 的转换操作，包括但不限于：

.item()
int(tensor)
.tolist()
其他类似的标量化操作

原因在于，从 torch.compile 的视角来看，Tensor 并不等价于具体数值，而是一种可被分析和优化的计算关系表示。一旦中间结果被转换为 Python 对象，相关数据依赖将很有可能脱离编译器的控制范围，导致计算图无法被完整捕获和优化。相反，保持计算逻辑完全以张量形式表达，有助于最大化编译器的优化空间，并确保推理过程中 CUDA 执行的高效性与并行性。

数据依赖与动态形状

另一类更为隐蔽的 Graph Break 源于数据依赖导致的动态形状推导失败。在 RoPE 的计算逻辑中，原始实现通过 tolist() 将 grid_sizes 张量转换为 Python 列表，并在循环中动态计算序列长度：

for f, h, w in grid_sizes.tolist():
    seq_len = f * h * w
    x_i = x[i, :seq_len]

这一实现同时引入了两个问题：一方面，tolist() 本身会触发 Graph Break，使相关计算逻辑脱离计算图；另一方面，由图外标量 f、h、w 参与计算得到的 seq_len 被用于张量切片，导致编译器无法为输出张量的形状建立有效的符号约束。最终，这种数据依赖关系会在编译阶段表现为守卫失败（data-dependent guard failure），报错如下：

Could not guard on data-dependent expression u0*u1*u2 < 0 (unhinted: u0*u1*u2 < 0).  (Size-like symbols: none)

但事实上，从推理优化的角度来看，这种实现方式本身是不必要的。对于 Self-Forcing 推理流程而言，grid_sizes 实际由视频帧数、latent 分辨率以及 patch 大小共同决定，而这些参数在推理服务启动时就已经确定，或仅存在有限几组离散取值。因此，在推理优化场景中，我们将 grid_sizes 视为配置期常量，并针对固定配置对计算图进行特化（specialization）。

尽管这种做法在形式上降低了实现的通用性，但在推理系统中，为固定分辨率和序列长度构建多组计算图是一种常见且行之有效的工程实践。其设计思想也与 CUDA Graph 实践中的分桶（bucketing）与填充（padding）机制高度一致。

KV Cache 的动态索引问题

KV Cache 的读写是推理代码中导致 Graph Break 的另一个高频来源。原始实现中，KV Cache 的访问依赖于运行时计算得到的索引：

# local_start_index 和 local_end_index 是 Tensor 类型
# 读取 KV Cache
x = kv_cache["k"][:, local_start_index:local_end_index]
# 写入 KV Cache
kv_cache["k"][:, local_start_index:local_end_index] = roped_key

由于当前主流版本的 torch.compile 实现尚不支持将张量作为切片边界，上述代码在 fullgraph 模式下会导致编译失败。

通过对因果注意力具体计算过程的分析可以发现，在未启用滑动窗口注意力的前提下，KV Cache 的访问范围实际上具有明确的闭式解：历史 KV 的读取起点始终为 0，而写入位置则可以由全局序列起始位置 current_start 与当前 block 的 token 数直接确定。在序列并行（SP）场景中，由于 attention 计算开始前已经完成了当前 block 所有序列的 all-gather，这一结论同样成立。

基于上述观察，我们将 KV Cache 中依赖运行期索引的动态切片逻辑重构为等价的静态索引访问，并在工程实现中通过自定义的 tilelang kernel 实现高效写入。该改造不仅彻底消除了由 KV Cache 读写引发的 Graph Break，也在实际推理中带来了较为明显的性能收益。

Host 调用与 Python 层缓存

除了张量相关的问题，Python 层的缓存与调试逻辑同样可能会破坏整图编译。例如，社区中常见的 RoPE 优化方案通常使用 LRU 缓存 cos/sin 值，但该缓存机制依赖 Python 字典的状态更新，推理过程中仍会引入 Host 端参与。

在实际工程中，我们将这类依赖运行期状态的动态缓存改写为预计算逻辑：在模型初始化阶段提前生成所需的 cos / sin 张量，并以连续 Tensor 的形式常驻于 GPU 显存中；在推理阶段仅通过张量索引完成访问，从而彻底消除 Python 侧的参与。

类似地，诸如 time.time() 等调试代码也会直接触发 Graph Break，应该在优化阶段彻底移除。

五、实验结果与总结

在完成 Graph Break 的系统性消除并启用整图编译后，我们在生成 5 秒、480P 视频的推理任务上进行了性能评测，模型规模为 14B 参数。消融实验结果表明，仅通过 torch.compile 的整图优化，便可在端到端层面获得约 47.6% 的加速效果，将推理耗时从 8.86 秒降低至 6.00 秒，且未观察到明显的精度退化。

综上所述，本文展示了在自回归视频生成推理场景下，基于 torch.compile 实现整图编译的一套工程实践经验。我们的经验表明，整图编译的核心价值并不仅在于“自动加速”，更在于其对数据依赖、控制流以及工程实现方式所施加的强约束。这种约束能够显式暴露系统中的隐性复杂度，为进一步的底层算子融合与系统级优化奠定基础。

-End-

作者丨storyicon、在喝可乐的派派

往期精彩指路

05 B站游戏大模型翻译实践 —— 我们如何用LLM撑起全年百万字本地化翻译任务

文末有礼丨2025年哔哩哔哩技术精选技术干货

Thu, 01 Jan 2026 12:04:00 +0800

陪你跨年的 2026-01-01 12:04 上海

一键收藏2025年哔哩哔哩技术最受欢迎的20篇文章！

哔哩哔哩技术

时光匆匆，【哔哩哔哩技术】公众号又与大家携手走过了充实的一年。2025年我们共精心打造了56篇原创技术文章，全方位、多角度地剖析了各类前沿技术与实用业务应用。今天，我们特别挑选出 2025 年度广受好评的 20 篇文章，汇集成这份年度精选干货，邀您一同回顾那些闪耀着智慧光芒的技术瞬间，汲取宝贵的知识养分，激发新的灵感火花！

哔哩哔哩技术精彩回顾（点击标题查看）

👇 👇 👇

01 B站消息新架构升级

IM系统是一个老生常谈的话题，也是融合众多有趣技术难点的地方。当技术上数据量越大，降级概率越大，但消息业务场景上数据量大的是影响力更大的UP，业务不接受技术降级，如何破？如果消息流量增加10倍，怎么保障服务不挂？本文基于以上命题，阐述了优化一个数据密集型 >> 计算密集型，读多写少（首页未读数）、读少写多（会话）场景兼具的系统，同时拥有热门C端产品的稳定性、扩展性和好的业务域解耦。

02 大会员交易系统建设

B站大会员交易系统，基于传统电商交易系统架构上适配虚拟物品业务，采用模块化架构，涵盖交易、订单、签约、商品、营销、清结算、规则配置等核心模块，搭载支付 SDK、风控等能力，通过事务控制、分布式锁、对账、分级业务限流等保障数据与资金安全，支撑多业务高效运转，适配个性化接入需求。

03 服务器故障管理实践

服务器故障管理实践总结了B站在服务器规模快速扩展下，故障检测与维修自动化的探索。文章介绍了故障分类、传统人工管理的不足，以及自动化故障检测与维修方案，包括带内/带外信息采集、统一故障规则库、自动化任务流转和资产更新。通过自动化系统，提升了故障发现、定位和处理效率，实现了高覆盖率和准确率。未来将继续推进智能化监测和更高效的故障管理。

04 Apache Celeborn 在B站的生产实践

B站完成 Apache Celeborn 大规模落地，替代 ESS 与 Push-based Shuffle，实现 Spark/Flink/MR 统一 Remote Shuffle 服务。构建元仓、HBO 智能路由、诊断治理、混沌测试、故障自愈等闭环运维体系，滚动升级与灰度发布零中断。Celeborn 承载 70% Shuffle 流量，单作业最大 200 T，日均 27 PB，显著降低 Fetch Fail 与重算，作业稳定性大幅提升；混部低优集群释放空闲资源，集群降本增效明显。后续将推进潮汐弹性、优先级 IO 调度、Remote Spill、Native 引擎集成及更多 Fallback 策略，持续与社区共建云原生中间数据服务新标准。

B站游戏自研翻译大模型体系，专为游戏本地化场景打造，覆盖 UI、技能、剧情等多类高复杂度文本。通过 RAG 检索增强、自动术语挖掘与 LLM 质检闭环，在保障角色语气与术语一致性的同时，实现翻译效率提升 7 倍、成本降低 70%+，稳定支撑 10 语种、全年百万字级本地化交付，为游戏出海提供强有力的技术支撑。

06 B站在KMP跨平台的业务实践之路

我们以一个实际业务视角，总结我们在使用 KMP 的 Share Logic 和 Share UI 两种模式在三端落地的经验与 infra 工程建设的互补，并总结了一套方便日常开发快速接入使用的框架和开发范式。

07 B站搜推大规模召回系统工程实践

召回作为搜索和推荐系统的首要环节，其性能直接决定了系统效果的上限。随着B站业务快速发展，搜推召回系统面临着数据规模爆炸式增长、算法策略日益复杂、时效性要求不断提高等严峻挑战。本文从工程实践角度，详细阐述了B站如何构建一套云原生、可扩展、配置化、搜推统一的大规模召回系统。希望对读者有所启发。

08 B站是如何实现原声视频翻译的

本文聚焦B站原声视频翻译的技术革新，其核心能力在于实现中文视频向多语种的“原声风格”沉浸式转化，突破传统配音的标准化局限与字幕的认知负担，完整保留原说话人音色、情绪与节奏，且达成口型与语音的自然适配。

技术层面，以BILIBILI IndexTTS2模型为核心，通过感知一致性建模破解跨语言音色偏移、情绪迁移等痛点；依托RIVAL对抗式强化学习框架与Deep Search技术，保障翻译精准度、风格适配性及专有名词翻译质量；再经字幕消除与Diffusion模型驱动的唇形同步技术，实现音画协同。

该技术降低了内容全球化成本，推动跨语言传播从“互通”向“共鸣”升级。未来B站将拓展语言覆盖、适配多元场景，并计划开源核心模型，助力全球内容生态构建。

09 B站票务抢购下单流程演进

由于近年来漫展、电影等文化产业的消费力复苏，系统频繁承载高并发抢购场景（如漫展门票）。然而，热门项目库存远低于市场需求，传统架构在高并发场景下面临性能瓶颈。如何保障系统稳定性与用户体验，成为核心挑战。本文介绍了B站票务抢购下单的演进迭代过程，从实战经验中为大家整理了一些高并发场景的应对策略。

10 B站社群AI智能分析系统的实践

社群 AI 智能分析系统是一套完全由 AI 驱动和自动实时运行的用户反馈分析与决策系统。通过对社群反馈内容进行话题聚合与意图识别，引入群体共振、话题热度和情绪变化等指标，系统能够从大量碎片化发言中快速识别具有代表性和风险性的关键问题，并自动生成预警或工单，推动问题流转与处理闭环，提升社群治理、产品优化与运营决策效率。

11 B站自研的第二代视频连麦系统（上）

B站基于 WebRTC 重构了视频连麦系统，本文从客户端角度介绍第二代视频连麦系统如何使用标准 WebRTC API 以符合其设计的方式接入视频连麦业务，并为后续服务器端（选择性转发服务器，SFU）篇做铺垫。

12 CIKM'24 : 更快的批量KV查询系统

针对 B 站推荐场景中亿级用户与海量多模态特征带来的 Memory Wall 挑战，本文介绍了入选 CIKM '24 的高性能分布式批量 KV 查询架构。

本文介绍了核心自研HashTable算法 NeighborHash ，利用 Lodger Relocation（寄宿重定位）与双向 Cacheline 感知探测，将平均内存访问次数压缩至物理极限的 1.12。结合 AMAC 异步指令流水与 SIMD 向量化加速，实现了查询吞吐的大幅提升。

系统架构层面，采用 NVMe + io_uring 的冷热分级存储策略与强一致性版本控制协议，以极低的成本开销支撑了海量特征吞吐。

13 RAG在B站大会员中心数据智能平台的应用实践

本文介绍 RAG 技术在 B 站大会员中心数据智能平台的应用，解决 LLM 生成 SQL 的幻觉问题，搭建完整技术架构，实现自然语言转精准 SQL，大幅提升数据查询效率，同时阐述现存挑战与后续优化方向。

14 构建可扩展的智能体系统：工程化方法与实践(一）

2024年下半年写这篇文章时，我们还在小心翼翼地探索：怎么让AI不胡说八道？怎么让它记住上下文？用LangChain还是自己写？每个选择都像在黑暗中摸索。

一年过去，这些"小众研究"已经变成了入门教程。Agent开发从少数人的实验，变成了大规模的工程实践。技术迭代快得让人眩晕，但回头看，当时那些看似笨拙的尝试——比如用多重验证对抗幻觉、用模块化应对不确定性——反而成了今天仍然适用的底层逻辑。

AI的进化速度可以很快，但工程的本质问题不会变。

15 VibeCut - 智能剪辑探索与实现

视频剪辑长期面临专业软件门槛高与模板工具创意受限的“两难”困境，如何填补全手动与全自动之间的鸿沟成为行业难题。本文基于WebCut平台，深入探索并实现了一款智能剪辑体——VibeCut。该系统采用创新的计划者-执行者(Orchestrator-Executor)双智能体架构，通过引入结构化的共享上下文(Shared Context)作为唯一事实源，有效解决了传统多智能体协作中的上下文丢失与错误累积问题，实现了任务规划与工具执行的解耦。在原型实践中，VibeCut利用LLM与MCP协议，成功通过了字幕调整、语义裁切及图文成片等场景考验，为下一代人机协同的智能内容创作工具提供了兼具效率与稳定性的范式。

16 新活动平台建设历程与架构演进

B站用户技术中心的活动平台是连接运营效率、用户体验和活动业务的重要基础设施。活动团队历时两年对活动平台进行了一次系统级重构，打造出了一套更现代、更高效、更智能的活动工业化生产体系。改版后，活动搭建耗时和配置问题显著减少，复杂玩法可以更低成本落地，页面性能和用户体验同步提升。本文详细阐述了整个重构过程中的设计理念、建设规划和架构思考，以及活动团队是如何解决不同阶段面临的挑战，希望能对你有点帮助～

17 为什么我的 TLS 1.3 多了一个 RTT

本文从一次非预期的 TSL 1.3 握手时延问题入手，通过细致的抓包分析，探究 TCP 协议细节，发现了 Nagle 算法在现代网络环境下对时延敏感应用的影响，并成功优化了握手时间。不仅提升了用户体验，也让我们对不同层级网络协议的真实交互逻辑有了更深入的理解。希望能对大家有所助益。

18 前端物料库的设计

随着公司前端业务快速发展，原有 cnpm 系统在物料管理、搜索和文档支持方面日显不足。本文介绍了如何基于 Nexus3 构建全新的前端物料平台，实现 npm 包、UMD 组件和 SVG 图标的统一管理。通过建立四维分类体系（终端、框架、领域、功能）提升物料可发现性，并引入外部文档嵌入、产物在线预览及 Cosmos2 示例沙盒等创新功能，有效解决了"找组件难、查文档难"的痛点，为前端物料标准化治理奠定了基础。

19 B站基础安全在AI溯源方向的探索实践

本文分享了B站基础安全团队在AI辅助告警溯源方面的探索实践。随着安全告警运营从人工查证演进到SOAR阶段,团队借助AI技术和MCP协议,将HIDS、蜜罐、EDR等安全产品的API转化为AI可调用的工具集,构建了"告警产生-研判降噪-机器人推送-AI溯源"的完整链路。通过蜜罐、HIDS、EDR三类真实告警案例,展示了AI自动关联堡垒机日志、资产信息、用户部门等多源数据,完成从事件追踪到责任主体定位的全链路溯源能力。显著提升了安全运营效率,实现了"人机协同+自动化溯源"的落地。

20 从拥塞控制算法热交换到内核错误修复

最近在哔哩哔哩，我们开发了一种改进的 BBR 拥塞控制算法，需要在真实环境中进行测试。该算法本身以内核模块的形式存在，因此将其安装到服务器上不是问题。然而，在快节奏的迭代过程中，我们遇到了一系列问题，最终发现了一个内核错误。本文将带您了解我们解决问题的整个过程，从拥塞控制算法热交换到内核错误修复。

-End-

福利时刻

以上就是2025年【哔哩哔哩技术】年度精选干货！

有没有哪篇在技术道路上给了你新启发？

或者有任何建议&意见、未来想看到的内容，都欢迎留言告诉我们。

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取4位幸运的小伙伴获取蛇来运转系列小电视毛绒挂件

抽奖截止时间：1月5日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

SABER: 模式切换的混合思考模型训练范式

Fri, 19 Dec 2025 12:01:00 +0800

原创 AI 2025-12-19 12:01 上海

bilibili Index-llm Team提出 SABER，一种让大模型具备可切换、可控、并受 token 预算约束的推理能力的强化学习框架。

一、概述

通过链式思考增强的大语言模型在复杂任务上已取得显著的性能提升，但在将这种推理方式无差别地应用于所有问题时，常常面临推理开销过大、响应延迟偏高等现实瓶颈。为解决这一矛盾，bilibili Index-llm Team提出 SABER（Switchable and Balanced Training for Efficient LLM Reasoning），一种让大模型具备可切换、可控、并受 token 预算约束的推理能力的强化学习框架。

SABER 首先对基座模型在每个训练样本中的推理长度进行统计，将样本划分到不同的预算层级。在随后的微调过程中，模型在系统提示词和混合奖励的引导下，学习如何在给定预算内完成推理。同时，我们额外加入一部分无思考训练数据，确保模型在关闭显式推理时依然能够稳定作答。SABER 支持四种离散推理模式：NoThink、FastThink、CoreThink、DeepThink，能够在推理深度与推理延迟之间灵活调节。我们在数学推理、代码生成和逻辑推理等复杂任务上进行了系统实验。结果显示：SABER 在限制 token 预算下依然保持高精度推理结果，具备平滑退化特性，并在跨模型规模与跨任务场景中展现出良好的泛化能力。特别是在 MATH 任务上，SABER-FastThink 将推理长度减少了 65.4%，并相较基座模型提升了 3.6% 的精度，展现出显著的效率与性能优势。

该论文已被AAAI 2026收录，链接：https://arxiv.org/abs/2508.10026

二、背景

近年来，大语言模型在复杂推理任务上的表现取得了显著进步，这主要得益于它们在显式、逐步的思考能力上的增强。诸如思维链提示（Chain-of-Thought）和推理时扩展（Test-Time Compute Scaling）等方法，使模型能够在给出最终答案前，将问题拆解为一系列中间步骤，从而提升推理的可靠性和准确性。这类策略已在多类任务中展现出了卓越的效果。

然而，这种方法也带来了一些新的挑战。首先，推理轨迹往往过长，导致推理成本和响应延迟显著增加。更重要的是，模型通常会在所有输入上机械地采用相同的深度推理流程，而不考虑任务本身的复杂度或用户的偏好。这种推理深度与任务需求的不匹配，引出了一个越来越受到关注的问题：过度思考（overthinking）。在这一现象中，大语言模型即便面对极其简单的问题，也会生成冗长、复杂且不必要的推理内容。例如，对于“1 + 1 等于几？”这样的简单问题，一些模型可能仍会给出多步推理、列举无关的推导过程，其 token 消耗远超直接回答。这不仅拖慢响应速度，也显著提高推理的计算成本，从而限制了模型在真实场景中的部署效率。

尽管已有工作尝试通过指令微调、长度约束、奖励重塑等方式来压缩输出，但这些方法多依赖静态规则或任务无关的启发式机制，既无法根据问题难度动态调节推理长度，也无法真正让用户掌控模型的推理深度。

三、方法

3.1 思考长度统计与预算划分

思考预算（thinking budget）的设计是 SABER 的核心。若所有样本采用统一预算，简单任务不会受到长度约束，难题则会持续受罚并导致性能崩塌。为此，SABER 对每个样本单独校准预算：先运行基础模型，统计和之间的推理 token 数量，再依据分布将样本划分为三个难度档：128（简单）、4096（中等）和 16384（困难）。难度越高，所允许的推理长度越宽松；超过 16384 的样本不设上限。同时在系统提示词中显式告知该样本的推理上限，从而让模型在训练中学习不同推理模式之间的切换。图1展示了不同思考模式的系统提示词。

^{图1 不同思考模式的系统提示词}

这种分级缩放策略既保证了大量样本能产生有效的长度惩罚，加速模式切换的学习，又能尊重任务本身的推理需求，使训练过程更稳定。

3.2 样本分组与稳定性控制

直接对所有样本一开始就施加强长度惩罚会导致训练不稳定，因此 SABER 采用两项稳定化机制：

（1）基于准确率的样本分组

我们测量基础模型对训练集的回答情况，对其无法正确回答的约 40% 样本，其中一半保持原预算、另一半不设预算上限，使其推理过程不受惩罚。只有基础模型能答对的 60% 样本才会被降级预算。该策略减少了模型早期因频繁切换推理模式而带来的不稳定性。

（2）推理长度比例约束

为了避免模型为了减少惩罚而故意生成过短的推理轨迹，我们要求生成的思考 token 数必须在基础模型长度的区间内：

防止出现因过度压缩推理导致的reward hacking现象。

3.3 无思考模式构造

在应用场景中，用户可能希望直接获得答案而无需推理过程。然而长推理模型若直接关闭思考通常会导致显著性能下降。因此 SABER 显式在训练集中加入部分 no-think 样本，通过构造极短的占位思维块来告诉模型跳过推理直接作答。即使少量数据，也能显著增强模型在无推理模式下的稳定性与表现。

3.4 无需SFT预热的直接RL优化

与许多需要先进行 SFT 的方法不同，SABER 的构造天然与模型行为一致，因此可直接用强化学习进行训练，无需额外的 SFT 热身阶段，使训练更简单高效。

模型采用 GRPO 进行优化，其奖励由四部分组成：

格式奖励：推理与答案必须使用 ... 标记的结构化格式；
答案奖励：数学任务检查 boxed{} 内容，代码任务通过运行测试；
长度惩罚：超过预算则扣分；
比例惩罚：推理长度若偏离基础模型过多则扣分，防止reward hacking。

综合优化后，模型能够实现对推理深度的精确控制，在长推理、短推理及无推理场景中均保持稳定的高质量回答。

^{图2 SABER框架}

图2总结了SABER的整体框架。上半部分展示了数据预处理流程，我们通过基座模型的推理结果估计每个样本所需的思考预算，并据此将训练数据划分为简单、中等和困难三类。下半部分展示了强化学习阶段的训练机制，模型在不同推理模式对应的提示词引导下生成回答，随后依据格式规范性、答案准确性以及推理长度与预算的匹配程度等多维奖励信号进行综合评估与更新，从而实现更高效、更可控的推理行为。

四、实验

我们在实验阶段系统评估了 SABER 框架的有效性，围绕四个核心研究问题展开：

（1）SABER 在数学推理与代码生成任务上相较现有方法是否具备优势？

（2）SABER 是否能推广到更大规模的模型，以及泛化到未见过的推理领域？

（3）SABER 的关键设计组件各自的重要性如何？

（4）SABER 的可切换推理模式之间呈现出怎样的行为差异？

为回答上述问题，我们首先介绍实验设置，包括使用的数据集、对比基线与训练数据构成。随后展示 SABER 在 1.5B 模型规模上的核心结果，覆盖数学推理（MATH / GSM8K）与代码生成（MBPP）任务；接着进一步在 7B 模型上复现相同训练流程，评估其跨规模、跨领域的泛化能力，并在 LiveBench-Reasoning 逻辑推理任务上验证模式切换机制的迁移能力。我们也通过逐项删减关键组件的消融实验，分析 SABER 各模块的贡献。最后，我们选取具体案例，比较 FastThink、CoreThink 和 DeepThink 三种推理模式的行为差异，展示不同思考深度下的推理风格与答案准确性表现。

4.1 与基线的比较（RQ1）

在 1.5B 模型规模下，SABER 的各模式均优于基座模型。

FastThink 在保证准确率提升的同时，使推理长度下降 70%+，实现极高的效率；
CoreThink 在精简推理的基础上进一步提升了整体准确率；
DeepThink 在维持较高推理完整性的同时仍显著压缩生成长度，并取得最高准确率。

对比 L1 和 SelfBudgeter，SABER 在更小训练量（2K vs. 30K）下获得更好的准确率—效率折中，并展现更稳定的推理行为学习能力。

4.2 跨规模与跨领域泛化（RQ2）

在应用于 7B 模型时，SABER 仍保持良好的推理压缩能力与准确率增益：

FastThink 在保持较高精度的前提下减少超过 80% 的推理长度；
DeepThink 同时实现较大幅度的压缩与轻微的准确率提升。

更重要的是，尽管训练数据仅包含数学和代码样本，但 SABER 的推理模式切换机制成功迁移到了逻辑推理任务（LiveBench-R），显示出跨领域的泛化能力。

4.3 消融实验（RQ3）

我们对 SABER 的核心设计逐项去除并测试其影响，包括预算降级策略、NoThink 示例比例、样本准确率过滤等。实验表明：

移除预算降级会显著削弱短推理模式的学习能力，使模型难以适应不同推理深度；
减少或删除 NoThink 数据会导致无推理模式性能明显下降，且不会带来其他模式的收益；
移除准确率过滤会引入监督噪声，使训练不稳定。

这些结果说明，SABER 的各子模块均是稳定学习推理模式的必要组成部分。

4.4 推理模式行为分析（RQ4）

通过 MATH500 的示例可见，各模式都会遵循核心解题步骤，但推理深度有所区分：

FastThink 仅包含关键步骤，最为简洁直接；
CoreThink 会加入额外的反思与局部解释，推理更完整；
DeepThink 则在得出答案后进一步展开自校验与总结，展现更深入、更具反思性的推理风格。

五、总结

在本研究中，我们提出了一种模式切换的混合思考模型训练范式SABER，使大语言模型能够在多种推理模式下实现高效、可控的思考过程。SABER 通过结构化奖励、离散化推理模式设计，以及类似课程学习的预算分配策略，在无需额外监督微调的前提下，依然能够保持稳定的训练过程与灵活的推理行为。实验结果表明，SABER 在数学推理、代码生成与逻辑推理等多类任务中都展现了良好的泛化能力，并能在不同的计算预算下保持稳健性能。同时，我们验证了 SABER 能够在同一模型中自然地支持开关思考两种模式，且关思考模式的性能退化很少。总体来看，这些结果说明 SABER 为构建可控、高效率且高性价比的大模型推理机制提供了一个具有前景的方向。

-End-

作者丨Index LLM Team

开发者问答

SABER将于2026年1月24日在新加坡Expo进行Poster展示，现场还会发放SABER精美无料，欢迎大家来一起交流！

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取龙年小电视鼠标垫键盘垫

抽奖截止时间：12月26日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路