作者：互联网效能平台团队-Wu Qinghua
在软件研发过程中，“环境问题”是制约研发效能的关键瓶颈之一。环境不稳定、测试环境混乱、环境抢占严重等问题，显著影响开发与测试效率。本文系统介绍vivo通过“全链路多版本环境管理”模式，实现开发测试环境的快速构建与高效管理，使多版本环境能够像“平行宇宙”一般，实现安全、隔离、高效的并行测试与发布。

本文为2025年 vivo 开发者大会互联网技术专场分享内容之一，在公众号“vivo互联网技术”对话框回复【2025VDC】获取 2025VDC 互联网技术会场议题相关资料。

1分钟看图掌握核心观点👇

图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言

一、背景&问题

1.1 我们遇到的问题

在软件研发过程中，环境问题常常成为关键路径上的阻塞点。2020年vivo某核心业务数据显示，因测试环境问题导致的转测延期占比高达67%，策划验收阶段因环境问题导致的延期超过10次。

这些数据背后，反映的是研发过程中常见的典型场景：

• 场景一：急需联调时，依赖服务异常，导致研发阻塞；
• 场景二：准备测试时，环境被其他版本占用，需求排期被迫延后；
• 场景三：环境配置差异导致线上Bug漏测，引发更多问题。

深入分析该业务场景后，我们发现环境问题主要集中在以下几个方面：环境不稳定、测试环境混乱、环境抢占严重、资源利用率低下。这些问题并非单一项目特有，在微服务架构和快速迭代模式下，已成为多个团队共同面临的挑战。

1.2 问题的挑战

随着vivo互联网业务的快速发展，为满足更快发布需求，我们全面转向微服务架构。这一转变在提升灵活性与敏捷性的同时，也带来了新的管理挑战。

挑战主要来自两个维度：

• 架构层面：服务拆分导致服务数量激增，各服务需独立部署维护，系统调用链路显著延长，任一环节故障都可能导致整体功能不可用。
• 流程层面：业务快速迭代需求推动多版本并行推进，如版本A测试、版本B功能开发、版本C线上热修复等同步进行。

这些变化叠加，使得研发环境管理复杂度大幅提升，环境稳定性下降、资源浪费严重，最终导致整体研发效率受损。

传统环境管理方式已难以满足当前需求，亟需一种创新方法，实现多版本像“平行宇宙”一样安全、隔离、高效地并行测试与发布。

二、解决方案思路

2.1 什么叫全链路多版本环境管理

为解决环境管理难题，我们提出了“全链路多版本环境管理”理念，其核心基于三大关键能力：

1.全链路能力

单一服务版本环境不足以保证整体功能验证。必须确保版本依赖的所有组件——从前端、网关到微服务，再到数据库、缓存和消息队列——整条链路能够一键拉起、快速就绪。以支付业务调试为例，无需手动启动账户、风控、结算等服务，通过一键操作即可分钟级生成完整环境，数据流、配置流与生产环境保持一致。

2.多版本并行

支持同时创建多个“完整环境”，使各版本在独立“沙箱”中运行，彻底解决资源抢占问题。热修复版本可分钟级拉起独立环境，新功能开发同步进行，实现“分钟级响应，零等待协作”。

3.环境自动化管理

通过全生命周期自动化——从环境搭建、弹性伸缩到闲置回收，减少人工干预，降低错误率，提升资源利用效率，实现降本增效。

基于这三项核心能力，线上问题或紧急需求出现时，我们可在几分钟内创建独立环境进行验证，且不影响其他版本进程。

2.2 业务目标示意图

理解全链路多版本环境管理理念后，我们的核心解决思路也从传统的“环境隔离”转向“流量隔离”模式。

传统方式为每个版本构建完整独立的测试环境，如同各自独立的烟囱。此方式隔离性好，但资源浪费严重，环境数量有限，扩展性差。

全链路多版本环境管理方案则采用不同策略：首先维护稳定可靠的公用基线环境。当某版本需开发新功能时，无需从头搭建整套环境，仅需为实际发生变更的服务创建独立的“特性环境”。

关键问题在于如何实现流量的精准路由。答案在于流量统一网关平台，该系统在流量入口识别每个请求的环境标签，根据标签将请求路由至对应版本的服务实例。

未改动服务继续共享稳定基线环境，发生变更的服务则拥有独立环境——通过流量精准调度，既保证隔离性，又显著节约资源与成本。

这一模式类似于单栋大楼内通过不同颜色手环区分访问区域，整栋楼共享基础设施，但各区域活动互不干扰。流量统一网关平台充当“智能前台”，负责识别“手环”、调度流量，使多版本并行开发井然有序。

“逻辑隔离”相较于“物理隔离”展现出显著优势：更弹性、更经济、更高效。

2.3 全链路多版本业务架构图

基于上述思路，我们构建了完整的技术架构，清晰展示系统核心组件及协同工作机制。

全链路多版本环境的核心能力可归纳为四个关键部分：环境编排、流量隔离、容器部署与分布式链路系统。

环境编排：负责组织软件从开发到部署各环节，确保每次代码变更快速部署至指定环境。在多版本环境中，编排系统自动识别不同版本，触发对应构建部署流程，保证各版本独立高效就绪。

流量隔离：实现多版本并行的关键。通过灵活路由策略，精确控制各版本流量走向。无论是HTTP请求、Dubbo调用还是MQ消息，均能在各自服务实例间有序流转、互不干扰，如同智能交通系统确保不同“车流”各行其道。

容器部署：为环境提供轻量、标准化封装方式，各服务及其依赖打包为独立镜像。借助容器技术，实现应用秒级启动与弹性伸缩。多版本场景下，各版本可快速拉起自身实例组，极大提升资源利用率与发布效率。

分布式链路系统：架构的“可观测性”基础，实时追踪记录请求在微服务间的完整流动路径并传递环境标签。当请求进入系统，经多服务处理时，该系统完整记录其“足迹”——包括经过服务、携带标签、是否异常，为问题排查与性能优化提供关键支撑。

接下来，我们将深入解析全链路多版本环境背后的三大关键技术实现。

三、关键技术实现

从实现视角聚焦，核心技术主要包括：

• 环境编排 - 负责指挥与创造
• 资源弹性 - 负责支撑与供给
• 流量隔离 - 负责识别与路由

三大技术形成有机整体，紧密协作，缺一不可。

3.1 环境编排

实现多版本并行的第一步是高效、标准化地“创建环境”。

这主要由CI/CD平台支撑，它不仅是自动化工具，更是强大的可视化环境编排器。开发人员在界面定义待部署服务，系统自动识别服务间依赖关系，判断哪些可并行部署、哪些需串行执行，最终实现“一键完成”环境编排。

优势显而易见：无论是全新版本环境搭建，还是单一服务更新，均可通过单次点击，在分钟级别快速完成，使“秒级拉起独立完整环境”成为研发流程常态。

具体而言，CI/CD平台在全链路多版本中提供两方面关键支撑：

• 全链路能力支持：实现代码提交到自动化验证的端到端集成，确保各环境配置一致，大幅减少环境差异问题。同时精细管理微服务间依赖，支持串并行混合执行，使复杂部署流程井然有序。
• 多版本并行支持：平台根据代码分支自动触发独立构建部署流程，为各版本创建隔离环境、添加环境标签，实现环境高效复用与隔离。底层对接强大容器化平台，为环境快速启动提供技术保障。

CI/CD平台作为多版本环境体系的“指挥中心”，高效调度四大核心组件——为容器部署提供调度依据，为流量隔离准备环境标签，使分布式链路系统充分发挥跟踪与观测能力。

3.2 弹性资源

指令发出后，需要强健的“执行体”高效落实。vivo容器化平台正是这一强大、可靠的实体。

弹性资源能力由容器化平台核心支撑。全链路多版本环境中，我们能够轻松、快速创建大量隔离环境，背后依赖的正是容器技术。

容器化工作原理简述：开发者将应用及其所有依赖打包为标准容器镜像。该镜像可在任何支持容器的环境中运行，确保开发、测试、预发和生产环境高度一致，真正实现“一次构建，随处运行”，从根源解决环境差异问题。

资源利用率方面，容器技术优势明显。传统虚拟机部署中，单节点通常仅运行单一应用，资源利用率低。容器化部署允许多个容器共享节点操作系统内核，轻量高效。对多版本环境管理而言，这意味着可低成本、高效率创建大量隔离环境。以往需10台服务器支撑的多版本测试，现仅需3-4台，成本显著降低。

此外，容器平台具备自动扩缩容能力，这在多版本场景中尤为重要：特性环境压力测试时，系统自动扩容保障稳定性；测试结束环境闲置时，资源自动缩容回收，真正实现按需使用、高效节能。

容器化带来三大核心价值：环境标准化、资源高效化与伸缩自动化。这些能力组合使我们能够轻松维护多版本并行研发，加速产品迭代，提高系统稳定性，同时显著降低成本。

对业务团队而言，这意味着更快功能交付、更稳定系统运行与更高资源利用率。这是全链路多版本环境支撑大量环境并行而无需担忧资源成本激增的根本原因。

3.3 流量隔离&流量染色

环境与资源就绪后，确保流量“对号入座”是实现隔离性的关键。这引出两个核心概念：“流量隔离”与“流量染色”。

3.3.1 流量隔离和流量染色的定义

流量隔离指由统一流量网关平台维护智能路由表，记录“环境标签”与“服务实例地址”间映射关系。

如图示：Feature1环境流量仅路由至IP1、IP2实例；Feature2流量指向IP3、IP4实例，实现真正互不干扰。

流量染色如同为每批流量分配“颜色标识”。请求进入网关前，为其添加明确环境标识，声明“属于Feature1”或“属于Feature2”。网关据此正确识别与路由。

理解流量隔离与染色后，需将其应用于真实网络环境。微服务架构下，流量基本分为两类：南北流量与东西流量。

图示说明：

• 南北流量：外部客户端与服务器间流量，即“进出数据中心流量”；
• 东西流量：数据中心内部服务器间流量，即微服务间调用。

在vivo实践中：

• HTTP流量由vivo统一访问平台处理；
• Dubbo流量由Dubbo服务治理平台负责；
• MQ消息通过MQ消息网关平台路由。

3.3.2 流量隔离实现

1.HTTP流量隔离

过程如图绿色路径所示。始于环境编排阶段：通过流水线部署服务时，为各实例注入唯一环境标签。同时，vivo统一访问平台建立“环境标签”与后端服务实例组（Upstream）的绑定关系，触发创建相应CRD并实施监听。

此后，无论是部署、实例扩容、缩容还是重启，只要实例IP和端口变化，变更都会被实时监听并动态更新至网关路由规则，形成高效自动化闭环，确保每个带环境标签的HTTP请求被网关精准路由至正确特性环境实例。

2.DUBBO协议隔离

借助Dubbo官方原生标签路由能力实现。原理直观：将服务实例动态划分至不同逻辑分组，约束带特定标签流量仅能访问指定分组。vivo实践中，打标动作发生于部署环节。容器启动时，Init Container自动调用Dubbo服务治理平台，通过动态规则配置，无感地为当前服务实例添加环境标签。整个过程无需重启服务，配置实时生效，完美支持全链路多版本对灵活性与实时性要求。

3.消息队列（MQ）隔离

与前两者不同，MQ组件本身缺乏完善隔离机制。我们基于MQ消息网关平台mq-proxy组件实现。

实现方式巧妙：生产者与消费者启动并与mq-proxy建立连接时，在连接属性中携带自身环境标签。消息生产时，mq-proxy拦截消息，将环境标签写入消息user-property中。消费时，mq-proxy根据消息中标签与消费者自身环境标签进行匹配过滤，确保消息不会被跨环境消费。整个过程对业务代码完全透明，实现无侵入隔离。

3.3.3 流量染色实现

南北流量染色：客户端至服务器端流量染色实现方式如下。

• HTTP请求：在请求头中添加环境信息，推荐使用ModHeader等浏览器插件，便捷地在请求头中添加env_tag=feature1等信息。
• Dubbo调用：将环境标签置于Attachment中，提供简洁API，开发者只需在发起调用前，通过RpcContext.setAttachment("dubbo.tag","feature1")代码即可设置环境标签，对业务代码侵入性极低。
• MQ流量染色：对业务方完全透明，由前述mq-proxy组件自动完成，业务代码无感知。

具体实现：生产者与消费者启动时，与mq-proxy建立连接，使用连接属性v-env-tag存放环境标签，即图示中间启动部分。消息生产消费环节中，生产者生产消息时，mq-proxy拦截消息，将环境标签写入消息user-property中。

消息消费端，mq-proxy拉取消息时，获取消息中环境标签信息并进行过滤，推送至对应环境服务实例，确保仅消费属于当前环境的消息。通过此机制，保证消息在整个生命周期携带环境标识，实现MQ流量染色。

3.3.4 标签的传递

最复杂部分在于环境标签在整条调用链中自动传递。通过vivo分布式链路系统实现，核心技术为javaagent，通过调用链Agent透明完成此项“接力”工作。

示例如下：来自客户端的HTTP请求携带env\_tag=feature1，网关将其路由至feature1环境的用户中心。用户中心需调用积分中心时，调用链Agent拦截此次Dubbo调用，从HTTP请求头中获取env\_tag，并注入Dubbo调用的Attachment中，积分中心因此收到该标签。积分中心处理完毕，需发送MQ消息通知活动中心。此时Agent再次拦截，从Dubbo Attachment中获取标签，写入MQ消息属性。最终，仅标注feature1的活动中心实例消费此消息。整条链路中，如有环节未匹配环境标签，流量则回退至基线环境。

如此，环境标签在HTTP→Dubbo→MQ完整链路中自动传递，确保全链路环境隔离，真正实现“一次染色，全程生效”。

回顾关键技术部分：环境编排是指挥中心，负责调度与创造；弹性资源是执行实体，负责支撑与运行；流量隔离与染色是传导系统，负责精准识别与路由。三者有机结合，构成全链路多版本环境管理的稳固架构，缺一不可。

四、业务实践与效果

全链路多版本环境落地实践后，成效显著：

• 环境搭建效率提升：从过去多团队沟通、手动配置、平均耗时2人天，转变为开发者一键触发、分钟级自动完成。
• 版本并发能力增强：以往受资源限制，仅支持2-3个版本串行测试；现可轻松支持9个以上特性环境并行开发测试。

这不仅带来效率提升，更实现研发节奏全面加速与业务响应能力质的飞跃。

五、未来规划

展望未来，我们对全链路多版本环境管理有清晰规划。这不仅是技术升级，更是研发管理理念的演进。

未来规划采用双轨并行策略，从研发效能环境标准化与资源成本高效化两个维度同步推进。两方向相互促进、协同支撑。

5.1 研发效能环境标准化

在已实现的环境编排、资源弹性与流量隔离基础上，重点推进三项关键措施：

1. 构建环境即服务平台

平台提供标准化环境模板，包括不同规模测试环境及各类专用环境（如性能测试、安全测试等）。通过模板化方式，确保环境一致性与标准化，同时大幅提升环境创建效率。

平台集成环境全生命周期管理功能，从环境申请、审批、创建、使用、监控到回收，形成完整闭环管理。这不仅提升管理效率，更建立完善的环境治理体系。

2. 建立全链路环境监控与可观测体系

监控体系涵盖多层：基础设施层监控CPU、内存、存储等资源使用；中间件层监控数据库、消息队列、缓存等组件性能；应用层监控服务响应时间、错误率、吞吐量等关键指标。

通过分层监控，快速识别环境中异常情况，及时发觉性能瓶颈，为环境优化提供数据支撑。监控数据同时为资源调度与成本优化提供重要决策依据。

3. 建立环境治理与合规自动化机制

治理机制包括环境命名规范、资源配置标准、安全配置要求、数据保护规则等多方面。通过自动化合规检查工具，实时监控环境合规状态，自动发现与修复不合规配置。

机制还包括环境定期审计功能，自动生成合规报告，为管理决策提供支撑。通过此方式，既确保环境安全合规，又减少人工审计工作量。

5.2 资源成本高效化

资源成本高效化方面，推进以下两项关键措施：

1. 非活跃环境自动回收

针对非活跃环境，建立智能自动回收机制。系统自动识别长期未使用环境，在确保数据安全前提下，自动进行资源回收。

机制包含多层管理：

• 测试环境非工作时间自动休眠；
• 开发环境连续7天未使用发出提醒；
• 连续14天未使用自动回收。

通过分层管理，既保证开发效率，又有效控制成本。

2. 成本可视化与归因分析

成本分析从多维度展开：

• 按项目维度分析各项目资源使用成本；
• 按团队维度分析各团队成本构成；
• 按环境类型维度分析不同环境成本效益；
• 按时间维度分析成本变化趋势等。

通过精确成本统计与分析，为成本优化提供数据支撑。

通过双轨并行策略，我们实现研发效能提升与资源利用最大化的良性循环。

全链路多版本环境管理的未来规划不仅是技术升级，更是研发管理理念的转变。通过双轨并行策略，我们将建立更高效、经济、可靠的研发环境体系，同时打造更先进的研发环境管理体系。

最新消息，Apache DolphinScheduler 3.4.0 已正式发布！

本次版本带来了多租户调度隔离、工作流并行性能优化、任务重试与告警机制增强，以及资源管理和日志处理改进。无论是复杂企业业务场景，还是高并发任务调度，3.4.0 都让系统更高效、更可靠、更易用。立即升级，体验全新调度能力！

升级与下载

下载页面（可选择镜像下载）：
https://dolphinscheduler.apache.org/zh-cn/download/3.4.0

GitHub Release 页面：
https://github.com/apache/dolphinscheduler/releases/tag/3.4.0
升级时建议参考官方文档中的集群升级指南，确保兼容性和配置一致性。

核心功能增强与重要更新

通用 OIDC 认证支持

3.4.0 引入了对 OpenID Connect（OIDC）的通用支持，旨在简化与企业身份认证系统的集成。通过 OIDC，用户可以使用统一的身份提供商（如 Keycloak、Okta 等）进行 SSO 登录，无需额外实现复杂自定义逻辑。这提升了安全性和用户体验，尤其是在多系统联邦登录与统一认证场景中，能够使 DolphinScheduler 更自然地融入企业级认证体系，减少重复配置和验证成本，从而提高登录配置的扩展性和一致性。

（参考图）

gRPC 任务插件支持

本版本新增了 gRPC 任务插件能力，使调度器能够通过原生 gRPC 协议直接与远程服务交互。用户可以将后端微服务暴露的 gRPC 接口作为任务执行目标，无需中间脚本封装。这种方式特别适合微服务生态或跨语言执行场景，通过明确参数契约和高性能通信协议提升任务整合效率，从而减少资源调度延迟、提高任务可靠性。

支持工作流串行策略

实现了 工作流串行执行策略（Workflow Serial Strategy） 的核心逻辑重构，通过引入一个全新的串行命令队列机制（t_ds_serial_command 表及相关 DAO/Mapper），配合一套串行执行协调器（WorkflowSerialCoordinator）及策略处理器，使 DolphinScheduler 能更智能地管理串行类型的工作流（如 SERIAL_WAIT、SERIAL_PRIORITY、SERIAL_DISCARD）。

该设计改进了工作流触发流程的执行类型判断、状态管理、命令队列处理等关键路径，使串行调度逻辑更清晰、更可靠，有助于提升串行工作流场景下的调度稳定性与可控性。同时，3.4.0 重构了触发器与状态机相关代码，增强该能力的可维护性和扩展性。

移除 PyTorch 任务类型

3.4.0 对任务类型体系进行了精简，正式移除了内置的 PyTorch 任务类型。该调整主要基于实际使用情况和长期维护成本的考量，因为原有 PyTorch 任务实现使用率较低，且与调度器核心任务模型耦合度较高，增加了版本演进和兼容性维护的复杂度。通过移除该任务类型，DolphinScheduler 能保持核心架构的简洁与稳定。

我们鼓励用户通过更通用的 Shell、Python 或插件化方式运行 PyTorch 作业，从而提升系统整体的可维护性和扩展性。

稳定性与重要修复

Kubernetes Worker 部署增强

在 Kubernetes 原生部署场景下，3.4.0 使 Worker StatefulSet 的 Helm Chart 支持注入 Secrets 和 InitContainers。通过 Secrets 注入，可以安全传递证书或凭据；InitContainers 允许在主容器启动前完成必要的初始化逻辑，如准备文件系统或校验环境依赖。

这些增强有助于在容器化环境下实现更安全、更一致的部署策略和生命周期管理。

SQL 任务取消能力

针对 SQL 任务类型，本次版本提供了对任务执行取消的原生支持。当执行的 SQL 语句由于逻辑错误或长期运行导致资源占用时，用户可以通过调度器下发取消操作，使任务尽快中止，而不是简单失败或等待超时。这一能力改善了任务控制能力，避免长时间运行对集群资源的无效占用，有助于提升整体资源利用率和执行调度体验。

条件任务节点在前置失败情况下执行逻辑修复

在某些复杂工作流中，当条件任务节点的前置任务失败时，条件节点未按预期执行。3.4.0 修复了这一调度核心逻辑，确保条件节点能够正确响应前置失败状态。这样，工作流分支逻辑能够按照既定 DAG 定义可靠运行，从而避免因逻辑错误导致的流程中断或不一致执行。

ZooKeeper 节点清理问题修复

在使用 ZooKeeper 作为协调组件的高可用部署中，部分用户反馈 Master Server 在启动失败后未正确清理已注册的 failover 节点路径，可能导致后续状态异常。该版本修复了这个问题，使 Master 在异常启动路径中能够正确清理关联注册节点，保持注册中心状态一致，确保高可用场景下集群状态的健康和可靠性。

Worker Group 分配逻辑错误修复

此前版本中，项目与 Worker Group 关联/移除操作可能在 API 层出现逻辑不一致，导致调度器未能正确识别项目与 Worker Group 的关系。本次版本修正了相关逻辑，使 API 行为与用户预期一致，从而改善 Worker 管控、资源隔离和调度分配体验。

此外，3.4.0 版本还进行了很多功能优化和问题修复，包括文档与配置规范完善（时区、安全、负载均衡）、核心调度与注册中心稳定性增强（TraceId、Failover 清理、可重入锁）、性能与资源管理优化（任务组索引）、前端与插件体验改进（日志查询、DataX 校验、文件展示）、依赖与安全更新（PostgreSQL JDBC、Spring Boot CVE 修复）等，篇幅所限不再一一展开，详情可查询完整更新列表：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0

Bug 修复亮点

标记任务为 Inactive 状态逻辑修复

某些生命周期事件中，当任务状态需要被标记为 Inactive 时，状态变更可能未正确触发，导致 UI 和执行引擎状态不一致。此版本修复了这一逻辑，使状态标记与生命周期事件更加一致。

Workflow Lineage 删除逻辑优化

在工作流血缘关系删除操作中，系统可能未能彻底清理相关引用，导致历史血缘链路残留。3.4.0 改进了删除逻辑，使 DolphinScheduler 在删除血缘链时能够更精确地清理对应关系，避免分析后续依赖时出现错误链路。

其他 Bug 修复包括前置任务失败导致条件节点不执行问题修复、项目级 Worker Group 绑定与移除逻辑修正、子工作流触发参数丢失问题修复等，详情请查询完整 Release Note：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0

文档更新

1. 发布并完善 Apache DolphinScheduler 3.3.2 版本发布说明文档。
2. 修复文档 CI 构建错误，提升文档发布流程的稳定性。
3. 补充 Prometheus 指标接口的认证机制及其在 Kubernetes 环境下的使用说明。
4. 同步更新 JdbcRegistry 引入事务机制后的相关文档描述，保证文档与实际行为一致。

致谢

本次版本发布离不开社区各位贡献者的热情参与与支持。特别感谢 @ Gallardot 作为 3.4.0 的 Release Manager，从版控、构建、候选版验证到最终投票组织，确保发布流程高质量推进。

同时，感谢以下本次版本的所有贡献者（GitHub ID，排名不分先后）：

Gallardot、njnu‑seafish、det101、Mrhs121、EinsteinInIct、sanfeng‑lhh、ruanwenjun、tusaryan、qiong‑zhou、SbloodyS、kvermeulen、npofsi、CauliflowerEater、ChaoquanTao、dill21yu、sdhzwc、zhan7236、KwongHing、jmmc‑tools、liunaijie

感谢所有通过提交 PR、Issue、文档贡献、社区讨论、测试验证等方式参与 Apache DolphinScheduler 项目的人。正是你们的努力推进了 DolphinScheduler 的持续演进与社区繁荣，欢迎更多人加入我们的队伍！

💡 鸿蒙生态为开发者提供海量的HarmonyOS模板/组件，助力开发效率原地起飞 💡
★ 更多内容，一键直达生态市场组件&模板市场 , 快速应用DevEco Studio插件市场集成组件&模板 ★
★ 一键直达 HarmonyOS 行业解决方案 ★

模板 | 求职招聘应用模板（点击下载）

本模板为招聘类应用提供了常用功能的开发样例，模板主要分职位、消息、个人中心三大模块。本模板已集成华为账号、即时通讯、推送、分享等服务，支持深色模式、适老化、无障碍等特性，提供完整的招聘应用解决方案，只需做少量配置和定制即可快速实现招聘应用的核心功能。

模板 | 购物（回收）应用模板（点击下载）

本模板为回收类应用提供了常用功能的开发样例，模板主要分首页和我的两大模块。本模板已集成回收服务、华为账号、订单流程、地址管理、银行卡等服务，支持创建订单、编辑地址、我的设置等特性，提供完整的回收服务应用解决方案，只需做少量配置和定制即可快速实现回收服务应用的核心功能。

模板 | 旅游攻略应用模板（点击下载）

本模板为旅游类应用提供了常用功能的开发样例，模板主要分首页、行程、消息和个人中心四大模块。本模板已集成华为账号、微信登录、消息管理、应用更新检查、意见反馈、实名认证等服务，采用模块化架构设计，支持多设备适配，只需做少量配置和定制即可快速实现旅游攻略应用的核心功能。

组件 | 可分可合组件

更多模板&组件上新，敬请关注！
欢迎下载使用模板&组件“点击下载”，若您有体验和开发问题，或者相关心愿单
欢迎在评论区留言，小编会快马加鞭为您解答~
同时诚邀您添加下方二维码加入“组件模板开发者社群”，精彩上新&活动不错过！

【相关推荐】

👉 HarmonyOS官方模板优秀案例系列持续更新， 点击查看 往期案例汇总贴，欢迎收藏，方便查找！
👉【组件征集】HarmonyOS组件开发征集活动，点击参加
👉【HarmonyOS行业解决方案】为各行业鸿蒙应用提供全流程技术方案。点击查看

———以点量云流商用实时云渲染平台为例

1. 技术背景：从“渲染流畅”到“业务适配”的能力升级
   随着实时云渲染技术的日趋成熟，其应用场景已从单纯的三维模型轻量化展示，深度渗透到数字孪生、工业仿真、远程三维协作、在线教学培训等多元化业务领域。当前，行业对云渲染平台的核心需求已发生本质转变：不再局限于“依赖云端算力实时渲染复杂三维模型，实现终端轻量化交互操作”，更聚焦于“能否承载真实业务场景中的全流程沟通，实现虚拟场景与现实信息的无缝联动”。
   点量云流在对接大量政企、工业、教育类商用项目落地过程中发现，仅依靠三维模型的实时渲染与基础交互，远不足以支撑复杂的远程协作场景。例如，工业远程运维中，工程师需要同步查看设备三维仿真模型与现场摄像头拍摄的设备实际运行状态；三维项目协作会议中，参会者需结合本地文档、操作演示视频，对虚拟场景进行精准讨论；在线技能培训中，讲师需通过摄像头实时讲解，同步展示课件、实操视频与三维仿真操作流程。
   基于此，点量云流在现有实时云渲染架构的基础上，针对性引入摄像头与本地媒体数据接入能力，通过技术优化实现现实世界数据流与虚拟三维场景的无缝融合，有效补齐了传统云渲染平台在“全维度信息表达”“业务场景适配”层面的短板，进一步拓宽了实时云渲染技术的商用落地边界。
   
2. 技术架构：四层协同，实现数据高效接入与融合呈现
   从技术实现逻辑来看，点量云流的摄像头与本地媒体数据接入能力，可拆解为“本地采集层—流媒体传输层—云端渲染融合层—Web三维呈现层”四个核心层级，各层级协同联动，既保证数据传输的低延迟、高稳定，又实现媒体内容与三维场景的自然融合，适配商用场景的严苛需求。
   2.1 本地数据采集与编码：多源适配，筑牢数据基础
   作为数据接入的源头，本地采集层的核心目标是实现多类型本地媒体数据的全面、高效采集，并通过标准化编码处理，为后续流媒体传输奠定基础。点量云流突破传统平台的采集局限，支持多种本地数据源的全覆盖采集，具体包括：
   摄像头数据：支持电脑内置摄像头、高清工业摄像头等各类设备，可根据场景需求灵活调整采集分辨率、帧率，适配从日常沟通到工业监测的不同清晰度要求；
   本地屏幕数据：支持全屏采集、指定区域采集、单个应用窗口采集，可精准捕捉桌面操作、软件演示等内容，适配项目演示、技能培训等场景；
   各类课件与文件内容：兼容Flash课件、exe可执行课件、PPT、Word、PDF等多种格式文档，支持直接采集展示，无需额外格式转换，提升使用便捷性；
   本地媒体文件：支持MP4等主流格式的本地视频文件，可实现文件的实时采集与流式播放，适配预录视频演示、案例讲解等场景。
   针对采集到的多类型数据，平台会进行实时标准化编码处理，采用H.264/H.265高效编码算法，在保证画面清晰度的前提下，最大限度压缩数据体积，降低后续网络传输压力，同时支持编码参数动态调整，适配不同网络环境下的采集传输需求。
   2.2 流媒体化与协议支持：低延迟传输，适配多场景分发
   流媒体传输层是连接本地采集与云端融合的核心枢纽，其核心作用是将本地编码后的媒体数据，统一转化为标准流媒体格式，并通过适配商用场景的传输协议，实现数据的低延迟、高稳定推送，同时支持多用户并发访问与各类外部视频源对接。
   点量云流采用“统一流媒体化”处理逻辑，将采集编码后的摄像头画面、屏幕内容、课件、视频文件等各类数据，均转化为标准化流媒体流，确保后续云端融合与终端播放的兼容性。在传输协议方面，平台聚焦商用场景的核心需求，重点支持两大主流协议，实现多场景适配：
   RTSP协议：主打低延迟、强控制特性，传输延迟可控制在毫秒级，适合对实时性要求极高的场景，如工业设备实时监测、远程手术指导、实时互动演示等，可实现媒体数据的实时推送与精准控制；
   RTMP协议：生态成熟、兼容性强，支持多用户并发分发，可适配大规模用户同时访问的场景，如在线公开课、大型项目协作会议、多终端同步演示等，确保不同用户的访问体验一致。
   值得注意的是，点量云流的媒体接入能力并非局限于本地摄像头，还可实现与监控系统、网络摄像头等各类标准视频源的无缝对接，通过协议兼容，将外部视频数据同步接入三维场景，进一步拓展了业务适配范围，适配工业数字孪生、智慧监控等高端场景需求。
   2.3 云端渲染融合层：无缝联动，实现虚实融合
   云端渲染融合层是整个技术架构的核心，承担着“三维场景渲染”与“本地媒体数据融合”的双重职责，也是点量云流区别于传统云渲染平台的关键所在。平台通过自研的融合渲染算法，将流媒体传输层推送的本地媒体数据（摄像头画面、屏幕内容等），与云端渲染的三维场景进行实时无缝融合，实现以下核心效果：
   媒体内容可灵活嵌入三维场景：支持将摄像头画面、本地视频、文档等内容，以悬浮窗口、内嵌模块等形式，嵌入三维场景的任意位置，不遮挡核心三维模型，实现自然呈现；
   虚实数据实时联动：当三维场景进行旋转、缩放、漫游等操作时，嵌入的本地媒体内容可同步适配，保持画面同步性，确保用户在查看三维场景的同时，能实时获取本地媒体信息；
   多源媒体内容协同展示：支持同时接入多路本地媒体数据（如摄像头+本地文档+屏幕演示）。
   2.4 Web端播放与访问：无插件适配，降低使用门槛
   Web三维呈现层作为面向用户的最终展示载体，核心目标是实现“便捷访问、跨端兼容”，降低用户使用门槛，适配企业多样化的访问场景。点量云流摒弃了传统平台需要安装专用客户端、插件才能播放媒体内容的模式，通过技术优化，实现媒体流与三维场景的Web端无插件直接播放。
   该层的核心优势的体现在三个方面：
   一是无需安装任何插件、客户端，用户通过Chrome、Edge等主流浏览器，即可直接访问平台，查看融合了本地媒体数据的三维场景，大幅降低企业用户的部署与使用成本；
   二是全面支持跨平台访问，兼容Windows、Mac等各类桌面操作系统，同时适配平板、手机等移动终端，用户可随时随地通过终端设备接入，满足远程协作、移动办公的需求；
   三是灵活适配网络环境，无论是企业内网的封闭场景，还是公网的开放场景，均能实现稳定播放，通过网络自适应算法，动态调整播放参数，避免因网络波动导致的卡顿、黑屏，保障商用场景的流畅体验。
3. 多人同步与分组控制：适配协作场景，提升业务效率
   在商用场景中，实时云渲染平台的核心应用之一是多人远程协作，而摄像头与本地媒体数据的接入，本质上是为了提升协作的高效性与精准性。为此，点量云流针对性打造了完善的多人同步与分组控制机制，将媒体数据接入能力与协作场景深度绑定，解决了多用户协作中“内容不同步、权限不清晰、场景切换繁琐”等痛点。其核心功能包括：
   多用户实时同步订阅：同一路本地媒体数据（如主讲人的摄像头画面、演示文档），可支持多个用户同时订阅查看，所有用户看到的内容与主讲人实时同步，无延迟、无偏差，确保协作沟通的一致性，适配多人项目会议、在线培训等场景；
   基于用户分组的内容隔离：支持根据业务需求，将用户划分为不同分组（如项目A组、项目B组、教学分组等），不同分组可接入不同的本地媒体数据，实现内容隔离，避免不同业务场景的内容干扰，同时保障数据安全，适配多项目并行、多班级教学等复杂场景；
   动态切换：支持本地媒体内容的动态切换（如从摄像头画面切换为本地文档、从屏幕演示切换为视频文件），实现协作流程的顺畅衔接，提升沟通效率。
   这套同步与控制机制，为各类复杂协作场景提供了坚实的技术支撑，无论是企业的多项目分组协作、教育机构的分班在线教学，还是工业领域的多团队远程运维沟通，都能通过该机制实现高效协作，进一步发挥实时云渲染与本地媒体接入融合的价值。
4. 技术价值总结：从“渲染引擎”到“综合型三维协作基础设施”的跨越
   实时云渲染平台接入摄像头与本地媒体数据，并非简单的功能叠加，而是对云渲染技术商用价值的深度挖掘与能力升级，从技术层面来看，这一能力的落地，具有三大核心价值，推动云渲染平台实现从“单一渲染工具”到“综合型三维协作基础设施”的跨越式发展。
   第一，搭建现实世界与三维空间的实时数据通道。传统云渲染平台仅能呈现虚拟三维场景，与现实世界存在明显的信息割裂；而摄像头与本地媒体数据的接入，打通了虚拟场景与现实世界的数据流壁垒，实现了现实信息与虚拟模型的实时联动，让三维场景不再是“孤立的虚拟载体”，而是能够承载现实业务信息的“综合展示窗口”，提升了平台的业务适配能力。
   第二，强化系统的整合与扩展能力。点量云流的媒体接入能力，支持多类型本地数据源、多标准传输协议、多终端访问场景的兼容适配，不仅可接入普通摄像头与本地文件，还能对接工业相机、监控系统等专业设备，实现与企业现有业务系统的无缝整合，无需对现有设备、系统进行大规模改造，降低企业数字化升级成本；同时，开放的接口设计，也为后续接入更多类型的媒体数据源、拓展更多协作功能提供了可能，具备极强的扩展性。
   第三，奠定高阶商用场景落地的技术基础。数字孪生、远程运维、三维协同设计、在线技能培训等高阶应用场景，均需要虚拟场景与现实信息的深度融合，而摄像头与本地媒体数据接入能力，正是支撑这些场景落地的核心技术支撑。例如，工业数字孪生中，通过接入现场摄像头与设备监控视频，可实现虚拟孪生模型与设备实际运行状态的实时对照，助力远程运维与故障排查；三维协同设计中，通过接入本地设计文档、操作演示视频，可实现多设计师的精准沟通，提升设计效率。
   综上，点量云流通过在实时云渲染平台中融入摄像头与本地媒体数据接入能力，不仅补齐了传统平台的能力短板，更推动云渲染技术从“专注渲染”向“赋能业务”转型，使其成为能够支撑多元化商用场景、承载全流程协作沟通的综合型三维协作基础设施，为各行业的数字化转型提供更加强劲的技术支撑。
   

目录

• DolphinScheduler 3.1.9 开发环境【IDEA】搭建访问

  • 前提

    • 1、软件要求
    • 2、克隆代码库
    • 3、编译源码

  • DolphinScheduler 普通开发模式

    • 1、编译问题：

    • 2、启动zookeeper

      • 官方内容
      • 存储配置
      • 启动脚本
    • 3、workspace.xml 修改

    • 4、数据库

      • 4-1：数据初始化
      • 4-2：依赖相关修改

    • 5、application.yaml 修改数据库配置

      • 5-1：dolphinscheduler-master
      • 5-2：dolphinscheduler-worker
      • 5-3：dolphinscheduler-api

    • 6、logback-spring.xml 修改日志级别

      • 6-1：dolphinscheduler-master
      • 6-2：dolphinscheduler-worker
      • 6-3：dolphinscheduler-api

    • 7、启动后端三个服务

      • 7-1：MasterServer

        • 配置 VM Options

      • 7-2：WorkerServer

        • 配置 VM Options

      • 7-3：ApiApplicationServer

        • 配置 VM Options

    • 8、启动前端服务

      • 命令：

    • 9、浏览器访问

      • 账号密码：
      • 成功访问：

  • 相关问题

    • 1、存储未启用、租户\\用户 指定

      • 解决方法：

        • 1、minio 创建 dolphinscheduler 桶
        • 2、commom.properties 修改

        • 3、dolphinscheduler 可视化页面添加租户

          • 用户添加租户

  • 演示

    • 创建文件夹、上传文件成功

这里按照官方提供的文档进行操作：

前提

官方提供的开发手册位置

1、软件要求

在搭建 DolphinScheduler 开发环境之前请确保你已经安装以下软件:

• Git
• JDK: v1.8.x (当前暂不支持 jdk 11)
• Maven: v3.5+
• Node: v16.13+ (dolphinScheduler 版本低于 3.0, 请安装 node v12.20+)
• Pnpm: v6.x

2、克隆代码库

通过你 git 管理工具下载 git 代码，下面以 git-core 为例

mkdir dolphinscheduler
cd dolphinscheduler
git clone git@github.com:apache/dolphinscheduler.git

3、编译源码

支持的系统:
* MacOS
* Linux
【这个我没有运行试试】
运行 `mvn clean install -Prelease -Dmaven.test.skip=true`

DolphinScheduler 普通开发模式

上面是官方提供的，我觉得有用就复制下来，

这里开始我就按照自己的操作顺序记录

1、编译问题：

1、git相关
1-1：开启 Windows Git 长路径支持，
管理员 PowerShell 执行，解决 DolphinScheduler 路径太深导致 git add 失败
git config --system core.longpaths true

1-2：先初始化git仓库，只在本地，不涉及账号、不推远程，Spotless 需要 HEAD
git init
git add .
git commit -m "initial commit"

2、Maven 编译 / 格式化（IDEA 里的 Terminal）
2-1：依赖 Git HEAD，自动修复格式问题
mvn spotless:apply
2-2：编译整个项目（跳过测试），确保所有模块已 install
mvn clean install -DskipTests

3、前端相关：

查看 Node.js 是否已安装
node -v

查看 npm 版本
npm -v

安装 pnpm
npm install -g pnpm
pnpm -v

编译都没有问题

2、启动zookeeper

官方内容

下载 ZooKeeper，解压

存储配置

启动脚本

搞个txt编辑完后，后缀该bat即可

@echo off
echo 正在启动 ZooKeeper...
cd /d E:\\install\\ZooKeeper\\zookeeper-3.8.3\\bin
zkServer.cmd
pause

3、workspace.xml 修改

【可以不用，我也是看其他文章有添加的，不过我没添加也能正常运行，这里只做记录】

在其他文章看到说在这里添加这行，说是让 IDEA 在运行时动态使用模块的 classpath，而不是用启动时生成的静态 classpath。

注意点：
这个作用只会影响本地 IDEA 启动，线上环境如果有问题这个是解决不了的。

"dynamic.classpath": "true",

4、数据库

我这里用的是mysql，所以需要修改

4-1：数据初始化

创建名为【dolphinscheduler】的新数据库后，
把这个位置的sql直接拷贝复制执行即可。

如图：

4-2：依赖相关修改

如果使用 MySQL 作为元数据库，需要先修改 `dolphinscheduler/pom.xml`，
将 `mysql-connector-java` 依赖的 `scope` 改为 `compile`，
使用 PostgreSQL 则不需要

test 改成 compile

5、application.yaml 修改数据库配置

5-1：dolphinscheduler-master

如图，配置文件中修改这些数据：三个内容都是一样的

spring:
  config:
    activate:
      on-profile: mysql
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/dolphinscheduler?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8
    username: 账户名
    password: 数据库密码

5-2：dolphinscheduler-worker

5-3：dolphinscheduler-api

6、logback-spring.xml 修改日志级别

6-1：dolphinscheduler-master

<appender-ref ref="STDOUT"/>

6-2：dolphinscheduler-worker

6-3：dolphinscheduler-api

7、启动后端三个服务

我们需要启动三个服务，包括 MasterServer，WorkerServer，ApiApplicationServer

* MasterServer：在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.server.master.MasterServer` 中的 `main` 方法，并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql`

* WorkerServer：在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.server.worker.WorkerServer` 中的 `main` 方法，并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql`

* ApiApplicationServer：在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.api.ApiApplicationServer` 中的 `main` 方法，并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Dspring.profiles.active=api,mysql`。启动完成可以浏览 Open API 文档，地址为 http://localhost:12345/dolphinscheduler/swagger-ui/index.html

> VM Options `-Dspring.profiles.active=mysql` 中 `mysql` 表示指定的配置文件

7-1：MasterServer

配置 VM Options

按照操作配置这个：打开后填入即可

-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql

7-2：WorkerServer

配置 VM Options

跟上面一样操作：

-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql

7-3：ApiApplicationServer

配置 VM Options

-Dlogging.config=classpath:logback-spring.xml -Dspring.profiles.active=api,mysql

总的就这三个：

8、启动前端服务

命令：

安装前端依赖并运行前端组件

cd dolphinscheduler-ui
pnpm install
pnpm run dev

9、浏览器访问

账号密码：

浏览器访问：
http://localhost:5173/home

默认账号密码：

账号：admin
密码：dolphinscheduler123

成功访问：

相关问题

1、存储未启用、租户\用户 指定

问题：测试能否创建文件夹、上传文件等，提示【存储未启用】

问题：当前登录用户的租户信息未被指定

解决方法：

Minio 安装、启动

我这里直接用minio来尝试：

1、minio 创建 dolphinscheduler 桶

2、commom.properties 修改

配置文件改了这些地方

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

# user data local directory path, please make sure the directory exists and have read write permissions
data.basedir.path=/tmp/dolphinscheduler

# resource view suffixs
#resource.view.suffixs=txt,log,sh,bat,conf,cfg,py,java,sql,xml,hql,properties,json,yml,yaml,ini,js

# resource storage type: HDFS, S3, OSS, NONE
# ljh -->   S3 is Minio--------------------------------------
resource.storage.type=S3
# resource store on HDFS/S3 path, resource file will store to this base path, self configuration, please make sure the directory exists on hdfs and have read write permissions. "/dolphinscheduler" is recommended
resource.storage.upload.base.path=/dolphinscheduler

# ljh --> The account and password of MinIO-------------------------------
# The AWS access key. if resource.storage.type=S3 or use EMR-Task, This configuration is required
resource.aws.access.key.id=minioadmin
# The AWS secret access key. if resource.storage.type=S3 or use EMR-Task, This configuration is required
resource.aws.secret.access.key=minioadmin
# The AWS Region to use. if resource.storage.type=S3 or use EMR-Task, This configuration is required
resource.aws.region=cn-north-1
# ljh --> add bucket ------------------------------
# The name of the bucket. You need to create them by yourself. Otherwise, the system cannot start. All buckets in Amazon S3 share a single namespace; ensure the bucket is given a unique name.
resource.aws.s3.bucket.name=dolphinscheduler
# You need to set this parameter when private cloud s3. If S3 uses public cloud, you only need to set resource.aws.region or set to the endpoint of a public cloud such as S3.cn-north-1.amazonaws.com.cn
# ljh --> localhost convert  127.0.0.1
resource.aws.s3.endpoint=http://127.0.0.1:9000

# alibaba cloud access key id, required if you set resource.storage.type=OSS
resource.alibaba.cloud.access.key.id=<your-access-key-id>
# alibaba cloud access key secret, required if you set resource.storage.type=OSS
resource.alibaba.cloud.access.key.secret=<your-access-key-secret>
# alibaba cloud region, required if you set resource.storage.type=OSS
resource.alibaba.cloud.region=cn-hangzhou
# oss bucket name, required if you set resource.storage.type=OSS
resource.alibaba.cloud.oss.bucket.name=dolphinscheduler
# oss bucket endpoint, required if you set resource.storage.type=OSS
resource.alibaba.cloud.oss.endpoint=https://oss-cn-hangzhou.aliyuncs.com

# if resource.storage.type=HDFS, the user must have the permission to create directories under the HDFS root path
resource.hdfs.root.user=hdfs
# if resource.storage.type=S3, the value like: s3a://dolphinscheduler; if resource.storage.type=HDFS and namenode HA is enabled, you need to copy core-site.xml and hdfs-site.xml to conf dir
resource.hdfs.fs.defaultFS=hdfs://mycluster:8020

# whether to startup kerberos
hadoop.security.authentication.startup.state=false

# java.security.krb5.conf path
java.security.krb5.conf.path=/opt/krb5.conf

# login user from keytab username
login.user.keytab.username=hdfs-mycluster@ESZ.COM

# login user from keytab path
login.user.keytab.path=/opt/hdfs.headless.keytab

# kerberos expire time, the unit is hour
kerberos.expire.time=2

# resourcemanager port, the default value is 8088 if not specified
resource.manager.httpaddress.port=8088
# if resourcemanager HA is enabled, please set the HA IPs; if resourcemanager is single, keep this value empty
yarn.resourcemanager.ha.rm.ids=192.168.xx.xx,192.168.xx.xx
# if resourcemanager HA is enabled or not use resourcemanager, please keep the default value; If resourcemanager is single, you only need to replace ds1 to actual resourcemanager hostname
yarn.application.status.address=http://ds1:%s/ws/v1/cluster/apps/%s
# job history status url when application number threshold is reached(default 10000, maybe it was set to 1000)
yarn.job.history.status.address=http://ds1:19888/ws/v1/history/mapreduce/jobs/%s

# datasource encryption enable
datasource.encryption.enable=false

# datasource encryption salt
datasource.encryption.salt=!@#$%^&*

# data quality option
data-quality.jar.name=dolphinscheduler-data-quality-dev-SNAPSHOT.jar

#data-quality.error.output.path=/tmp/data-quality-error-data

# Network IP gets priority, default inner outer

# Whether hive SQL is executed in the same session
support.hive.oneSession=false

# use sudo or not, if set true, executing user is tenant user and deploy user needs sudo permissions; if set false, executing user is the deploy user and doesn't need sudo permissions
sudo.enable=true
setTaskDirToTenant.enable=false

# network interface preferred like eth0, default: empty
#dolphin.scheduler.network.interface.preferred=

# network IP gets priority, default: inner outer
#dolphin.scheduler.network.priority.strategy=default

# system env path
#dolphinscheduler.env.path=dolphinscheduler_env.sh

# development state
development.state=false

# rpc port
alert.rpc.port=50052

# set path of conda.sh
conda.path=/opt/anaconda3/etc/profile.d/conda.sh

# Task resource limit state
task.resource.limit.state=false

# mlflow task plugin preset repository
ml.mlflow.preset_repository=https://github.com/apache/dolphinscheduler-mlflow
# mlflow task plugin preset repository version
ml.mlflow.preset_repository_version="main"

# ljh --> minio must open path style
resource.aws.s3.path.style.access=true

3、dolphinscheduler 可视化页面添加租户

安全中心 - 租户管理 - 创建租户

用户添加租户

演示

创建文件夹、上传文件成功

如图，数据已经存放在我指定的minio文件夹里面了

为什么需要节点式思维对齐工具？

在复杂的团队协作中，传统的线性沟通方式往往只关注信息的单向传递，而忽略了认知的深层对齐 。然而，战略与执行之间存在多维度的关联，如果没有节点化的对齐管理，可能会导致：

• 团队认知断层：战略意图在层层传递中失真，执行端无法理理解决策背后的逻辑原点 。
• 沟通效率低下：缺乏可视化逻辑链条，导致决策路径破碎，难以回溯演进过程 。
• 协作方向偏离：各部门缺乏统一的“认知地图”，导致资源投入无法形成合力。

节点式思维对齐工具通过将抽象的想法、目标和任务转化为可视化的节点与链路，帮助团队建立结构化的认知模型，确保每个人的思考都能在同一频率上 。

节点式思维对齐工具的核心特性

• 图谱化展示：将思路和任务以节点形式呈现，直观展示非线性的逻辑关联 。
• 动态实时同步：支持多人在线实时推演，任何思维层面的变动都能即刻实现全员对齐。
• 多层级逻辑穿透：可从宏观的战略节点下钻至微观的执行细节，实现全局与局部的统一 。
• 关系链路建模：清晰标记节点间的因果、阻塞或支撑关系，构建严密的逻辑闭环 。

节点式思维对齐工具的重要意义

1. 缩短认知半径：通过可视化的思维图谱，极大降低了跨部门理解复杂战略及业务逻辑的门槛 。
2. 强化决策严密性：可视化的过程会倒逼团队梳理逻辑，从而更容易发现潜在的逻辑矛盾或执行缺失点。
3. 提升资源协同效率：节点式对齐能快速识别出“关键节点”和“瓶颈节点”，引导团队精准投入核心资源 。
4. 增强成员目标感：透明化的思维路径让每位执行者都能清晰看到自己的工作在整体大蓝图中的位置。

应用场景

• 战略解码与推演：将公司愿景逐级拆解为各层级的关键决策节点，确保上下同欲 。
• 复杂项目架构设计：在项目启动前，通过节点图梳理系统架构、功能模块与业务依赖 。
• 项目复盘与逻辑对齐：回溯执行过程中的关键决策节点，识别逻辑拐点并沉淀为组织资产。

---

5款值得尝试的节点式思维对齐工具

1. 板栗看板

结构化节点展示与任务对齐的可视化平台

• 特点：支持任务卡片间的逻辑连线，通过看板视图直观展示节点的流转过程与依赖关系 。
• 优势：将“抽象逻辑”与“具体任务”通过节点连接，团队能清晰看到每个任务背后的价值支撑 。
• 适合团队：追求流程透明与逻辑一致性，需要将战略目标快速落地为执行动作的敏捷团队。
  

2. Trello

直观的看板式思维对齐工具

• 特点：通过颜色标记、标签系统和列表组织，让节点在工作流中的位置一目了然 。
• 优势：界面设计直观，通过简单的拖拽即可实现任务节点的优先级调整与共识达成 。
• 适合团队：注重可视化呈现和轻量级协同的初创或创意团队 。
  

3. ClickUp

灵活的多视图节点管理系统

• 特点：支持将思维节点在时间线、看板等多种视图间切换，适应不同的认知需求。
• 优势：功能极其丰富，能够帮助团队管理复杂的任务层级和多维度的逻辑分类 。
• 适合团队：需要多层级管理、涉及复杂职能交叉的中大型团队 28。
  在这里插入图片描述
  

4. Jira Software

专业级研发逻辑对齐与追踪平台

• 特点：将目标对齐作为敏捷流程的核心，支持任务节点的深度影响分析与状态追踪 。
• 优势：严密的逻辑关联能力，适合对研发流程、故障节点有严格闭环管理要求的团队 。
• 适合团队：追求高度标准化、需要将思维对齐固化为生产流水线的专业技术团队 。
  

5. Asana

跨职能思维协同与目标分发平台

• 特点：提供灵活的节点管理能力，强调跨职能团队间的目标一致性与协作友好性 。
• 优势：强大的集成能力，能将思维对齐的结果快速转化为不同应用间的自动化流转 。
• 适合团队：需要灵活处理跨部门复杂依赖、注重易用性与协作体验的通用型团队 。
  

---

如何选择合适的节点式思维对齐工具？

1. 按团队规模选择

• 小型团队：推荐 板栗看板、Trello 等上手即用的工具，强调从思维到执行的转化效率 。
• 中型团队：适合使用 Asana、Trello 等灵活管理复杂任务节点与标签的平台 。
• 大型团队：建议选择 ClickUp 或 Jira，这些工具提供强大的层级管理功能，适应大规模共识难题 。

2. 按思维复杂度选择

• 简单对齐（如日常待办、轻松项目）：选择 板栗看板、Trello 等直观、操作简便的工具 。
• 复杂对齐（如跨部门协作、深层系统重构）：推荐 ClickUp、Jira 等支持深度自定义和多层级节点管理的系统。

---

结语

节点式思维对齐工具让组织的认知从碎片走向网状，帮助团队打破“理解的墙”，在高度不确定的商业环境中快速形成合力。通过这些工具，团队可以构建可视化的组织大脑，确保每一个动作都源于深度共识，并最终指向共同的目标

引言

想象一下：你只需要用自然语言描述你的需求，AI 就能自动帮你完成数据库操作 —— 创建文档集合、插入数据、执行复杂查询，甚至构建一个完整的知识库应用。这不是未来，而是现在就能实现的能力。

seekdb MCP Server 就是实现这一愿景的桥梁。它基于 Anthropic 提出的 MCP（Model Context Protocol）协议，让 AI 助手能够直接与 seekdb 数据库交互，将 "自然语言" 转化为 "数据库操作"。

本文将带你上手 seekdb MCP Server，并通过一个实战案例 —— 通过自然语言构建 AI 应用，让你亲身体验 AI 原生数据库的魅力。

欢迎大家关注，在这里，我们会持续为大家更新与 #数据库、#AI 相关的技术内容！

什么是 seekdb MCP Server？

seekdb 是一款 AI 原生搜索数据库，在统一架构下融合了关系数据、向量数据、全文索引、JSON 和 GIS 能力，支持混合检索和库内 AI 工作流。

MCP Server 则是连接 AI 工具与数据库的"适配器"。通过 MCP 协议，Cursor、Claude Code、Cline 等 AI 工具可以直接访问和操作 seekdb 数据库。

核心能力一览

安装 seekdb 数据库

在使用 seekdb MCP Server 之前，你需要先准备好 seekdb 数据库。seekdb 提供两种部署模式：

模式一：嵌入式模式（零配置，仅限 Linux）

嵌入式模式无需单独安装 seekdb 数据库！seekdb MCP Server 启动时会自动初始化一个本地嵌入式数据库，开箱即用。

适用场景：个人学习、快速原型开发、边缘设备运行。

⚠️ 提示：
macOS 和 Windows 用户需要使用「客户端 / 服务器模式」，需要先部署 seekdb 数据库（推荐 Docker 方式），然后配置连接参数。

模式二：客户端/服务器模式（生产推荐）

如果你需要在测试或生产环境部署 seekdb，可以选择以下方式：

方式 1：使用 yum 安装（RPM 系统）

# 1. 添加 seekdb 镜像源
sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo

# 2. 安装 seekdb 和客户端
sudo yum install seekdb obclient

# 3. 启动 seekdb
sudo systemctl start seekdb

# 4. 检查启动状态（状态为 "Service is ready" 表示启动成功）
sudo systemctl status seekdb

# 5. 连接测试
mysql -h127.0.0.1 -uroot -P2881 -A oceanbase

方式 2：使用 Docker（最快捷）

# 一行命令启动 seekdb
sudo docker run -d -p 2881:2881 oceanbase/seekdb

# 如果拉取失败，可使用备用镜像源：
# sudo docker run -d -p 2881:2881 quay.io/oceanbase/seekdb
# sudo docker run -d -p 2881:2881 ghcr.io/oceanbase/seekdb

系统要求：

• CPU：最低 1 核
• 内存：最低 2 GB 可用内存
• 支持的操作系统：CentOS 7/8、Ubuntu 20+、Debian 9+、Anolis OS 8、麒麟 V10 等

更多部署方式请参考 seekdb 部署文档^[1]。

安装 seekdb MCP Server

安装 uv 包管理器

# 安装 uv 包管理器
curl -LsSf https://astral.sh/uv/install.sh | sh

配置 AI 工具连接

Stdio 模式

以 Cursor 为例在 Cursor 中，打开设置 → Tools & MCP → New MCP Server，根据你的操作系统选择配置方式：

Linux 用户（嵌入式模式）

{
  "mcpServers": {
    "seekdb": {
      "command": "uvx",
      "args": ["seekdb-mcp-server"]
    }
  }
}

就这么简单！嵌入式模式无需任何配置，服务器启动时会自动初始化一个本地 seekdb 数据库。

macOS / Windows 用户（服务器模式）

macOS 和 Windows 不支持嵌入式模式，需要先部署 seekdb 数据库（推荐使用 Docker），然后配置连接参数：

{
  "mcpServers": {
    "seekdb": {
      "command": "uvx",
      "args": ["seekdb-mcp-server"],
      "env": {
        "SEEKDB_HOST": "127.0.0.1",
        "SEEKDB_PORT": "2881",
        "SEEKDB_USER": "",
        "SEEKDB_PASSWORD": "",
        "SEEKDB_DATABASE": "test"
      }
    }
  }
}

参数说明：

SSE 模式

Linux 用户（嵌入式模式）

直接启动 SSE 服务器：

uvx seekdb-mcp-server --transport sse --port 6000

macOS / Windows 用户（服务器模式）

先配置环境变量，再启动服务器：

# 配置 seekdb 连接信息
export SEEKDB_HOST=127.0.0.1
export SEEKDB_PORT=2881
export SEEKDB_USER=
export SEEKDB_PASSWORD=
export SEEKDB_DATABASE=test

# 启动 SSE 服务器
uvx seekdb-mcp-server --transport sse --port 6000

然后在客户端配置：

{
  "sse-seekdb": {
    "type": "sse",
    "url": "http://127.0.0.1:6000/sse"
  }
}

实战案例：用 AI 对话构建个人笔记知识库

现在让我们通过一个完整的实战案例，体验 seekdb MCP Server 的强大能力。我们将构建一个个人笔记知识库，实现：

• ✅ 用自然语言存储笔记
• ✅ 语义搜索相关内容
• ✅ 混合搜索精准定位
• ✅ AI 智能问答

场景设定

假设你是一名技术工作者，平时会记录各种学习笔记、工作心得。现在你希望用 AI 帮你管理这些笔记，并能通过自然语言快速找到需要的内容。

第一步：创建笔记集合

在 AI 工具（如 Cursor）的对话框中输入：

创建一个名为 "my_notes" 的知识库集合

AI 响应示例：

我已成功创建名为 "my_notes" 的集合：

• 维度: 384（向量大小）
• 距离度量: L2（欧几里得距离）

就这样，一个支持语义搜索的向量集合就创建好了！

第二步：添加笔记内容

继续输入：

向 my_notes 中添加以下笔记：

1. "seekdb 支持向量搜索和全文搜索的混合检索，可以同时利用关键词匹配和语义理解"
2. "MCP 协议是 Anthropic 在 2024 年 11 月提出的开源协议，让大模型可以与外部工具交互"
3. "Python 的 asyncio 模块提供了异步编程能力，适合 I/O 密集型任务"
4. "Docker 容器化技术可以实现应用的快速部署和环境隔离"
5. "RAG（检索增强生成）是目前最流行的 AI 应用架构，结合检索和生成能力"

AI 响应示例：

完成！已成功向 "my_notes" 集合添加 5 条笔记：

第三步：语义搜索

现在，让我们用自然语言搜索笔记：

在 my_notes 中搜索与 "AI 应用开发" 相关的笔记

AI 响应示例：

以下是与 "AI 应用开发" 相关的笔记，按相关性排序：

注意：我们搜索的是 "AI 应用开发"，但笔记中并没有这个确切的词。seekdb 的向量搜索能够理解语义相似性，自动找到相关内容！

第四步：混合搜索

混合搜索结合了关键词匹配和语义理解，效果更精准：

对 my_notes 执行混合搜索：
- 全文关键词："Python"
- 语义查询："异步编程和并发处理"

AI 响应示例：

混合搜索使用 RRF（倒数排名融合） 算法，综合关键词匹配（BM25）和向量相似度得分，排名结果更准确。

第五步：让 AI 记住你的偏好

seekdb MCP Server 还提供了 AI 记忆系统，让 AI 能够跨会话记住你的信息：

记住我是一名 Python 开发者，主要使用 seekdb 做向量搜索应用

AI 响应示例：

已记录！我会记住：

• 你是一名 Python 开发者
• 主要使用 seekdb 做向量搜索应用

下次对话时，你可以直接问：

根据我的技术背景，推荐一些学习资源

AI 会自动检索你的偏好，给出个性化推荐！

功能一览

向量集合管理

高级搜索

AI 模型工具

AI 记忆系统

seekdb MCP Server 提供了强大的 AI 记忆功能，让 AI 助手能够跨会话记住信息：

使用场景：

• AI 记住你的技术栈偏好（如 "我习惯使用 Python"）
• AI 记住项目信息（如 "这个项目使用 FastAPI"）
• AI 记住个人偏好（如 "我喜欢简洁的代码风格"）

数据导入导出

SQL 操作

更多工具探索

除了本文介绍的功能，seekdb MCP Server 还支持：

• AI 函数调用

  • 使用 AI 模型分析这段文本的情感倾向："今天天气真好，心情愉悦！"

• CSV 数据导入

  • 将 /path/to/products.csv 导入为向量集合，使用第 2 列（产品描述）作为文档

常见问题

Q: 需要安装 seekdb 吗？

A: 不需要！seekdb MCP Server 使用嵌入式模式，seekdb 已经包含在内，无需单独安装。

Q: 数据存储在哪里？

A: 数据存储在本地文件系统中，默认在当前用户家目录下。你的数据完全在本地，不会上传到任何云端。

Q: 支持哪些操作系统？

A: 目前支持 Linux（glibc >= 2.28），支持 x86_64 和 aarch64 架构。

Q: 如何升级？

A: 使用 uvx 时会自动使用最新版本。

总结

seekdb MCP Server 让数据库操作变得前所未有的简单：

无论你是想快速构建 RAG 应用，还是想让 AI 助手拥有"长期记忆"，seekdb MCP Server 都是你的最佳选择。

开始你的 AI 原生数据库之旅吧！ 🚀

参考资料

[1] seekdb 部署文档: https://www.oceanbase.ai/docs/deploy-overview/

案例背景

作为亚洲领先的投资基金，某东南亚投资基金公司（以下简称 A 基金）正处于从传统数仓向企业级数据中台转型的关键期。目前，其核心业务系统深植于 AWS 环境，涵盖了 SQL Server、MySQL 及 S3 等多种存储形态，并已初步建成基于 MSK（Kafka）与 Flink 的实时处理链路。为了应对日益增长的业务需求，A 基金规划引入 Databricks Lakehouse 作为统一的数据底座。

然而，随着任务规模预估跨越式增长，多云环境导致的“碎片化”问题愈发凸显。跨云任务协同困难、多套调度体系割裂、缺乏 CI/CD 机制以及 Databricks 作业无法深度纳管等挑战，使得平台运维成本激增，资源弹性难以支撑业务峰值。

核心挑战

具体来说，A 基金在推动企业级数仓与数据中台建设的过程中 遇到的核心挑战来源于多方面：

• 多云环境共存导致协同困难： 存量系统在 AWS，新系统与 Lakehouse 规划落在 Databricks（跨云可部署），跨云数据传输与资源调度缺乏统一协同机制。
• 数据工具多样、调度体系割裂： 内部存在多套同步与调度方案，缺少统一编排、统一运维监控与统一告警体系。
• 缺乏 CI/CD 机制： 任务上线、变更依赖人工导入导出，版本控制、审计与回滚能力不完善。
• 资源弹性不足： 高峰期任务堆积、低峰期资源闲置，扩缩容响应不及时，影响整体 SLA。
• Databricks 作业体系纳管不足： Databricks Jobs/Notebook/Workflow 与现有调度体系割裂，容易形成“第二套平台”，进一步加剧治理碎片化。
• Lakehouse 建设需求增强： 需要支持批/实时数据统一落地到 Lakehouse，支持 Schema 演进、版本治理与表格式演进策略，避免口径漂移与数据孤岛。
• 运维噪声与体验问题： 任务状态多、告警多、定位慢；Dashboard 缺少时间记忆与常用筛选保持，影响日常运营效率。

WhaleStudio + Databricks 统一湖仓方案

针对上述挑战，A 基金采用 WhaleStudio 商业版 作为统一的数据集成与调度中枢，深度纳管 AWS 与 Databricks 作业体系。通过“批处理+CDC”双引擎及实时链路（MSK+Flink）统一编排，打破多云割裂，消除治理孤岛。结合 CI/CD 自动化交付与动态扩缩容架构，在支撑万级任务扩展的同时，实现 Lakehouse 的标准化治理与智能运维，确保金融级数据的高可靠与强一致性。

具体来说，WhaleStudio 商业版作为核心的数据集成与调度中枢，通过以下四大核心模块，实现了从数据接入到运维治理的全流程自动化，将 Databricks Lakehouse 深度整合进企业的统一治理闭环：

1. 统一编排中枢：跨云协同与 Databricks 深度纳管

该方案通过构建统一的任务中心与元数据仓库，整合了原本分散的集成与调度工具，实现跨系统的集中管理与审计。它不仅能够统一编排 AWS 生态下的原生任务，更实现了对 Databricks Jobs / Notebook / Workflow 的深度对接。通过建立跨云任务的统一依赖、统一调度与统一监控体系，有效避免了 Databricks 沦为孤立的“第二套平台”，确保了多云环境下业务协同的连贯性。

2. 批流一体架构：双引擎接入与实时链路治理

为了满足金融资管对数据时效性的多样化需求，平台提供 “批处理 + CDC” 双引擎接入能力，全面覆盖 SQL Server、MySQL 及 S3 等多源数据的采集与同步。同时，方案将 Kafka (MSK) 与 Flink 实时流任务深度纳入统一工作流编排，形成了离线分层落地与实时链路供给并行的治理模式。这种“批流一致”的体系，确保了实时与离线任务在调度逻辑、监控视图及告警机制上的高度统一。

3. 规范化湖仓落地：Lakehouse 演进与自动化交付

在数据落地阶段，方案优先支撑产出统一汇聚至 Databricks Lakehouse，构建起从 ODS、DWD 到 DWA 的标准化分层体系。平台兼容 Delta 与 Iceberg 等主流表格式策略，并提供 Schema 演进与版本治理能力，防止口径漂移。此外，通过引入 CaC（配置即代码）与 CI/CD 标准化流水线，实现了配置版本化、变更审计与灰度发布，将传统的人工操作转化为自动化的持续交付，极大降低了上线风险。

4. 智能化运维体系：告警降噪与交互体验优化

针对大规模任务环境下的运维压力，方案提供了智能化的监控解决方案。通过多级告警聚合与降噪技术，配合失败/告警过滤视图，运维人员能从海量信息中快速锁定核心问题。同时，系统对 Dashboard 进行了人性化改良，支持时间记忆与筛选状态保持，大幅提升了异常定位的速度与日常运营的整体效率。

方案对比：从多工具拼装到一体化中枢

在 A 基金最初的架构设计中，多工具拼装的“烟囱式”结构虽然在短期内解决了业务上线快的问题，但随着任务规模向万级跨越，这种模式带来的协同成本和运维压力已成为技术债。

WhaleStudio 方案的核心价值在于“打破割裂”，它不是在原有的工具堆栈上多打一个补丁，而是通过统一的编排大脑和标准化的交付流水线，将 Databricks 从一个孤立的计算引擎，彻底转变为企业全局数据治理闭环中的一部分。这种转变不仅是为了解决当前的运维噪声，更是为了在跨云环境下，为后续 Lakehouse 的长期演进提供一个稳固的工程化底座。

通过下图和表格，我们可以直观地看到架构重塑前后的差异：

业务价值与收益：从效率跃迁到治理升级

总结起来，通过引入 WhaleStudio 平台，A 基金成功实现了从“多工具拼装”向“一体化治理”的架构跨越，其核心收益主要体现在以下三个维度：

首先，在管理架构上实现了全链路闭环与深度纳管。
平台将集成、编排、监控、告警与审计高度整合，彻底终结了系统割裂带来的重复维护。最显著的变化在于，Databricks 的作业体系与数据落地被完整纳入统一调度，使其不再是游离于主体系之外的“第二套平台”，实现了真正的跨云而不割裂。

其次，在交付能力与资源利用率上达成了双重突破。
在工程化方面，标准化的流水线交付取代了低效的人工导入导出，配合审计与一键回滚机制，让业务变更既快又稳。在性能方面，分布式架构配合动态扩缩容，有效缓解了金融业务在峰值期的任务堆积，在确保 SLA 稳定的同时，大幅减少了低峰期的资源浪费。

最后，在运维体验与长期演进中建立了坚实底座。
针对金融级治理需求，Schema 演进与版本控制能力显著降低了口径漂移风险，保障了 Lakehouse 的长期健康演进。而在日常运营中，告警降噪、过滤视图与时间记忆等智能化功能，将运维人员从干扰信号中解放出来，实现了异常问题的精准定位与快速响应。

归结起来，在多云与多工具并存的背景下，A 基金选择以 WhaleStudio 商业版作为统一的数据集成与调度中枢，将 AWS 上的批处理/CDC 与实时链路（MSK + Flink）以及 Databricks Lakehouse 的作业与数据落地纳入同一套编排、交付与运维治理体系。通过分布式架构与跨云统一编排，其能在任务规模从数百向数千增长的过程中保持 SLA 稳定，并以 CI/CD、告警降噪与 Lakehouse 治理能力，为基金业务提供更安全、更可追溯、更易演进的数据底座。

相关点击访问：

github

HUGGINGFACE

MODELSCOPE

SHOWCASEgithub

从 Chatbot 到 Autonomous Agent

通义DeepResearch —— 首个在性能上可与 OpenAI DeepResearch 相媲美、并在多项权威基准测试中取得领先表现的全开源 Web Agent。

在多个极高难度的信息检索和推理任务中，通义DeepResearch 取得了最先进的（SOTA）成绩：

• Humanity’s Last Exam (HLE)：32.9
• BrowseComp‑EN：43.4
• BrowseComp‑ZH：46.7
• xBench‑DeepSearch：75.0

全面超越了目前所有的闭源及开源 Deep Research 智能体（Agent）。

不仅如此，我们还完整分享了一套可落地的高水平Agent构建方法论，详细介绍了从数据合成、Agentic 增量预训练（CPT）、有监督微调（SFT）冷启动，到强化学习（RL）的全套流程。在 RL 环节，我们提供了算法创新、自动化数据构建与高稳定性基础设施的全栈解决方案。

在推理阶段，基础的 ReAct 模式无需任何提示工程即可充分展现模型固有能力，而深度模式（test‑time‑scaling） 则展示了其在复杂推理与规划能力上的上限。

基于合成数据的增量预训练和后训练

增量预训练数据

我们提出在Agent模型训练中加入智能体增量预训练（Agentic Continual Pre‑training, Agentic CPT）阶段，从而为后训练提供一个强大的Agent基座模型。为此，我们提供了一套支持大规模持续扩展的智能体预训练数据合成方案AgentFounder，并与后训练过程中源源不断生产的数据形成数据飞轮。

数据重组和问题构建 

基于广泛收集和持续更新的知识文档、公开可用的爬虫数据、知识图谱以及后训练数据生产和训练中产生的轨迹数据和工具调用返回结果（例如，搜索结果和网页访问记录）等，我们构建了一个以实体为锚定的开放世界知识记忆。进一步，我们基于采样的实体和相关知识构造多风格的（问题，答案）对，以尽可能涵盖智能体所面临的真实场景。

动作合成 

基于多风格问题和历史轨迹数据，我们分别构建了三种类型的动作数据，包含单步的规划、推理动作和多步的决策动作合成。我们的方法能够在离线环境下大规模、全面地探索潜在的推理‑动作空间，从而消除了对额外商业工具 API 调用的需求。例如，对于决策动作合成，我们将原始轨迹中的步骤进行扩展，并最终建模成多步骤决策过程数据，以激发模型的探索能力和决策能力。

后训练数据

High‑quality QA

我们开发了一套端到端的合成数据生成解决方案。这一全自动流程无需人工干预即可构建超越人类质量的数据集，旨在突破智能体的性能极限。经过长期的探索和迭代——从早期的网页点击流逆向工程Benchmark（WebWalker）到基于图谱的合成方法（WebSailor 和 WebSailor‑V2），再到形式化的任务建模（WebShaper），我们的方法确保了卓越的数据质量和强大的可扩展性，突破了模型能力的上限。

为了解决复杂且高度不确定的问题，我们通过一种新颖的流程合成基于 Web 的问答数据。该流程首先通过在高度互联的知识图谱随机游走和基于表格数据融合同构表构建，将来自真实网站数据整合，并确保信息结构的真实性；然后，我们对子图和子表进行采样，生成初始问题和答案，关键步骤是通过策略性地混淆或模糊问题中的信息来增加问题难度。该方法基于一个组合泛化的理论框架，我们将问答难度正式建模为一系列可控的“原子操作”（例如，合并具有相似属性的实体），这些操作基于实体关系，使我们能够系统地增加复杂性。

为了进一步减少问答系统的信息结构与推理结构之间的不一致性，提高推理难度和结构扩展能力，我们提出了一种基于集合论的信息搜索问题形式化建模，基于这种建模，我们开发了能够以可控方式扩展问题的智能体，并最大限度地减少了推理捷径和结构冗余，从而进一步提升了问题质量，此外，这种形式还能高效地验证问答的正确性，有效解决了信息搜索合成数据难以验证的挑战。

我们还开发了一个自动化学术数据构建流程，以扩大博士级研究问题的规模。该引擎基于多学科知识库，生成需要多源推理的“种子”问答对；然后，每个种子都会进入一个自我引导的“迭代复杂性升级”循环，其中，一个问题构建代理配备了一套强大的工具，包括网络搜索、学术检索和 Python 执行环境。在每次迭代中，代理都会扩展知识边界，深化概念抽象，甚至构建计算任务，从而形成一个演化循环，上一轮的输出成为下一轮更复杂的输入，确保任务难度的可控且系统地升级。

融合多样推理模式，激发智能体潜能

为激发模型的初始能力，我们基于 ReAct 和 IterResearch 框架，通过拒绝采样的方式构建了一组轨迹。一方面，ReAct 作为一个经典且基础的多轮推理范式，为模型注入了丰富的推理行为，并加强了其遵循结构化格式的能力。

另一方面，我们引入了一种创新的智能体范式——IterResearch（下文将详细介绍）。它通过在每一轮动态地重构一个精简的工作空间，来释放模型的全部推理潜力，从而确保每一个决策都经过深思熟虑，不受上下文噪声干扰。

Rollout模式

我们对深度研究型智能体的部署范式进行了广泛的探索。因此，我们的最终模型支持多种部署格式，包括原生的 ReAct 模式和上下文管理的深度模式。

ReAct 模式

我们的模型使用ReAct推理范式展现出卓越的性能。它严格遵循“思考‑行动‑观察”的循环，通过多次迭代来解决问题。模型上下文长度为 128K，可以处理大量的交互轮次，从而完全实现与环境交互的可扩展性。ReAct 的简单性和通用性为模型的内在能力和我们训练流程的有效性提供了最清晰的基准。

我们选择ReAct很大程度上受到了“The Bitter Lesson”的影响，利用可扩展计算的通用方法最终将优于依赖复杂的人工知识和复杂设计的方法。

深度模式

除了 ReAct 模式外，我们还开发了“深度模式”，用于处理极端复杂的多步研究任务。此模式基于我们全新的 IterResearch 范式，旨在将Agent的能力发挥到极致。

IterResearch 范式的创建是为了解决Agent将所有信息堆积在一个不断扩展的单一上下文窗口中时出现的认知瓶颈和噪音污染。针对多步研究任务，IterResearch 将其解构为一系列研究回合。

在每一轮中，Agent仅使用上一轮中最重要的输出来重建一个精简的工作空间，在这个专注的工作空间中，Agent会分析问题，将关键发现整合成一个不断演变的核心报告，然后决定下一步行动——是收集更多信息还是提供最终答案。这种“综合与重构”的迭代过程使Agent能够在执行长期任务时保持清晰的认知焦点和高质量的推理能力。

在此基础上，我们提出了Research‑Synthesis框架，并行使用多个IterResearch Agent探索同一个问题。并最终整合它们完善的报告和结论，从而得出更准确的最终答案，这种并行结构使模型能够在有限的上下文窗口内考虑更广泛的研究路径，从而将其性能推向极限。

端到端Agent训练流程

训练这样的Agent模型需要重新思考整个模型训练流程，从预训练到微调再到强化学习，我们建立了一套完整的智能体模型训练范式，将Agentic CPT → Agentic SFT → Agentic RL 连接起来，为 AI Agent创建了一个无缝的端到端训练循环。

以下是我们利用强化学习解决最后阶段的方法，对于使代理的行为与高阶目标保持一致至关重要：

基于On-Policy策略的智能体强化学习 (RL)

通过强化学习构建高质量的Agent是一项复杂的系统工程挑战；如果将整个开发过程视为一个“强化学习”循环，其组件中的任何不稳定或鲁棒性不足都可能导致错误的“奖励”信号。接下来，我们将分享我们在强化学习方面的实践，涵盖算法和基础设施两个方面。

在强化学习（RL）算法方面，我们基于GRPO进行了定制优化，我们严格遵循 on‑policy 的训练范式，确保学习信号始终与模型当前的能力精准匹配，同时，我们采取了一个 token 级别的策略梯度损失函数来优化训练目标。

其次，为了进一步降低优势估计（advantage estimation）的方差，我们采用了留一法 (leave‑one‑out) 策略，此外，我们发现未经筛选的负样本会严重影响训练的稳定性，这种不稳定性在长时间训练后可能表现为“格式崩溃”（format collapse）现象。为缓解此问题，我们会选择性地将某些负样本排除在损失计算之外，例如那些因过长而未能生成最终答案的样本，出于效率考虑，我们没有采用动态采样，而是通过增大批次（batch size）和组规模（group size）的方式，来维持较小的方差并提供充足的监督信号。

训练过程的动态指标显示，模型学习效果显著，奖励（reward）呈持续上升趋势。同时，策略熵（policy entropy）始终维持在较高水平，这表明模型在持续进行探索，有效防止了过早收敛。我们将此归因于Web环境天然的非平稳性，该特性促进了稳健自适应策略的形成，也因此无需再进行显式的熵正则化。

我们认为，算法固然重要，但并非 Agentic RL 成功的唯一决定因素。 在尝试了多种算法和优化技巧后我们发现，数据质量和训练环境的稳定性，可能是决定强化学习项目成败的更关键一环。一个有趣的现象是，我们曾尝试直接在 BrowseComp 测试集上训练，但其表现远不如使用我们合成数据的结果。我们推测，这种差异源于合成数据提供了一致性更高的分布，使模型能进行更有效的学习和拟合。

相比之下，像 BrowseComp 这样的人工标注数据，本身就含有更多噪声，加之其规模有限，导致模型很难从中提炼出一个可供学习的潜在分布，从而影响了其学习和泛化（generalize）能力。这一发现对其他智能体的训练同样具有启发意义，为构建更多样、更复杂的智能体训练方案提供了思路。

在基础设施方面，使用工具训练智能体需要一个高度稳定高效的环境：

● 仿真训练环境：依赖实时 Web API 进行开发成本高昂、速度慢且不一致。我们利用离线维基百科数据库和自定义工具套件创建了一个模拟训练环境来解决这一问题。并且通过SailorFog‑QA‑V2的流程，为该环境生成专属的高质量数据，创建了一个经济高效、快速可控的平台，显著加快了我们的研究和迭代速度。

● 稳定高效的工具沙盒：为了确保在智能体训练和评估期间对工具的稳定调用，我们开发了一个统一的沙盒。该沙盒通过缓存结果、重试失败的调用以及饱和式响应等改进来高效地处理并发和故障。这为智能体提供了快速且鲁棒的交互环境，可以有效防止工具的错误响应破坏其学习轨迹。

● 自动数据管理：数据是提升模型能力的核心驱动力，其重要性甚至超过了算法。数据质量直接决定了模型是否能通过自我探索提升分布外泛化能力。因此，我们在训练动态的指导下实时优化数据，通过全自动数据合成和数据漏斗动态调整训练集。通过数据生成和模型训练之间的正向循环，这种方法不仅确保了训练的稳定性，还带来了显著的性能提升。

● On‑Policy策略的异步框架：我们在 rLLM 之上实现了异步强化学习训练推理框架，多个智能体实例并行与（模拟或真实）环境交互，独立生成轨迹。

通过这些措施，我们实现了智能体强化训练的“闭环”。从基座模型开始，我们进行了Agentic持续预训练以初始化工具使用技能，然后使用类似专家的数据进行监督微调以实现冷启动，最后进在on‑policy的强化学习，使模型进行自我进化。这种全栈方法为训练能够在动态环境中稳健地解决复杂任务的 AI 代理提供了一种全新的范例。

（我们的强化学习算法受到 Agentica 过去研究的启发。我们基于rLLM框架进行开发和扩展，实现高效训练）

应用及影响

通义Deep Research不仅仅是一个研究成果的展示，它已经在阿里巴巴内外赋能实际应用，并在实际场景中展现其价值：

高德地图（地图导航智能体） 高德 App 作为通义在集团内长期共建的重点客户，其“地图导航+本地生活”的业务场景，以及高德内部丰富的专用工具，具备构建Deep Research 类 Agent 的土壤，高德也将这种能力作为 25 年暑期大版本 V16 的一个亮点功能。通义团队近期在地图+本地生活场景，基于纯agentic + ReAct执行复杂推理的垂类Deep Research技术建设，为高德提供更好效果的模型。因此，双方团队共建合作，“通义团队提供Deep Research模型 + 高德团队提供工具和 Agent 链路”，打造了高德 App 中助手「小高老师」的复杂查询体验，在地图行业内打出影响力。

通义法睿（法律Deep Research） 作为大模型原生的“法律智能体”，致力于为大众及法律从业者提供专业、便捷的法律智能服务。集法律问答、案例法条检索、合同审查、文书阅读、文书起草等功能于一体，全面满足法律用户需求。依托创新的Agentic架构与迭代式规划（Iterative Planning）技术，通义法睿全新升级司法DeepResearch能力，可高效执行多步查询与复杂推理，实现权威类案精准检索、法条智能匹配与专业观点深度融合。我们以真实判例、官方法规和权威解读为基础，打造可追溯、高可信的法律分析服务，在法律问答的深度研究三大核心维度——答案要点质量、案例引用质量、法条引用质量上领先行业。

未来工作

我们未来的工作将致力于解决以下三个关键局限性：首先，当前 128k 的上下文长度在处理极端复杂的长程推理任务时仍显不足。为此，我们将探索扩展上下文窗口的有效方法，并研究更精细的上下文管理策略。其次，我们训练流程的可扩展性在远超 30B 参数规模的模型上尚未得到充分验证，我们计划在更大规模的模型上测试并验证我们流程的有效性。最后，我们旨在通过引入 partial rollouts 等技术进一步提升强化学习框架的效率，这需要我们攻克离线训练所面临的挑战，尤其是分布偏移问题。

敬请期待我们下一代Agent模型：

@misc{tongyidr,
  author={Tongyi DeepResearch Team},
  title={Tongyi DeepResearch: A New Era of Open-Source AI Researchers},
  year={2025},
  howpublished={\url{https://github.com/Alibaba-NLP/DeepResearch}}
}

点击下方访问产品链接：

面向深度的查询问答和调研分析需求场景,多步骤推理规划研究路径,生成有洞察、可溯源、图文并茂的长文报告-大模型服务平台百炼(Model Studio)-阿里云帮助中心

现在 datetime 都是英文的，英文不看的都看不到是几月份的，所以我需要改成纯数字的 iso8601 格式的

操作方法看下面的图片

生物体中，细胞蛋白的及时降解与更新是维持蛋白稳态的关键。泛素-蛋白酶体系统（UPS）是调控信号传导和蛋白质降解的核心机制。在这一系统中，E3 泛素连接酶作为关键催化单元，负责识别特定底物并催化泛素标记，从而调控蛋白降解、定位和功能状态。此外，E3 连接酶还调控免疫和炎症通路。由于其组织特异性表达及与发育和代谢综合征（包括癌症进展）的关联，E3 连接酶已成为很有前景的药物靶点，尤其适用于以往难以药物化的靶标。

与 E1（约 10 种）和 E2（约 50 种）酶相比，人类已鉴定出大量 E3 连接酶（约 600 种）。尽管如此，许多人类 E3 连接酶仍仅被部分表征，仍有大量酶处于假设或未知状态。迄今为止，已研究的 E3 连接酶表现出高度异质性，使其成为最具多样性的酶类之一，为模式识别和大规模研究带来瓶颈。因此，对人类 E3 连接酶组——即人类基因组编码的全部 E3 连接酶进行详细表征和分析，对于全面理解其生物学功能至关重要。

在此背景下，来自德国歌德大学的研究团队对「人类 E3 连接酶组（human E3 ligome）」进行了分类，整合了多层次数据，包括蛋白序列、结构域组成、三维结构、功能以及表达模式。该团队的分类方法基于度量学习（metric-learning）范式，采用弱监督的层级框架，以捕捉 E3 家族及亚家族间的真实关系。这一方法扩展了 E3 酶的传统分类（RING、HECT 和 RBR 类），区分了多亚基复合物与单体酶，并将 E3 酶映射到底物及潜在药物作用靶点。

相关研究成果以「Multi-scale classification decodes the complexity of the human E3 ligome」为题，已刊登 nature communications。

研究亮点：

• 将现有 E3 连接酶的结构域架构、三维结构、功能、底物网络及小分子相互作用映射到分类框架中，以获得一般性及家族特异性洞察

* 所开发的多尺度分类框架涵盖了典型及非典型 E3 机制，为理解 E3 连接酶的广阔生物学图景提供了完整路线图

* 为开发 E3-底物网络的药物干预策略打开了新思路

论文地址：
https://www.nature.com/articles/s41467-025-67450-9
关注公众号，后台回复「E3 酶」获取完整 PDF

更多 AI 前沿论文：
https://hyper.ai/papers

数据集：构建人类 E3 泛素连接酶数据

研究团队首先整合了来自 8 个独立数据源的人类 E3 泛素连接酶数据，包括既往文献报道和公共数据库（E3Net、UbiHub、UbiNet 2.0、UniProt、BioGRID 等），形成初步数据集共计 1,448 个蛋白条目。通过对各来源数据的交叉比对与一致性评分，去除了重复和潜在假阳性条目。随后，利用 InterPro 提供的 RING、HECT 和 RBR 催化结构域特征，筛选出 462 个高置信度的催化 E3 泛素连接酶，形成最终的人类 E3 连接酶组。

在多亚基 E3 复合物（如 Cullin-RING ligases）中，三个功能不同的子单元（支架蛋白、适配蛋白和受体蛋白）协同工作，将 E2\~Ub 分子定位到特定底物上。大型、刚性且位于中心的支架蛋白（如 Cullin 家族，Cul1–Cul5）通过同时结合催化 RING 指结构域亚基和适配蛋白/受体的对接位点，组织起整个连接酶复合体；适配蛋白桥接各模块，将支架蛋白 N 端对接面与独立的底物受体相连；受体蛋白决定底物特异性，直接识别并结合底物上的降解信号（degron），确定哪些底物会被泛素化（如 Skp2、Keap1、VHL）。研究团队独立注释并分类了三类亚基：151 个适配蛋白、106 个受体蛋白和 8 个支架蛋白，并利用它们的蛋白–蛋白相互作用（PPIs）绘制多亚基 E3 的底物映射。

随后，在催化结构域筛选阶段，研究人员以催化能力为核心判据，对候选蛋白进行严格过滤。通过 InterPro 等结构域数据库，系统识别与 E3 活性直接相关的关键催化结构域，包括 RING、HECT 和 RBR。仅保留明确包含这些结构域、且在序列和结构层面支持其泛素连接功能的蛋白，构建最终的「催化型 E3 连接酶」。这一过程有效剔除了仅参与调控、但不具备直接催化能力的辅助蛋白，从而保证了核心 E3 集合的功能一致性。

基于度量学习的多尺度分类框架

为了捕捉人类 E3 连接酶组中的复杂关系，研究人员采用机器学习方法来学习一个 Emergent 距离度量，整体框架如下图：

度量学习流程示意图

①多尺度距离度量

研究人员通过计算 12 种不同的距离来编码 E3 连接酶两两之间的关系，这些距离覆盖多个粒度层次：一级序列、结构域架构、三级结构、功能、亚细胞定位以及细胞系/组织表达。所有距离度量均被缩放至 [0,1] 区间，以便比较和组合，见下图：

覆盖分子和系统层级组织的多种成对距离度量的分布情况

• 序列层面：使用了无比对的局部匹配得分（LMS）距离和基于比对的 γ 距离
• 结构域架构层面：计算了三种距离——Jaccard 距离、Goodman–Kruskal γ 距离和结构域重复距离
• 三维结构层面：使用 AlphaFold2 模型 TM-score

* 功能层面：蛋白对 P 和 Q 的功能距离使用 GO 注释的语义相似性衡量，涵盖* 分子功能（MF）、生物过程（BP）和细胞组分（CC）三类本体

* 亚细胞定位距离

* 组织和细胞系共表达距离

②度量优化、聚类、自助法与分类

四个主要距离（γ、Jaccard、结构、分子功能）通过加权和整合，权重通过弱监督学习和元素中心相似指数（SEC）优化，如下图 ，得到最优组合指标。

通过最 SEC 评估 emergent 分层聚类（右图）与真实标签（左图）的重叠程度

层次聚类采用 Ward 最小方差法，结合自举方法计算支持度，生成最终 E3 树状图，并在树切割阈值 h = 0.25 下获得最优 emergent clusters，即将 462 个 E3 系统性地划分为 13 个家族，10 个 RING 家族、2 个 HECT 家族、1 个 RBR 家族，如下图：

人类 E3 连接酶的分类

每个家族进一步人工分析序列和结构域特征，识别亚家族和异常蛋白。

③小分子聚类与结合概率

整合的 2D UMAP 投影用于小分子聚类，结合局部密度峰值识别 20 个代表性小分子簇。通过 log-transformed propensities（LPij）量化每个簇与 E3 蛋白的结合可能性，为后续 PROTAC 开发和靶向小分子设计提供指导。

对人类 E3 连接酶组的完整性提供了详细评估

①精细整理人类 E3 连接酶组

为了解决已有研究在整理 E3 系统时策略多样且定义标准常有差异的挑战，该研究团队明确界定了 E3 系统的催化成分，即包含一个或多个催化结构域的多肽序列。利用这一客观标准，能够对 E3 进行恰当注释并进行针对性分析。最终，研究人员发现所有数据集中共有 462 条多肽序列至少包含一个催化结构域，这些多肽构成了精细整理的人类 E3 连接酶组，见下图：

饼图显示了蛋白注释与筛选的程度，用以区分人类 E3 连接酶的催化和非催化组分

为了验证整理过程的可靠性，研究人员为每个蛋白定义了基于其在不同来源数据集中出现频次的共识评分。结果显示，HECT 类和 RBR 类 E3 连接酶在数据集中高度一致（共识评分 ≥ 0.6，橙色和紫色柱），而 RING 类（绿色柱）共识评分分布较广，显示出注释上的挑战，如下图：

所有注释蛋白类别的共识评分分布反映了跨数据集对 E3 催化组分的一致性

通过这一方法，研究人员最大限度地减少了假阳性和真阴性，纳入了高可信度的催化活性 E3，同时考虑了伪 E3 及未经过催化活性验证的其他 E3，从而对人类 E3 连接酶组的完整性提供了详细评估。

②人类 E3 连接酶的功能分化

为了评估人类 E3 连接酶的功能，研究人员进行了 UPS 基因的 CRISPR-Cas9 缺失筛选，以细胞活力作为主要表型。结果显示，共识别出 53 个催化型和 32 个非催化型 E3 组分对于细胞活力至关重要，如下图：

火山图显示 CRISPR 筛选中 E3 连接酶的关键基因分析结果

对 53 个关键 E3 的 GO 分析显示，其在核成分以及 DNA 损伤、复制和修复过程中显著富集，如下图，表明它们在维持基因组完整性和细胞核调控方面的核心作用，这些结果揭示了对细胞生存至关重要的 E3 组分。

对必需催化型 E3 的 GO 富集分析结果

*
*

利用 Metascape 对 13 个 E3 家族进行 GO 富集分析，并通过 Cytoscape 可视化网络。结果显示，不同家族在底物选择、细胞定位和催化功能上具有明显分工，如下图。例如，RBR 家族成员 RNF14、RNF144A 和 PRKN 对 K6-linked 泛素具有特异性。K6-linked 链可标记停滞的 RNA-蛋白交联复合物（RNF14）、用于激活干扰素信号的 DNA 感应适配器 STING（RNF144A）以及受损线粒体以便清除（PRKN）。类似地，TRIM E3s（RING5）显著富集于抗病毒先天免疫反应中，它们调控细胞中模式识别受体活性，如 RIG-1 和 MDA5 介导的反应。

热图显示所有功能簇及对应家族特异性富集的 E3

④人类 E3 连接酶的可成药性图谱

为了探索基于近距离作用的潜在治疗途径，研究人员将已知的蛋白降解靶向嵌合体（PROTAC）和 E3 结合子衍生的现有 E3 操作位映射到各个 E3 及其家族。目前，仅有 16 个蛋白（9 个催化型 E3 和 7 个适配器）可被现有 E3 操作位直接靶向。已设计的 E3 操作位大多针对适配器蛋白（如 VHL、CRBN），而直接靶向催化型 E3 的仅极少数（如 XIAP、MDM2/4/7、BIRC2/3/7）。

利用该研究的人类 E3 连接酶进行最近邻分析，发现 5 个高度相关蛋白（BIRC8、RN166/181/141 和 UBR2），如下图：

由于它们具有高度结构相似性（通常为同源蛋白），现有 E3 操作位可被重新利用来靶向这些蛋白。映射小分子 E3 结合子使研究人员获得潜在的化合物集合，可靶向另外 25 个 E3 和 15 个非催化成分，从而发现未开发的靶点，为 E3 操作位的理性设计提供先导化合物开发途径，如下图：

多尺度框架为复杂生物系统的解析提供利器

在机器学习领域，多尺度框架（multi-scale framework）指的是一种能够在不同抽象层次或不同特征尺度上处理数据的建模方法或分析策略。它并不是固定的算法，而是一种设计思想，用于整合局部与全局信息、粗粒度与细粒度特征，从而提高模型的表达能力和泛化能力。

多尺度分类框架的价值，并不局限于对 E3 连接酶家族本身的系统梳理，其更重要的意义在于提供了一种可迁移、可扩展的组学整合方法论范式。这种跨尺度的整合思路，使其天然具备向其他多模态组学数据扩展的能力，为复杂生物系统的系统性解析提供了通用工具。

例如，细胞是生命的基本单位，其功能和命运由复杂的分子网络共同决定。传统的深度学习方法虽在单细胞转录组数据的细胞类型识别中表现良好，但缺乏生物学可解释性。2025 年 10 月 20 日，来自中国国家蛋白质科学中心（北京）、清华大学团队的研究人员提出了一种融合生物先验知识的多尺度可解释深度学习框架 Cell Decoder，实现了从基因、通路到生物过程的分层表征与推理，为单细胞水平上解码细胞类型提供了新的思路。Cell Decoder 通过将蛋白质互作网络、基因-通路映射及通路层级关系嵌入图神经网络架构，构建出跨尺度的生物知识图谱。在七个公开单细胞数据集的人体和小鼠样本上，研究团队对 Cell Decoder 与 9 种主流方法进行了系统评测。结果显示，Cell Decoder 在预测准确率 (0.87) 与 Macro F1 (0.81) 上均居首位，且在存在噪声扰动、细胞类型不平衡及跨批次分布偏移等复杂情形下仍保持稳定性能。\
论文标题：Cell Decoder: decoding cell identity with multi-scale explainable deep learning\
论文地址：

https://link.springer.com/article/10.1186/s13059-025-03832-y

从更长远的视角来看，多尺度框架可以进一步与空间蛋白组学数据、小分子药物库及化学空间信息等相结合，从而打通基础生物学研究、疾病机制解析与转化应用之间的数据壁垒。随着多组学数据持续积累，这一框架有望在生命科学研究与生物医药创新中发挥越来越重要的支撑作用。

参考文献：
\
1.https://www.nature.com/articles/s41467-025-67450-9
\
2.https://blog.csdn.net/qazplm12_3/article/details/153948711
\
3.https://link.springer.com/article/10.1186/s13059-025-03832-y

在这个被大模型和智能体（Agent）疯狂重塑的年份，我们不得不承认一个残酷的事实：传统的边缘计算叙事，正在失效。

当算力从中心有序下沉，当 AI Agent 开始接管终端决策，边缘计算不再只是网络的延伸，而正在成为智能的前沿阵地。谁还停留在旧叙事中，谁又真正拿到了通往下一个十年的船票，答案正在迅速分化。

基于这样的行业背景，边缘计算社区正式启动「2026 中国边缘计算企业 20 强」榜单评选。这不仅是一份年度名单，更是一场在技术代际更迭下的行业校准。

榜单背景

自 2019 年起，边缘计算社区已连续六年发布「中国边缘计算企业 20 强」榜单，累计吸引 800 余家产业链企业参与评选，覆盖边缘云、边缘一体机、边缘 AI、5G MEC 等核心领域。

过去六年中，该榜单全网累计传播曝光量突破 3500 万次（清博大数据舆情统计），不仅持续为行业树立技术与商业标杆，也逐步成为企业扩大市场影响力、获取生态与产业资源的重要入口。

当边缘计算进入 “边缘 × AI × 智能体” 的新阶段，我们认为：这份榜单，也必须随技术代际一起升级。

从“连接”到“智算”

回望过去两年，边缘计算的演进速度远超预期。

如果说 2024 年行业仍在聚焦边缘盒子、网关与连接能力，那么到了 2025 年底，只谈连接、不谈推理的产品，已经很难再获得市场认可。

大模型正在以前所未有的速度“瘦身”并下沉至边缘侧：从手机、PC，到工业控制器与现场设备，越来越多的终端被要求具备本地推理与自主决策能力。

边缘计算正在从“管道”，演进为 AI 的“触角”。当然，这并不意味着所有传统边缘计算企业都会被淘汰。但可以确定的是：

以“连接能力”为核心竞争力的边缘产品，正在快速失去议价权。

智能体爆发，边缘侧的“寒武纪时刻”

2026 年，或将成为边缘智能体（Edge Agents）走向规模化应用的起点。所谓边缘智能体，并非简单的模型端侧部署，而是指在受限算力、弱网络甚至离线条件下，仍具备自主感知、规划与执行能力的边缘决策单元。

未来的边缘计算竞争，将不再取决于硬件参数，而在于：

• 谁能让大模型在边缘侧稳定运行
• 谁能在毫秒级延迟内完成复杂决策
• 谁能在算力、算法与网络之间实现系统级优化

这不仅是技术升级，更是一轮生态重构。

寻找 2026 年的“边缘脊梁”

正是在这样的行业变局之下，我们启动「2026 中国边缘计算企业 20 强」评选。

我们要寻找的，不是停留在历史成绩上的老牌玩家，也不是只会包装概念的“PPT 公司”，而是那些真正进入 “边缘 × AI”深水区 的企业：

• 成功将 7B、14B 等模型量化并部署到边缘端的技术实践者
• 用边缘智能体解决真实、碎片化场景问题的实干团队
• 在算力、算法与网络协同中实现突破的破局者

他们，才是真正决定边缘计算下一个十年走向的力量。

评选标准与参选要求

参选条件

• 在边缘计算领域具备成熟的技术解决方案与商业化落地案例；
• 拥有核心技术壁垒（如边缘芯片、算法优化、异构计算等）或独特生态资源；

• 2026 年新增重点：展示边缘计算与 AI 大模型的融合实践（如优化 AI 推理效率、隐私计算、联邦学习等），以及算力。
  

  评分机制

• 线上投票（30%）：公众通过官方渠道为心仪企业投票；

• 专家评审（70%）：从以下四大维度综合打分：

  • 技术领先性（35%）
  • 商业落地（30%）
  • 边缘×AI创新（25%）
  • 生态贡献（10%）

上榜权益

• 品牌升维：通过头部合作伙伴渠道全域曝光，覆盖 10 万+ 开发者社区；
• 商机裂变：优先对接甲方订单资源，2024 年某上榜企业通过生态合作斩获 800 万项目订单；
• 权威认证：榜单企业客户咨询量平均提升 120%（历史数据）；
• 生态赋能：优先加入“边缘计算产业图谱”。

特别提醒

独行者快，众行者远：在 AI 巨头定义规则的战场上，边缘计算企业唯有被看见，才有机会被选择。技术不应被埋没，真正的能力值得被记录。边缘计算的下一个十年，不属于参数最多的人，而属于最懂场景、最懂约束、也最懂 AI 如何落地的人。

边缘计算社区
2026年1月21日