简介这是一款面向计算化学、药物发现与结构生物学场景的高通量分子对接工具基于AutoDock Vina系列引擎可同时处理多个靶标与配体自动完成PDBQT准备、灵活残基定义、对接执行与结果汇总解决传统逐对对接的低效问题。资源包共15个文件体积仅20KB以6个Python脚本为核心另配Dockerfile与docker-compose.yml实现容器化部署附CSV参数文件和Markdown使用文档结构清晰便于直接集成到虚拟筛选流程中。已有1678人学习下载。核心脚本覆盖受体和配体预处理、柔性残基定义、对接运行及结果提取兼容Vina、smina、qvina等类似引擎并输出标准化CSV方便批量分析与排序。对需要搭建自动化对接流程、复现高通量筛选管线的研究者而言这份轻量代码库提供了可直接扩展的框架值得参考。 搞过分子对接的人多数都绕不开 Vina 系列引擎而一旦你真正开始做高通量分子对接就会明白批量跑的痛远比想象中多。我维护的这套批处理流程叫 dockit专门用来解决“配体多、靶点多、要排队跑”的问题。这篇文章就围绕 dockit 展开把 Vina、Smina、Vinardo 的选型差异、受体配体准备、批处理命令、结果汇总、常见坑还有一次 5000 个分子的实际筛选项目都过一遍。不管你是刚接触虚拟筛选还是手上已经堆了几万个小分子准备排队对接这篇都应该对你有用。1. 为什么选 Vina 系列引擎做高通量分子对接1.1 Vina、Smina、Vinardo 各自擅长什么很多人在群里问“做虚拟筛选到底该用哪个软件”我的答案一直是先别急着上商业软件把 Vina 系列吃透再说。AutoDock Vina 本身是开源的打分函数稳定命令行友好对 CPU 为主的计算环境很友好。Smina 是 Vina 的一个重编译分支保留了 Vina 的底层搜索框架但跑批处理时经常有惊喜支持自定义打分函数和部分柔性侧链处理。Vinardo 则是一个更“轻”的打分函数变体搜索时对位姿收敛更敏感适合做初筛阶段的速度优先任务。我用三句话概括这三者在高通量场景里的分工AutoDock Vina 1.2.x默认选项适合绝大多数蛋白质-小分子体系结果相对保守复现性好。Smina适合需要自定义打分项、特殊原子类型或者想用脚本批量控制对接细节的时候。Vinardo速度比 Vina 略快打分表面更“锐利”用它对大库做第一轮粗筛能快速砍掉明显不结合的分子。实际项目里我经常用 Vinardo 初筛一遍再用 AutoDock Vina 对排名靠前的分子做复筛和精打分。这样可以把每一轮的计算成本控制在合理范围而不是让一万个配体全都在默认 Vina 上慢慢跑。要注意的是Vinardo 和 Vina 的打分数值不是一个标尺混在一起排序会出问题这点后面第 4 章还会细说。引擎选型表引擎速度感受主要优点适合场景AutoDock Vina中等默认分值稳定社区资料多常规虚拟筛选、精打Smina中等偏快支持自定义打分、批处理友好有特殊评分需求或柔性残基Vinardo较快位姿搜索更“有辨识度”大规模库初筛、快速排序1.2 高通量对接的本质是调度问题很多人以为高通量分子对接就是把同一个配体文件复制一万份然后多开几个 Vina 窗口跑。真正做过上万分子筛选的人会告诉你对接计算本身可能不是瓶颈怎么让一万个任务有序跑完才是。这就像快递分拣每个包裹的运输时间只有几分钟但如何排班、如何识别坏件、如何重新投递决定了整个系统一天能处理多少单。我当时写 dockit 的初衷就是发现团队里每个人都在手动写 for 循环调 Vina命令路径不一致、评分结果格式不统一、日志也散落一地。dockit 做的事情其实很克制它不自研对接引擎而是把“配体准备—受体格点盒检查—并行对接调度—结果汇总—失败重试”这一整条链路串起来。引擎还是 Vina 系列但外部多了一个能落地的批处理壳于是整个高通量对接才真正可复现、可审计、可断点续跑。2. 高通量分子对接的前置准备2.1 受体结构与 Grid Box 设置很多菜鸟第一次跑 Vina 时报错“Error: receptor does not contain a valid PDBQT”多半不是软件问题而是受体文件没洗干净。从 PDB 数据库拿到的结构通常带有水分子、金属离子、共晶配体或者无序残基这些在高通量对接前都得处理。水分子一般直接删掉除非你想专门研究水介导的氢键共晶配体必须和受体分离它只是告诉你结合口袋在哪里的参考点不能参与对接。金属离子要单独判断有些金属是结构必需有些只是结晶条件里的盐离子。把受体处理成 PDBQT 格式这一步可以用 AutoDock Tools 里的 prepare_receptor4.py也可以用 ADFRsuite 的 prepare_receptor或者 Open Babel 配合脚本。我实际更推荐 ADFRsuite 方式它生成的 PDBQT 对 Vina 的原子类型识别更干净。处理完后一定要把受体拖进 PyMOL 或者 Vina 自带的 visualizer 里看一眼确认加氢位置没有问题。Grid Box 的设置是最容易影响结果的一个环节。高通量场景下我们通常已经有了一个已知的结合口袋比如共晶配体所在位置那就以共晶配体的几何中心作为 Box 中心。如果没有共晶配体就取已知活性残基或催化残基的中心点。Box 的边长建议比结合口袋稍微外扩 5 埃左右保证配体可以在合理空间内采样。Box 太大没必要搜索空间指数增大耗时会明显上升Box 太小又可能漏掉配体真正能结合的位点。2.2 配体文件的预处理与去质子化配体端的坑比受体端多得多。第一次做大规模对接的时候我从数据库导出 SMILES 直接丢进 Open Babel 批量生成了 SDF 文件结果对接时接近 10% 的分子报错。后来排查发现问题大多出在三类情况SMILES 本身带有不合理的盐离子、没有生成正确的 3D 坐标、加氢状态和生理条件下的质子化状态不一致。对于高通量流程我现在的标准做法是先用 RDKit 对 SMILES 做一遍清洗过滤掉明显不对的原子类型和电荷不平衡的分子再用 RDKit 2D 转 3D生成多个低能构象选择一个作为对接起始构象最后用 Open Babel 或者 Meeko 把 SDF 转成配体 PDBQT 文件。整个过程需要记录每个分子的来源 ID方便后面把对接分数对应回数据库。配体处理命令大致长这样obabel ligand.sdf -O ligand.pdbqt --partialcharge gasteiger -p 7.4这里-p 7.4表示按 pH 7.4 条件调整质子化状态对大多数虚拟筛选场景是一个相对合理的默认值。但要注意如果一个配体含有多个可电离基团只用一个 pH 静态表示可能失真更严谨的做法是用 Epik 或 FAF-Drugs 这类工具做多种质子化状态枚举。高通量初筛阶段我经常直接用 pH 7.4 一刀切只要批量流程提前说明边界结果还是能用的。2.3 目录结构与输入配置dockit 对项目目录结构有一个固定约定目的是让每批次筛选都像一个独立实验一样可以复现project/ ├── receptors/ │ └── target1.pdbqt ├── ligands/ │ ├── ligands.sdf │ └── ligands.csv ├── config.yaml ├── output/ └── logs/config.yaml 里主要写受体路径、配体文件路径、Box 中心坐标、尺寸、对接引擎、exhaustiveness、并行核数等核心参数。把这些参数抽到配置文件里而不是写在命令行里最大的好处是同一批对接任务无论谁接手跑出来的设置是一致的后续重新筛选时只需要改 Box 坐标或者引擎名就可以完整复现。3. 真正跑起来dockit 的实操流程与核心实现3.1 并行任务拆分与调度策略Vina 本身支持多线程但我们在高通量场景下不能让每个 Vina 单任务占用整台机器。因为对接任务彼此独立最自然的做法是把上万个小分子拆成若干独立 Job每个 Job 分配固定资源然后并行调度。Linux 下我一般直接用 GNU Parallel简单高效find ./ligands_pdbqt -name *.pdbqt | \ parallel -j 16 --joblog docking.log \ vina --receptor receptors/target1.pdbqt \ --ligand {} --out output/{/.}_out.pdbqt \ --center_x 15.2 --center_y -8.4 --center_z 22.7 \ --size_x 24 --size_y 24 --size_z 24 \ --exhaustiveness 8 --cpu 2这里-j 16表示同时运行 16 个 Vina 任务每个任务里面再设置--cpu 2。所以总占用是 32 核左右。实测下来这个比例往往比一个 16 核任务跑 16 个 Vina 单线程更稳既能利用 Vina 本身的搜索能力也不会因为 CPU 过度争抢导致整体变慢。dockit 在底层就是这么干的只不过它把命令封装得更友好并且把运行日志统一写到了 logs 目录。3.2 核心命令与参数选择实际使用 dockit 时一条命令大概长这样dockit run \ --receptor receptors/target1.pdbqt \ --ligands ligands/ligands.sdf \ --config config.yaml \ --engine vina \ --exhaustiveness 8 \ --cpu_per_job 2 \ --out_csv results.csv参数选择上exhaustiveness是最容易“用力过猛”的选项。有人觉得数字越大越好直接给它设成 32结果一个配体要跑十几分钟。我的经验是初筛阶段 exhaustiveness 设 4 到 8 就足够复筛阶段可以提高 16 到 32。我们做过一个小实验同一个激酶体系exhaustiveness 从 8 提高到 32打分排序的前 100 名单变化不到 15%但计算时间翻了近三倍性价比很低。关于--cpu_per_job建议先在小样本上做一次测试。比如拿 50 个配体分别用 1、2、4 核跑同一批分子记录有没有因为资源争抢导致时间反而变长。我见过不少机器单 Job 核数超过 2 以后并行效率反而因为内存带宽和 CPU 缓存争用而下降。3.3 结果汇总、打分排序与位姿提取跑完对接之后最怕的事情是结果散落在一堆 PDBQT 输出文件里然后靠肉眼去翻。一个成熟的高通量流程必须自动汇总结果。Vina 的日志输出里有affinity分数dockit 会把每个配体的最佳结合自由能、对应 RMSD、输出文件路径、运行状态统一写进 CSV。这样后续用 Pandas 排序、过滤、聚类都会很顺。汇总完之后还需要从每个配体的输出文件中提取前几个结合模式。对于 Top 100 的分子我一般再用 PyMOL 脚本把这些位姿叠加到受体上人工检查关键氢键和疏水接触是否合理。识别“真阳性”不能只看分数还要看结合构象有没有明显冲突。哪怕 Vina 打分不错如果配体落在了盒子的边缘或者与侧链产生严重近距离碰撞也要多留个心眼。4. 高性能批量对接的常见坑与排查技巧4.1 配体文件“看得见但跑不了”第一次跑大批量对接时最容易遇到的现象是SDF 文件在 PyMOL 里打开完全正常但 Vina 一跑就报错。这个问题很大程度出在配体加氢不完整或者带了不支持的原子类型。RDKit 生成的 SDF 转 Open Babel 后有时候芳香环上的氢没有被正确分配Vina 读进去后会直接拒绝。我的排查套路分三步先查原子类型把所有出现的元素拉个列表看看有没有 Vina PDBQT 不认的原子再查电荷是否合理比如带正电荷的氮原子如果没有正确表示会直接影响打分最后检查每个分子是否有有效 3D 坐标经历过 2D 结构转换失败的分子需要单独过滤。dockit 里加了一个“失败自动重试”的机制如果在某一步转换失败自动尝试用 Open Babel 强制写入并加氢。有一次跑 8000 个分子一开始失败率是 12%靠这套重试机制降到了 1% 以下剩下的 1% 基本都是输入 SMILES 本身有问题价值不大。4.2 Grid Box 与结合口袋对不上Vina 打分再漂亮如果 Box 中心定位错了结果也没有意义。有一个非常典型的错误把共晶配体从受体中删掉时数据库里的配体坐标单位不是埃而是纳米或者受体已经做过对称变换导致 Box 坐标和实际结合位点相差好几个纳米的距离。结果就是跑到最后排名靠前的分子全部堆在蛋白表面上而不是在真正的口袋里。排查方法也很直接对接完成后把 Vina 输出的最佳位姿和受体一起加载进 PyMOL看配体是不是稳定落在结合口袋里。如果发现位置明显偏了回到 config 里检查 Box 中心和坐标单位。临床上公认的一句话是“垃圾进垃圾出”在分子对接领域同样适用。4.3 打分函数的选择一致性高通量对接过程中最容易犯的隐性错误是不同引擎的结果混着排序。比如初筛用 Vinardo 跑了 5000 个分子复筛时换 AutoDock Vina 跑了 Top 100然后直接拿两轮分数放在一张排名表里。这两套打分函数没有线性关系排序必然失真。所以我在 dockit 的配置里强制标记每一批任务的引擎名和打分函数版本后续汇总时如果发现引擎不一致会在结果表里明确标注而不是默默混在一起。另外Smina 支持自定义打分函数初学者很容易被各种评分项弄晕。我的建议是在验证一个打分函数是否适合当前体系之前先用默认打分函数跑通整个流程再逐步替换。4.4 资源调度与断点续跑高通量任务跑十几个小时是家常便饭。一旦中间断电或者某个配体文件异常挂死整个任务可能就白跑了。所以我特别重视“断点续跑”功能。dockit 会把每个配体的运行状态写进 joblog 和 results 表再次启动时自动跳过已经完成且没有报错的配体只重跑失败和未运行的任务。这样即使中途机器重启也不会从头开始。资源调度上还要注意内存占用。小分子对接通常不是内存密集任务但如果配体本身特别大、原子数超过 80Vina 偶发内存暴涨也是有的。批量任务前最好先限制单任务的内存上限或者在集群上使用 cgroup 级别隔离避免一个异常任务把整台机器拖垮。常见问题速查表现象可能原因排查方法配体对接报错加氢失败/原子类型不支持先查原子类型再查电荷和3D坐标打分极低但构象不合理Grid Box 设置错误在 PyMOL 中查看位姿是否落在口袋多个引擎结果无法排序打分函数不一致统一用同一引擎复筛任务跑到一半挂死单个配体异常或资源不足开启断点续跑限制并发任务数输出文件很大每个配体保存了过多位姿限制--num_modes为 5 或 105. 实际项目案例5000 个小分子对同一靶点的批量筛选5.1 准备过程与耗时统计有一个实际项目是帮课题组做某种激酶靶点的虚拟筛选配体库用了 5000 个小分子。机器是 64 核的服务器没有任何 GPU 加速。整个流程分成几段受体处理和格点盒确定用了大概 1 个小时这步基本是人工操作急不来配体准备 5000 个分子RDKit 转 3D、Open Babel 转 PDBQT、去重和过滤跑完大概是 2 小时然后对接阶段用 dockit 按 32 个并发 Job、每个 Job 占用 2 核的方式跑exhaustiveness 设 8平均一个配体 1 分钟出头总耗时大约 28 小时。耗时统计表阶段耗时说明受体清洗和格点盒确定1 小时人工为主配体准备2 小时自动化批量处理并行对接28 小时64 核32 个并发结果汇总和Top分子分析3 小时自动化人工检查这个时间对于一个 5000 分子的库来说比较典型。如果你只有一台普通 16 核工作站时间会拉到 4 天左右所以在开始跑之前先把流程验证好很重要。5.2 命中结果的分析与取舍按照 Vina 打分排序后我们取了前 200 个分子做第二轮分析。打分最低的一半确实结合模式比较规整但只看分数会有两个陷阱一是高活性分子不一定打分最低二是打分最低的分子可能结构特别相似等于多次重复计数。所以筛选结果还需要做聚类我一般用 Butina 聚类或者基于骨架相似性的方法让每个化学系列只保留少数代表分子。之后对这 200 个分子进行了聚合枚举和 MM-GBSA 小规模精算把结合自由能更差的那批分子砍掉剩下约 40 个进入实验测试。最后实验测出来有几款分子在微摩尔级别有初步活性虽然没有到理想的纳摩尔但对虚拟筛选流程来说已经算是可用的产出。5.3 跑完这批数据之后的一些体会连续几次项目跑下来我越来越确认一件事高通量分子对接真正考验人的不是软件操作是流程设计。准备工作做得越扎实后期排查问题越轻松。比如配体文件命名规则、日志记录、失败重试机制这些看上去都不起眼但在跑长任务时都是救命稻草。我要特别强调一个小习惯正式全量跑之前一定先随机抽 200 个配体跑个小规模测试检查错误率、平均耗时、输出文件完整性。这一步只需要十几分钟却能避免很多“跑了 20 个小时发现 Box 坐标错了”的惨剧。另一个习惯是结果文件里一定要带上原始配体 ID不要只保留 PDBQT 文件名否则后面做数据回溯会非常痛苦。dockit 这套流程写出来后后来又给团队里的几个项目复用了几次除了改改受体和配体路径、调整一下 Box 坐标基本上不需要额外改脚本。对一个以分子对接为主要方法的团队来说这种效率提升远比多买几块 GPU 更明显。如果你手头也有一批配体要跑高通量对接不妨先按这个思路把流程搭起来磨刀不误砍柴工。本文还有配套的精品资源点击获取