开源的世界里，没有微不足道的参与，只有共同成就的未来。

回望 2025，龙蜥社区始终向上突破——从技术演进到解决方案规模化落地，从高校开源教育到生态拓展，龙蜥社区交出了一份扎实而令人自豪的答卷。

而你，或许曾提交过代码、参与过活动，又或许只是默默关注、静静使用——无论以何种方式同行，你都是这段旅程中不可或缺的一份力量。正是因为你的每一次关注与信任，都为龙蜥注入了前行的动力。

值此龙蜥社区成立五周年& 2026 新年来临之际，为感谢大家的一路相伴，我们特别准备了上千份精美礼品，包括龙蜥定制保温杯、限定款龙蜥卫衣、萌趣小龙抱枕、猫超卡、B 站/腾讯视频月卡等。诚挚邀请每一位关注、使用或贡献过龙蜥的朋友，打开龙蜥社区官网（openanolis.cn），一起回望 2025 年那些你在社区留下的珍贵“足迹”，重温属于你与龙蜥的共同记忆，还有精美周边领取哦。

活动时间：2026 年 2 月 10 日-3 月 31 日

（图/龙蜥开源足迹活动礼品图集）

开启你的“龙蜥开源足迹”

活动期间，首次登录龙蜥官网，会自动弹出“龙蜥开源足迹”，一键点击开启。若手滑退出或再次进入龙蜥官网，不用担心，可在官网顶部点击“龙蜥开源足迹”图片或官网右侧图标，都可开启活动。

兑换礼品

活动截止时间：2026 年 3 月 31 日。

📌 兑换流程：开启龙蜥之旅，回顾年度开源足迹，点击抽盲盒。
🎁 礼品邮寄：根据中奖提示，填写收件信息。工作人员会在 3 月起陆续安排邮寄。

彩蛋

除领取盲盒外，还可以下载“龙蜥开源足迹”图片，并在龙蜥公众号（搜 OpenAnolis 龙蜥）发布的这篇文章评论区留言，注意必须带“龙蜥开源足迹”图 + 评论（图片示意图如下所示；评论格式为“2026，我祝龙蜥社区...”内容不限，祝福或需求都可）。我们将按照规则送出龙蜥定制双肩包。

（图/“龙蜥开源足迹”示意图）

✨ 送礼规则

高赞有礼！我们将分别在 2 月 27 日（统计 2 月 10-26 日 23:59 的点赞数）、4月 1 日（统计 2 月 27 日-3 月 31 日 月 1- 30 日 23:59 的点赞数）各公布评论点赞排名前 10 的用户，送出龙蜥定制双肩包一个。

届时请大家及时关注龙蜥公众号（OpenAnolis龙蜥），获奖名单将在以上两个开奖日通过公众号文章的形式公布，请及时填写邮寄地址。

注意：评论须为原创，禁止发广告、拉踩等无意义内容，同一用户多条评论仅取点赞最高的一条参与当期评选。2 月已获奖的用户将不再参与 3 月的点赞排名评选。

快来一键开启你的龙蜥开源足迹吧～

—— 完 ——

在制造业的竞争格局中，产品研发的效率与质量已成为企业核心竞争力的关键。然而，传统的研发管理模式往往面临信息割裂、流程冗长、协作低效等痛点。设计图纸版本混乱、跨部门沟通成本高、质量风险难以提前识别等问题，不仅拖慢了产品上市速度，也增加了研发过程中的隐性成本。面对这些挑战，越来越多的企业开始将目光投向设计研发协同平台，希望通过数字化手段重构研发流程，实现数据驱动的协同创新。
设计研发协同平台的核心价值
设计研发协同平台并非单一的工具叠加，而是一种系统性的研发管理理念的落地。它通过整合产品生命周期中的需求、设计、仿真、试制、质量等环节，构建起一个统一的数据底座和协作环境。在这个平台上，三维模型、技术文档、物料清单（BOM）等核心数据得以结构化存储和动态关联，任何变更都能实时传递到所有相关环节，从而避免因信息滞后导致的错误和返工。更重要的是，平台打破了部门壁垒，使得设计、工艺、生产、质量等团队能够在同一语境下协作。例如，设计人员发起的模型修改，工艺人员可以即时反馈可制造性意见，质量人员则能同步更新FMEA（失效模式与影响分析）中的风险控制措施。这种“设计-工艺-质量”的一体化协同，不仅加速了决策流程，也从根本上提升了产品的可制造性和可靠性。
技术实现与流程重构
从技术层面看，现代设计研发协同平台通常基于云原生架构，支持分布式协同和轻量化应用。通过模型轻量化技术，非设计人员（如采购或质量工程师）无需安装专业CAD软件，即可通过浏览器查看、批注甚至参与评审复杂的三维模型。同时，平台内置的流程引擎将传统的纸质审批、邮件沟通转变为自动化的工作流，任务推送、节点提醒、权限控制等功能大幅减少了人为延误。在质量管控方面，平台通过集成FMEA管理模块，将历史故障库、行业标准与实时项目数据打通。系统能够基于相似产品或设计特征，自动推荐潜在的失效模式及改进措施，从而帮助工程师在研发早期识别风险，而非事后补救。这种预防性的质量保障机制，使得平台不再是简单的文档管理系统，而是贯穿产品创新全过程的智能决策支持系统。
实践案例
在国内，广域铭岛旗下的Geega（际嘉）工业互联网平台已成为研发协同领域的代表性解决方案。在某汽车零部件企业的实践中，Geega平台通过统一数据源和流程集成，实现了BOM准确率提升至98%，设计变更审批周期缩短50%，零部件复用率提高30%。其特点在于深度契合中国制造业的需求，注重轻量化部署和低成本适配，尤其擅长与现有ERP、MES系统的集成，帮助企业以较低门槛实现研发数字化。相比之下，国际厂商如PTC的Windchill和西门子的Teamcenter则代表了另一种路径。PTC通过强化AR/VR与数字孪生技术的融合，使研发协同不再局限于桌面屏幕，而是延伸至车间现场和远程运维场景。例如，工程师可通过AR设备在物理原型上叠加虚拟设计模型，直接进行偏差比对和装配验证。西门子Teamcenter则依托其完整的PLM（产品生命周期管理）生态，实现了从设计、仿真到制造执行的全链条数据闭环，特别适用于大型跨国企业的多地点、多学科协同需求。尽管路径不同，这些平台都在试图解决同一问题：如何让研发更高效、更可靠、更贴近市场需求。
设计研发协同平台的崛起，标志着制造业研发模式从“粗放式管理”向“精细化运营”的转变。它不仅仅是一种技术工具，更是企业重塑研发体系、构建数字驱动文化的重要契机。当数据成为新的生产要素，协同成为新的创新范式，那些率先拥抱这一变革的企业，无疑将在未来的市场竞争中占据先机。

在上篇文章（你的 7x24 “AI 运维同事”，OC 9 + OpenClaw 部署及实战指南）中，我们介绍了如何基于OpenCloudOS 9 安装配置OpenClaw，并接入企业微信等IM，让你最终拥有一位 7x24 的“AI全能助理”。一些用户看完文章后跃跃欲试，但一上手实操，却被繁琐的配置劝退了：

● “Node.js 版本不对，报错了……”

● “GitHub 连不上，插件装不下来……”

● “我想接企业微信，怎么还得手动改配置文件？”

大家的痛点，OpenCloudOS社区听到了！

为了让大家把精力从“装环境”转移到“用 AI”上，带来了 OpenClaw x OpenCloudOS 2.0 部署方案 。这一次，我们推出了一键安装脚本，用户只要一条命令就能极速体验OpenClaw。

一、 新版“极速部署脚本”做了什么？

1. 环境全自动适配 ：自动检测系统环境，帮你搞定 Node.js 24 等所有底层依赖，不再担心版本冲突。

2. 国内 IM 原生支持 ：不再需要满世界找插件。 企业微信、QQ、飞书、钉钉 ，你想用哪个，脚本直接帮你装好。

3. 网络与源优化 ：针对国内网络环境做了深度适配，下载更稳、速度更快。

简单来说：以前需要 30 分钟的手工操作，现在只需要 1 分钟等待。

二、极速版上手指南

2.1 安装 Openclaw 及IM相关插件

场景A：我全都要（推荐）

如果你希望 OpenClaw 能连接企业微信、QQ、飞书、钉钉等所有国内主流 IM，可直接运行如下脚本。

# 默认完整安装所有国内 IM 插件
curl -fsSL https://opencloudos.org/extra/deploy_openclaw.sh | bash

备注：因一键安装脚本会执行较多依赖并启动OpenClaw安装，所以整个安装过程大概耗时15-20min左右，中途请不要终止或推出。

一键安装脚本代码请见：scripts/deploy\_opneclaw.sh · OpenCloudOS/web-extra - Gitee.com

场景B：我只需要特定渠道

如果你只想安装某个指定IM（如企业微信和QQ），不想安装多余插件，可直接运行如下脚本。安装耗时：5-10min

# 安装指定IM（下方以同时安装企业微信和QQ为例）：
curl -fsSL https://opencloudos.org/extra/deploy_openclaw.sh | bash -s -- --plugins wecom,qq

场景C：纯净版安装

如果你只需要 OpenClaw 的核心功能（比如只在终端使用，或者通过 Web 界面交互），不需要连接任何国内IM，可直接运行如下脚本。安装耗时：2-3min

# 跳过所有 IM 插件安装：
curl -fsSL https://opencloudos.org/extra/deploy_openclaw.sh | bash -s -- --skip-plugins

# 手动打开交互命令
openclaw onboard

2.2 配置 OpenClaw

OpenClaw配置流程较多，OpenCloudOS已在上篇内容（你的 7x24 “AI 运维同事”，OC 9 + OpenClaw 部署及实战指南）进行了详细展示，这篇不再赘述。唯一不同的是，如您在2.1章节中执行了指定IM安装（如企业微信、飞书等），则会在IM配置环节的列表中，看见该可选项。

2.3 OpenClaw 运行状态确认

# 查看openclaw是否在后台运行
openclaw health
# 查看模型状态，是否连上了大模型
openclaw models list
# 查看聊天通道,比如qq，企业微信等
openclaw channels list

三、接入IM及实际应用演示

接下来，我们将详解如何配置企业微信、QQ、飞书、钉钉.

3.1 接入企业微信

OpenClaw 原生基本只支持国外社交软件，可以通过插件的方式来支持国内的社交软件。这里我们以企业微信为例，演示接入教程。

注意要接入企业微信有两个条件，首先你的clawdbot安装在有公网ip的机器上，2.你是企业管理员能创建APP或者机器人

# 查看企业微信插件运行是否加载
openclaw plugins list | grep -i wecom

企业微信插件使用目录

@marshulll/openclaw-wecom - npm

接下来需要在企业微信里创建一个一个应用，这一步需要首页 - 企业微信开发者中心先在这里创建一个应用。

选择个人

配置企业微信应用相关信息

首先获取如下信息

1.  登录 企业微信管理员后台

2.  在"我的企业"中查看 企业ID (CorpID)

3.  进入"应用管理" → 选择或创建应用

4.  在应用详情页获取：AgentId：应用ID

Secret(corpsecret)：点击"查看Secret"获取

5.  在"接收消息"设置中获取：Token：点击"随机获取"

EncodingAESKey：点击"随机获取"

然后在部署了openclaw的服务器上输入如下命令：

# 企业微信应用配置（必需）
# 这里配置的是 app 模式，可以参考插件使用指南换成bot或者both模式
openclaw config set channels.wecom.mode "app"
openclaw config set channels.wecom.defaultAccount "app"
openclaw config set channels.wecom.accounts.app.mode "app"
openclaw config set channels.wecom.accounts.app.webhookPath "/wecom/app"
openclaw config set channels.wecom.accounts.app.corpId "你企业ID"
openclaw config set channels.wecom.accounts.app.corpSecret "应用secret"
openclaw config set channels.wecom.accounts.app.agentId "你的应用ID"
openclaw config set channels.wecom.accounts.app.callbackToken "你设置的应用的token"
openclaw config set channels.wecom.accounts.app.callbackAesKey "你设置的应用的aes-key"
openclaw config set channels.wecom.enabled true
 
# 设置openclaw链接公网
openclaw config set gateway.bind lan
 
openclaw gateway restart
# 查看相关配置
openclaw channels list
openclaw config get channels

配置应该是这样的，我只配置了app，如果你配置了bot会更丰富一点


如上执行后，回到企业微信app管理界面，点击保存，企业微信会回发送token和AESKey去和openclaw服务器进行匹配

如果匹配成功界面如下

在企业微信里找到相关应用，直接和他聊天

可以看到 Clawdbot 确实识别到了相关的用户和请求

让 ClawdBot 创建一个定时任务：

可以看到确实创建完成了。

3.2 接入QQ

QQ更方便个人用户使用，OpenCloudOS也提供一个接入QQ的场景。

QQ插件地址https://github.com/sliverp/qqbot#

# 一件安装脚本已经安装了qq相关插件
# 查看当前的脚本
openclaw plugins list | grep qq
 
# 如果你开始没安装qq插件可以执行如下命令安装
openclaw plugins install https://github.com/sliverp/qqbot.git

创建QQ机器人：

访问 QQ 开放平台

创建机器人应用

获取 AppID 和 AppSecret（ClientSecret）

Token 格式为 AppID:AppSecret，例如 102146862:Xjv7JVhu7KXkxANbp3HVjxCRgvAPeuAQ

#方式一：交互式配置,选择 qqbot，按提示输入 Token
openclaw channels add
#方式二：命令行配置
openclaw channels add --channel qqbot --token "AppID:AppSecret"
# 示例
openclaw channels add --channel qqbot --token "102146862:xxxxxxxx"

配置好后在qq开发平台里的，沙箱配置里先点击添加成员再扫描二维码就能和ClawdBot沟通，并安排他工作了

3.3 接入飞书

飞书插件地址

GitHub - m1heng/clawdbot-feishu

# 一件安装脚本已经安装了飞书，查看飞书插件运行是否加载
openclaw channels list
# 如果没看到飞书执行如下命令
openclaw plugins enable feishu
openclaw gateway restart
# 如果没有安装飞书，那么执行如下命令
openclaw plugins install @m1heng-clawd/feishu

飞书应用（机器人）配置

进入飞书应用中心：开发者后台 - 飞书开放平台

创建企业自建应用

路径： 创建应用 → 企业自建应用

  基础信息按提示填写即可（名称、描述等），完成后进入应用详情页。

配置应用权限

进入 权限管理，添加以下权限（按插件文档要求）：

必要权限
|权限|范围|说明|
|-|-|-|
im:message |消息| 发送和接收消息
im:message.p2p_msg:readonly |私聊| 读取发给机器人的私聊消息
im:message.group_at_msg:readonly |群聊| 接收群内 @机器人 的消息
im:message:send_as_bot |发送| 以机器人身份发送消息
im:resource |媒体| 上传和下载图片/文件

可直接复制如下配置直接导入

{
  "scopes": {
    "tenant": [
      "bitable:app:readonly",
      "contact:user.base:readonly",
      "docx:document",
      "docx:document.block:convert",
      "docx:document:create",
      "docx:document:readonly",
      "drive:drive",
      "drive:drive:readonly",
      "im:chat:readonly",
      "im:message",
      "im:message.group_at_msg:readonly",
      "im:message.group_msg",
      "im:message.p2p_msg:readonly",
      "im:message:send_as_bot",
      "im:resource",
      "wiki:wiki:readonly"
    ],
    "user": [
      "contact:contact.base:readonly"
    ]
  }
}

进入凭证与基础信息 页面，记录 App ID / App Secret 同步更新到 openclaw 配置中

openclaw config set channels.feishu.appId "你的appid"
openclaw config set channels.feishu.appSecret "你的app_secret"
openclaw config set channels.feishu.enabled true
 
openclaw gateway restart
# 查看相关配置
openclaw channels list
openclaw config get channels

然后进入事件与回调界面，订阅方式选择长链接

之后点击右下角的添加事件

添加如下事件

|权限|范围|说明|
|-|-|-|
im.message.receive_v1 |接收消息（必需）| 发送和接收消息
im.message.message_read_v1 |消息已读回执| 读取发给机器人的私聊消息
im.chat.member.bot.added_v1 |机器人进群| 接收群内 @机器人 的消息
im.chat.member.bot.deleted_v1 |机器人被移出群| 以机器人身份发送消息

之后点击发布

在飞书里直接搜索 你机器人的名字就能和他聊天了。

3.4 接入钉钉

钉钉插件地址

GitHub - soimy/openclaw-channel-dingtalk: A dingtalk bot channel plugin for clawdbot

# 一件安装脚本已经安装了飞书，查看飞书插件运行是否加载
openclaw channels list
# 如果没看到飞书执行如下命令
openclaw plugins enable dingtalk
openclaw gateway restart
# 如果没有安装飞书，那么执行如下命令
openclaw plugins install https://github.com/soimy/clawdbot-channel-dingtalk.git

前往钉钉开发者后台，使用具有管理员权限的账号进行登录。选择

创建应用->填写应用名称 和 描述 -> 再点击左侧“添加应用能力” -> 选择 “机器人"->完善机器人配置 -> 消息接受模式选择 stream模式 -> 点击发布

然后点击坐上角的 "凭证与基础信息" 找到Client ID与Client Secret两个参数

然后再进入发布界面，点击保存

然后在服务器上输入

openclaw config set channels.dingtalk.clientId "你的ClientID"
openclaw config set channels.dingtalk.clientSecret "你的Client Secret"
openclaw config set channels.dingtalk.enabled true
openclaw gateway restart
# 查看相关配置
openclaw channels list
openclaw config get channels.dingtalk

接着你就可以在钉钉里搜索到你的应用并让他给你干活了。

参考链接

Node.js — 下载 Node.js®

Moltbot — Personal AI Assistant

openclaw企业微信插件

MoltHub

https://linux.do/t/topic/1518570

🚀 云上Moltbot（原Clawdbot）最全实践指南合辑-腾讯云开发者社区-腾讯云

openclaw的QQ机器人插件

Clawdbot 全面指南 - 汇智网

蚂蚁集团开源业界首个高性能扩散语言模型（Diffusion Large Language Model，dLLM）推理框架 dInfer。
在基准测试中，dInfer 将 dLLM 的推理速度相比于 Fast-dLLM 提升了 10 倍以上，并在关键的单批次（batch size=1）推理场景下，作为首个开源框架实现了大幅超越经过高度优化的自回归（AR）模型的性能里程碑，在 HumanEval 上达到 1011 tokens / 秒的吞吐量。dInfer 通过一系列算法与系统协同创新，攻克了 dLLM 的推理瓶颈，兑现了其内生并行生成带来的推理效率潜力。
这不仅为开发者提供了即刻可用的高效推理框架，更标志着扩散语言模型这一全新的范式迈出了走向成熟的坚实一步。

• 论文链接: https://arxiv.org/abs/2510.08666

• 项目地址: https://github.com/inclusionAI/dInfer 

  理论的「翅膀」，现实的「枷锁」：扩散语言模型的推理困境

  近年来，以自回归（Autoregressive，AR）范式为核心的大语言模型（Large Language Models）已经取得了巨大的成功，推动了智能问答、代码生成、智能体助手等领域的重大进步。然而，AR 生成范式也存在其固有瓶颈：生成过程完全依赖前序结果，必须逐词串行生成，这导致推理延时难以降低，即使 GPU 的并行计算能力强大也无用武之地。
  作为一种全新的范式，扩散语言模型（dLLM）应运而生。它将文本生成视为一个 「从随机噪声中逐步恢复完整序列」的去噪过程。这种模式天然具备三大优势：

• 高度并行：理论上可以在单次迭代中，并行地预测和更新序列中的多个 token
• 全局视野：模型的每一步决策都基于对整个序列的全局上下文理解，而非仅依赖于已生成的部分
• 结构灵活：更易于适应多模态、代码生成等需要复杂结构和长程依赖的任务
  凭借这些优势，以 LLaDA-MoE 为代表的 dLLM 已在多个基准测试中，展现出与顶尖 AR 模型相媲美的准确性 。然而在推理效率方面，dLLM 理论上的强大潜能，却长期被残酷的现实「枷锁」所束缚。dLLM 的高效推理面临三大核心挑战：
  1.高昂的计算成本：多步迭代去噪的特性，意味着模型需要反复对整个序列进行计算，这带来了巨大的算力开销
  2.KV 缓存的失效：dLLM 中的双向注意力机制，使得 token 对应的 KV 值在每次迭代中都会改变。这导致 AR 模型中「一次计算、永久复用」的 KV 缓存技术直接失效，使得推理过程异常昂贵
  3.并行解码的双刃剑：尽管理论上可以并行生成序列中的所有 token，但在难以精准刻画其联合概率分布的情况下一次性解码太多 token，极易引发彼此间的语义错配，导致「并行越多，质量越差」的窘境

这些瓶颈使得 dLLM 的推理速度一直不尽人意，其并行生成带来的效率沦为「纸上谈兵」。如何打破枷锁，释放 dLLM 在推理效率的潜能，成为整个领域亟待解决的难题。

dInfer：人人可上手的扩散语言模型高效推理框架

为彻底突破上述瓶颈，蚂蚁集团推出了 dInfer—— 一个专为 dLLM 设计的、算法与系统深度协同的高性能推理框架，可支持多种扩散语言模型，包括 LLaDA、 LLaDA-MoE、LLaDA-MoE-TD 等。

dInfer 的设计哲学是模块化与可扩展性，以系统性集成算法与系统优化。如下图所示，dInfer 包含四大核心模块：模型接入（Model）、KV 缓存管理器（KV-Cache Manager），扩散迭代管理器（Iteration Manager），和解码策略（Decoder）。

图 1. dInfer 架构

这种可插拔的架构，允许开发者像搭乐高一样，进一步组合和探索不同模块的优化策略，并在统一的平台上进行标准化评测。更重要的是，dInfer 针对上述三大挑战，在每个模块中都集成了针对性的解决方案。

表 1. dInfer 组件

dInfer 如何「快」起来？

1.削减计算成本，控制生成质量：邻近 KV 缓存刷新 (Vicinity KV-Cache Refresh)
dLLM 使用双向注意力机制让模型获得更全局的视野，代价是每次解码会影响所有的 token 的 KV 值，导致 AR 模型依赖的 KV 缓存技术不能直接应用到 dLLM 上。如果不使用任何 KV 缓存，在一个 sequence 上的一次 diffusion 迭代会导致大量的计算。

为了削减计算成本，Fast-dLLM 提出的将 sequence 划分为 block，然后再逐个对 block 进行解码，并在当前解码 block 之外进行 KV 缓存的方法，可以有效降低 diffusion 迭代的计算成本。然而虽然利用上了 KV 缓存，但在大部分情况下，缓存中的 KV 实际上是过时的，因此会导致生成质量的下降。

为了缓解这一问题，dInfer 采取了一种邻近刷新的策略：KV 缓存过时的原因是 dLLM 中一个新 token 的确定，会影响全局所有 token 的 KV 表示。而 dInfer 基于「语义局部性」原理（ 一个词的更新，对其近邻词的影响最大），在每次迭代解码一个 block 时，dInfer 只选择性地重新计算该区块及其邻近一小片区域的 KV，而让远处的缓存保持不变。这好比修改文档中的一句话，你只需检查上下文是否通顺，而无需重读整篇文章。
这种策略结合 dInfer 的其它优化，在计算开销和生成质量之间取得了平衡，首次让 KV 缓存机制在 dLLM 上高效、可靠地运作起来。

2.系统优化：让 dLLM 的前向运算速度追上 AR
在利用上 KV 缓存之后，dInfer 选择了合适的 block 大小和 Vicinity KV-Cache Refresh 的范围，并做了一系列的系统优化，以使 dLLM 一次迭代的速度能追上运行在 SOTA 的推理服务框架如 vLLM 上的 AR 模型，包括：

• 多卡并行：结合了张量并行 (TP) 与专家并行 (EP)，即使在 batch size=1 的条件下，也能充分利用 GPU 的算力，效率提升超 100%。
• 编译优化：通过 torch.compile 进行内核融合并编译为 CUDA Graph 执行，消除了 PyTorch 框架的执行开销，结合上述的多卡并行，可让效率提升 200%。
• 消除迭代之间的气泡：采用循环展开 (Loop Unrolling) 技术，让 Python 可以连续不断地启动 CUDA 内核，消除了迭代间的 GPU 空闲气泡，带来 5-10% 的性能提升。
• 早停：在生成 EOS token 后，跳过后续 block 的推理过程，可以减少 5-40% 不必要的开销。

3.并行解码：层级解码 (Hierarchical) 与信用解码 (Credit)
为了在保证生成质量的前提下，最大化并行解码的 token 数量，dInfer 提出了两种无需额外训练的解码算法 ：

• 层级解码 (Hierarchical Decoding)：该算法借鉴了「分治」思想，将待解码的区域不断递归地一分为二，并优先在每个子区域的中心位置解码 token 。这种方式自然地拉开了新生 token 间的距离，减少了它们之间的语义干扰 。在理想情况下，它能以近似对数级的复杂度完成多点并行生成，既快又稳 
• 信用解码 (Credit Decoding)：在多轮迭代中，有些正确的 token 可能很早就被模型稳定地预测出来，但因其单次置信度未能「达标」而被反复重算 。dInfer 为此引入了「累积信用」机制，持续追踪并累积每个 token 在历史迭代中的置信表现 。一个长期被稳定预测的 token，即使当前置信度稍低，也能凭借高累积信用被「破格」解码，从而有效避免了大量冗余计算

4.压榨每步迭代价值：迭代平滑 (Iteration Smoothing)
传统 dLLM 在每轮迭代中，只利用了置信度最高的 token 信息，而将其他位置的概率分布整个丢弃。dInfer 的迭代平滑算法，旨在回收这些被浪费的信息。

它基于未解码位置的 logits 分布得到该位置的加权 Embedding，并将其作为宝贵先验知识，平滑地融入下一轮迭代的 Embedding 中。这极大地丰富了上下文信息，使得单次迭代解码的 token 数量平均提升了 30-40%。

此外，由于 dInfer 可以无障碍地接入多种扩散语言模型，此次率先支持了基于轨迹蒸馏（Trajectory Distillation）加速 diffusion 去噪过程的 LLaDA-MoE-TD 模型，推理性能更强。

实测数据：里程碑式的性能飞跃

在配备 8 块 NVIDIA H800 GPU 的节点上，dInfer 的性能表现令人瞩目。

图 2. 评测数据

• 10 倍性能提升：在与先前的 dLLM 推理方案 Fast-dLLM 的对比中，dInfer 在模型效果持平的情况下，平均推理速度（avg TPS）实现了 10.7 倍的巨大提升（681 vs 63.6）
• 超越自回归：与在业界顶尖的推理服务框架 vLLM 上运行的、参数量和性能相当的 AR 模型 Qwen2.5-3B 相比，dInfer 的平均推理速度是其 2.5 倍（681 vs 277） 
• 突破推理极速：在代码生成任务 HumanEval 上，dInfer 在单批次推理中创造了 1011 tokens / 秒的纪录 。这是开源社区首次见证，扩散语言模型在延迟敏感的单批次推理场景下，速度显著超越经过高度优化的自回归模型

更进一步，当结合轨迹蒸馏（Trajectory Distillation）技术（一种让模型学会 「跳跃式」去噪的后训练优化方法）后，dInfer 的平均推理速度飙升至 847 TPS，实现了超过 3 倍于 AR 模型的性能。

开源开放：共建下一代 AI 推理新生态

dInfer 的诞生，不仅是一个工具的发布，更是一次 LLM 范式的试炼：它证明了扩散语言模型的效率潜力并非空中楼阁，而是可以通过系统性的创新工程兑现，使其成为 AGI 道路上极具竞争力的选项。
目前，dInfer v0.1 的全部代码、技术报告与实验配置已开源。
蚂蚁希望 dInfer 能成为：

• 研究者的标准平台：为 dLLM 领域的算法创新提供一个公平、高效的试验场 。
• 开发者的加速引擎：助力社区将强大的 dLLM 轻松部署到实际应用中，享受极致性能 。
  dInfer 连接了前沿研究与产业落地，标志着扩散语言模型从「理论可行」迈向「实践高效」的关键一步。我们诚邀全球的开发者与研究者一同加入，共同探索扩散语言模型的广阔未来，构建更加高效、开放的 AI 新生态。

在日常上网过程中，你可能听说过“浏览器指纹检测”这个概念，但具体它是怎么工作的，尤其是“浏览器Canvas 指纹”，很多人还是一头雾水。

今天，就给大家聊聊什么是 Canvas 指纹，它对隐私的威胁，以及如何在 Chrome、Edge、Firefox 上有效防护，顺便分享一些实用工具和操作技巧。

什么是浏览器Canvas 指纹？

简单来说，浏览器Canvas 指纹是浏览器指纹检测的一种方式。它通过浏览器渲染一段隐藏的图形（Canvas），然后读取渲染结果的像素信息。每台电脑、每个浏览器的硬件和软件环境不同，比如显卡型号、操作系统字体、驱动版本等等，这些细微差异会让 Canvas 渲染出的图像“唯一化”，从而生成一个“指纹”，可以用来追踪你的上网行为。

也就是说，即便你关闭了 Cookie，网站仍然可以通过 Canvas 指纹识别你是不是同一位访问者。听起来有点吓人对吧？这也是很多隐私保护爱好者特别关注的点。

浏览器指纹检测的危害

浏览器指纹检测不仅用于广告追踪，还可能被用来：

精准识别用户身份，即便切换 IP 或隐身模式也能追踪

个性化广告投放，让你的隐私被过度利用

防止访问某些网站或限制功能，比如一些服务会根据指纹限制访问次数

所以，了解 Canvas 指纹的工作原理，并学会防护，确实很必要。

如何在 Chrome/Edge/Firefox 上防护 Canvas 指纹

1. 使用隐私浏览器或增强隐私插件

Firefox：Firefox 对隐私保护比较友好，可以在 about:config 中开启 privacy.resistFingerprinting，它会主动对 Canvas 指纹进行干扰，降低被唯一识别的风险。

Chrome / Edge：可以安装类似 uBlock Origin、Privacy Badger 的插件，有些插件提供 Canvas 指纹保护功能，会在 Canvas 渲染请求时提示你是否允许。

温馨提示：完全屏蔽 Canvas 指纹可能会导致某些网站功能异常，比如图形验证码或绘图功能。建议按需开启。

2. 修改浏览器 Canvas 行为

部分浏览器插件可以随机化 Canvas 指纹，或者在读取 Canvas 数据时注入“噪声”，从而干扰指纹生成。例如：

CanvasBlocker（Firefox / Chrome）：这是一个专门防护 Canvas 指纹的插件，可以随机化你的 Canvas 输出，阻止网站准确识别你的浏览器。

Trace（Chrome / Edge）：提供多种防护选项，包括 Canvas、WebGL 和字体指纹保护。

通过这些插件，你可以在保证上网体验的前提下，有效降低 Canvas 指纹被利用的风险。

3. 使用隐身或隔离浏览模式

虽然隐身模式不能完全防止 Canvas 指纹，但结合插件使用，可以大幅降低追踪成功率。此外，多账户浏览器或容器插件（Firefox 的 Multi-Account Containers）也可以隔离网站数据，避免跨站点追踪。

4. 检测你的浏览器指纹安全性

防护前，最好先知道自己的浏览器有多“容易被识别”。ToDetect指纹查询：

查看自己浏览器的 Canvas 指纹信息

检测是否存在其他指纹威胁（WebGL、字体、插件等）

评估当前防护措施的效果

操作也很简单，只需访问网站，点击检测即可生成报告。这样你可以直观了解防护是否成功。

总结

Canvas 指纹是现代浏览器指纹检测中一个比较精准的手段，它能在无 Cookie 情况下追踪用户。想要在 Chrome、Edge、Firefox 上防护 Canvas 指纹，主要方法就是：

使用隐私浏览器或增强隐私插件

随机化或干扰 Canvas 输出

使用隔离浏览或容器模式

借助 ToDetect指纹查询工具 评估防护效果

如果你平时比较注重隐私，上述方法结合起来使用，会显著降低浏览器被跟踪的概率。毕竟，保护自己的数字足迹，是每一个现代网民都该掌握的技能。

前言

在如今快速迭代的软件开发环境中，如何提升前端开发效率、降低重复劳动，成为许多团队关注的核心问题。低代码平台正是在这种背景下应运而生，它通过可视化拖拽、逻辑编排等方式，让开发者甚至非技术人员也能快速搭建出功能完整的页面或系统。织信Informat 正是这样一款专注于中后台场景的低代码可视化搭建平台，它不仅支持免费体验，还提供了高度灵活的扩展能力，真正做到了"让搭建更简单，让开发更高效"。

项目介绍

织信Informat 由前平安项目交付（后出来创业）团队打造，目标用户主要是面向企业内部管理系统、运营平台、数据看板等中后台（如ERP/MES/SRM）应用场景的开发者。平台支持从零开始创建项目、页面和组件，并通过图形化界面完成复杂的交互逻辑与接口对接。值得一提的是，织信Informat 不仅可以本地部署使用，还能通过微前端框架轻松嵌入到已有的 Vue 或 React 项目中，极大降低了技术栈迁移的成本。

项目功能

1、项目管理：支持主题色、菜单布局、系统 Logo、面包屑等基础配置，并内置完整的 RBAC（基于角色的访问控制）权限体系。

2、页面搭建：提供可视化拖拽编辑器，支持页面主题设置、组件布局、样式配置、事件流编排及接口调用。

3、权限控制：细化到项目、页面、菜单乃至按钮级别的权限分配，确保不同角色看到的内容和可执行的操作精准可控。

4、自定义组件：当平台内置的 1000+ 组件无法满足需求时，开发者可上传自研组件，平台在线编译后即可在编辑器中使用。

5、接口管理：统一维护 API，支持 GET/POST/PUT/DELETE 等请求方式，可配置全局拦截器、动态参数传递及返回结构处理。

6、事件流引擎：通过图形化逻辑编排，实现组件联动、显隐控制、禁用状态切换、路由跳转、接口调用等复杂业务逻辑。

7、多环境发布：支持 STG（测试）、PRE（预发）、PRD（生产）三套环境，页面需发布后才对外可见。

8、版本回滚：已发布页面支持一键回滚至上一版本，保障上线稳定性。

9、微服务集成：通过微前端方案，可将页面无缝嵌入传统 Vue/React 项目中。

项目特点

开箱即用：提供完整中后台解决方案，无需从零搭建基础架构。

灵活集成：既可作为独立系统使用，也可作为子应用嵌入现有工程。

权限精细：RBAC 模型覆盖项目、页面、操作各层级。

逻辑可视化：事件流机制让复杂交互不再依赖硬编码。

项目技术

前端：

基础UI库选型：Vue

基础UI库选型：Element-UI

开发语⾔标准：使⽤ES5、ES6、ES7语⾔标准

语⾔规范检查：使⽤eslint对代码进⾏检查

⼯程依赖管理：使⽤npm管理⼯程依赖

⼯程打包⽅式：使⽤Webpack4

浏览器兼容控：使⽤babel7，将ES6、ES7语法转换为ES5交付，postcss进⾏浏览器⾃动样式兼容

后端：

开发语⾔选型：JAVA(jdk11)

基础框架选型：SpringBoot2

数据库：Postgres13或以上

缓存：Redis 5

文件存储服务：支持符合 S3 标准的文件对象服务（如：腾讯云 COS、阿里云 OSS、Amazon S3、Minio等）

消息队列服务：RabbitMQ

服务器监控：SpringBoot Admin

项目目录清晰划分为：

项目访问端（用户侧）

可视化编辑器（开发侧）

内置组件物料库

项目体验

在线体验地址：https://demo.informat.cn/workbench/app，也开放了产品文档：https://next.informat.cn/doc/index.html，方便大家快速上手。

项目效果

实际使用 织信Informat 搭建页面的体验相当流畅。无论是简单的表单页还是包含多组件联动的数据看板，都能在几分钟内完成原型搭建。配合其强大的事件流和接口配置能力，很多原本需要前后端联调的功能，现在前端即可独立闭环实现。

项目部署说明

部署逻辑图

浏览器支持

安装所需的服务器和组件

服务器推荐配置

提示：超过1000并发的需求，按照200~1000的配置倍增。上述配置中的数据盘大小可根据实际业务存储的数据量调整。

license和部署密钥

在进行私有化部署之前需要申请部署密钥，部署密钥会绑定服务器的MAC地址，更换服务器后需要重新申请。在系统安装成功后，使用部署密钥作为密码登录织信企业级后台。在企业级后台中使用license可创建团队。

license中会限制团队的名称、创建应用数量、成员数量、到期时间等信息

总结

织信Informat 并没有盲目追求"零代码"，而是聚焦于"低代码 + 高扩展"的平衡点——在大幅减少重复性工作的同时，保留了专业开发者的控制力和灵活性。

对于正在构建或重构中后台系统的团队而言，它既能加速 MVP 验证，也能支撑长期业务演进。随着专业版逐步上线图片云、数字大屏、工作流等高级能力，织信的生态价值将进一步凸显。

当前全球网络空间竞争格局正在加速演变，密码技术作为保障网络与信息安全的核心支柱和关键基础，其自主可控性已被提升至国家战略层面。国内独立研发的商用密码算法体系，正是这种战略思维的具体体现。在此等背景下，基于SM2算法开发的国密SSL证书，正在从满足特定合规需求的单一技术方案，转变为数字化转型安全保障的关键基石，同时支撑自主可控的网络信任体系建设。JoySSL技术总监指出，国密SSL证书的推广与应用不仅是技术选择，更是对国家信息安全、产业保障以及数据主权的积极践行。国密证书的核心价值在于，能够为具备高安全性、强监管要求以及自主控制需求的场景，带来一整套兼容国内密码法规、性能优越且具有自主信任根的端到端的安全通信解决方案。

核心优势 国密证书展现多重战略价值

国密SSL证书采用SM2算法替代国际通行的RSA/ECC、SHA-256和AES算法，形成了多方面战略优势。首先，自主构建的国家密码信任体系，其信任链完全依托国内自主创建的数字证书根信任体系，避免了对国外密码技术和根证书系统的依赖。

自主研发的国密证书拥有更高安全性能的算法优势，特别适用于高并发场景或资源有限的移动终端环境，算法均由国家密码管理局设计并正式认可，安全性可满足当前及未来阶段应对高强度计算攻击的需求。同时，国密SSL证书已深入兼容主流浏览器、与各种软硬件设备，具备生态适配优势。

应用场景 关键领域的不可替代与前景

国密SSL证书多应用于政务及公共服务领域，包括相关部门官方网站、在线政务服务平台等，这些平台需要全面应用国密算法，确保通信加密及身份认证的安全性，实现跨部门数据共享，加强数据传输安全性和管控能力。

网上银行、移动金融以及供应链平台等金融业具体场景，是推广国密算法的核心地带，旨在保障交易数据的安全与合规性。金融行业对通信安全要求极高，国密证书提供了符合监管要求的国产自主解决方案。

特定的商业领域在运营时，往往涉及大量敏感个人信息，通过国密算法的部署，既满足了国家合规要求，同时展现了更高等级的安全保障能力。

解决方案 自主可控与全球兼容双向发展

面对不同群体多元化需求，国密SSL证书不仅需要专业，同时配备还需灵活，方能适应市场需求。JoySSL以双证书部署为解决方案，既满足国密改造要求，又符合用户日常访问需求，确保证书符合主流浏览器与设备的兼容，实现安全合规与用户体验双向平衡。

创新之道 以算法构建自主可控安全体系

国密SSL证书的普及与应用，是国内构建网络安全自主体系的重要举措，不仅是算法技术层面的突破，更确保了在数据安全领域的话语权。随着数字化时代的到来，国密SSL证书将在更多重要领域发挥关键作用。选择国密证书，亦是顺应未来发展的重要抉择。

在过去的一年里，Voice Agent 的开发者们经历了一场集体“祛魅”。一个被反复提及、逐渐成型的行业共识是：“Evals are back”（测评回归）。

这是因为行业遇到了共同的瓶颈：基础模型在通用学术榜单上卷得难解难分，一进到真实的业务电话里，表现往往不如人意。一个能写出精美诗歌的 Agent，可能听不懂带口音的“退款”请求，或者在用户情绪激动时不知道该如何安抚。这就带来一个更现实的问题：在充斥着打断、噪音和情绪波动的真实通话中，我们到底需要什么样的 Voice Agent？

最近，美团、声网 与 Xbench 三方联合构建了一个名为 VoiceAgentEval 的基准测试，主要解决现有测试方法的三个关键问题：数据集多样性不足、用户模拟不真实、评估指标不准确。

测试结果表明，大语言模型在外呼对话场景中已经达到了相当的基础能力，并展现出了各自的适用性。这说明，Voice Agent 的发展已经跨过了“参数为王”的阶段，进入了“场景适配”的新时期。

论文链接：
https://xbench.org/reports/zmbbhdtfc5ui5qx5xjgquusj

VoiceAgentEval 在做什么

在人机对话场景中，用户不仅关注 Agent 是否提供了正确的反馈，如解答疑问、完成任务等；良好的、更像真人间交互体验也是非常重要的评估指标。

因此，区别于传统测评， VoiceAgentEval 不再执着于考察 Agent 到底“会不会说话”，而是同时从“有没有说对”和“说的好不好”两个层面来评估：

1. 任务流程遵循度（Task Flow Compliance，TFC）： AI 客服是否按照业务流程办事，是否真正解决用户的问题
2. 一般交互能力（General Interaction Capability，GIC）： AI 客服的响应是否自然，回复内容是否与谈话主题相关，是否能响应用户的负面情绪等。

换句话说，这套评估不是在挑“谁最聪明”，而是看谁最适合在真实通话场景下干活。

在 VoiceAgentEval 中，这两类能力通过三个紧密衔接的设计进行评估：

基准构建（Benchmark）

从真实外呼业务中抽象出 6 大商业领域（客服、销售、招聘，金融风控、调研以及主动关怀）、 30 个子场景，包括银行投诉、电商退货、面试邀约等在真实世界里出现频率最高的情况。丰富了数据集的多样性与种类，覆盖业务中多样的场景，也就是现实中最容易出现问题的对话。

用户模拟器（User Simulator）

本次测评用 LLM 模拟了 5 个性格、背景、沟通风格都不相同的用户，结合 30 个真实业务的子场景，形成 150 种情况下的虚拟用户对话评估。这些虚拟用户有的态度友好，有的犹豫不决，甚至有的情绪抗拒。通过用户模拟器，输出每一个 Agent 在这 150 种真实场景中的 TFC 和 GIC 得分并加权计算出最终测试结果，能够有效的评估 Agent 在复杂场景下遵循任务流程与交互能力的平衡程度。

评估方法（Evaluation）

VoiceAgentEval 通过文本和语音，对 Agent 进行 TFC 和 GIC 的双维度评估

在 TFC 层面，重点关注：

• 按业务流程推进对话
• 最终把事情“办成”

在 TIC 层面，评测关注的是：

• 在口音、噪音或打断下，是否还能听清关键需求
• 回应是否自然、简洁、不制造额外负担
• 在被打岔、被质疑时，是否还能保持对话连贯

也就是说，这套评测是在模拟一通真实业务电话，看看它能不能把事办完、还能不能让人愿意继续聊。

需要说明的是，VoiceAgentEval 并非在离线环境中对模型进行脚本化测试，而是基于声网在实时语音与对话式 AI 领域长期积累的工程能力，搭建出一套真实可运行的 Agent 架构来完成评测流程。因此，评测中的语音交互、流程切换与被打断后的恢复，均通过一条的真实 Voice Agent 链路完成，而非通过静态对话拼接。这也是 VoiceAgentEval 能够在实验条件下逼近真实业务通话复杂度的基础。

测评启示：没有最好，只有最合适

在这套实时语音交互评测环境中，测试结果并不意味着 Agent 的绝对高低，而是它们在特定外呼任务设计、用户模拟方式以及评分权重设定 下所呈现出的行为差异。

即便如此，这些差异依然为开发者理解模型在高度贴近真实外呼场景中的“行为倾向”提供了一张有价值的参考图谱：

• 均衡的“多面手”—— 在“完成办事流程”和“闲聊”之间取得了极佳的平衡。它们既能按流程推进业务，又能顺滑地接住客户的闲聊。如果你需要一个适应性强的通用型 Agent，它们值得优先考虑。
• 严谨的“执行者”—— 流程合规性得分高但交互能力相对低一些。就像一个处理金融业务、一丝不苟的银行柜员，绝不随意发挥，但也绝不出错。对于合规性要求极高的严肃场景，它是安全的选择。
• 温情的“倾听者”—— 在交互体验上表现优异，极善于安抚沟通，提供情绪价值。如果你的场景是心理咨询或陪伴，它可能比那些“死磕流程”的模型更懂用户的心。

不仅在外呼场景，随着 Voice Agent 越来越多地走向 AIoT、情感陪伴等日常生活场景，对交互的评测，也正在从“是否听清需求、是否能顺畅对话”，延伸到更底层的环境与语境理解能力。

在这一层面上，评测维度将不可避免地扩展到对掌声、敲门声等声学事件的感知，对所处环境的声学场景判断，以及对方言、间接表达和语境变化的识别。这些能力决定的，不只是一次对话能否完成，而是 Voice Agent 是否具备在真实环境中持续交互的基础条件。

共同的目标：从探索走向落地

这套评测体系的发布，其意义不在于分出高下，而在于展示了 Voice Agent 进化的必经之路：场景 + 技术的双重融合。

• 场景上： 评测设计基于美团外呼业务中长期积累的真实场景经验与典型问题抽象而来，使得测试不再停留在理想化设定中，而是带有明显的“泥土味”。
• 技术上： 通过声网的音视频技术积累和架构支持，验证了一套可复用的“生产级”技术栈。

对于整个开发者社区而言，这传达了两个积极的信号：

1. 选型更从容： 我们不必再盲目追求“最强”模型，而是可以根据业务需求（是重逻辑还是重体验）找到最匹配的那一块拼图。
2. 研发更聚焦： 开发者不必重复造轮子，可以将宝贵的精力投入到对业务逻辑的打磨上。

结语：共建行业的“度量衡”

AI 的进化速度太快，单打独斗的时代已经过去。

我们解读这篇论文，是希望所有 Voice Agent 的从业者关注这种“场景化测评”的趋势。VoiceAgentEval 给出了外呼场景的一种答案，更像是一次示范：如何把一个具体业务，拆解成可被复用的评测单元。

当 Evals 从“纸上谈兵”回归到“实战演练”，当底层的实时交互框架逐步成熟，Voice Agent 才有可能真正走出实验室，接受千行百业的复杂检验。这扇门是否能被真正推开，最终取决于行业能否持续围绕具体场景，持续形成可被复用、可被讨论、也可被不断修正的共同度量。

参考链接

xbench 官网：
https://xbench.org/VoiceAgentEval

新闻稿：
https://xbench.org/reports/zmbbhdtfc5ui5qx5xjgquusj

声网对话式 AI 引擎：
https://www.shengwang.cn/ConversationalAI/

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么