1. 引言

流行病学监测是公共卫生的基石之一。 Régis Júnior等人（2026）将其定义为一个针对健康事件的持续性数据收集、分析、解读和传播系统——该功能的有效性在很大程度上取决于信息系统的质量、数据分析能力以及不同医疗层级之间的协调。 在新冠疫情期间，这一职能的战略重要性已毋庸置疑：世界卫生组织（2021）的记录显示，拥有更健全监测系统的国家始终表现得更好，而监测能力方面的区域差异则直接导致了应对措施的不一致，并在发病率和死亡率方面产生了可测量的差异。

尽管医疗系统如今能够收集海量的标准化临床数据，但挑战在于如何将这些数据转化为及时且可付诸行动的洞见。传统的流行病学报告往往依赖于人工分析和定制数据库查询，由此产生的延迟可能会阻碍公共卫生部门的快速响应。

EpInsights通过整合 InterSystems IRIS for Health、嵌入式 Python 临床向量化技术、IRIS Vector Search 以及 LangChain4j 对话式智能助手，填补了这一空白。 该平台使流行病学家和卫生管理者能够提出自然语言问题，并即时获得基于真实FHIR数据的地理空间热力图、区域排名、相似聚类检测以及AI生成的建议，所有结果均在数秒内呈现。

2. 架构概述

EpInsights 采用三层架构，各层职责划分明确。

InterSystems 编程竞赛： https://openexchange.intersystems.com/contest/46上的 FHIR 人工智能代理 。 

代码： https://github.com/eungi-hong/central-park

演示： https://triagepark.78-47-167-98.sslip.io/ 

就诊的前十分钟总是千篇一律：采集病史、调取病历、核对用药情况、判断病情紧急程度。Triage Park通过一支完全在 InterSystems IRIS for Health 内部运行的 AI 代理团队来完成这一初步筛查，并向临床医生提供一份附有依据且可解释的交接报告。 大多数“AI分诊”演示所忽略的部分，恰恰是我们最重视的：安全性。这里的所有安全机制都是确定性的且单向的。系统只能提高病例的紧急程度，绝不会降低，因此患者的安全绝不会取决于模型是否判断正确。

代理、检查与技能

该平台经过刻意划分：需要大量判断的工作以代理的形式运行（即使用工具的循环，负责决策和执行），安全关键型工作以确定性检查的形式运行（基于规则，而非大型语言模型），其余部分则专注于大型语言模型技能

InterSystems IRIS® 数据平台、InterSystems IRIS^®for Health^™ 以及InterSystems Health Connect™的2026.2版本现已正式发布（GA）。这是一个持续交付（CD）版本。

版本亮点：

• SQL 和数据管理增强功能：InterSystemsSQL 现已在存储过程中支持通用表表达式（CTE）。此版本还改进了表分区功能，包括优化了 ALTER TABLE ... MOVE PARTITION 的行为，并修复了包含大写字母字段的分区键问题。
• 商业智能增强：InterSystems IRIS BI 现可在定义分析模型时利用 SQL外键关系，从而更轻松地对通过关系型结构表达的运营数据进行建模。
• 数据库操作改进：cvendian实用程序（用于在 big-endian 和 little-endian 平台之间迁移数据库）已得到优化，转换速度更快——某些情况下速度最高可达原来的两倍——并且在转换中断时，错误报告功能也得到了改进。
• 互操作性用户体验改进：全新的互操作性用户界面持续完善，在生产配置、消息查看器和消息搜索、可视化跟踪、DTL 和 BPL 编辑器、模式查看器以及规则编辑器等方面均进行了优化。 这些功能对现有客户仍为可选功能，我们鼓励您尝试新体验，并将反馈发送至：InteropUXFeedback@intersystems.com

摘要

这一切始于我乘火车去看望父母的途中，当时我正和隔壁包厢的一位邻居聊天。像往常一样，话题转到了科技上，她抛出了一个非常具体的问题：“ChatGPT 能用来分析人类基因组吗？”我对它能否完成如此复杂的事情持高度怀疑态度。 但这个问题始终萦绕不去，深深扎根于我的脑海。等我踏进家门时，我的怀疑已经转变为一种挑战。 虽然手头没有基因组测序数据集，但我确实想看看标准的ChatGPT能否利用PyProd包从零开始构建一个可运行的互操作性生产环境。况且，这还能让我有机会参与“从构想到应用”社区赏金计划的第一轮，实现第三个创意。

在即将发布的 2026.2 版本（目前已开放预览）中，我们将新增对 FHIR 读取操作中一种特定情况的支持。

该功能针对二进制资源 ——当通过 GET 请求获取具有特定 MIME 类型的二进制资源，且请求的 Accept 头也包含相同的 MIME 类型时，返回的内容将不是 FHIR 资源（JSON）本身，而是实际的二进制内容。详情请参阅FHIR 文档。

随着 v2026.1 版本的发布，HL7 FHIR 引入了一项非常重要的功能——支持SMART on FHIR v2 的细粒度作用域。

这使您能够对 FHIR 存储库中数据的访问权限进行更严格、更精确的控制。

这项新功能的一部分是拒绝不符合范围的请求，但更有趣的功能是能够根据提供的范围过滤结果。

在 v2026.2 版本（目前作为开发者预览版提供）中，我们新增了一项功能，可协助完成 FHIR 端点的 SMART/OAuth 授权——在受众值验证方面提供了更多开箱即用的灵活性。

在 v2026.2 版本（现已开放预览）中，我最期待的新功能之一就是“FHIR 资源管理器”。

作为 InterSystems FHIR 服务器的一部分，这项新功能允许用户通过友好且直观的用户界面探索 FHIR 数据：该界面能够构建（可能较为复杂的）FHIR 搜索 URL，将其发送至您的 FHIR 服务器（实际上是任何 FHIR 服务器……）进行查询，并显示查询结果。

以下是一个简单的操作流程：

在使用 Studio 进行多年开发之后，我将分享一些我认为 VS Code 非常实用的功能。

对我来说，最明显的一点是，即使因任何原因断开网络连接，它也不会突然崩溃，从而避免了被迫重启 Studio 并面临丢失宝贵代码的风险。我还发现 VS Code 比 Studio 快得多，而且用户界面也更好，有多种方式可以按个人喜好进行自定义。

在法国，我们习惯用农场动物的名字来命名开发和测试环境。要将 VS Code 的配色调整为与该动物的颜色相匹配，其实非常简单。 例如，我将“Grenouille”（青蛙）设为绿色，“Poule”（鸡）设为橙色，“Boeuf”（牛）设为棕色。 这些是我们分支和主开发环境。可以通过Peacock 扩展设置颜色，并在工作区文件中进行配置：Ctrl + Shift + P -> 打开工作区设置（json）。这种设置让你在同时运行多个 VS Code 实例时，能够轻松识别当前正在操作的环境。 

我相信还可以进行更多自定义设置，但我还没来得及尝试。

这些工作区文件的另一个很酷的功能是，你可以更改要处理的代码的默认文件夹。 当存在大量你不感兴趣的代码时，这尤其有用。一个实际的例子是直接访问某个文件夹，例如，你可以为特定环境创建一个工作区文件，使其直接指向 Region/FRXX/Convert 文件夹。 

现在，当你点击工作区链接（.

2026 年 7 月 20 日，中国 北京 —— 为全球超过 10 亿份健康记录提供支持的创新数据技术提供商InterSystems近日宣布，在2026年 《2026 Gartner® Magic Quadrant™：企业级电子健康档案》中位列“领导者（Leader）”。

要成功构建和部署人工智能代理以应对医疗保健领域的各种用例，关键在于高质量的数据和API，以及有效的治理与管理。 InterSystems IRIS FHIR 服务器不仅能满足上述所有需求，还精通 Python、向量搜索和互操作性。结合强大的大型语言模型（LLM），患者、医生、护理人员和管理者将能够利用最先进的技术来改善个人健康和公共卫生。

本文利用 InterSystems IRIS FHIR 存储库、FHIR API、嵌入式 Python 以及向量搜索作为数据服务和 API，从而使部署在 Ollama 上的 LLM lhama3 能够处理以下用例：临床摘要、 通过API使用自然语言探索FHIR数据、AI生成的患者临床指标图形分析，以及利用向量搜索进行病例相似性比较等用例。

安装

1. 访问 Open Exchange 并查找应用程序 fhir assistant（https://openexchange.intersystems.com/package/fhir-assistant）

2. 将代码库克隆/通过 Git 拉取到任意本地目录：

$ git clone https://github.com/yurimarx/fhir-assistant.git

3.

InterSystems IRIS 社区版 HAOS 插件

在 Home Assistant 中以插件形式运行 InterSystems IRIS。在你可能以“这只是噱头”为由忽略本文之前，我希望你能退一步，看看使用这个平台启动基于 IRIS 的应用程序是多么简单。  如果你浏览 Open Exchange，会发现成百上千款值得运行的应用程序，但它们基本上被晾在一边，沦为“Gitware”（仅存于代码库中），若想运行它们，你还得在笔记本电脑上与 containerd 或 Docker 展开一番较量。  如今，只需一个简单的 Git 仓库和一份规范，你就能在 IRIS 上构建应用，并通过应用市场将其发布，而终端用户几乎无需费心。  将其与 Ollama 以及 LLM/LAM 实现并行运行，将 IRIS 中的任何内容作为传感器公开，或在你的 IRIS 应用中暴露交互端点，以便与连接到 HAOS 的任何设备进行交互。 想通过轻按物理开关或借助辅助 AI 重启 IRIS 生产环境吗？你可以使用这个插件，或者开发自己的插件，与家庭自动化极客们并肩协作。

项目链接

• GitHub：https://github.com/vinogrannia/fhir-patient-snapshot-agent
• 在线演示：https://fhir-patient-snapshot-agent.onrender.com/
• YouTube 演示：https://youtu.be/Hsu10Nnujng

概述

FHIR 患者快照代理（FHIR Patient Snapshot Agent）是一款专为 InterSystems AI 代理和 FHIR 编程竞赛开发的小型开源应用程序。

该项目实现了建议的“智能患者摘要生成器”构想：它检索所选患者的结构化 FHIR 资源，并生成一份简明扼要、针对特定角色的患者摘要。

其目的并非进行诊断或推荐治疗方案。该代理仅作为摘要生成助手，所有生成的内容都必须与源FHIR数据进行核对验证。

InterSystems IRIS for Health 的应用方式

该应用程序使用 InterSystems IRIS for Health 作为 FHIR 互操作性层。

在本地部署环境中，IRIS for Health 提供了一个 FHIR R4 API。Python 应用程序通过查询该 API 来获取与患者相关的资源，包括：

• 患者
• 病情
• 用药请求
• 过敏与不耐受
• 观察
• 就诊
• 护理计划

该 Python 应用程序不会直接读取本地临床文件。

在我的第一篇文章中，我介绍了 FHIR 患者快照代理的基础版本：这是一个基于 Streamlit 和 Python 的应用程序，它从 InterSystems IRIS for Health 中检索 FHIR 资源，并利用大型语言模型（LLM）生成简明扼要的患者摘要。

本文作为后续文章，将介绍我是如何通过添加两项针对 InterSystems 的功能来扩展该项目的：

• 源上下文向量搜索
• 用于 IRIS 兼容审查的嵌入式 Python 组件

目标是让该项目作为临床摘要原型更具实用性，同时保持设计足够精简，以便于理解和复现。

项目回顾

FHIR 患者快照代理（FHIR Patient Snapshot Agent）是一款基于人工智能的 FHIR 患者数据摘要工具。

该应用程序可检索所选患者的结构化资源：

• 患者
• 病情
• 用药请求
• 过敏与不耐受
• 观察
• 就诊
• 护理计划

Python 层将这些资源整合为一个紧凑的患者背景。用户随后可以生成以下任一内容：

• 确定性摘要，或
• 由大型语言模型（LLM）生成的针对特定角色的摘要

该 LLM 集成通过兼容 OpenAI 的聊天补全 API 使用 Nebius Token Factory。演示中使用的模型为：

该项目为开源项目：

影子服务器的过滤器中可以提取global的新值和旧值，想通过类属性或者表字段，按顺序转换成表数据，但是global值顺序和表字段顺序核对后发现不一致，无法正常转换，怎么才能将global值转换成表，d ClassMethod GlobalToList(classname As %String, globalValue As %String) As %Status { Set sc = $$$OK #; Try { // 1. 获取编译类定义 Set clsCompiled = ##class(%Dictionary.CompiledClass).%OpenId(classname) If '$IsObject(clsCompiled) { Set sc = $$$ERROR($$$GeneralError, "类定义不存在") Quit } // 2. 获取属性数量（按顺序） Set propCount = clsCompiled.Properties.Count() If propCount = 0 { Write "类无属性", ! Quit } // 3. 遍历属性并解析 Write "从 Global 值解析字段：", propCount, ! For i = 1:1:propCount { Set prop = clsCompiled.Properties.

大家好， 

我创建了一个简短的演示和参考代码库，展示了如何将 Auth0 配置为 InterSystems IRIS FHIR 服务器的 OAuth 提供商，以及如何从 Python Flask 应用程序调用受保护的 FHIR 资源。 

以下链接包含一段视频演示以及一个 GitHub 仓库，其中包含视频中使用的示例应用程序 

链接 

视频演示： 

GitHub 仓库：https://github.com/MarshyKid/iris-fhir-oauth-demo

在问诊前，人工智能助手会先阅读FHIR患者病历，根据已掌握的信息提出恰当的问题，识别关键的警示信号，并将分析结果反馈给医生——这样医生就能做好充分准备。

该项目灵感源自InterSystems编程大赛“FHIR人工智能代理”中建议的第10项任务（对话式FHIR分诊助手）。

解决的医疗痛点

在患者走进诊室之前，一个关键的疏漏已经发生：没有人阅读过他们的病史。医生只有15分钟的时间。患者不得不第三次向医生重复自己的病情、用药情况和过敏史——这已经是今年第三次了。 诸如华法林治疗期间的出血、心力衰竭伴随的胸痛、抑郁症伴随的自杀意念等“危险信号”，要么直到为时已晚才被询问，要么根本未被提及。

这并非技术上的缺口。 数据是存在的。它们存储在分布于不同系统中的数据仓库中，其中包含患者的纵向病历，涵盖病情、用药情况、实验室检查结果、过敏史及就诊史。真正的缺口在于诊疗现场的智能辅助——一个能在就诊前阅读病历、根据已知信息提出恰当问题，并将分析结果反馈给医生，使医生做好充分准备的智能助手。

在技术示例应用TriageAide中，我们以具体场景为切入点，探索如何将 InterSystems IRIS FHIR 服务器、模型上下文协议（MCP）和生成式人工智能（Generative AI）结合使用。该应用是一款人工智能助手，旨在优化患者接诊流程和临床交接工作。

大多数“AI 代理 + FHIR”项目最终都呈现出相同的架构：这边是一个 FHIR 服务器，那边是一个向量数据库，中间则是一个 Python 服务，其职责是调用嵌入 API、在两端之间转换浮点数数组，并保持两个数据存储库的同步。 三个活动组件、两次网络跳转，以及一个你从此永久拥有的嵌入式客户端。

Triage Park：我们 提交给InterSystems 编程大赛:FHIR AI Agent的参赛作品，完全没有这些复杂结构。该代理从不计算嵌入向量，也从未导入过 OpenAI 嵌入向量客户端。 没有向量数据库。它将原始文本发送给 IRIS，剩下的工作由 IRIS 完成：它在服务器端计算嵌入向量，并通过针对与 FHIR 存储库位于同一数据库*中的表执行单条 VECTOR_COSINE SQL 语句来响应检索请求。

这就是 IRIS for Health 的“AI Hub”模式，一旦我采用该模式，我自己的代码中整整一层就消失了。以下是它的具体工作原理。

问题在于：分诊人员需要快速获得指导方针

Triage Park 是一款对话式分诊助手。患者描述症状（“我上楼梯时胸口发紧”），由大型语言模型（LLM）支持的助手会读取患者的真实 FHIR 病历，并生成分诊决策：自我护理 / 看全科医生 / 急诊护理 / 急诊科，同时附上依据说明。

“引用依据”(Cited rationale)是关键所在。

在开始开发“智能出院导航器(Smart Discharge Navigator)”时，我遇到了一个常见的难题：FHIR 数据以 JSON 数据包的形式存储，但我所需的分析需要将多个资源进行关联，而这正是 SQL 所擅长的领域。

InterSystems FHIR SQL Builder 彻底解决了这一问题。我无需在应用程序代码中解析 JSON 数据包，而是能够直接在 IRIS for Health 中针对 FHIR 资源投影编写纯 SQL 语句。本文将详细介绍我如何利用该工具构建了该应用程序核心——基于人群的再入院风险评分引擎。

临床问题

30 天内的医院再入院是医疗保健领域成本最高且本可预防的问题之一，每年给美国医疗系统造成 170 亿美元的损失。挑战并不在于事后识别风险因素，而在于在恰当的时机——即患者出院前——及时发现这些风险因素。

为了评估再入院风险，我需要针对每位患者同时回答以下五个问题：

• 该患者近期住院过几次？
• 该患者是否患有多种活动性慢性病？
• 该患者目前是否正在服用五种或更多种药物（多药联用）？
• 病历中是否有任何异常实验室检查结果？
• 是否有缺席随访的情况？

如果通过 Python 解析 FHIR 数据包来回答这五个问题，不仅速度慢，而且容易出错。而 FHIR SQL Builder 则让这一切变得简单明了。

摘要

常见表表达式（CTE）为在SQL语句中定义可重用的中间结果集提供了一个结构化的框架。InterSystems IRIS通过WITH子句实现CTE，在与IRIS基于成本的优化器完全集成的情况下，既能实现更清晰的查询构建，又能支持模块化的分析处理。

本文探讨了 InterSystems IRIS 中 CTE 的语义，解释了其与查询优化的交互关系，讨论了合适的部署场景，并提供了可执行的示例，以说明生产环境中的实用模式。

1. 引言

复杂的 SQL 工作负载通常需要多个逻辑处理阶段（例如过滤、聚合、数据增强和投影）。如果没有抽象机制，这些操作往往会导致查询结构深度嵌套，难以理解和维护。

常见表表达式（CTE）通过允许开发人员定义可在单个 SQL 语句中求值的命名查询组件，解决了这一问题。

在 InterSystems IRIS 中，CTE 通过 SQL 的 WITH 子句实现，并作为逻辑查询表达式运行，与周围的语句一同进行优化 [1]。

2. InterSystems IRIS 中的常见表表达式

2.1 定义

公共表表达式（Common Table Expression）是在 SELECT 语句之前声明的命名子查询：

WITH PersonSubset AS (
  SELECT ID, Name, Age
  FROM Sample.Person
)
SELECT Name
FROM PersonSubset

在 v2026.1 版本中，我们为您的 FHIR 端点引入了更强大且符合实际安全需求的授权支持。

这是通过使用SMART on FHIR v2 的细粒度作用域来实现的。

重点——并非 SMART 本身，而是其细粒度作用域；简单易上手的示例

太长不读版（TL;DR:）:本文演示了如何利用iris-vector-graph包，完全在 InterSystems IRIS 环境中实现 GraphRAG 风格的混合检索——该方法结合了向量相似度、图遍历和全文搜索。 我们通过一个欺诈检测场景，展示了图模式如何揭示仅靠向量搜索无法发现的问题。

为何欺诈检测需要图技术

每年，企业和消费者因欺诈损失数十亿美元。仅在2024年，消费者报告的损失就达125亿美元——同比增幅达25%。 现代欺诈之所以难以被发现，是因为欺诈者很少单独行动。他们通过有组织的网络运作，实施协调一致的骗局，利用我们无法察觉看似无关的交易之间存在关联这一弱点。

举个简单的例子：从账户 A 转账至账户 B 的单笔交易看起来完全正常。金额合理，时间点符合常规，且两个账户均未被标记为可疑。传统的基于规则的系统，甚至那些孤立分析交易的机器学习模型，都会毫不犹豫地批准这笔交易。

但如果我们能看到全局呢？

同一笔交易其实是环形模式的一部分——资金在循环流动，每一步都会被截留一小部分。这是一种典型的洗钱结构，对于任何不分析交易关联性的系统来说，都是隐形的。

这一洞见——即欺诈隐藏在关联关系中，而非单个记录中——正是图数据库成为欺诈检测不可或缺工具的原因。

各位社区成员，欢迎大家订阅InterSystems 学习服务通讯，获取与您的职位和目标相关的最新内容，保持领先！

了解如何定制您的学习之旅！👇

我很高兴与大家分享FHIR Agent Studio 的演示视频，该视频现已在 YouTube 上发布。

FHIR Agent Studio 演示视频

https://www.youtube.com/watch?v=vktfq_kvNnk

FHIR Agent Studio 将 AI Agent与 FHIR、InterSystems IRIS、Vector Search 以及大型语言模型相结合，向开发者展示如何探索、构建和测试由Agent驱动的医疗保健工作流。

您还可以在此处查看更多信息：

介绍文章：https://community.intersystems.com/post/introducing-fhir-agent-studio-ai-agents-fhir-intersystems-iris

GitHub 代码库：https://github.com/SeanConnelly/ai-studio-for-fhir

Open Exchange 页面：https://openexchange.intersystems.com/package/FHIR-Agent-Studio

我很高兴地告诉大家FHIR Agent Studio现已在 InterSystems Developer Cloud 上作为在线托管演示运行—— 无需安装，无需配置，只需在浏览器中打开即可。

FHIR Agent Studio 是一个开发者门户，用于在单一的 InterSystems IRIS for Health 后端上 构建、运行和检查面向 FHIR 工作流的 AI代理。每个 代理都是一个小型临床工作流，您可以从左到右阅读其流程：

Trigger -> Evidence (FHIR / SQL / Vector Search) -> Agent (LLM) -> Action (draft FHIR) -> Trace

该平台随附十二个可运行的代理，基于一个包含约 1,000 名患者和 20,000 多个资源的合成 FHIR 存储库，此外还提供一个面向临床医生的应用程序和一个面向患者的手机 应用程序，均运行在同一后端上。每次运行的每个步骤均可追溯。

立即试用（无需登录）

应用程序界面已开放——只需点击即可探索：

v2026.1 刚刚正式发布，其中我最期待使用的一项功能就是DTL 说明功能。

该功能允许您选择一个数据转换，只需点击一下按钮，即可获得该转换的人类可读描述（您还可以将其作为 DTL 描述的基础）。

对于复杂的 DTL，尤其是那些并非由您亲自编写，或者虽然由您编写但已时隔许久的 DTL，该功能将帮助您快速清晰地了解其工作原理。

对于尚未使用过“安全钱包”（Security Wallet）功能 的用户（有关此功能的更多信息，请参阅这些文档、这段 4 分钟视频以及这段 36 分钟视频），请注意：您需要使用该功能来配置DTL 解释器的OpenAI 许可证 API 密钥。

有关此功能的更多详细信息，请参阅此处的文档。

另请参阅@Aya Heshmat的帖子，其中包含一段视频（链接直接跳转至展示 DTL Explainer 的时间点），介绍了新互操作性 UI 中的所有最新功能。

此外，还可观看@Julie Ma 提供的这段更详细的视频演示与讲解。

这是将生成式人工智能（GenAI）功能整合到 InterSystems 产品中的一个示例。

人工智能将改变医疗保健行业，但前提是临床医生能够信任它，而开发人员 在构建它时无需每次都从头开始重新设计基础架构。 FHIR Agent Studio 正是我 为实现这两点所做的尝试：它是一个平台，可以利用可重用的构建 模块为 FHIR 工作流构建 AI 代理，在真实的 InterSystems IRIS for Health 后端上运行它们，并精确 检查每个代理在每个步骤中执行了哪些操作。

这是我参加 InterSystems FHIR AI Agent 竞赛的参赛作品，它附带了 十二个可运行的代理，这些代理运行在一个包含约 1,000 名患者和 20,000 个资源的合成 FHIR 存储库上。 我的目标是打造一个“工作室”而非单一的演示程序：在这里，您可以 设计、运行和检查多个代理，进而构建自己的代理。所有操作均在单个 容器中运行，仅需一条命令，且无需 API 密钥。

克隆该仓库并运行 docker compose up --build。然后打开引导式演示，运行其中的任意一个代理。 每个步骤都可供您详细查看。

从引导式演示开始

如果你只能做一件事，那就打开引导式演示。它带你游览全部十二个代理， 每个代理都配有通俗易懂的说明、一个直接跳转到相应界面的“试一试”链接， 以及关于注意事项的提示。即使你对该项目一无所知， 也能在几分钟内探索其全部内容。

我们有一则令人振奋的消息要分享！🎉

2026年6月30日(美国东部时间）， Global Masters将迁移至全新平台，届时 将带来焕然一新的使用体验以及一些大家期待已久的功能。

最棒的是？您辛勤积累的所有进度都将随您一同迁移。您的积分、徽章和奖励记录都将得以保留，同时我们还将恢复“等级”系统——这是社区用户呼声最高的功能之一。✨

所有正在进行的“全球大师”挑战都将在新平台上继续，因此您将能够无缝衔接，继续您的征程。

我需要做什么？