MONAI Model Bundle 深度解析：Config Item、Config Parser 与 Bundle 脚本实战指南

MONAI Model Bundle 深度解析：Config Item、Config Parser 与 Bundle 脚本实战指南

【免费下载链接】MONAIAI Toolkit for Healthcare Imaging项目地址: https://gitcode.com/GitHub_Trending/mo/MONAI

Model Bundle 是 MONAI（AI Toolkit for Healthcare Imaging）中用于封装"模型 + 配置 + 元数据"的一整套标准化方案：它把网络结构、数据预处理、训练/推理流程和实验跟踪配置统统写成可解析、可引用、可覆盖的 JSON/YAML 配置，从而让同一个模型可以一键下载、一键训练、一键推理、一键导出部署格式。本篇指南以仓库中的 bundle.rst 为核心，系统讲解monai.bundle模块的四大组成部分——Config Item（配置项）、Reference Resolver（引用解析器）、Config Parser（配置解析器）与 Scripts（命令行脚本），并结合 monai/bundle 下的源码与 tests/bundle 中的测试用例，带读者掌握从编写配置、解析实例化到 CLI 落地部署的完整链路。读完本文，你将能够读懂任意 MONAI Bundle 的配置文件、独立编写可运行的 bundle 配置，并用命令行完成下载、验证、运行、导出等全部日常操作。

Model Bundle 整体架构：从配置到可运行工作流

monai.bundle模块位于 monai/bundle，其核心设计思想是"配置即代码"。整个解析链路可以概括为：

配置文件(JSON/YAML) → ConfigParser → ConfigItem / ConfigComponent / ConfigExpression → ReferenceResolver（解析 @ 引用与 $ 表达式）→ 实例化对象 / 执行表达式 → BundleWorkflow（ConfigWorkflow / PythonicWorkflow）→ initialize / run / finalize

• config_item.py 定义了配置项的基础数据结构：Instantiable、ComponentLocator、ConfigItem、ConfigComponent、ConfigExpression；
• reference_resolver.py 维护一组ConfigItem并解析它们之间的@id引用关系；
• config_parser.py 是主入口，负责读取文件、递归遍历、生成唯一 ID 并协调上述两者；
• workflows.py 提供BundleWorkflow、ConfigWorkflow、PythonicWorkflow三个工作流抽象，定义initialize/run/finalize生命周期；
• scripts.py 通过main.py 暴露为python -m monai.bundle <command>形式的 CLI。

从 monai/bundle/init.py 可以看到，模块对外统一导出上述全部类与函数，用户既可以from monai.bundle import ConfigParser以 Python API 方式使用，也可以通过python -m monai.bundle以命令行方式使用。

Config Item：配置项的四种形态

ConfigItem是所有配置项的共同基类。它"可以有一个字符串 ID 以便其他配置项引用它"，内部通过config属性持有配置对象，并提供了get_id()、get_config()、update_config()三个核心方法（config_item.py）。update_config()的典型用途是在运行时修改初始配置内容——测试用例 test_config_item.py 中先实例化ConfigItem(config={"lr": 0.001})，随后update_config把学习率改为0.0001再读回，验证了"配置可在解析前被动态改写"这一特性。

基于ConfigItem，MONAI 派生出三种具有不同语义的配置项，它们共同构成 bundle 配置的语法基础：

ConfigComponent：可实例化的类/函数组件

ConfigComponent用"字符串为键的字典"表示一个类或函数组件并支持实例化。其判定规则非常简单：只要配置内容是Mapping且包含"_target_"键，就被视为一个待实例化的组件（is_instantiable，见 config_item.py）。除普通参数外，目前定义了以下五个特殊键（均以下划线包围，见non_arg_keys，config_item.py）：

文档中给出的最小示例（config_item.py）展示了如何用ComponentLocator+ConfigComponent手写实例化一个LoadImaged变换：

from monai.bundle import ComponentLocator, ConfigComponent locator = ComponentLocator(excludes=["modules_to_exclude"]) config = { "_target_": "LoadImaged", "keys": ["image", "label"] } configer = ConfigComponent(config, id="test", locator=locator) image_loader = configer.instantiate() print(image_loader) # <monai.transforms.io.dictionary.LoadImaged object at 0x...>

测试 test_config_item.py 进一步覆盖了_disabled_为布尔与字符串两种写法、_target_使用完整模块路径"monai.transforms.LoadImaged"、非 MONAI 模块"torch.optim.Adam"、以及_mode_为"callable"时返回functools.partial等场景。

ConfigExpression：以$开头的可执行表达式

ConfigExpression表示一段可执行表达式：任何以$开头的字符串都会被解释为表达式，基于 Python 内建eval()求值（config_item.py）。如果表达式是import语句（如"$import json"、"$from json import dump"），则会执行导入并把模块注入全局命名空间，供后续配置引用。

import monai from monai.bundle import ConfigExpression config = "$monai.__version__" expression = ConfigExpression(config, id="test", globals={"monai": monai}) print(expression.evaluate())

值得注意的实现细节：在run_debug模式下，表达式会进入pdb交互调试；在run_eval被禁用时（config_item.py），表达式不会执行而是原样返回字符串，这是出于安全考虑提供的开关。测试 test_config_item.py 验证了"$monai.data.list_data_collate"这类函数引用、"$lambda x: ..."匿名函数以及带引用变量"$var + 100"的表达式均可正确求值。

Instantiable：统一实例化接口

Instantiable是一个抽象基类（ABC），定义了两个抽象方法：is_disabled()（该对象是否应被跳过实例化）与instantiate()（实例化目标组件并返回实例）。ConfigComponent继承自ConfigItem, Instantiable并实现了这两个方法（config_item.py），从而让"解析配置"与"实例化组件"两个概念解耦——这也是后续ConfigParser能统一处理各类配置项的接口基础。

ComponentLocator：组件名到模块路径的映射

ComponentLocator会扫描 MONAI 包内所有已加载模块，用inspect.getmembers收集类与函数，构建"组件名 → 模块路径"映射表（config_item.py）。get_component_module_name(name)返回目标组件的完整模块名；如果同名组件存在于多个模块，则返回列表并告警提示改用完整路径。构造参数excludes可以排除指定子串的模块（例如排除"metrics"以避免混淆）。这正是配置里写短名"LoadImaged"也能被正确解析为monai.transforms.io.dictionary.LoadImaged的底层机制。

Reference Resolver：@引用与$表达式的解析引擎

ReferenceResolver负责管理一组ConfigItem并解析它们之间的引用（reference_resolver.py）。其核心约定是：配置字符串中以@开头的内容被视为对其它配置项 ID 的引用；由于配置项可能嵌套字典/列表，引用字符串还可以带::分隔符做按键/按索引的子结构寻址，例如"@net::channels"表示net配置项下的channels字段。

解析流程（_resolve_one_item，reference_resolver.py）概括如下：

1. 若该 ID 已解析，直接返回缓存结果；
2. 用waiting_list检测循环引用——测试 test_reference_resolver.py 中{"A": "@B", "B": "@C", "C": "@A"}会在解析时抛出ValueError: detected circular references；
3. 先递归解析所有@引用指向的依赖项（instantiate / evaluate）；
4. 依赖全部就绪后，把引用替换为对应对象，再对当前项实例化或求值，结果缓存在resolved_content。

ReferenceResolver还负责两件看似不起眼但很重要的杂务：

• normalize_id：为向后兼容，把旧的#分隔符统一替换为::（reference_resolver.py），因此配置里写"@training#A"与"@training::A"等价；
• normalize_meta_id：对弃用字段做自动迁移，例如把旧的optional_packages_version替换为required_packages_version并给出告警（reference_resolver.py）。

此外，update_refs_pattern在表达式场景下的处理很巧妙：当"$..."表达式中出现@ref时，会用__local_refs['ref']替换该引用，并把解析后的resolved_content作为globals注入eval()，从而支持"$@training::A + @training::A_B + 1"这类"表达式内引用其它配置项"的写法（参见 test_config_parser.py 的TEST_CASE_5）。

ConfigParser：配置解析的总入口

ConfigParser是整个 bundle 体系的核心类（config_parser.py）。它遍历结构化的配置（嵌套 dict/list），为每一项创建ConfigItem并分配唯一 ID，再通过 ID 提供便捷访问。文档给出的典型工作流只有两步：初始化ConfigParser→ 调用get_parsed_content()：

from monai.bundle import ConfigParser config = { "my_dims": 2, "dims_1": "$@my_dims + 1", "my_xform": {"_target_": "LoadImage"}, "my_net": {"_target_": "BasicUNet", "spatial_dims": "@dims_1", "in_channels": 1, "out_channels": 4}, "trainer": {"_target_": "SupervisedTrainer", "network": "@my_net", "preprocessing": "@my_xform"} } parser = ConfigParser(config) # 解析前读写配置内容（set 必须在 parse 之前） print(parser["my_net"]["in_channels"]) # 1 parser["my_net"]["in_channels"] = 4 # 运行时改为 4 print(parser["my_net"]["in_channels"]) # 实例化网络组件 parser.parse(True) net = parser.get_parsed_content("my_net", instantiate=True) print(net) # 也可以只取配置内容而不实例化 trainer = parser.get_parsed_content("trainer", instantiate=False) print(trainer)

注意my_dims与dims_1展示了两种非组件配置：dims_1是$表达式（值为@my_dims + 1 = 3），而my_net与trainer是_target_组件，且my_net通过"@dims_1"、trainer通过"@my_net"、"@my_xform"建立了引用关系——这三者分别对应表达式求值、组件实例化、引用替换三种解析语义。

ID 寻址语法

ConfigParser.__getitem__/__setitem__把"::"（或旧式"#"）解释为"向嵌套结构深入一层"：字典用字符串键、列表用整数下标。例如"xform::5"表示xform列表的第 6 个元素，"net::channels"表示net字典的channels字段；空字符串""表示整个配置（config_parser.py）。测试 test_config_parser.py 完整覆盖了get、set、__getitem__、__setitem__、嵌套 ID 更新与整数索引等操作。

相对 ID 与宏（macro）

为了简化嵌套配置里的书写，MONAI 支持相对 ID："@#A"表示同一层级下的A，"@##A"表示上一层级的A。解析逻辑在resolve_relative_ids（config_parser.py），测试 test_config_parser.py 中D项里的"@##A"被解析为顶层A，"@#1"指向同层列表索引1，最终求值结果与预期完全一致。

宏（macro）以%开头，用于复用其它配置片段，支持两种形态："%default_net"（本配置内的项）与"%/data/config.json#net"（另一配置文件的子项，路径与 ID 用::或#分隔）。宏替换发生在parse()之前（resolve_macro_and_relative_ids），且不支持递归宏。测试 test_config_parser.py 展示了宏配合相对 ID 与跨文件引用的组合用法。

多配置文件合并与+前缀

load_config_files支持一次加载多个 JSON/YAML 文件并合并：后者覆盖或新增前者；如果键名以+开头（MERGE_KEY，见 utils.py），则对列表采用"追加合并"而非"覆盖"。测试 test_config_parser.py 中，{"key2": [0]}合并{"+key2": [4]}得到[0, 4]，而普通键key1被后者覆盖为1。此外load_config_file在解析时会通过CheckKeyDuplicatesYamlLoader与check_key_duplicates检测 JSON/YAML 中的重复键（可用环境变量MONAI_FAIL_ON_DUPLICATE_CONFIG=1让重复键直接抛错，见 test_config_parser.py）。

globals预导入与安全选项

ConfigParser.__init__的globals参数会预导入最小依赖包并注入表达式的求值上下文，默认别名包括monai、torch、np（numpy）、numpy；额外包可通过globals={"itk": "itk"}添加，设为False则完全禁用（config_parser.py）。这解释了为什么配置里可以放心书写"$torch.device(...)"、"$monai.data.list_data_collate"而不需要显式 import。

需要特别强调的是安全边界：ConfigParser解析"_target_"时会定位并调用任意可导入的可调用对象，"$"表达式会交给 Pythoneval()执行。因此 MONAI 在 scripts.py 与 workflows.py 中多次明确告警：只应运行来自可信来源的配置（对应安全公告 GHSA-873f-pvrv-4x83），本文所有示例均为本地自写配置。

便捷属性访问与_ConfigProxy

从源码可见ConfigParser实现了__getattr__，让parser.training.trainer.max_epochs等价于parser.get_parsed_content("training::trainer::max_epochs")；当解析结果是 dict/list 时，会被包一层_ConfigProxy以支持链式属性/下标访问，并保持keys()、items()等容器方法的正常语义（config_parser.py）。如果配置键与容器方法重名（如键名为keys），应改用括号下标或get_parsed_content访问。需要真实容器对象时可通过只读属性._raw取得。

Scripts：从 CLI 到一键落地

monai.bundle通过main.py 以python -m monai.bundle <command>提供完整命令行入口（基于fire），支持以下子命令：download、load、run、run_workflow、verify_metadata、verify_net_in_out、ckpt_export、trt_export、onnx_export、init_bundle、download_large_files、push_to_hf_hub、get_all_bundles_list、get_bundle_info、get_bundle_versions。所有函数都以args_file支持把默认参数写进 JSON/YAML 以简化命令行。

下载与加载：download / load / download_large_files

download支持从多种源获取 bundle（scripts.py）：

# 从 model-zoo 下载指定版本 python -m monai.bundle download --name <bundle_name> --version "0.1.0" --bundle_dir "./" # 从指定 github release 下载 python -m monai.bundle download --name <bundle_name> --source "github" --repo "repo_owner/repo_name/release_tag" # 从 NGC / monaihosting 下载最新版 python -m monai.bundle download --name <bundle_name> --source "ngc" --bundle_dir "./" python -m monai.bundle download --name <bundle_name> --source "monaihosting" --bundle_dir "./" # 从 Hugging Face Hub 下载 python -m monai.bundle download --name "bundle_name" --source "huggingface_hub" --repo "repo_owner/repo_name" # 直接通过 URL 下载 python -m monai.bundle download --name <bundle_name> --url <url> # 用 args_file 提供默认参数 python -m monai.bundle download --args_file "args.json" --source "github"

各参数要点：source默认取环境变量BUNDLE_DOWNLOAD_SRC（默认值"monaihosting"），可选"ngc"、"monaihosting"、"github"、"ngc_private"、"huggingface_hub"；version=None时自动解析与当前 MONAI 版本兼容的最新版本（_get_latest_bundle_version会逐一检查metadata.json中的monai_version）；ngc_private需要环境变量NGC_API_KEY；bundle_dir默认是torch.hub.get_dir()/bundle。下载完成后会检查configs/metadata.json里的monai_version与已安装版本是否兼容并给出告警。monaihosting 源还支持large_files机制——download_large_files会读取 bundle 根目录的large_files.yml/yaml/json并按其中声明的url/path/hash_val下载大文件（scripts.py）。

load则用于直接加载 bundle 中的模型权重或 TorchScript 模块：model_file默认为models/model.pt（权重）或models/model.ts（TorchScript，需load_ts_module=True）；workflow_type取"train"/"training"或"infer"/"inference"/"eval"/"evaluation"；加载权重时会用copy_model_state把 checkpoint 拷入实例化后的网络。若本地文件不存在会自动触发下载（scripts.py）。

运行工作流：run / run_workflow

run是日常使用频率最高的命令，它加载元数据与配置后按initialize → run → finalize三个 ID 依次执行（默认分别为"initialize"、"run"、"finalize"，其中initialize与finalize可选）：

# 基本用法 python -m monai.bundle run --meta_file <meta path> --config_file <config path> # 指定 run_id python -m monai.bundle run training --meta_file <meta path> --config_file <config path> # 运行时覆盖配置：--<id>#<子键> <值>，或用 % 引用其它配置文件 python -m monai.bundle run --net#input_chns 1 ... python -m monai.bundle run --net %/path/to/another.json ... python -m monai.bundle run --net %/data/other.json#net_arg ...

override机制把命令行参数转换为"ID-值"对写回配置（如--net#input_chns 1），而%前缀则把值替换为另一配置文件的（子）内容——这正是 CLI 层面对宏机制的复用。run内部由create_workflow构造ConfigWorkflow后调用其run()与finalize()（scripts.py）。run_workflow则允许通过--workflow_name指定自定义的BundleWorkflow子类（ConfigWorkflow为默认值），适合把业务逻辑写成 Python 类的场景。

ConfigWorkflow.run()在运行前会自动把 bundle 根目录插入sys.path，从而允许配置_target_引用 bundle 自带的 Python 模块（workflows.py）。BundleWorkflow基类还定义了"属性（property）"机制：TrainProperties、InferProperties、MetaProperties（properties.py）声明了 bundle 应提供的公共属性，check_properties()会在启动时检查必需属性是否齐备，第三方应用也可通过add_property扩展自定义属性约束。

验证与导出：verify_metadata / verify_net_in_out / ckpt_export / onnx_export / trt_export

verify_metadata依据 JSON Schema 校验 metadata：metadata 必须包含schema字段指明 schema 文件的 URL，下载后用jsonschema.validate校验（scripts.py）。

python -m monai.bundle verify_metadata --meta_file <meta path> --filepath <schema save path>

verify_net_in_out根据 metadata 中_meta_#network_data_format声明的输入输出通道数、空间形状与 dtype，生成随机张量对网络做一次前向，验证输出通道数与 dtype 是否匹配（scripts.py）。其中形状字符串支持"32"、"32 * n"、"32 ** p"、"*"等模式，分别由n（倍乘因子）、p（幂次因子）、any（通配尺寸）三个参数控制（_get_fake_spatial_shape）。fp16 输入会走torch.autocast路径。

python -m monai.bundle verify_net_in_out network --meta_file <meta path> --config_file <config path>

三个导出命令把训练好的 checkpoint 转换为可部署格式，共享同一套_export流水线：先从配置实例化网络、用ignite Checkpoint（或torch.load+copy_model_state）装载权重，再交给monai.networks中的转换器（convert_to_torchscript/convert_to_onnx/convert_to_trt），最后把 metadata 与配置（统一序列化为 JSON）作为附加文件一并写入目标模型：

# 导出为 TorchScript（含 metadata 与配置，.ts） python -m monai.bundle ckpt_export network --filepath <export path> --ckpt_file <checkpoint path> ... # 导出为 ONNX python -m monai.bundle onnx_export network --filepath <export path> --ckpt_file <checkpoint path> ... # 导出为 TensorRT engine 版 TorchScript python -m monai.bundle trt_export --net_id <network definition> --filepath <export path> \ --ckpt_file <checkpoint path> --input_shape <input shape> --dynamic_batchsize <batch range> ...

trt_export支持两条转换路径：Torch-TensorRT 路径（PyTorch → TorchScript → TRT engine）与 ONNX-TensorRT 路径（PyTorch → TorchScript → ONNX → TRT engine，use_onnx=True）；precision取"fp32"或"fp16"；dynamic_batchsize形如[MIN_BATCH, OPT_BATCH, MAX_BATCH]定义动态 batch 范围；未给input_shape时会自动从 metadata 推导（scripts.py）。

初始化与发布：init_bundle / push_to_hf_hub

init_bundle一键生成标准 bundle 目录骨架（configs/、models/、docs/，默认写入configs/metadata.json与configs/inference.json），可选拷贝 checkpoint（ckpt_file）或直接保存传入网络的权重（network），并可用dataset_license=True生成docs/data_license.txt（scripts.py）。默认生成的 metadata 与 inference 模板定义在 utils.py，其中 inference 模板完整展示了"预处理 Compose → Dataset → DataLoader → inferer → 后处理 → evaluator"的典型推理配置结构，是学习书写 bundle 配置的最佳起点。

python -m monai.bundle init_bundle /path/to/bundle_dir network_ckpt.pt

push_to_hf_hub把 bundle 推送到 Hugging Face Hub（默认私有仓库），自动创建/更新模型卡片并注入 license 与标签元数据；version与tag_as_latest_version控制版本标签的创建——被标记为latest_version的版本会被download默认拉取（scripts.py）。

仓库查询：get_all_bundles_list / get_bundle_info / get_bundle_versions

这三个函数用于查询 model-zoo 的 bundle 清单与版本信息（默认repo="Project-MONAI/model-zoo"、tag="dev"）。get_all_bundles_list返回(bundle_name, latest_version)列表；get_bundle_versions返回{"latest_version": ..., "all_versions": [...]}；get_bundle_info返回指定 bundle+version 的完整信息（含browser_download_url）。当tag="hosting_storage_v1"时改从 GitHub Releases API 读取（scripts.py）。由于 GitHub API 有速率限制，可传入auth_token（个人访问令牌）提升配额。

源码级进阶：从实现看解析原理

把测试与实现对照起来，可以更深入地理解解析器的设计取舍：

• 引用与表达式求值的先后顺序：_resolve_one_item中"先递归解析依赖，再解析自身"，并且 import 语句形式的表达式会被优先批量求值（reference_resolver.py），保证"$import glob"这类语句在其它表达式用到glob之前就已生效。
• 表达式中引用替换为局部变量：update_refs_pattern把$表达式内的@ref替换为__local_refs['ref']，同时把解析结果字典注入eval的 globals——这让"$'test' + '@F'"中带引号的字符串@F不会被误替换（test_config_parser.py 的TEST_CASE_4专门覆盖了此场景）。
• _mode_与函数型目标：_mode_="callable"适用于_target_为函数或需要柯里化参数的场景；测试 test_config_parser.py 用_mode_解析出静态方法、类方法、lambda 与可调用类实例，甚至"$@model.forward"这种以表达式作_target_的写法（test_non_str_target）。测试 test_config_parser.py 还验证了_mode_="debug"会进入pdb调试（返回None）。
• 惰性实例化与缓存：get_parsed_content(id, lazy=True)（默认）复用解析缓存，lazy=False则强制重新解析；测试 test_config_parser.py 通过lazy开关验证了同一组件是否返回相同实例。
• list 表达式执行：工作流的initialize/run/finalizeID 可以是"表达式列表"，ConfigWorkflow._run_expr会逐个求值并每次从解析缓存中移除结果，从而支持流式应用中的重复执行（workflows.py；对应测试见 test_config_parser.py 的test_list_expressions）。
• 实验跟踪（tracking）：run --tracking "mlflow"会把MLFlowHandler自动注入 trainer/validator/evaluator 的 handlers，默认配置定义在 utils.py：输出目录默认<bundle_root>/eval、tracking URI 默认本地 SQLite（<output_dir>/mlruns.db）、save_execute_config会把实际执行的配置快照保存为config_<时间戳>.json以便复现实验（patch_bundle_tracking，workflows.py）。也可用自定义 JSON 文件或 dict 传入自定义 tracking 设置。

实战示例：从零构建并运行一个最小 Bundle

综合以上内容，给出一个完整的最小实战路径。首先用init_bundle生成骨架，再编辑配置、验证、运行：

# 1. 生成 bundle 骨架（configs/metadata.json 与 configs/inference.json） python -m monai.bundle init_bundle ./my_bundle # 2. 编辑 configs/inference.json，参考 DEFAULT_INFERENCE 模板 # 填入 network_def 的 _target_ 与预处理、后处理 transforms # 3. 校验 metadata 与网络输入输出 python -m monai.bundle verify_metadata --meta_file ./my_bundle/configs/metadata.json --filepath ./schema.json python -m monai.bundle verify_net_in_out network --meta_file ./my_bundle/configs/metadata.json \ --config_file ./my_bundle/configs/inference.json # 4. 运行推理（--dataset_dir 与 --bundle_root 属于 override 机制） python -m monai.bundle run \ --meta_file ./my_bundle/configs/metadata.json \ --config_file ./my_bundle/configs/inference.json \ --dataset_dir ./input \ --bundle_root ./my_bundle # 5. 导出部署格式 python -m monai.bundle ckpt_export network --meta_file ./my_bundle/configs/metadata.json \ --config_file ./my_bundle/configs/inference.json --ckpt_file ./my_bundle/models/model.pt \ --filepath ./my_bundle/models/model.ts

对于已发布的 bundle，一条download+ 一条run即可完成"获取模型 → 本地推理"的完整闭环；若要自行编写训练/推理配置，建议以 utils.py 中的DEFAULT_INFERENCE为蓝本，理解_target_（组件）、@（引用）、$（表达式）、%（宏）、_disabled_（条件跳过）五种语法后即可触类旁通。

小结

monai.bundle通过四层抽象把医疗影像模型的整个生命周期"配置化"：ConfigItem系列定义配置语义，ReferenceResolver完成引用与表达式解析，ConfigParser提供文件读写、ID 寻址、宏替换与多文件合并能力，而Scripts层把这一切封装成python -m monai.bundle命令行。理解这四层之后，无论是读懂模型 zoo 中的既有 bundle、编写自己的训练/推理配置，还是通过导出命令把模型交付到 TorchScript/ONNX/TensorRT 环境，都能在统一的心智模型下高效完成。进一步阅读可深入 bundle_intro.rst（入门介绍）、mb_specification.rst（bundle 规范）与 mb_properties.rst（属性定义），并在 tests/bundle 中查看覆盖上述全部机制的单元测试。

【免费下载链接】MONAIAI Toolkit for Healthcare Imaging项目地址: https://gitcode.com/GitHub_Trending/mo/MONAI