HuDiff在抗体人源化项目中的工程化落地

在之前的文章中，我们讨论了HuDiff如何将抗体人源化重新表述为一个条件生成问题：保留抗体的互补决定区，由模型重新生成更符合人源抗体分布的框架区。与传统的"选择人源胚系模板---移植CDR---设计回复突变"相比，这种方法不再要求研究人员预先确定唯一的人源骨架，而是允许模型在更大的序列空间中生成多个候选。

但真正把HuDiff用于抗体研发后，很快会发现，模型能够生成序列，只是整个项目的起点。

一个人源化模型可以在几分钟或几小时内产生大量候选，但这些候选是否真正不同、是否提高了人源性、是否保持了CDR构象、是否影响VH--VL装配、是否引入新的修饰风险，以及最终应该选择哪些序列进入实验，都不是模型输出文件能够直接回答的问题。

因此，HuDiff的实际落地并不是一次简单的模型推理，而是需要建立一套从输入质控、候选生成、序列筛选、结构评价到实验交付的完整流程。

首先要明确：HuDiff在项目中承担什么角色

HuDiff包含面向常规抗体和纳米抗体的人源化模型，公开代码提供了训练、微调、评价和推理流程，相关模型权重和预处理数据可以从公开模型仓库获得。对于抗体人源化，模型可以接受重链和轻链序列，也可以读取包含抗体信息的FASTA文件进行推理。

从论文方法看，HuDiff的核心能力是：在给定CDR条件的基础上，对可变区框架进行生成，不依赖预先指定的人源化模板。论文中的实验结果说明，这种生成方式有可能在提高人源性的同时保留抗原结合能力。

但在工程应用中，必须给HuDiff一个准确的定位：

HuDiff是候选序列生成器，而不是最终候选决策器。

模型学习的是人抗体序列中的统计分布及CDR与框架之间的组合规律。它能够回答"在当前CDR条件下，哪些框架序列更像合理的人抗体"，却不能独立证明这些序列一定保持原抗体的亲和力、特异性、表达水平和稳定性。

因此，项目不能以"模型成功运行并生成序列"作为完成标志，而应将HuDiff放在更长的工作链条中：

亲本抗体分析 → HuDiff生成 → 序列质控 → 多样性评价 → 人源性评价 → 关键位点复核 → 结构评价 → 可开发性评价 → 综合筛选 → 实验验证。

模型部署：先解决可复现，而不是先追求跑通

HuDiff的代码仓库提供了环境配置文件，可以通过Conda建立运行环境，也提供了与容器运行相关的脚本。官方模型权重和部分预处理数据则存放在Hugging Face模型仓库中。

最基本的环境安装方式是：

# 下载HuDiff代码
git clone https://github.com/TencentAI4S/HuDiff.git
cd HuDiff

# 创建环境
conda env create -f environment.yaml
conda activate <environment_name>

完成环境配置后，需要下载抗体模型权重，并按照项目目录进行统一保存。例如：

hudiff_project/
├── checkpoints/
│   └── antibody/
├── input/
├── raw_output/
├── processed_output/
├── logs/
├── scripts/
└── reports/

HuDiff-Ab支持直接输入重链和轻链序列，例如

python antibody_scripts/sample_for_anti_cdr.py \
    --ckpt checkpoints/antibody/hudiffab.pt \
    --heavy_seq HEAVY_SEQUENCE \
    --light_seq LIGHT_SEQUENCE

也可以使用FASTA文件作为输入。

python antibody_scripts/sample_for_anti_cdr.py \
    --ckpt checkpoints/antibody/hudiffab.pt \
    --anti_complex_fasta data/fasta_file/7k9i.fasta

真正用于项目时，不应只保存最终序列，还需要同时记录：

• 代码版本或Git commit；

• 模型权重名称和校验值；

• Python及依赖环境；

• GPU和CUDA环境；

• 输入序列；

• 随机种子；

• 采样参数；

• 原始输出文件；

• 运行日志；

• 结果处理脚本版本。

这一步看起来偏向软件工程，但它决定了半年后能否复现同一批结果，也决定了更换模型、重新采样或调整参数后，能否判断结果差异究竟来自哪里。

对于研发项目而言，"这次能够跑通"远远不够，更重要的是"下一次还能按照相同条件重新得到并解释结果"。

在运行模型之前，先建立亲本抗体基线

生成模型容易让人形成一种错觉：只要把序列输入模型，再从结果中选择最像人的候选即可。

实际上，在开始生成之前，必须先回答亲本抗体本身是什么状态。

首先需要进行序列标准化 。重链和轻链应统一采用同一种编号体系，明确FR1、CDR1、FR2、CDR2、FR3、CDR3和FR4的边界，并保留不同编号体系之间的映射关系。抗体工程中很多经典位点仍采用Kabat编号，而结构分析和序列统计又经常使用IMGT编号，如果不提前建立映射，很容易出现同一个位点被重复统计或错误解释的问题。

随后需要建立亲本抗体的序列基线，包括最接近的人源germline、VH和VL分别的人源相似性、各FR区域的差异、潜在PTM位点、理论pI、净电荷和明显的疏水性风险。

如果存在可靠的实验结构，应优先使用实验结构。如果没有实验结构，则可以通过抗体结构预测建立结构基线，但需要同时记录预测置信度，并尽可能比较不同方法或不同随机种子之间的一致性。（后续会更新抗原－抗体结构预测比较，点击关注，及时查收最新推送～）

亲本基线的意义不在于制造更多指标，而在于提前定义后续比较对象。否则，候选生成后看到某个RMSD、某个人源性分数或某个PTM风险，很难判断它究竟是人源化引入的问题，还是亲本抗体本来就存在的特征。

候选生成之后，第一步不是排序，而是质控

HuDiff生成结果首先需要经过格式和序列检查。

最基本的检查包括：VH和VL是否完整、序列长度是否发生异常变化、是否存在非标准氨基酸、重轻链是否正确配对，以及CDR是否按照项目要求保持不变。

HuDiff的设计目标是在人源化过程中以CDR为条件生成框架，但实际运行时仍然不能跳过CDR核验。区域定义错误、输入格式错误、编号差异或脚本处理问题，都可能造成非预期变化。对于常规人源化项目，CDR序列发生改变的候选通常应被单独标记并排除，除非项目本身同时包含亲和力成熟或CDR优化任务。

完成基础质控后，还不能立即进入结构预测。生成式模型往往会产生一批高度相似的序列，其中部分候选可能只相差一个或少数几个氨基酸。

如果只进行完全去重，这些序列都会被当作独立候选。最终可能得到几十条"不同序列"，但它们实际上集中在少数几个非常接近的序列模式中。

因此，需要进一步计算候选之间的框架区差异，例如：

• VH框架区的Hamming distance；

• VL框架区的Hamming distance；

• VH与VL组合后的框架差异；

• 突变位点集合之间的相似度；

• 各FR位置的氨基酸分布。

由于不同候选的CDR本来就是相同的，直接计算完整Fv序列一致性会高估候选相似度。更合理的做法是以FR区域为主要对象进行聚类，将仅相差少量框架位点的序列归入同一个候选簇，再从每个簇中选择代表序列。

这一步能够把"生成了多少条序列"转化为"获得了多少种真正不同的人源化设计"。

人源性评价不能只看一个总分

完成去重和聚类后，需要评价候选序列的人源化程度。

最直观的方法是为VH和VL分别匹配最接近的人源germline，并计算候选序列与germline之间的一致性。但评价时不能只看完整Fv的总相似度，还应拆分到VH、VL以及FR1、FR2、FR3和FR4。

这种分区评价尤其重要。一个候选可能整体人源性较高，但某一条链仍保留较多动物源框架特征；也可能大部分FR已经接近人源germline，但少数关键结构区域变化较大。

此外，对于生成模型产生的序列，应谨慎使用"回复突变"这一概念。

传统CDR移植中的回复突变，是先确定一个人源骨架，再将其中部分位点恢复为亲本残基。HuDiff并不一定围绕某一个固定germline进行生成，因此候选中与亲本相同、与事后匹配germline不同的位点，更准确的表述是：

相对于匹配人源germline仍保留的亲本框架残基。

这种区分不是文字游戏。它决定了我们能否正确解释模型结果。某个残基与亲本相同，不一定说明模型"主动进行了回复突变"，也可能说明该残基本身在人抗体序列空间中仍然合理，或者与当前CDR组合具有较高的条件概率。

关键位点分析：从机械过滤转向风险分级

抗体人源化长期依赖一组经验性结构规则，例如Vernier zone、VH--VL packing残基、CDR支撑残基、埋藏残基和链间界面残基。

这些规则仍然有价值，但在生成模型时代，不宜简单转化为"出现突变即淘汰"。

更合理的方式，是先识别候选突变是否位于以下区域：

• 与CDR形成直接接触的FR位点；

• VH--VL界面位点；

• 经典Vernier zone；

• 重轻链packing区域；

• 蛋白内部埋藏位点；

• 参与局部氢键或疏水核心的位点；

• 距离CDR较近的框架残基。

随后再结合具体氨基酸替换判断风险。一个保守的疏水替换，与一个埋藏位点上的带电残基替换，虽然都发生在关键区域，但其风险显然不同。

经典位点更适合作为"重点复核标签"，而不是脱离具体结构环境的绝对禁区。否则，规则可能会一次性淘汰大量由模型生成、但实际结构仍然合理的候选。

这也是生成模型落地过程中一个重要变化：传统经验规则不再单独决定候选生死，而是进入序列、结构和性质联合评价体系。

结构预测的任务不是证明亲和力，而是排除明显风险

候选进入结构评价后，首先要明确结构预测能够回答什么。

对于人源化候选，结构分析主要用于判断：

• Fv整体折叠是否合理；

• VH和VL是否维持正常装配；

• CDR主链是否发生明显偏移；

• 关键FR突变是否引起局部结构变化；

• VH--VL界面是否出现明显重排；

• 不同随机种子预测结果是否稳定。

常用比较可以包括Fv RMSD、VH和VL分别的RMSD、各CDR主链RMSD以及关键位点邻域的局部变化。

但RMSD较低并不等价于亲和力保持。亲和力可能受到侧链取向、局部水网络、静电环境、构象分布和结合动力学影响，这些信息难以通过单一静态结构充分描述。

同样，抗原---抗体复合物预测也需要谨慎使用。若不同模型、不同种子或不同构象给出的结合姿态不一致，就不应基于某一个预测界面做精细的位点删除或保留决策。在缺少实验表位和复合物结构时，抗体自身结构通常比预测结合姿态更适合作为人源化候选的基础评价对象。

因此，结构预测在这一流程中的角色是：

排除明显不合理的序列，并为风险位点提供结构解释，而不是在计算阶段直接证明候选保持了功能。

可开发性评价必须与人源性同步进行

提高人源性并不意味着候选的可开发性会自动改善。

每一次框架区替换，都可能改变局部电荷、表面疏水性和化学修饰风险。因此，候选筛选中至少应检查：

• 新增N-连接糖基化基序；

• 脱酰胺化风险；

• 天冬氨酸异构化风险；

• 氧化风险；

• 非预期半胱氨酸；

• 理论pI和净电荷变化；

• 明显的疏水性增加；

• 潜在聚集和多反应性风险。

这里应重点比较候选与亲本之间的变化，而不是孤立地判断某个候选是否存在风险位点。

如果亲本已经具有某一潜在修饰位点，而候选没有新增同类风险，该问题属于亲本遗留风险；如果人源化后出现了新的高风险位点，则应作为候选筛选的重要依据。

候选评价最终不是寻找某个单项指标最高的序列，而是在三类目标之间寻找平衡：

提高人源性、尽可能保持结构与功能、避免可开发性明显恶化。

最终候选不应只是排行榜前几名

完成序列、结构和性质评价后，最简单的做法是建立一个总分，选取分数最高的若干条序列。

这种方式虽然方便，却可能掩盖指标之间的冲突，也容易选择出一批彼此高度相似的候选。

更合理的候选选择可以分为三步。

首先设置硬性排除条件，例如非预期CDR变化、序列异常、新增不可接受的高风险PTM或明显的结构预测异常。

随后对剩余候选进行风险分层，标记关键FR位点变化、CDR局部偏移、鼠源框架残基保留较多、低风险PTM增加或理化性质变化较大的序列。

最后，不是简单按照总分从高到低选择，而是从不同的序列簇、不同框架组合和不同风险水平中选择具有代表性的候选。

最终交付的候选集合可以同时包含：

• 人源性较高的候选；

• 结构保持较好的候选；

• 可开发性风险较低的候选；

• 在关键框架位点上更加保守的候选；

• 与其他候选具有明显序列差异的备选设计。

这种选择方式更适合实验验证，因为实验团队得到的不是多个近乎相同的序列，而是一组能够真正检验不同设计假设的候选。

结语

HuDiff降低了抗体人源化候选生成的门槛，但并没有消除抗体工程中的判断难题。

模型可以快速给出大量符合人抗体序列分布的框架组合，却不能独立决定哪些序列真正值得进入实验。候选数量也不等于候选多样性，人源性提高不等于功能保持，CDR序列不变不等于CDR构象完全不变，结构RMSD较低更不等于亲和力一定得到保留。

因此，HuDiff的实际落地不是"一键人源化"，而是建立一条完整的候选生产和评价流水线：

让模型负责探索序列空间，让规则负责识别已知风险，让结构和性质分析负责压缩候选范围，最终由实验决定哪些设计真正有效。

从这个意义上看，HuDiff带来的价值不只是替代传统人源化方法，而是改变了人源化项目的组织方式。过去的核心问题是"应该选择哪个人源模板"，而在生成模型参与之后，新的核心问题变成了：

面对模型产生的大量可能序列，我们如何建立一套可靠、可解释并能够持续被实验修正的决策体系。

这可能比单纯运行一个模型，更接近抗体人源化真正的工程化落地。