哔哩哔哩技术

[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

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

从JS云函数到MCP：打造跨平台AI Agent工具的工程实践

Fri, 12 Dec 2025 12:01:00 +0800

原创 AI 2025-12-12 12:01 上海

构建 AI 工具生态这件事上，过去一年B站做了不少尝试。

构建 AI 工具生态这件事上，过去一年我们做了不少尝试。

回头看，会觉得这条路径像是在搭建一条越来越清晰的“能力生产线”：

从写 JS → Agent Tool 工具 → 成为 MCP 工具 → 成为跨平台 Agent 能力。

这篇文章我们就按这条演进路线，把底层逻辑、踩坑经验和最终的工程方案完整讲清楚。

一、先做简单介绍

我们做了一个“在线 JS 云函数平台”，它的本质是：把写一个 JS 函数，变成给 AI 赋予一个 Tool 新能力。

这套系统经历了三个阶段：

1. 第一版：只是 Flowise 里的一个 LangChain StructuredTool 扩展，能在工作流里被 Agent 调用。

Flowise（https://flowiseai.com/）是一款开源、可视化的 AI 工作流工具，通过拖拽节点即可构建 LLM 应用或 Agent。它底层基于 LangChain 的 TypeScript 版本，因此天然具备模型调用、工具调用、链式处理、记忆与向量检索等能力。

当时我们在技术选型时使用 Flowise 做AI工作流平台有两个原因：

一是它基于 LangChain 的 TypeScript 版本——在早期 AI 框架还不成熟时，这是少数原生支持 TS 的方案；二是它提供了可拖拽的可视化工作流，能让我们快速搭建和验证 AI 原型。

2. 第二版：演进为一个浏览器里的云函数 IDE：在线写代码、调试、沙箱运行时、连内网 gRPC/HTTP/MySQL。

3. 现在：接上 MCP 协议，变成一个可以被「任何支持 MCP 的 Agent / Studio」跨平台调用的独立工具平台，并支持 SSE + Streamable HTTP 两种流式协议。

二、为什么我们需要“AI 工具能力层”？

在我们内部构建 AI 应用（客服、直播运营助手等）时，遇到几个非常典型的痛点。

1. 工具很多，但每接一次 AI，

都要重写一遍工具

想让 AI 查开播状态、查卡顿、查稿件、给用户发通知……
后端能力其实都有，但每接一个新智能体，就要：

在某个项目里再写一遍调用代码
手动写结构化参数 / 返回值
校验、鉴权

每个团队都重新写一遍

2. AI 需要的是“能力”，而不是“接口”

业务接口往往是这样的：

GET /room/info?roomid=123

但是用户却会说：“查一下imzerooo开播状态”

这中间的自然语言 → 参数的语义映射，很难靠简单规则完成。

如果让开发者直接暴露接口，AI 是很难用好的。

3. JSON 不是 AI 友好的输入格式

内网接口通常返回一大坨 JSON。LLM 解析 JSON 没问题，但：

字段多、嵌套深 → 容易丢字段
字段名杂乱 → 模型记不住
文本内容多 → 容易产生幻觉

AI 友好的格式是：

Markdown 表格
简洁的自然语言
提炼过的信息

而不是整包 JSON。

4. 工具没有做成“资产层”

以前的工具要么：

绑死在某个 AI 工作流上
埋在某个项目里
放在某个业务脚本中

无法像资产一样复用。

所以一切问题的核心其实是：

缺少一个可以写工具、管理工具、发布工具、复用工具的统一能力层。

而我们做的，就是让这件事：只需写一段 JS 函数。

三、第一版：StructuredTool

—— 工具能力的萌芽

最初我们是在 Flowise 里写 StructuredTool 组件。

Flowise 底层基于 LangChain，所以我们写了很多 StructuredTool：

exportclassQueryLiveRoomToolextendsStructuredTool {
  name = 'QueryLiveRoomTool'
  description = '根据 uid 查询主播信息'


  schema = z.object({
    roomid: z.string().describe('直播间id')
  })


  async _call({ roomid }) {
    const res = await axios.post({...})
    return formatForAI(res)
  }
}

这一版有几个优点：

工具能被 Agent 调用
参数有 schema
有一定的模块化

但有几个局限：

工具生命周期跟 Flowise 项目绑死
要写 TS、写 Node 项目，对效率很不友好
无法跨平台使用
JSON 处理还是要自己写
无法注入通用能力（如内网 SDK）

于是我们开始考虑平台化。

四、第二版：在线 JS 云函数平台（NodeVM 运行时）

我们打造了一套全新的平台：在线 JS 云函数平台。

开发者不需要知道 Flowise、LangChain，也不用开

Node 项目。

4.1 NodeVM：一个安全可控的 JS 执行沙箱

我们基于 vm2（NodeVM）做了一个“可控的 JS 执行环境”。

运行时基于 StructureTool
NodeVM 作为安全隔离的执行环境
自动注入企业内部能力（统一上下文能力层）

/**
 * 核心思路抽象版
 */
import { NodeVM } from 'vm2'
import { StructuredTool } from '@langchain/core/tools'
//...


classDynamicToolextendsStructuredTool {
  constructor({ name, description, schema, code }) {
    super({ name, description, schema })
    this.code = code // 用户在在线编辑器里写的 JS 代码
  }


  async _call(args, runManager, flowContext) {
    // 1. 构建沙箱（所有注入能力都放在这里）
    const sandbox = {
      // 用户传入的参数转成 $xxx
      ...Object.fromEntries(Object.entries(args).map(([k, v]) => [`$${k}`, v])),


      // 内部上下文（cookie/env/session）
      $flow: flowContext,
      $cookie: flowContext.cookie,


      // 内网能力封装（gRPC/HTTP）
      $yuumi: yuumi,


      // 结果转换工具（用于把 JSON 转成更 AI 友好的 Markdown 表格）
      $json2MarkdownTable: json2MarkdownTable,


      // 内部 AI 模型
      $biliLLM: biliLLMClient
    }


    // 2. 构建 NodeVM 沙箱
    const vm = new NodeVM({
      sandbox,
      console: "inherit",
      require: {
        builtin: allowedBuiltinDeps,
        external: allowedExternalDeps
      }
    })


    // 3. 执行开发者写的云函数代码
    return await vm.run(
      `module.exports = async () => { ${this.code} }()`,
      __dirname
    )
  }
}

它既能隔离风险，又能注入能力：

禁止访问文件系统
禁止随意 require
只开放白名单依赖
内置 $yuumi（内网 gRPC/HTTP 调用）
内置 $json2MarkdownTable
内置 $cookie
内置 $flow（上下文）
内置内部 AI 能力

于是开发者传入的业务代码类似这样：

const res = await $yuumi.grpc({
  appId: 'live.service',
  path: '/room/info',
  params: { roomid: $roomid },
  cookie: $cookie,
})


return $json2MarkdownTable(res.data.list)

4.2 在线调试：monaco-editor

+ Mock + 沙箱日志

编辑器底层用的是 microsoft/monaco-editor，好处是：

TypeScript / JS 语法高亮
可以做一些简单的智能提示
UI 很像 VSCode，大家上手成本低

调试方面：

提供了一个参数 Mock 面板：可以填入调用时的 JSON
点击「运行」，平台会在沙箱里跑一遍你的函数，把：日志打印（console.log）、返回字符串、可能的异常，全都展示出来

每次保存，我们都会生成一个版本：

当前编辑的是“草稿”
发布的时候会把某个版本标记为发布
出现问题可以一键回滚到上一版

最后，开发者只需要在编辑器里写一个 “普通 JS 函数”，但：

安全隔离由 NodeVM 负责
内网调用靠 $yuumi
会话靠 $cookie
AI 友好的结果格式靠 $json2MarkdownTable

4.3 Tool Arguments：

为 AI 帮开发者“定义接口”

传统开发写接口参数：

roomid: string

为此，我们提供了转为 Tool Arguments 的可视化配置：

它会统一生成：

MCP Tool 的 JSON Schema
StructuredTool 的 Zod Schema
NodeVM 内 $roomid 变量

一次配置，全平台复用。

4.4 工具市场：企业内部的 Agent 工具仓库

我们提供了工具市场：

各部门把工具上架
其他部门直接复用
工具行为一致，调用方式一致
避免重复开发

工具从“项目资产”变成“企业能力”。

五、第三版：接入 MCP ——

让工具跨平台、跨模型、跨框架

做到第二版时，工具已经变得很好用了。但还缺一块：

同一份工具定义，既能在 Flowise 里当 LangChain StructuredTool 用，又能在 MCP 里变成跨平台 ToolCall。

5.1 MCP 是什么？以及一个常见误区

MCP 全称 Model Context Protocol，可以简单理解为：

给“大模型 + 工具调用”定义了一个“统一插线板”

它解决的是：

大模型想调用一个外部工具
这个工具可能跑在本机、另一台服务器、甚至另一个团队的系统里
我们希望“调用方式”是统一、可描述、可流式的。

5.2 一个常见误区：把旧接口一包就行了？

很多人第一反应是：

那我把现在的业务 HTTP 接口包成一个 MCP 工具，不就行了吗？

理论上可以，实践里有两个坑：

1. 自然语言 ≠ 接口参数

用户会说：“查一下未完成的任务”。但你的接口长这样：/tasks?status=1&owner_id=xxx。中间这层 “自然语言 → status=1” 的映射，需要：

prompt / few-shot
枚举表 / 映射关系
甚至分类模型。

所以我们在 Tool Arguments 设置时一定要尽量贴近自然语言，比如 status 描述写成“任务的进度状态（未开始/进行中/已完成）”，而不是“1/2/3”。

2. JSON 返回 ≠ AI 可读

很多内部接口返回一大坨嵌套 JSON，LLM 虽然能解析，但：

容易“漏看”字段；
回答会很啰嗦或不稳定。
所以我们在云函数层统一规定：

返回给 AI 的一定是“人类可读”的文本/Markdown，JSON 只是中间态。

这就是前面 $json2MarkdownTable 那段代码存在的原因。

5.3 StructuredTool → MCP：

我们是怎么做“代理层”的？

前面说了两件事：

工具在平台内部用 LangChain StructuredTool + NodeVM 来执行
我们希望同一份工具定义，既能在 Flowise 里用，也能被任意支持 MCP 的 Agent / Studio 调用

createMCPServer：Express 里的一层 MCP 网关

在服务端，我们做了一层很薄的 MCP 网关，挂在 Express 应用上：

export function createMCPServer({ app, AppDataSource }: App){
  // 单个云函数 → MCP-StreamableHTTP
  app.post('/api/mcp/function-tool/:toolId', singleToolCreateStreamableHTTPServer)
  // 多个云函数组合 → MCP-StreamableHTTP
  app.post('/api/mcp/:mcpId', multipleToolCreateStreamableHTTPServer)


  // 会话后续请求复用
  app.get('/api/mcp/function-tool/:id', handleSessionRequest)
  app.delete('/api/mcp/function-tool/:id', handleSessionRequest)
  app.get('/api/mcp/:mcpId', handleSessionRequest)
  app.delete('/api/mcp/:mcpId', handleSessionRequest)


  const transports = {
    streamable: {} as RecordStreamableHTTPServerTransport>
  }


  // ... 省略 SSE 相关 ...
}

对外就是几条 HTTP 路由；
对内维护一个 streamable 的 transport 池，用 sessionId 作为 key。

这样，不同 AI Studio / Agent 只要知道某个 URL，就可以把它当 MCP 端点来用。

Streamable HTTP：用 session 管住一条“长连接”

StreamableHTTPServerTransport 是 MCP 官方 SDK 提供的一个传输实现，用来做 Streamable HTTP 模式。我们做的事情有两种情况：

客户端第一次初始化（没有 sessionId）；
之后所有请求都带上 mcp-session-id 头，复用之前的 session。

核心代码大概是这样：

async function createStreamableHTTP(config: CreateMcpServerConfig){
  const { req, res, username } = config
  const sessionId = req.headers['mcp-session-id'] as string | undefined
  let transport: StreamableHTTPServerTransport


  if (sessionId && transports.streamable[sessionId]) {
    // ① 有 sessionId，复用之前的 transport
    transport = transports.streamable[sessionId]
  } elseif (!sessionId && isInitializeRequest(req.body)) {
    // ② 首次初始化，请求体符合 MCP 初始化格式
    transport = new StreamableHTTPServerTransport({
      sessionIdGenerator: () => randomUUID(),
      onsessioninitialized: (sessionId) => {
        transports.streamable[sessionId] = transport
      }
    })


    // 连接关闭时清理掉这个 session
    transport.onclose = () => {
      if (transport.sessionId) {
        delete transports.streamable[transport.sessionId]
        opsLogger.info(`[Streamable] 删除sessionId: username=${username} sessionId=${transport.sessionId}`)
      }
    }


    const server = buildMcpServer({
      ...config,
      transport: 'streamable-http'
    })


    await server.connect(transport)
  } else {
    // 既不是初始化，又没有合法 sessionId：直接返回错误
    res.status(400).json({
      jsonrpc: '2.0',
      error: {
        code: -32000,
        message: 'Bad Request: No valid session ID provided'
      },
      id: null
    })
    return
  }


  await transport.handleRequest(req, res, req.body)
}

配合一个统一的会话请求入口：

async function handleSessionRequest(req: Request, res: Response){
  const sessionId = req.headers['mcp-session-id'] as string | undefined
  if (!sessionId || !transports.streamable[sessionId]) {
    res.status(400).send('Invalid or missing session ID')
    return
  }


  const transport = transports.streamable[sessionId]
  await transport.handleRequest(req, res)
}

这样实现的好处是：客户端只需要记住一个 mcp-session-id，之后所有请求都可以复用同一条 Streamable HTTP 会话。

buildMcpServer：真正把“工具注册到 MCP 协议”

首先，用户可以将云函数平台创建的智能体工具代理到MCP协议上，一个MCP可以关联多个工具

接下来是最关键的一步：用官方 McpServer 把 Tool Registry 里的工具挂成 MCP Tool。

function buildMcpServer(config: BuildMcpServerConfig): McpServer {
  const { name, tools, cookie, env, id, type, username, transport } = config


  const server = new McpServer({
    name,
    version: '1.0.0'
  })


  for (const tool of tools) {
    // 1）把数据库里的元信息，转成 DynamicStructuredTool 入参
    const obj = {
      name: tool.name,
      description: tool.description,
      schema: z.object(convertSchemaToZod(tool.schema as string | object)),
      code: tool.func as string
    }


    // DynamicStructuredTool 内部就是一个“动态 StructuredTool” + NodeVM 沙箱
    const dynamicStructuredTool = new DynamicStructuredTool(obj)


    // Flow 信息：cookie + env（来自 MCP URL 上的 sign / 其它 query）
    dynamicStructuredTool.setFlowObject({
      cookie,
      env: typeof env === 'object' && Object.keys(env).length ? env : {}
    })


    // 2）把我们在 UI 里配置的 Tool Arguments schema，转成 MCP 需要的 zod 参数定义
    const schemaParser = (tool.schema ? JSON.parse(tool.schema) : []) as Schema[]


    const paramsSchema = schemaParser.reduce((res, cur) => {
      if (cur.required) {
        res[cur.property] = z[cur.type]({ required_error: `${cur.property} required` })
          .describe(cur.description) as z.ZodTypeAny
      } else {
        res[cur.property] = z[cur.type]()
          .describe(cur.description)
          .optional() as z.ZodTypeAny
      }
      return res
    }, {} as any)


    // 3）用官方 server.tool() 方法注册 MCP Tool
    server.tool(tool.name, tool.description, paramsSchema, async (args, _extra) => {
      // 注意：这里的 call() 对应的就是 LangChain StructuredTool._call()
      const runnerResult = await dynamicStructuredTool.call({
        ...args
      })


      // 线上环境做一层使用上报（方便统计谁在用哪个 MCP）
      if (process.env.DEPLOY_ENV === 'prod') {
        reportMcpUse({
          id,
          type,
          name,
          username,
          transport
        })
      }


      // MCP 协议统一的返回格式：content[] 数组
      return {
        content: [{ type: 'text', text: runnerResult }]
      }
    })
  }


  return server
}

把Tool Registry 里的：

name
description
schema（以数组 JSON 形式存）
func（在线编辑器里的 JS 代码）

按 MCP 需要的格式做了一层映射：

输入 → paramsSchema（zod 校验）
执行 → dynamicStructuredTool.call()
输出 → MCP 标准的 content[{ type: 'text', text: ... }]

StructuredTool 内部：从 MCP 入参到 NodeVM 执行的最后一步

DynamicStructuredTool.call() 里面最终会走到 _call()，这一步就是前面介绍的 NodeVM 沙箱执行：

把 MCP 传进来的参数变成 $xxx 变量
把 cookie / env、以及会话信息塞进 $flow
注入 $yuumi、$json2MarkdownTable、$biliIndex、$deepseek、$chatgpt 等能力
在受限依赖白名单下创建 NodeVM
以 module.exports = async function() { ${this.code} }() 的形式执行开发者写的 JS

对于上层 MCP 调用方来说：

调用了一个名字叫 QueryLiveRoomInfo 的 MCP 工具，传了一些参数，收到了一个文本/Markdown 结果

而对于我们平台来说，这中间其实已经执行了一整套：

MCP → McpServer.tool → DynamicStructuredTool → NodeVM → 内网服务的完整链路。

可复用可共享的MCP市场

对于 MCP 新手，我们在平台上还提供了“MCP 市场” 的入口，里面还提供了一键调试：

不需要真的连上一个大模型
直接在浏览器里模拟一次 MCP ToolCall
看看云函数有没有跑对、返回是不是 AI 友好的格式

六、身份鉴权：MCP 是独立服务，

安全必须先想清楚

MCP 本质上是一个“跨平台的服务访问入口”，如果不做鉴权，很容易变成无法管理。我们的做法大致是这样：

1. 注册阶段就要带 sign：

每个 MCP 工具的注册地址必须带一个 sign 参数
sign 是基于内网规范签出的签名
没有合法签名，工具不会被注册成功

2. 调用阶段统一 Proxy：

外部 Agent 调用 MCP Server
MCP Server 把调用转发给云函数平台的 Proxy 层
Proxy 层会：

校验 sign
注入对应的 $cookie / 会话
再去调真正的内网业务接口

3. 业务侧拿到的是“处理后的内网协议”：

Proxy 会把 sign 解密、校验后，以内部统一格式透传给业务
避免在业务里掺杂各种外部协议细节

这样，MCP 既可以对外暴露统一的工具接口，又仍然受控在内网的安全体系内

七、结语：把“接 AI”变成“写一个云函数”

从 AI工作流 → StructuredTool → 云函数平台 → MCP 的这条路径，我们最终得到了：

一个统一的工具定义方式：元信息
一个统一的执行方式：NodeVM
一个统一的调用协议：MCP
一个统一的共享方式：工具市场
一个统一的安全体系：sign + cookie

也让我们真正做到了：

让业务同学不再关心“怎么接 AI”，而是只需要关心“我能给 AI 提供什么能力”。

把写一个 JS 函数，变成给 AI 加一个新能力。

未来我们还会继续提升运行时性能、正确性评估观测、深度研究等方向，把工具能力建设得更现代、更企业级。

-End-

作者丨Zerooo、Gengar

开发者问答

在你们团队做 AI 应用时，最困扰你的一件事是什么？

欢迎在留言区分享你的经历~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取星星向龙系列卡套包

抽奖截止时间：12月19日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

B站社群AI智能分析系统的实践

Fri, 28 Nov 2025 12:01:00 +0800

原创 AI 2025-11-28 12:01 上海

AI 让我们从“人工盯岗”进入“主动洞察”时代。

一、为什么我们需要一套能“读懂群聊”的 AI？

在 B 站，我们运营团队需要管理着数量庞大的UP主交流群，如：品类扶持、成长训练营、专项交流、答疑沟通群等。覆盖许许多多的创作者，每天会产生大量的消息。如果完全依赖人工逐条统计，不仅效率低下，而且容易遗漏关键问题。早期运营尝试过简单的关键字分析和人工汇总的方式，但这种传统方案存在明显局限：只能捕捉预先设定的词汇，无法理解上下文和隐含含义，对新出现的话题无法及时捕获。同时人工整理出的反馈多为自由文本，缺乏结构化信息，难以及时深入分析。

于是我们做了一件事：

让 AI 自动阅读社群会话内容
理解创作者的真实声音
并生成结构化洞察、预警、日报、周报。

二、整体架构：一套由 LLM 驱动的社群 “AI 中台”

整个系统的生命周期可以分为四层：

数据采集层 → AI 结构化层 → 群体分析层 → 运营洞察层

在大量真实业务场景中落地群聊智能分析，我们不仅构建了由多个大模型驱动的 Agent Pipeline，更形成了一套可治理、可复用、可演化的 Prompt Engineering 与语义分析架构。

系统的关键点如下：

1.分层 Prompt Engineering 体系：

高召回 × 高精度的协同设计

我们将整条 LLM 链路拆分为四层 Prompt：

1. 信息挖掘层

用于高召回地提取所有可能的用户反馈
固定 Schema 输出，保障结构化稳定性
内置业务语义空间（反馈类型、标签体系、情绪体系）

2. 内容治理层

用于高精度校验、去幻觉、去噪
引入“模糊语句过滤 + 情绪 × 意图双因子校验”
合并同用户重复反馈、剔除弱反馈、剔除运营/测试信息

3. 语义聚类层

基于大模型语义理解自动构建话题簇
统一标签命名，避免相似标签分裂
当出现语义相近但不属于既有标签的反馈时，模型能够基于语义自动归并或生成新标签

4. 洞察生成层

a. 自动生成 100 字社区热点摘要

b. 基于结构化数据生成日报/周报，包含环比变化与风险事件

通过分层 Prompt，我们实现了 可控、高可用、全链路可解释 的模型输出体系。

2.双模型协作：精准性与成本之间的动态平衡

社群消息本质是 非结构化、口语化、强上下文依赖 的文本，针对每日大量群聊，我们采用“轻模型做召回 → 强模型做校验”的方法：

LLM A：擅长高召回、信息挖掘
LLM B：擅长严谨判断、减少幻觉

出于业务安全，本次分享中我们对实际使用的大语言模型进行了匿名化处理，仅以其能力特征进行描述。

这种多模型协同校验的设计，让我们在成本、召回率、准确率之间达成最佳平衡。

真实样例：模型幻觉导致的严重误判

在项目初期，我们仅使用单模型直接解析群聊内容。当遇到某些“非结构化、短句、无明确反馈意图”的消息时，模型会为了满足结构化输出要求，主动补充一些并不存在的反馈信息。

下面是一次典型的错误样本：

真实情况：该群当天没有 UP 主提出任何有效反馈内容。

模型输出：却“凭空生成”了数十条反馈结构，包括需求、负向反馈、标签分类等。

截图如下：

然而经过人工复查可以确认：

以上所有反馈均为模型“自动脑补”，群聊原文中完全不存在。

这不是简单的技术 Bug，而是足以影响业务判断的 严重幻觉风险。

因此，我们必须引入第二阶段严格复核节点

为了避免这类“凭空生成反馈”的问题，我们设计了 LLM A（高召回） → LLM B（高精度）的双模型协作机制。

在复核节点中我们做了几类专门的“反幻觉策略”：

严格禁止模型补充不存在的用户原话
无原话时 → 必须输出「无反馈」
结构化数据必须与原文一一对应
模糊语气（似乎、可能） → 自动判定为高风险 → 进入复核
字段缺失、标签不符 → Must Fix

经过增强后：

幻觉率从早期的 8–12% → 降为 <1%
假反馈基本完全消失
所有反馈均带可追溯原话，形成“证据链”

3.基于 Few-shot 的结构化输出稳定机制

在实际使用大模型时，结构化输出（尤其是表格字段）容易随着上下文或模型版本发生“格式漂移”。

为此，我们采用了一种轻量级 Few-shot Prompting 方法，让模型在正式解析业务数据前，通过少量示例快速“记住”目标格式，从而保持输出稳定。

方案原理：

通过给模型连续提供 2～3 个标准表格示例（Few-shot），并让模型在后续回答中沿用同样的格式，来显著降低结构漂移概率。

无须额外的校验器，无须复杂自愈机制，成本极低，但对稳定性提升非常明显。

技术流程：

1. 在 Prompt 中加入 1–2 个“标准表格示例”（Few-shot Examples）

a. 示例内容来自真实数据或我们构造的理想格式。

2. 要求模型：下一轮回答必须完全沿用示例格式

3. 如果模型偶尔偏移，少量的“格式纠正提示”即可修正

在某些场景下，这种 few-shot 技巧甚至比复杂的结构化约束更实用。

4.LLM 语义聚类：适应社区语言变化的

轻量级 Topic 分组

用户在群聊中的用词高度自由，包含大量细微表达差异：

多种说法表达同一个问题（如“审核慢”“卡审核”）
多种术语、别名并存（“流量波动”“推流不稳”）
不断出现新的词汇或表述

为避免关键词维护负担，我们采用：

LLM 自主判断语义相似度（不是关键词匹配）
让模型生成统一标签（避免同类话题被拆分）
当模型识别到“完全不属于现有主题”的内容时，自动生成新主题

这是一种轻量但非常实用的 Topic 聚类方式，可以让系统在不依赖复杂算法的前提下，自动跟上业务与社区语境的变化，效果足以支撑每日热点、话题趋势分析。

以下Prompt隐去了一些我们业务标签注入的内容，但仍可供大家参考

你是社区运营团队的一员。你即将阅读到一批用户反馈内容，每条反馈都有唯一的“反馈ID”。


你的工作如下：
主题聚类
- 对所有反馈进行语义聚类，将语义相近的反馈归为同一主题（如“系统卡顿”和“服务器崩溃”应归为同类）。
- 相同主题只保留一个统一标签，不要生成相似但不同的标签名称。
标签命名
- 参考微博热搜命名方式，生成简洁有冲击力的标签（2~8字），避免冗长描述。
- 标签需覆盖多种类型（满意度、咨询、问题等），不可只聚焦问题反馈。
事件提炼
- 为每个标签用一句话概括用户关注的焦点，事件化描述，不要罗列类别。
热度统计
- 统计该标签下的反馈数量，作为热度值。
反馈ID标注
- 列出与该标签相关的最多5个反馈ID，用英文逗号分隔。
排序输出
- 按热度从高到低，输出前10个标签的信息。


输出表格格式如下，请勿返回多余的注解：
| 标签 | 热议事件 | 热度 | 反馈ID |

5.语义驱动的风控预警体系：

从趋势中提前发现风险

我们结合语义聚类结果与反馈指标，形成了轻量级的预警判断逻辑：

量级分析
增速分析
负向占比
情绪突发检测
跨群体一致性判断

当某个话题出现：

负向情绪短时间急增
环比快速上涨
多个群同时出现类似反馈

系统会自动判定为 突发事件，并标注风险等级。

相比传统人工轮询，这种能力可以：

全链路流程图

三、实际效果与业务收益

引入 AI 智能分析系统后，我们在反馈洞察的效率、覆盖、准确性上都取得了显著提升。

过去依赖人工筛查时，在有限人力下日均只能回收约 50 条有效反馈；如今系统能够每天自动回收近 600 条，覆盖范围扩大十倍以上，大量被忽略的“弱信号”得以被及时捕捉和记录。

AI 带来的价值不仅体现在规模化处理，更重要的是对关键事件的提前洞察能力。系统能够识别短时间内出现的异常聚集信号，如创作流程、审核体验、版权申诉等领域的情绪波动。当某一话题的负面表达突然增多时，系统会自动聚合并提升为重点关注事件，让团队能在问题形成大范围扩散前就提前介入，在早期苗头阶段就进行响应与处理。

此外，结构化处理后的海量群聊信息，也成为了团队的重要知识资产。这些数据会进一步被用于：

生成每日/每周的事件简报，为运营与产品提供准确的用户温度计
输出典型案例与话题热度，辅助判断优先级
自动生成 TAPD 需求，推动问题闭环处理
为产品团队提供真实用户的“原声证据”，减少沟通成本

在 BI 看板上，这些沉淀的数据以更直观的方式呈现：情绪趋势、话题聚类、反馈规模、风险事件等核心指标一目了然，让业务团队可以随时掌握用户的关注点和变化趋势，做到“数据驱动运营决策”。

整体而言，这套社群信息 AI 分析体系让我们从被动响应走向了主动洞察——

不再是等用户大量投诉后再处理，而是能够利用 AI 的语义理解能力，及时捕捉到群聊中不断浮现的细微变化，并将分散的用户声音转化为推动产品迭代的动力。

四、AI应用优势总结

这套社群信息 AI 分析体系的落地，让我们在反馈获取、问题识别和运营决策三个层面都获得了实质性的提升：

效率跃升：大量重复、零散的群聊分析工作被自动化取代，团队能把更多精力投入到关键问题的判断与沟通上。
全面覆盖：大模型的语义理解能力让“隐晦表达、弱信号、新话题”都能被及时捕捉，显著降低反馈遗漏率。
情绪量化：用户情绪从主观判断变成可观测指标，趋势变化也能通过数据直接呈现，为运营提供更及时的风险提示。
话题聚合能力：语义聚类让重复表达的意见被合并、长尾问题被显性化，帮助我们更准确地把握 UP 主的关注点。
推动闭环：结构化数据沉淀后，反馈能自然进入日报、周报和需求流转体系，问题从被发现到被解决的路径更加顺畅。

AI 让我们从“人工盯岗”进入“主动洞察”时代。

我们真正实现了将创作者的声音得到规模化记录、分析与反馈，这在过去几乎是不可能完成的任务。

未来，我们也会继续加强模型在风险识别、创作支持与社区生态等方向的能力建设，为平台持续提供更智能的基础设施。

-End-

作者丨Zerooo、蓝莓派

开发者问答

你们团队在 AI 效率提升上做过哪些有趣的探索？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取星星向龙系列卡套包

抽奖截止时间：12月05日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

https://github.com/go-kratos/blades/blob/main/examples

智能体开发新范式：Blades 架构下的高效 Agent & Workflow 实践

Thu, 27 Nov 2025 12:02:00 +0800

Blades 2025-11-27 12:02 上海

🎉Blades 已发布 v0.3.0 版本，欢迎大家使用
https://github.com/go-kratos/blades/releases/tag/v0.3.0

什么是 Agent（智能体）？

业界对 Agent 并没有一个统一、严格的定义。不同厂商、开源社区甚至论文体系中，对 Agent 的描述都略有差异。但整体来看，Agent 通常指 能够长期自主运行、具备一定决策能力、并能根据任务需要调用多种外部工具的智能系统。

它可以表现为一个“懂目标、会判断、能执行”的程序，也可以是传统意义上基于规则的固定流程机器人。

在 Blades 中，我们把这些不同形态统称为 智能体系统（Agentic Systems）。尽管它们都属于 Agent 范畴，但在实际架构设计时，需要特别区分两个核心概念：工作流（Workflow） 与 智能体（Agent）。

工作流（Workflow）

工作流更偏向传统软件的思想：它依赖 预先定义好的执行步骤 来组织 LLM 与工具的调用关系，一切的逻辑顺序都由开发者提前规划、写死在流程图或代码中。

特点：

执行路径是固定的、可预期的
每一步的输入、输出、条件分支都由开发人员提前设定
更适用于业务流程标准化、稳定、可拆分的任务
易于控制边界、测试与审计

一句话：它是模型按照流程走，而不是流程根据模型变。

智能体（Agent）

Agent 的核心价值在于“自主性”和“适应性”。它不是按照流程图运行，而是让 LLM 作为“大脑”，根据任务目标与当前状态，动态决定下一步做什么。

Agent 的典型能力包括：

由 LLM 自主决定 执行步骤，而不是依赖预设流程
能够自主选择、组合或多轮调用外部工具
在执行过程中具有对任务全局状态的“记忆”和“理解”
根据实时反馈动态改变策略，而不是固定走分支
某些情况下可以持续运行，类似“服务型 Agent”

因此相比 Workflow，Agent 更接近一个主动的执行者，而不是被动的流程节点。

一句话：工作流是“流程在控制模型”，而 Agent 是“模型在控制流程”。

使用 Blades 构建：智能体（Agent）

Blades 基于 Go 语言的简洁语法和高并发特性，提供了灵活、可扩展的 Agent 架构。其设计理念是通过统一的接口和可插拔式组件，让开发者能够在保持高性能的同时，轻松扩展 Agent 的能力。整体架构如下：

architecture

在 Blades 中，可以通过 blades.NewAgent 创建一个智能体（Agent）。Agent 是整个框架的核心组件，主要负责：

调用 LLM 模型
管理工具（Tools）
执行提示词（Prompts）
控制整个任务的运行流程

同时，Blades 提供了简单优雅的方式来自定义工具，可以使用 tools.NewTool 或者 tools.NewFunc 进行构建工具，让 Agent 能够访问外部 API、业务逻辑或计算能力。

下面是一个自定义天气查询工具的示例：

// 定义天气处理逻辑
funcweatherHandle(ctx context.Context, req WeatherReq)(WeatherRes, error) {
return WeatherRes{Forecast: "Sunny, 25°C"}, nil
}
// 创建一个天气工具
funccreateWeatherTool()(tools.Tool, error) {
return tools.NewFunc(
"get_weather",
"Get the current weather for a given city",
        weatherHandle,
    )
}

再构建一个可调用天气工具的智能助手（Weather Agent）：

// 配置所调用的模型和地址
model := openai.NewModel("deepseek-chat", openai.Config{
    BaseURL: "https://api.deepseek.com",
    APIKey: os.Getenv("YOUR_API_KEY"),
})
// 创建一个天气智能助手
agent, err := blades.NewAgent(
"Weather Agent",
    blades.WithModel(model),
    blades.WithInstruction("You are a helpful assistant that provides weather information."),
    blades.WithTools(createWeatherTool()),
)
if err != nil {
    log.Fatal(err)
}
// 实现查询上海的天气信息
input := blades.UserMessage("What is the weather in Shanghai City?")
runner := blades.NewRunner(agent)
output, err := runner.Run(ctx := context.Background(), input)
if err != nil {
 log.Fatal(err)
}
log.Println(output.Text())

使用 Blades 的框架设计，你只需少量代码就能快速构建一个既能调用工具又能自主决策的智能体。

接下来，我们将基于 Blades 框架介绍几种典型的工作流模式，每种设计模式适用于不同的业务场景，从最简单的线性流程，到高度自治的智能体，可以根据实际业务需求选择合适的设计方式。

模式 1：Chain Workflow（串联工作流）

该模式体现了“将复杂任务拆分为简单步骤”的原则。适用场景：

任务本身具有明确的、顺序分明的步骤。
想以牺牲少许延迟换取更高准确度。
每个步骤都依赖前一个步骤的输出。

示例代码（examples/workflow-sequential）：

// 串行工作流，进行按编排顺序执行智能体
sequentialAgent := flow.NewSequentialAgent(flow.SequentialConfig{
    Name: "WritingReviewFlow",
    SubAgents: []blades.Agent{
        writerAgent,
        reviewerAgent,
    },
})

模式 2：Parallelization Workflow（并行工作流）

该模式用于让 LLM 同时处理多个子任务，然后将结果汇总。

适用场景：

需要处理大量“相似但独立”的项。
任务需要多个不同视角。
时间敏感、任务可并行化。

示例代码（examples/workflow-parallel）：

// 并行工作流，通过把生成的结果存到 session state 中，后续流程进行引用
parallelAgent := flow.NewParallelAgent(flow.ParallelConfig{
    Name:        "EditorParallelAgent",
    Description: "Edits the drafted paragraph in parallel for grammar and style.",
    SubAgents: []blades.Agent{
        editorAgent1,
        editorAgent2,
 },
})
// 定义串行工作流，实现同时与并行定义
sequentialAgent := flow.NewSequentialAgent(flow.SequentialConfig{
    Name:        "WritingSequenceAgent",
    Description: "Drafts, edits, and reviews a paragraph about climate change.",
    SubAgents: []blades.Agent{
        writerAgent,
        parallelAgent,
        reviewerAgent,
    },
})

这种模式能显著提升吞吐量，但也要注意并行带来的资源消耗与复杂性。

模式 3：Routing Workflow（路由工作流）

这个模式通过 LLM 智能判断输入类型，再将其分派给不同处理流程。适用场景：

输入类别多、结构差异大。
各类输入需不同专用处理流程。
分类准确率较高。

示例代码（examples/workflow-routing）：

// 通过 Agent 中的 description 进行自动选择合适的专家智能体
agent, err := flow.NewRoutingAgent(flow.RoutingConfig{
    Name:        "TriageAgent",
    Description: "You determine which agent to use based on the user's homework question",
    Model:       model,
    SubAgents: []blades.Agent{
        mathTutorAgent,
        historyTutorAgent,
 },
})

模式 4：Orchestrator-Workers（编排-工作者模式）

这个模式结合了 “Agent” 倾向：一个中央 LLM 作任务分解（orchestrator），再由不同 “Worker” 执行子任务。

适用场景：

无法事先完全预测子任务。
任务需要多种视角或处理方法。
需要系统的适应性与复杂决策流程。

示例代码（examples/workflow-orchestrator）：

// 通过工具定义翻译器（Agent as a Tool）
translatorWorkers := createTranslatorWorkers(model)
// 协调器进行选择需要的工具进行执行
orchestratorAgent, err := blades.NewAgent(
"orchestrator_agent",
    blades.WithInstruction(`You are a translation agent. You use the tools given to you to translate.
    If asked for multiple translations, you call the relevant tools in order.
    You never translate on your own, you always use the provided tools.`),
    blades.WithModel(model),
    blades.WithTools(translatorWorkers...), 
)
// 进行合成生成的多个结果
synthesizerAgent, err := blades.NewAgent(
"synthesizer_agent",
    blades.WithInstruction("You inspect translations, correct them if needed, and produce a final concatenated response."),
    blades.WithModel(model),
)

模式 5：Evaluator-Optimizer（评估-优化模式）

该模式中，一个模型生成输出，另一个模型评估该输出并提供反馈，如同人类“先写后改”流程。适用场景：

有明确可量化的评估标准。
通过多轮“生成→评估→改进”能显著提升质量。
任务适合反复迭代。

示例代码（examples/workflow-loop）：

// 通过生成内容，再进行评估效果，反复实现多次迭代
loopAgent := flow.NewLoopAgent(flow.LoopConfig{
    Name:          "WritingReviewFlow",
    Description:   "An agent that loops between writing and reviewing until the draft is good.",
    MaxIterations: 3,
    Condition: func(ctx context.Context, output *blades.Message)(bool, error) {
// 评估内容效果判断是否结束迭代
return !strings.Contains(output.Text(), "The draft is good"), nil
    },
    SubAgents: []blades.Agent{
        writerAgent,
        reviewerAgent,
    },
})

最佳实践与建议

在业务实践中，不管是单一智能体还是多智能体架构，工程设计往往比模型能力更决定最终效果。

以下实践建议总结了实际项目中最关键的原则，可作为设计与实现智能体时作为参考。

从简单做起

先构建基础工作流，再考虑更复杂的智能体。
用最简单能满足需求的模式。

设计可靠性

明确错误处理机制。
尽量使用类型安全响应。
每一步加上验证。

权衡取舍

在延迟与准确率之间做平衡。
是否并行要评估场景。

参考

B站消息新架构升级

Fri, 21 Nov 2025 12:03:00 +0800

原创业务线 2025-11-21 12:03 上海

技术升级不是一蹴而就的，一个逐步优化的过程。

先思考两个问题：

技术上数据量越大，降级概率越大，但消息业务场景上数据量大的是影响力更大的UP，业务不接受技术降级，如何破？
如果消息流量增加10倍，怎么保障服务不挂？

1.现状

业务解读

按业务全域现状，在服务端角度分成客服系统、系统通知、互动通知和私信4个业务线，每个业务线内按现状标识了服务分层。私信内分为用户单聊、bToC的批量私信、群聊和应援团小助手四类，这四类细分私信没有技术解耦，单聊和批量私信比较接近系统天花板。

私信单聊发送到触达的pv转化和uv转化不足10%，有明显通过业务优化提升触达率的潜力。

技术解读

私信域内的几个概念解释：

会话列表：按聊天人排序的列表。即B站首页右上角信封一跳后看到的历史聊天人列表，以及点击未关注人等折叠会话看到的同属一类的聊天人列表。传达对方账号、最新私信和未读数的信息。点击一个会话后看到的是对聊历史，也称会话历史。
会话详情：描述和一个聊天人会话状态的原子概念，包括接收人uid、发送人uid、未读数、会话状态、会话排序位置等。
会话历史：按时间线对发送内容排序的列表。一份单聊会话历史既属于自己，也属于另一个和自己的聊天的人。群聊的会话历史属于该群，不属于某个成员。会话历史是收件箱和消息内容合并后的结果。
收件箱：将一次发送的时序位置映射到发送内容唯一id的kv存储，可以让服务端按时间序读取一批发送内容唯一id。
私信内容：一个包括发送内容唯一id、原始输入内容、消息状态的原子概念。批量私信把同一个发送内容唯一id写入每个收信人的收件箱里。
timeline模型：时间轴的抽象模型，模型包括消息体、已读位点、最大位点、生产者、消费者等基本模块，可以用于基于时间轴的数据同步、存储和索引。私信涉及timeline模型的包括会话列表和会话历史。
读扩散：pull模式。群聊每条私信只往群收件箱写一次，让成百上千的群成员在自己的设备都看到，是典型的读扩散。
写扩散：push模式。单聊每条私信既更新接收人会话也更新发送人会话，是轻微的写扩散，无系统压力。群聊有另一个不一样的特点，就是当群成员发送消息后，需要通过长链接通知其他群成员的在线设备，以及发送人其他的在线设备，这是一个写扩散的技术模型，但是这个写扩散是通知后即时销毁的，并且具有过期时间，所以仅临时占用资源，并不对存储造成压力，且能有较好的并发量。

私信核心概念关系表达：

2.问题

会话慢查询

当会话缓存过期时，Mysql是唯一回源，Mysql能承载的瞬时QPS受当时应用总连接数和sql平均响应速度的影响，连接数打满时会给前端返回空会话列表。虽然可以增加POD数量、增大akso proxy连接数、优化sql和索引来作为短线方案，来提升瞬时请求Mysql容量，但是这种短线方案无法加快单次响应速度，mysql响应越来越慢的的问题依然在。另外增加POD数量也会降低发版速度。

会话Mysql使用用户uid%1000/100分库，用户uid%100分表，table总量是1000。

单表会话量在1kw-3.2kw。单个大up的会话积累了10W条以上，会话量最大的用户有0.2亿条会话。单个Up的会话会落到一张表中，每张表都有比较严重的数据倾斜。如果考虑增加分库分表的方案，sql查找条件依然需要用户uid，所以相当于倾斜数据要转移到新的单表，问题没有解决。另外，重新分库分表过程中新旧table增量同步和迁移业务读写流量的复杂度也很大，有比较大的业务风险。

Mysql的规格是48C 128G和32C 64G。由于会话数据量大，Mysql buffer_pool有限，数据比较容易从内存淘汰，然后mysql需要进行磁盘扫描并将需要的数据加载到内存进行运算，加之比较多的磁盘扫描数据，这时的响应一般在秒级别，接口会给前端返回超时错误，会话列表页空白。

为了适配业务发展，Mysql 会话表已经添加了9个非聚集索引，如果通过增加索引使用业务需要，需要更大的Mysql资源，且解决不了冷数据慢查询的问题。增加更多索引也会让Mysql写入更慢。

私信内容单表空间和写性能接近天花板

每条私信内容都绑定私信自己的发号器生成的msgkey，即私信内容唯一id，该msgkey包含私信发送时的时间戳。读写私信内容Mysql之前先从msgkey解析出时间，用这个时间路由分库分表。私信内容库按季度分库，分库内按月度分表，单表数据量数亿，数据量最大的用户日增私信351.9W条。按照曲率预测，25年全年数据量有近百亿，如果继续按照月度分表，分表规则不适应增长。

当前该Mysql最大写qps 790，特别活动时写qps峰值预计是20k，但是为了保障Mysql服务整体的可靠，单库写流量我们需要控制在3000qps以下，无法满足写入量峰值时的需要。

此外，消息内容表结构包含了群聊、单聊和应援团小助手全部的属性，增加业务使用难度。绝大部分私信内容是单聊的。

服务端代码耦合

四类私信（单聊、群聊、B端批量私信、应援团小助手）都需要实现发送和触达两条核心链路，四种私信核心链路的代码逻辑和存储耦合在一起，代码复杂度随着业务功能上线而不断增加，熵增需要得到控制。从微服务这方面来说，实例和存储耦合会带来资源随机竞争，当一方流量上涨，可能给对方的业务性能带来不必要的影响，也会带来不必要的变更传导。

3.升级路径

基于对私信现状的论述，可以确定我们要优化的是一个数据密集型 >> 计算密集型，读多写少（首页未读数）、读少写多（会话）场景兼具的系统，同时需要拥有热门C端产品的稳定性、扩展性和好的业务域解耦。针对读多写少和读少写多制定了针对的技术方案。

消息域整体架构设计

结合B站业务现状，我觉得比较合理的架构：

一个兼顾复杂列表查询架构和IM架构的消息域框架，整体分四层

接入层：即toC的BFF和服务端网关

业务层：按复杂查询设计系统，用于各种业务形态的支撑

平台层：按IM架构设计系统，目标是实时、有序的触达用户，平台层可扩展

触达层：对接长链和push

端上本地缓存降级

端上应该支持部分数据缓存，以确保极端情况下用户端可展示，可以是仅核心场景，比如支付小助手、官号通知，用户在任何情况下打开消息页都不应该白屏。

BFF架构升级

BFF网关吸收上浮的业务逻辑，控制需求向核心领域传导。服务端基于业务领域的能力边界，抽象出单聊、群聊、系统通知、互动通知和消息设置共五个新服务，提升微服务健康度。

新服务剥离了历史包袱，也解决一些在老服务难解的功能case，优化了用户体验，比如消息页不同类型消息的功能一致性；重新设计会话缓存结构和更新机制，优化Mysql索引，优化Mysql查询语句，减少了一个量级的慢查询。

服务端可用性升级

服务端按四层拆分后，集中精力优化业务层和平台层：

业务层：按复杂查询设计系统，用于各种业务形态的支撑

冷热分离：多级缓存 redis(核心数据有过期)+taishan(有限明细数据)+mysql(全部数据)

读写分离：95%以上复杂查询可以迁移到从库读

平台层：按IM架构设计系统，目标是实时、有序的触达用户，平台层可扩展

Timeline模型：依赖雪花发号器，成熟方案

读写扩散：单聊-写扩散，群聊-读扩散

单聊会话

缓存主动预热

用户在首页获取未读数是一个业务域内可以捕捉的事件，通过异步消费这个事件通知服务端创建会话缓存，提高用户查看会话的缓存命中率。鉴于大部分人打开B站并不会进私信，此处可以仅大UP预热。大UP的uid集合可以在数平离线分析会话数据后写入泰山表，这个泰山表更新时效是T+1。

监控UP会话数量实时热点，触发突增阈值时，通过异步链路自动为热点用户主动预热会话列表缓存。

对预热成功率添加监控，并在数平离线任务失败或者预热失败时做出业务告警，及时排查原因，避免功能失效。

泰山和Mysql双持久化

增加泰山存储用户有限会话明细，作为redis未命中后的第一回源选择，Mysql作为泰山之后的次选。基于用户翻页长度分析后确定泰山存储的有限会话的量级。

redis 存储24小时数据，taishan 存储 600条/用户（20页），预设到的极端情况才会回源mysql从库。

对于ZSET和KV两种数据结构，评估了各自读写性能的可靠性，符合业务预期。业务如果新增会话类型，可以跟本次新增泰山有限明细一样，基于会话类型的具体规则新增泰山Key。

泰山长尾优化

查询redis未命中时会优先回源泰山，考虑到泰山99分位线在50ms以下，而且Mysql多从实例都能承受来自C端的读请求，所以采用比泰山报错后降级Mysql稍微激进的对冲回源策略。在泰山出现“长尾”请求时，取得比较好的耗时优化效果。可以使用大仓提供的error group结合quit channel实现该回源策略，同时能避免协程泄漏。整个处理过程在业务响应和资源开销中维持中间的平衡，等待泰山的时间可以灵活调整。

泰山最初没有数据，可以在泰山未命中时进行被动加载，保证用户回访时能命中。

一致性保证

虽然我们重构了新服务，但是老服务也需要保留，用来处理未接入BFF的移动端老版本和web端请求，这些前端在更新会话时（比如ACK）请求到了老服务，新服务需要通过订阅会话Mysql binlog异步更新本服务的redis和泰山。为了避免分区倾斜，订阅binlog的dts任务使用id分区，这样方便的是一条会话在topic的分区是固定的。

为了避免两次请求分别命中泰山和Mysql时给用户返回的数据不一样，需要解决三大问题：

当出现分区rebalance需要避免重复消费；
当Mysql一条会话记录在短时间内（秒级）多次更新，要保证binlog处理器不会逆时间序消费同一个会话的binlog，即跳过较早版本的binlog；
保证泰山写入正确并且从Mysql低延迟同步。

这三个问题都要保证最终一致性，具体解决方案是用redis lua脚本实现compare and swap，lua脚本具有原生的原子性优势。dts每同步一条binlog都会携带毫秒级mtime，当binlog被采用时，mtime被记入redis10分钟，如果下一条binlog的mtime大于redis记录的mtime，这条binlog被采用，否则被丢弃。这个过程可以考虑使用gtid代替mtime，但这个存在的问题是每个从实例单独维护自己的gtid，当特殊情况发生mysql主从切换，或者dts订阅的从节点发生变更，gtid在CAS计算中变得不再可靠，所以我们选择了使用mtime作为Mysql会话记录的版本。

通过消费路线高性能设计保证泰山异步更新的延迟在1秒以内，并在特殊情况延迟突破1s时有效告警。高性能消费路线中，每个库的binlog分片到50个partition，业务提供不低于50个消费pod，单pod配置100并发数，按照写泰山999分位线20ms计算，每秒可以消费50*100*(1000/20)=250000条，大约线上峰值8.3倍，考虑dts本身的max延迟在600~700毫秒，同步泰山和redis的延迟会在700毫秒至1秒以内，符合业务预期。

收件箱

BFF已经从业务层和平台层将单聊读收件箱独立出来，本次升级主要是从存储做增量解耦，存量单聊收件箱的读流量可以访问旧表。单聊新收件箱存储采用redis+泰山的模式，redis提供热数据，泰山提供全部数据并采用RANDOM读模式，让主副本都能分担读流量。

私信内容

本次升级主要如下

单聊增量数据独立存储，按照单聊业务设计表结构，和群聊、应援团小助手彻底解耦。
写Mysql升级为异步化操作，提高写性能天花板，这种异步写Mysql改造不会影响读消息内容的可用性和设计。
单聊分库规则升级为月度分库，单库内分表为100张。群聊、应援团小助手和历史单聊依然使用旧的分库分表规则读写Mysql。

业务需要对增量单聊私信路由分库分表时，先从msgkey先解析出时间戳，找到用时间戳对应的月份分库，然后用msgkey对100取余找到分表。这种方案能达到按时间纬度的冷热数据的分离，同时由于msgkey取余的结果具有随机性，平衡了每张表的读写流量。这样预计2025年单表数据量能从9亿下降到900万。

批量私信

日常通道：日常批量私信任务共用通道，共用配额。
高优通道：主要通过将链路上topic partition扩容、消费POD扩容、POD内消费通道数扩容、缓存扩容、akso proxy连接数扩容，把平均发送速度从3500 人/秒提高到30000人/秒。这个通道可以特殊时期开给特殊业务使用。

4.结语

我们逐步发现技术升级不是一蹴而就的，一个逐步优化的过程；设计技术方案前设立合适和有一些挑战的目标，但这个目标要控制成本，做好可行性；设计技术方案的时候，需要清楚现有架构与理想架构的差距和具体差异点，做多个方案选型，并确定一个，这个更多从技术团队考虑；其次要保证功能在新老架构平稳过渡，保证业务的稳定性。后面持续关注新老架构的技术数据，持续优化，老架构要持续关注它的收敛替换。IM系统是一个老生常谈的话题，也是融合众多有趣技术难点的地方，欢迎感兴趣的同行交流研讨。

-End-

作者丨比奇堡、Xd、三木森

开发者问答

在消息系统架构升级中，你最关心的是哪项能力？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取星星向龙系列卡套包

抽奖截止时间：11月28日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

VisionWeaver：从“现象识别”到“病因诊断”，开启AI视觉幻觉研究新篇章

Fri, 14 Nov 2025 12:01:00 +0800

原创 AI 2025-11-14 12:01 上海

bilibili用户技术中心提出VisionWeaver及其核心诊断工具 VHBench-10，带来了创新性的视角。

前言

长久以来，我们只知道大型视觉语言模型（LVLM）会犯错，但始终缺乏一把“手术刀”，无法剖析其视觉感知的根源性缺陷。我们只知其然，不知其所以然。我们希望当 AI 模型观察图像时，不再凭空想象，不再“指鹿为马”。

现在，这一瓶颈被打破了。bilibili 用户技术中心提出 VisionWeaver 及其核心诊断工具 VHBench-10，带来了创新性的视角。VisionWeaver 不再依赖单一编码器，而是开创性地提出“上下文感知路由网络”，动态协同多个“视觉专家” 。而这一切得以实现的基础，正是其专门打造的诊断基准 VHBench-10——它让幻觉研究从“识别现象”迈向了“诊断病因”的新阶段。此工作已被 EMNLP 2025 Findings 录用。

相关链接

文章: https://arxiv.org/abs/2509.13836v1
代码：https://github.com/whwangovo/VisionWeaver
数据集：https://huggingface.co/datasets/whwangovo/VHBench_10

论文介绍

大型视觉语言模型（LVLM）的“幻觉”问题是阻碍其应用的核心障碍。以往的评测方法（如POPE）虽然有价值，但普遍停留在粗粒度层面，大多只关注“图片中是否存在某个物体”这类简单判断。这就像医生只知道病人发烧，却无法定位具体的病灶。这种“只知其然”的评测方式，无法揭示幻觉产生的根本原因，更无法为模型的改进提供针对性指导。

为了解决这一核心痛点，本研究首先提出了全新的诊断工具——VHBench-10基准。它开创性地将幻觉问题溯源至检测、分割、定位、分类这四项基本视觉能力，并进一步细分为10个具体的子任务（如颜色、计数、文本识别等）。通过这个“精准CT扫描”，我们首次能够系统性地诊断出不同视觉编码器各自的“能力盲区”。

基于这一深刻洞察，VisionWeaver架构应运而生。它不再是盲目地使用单一编码器，而是构建了一个动态专家协作系统，根据图像内容智能地调度最合适的视觉专家参与决策，从根源上抑制幻觉的产生。

^{图1 VisionWeaver整体架构}

我们的主要贡献点如下：

提出了VHBench-10——一个革命性的精细化诊断基准，推动幻觉研究从“识别现象”迈向“诊断病因”。它首次将幻觉与底层视觉任务失败直接挂钩，为精确评估和定位LVLM的视觉能力短板提供了强有力的工具。
系统性地揭示了不同视觉编码器的幻觉倾向。通过在VHBench-10上的全面评估，论文首次量化并证实了特定编码器在特定视觉任务上的优势与短板，为解决幻觉问题提供了明确的靶点。
提出了VisionWeaver——一个强大的LVLM新架构。它引入上下文感知专家路由机制，能根据图像内容智能地聚合多个专家的视觉知识，效果远超简单的特征融合方法。
在多个权威基准上取得了SOTA性能。大量实验表明，VisionWeaver不仅显著降低了幻觉率，还全面提升了模型的综合表现。

方法概述

VisionWeaver 的核心是解决单一视觉编码器能力有限且存在固有偏见的问题。简单地将多个编码器的特征相加或拼接，实验证明效果并不理想。为此，VisionWeaver 设计了一套智能、动态的专家协作流程，主要包含两大模块：

上下文感知路由 (Context-Aware Routing)： 该机制旨在利用图像的全局语义特征来计算自适应的软路由权重，从而选择最合适的视觉专家。具体而言，系统将基础 CLIP 编码器输出的[CLS] Token 特征作为路由模块的主要输入。该 [CLS] Token 被证实能够有效捕获图像的关键全局视觉信息。路由模块基于此特征生成一组路由信号，即针对每个下游专家编码器（如ConvNext, DINOv2, SAM, Vary等）的动态权重，以此决定不同专家在当前情境下的重要性得分。

知识增强与特征融合 (Knowledge Enhancement and Fusion)： 获得各专家的重要性权重后，系统对所有专家的输出特征进行加权融合（Weighted Fusion），生成一个聚合的专家表征。为了在引入专家知识的同时不损失原始的细粒度视觉信息，该聚合表征将与基础 CLIP 编码器输出的 Patch Tokens 进行对齐。实现方式上，通过一个残差式连接（residual-style connection），将聚合的专家特征与原始的 Patch Tokens 进行加法操作。最终，这份增强后的视觉表征被传递至投影器（Projector），以映射到大型语言模型（LLM）的嵌入空间中，供后续的文本生成使用。

^{图2 VHBench-10将幻觉分为4大类10小类}

关键特征

精细化幻觉诊断： 依托VHBench-10，从视觉任务根源诊断并解决幻觉问题。
上下文感知路由： 告别单一编码器，智能调度最适合当前任务的视觉专家。
多专家协同融合： 汇集不同编码器的独特优势，实现对图像的全方位、深层次理解。
卓越的幻觉抑制能力： 在多个基准上显著降低幻觉率，提升模型可靠性。
高效推理设计： 通过轻量级专家和KV缓存等机制，在不显著增加延迟的情况下提升性能。

实验

全新的精细化幻觉评估

VHBench-10基准的核心并非简单地判断对错，而是通过对10个细分视觉任务的评估，精准定位模型在感知能力上的具体短板。团队利用GPT-4为近万张图片生成了包含特定类型错误的描述（例如，颜色错误、数量错误等），与正确的描述形成对比，从而精确量化模型在各个维度上的幻觉倾向。

与已有方法的比较

在VHBench-10以及POPE、AutoHallusion等多个幻觉基准测试中，VisionWeaver的表现全面超越了使用单一编码器或简单多编码器融合的方法。如下图所示，无论是在物体存在性、颜色、形状还是文本识别等所有10个细分任务上，VisionWeaver的错误率均为最低，证明了其架构的普适性和有效性。

^{图3 VisionWeaver在10类细分幻觉任务上均取得最低错误率}

总结

VisionWeaver及其核心评测工具VHBench-10，共同将幻觉研究的范式从模糊的现象描述，提升到了病因诊断层面。它不再满足于“知道模型错了”，而是要探究“模型为什么会错”。通过VHBench-10提供的深刻洞察，VisionWeaver得以构建一个智能、动态的多专家协作系统，从视觉感知的根源上大幅缓解了幻觉问题。这一“诊断+治疗”的新范式，为构建更可靠、更精确的下一代多模态AI提供了坚实的基础和清晰的实现路径。

-End-

作者丨Jerry酱、Kiren_

开发者问答

大家在用大模型的时候，有产生什么样的幻觉问题呢？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取星星向龙系列卡套包

抽奖截止时间：11月21日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

B站基础安全在AI溯源方向的探索实践

Fri, 07 Nov 2025 12:02:00 +0800

原创 AI 2025-11-07 12:02 上海

借助 AI 的能力来提升安全事件告警的处理效率，已经成为各大企业探索与实践的重要方向。

背景

安全事件告警自动化运营的演变

在企业安全建设中，SIEM/SOC 的告警运营始终是不可或缺的核心环节。随着安全需求的不断提升，告警自动化运营经历了多个迭代阶段：

人工查证阶段：运营人员需要在各类平台之间频繁切换，手动收集与比对信息；
脚本驱动阶段：通过编写简单脚本实现部分告警处理的自动化，但灵活性有限；
SOAR 阶段：引入编排化的剧本设计，能够串联多种安全工具与流程，实现更高程度的自动化。

虽然自动化能力在不断增强，但实际运营中仍需安全人员持续参与，对剧本进行调试和优化，以确保其适应复杂多变的威胁场景。

AI的发展

随着 AI 技术的不断成熟，其在自动编排、报告生成与智能分析等方面展现出天然优势。借助 AI 的能力来提升安全事件告警的处理效率，已经成为各大企业探索与实践的重要方向。

演变过程大致经历了以下几个阶段：

大模型安全知识库搭建：沉淀安全规则与经验，为 AI 的智能化分析提供底层支撑；
大模型告警解读分析：自动化理解告警内容，完成分类、归因与初步分析；
大模型告警研判：在多源数据与上下文的支撑下，AI 逐步具备辅助安全人员进行告警定性与风险判断的能力。

近年来，随着 Claude 的 MCP（Model Context Protocol）协议逐渐成为主流的 AI 与工具交互标准，基于 MCP 的 AI Agent 已经演变为连接 AI 与真实数据的关键桥梁。这种方式不仅提升了告警分析、研判的智能化程度，也让自动化溯源与安全运营更加契合企业内部的实际需求。

人与平台交互的演变

最初，用户通过账号密码登录平台，在界面上逐步完成各类操作；随着平台开放程度的提高，API 的出现让机器能够直接调用数据和服务，OpenAPI极大地提升了交互的效率与自动化程度。随后，低代码平台的兴起又进一步降低了门槛，使非专业开发者也能以可视化、拖拽式的方式快速构建业务流程。

而在当下，AI 正在重塑人与平台的交互方式。借助 MCP，大模型不仅仅是对话聊天，答疑助手，而是一个具备领域全面，专业性极强的智能体，通过增加记忆能力，管理上下文能力，自动解析意图、调用合适的工具集，便可完成复杂的业务闭环。这意味着交互正从 “人教机器做事” 向 “人与智能体协作” 转变，平台的可用性和智能化程度也因此迈入新的阶段。

技术方案

发展

对于基础安全团队而言，我们同样经历了引入 AI 的逐步过程：从告警解读到告警研判，再到告警降噪。随着 MCP 协议逐渐被业界认可并采纳，基于 MCP 的 AI Agent 可以在告警降噪之后，在解读告警的同时关联内部多源数据，进一步完成对事件的溯源分析。

工具准备与处理

在溯源场景中，关键在于让 AI 能够接触并查询到企业内部平台的数据。安全团队通常会部署多种安全产品，例如 HIDS、WAF、EDR、IPS、蜜罐等。若希望实现 AI 自动化溯源，就需要借助 MCP 将 AI Agent 与这些安全设备能力对接，使其能够：

查询并关联 HIDS、WAF 等安全告警数据；
访问内部资产信息；
将结果映射和关联到人、IP、部门等维度。

通过这种方式，AI 不仅能完成告警分析，还能自动串联攻击线索，最终实现更高程度的自动化溯源。

方案设计

基于上述思路，我们的整体设计方案是将内部安全产品的 API 接口、内部资产接口和日志相关的查询接口转化为 AI 可调用的 MCP 工具集，供AI-Agent调用。目前，我们已完成对以下产品的转化与实现：

安全产品	MCP能力
HIDS	资产信息：IP、Hostname、端口、进程、账户信息告警信息：异常登录、命令执行、暴力破解、后门检测、反弹shell等
蜜罐	告警信息：告警时间、源目IP、源目端口、连接信息、登录使用的帐密信息
CMDB	主机资产信息
EDR	告警信息，用户资产信息
日志平台	堡垒机登录、操作信息，SLB访问数据信息、DNS查询信息
SIEM平台	告警汇总信息，告警详情信息
SRC平台	漏洞工单信息，漏洞数量信息
......	......

流程架构

在实际工作中，告警信息通常会通过机器人推送到告警处置群。联合大模型智能体、企业微信机器人以及企业微信三方应用号，我们设计并实现了如下处理链路，以提升告警研判与溯源的效率：

安全产品产生告警 —— HIDS、蜜罐、EDR 等安全设备输出原始告警事件；
流式处理 —— 通过实时流处理框架对告警进行过滤和汇总至安全SIEM平台；
AI 研判降噪 —— AI Agent对告警进行解读与风险评估，实现告警降噪；
机器人推送告警 —— 企业微信机器人将大模型研判为高危的告警推送至告警处置群；
运营人员响应 —— 安全运营人员根据高危告警信息进行分析与处置；
AI 辅助溯源与自动处置（可选） —— 运营人员借助大模型可进一步触发溯源流程，甚至自动完成处置动作。

这一架构使得告警处理流程既保留了人工判断的灵活性，又逐步引入 AI 的智能化能力，实现了“人机协同 + 自动化溯源”的目标。

实践案例

prompt

对于集成了众多工具集的AI-Agent,prompt在大幅简化的情况下，仍能有很不错的溯源效果，比如下边例子中，我们给的prompt均为：

prompt

以下是我收到的安全告警详情，请帮我使用合适的工具进行溯源和分析：

溯源流程图

蜜罐告警溯源分析

一次溯源分析流程，运营人员只需要点击告警卡片的AI溯源，即可触发大模型的溯源分析：

完整溯源结果如下，可见AI-Agent可自行搜索主机信息，关联堡垒机信息，找到命令执行人和执行的命令，并定位到触发告警的员工部门

告警溯源信息

溯源分析结果

攻击者信息

- 攻击者IP: 10.xxx.xxxx.35

- 主机名: js02-xxxs-xxx-01

- 操作系统: Debian GNU/Linux 11.2

堡垒机操作日志分析

在告警发生时间（2025-08-28 07:56:06 UTC）前后1小时时间段内，发现攻击者IP 10.xxx.xxxx.35上有堡垒机操作记录：

- 操作人: zhangxxx

- 操作时间: 2025-08-28 15:25:56 至 15:55:11（北京时间）

- 操作命令: 包含多次 telnet 172.xx.xx.39 22 连接尝试，以及网络配置命令 mtu 1500 、 ifconfig 等

- 客户端IP: 10.xx.xx.79

- 用户部门: xx工程部-xxx部

HIDS检测结果

对攻击者主机10.xx.xx.35进行HIDS检测：

1. 进程信息: 主机运行了nginx、postgres、docker相关进程，未发现异常进程

2. 端口信息: 开放了22(SSH)、80(HTTP)、5432(PostgreSQL)等常规服务端口

3. 异常登录: 未发现异常登录记录

4. 后门检测: 未发现后门程序

5. 反弹Shell: 未发现反弹Shell行为

攻击行为分析

根据蜜罐告警和堡垒机日志，攻击者通过TCP连接尝试访问蜜罐的22端口（SSH服务），并在同一时间段内通过堡垒机执行了多次telnet连接尝试，确认攻击行为来自用户zhangxxxxx的操作。

HIDS告警溯源分析

HIDS基于主机的告警类型比较多，此处我们用真实的例子，说明在命令执行场景中，借助MCP能力，大模型能够自行分析恶意进程，并关联HIDS的其他告警信息，最终给出行为分析和结论：

告警溯源信息

根据告警详情，这是一个HIDS告警，属于"web命令执行"类别。我将从HIDS检测的角度进行分析：

HIDS告警分析报告

告警基本信息

- 告警类型: HIDS - web命令执行

- 告警等级: 中危

- 触发规则: [web命令执行]Java服务异常写文件

- 告警时间: 2025-09-07 11:51:36 UTC

- 主机名: nvm-xxxxx-14

- 操作系统: Linux (Debian GNU/Linux 11.6)

主机信息溯源

- 主机名: nvm-xxxxx-14

- IP地址: 10.xxx.xx.41 (主要IP)

- 连接IP: 10.xxx.xx.13

- 操作系统: Debian GNU/Linux 11.6

- 所属业务组: xx技术中心

- 云平台: OpenStack Nova虚拟机

用户信息溯源

- 操作用户: root (UID: 0)

- 最后登录用户: zhuxxxjie (朱xx)

- 用户部门: xx技术中心-xx研发组

- 最后登录时间: 2025-09-07 00:52:53

- 登录来源: 10.xxx.xx.18 (通过SSH)

进程信息分析

主机运行的主要进程包括：

- sshd: SSH服务进程，开放22端口

- java: Jenkins agent进程，连接至 http://xxx.bilibili.co/xxx/

- node_exporter: Prometheus监控进程，开放9100端口

- titanagent/titan_monitor: 安全监控agent

- chronyd: 时间同步服务

- 常规系统进程: systemd, cron, rsyslogd等

命令执行分析

触发告警的命令:

node /usr/local/bin/claude -p /data/soft/ClaudeCodeReviewPrompt/java.txt

执行的bash脚本内容:

- 创建shell快照文件 /root/.claude/shell-snapshots/snap17067224-n3plkv.sh

- 使用base64编码/解码函数定义

- 使用eval执行动态代码

- 设置PATH环境变量包含多个Java和Node.js路径

安全检测结果

1. 进程检测: 未发现异常进程，均为系统正常服务进程

2. 端口检测: 仅开放22(SSH)和9100(node_exporter)端口，无异常端口

3. 账户检测: 系统账户状态正常，root账户有堡垒机SSH密钥授权

4. 异常登录: 未发现异常登录记录

5. 后门检测: 未发现后门程序

6. 反弹Shell: 未发现反弹Shell行为

攻击行为分析

根据HIDS检测和命令分析，该告警由Claude代码审查工具触发：

- 执行上下文: Node.js执行的Claude代码审查工具

- 行为特征: 创建shell环境快照文件，涉及动态代码加载和文件操作

- 风险等级: 中危 - root权限下执行包含eval和base64操作的脚本

- 关联信息: 该操作为代码审查工具的正常功能，但触发了HIDS的web命令执行检测规则

该告警属于误报情况，是开发工具的正常操作触发了安全检测规则。

EDR告警溯源分析

对于EDR的告警，我们更加聚焦于员工的行为分析，以某位员工终端设备疑似被病毒感染的告警为例：

告警溯源信息

根据EDR告警信息，我为您进行溯源分析：

用户信息溯源

- 用户名：xxx（徐xx）

- 所属部门：xxx发行部-xxxx项目组

设备信息溯源

- 主机名：WIN-xxxxxx

- IP地址：10.xxx.xxx.151（主要IP），10.xx.xxx.69

- 操作系统：Windows 10

- 办公区域：国正

恶意文件信息

- 文件名：hitokoto_api.exe

- 文件路径：C:/Program/Data/Autodesk/Application/Pluginsng/skintools2Contents/scripts/ngSkinTools2api/hitokoto_api.exe

- MD5：7f1a37388876e4b6eac5609cab534a56

- 病毒类型：Win32.Trojan.Agent.ckjl (aiScore=h)

- 发现时间：2025-09-05 15:33:23

关联信息

该恶意文件位于Autodesk 3D建模软件插件目录下，具体路径为ngSkinTools2（Maya皮肤工具插件）的API文件夹中。hitokoto_api.exe文件名暗示可能与"一言"API相关，但实际为特洛伊木马程序，疑似通过Autodesk相关软件或插件进行伪装植入。该IP地址历史使用记录显示，当前用户xxxxx从2025年8月11日开始使用此IP地址。

可见大模型可根据提供的MCP工具，自行查询并给出用户信息，包含用户名，部门、操作系统，办公区域等，并在关联分析中，给出员工从8月11日开始使用该IP，且因为使用了带病毒的Autodesk 3D建模插件，触发了EDR告警。

AI提效

通过半年的探索实践，以HIDS告警比较多的命令执行为例，以往人工研判的告警每天大概30条左右，接入大模型后，需人工研判的数量下降到了1-3条，降噪率平均约93.33%，对于降噪后的告警，结合AI的自动化溯源分析，大大提升了运营人员的安全问题排查效率。

未来畅想

基于上述实践，我们认为未来的安全产品与安全设备在交付时，将不仅仅局限于提供传统的OpenAPI 接口，还会同时向客户开放基于 MCP 的工具集。借助大模型能力的延伸，用户可以直接将安全产品与自身的大模型平台对接，实现更自然的交互与更高效的使用体验。

这种模式将显著提升客户在告警关联分析与自动化安全运营方面的效率，使安全产品从“单点能力输出”转变为“智能化协同伙伴”，帮助企业更好地应对复杂多变的安全威胁。

总结

通过本次在 B 站基础安全体系中的探索实践可以看到，AI 已经不再只是辅助告警分析的“锦上添花”，而是逐步演变为推动告警运营自动化与溯源智能化的核心引擎。从告警解读、研判到降噪，再到与内部安全数据的深度关联，AI-Agent 借助 MCP 协议真正成为了连接安全产品能力与智能分析的桥梁。

在实践案例中，无论是蜜罐、HIDS，还是 EDR 的告警，AI 都能够在具备足够上下文和工具集的前提下，完成从事件追踪、行为分析到责任主体定位的完整溯源链路。这不仅显著提升了运营人员的效率，也推动了“人机协同 + 自动化溯源”的落地。

展望未来，随着 MCP 工具集逐渐成为安全产品的标配，AI 在安全运营中的价值将进一步释放。安全部门能够在更短的时间、更低的成本、更高的准确性下完成告警处置与溯源，为企业抵御日益复杂的安全威胁提供坚实保障。

-End-

作者丨zhiye

开发者问答

对于网络安全&大模型的探索，大家还有哪些落地实践？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取宝可梦徽章（随机款）

抽奖截止时间：11月14日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

RIVAL：面向机器翻译的迭代对抗强化学习

Fri, 31 Oct 2025 12:04:00 +0800

原创 AI 2025-10-31 12:04 上海

本文提出 RIVAL 框架，通过对抗式迭代优化解决了RLHF在口语字幕翻译中的分布偏移问题。

一、概述

本文提出 RIVAL（Reinforcement Learning with Iterative and Adversarial Optimization），一种针对机器翻译（MT）的迭代对抗强化学习框架。我们发现基于人类反馈的强化学习（RLHF）在口语化字幕翻译任务中表现不佳，主要是因为奖励模型（RM）与翻译模型（LLM）之间存在分布偏移，导致训练失效。RIVAL通过以下创新解决该问题：

对抗博弈机制：将RM与LLM的优化过程建模为最小化-最大化博弈，RM负责区分强弱翻译，LLM负责优化弱翻译，以缩小与强翻译的质量差距。
双奖励设计：结合语义对齐的定性偏好奖励与定量偏好奖励（如：BLEU分数），提升迭代强化学习训练的稳定性与泛化性。

实验表明，RIVAL在口语字幕和WMT数据集上显著优于监督微调（SFT）和专用翻译模型（如：Tower-7B-v0.2），同时保持跨语言泛化能力。

论文已被EMNLP 2025收录，链接：https://arxiv.org/abs/2506.05070

二、动机

大语言模型（LLM）在多任务中展现出突破性能力，其强大的多语言理解与生成能力为MT提供了新范式。大部分研究是基于极大似然估计的SFT，这种方法容易受到暴露偏差的影响，导致错误累积与翻译质量退化。同时，有限的句子级上下文建模能力难以保证全局连贯性。所以另一种可选的方案是RLHF。当前MT研究主要聚焦于正式的书面语，而口语化字幕翻译面临独特挑战：口语化字幕具有高度非正式性（如俚语、语气词、语法省略）、结构松散及多领域混杂性等特点，在真实场景中缺乏高质量平行语料，传统依赖人工标注的评估方法（如BLEU）在语义对齐优先的场景中失效。为填补这一空白，我们首次构建了大规模口语化字幕数据集，并尝试应用RLHF优化翻译质量。

我们在探索LLM在机器翻译中的应用时，发现使用RLHF优化口语化字幕翻译任务的效果不佳。具体示例如下：LLM对源文本翻译完成后，又额外补充了“It's ok! It's great!”的正向翻译，但源文本中并没有对应的原文。这种“投机行为”导致翻译失真，违背语义忠实性原则，是典型的Reward Hacking问题。

^{Reward Hacking示例}

为了探究出现Reward Hacking的原因，我们对比了RM与GPT-4o的评分差异。我们发现RM的评分差（强翻译-弱翻译）持续下降：随着LLM优化，评分差越来越大，RM误判弱翻译的质量越来越好。然而，GPT-4o的评分差先降后升，表明真实的弱翻译质量先因初始正确的奖励信号不断提升，后因翻译模型过拟合RM而偏离真实的质量评分。追溯其根本原因，离线RM是基于初始的弱翻译训练得到的，无法适应LLM优化过程中数据的分布偏移，导致给出的奖励信号失效。

^{RM和GPT-4o对强弱翻译的评分差}

受生成对抗网络（GAN）的启发，我们提出RIVAL框架：将RM与LLM的优化过程建模为最小化-最大化博弈，二者可通过博弈共同进化，离线RM被转化为在线RM，从而避免数据分布偏移问题。

三、方法

3.1 RIVAL框架：对抗式迭代优化范式

RIVAL框架将传统RLHF的两阶段训练重构为RM与LLM的对抗博弈。其核心思想源自GAN的生成-判别机制，形式化为以下最小化-最大化目标：

其中，r_Phi是奖励模型，作为判别器来区分强弱翻译，pi_theta是翻译模型，作为生成器逼近来强翻译分布P_strong，pi_ref是参考模型，即初始化的模型，通过KL散度约束防止模型过度偏移。通过不断地迭代优化，并且利用当前轮的LLM构造RM的训练数据，RM能够有效地学习并适应新的数据分布。同时，LLM也能在准确的奖励信号监督下不断探索新的动作空间，从而逐渐变成强翻译模型。RIVAL框架的示意图如下：

^RIVAL框架

3.2 RM和LLM优化

在RM优化时，固定LLM的参数，其优化目标简化为：

其中，x 是输入的源文本，y_strong是GPT-4o生成的强翻译，y_weak是当前LLM生成的弱翻译。其物理含义为尽可能增大强弱翻译之间的差距，损失函数的形式为rank loss。在本文中，我们将其命名为定性的偏好损失。此外，在每一轮的迭代训练中，我们不仅只利用当前轮LLM生成的弱翻译，也会回放历史轮数据，来增强数据的多样性以及防止数据分布偏移。

相似地，LLM优化时，我们需要固定RM的参数。其优化目标被简化为：

其物理含义为尽可能最大化RM给出的奖励分数。我们采用GRPO算法来优化LLM模型。

3.3 结合定量偏好奖励

由于翻译任务的动作探索空间比较大，在GRPO训练中，只依赖定性偏好奖励可能会导致训练不稳定。另外，考虑到计算开销，我们设计了多头RM，一个输出头用来预测定性偏好奖励，另一个输出头用来预测定量偏好奖励，例如：BLEU分数。所以，最终我们的RM损失函数除来上述介绍的rank loss，还包含了对BLEU分数预测的mae loss。具体形式如下：

详细的算法流程图如下：

^{RIVAL算法流程图}

四、实验

我们在自建的口语字幕数据集和WMT标准数据集上验证RIVAL框架的有效性。针对两个任务的特性，我们选用了不同的评估指标：口语字幕任务采用GPT-4o多维度评分（准确性、完整性、连贯性、风格一致性）和COMETKiwi指标，因为更侧重语义对齐而非字面匹配；WMT任务则同时使用BLEU和COMETKiwi，以兼顾词汇忠实度与语义充分性。

在口语字幕翻译任务中，RIVAL框架展现出显著优势。仅使用定性偏好奖励的RIVAL-Iter1模型在GPT-4o评估中达到3.68的平均分，较基线模型提升5.5%，COMETKiwi指标同步改善至66.27。然而，迭代至第三轮时GPT-4o的评分出现回落（平均分3.53），表明纯定性偏好奖励在开放空间中的优化方向存在不稳定性。WMT翻译任务的实验进一步验证了双奖励机制的必要性。当引入定量偏好奖励（BLEU）后，RIVAL-Iter2-Qual+Quant在英中和中英翻译任务上的BLEU分数和COMETKiwi指标都优于使用单独的定性偏好奖励优化的模型。这种提升源于双奖励的协同作用：定量奖励锚定词汇对齐，定性奖励保障语义质量。

^{RIVAL框架在字幕翻译和WMT翻译任务上的效果}

在跨语言泛化性测试中，RIVAL展现出优于SFT的鲁棒性。以医疗领域的中德翻译为例，SFT模型在OOD场景下COMETKiwi降至49.15，显著低于原始模型（52.58），而RIVAL-Iter1仍保持53.42的优异表现，甚至在部分OOD任务上超越原始模型，证明其通过探索有效翻译策略而非模式记忆实现泛化。

我们也画了后两轮迭代过程中RM和GPT-4o对强弱翻译的评分差，从图中可以看到，RIVAL通过对抗机制将评分差稳定维持在较小范围，有效缓解了奖励模型与翻译模型间的分布偏移问题。

五、总结

本文提出 RIVAL 框架，通过对抗式迭代优化解决了RLHF在口语字幕翻译中的分布偏移问题。RIVAL将LLM和RM的优化建模为最小化-最大化博弈：RM最大化强弱翻译评分差距，LLM缩小与强翻译质量差距，并创新引入双奖励机制使得训练更稳定。我们在口语字幕翻译任务和WMT英中翻译任务中，验证了RIVAL方法相较基线、SFT模型和专用翻译模型的优越性。此外，RIVAL在OOD测试中的性能也超越SFT，证明其通过探索有效策略避免灾难性遗忘。尽管迭代上限与计算成本仍需优化，但该框架为机器翻译甚至后训练方法提供了兼具理论创新与实用价值的新范式。

参考文献

[1] Ouyang L, Wu J, Jiang X, et al. Training language models to follow instructions with human feedback[J]. Advances in neural information processing systems, 2022, 35: 27730-27744.

[2] Luo W, Li H, Zhang Z, et al. Sambo-rl: Shifts-aware model-based offline reinforcement learning[J]. arXiv preprint arXiv:2408.12830, 2024.

[3] Goodfellow I J, Pouget-Abadie J, Mirza M, et al. Generative adversarial nets[J]. Advances in neural information processing systems, 2014, 27.

[4] Shao Z, Wang P, Zhu Q, et al. Deepseekmath: Pushing the limits of mathematical reasoning in open language models[J]. arXiv preprint arXiv:2402.03300, 2024.

[5] Achiam J, Adler S, Agarwal S, et al. Gpt-4 technical report[J]. arXiv preprint arXiv:2303.08774, 2023.

[6] Rei R, Treviso M, Guerreiro N M, et al. CometKiwi: IST-unbabel 2022 submission for the quality estimation shared task[J]. arXiv preprint arXiv:2209.06243, 2022.

[7] Shoeybi M, Patwary M, Puri R, et al. Megatron-lm: Training multi-billion parameter language models using model parallelism[J]. arXiv preprint arXiv:1909.08053, 2019.

[8] Sheng G, Zhang C, Ye Z, et al. Hybridflow: A flexible and efficient rlhf framework[C]//Proceedings of the Twentieth European Conference on Computer Systems. 2025: 1279-1297.

[9] Guo D, Yang D, Zhang H, et al. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning[J]. arXiv preprint arXiv:2501.12948, 2025.

[10] Alves D M, Pombal J, Guerreiro N M, et al. Tower: An open multilingual large language model for translation-related tasks[J]. arXiv preprint arXiv:2402.17733, 2024.

-End-

作者丨Index MT Team

开发者问答

除了机器翻译，你觉得对抗式强化学习还能解决LLM在哪些任务上的"投机行为"问题？

欢迎在留言区分享你的见解~

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取1位幸运的小伙伴获取宝可梦徽章（随机款）

抽奖截止时间：11月7日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路