企业官网建设流程全解析

在Linux服务器上跑分子对接，绕不开AutoDock这套老牌工具链。但真要动手装的时候，不少人会被AutoDockTools、AutoGrid、AutoDock这几个名字绕晕——它们到底谁是图形界面、谁是计算程序？为什么装AutoDockTools要拖着MGLTools一起装？Grid Box的坐标到底怎么定？这些坑我在自己服务器和课题组工作站上都踩过一遍，这篇就把整个安装和首次对接的完整链路写清楚，从依赖环境到结果解读，照着做就能跑通。

1. 装之前先把三个工具的分工和版本坑理清楚

很多新手上来就直接搜“AutoDock安装教程”，结果发现网上的资料有的说装MGLTools，有的说装AutoDock 4.2.6，还有的推荐AutoDock Vina，一会儿说用Python 2，一会儿说用Python 3，整个人都是懵的。这里先花几分钟把工具链的关系捋清，后面能少走不少弯路。

1.1 三个工具各自负责什么

AutoDockTools（ADT）严格来说不是一个独立的软件，而是依附于MGLTools平台的图形化操作前端。它的作用是：准备受体和配体的PDBQT文件、设置Grid Box、生成对接所需的GPF和DPF参数文件、查看对接结果。它本身不做对接计算。

AutoGrid是网格参数计算程序，读入受体和配体信息之后，在指定范围内计算探针原子与受体之间的相互作用能，把结果写进map文件，为后续的对接搜索做能量打底。

AutoDock才是真正执行对接搜索的程序，它把配体放在Grid Box定义的搜索空间里，通过遗传算法或模拟退火不断尝试配体的构象和位置，最后输出结合能和结合模式。

通俗点说：ADT是“办公室”，AutoGrid是“准备地图的人”，AutoDock是“跑到地图里找最优路径的人”。三者串起来才能完成一次完整对接。

1.2 版本选择：MGLTools 1.5.7配AutoDock 4.2.6

官方稳定组合是MGLTools 1.5.7（内含ADT 1.5.7）加AutoDock 4.2.6。这个组合在2010年前后进入成熟期，虽然界面老，但胜在稳定、资料多、兼容性好，至今仍在大量论文中使用。

这里有个关于Python版本的隐情：ADT 1.5.6依赖Python 2.5，ADT 1.5.7依赖Python 2.6，但是MGLTools发布的是自带Python的解释器环境，不需要你系统里提前装好对应版本的Python，这点对Linux用户友好。

不过要注意，如果你的系统是近两年的发行版，比如Ubuntu 22.04或更新版本，系统默认没有Python 2相关包，但这不影响MGLTools运行，因为它自带的Python库是打包在一起的。真正需要担心的是动态链接库缺失的问题，后面专门讲。

2. 环境检查与依赖准备：别让老软件卡在新系统上

AutoDock 4.2.6的源码是2010年前后的代码，编译依赖和今天的Linux发行版存在一些代沟。我在Ubuntu 20.04和22.04上都编译过，也在CentOS 7和8上试过，这里直接给出稳妥的环境准备清单。

2.1 系统与编译器检查

先确认系统是64位还是32位。现在基本都是64位，但保不齐手上有台老的工控机或虚拟机，跑uname -m看看，输出x86_64就是64位。

编译器方面，AutoDock 4.2.6要求有gcc和g++，版本不用太新，gcc 4.8以上的都可以。Ubuntu/Debian系安装：

sudo apt update sudo apt install -y gcc g++ make cmake

CentOS/RHEL/Fedora系用：

sudo yum install -y gcc gcc-c++ make cmake

如果提示找不到g++,一般是没装build-essential，Ubuntu直接装这个包就行。另外建议把libx11-dev和libmotif-dev装好，虽然AutoDock本身的编译不需要图形库，但ADT的图形界面在部分系统上依赖这些X11相关组件。

2.2 下载渠道和压缩包确认

三个软件的下载渠道先说清楚：

• MGLTools 1.5.7：去CCSB官网的“Download”页面找Linux版，文件名一般是mgltools_x86_64Linux2_1.5.7.tar.gz。
• AutoDock 4.2.6：去AutoDock官网下载源码压缩包autodock-4.2.6-x86_64.tar.gz，这是同时包含AutoGrid和AutoDock源码的包。

下载的时候有个小细节：有些高校或机构的网络访问国外站点慢，或者被拦，可以尝试用校内镜像或GitHub上的存档仓库。还有，下载完立刻算一下MD5，我用curl下载时遇到过不完整的情况，解压时报“unexpected EOF”才发现的，白白浪费了二十分钟。

2.3 确认gnuplot是否为必需

网上有些教程会提到gnuplot，说ADT的某些分析功能需要它。实际上gnuplot只是ADT用于绘制能量曲线等图表的外部工具，不装也能完成对接全流程。如果你只是做常规的对接和结果分析，可以先不装，节省时间。后面如果需要绘制能量趋势图再补装也不迟。

3. AutoDockTools安装：图形环境与Python兼容问题

MGLTools 1.5.7的安装方式比较特别，它不是传统意义上的configure && make && make install，而是解压后直接运行安装脚本。

3.1 解压、安装与配置环境变量

cd /opt sudo tar zxvf mgltools_x86_64Linux2_1.5.7.tar.gz cd mgltools_x86_64Linux2_1.5.7 sudo ./install.sh

安装脚本会询问安装路径，默认就是当前目录，直接回车即可。安装完成后，会在/opt/mgltools_x86_64Linux2_1.5.7/bin下生成一堆可执行文件，其中重要的是pythonsh（MGLTools自带的Python解释器）和pmv、adt等启动脚本。

之后配置环境变量，编辑~/.bashrc：

export MGL_ROOT=/opt/mgltools_x86_64Linux2_1.5.7 export PATH=$MGL_ROOT/bin:$PATH

运行source ~/.bashrc使其生效，然后在终端输入adt，如果弹出ADT的主窗口，说明安装成功。

3.2 无图形环境的服务器怎么用ADT

这个问题非常普遍：科研服务器往往没有显示器，ADT的图形界面根本打不开。我在帮同事配置的时候，遇到过两种典型场景：

一是有X11转发，可以远程打开图形界面。这种情况下需要确保X11Forwarding开启，并且本地有X Server（Windows上用MobaXterm或Xshell配合Xmanager）。但受网络延迟影响，画图操作会卡，体验一般。

二是纯命令行环境，无法打开图形界面。此时ADT只能用来做一件事——利用它的pythonsh脚本批量处理PDBQT文件。你可以在有图形环境的个人电脑上把参数文件准备好，再用命令行执行AutoGrid和AutoDock。更高效的做法是用prepare_receptor4.py和prepare_ligand4.py这两个命令行脚本直接生成PDBQT文件，这两个脚本就在MGLTools的MGLToolsPckgs/AutoDockTools/Utilities24/目录下，也是用pythonsh调用的：

cd /opt/mgltools_x86_64Linux2_1.5.7/MGLToolsPckgs/AutoDockTools/Utilities24 /opt/mgltools_x86_64Linux2_1.5.7/bin/pythonsh prepare_receptor4.py -r receptor.pdb -o receptor.pdbqt

这对无图形界面的服务器来说，等于打开了自动化批量对接的大门。这也是为什么我建议你即使看到ADT界面，也顺手把命令行脚本的调用方式学会——批量处理几十个配体的时候，你就知道这有多重要了。

3.3 新版系统缺少libXext等图形库的解决方案

MGLTools 1.5.7毕竟是老软件，在较新的Ubuntu发行版上，双击adt启动时可能会报：

error while loading shared libraries: libXp.so.6: cannot open shared object file

这是因为新版系统把libxp从默认安装中去掉了。解决办法是安装兼容库：

sudo apt install libxp6 # 如果提示没有该包，先启用 universe 源

还有可能缺少libXmu.so.6、libXi.so.6等，同样用sudo apt install libxmu6 libxi6解决。每次碰到缺库，先执行ldd /opt/mgltools_x86_64Linux2_1.5.7/bin/adt看看缺哪几个，缺啥补啥就行。

如果是纯命令行服务器，建议直接跳过ADT图形界面，用Utilities24目录下的脚本完成结构准备，这是当前最推荐的做法。

4. AutoGrid和AutoDock的编译安装：从源码到可执行文件

AutoGrid和AutoDock的源码在同一个压缩包里，编译方式一致，必须使用g++编译。

4.1 解压源码并进入对应目录

tar zxvf autodock-4.2.6-x86_64.tar.gz cd autodock-4.2.6

解压后你会看到autodock和autogrid两个子目录，每个目录下都有src子目录，源码和Makefile都在里面。

4.2 编译AutoDock核心程序

cd autodock/src ./configure make

configure会检测编译器并生成Makefile，如果系统缺少某些头文件，会在这里报错。常见的报错如fatal error: X11/Xlib.h: No such file or directory，这是因为AutoDock 4.2.6的源码里包含了一个带图形界面的辅助工具，编译时需要X11开发头文件。

解决办法是安装X11开发库：

sudo apt install libx11-dev

然后再make clean重新编译。编译结束后，在autodock/src下会生成autodock4可执行文件。

AutoGrid的编译方式完全一样：

cd ../../autogrid/src ./configure make

生成autogrid4可执行文件。

4.3 安装到系统路径并验证

把两个可执行文件复制到/usr/local/bin，方便全局调用：

sudo cp autodock4 /usr/local/bin/ sudo cp autogrid4 /usr/local/bin/

验证方法很简单，直接运行：

autodock4

正常情况下会输出一大段版本信息和用法说明。同样运行autogrid4验证。如果提示Permission denied，检查可执行权限：

chmod +x /usr/local/bin/autodock4

编译过程中还有一个小技巧：Makefile里默认的优化参数是-O3，如果编译时内存不足或想排查问题，可以在configure之前手动修改Makefile，把-O3换成-O0，但正式计算建议保留-O3以保证速度。

5. 第一次对接前必须做对的准备：受体与配体处理

工具装好只是第一步，真正决定对接结果质量的，是输入文件的处理。这一步做错，后面的Grid设得再准都白搭。我见过太多人拿AutoDock跑的原始结果全是正结合能，十有八九是蛋白或者配体没有正确处理氢原子。

5.1 受体的获取与预处理

受体的初始结构一般从PDB数据库下载。这里有个关键点：AutoDock的输入格式是PDBQT，不是PDB，需要用ADT或脚本做转换。PDBQT相比于PDB，多了部分电荷（Q）和原子类型（T）信息。

用命令行脚本处理，最标准的方法是：

pythonsh prepare_receptor4.py -r 1abc.pdb -o 1abc.pdbqt -A hydrogens -U nphs_lps_waters_nonstdres

这里的参数含义是：-A hydrogens表示添加所有氢原子，-U nphs_lps_waters_nonstdres表示去除非极性氢、孤对电子、水分子和非标准残基。小白容易忽略的是，AutoDock4中的非极性氢不参与计算，会在生成PDBQT时被合并掉；而极性氢（比如羟基、氨基上的氢）必须保留，它们是形成氢键的关键。

如果蛋白结构里含有配体或辅因子，要先用文本编辑器或PyMOL把这些异源分子移除，只保留蛋白质部分。特别的，结合位点内的水分子要不要删除是有讲究的。计算结合自由能时，通常建议先全部删除水，之后再根据实际需要做全水分子显式处理的进阶研究，新手不要在一开始就纠结。

5.2 配体的获取与可旋转键设置

配体可以从PubChem、ZINC15等数据库下载，格式一般是SDF或MOL2。AutoDock的PDBQT不直接支持SDF输入，可以用Open Babel做格式转换：

obabel ligand.sdf -O ligand.pdb

转到pdb之后，再用ADT的prepare_ligand4.py脚本处理：

pythonsh prepare_ligand4.py -l ligand.pdb -o ligand.pdbqt

脚本会自动检测配体的可旋转键，在PDBQT文件的ROOT和TORSDOF字段里标注。也可以手动通过-A参数设定“保持所有原子严格位于根节点”或者-B参数指定旋转键数目。这里我说一个我自己常用的方式：

在脚本处理前，用Open Babel给配体加氢并生成3D构象：

obabel ligand.sdf -O ligand.pdb --gen3d

然后用prepare_ligand4.py处理。如果配体本身是柔性很大的长链分子，自动检测的旋转键可能过多，导致搜索空间爆炸，建议通过ADT图形界面手动限制只保留关键的单键，或者用-B参数限制旋转键数量。

5.3 PDBQT转换失败的常见报错与对策

在脚本处理过程中，最容易遇到的是：

• "Need to 'united' atom types"或"Bad atom type"：原子类型不被AutoDock识别。原因是PDB文件里的原子命名不规范，或者包含了AutoDock不支持的金属离子。对策是检查配体的HETATM记录，必要时用ADT图形界面的Edit -> Add H或Edit -> Delete水先做整理。
• "Number of atoms in ligand is different"：比较少见，通常是配体含多个构象导致的。对策是只保留第一个构象，用obabel ligand.sdf -O ligand.pdb -f 1 -l 1强制读取第一个构象。

还有一点，配体如果在PDB里含有磷酸基团、硫酸基团等，需要用Gasteiger电荷默认自动分配。AutoDock 4默认使用的就是Gasteiger电荷模型，如果手动改过电荷，反而可能导致结果不可复现。

6. Grid Box到底怎么框：活性口袋定位与AutoGrid运行

Grid Box是AutoDock搜索配体结合位置的空间范围，它的设置直接影响对接结果。框小了，配体找不到正确结合位点；框大了，搜索空间指数增长，耗时剧增且结果混乱。这一步是整个流程中最依赖经验的部分。

6.1 如何确定活性口袋位置

如果你研究的是已知有实验结构的蛋白配体复合物（比如PDB里自带共晶配体），那活性口袋的位置直接参考共晶配体即可。操作思路是：把受体和原始配体一起加载到ADT里，用Grid Box的中心对准原始配体的质心。

如果没有共晶配体，就只能靠经验判断。常见的方法：

• 查找文献中关于该蛋白的关键残基（往往是突变实验或酶动力学实验验证过的活性中心残基）。
• 用FPocket或DoGSiteScorer等服务器预测口袋位置。
• 根据蛋白的序列注释和保守结构域判断。

最直接的可操作办法是把关键残基的坐标均值作为Grid Box中心。例如已知蛋白的催化三联体是Ser195、His57、Asp102，就把这三个残基的中心坐标求出来，填入Grid Box的center。

6.2 Grid Map类型与Box间距选择

进入ADT图形界面后：

1. Grid -> Macromolecule -> Choose，选择受体PDBQT文件。
2. Grid -> Set Map Types -> Choose Ligand，选择配体PDBQT，系统会自动生成配体所有原子类型对应的map。
3. Grid -> Grid Box，调整Box大小和中心坐标。

Grid Box的间距（spacing）一般保持默认的0.375埃，这个值正好是碳碳单键长度的四分之一左右，密度足够。如果你的口袋很大或者是蛋白蛋白界面，可以适当调到0.5埃来加速，但要接受精度的下降。

Box尺寸上，我一般把盒子三个方向的格子数（points）设置在46到60之间，对应约为17到22埃的立方体，足以容纳分子量500以内的配体和其柔性侧链的摇摆空间。如果是多口袋大蛋白，可以适当增加到60以上，但超过90就会明显变慢。

6.3 生成GPF文件并运行AutoGrid

在ADT里设置完成后：

1. Grid -> Output -> Save GPF，保存为receptor_ligand.gpf。
2. 在终端运行：

autogrid4 -p receptor_ligand.gpf -l receptor_ligand.glg

-l参数指定日志输出文件。正常运行时终端会滚动显示网格计算进度，最后以Successful Completion之类字样结束。如果中途报错，最常见的错误是Cannot find map file，原因通常是GPF里引用的map文件类型和受体PDBQT里的原子类型对不上。比如配体里有氯原子，但GPF里没有生成Cl对应的map，需要回去重新Set Map Types -> Choose Ligand。

运行结束后，会生成一系列.map文件和.glg日志文件，这些是AutoDock对接时读取的能量地图。

7. 运行AutoDock对接并读懂结果文件

Grid算完，对接就是一个参数文件和一条命令的事。但很多人卡在这一步的反而是看不懂输出结果，这里把完整流程和结果判读一起讲透。

7.1 生成DPF对接参数文件

在ADT图形界面中：

1. Docking -> Macromolecule -> Set Rigid Filename，选择受体PDBQT。
2. Docking -> Ligand -> Choose，选择配体PDBQT。
3. Docking -> Search Parameters -> Genetic Algorithm，保持默认的2,500,000次评价（ga_num_evals），这是中等搜索强度，一般小分子配体够用。
4. Docking -> Docking Parameters -> Accept，接受默认的对接参数。
5. Docking -> Output -> Lamarckian GA，保存为dock.dpf。

如果你的配体柔性键很多（超过8个可旋转键），建议把ga_num_evals提高到25,000,000，搜索次数从默认的10次提高到50次，否则结果容易陷入局部最优。

DPF文件里面核心的几个参数含义如下表所示：

7.2 对接命令与运行过程监控

autodock4 -p dock.dpf -l dock.dlg

运行时间取决于系统性能和搜索空间大小。2,500,000次评价的小配体对接，在普通服务器上大约需要几分钟到十几分钟；25,000,000次就要半小时以上。

运行过程中可以实时看进度：

tail -f dock.dlg

里面会显示当前正在进行第几次遗传算法搜索（Run）、当前最佳能量值等信息。如果发现能量值在正负几千之间乱跳，多半是受体和配体初始位置重叠严重，需要检查初始坐标是否放在了Grid Box内部。解决方法是把配体手动移动到一个合理结合位点附近的初始位置，或者用--n参数指定随机初始位置。

7.3 从DLG文件中提取结合能信息

dock.dlg是文本文件，可以直接用文本编辑器打开。找到每个Run结束后的能量统计部分：

DOCKED: FINAL INTERMOLECULAR ENERGY = -8.23 DOCKED: FINAL TOTAL ENERGY = -8.15 DOCKED: ESTIMATED FREE ENERGY OF BINDING = -7.52 kcal/mol DOCKED: FINAL INTERNAL ENERGY = -0.30

这里需要注意三个核心数据的区别：

• FINAL INTERMOLECULAR ENERGY：受体与配体之间的非键相互作用能，是筛选结合模式时最常用的指标。
• ESTIMATED FREE ENERGY OF BINDING：估算的结合自由能，考虑了去溶剂化、构象熵等校正项，学术表达中常用这个值。一般负值越小如-9.5比-6.0结合更强。
• FINAL TOTAL ENERGY：体系总能量，包含了配体内部的扭曲能量。

在dock.dlg的每个Run后面还有RMSD值，用于判断构象差异。ADT里可以通过Analyze -> Conformations -> Load打开DLG文件，查看所有对接构象并按能量排序和聚类。聚类容忍度rmstol为2.0时，聚类中成员数越多，说明该结合模式在搜索过程中越稳定，可靠性越高。

实际经验是：同一个配体多次对接得到的构象如果聚成一类且成员占比超过80%，那么该构象的可信度就高。如果前十名结合能的构象RMSD都超过4埃，说明结合模式没有收敛，可能搜索空间没设好或者柔性键设置有问题，需要回头调整Grid Box或配体柔性键。

7.4 批量对接时如何自动提取结果

如果你需要对接几十个配体，手动从DLG里复制能量信息效率极低。可以用grep命令批量提取：

grep "ESTIMATED FREE ENERGY OF BINDING" dock.dlg

或者写一个简单的脚本循环处理所有DLG文件：

for f in *.dlg; do echo "=== $f ===" grep "ESTIMATED FREE ENERGY OF BINDING" "$f" done

这样批量筛选出的最优配体，再回到ADT或PyMOL里做可视化验证。

8. 我踩过的坑和给你的建议

最后分享几个我做对接这几年实打实踩过的坑，有些是安装阶段就埋下的隐患，有些是对接结果分析时的思维陷阱。

8.1 安装阶段的教训：贪新反而麻烦

AutoDockTools这个工具链，坚持稳定优先，不要追求最新。我早期试过在完全没有X11库的最小化服务器上硬装MGLTools，结果图形界面起不来，后来明白了：ADT的图形界面不是必需品，用命令行脚本配合PyMOL可视化，照样能完成全部工作。MGLTools里的prepare_receptor4.py和prepare_ligand4.py才是真正的核心工具，Graphical UI只是一个套壳。

另外AutoDock 4.2.6的configure脚本在老系统上很乖，但新系统的编译器版本和一些头文件路径变了，我遇到过make时找不到X11/Intrinsic.h的情况，装好libxt-dev后就解决了。遇到编译报错不要慌，看提示缺什么就装什么，一般不会卡太久。

8.2 对接结果的验证：结合能不是唯一标准

很多人只看结合能大小就下结论，说结合能负值越大越好。实际上，AutoDock的评分函数对具体体系的适用性是有偏差的，不同配体之间的结合能对比才更有参考意义。我在帮同事筛药时，遇到过两个结构相似的配体，一个输出-9.3，另一个输出-7.8，但前者在分子动力学模拟中并不稳定，最终实验也验证了后者活性更好。

所以合理的工作流是：AutoDock对接做初筛，选出前几个结合模式，然后用分子动力学模拟验证复合物稳定性，或者用MM-PBSA/GBSA等更精确的方法重算结合自由能。

8.3 关于Vina的选择

AutoDock Vina作为AutoDock 4的替代方案，速度和精度都有优势。但AutoDock 4仍在科研中使用的原因在于它保留了柔性侧链对接、更丰富的力场参数和可解释性强的DLG文件，适合做精细研究和教学。我的建议是安装AutoDock 4的同时也装上Vina，日常初筛用Vina，精细分析和柔性残基研究用AutoDock 4，两者互为补充。这次写的是AutoDock 4的完整流程，后面有时间我会再单独写一篇Vina的对接实操，把两者的结果对比也一并放出来。

8.4 一个小建议：规范命名与存档

对接流程涉及的中间文件很多：原始PDB、加氢后的PDB、PDBQT受体、PDBQT配体、GPF、GLG、DPF、DLG、map文件……如果不规范命名，过两周你可能连哪个对应哪个都分不清。我的习惯是建立如下目录结构：

project/ ├── input/ # 原始PDB和配体文件 ├── prep/ # 处理后的PDBQT文件 ├── grid/ # GPF、GLG和map文件 ├── dock/ # DPF、DLG文件 └── results/ # 提取出的最终对接结果

每个文件加上体系名前缀（比如1abc_receptor.pdbqt、1abc_ligand.pdbqt、1abc_dock.dgl），这样即便过了几个月回来翻数据，也能一眼看明白是哪个体系的结果。

分子对接这个领域入门容易，精通难。工具安装只是第一步，真正积累的是对受体结构、口袋特征、评分函数适用性的理解。把AutoDockTools、AutoGrid和AutoDock这一套跑通，你就有了一个可靠的基础平台，后面不管是做虚拟筛选、酶工程改造，还是蛋白质-配体相互作用研究，都能在这个平台上继续延伸。希望这篇能让你一次顺利跑通。