刚刚，扩散模型杀进Agent主场：350亿参数，速度比Jev快一倍
虽然名字里多了“扩散”两个字，但实际体验下来，无论是写代码、操作网页、调用工具，还是生成HTML，用法都和我们熟悉的大语言模型差不多。
量子位 | 公众号 QbitAI
服了！天天在AI一线冲浪，竟然也会跟不上版本。
谁能想到，印象中用来生图、生视频的“扩散模型”，竟然也能写代码、生成网页、调用工具，当Agent了！
就在刚刚，扩散智能发布了全新的扩散语言模型——
Clover-35B-A3B-Preview。
虽然名字里多了“扩散”两个字，但实际体验下来，无论是写代码、操作网页、调用工具，还是生成HTML，用法都和我们熟悉的大语言模型差不多。
我个人用下来的第一感受就是一个字：“快”。
比如，让它生成一个太阳系模拟器，Clover就思考了约1秒，然后也就4-5秒，一个能交互的太阳系模拟器就出来了。
再比如，我给它丢了一堆简历信息，让它整理成LaTeX格式的简历代码，也就十来秒，搞定～
有一说一，用过GPT的朋友，应该都懂盯着“正在思考”等半天是什么感觉，要不然最近也不会有主打快速决策的Jev什么事儿～
而说到Jev，Clover这次还真和它比了一把速度。
在网页Agent评测WindTunnel的49个任务中，每个任务尝试3次，Clover的中位执行时间为1.52秒，Jev＋Mercury 2.5组合为3.21秒，用时少了一半多。
尝试成功率也略高，分别为98.6%和95.9%。
对比同表中的Gemini，速度更是快了好几倍！
好好好，你个扩散模型，要把自回归逼疯？（doge）
会做Agent任务的扩散模型
说回模型，Clover-35B-A3B-Preview这次采用MoE架构，总参数350亿，每个token激活约30亿参数，支持思考模式。
它进一步将团队的扩散语言模型，从此前Dream 7B的70亿参数，推进到了350亿总参数规模。
更关键的是，参数量上来后，Clover的速度并没有因此变慢，它在同尺寸对比中超过自回归模型。
除了前面的交互页面和代码生成，官方演示里，Clover还进一步展示了复杂任务、WebUI生成等Agent能力。
Clover可以通过WebMCP，连续处理六项任务，涉及开票、课程报名、金额汇总、活动状态查询、以及客户信息查询和发票信息查询。
从下面的对比视频我们可以看出，Clover不仅成功完成任务，还在执行速度上彻底甩开了Gemini 3.6 Flash。
在线上购物场景中，Clover还能按要求找到指定款式、黑色、L码的T恤，加入购物车，填写访客信息，再走完测试结账流程。
老实说，这种连续任务的处理其实是这次演示值得关注的地方。
要知道，扩散语言模型虽然有并行生成的速度潜力，但在做Agent任务时，以往的表现其实还不够稳定：
模型工具调用格式可能出错，也容易在同一个步骤上反复尝试，没能根据返回结果调整动作。
Clover这次的进步，就体现在这些连续操作里：调用工具、读取反馈、继续执行，直到完成任务。
具体到Benchmark，按照团队公布的数据，Clover在工具使用相关的τ³ Overall和BFCL-v4评测中，分别拿到65.3和67.9，位居前列。
△ 图源：扩散智能
Agent任务看完，再看看代码。
我又让Clover生成了一个个人Agent的网页界面。看起来也是有模有样，整个生成过程也就十几秒。
在代码评测这边，Clover也交出了一组不错的成绩。
在考察真实代码仓库问题解决能力的SWE-bench Verified上，它拿到73.6；在考察终端任务执行能力的Terminal-Bench 2.1上，拿到51.7。
△ 图源：扩散智能
可以说，从生成交互页面，到调用工具、跑完业务流程，再到代码评测，身为扩散语言模型的Clover，这次确实接了不少Agent的活。
哎，这就有意思了。印象里负责去噪生图的扩散思路，到了语言模型里，究竟是怎么生成文字、写出代码的？
难不成上面的demo真是AIGC出来的？
扩散语言模型，什么来头？
一般来说，我们熟悉的自回归（Autoregressive，AR）语言模型是根据前文预测下一个token，生成一个，再接着生成下一个，也就是大家常说的“词语接龙”。
这里的token，可以简单理解成模型处理的文字片段。
相比于自回归模型的逐个串行预测生成，扩散语言模型则换了一种生成方式：允许多个位置同时更新，再经过几轮完善，逐步得到结果。
△ 图源：AI生成
这里的扩散去噪，可以理解为把被遮住或受到扰动的内容，逐步恢复成符合上下文的文字。
具体到Clover，它采用的是块扩散：把待生成的内容分成若干块，块与块依次推进，块内多个位置并行更新、相互参考。
这样一来，一轮计算就有机会推动多个位置的生成，减少逐个生成带来的等待。
但问题在于，能一起生成并不代表一轮就能写好。
因为扩散模型往往需要多轮去噪，才能把结果逐步确定下来。轮数太少，内容可能还没调整好；多来几轮，计算开销也跟着增加。
到了代码和Agent任务，上下文还会不断变长。之前的要求、已经执行的操作、工具返回的结果，都可能影响下一步，历史信息的保存和读取也成了效率问题。
Clover的改进思路，就是让历史记忆和当前生成各司其职。
它围绕块扩散重构了门控Delta网络（GDN）：已经生成的上下文被压缩进持续更新的状态，供后续步骤读取；当前生成的块则通过双向注意力，让块内的token相互参考。
与此同时，Clover将历史记忆的读出作为独立的信息单元，与当前token一起参与注意力计算，让模型自己学习如何权衡前文与当前内容；再通过可学习的块大小校准，减少块变大后历史信息被稀释的问题。
换句话说，这些调整的目标，就是让并行生成、历史信息利用和计算效率更好地配合，这也是Clover将扩散语言模型进一步推进到代码和Agent任务的关键。
而除了Clover以外，扩散语言模型这两年之所以受到关注，也主要在于它相对于自回归的两大优势：
一方面，扩散语言模型允许多个位置同时生成，有机会减少逐token生成带来的串行等待。对于需要反复生成代码、调用工具的Agent，这种潜力尤其值得关注。
另一方面，生成过程中，前后内容可以相互参考。在双向建模的设计下，多个位置能在迭代中共同调整，为处理内容之间的依赖关系提供另一种方式。Clover当前块内的交互，就是其中一种实现。
围绕这些可能性，学术界和产业界已经给出了不同的尝试。
何恺明今年参与的ELF，尝试在连续嵌入空间中生成语言；谷歌推出的DiffusionGemma，探索并行文本生成；国内大厂也在研究面向代码任务的扩散语言模型。
具体方法各不相同，大家都在尝试把另一种生成方式，变成能用起来的能力和效率。
Clover这次，则把自己的进展放进了代码、工具调用和连续任务里，交给用户上手检验。
从DiffuSeq到Clover，扩散智能的下一步
最后，让我们说回Clover背后的团队——
扩散智能。
据悉，扩散智能由香港大学孔令鹏教授及其博士生龚珊三、叶佳成联合创立。团队成员对扩散语言模型的探索，可以追溯到2022年。
那一年，他们提出了DiffuSeq，研究如何用扩散模型完成序列到序列的文本生成：给定一段文字，再按条件生成另一段文字。
当时要迈过的一道坎，就是把擅长处理图像等连续信号的扩散方法，用到离散的自然语言上。
到了2025年4月，团队核心成员参与推出Dream 7B，将研究推进到70亿参数语言模型。
根据当时公布的结果，Dream 7B在通用、数学和代码任务上，取得与同规模自回归模型可比的表现，也展示了规划能力和生成顺序上的灵活性。
再到这次的Clover，模型规模继续扩大，写代码、调用工具、连续执行任务，都成了重点展示的内容。
这条路线，也就从最初研究怎么生成文字，一步步走到了如何把复杂任务做对、做快。现在，团队还在往多模态和端侧延伸。
据介绍，Clover后续也将推出多模态版本，团队正在推进扩散语言模型与多模态理解及动作生成的结合，并持续开展端侧场景的适配与验证。与Acrab的合作，则在推进面向端侧场景的系统适配和软硬件协同验证。
按照团队计划，接下来还会继续探索更大规模的模型，提高长程任务的稳定性，并通过推理优化、量化和部署适配，推进端侧应用。
最后的最后，咱们不妨借着这次新发布的Clover开个脑洞：
人类思考时，究竟是一句接一句往下推，还是先有个模糊的整体，再逐渐补全细节——
大脑究竟更像自回归，还是扩散？
