本文收录于专栏开源小分子生成和设计实践—— 专栏覆盖生成分子、对接、SA 评估、可合成性筛选等完整链路。你做 AI 药物设计时大概率撞过这堵墙Pocket2Mol / ResGen / TargetDiff 生成的分子 Vina 打分漂亮但药化同事摇头——“根本合不出来”。北大来鲁华团队 2026-09-23Nature Machine Intelligence发表的 SynCraft 把这堵墙叫synthesis cliff。这篇拆解机制与实战把 GLM-5.3 接入源码端到端跑通修 9 个上游 bug。近期有中南大学团队有同名模型请看下一篇SynCraft (中南大学版): 合成路线规划与 ADMET 评估一体化平台——在线使用 离线部署实录关键字SynCraft合成悬崖分子编辑LLM 推理RDKitAutoDock VinaPLIPGLM-5.3目录一、为什么写这篇二、论文核心机制逻辑推理与图编辑解耦三、5 项关键数字基准压倒性优势四、PLK1/RIPK1/Mpro 3 大实战案例五、源码改造把 GLM-5.3 加进 skill pipeline六、本地复现核心引擎 GLM-5.3 实测七、局限与边界八、待追踪锚点一、为什么写这篇SBDD 项目里最浪费时间的循环生成模型出 100 个分子 → Vina 排序挑 top-20 → 药化评审 reject 18 个理由例如糖苷键无法构建 / 邻位氨基恶唑酮不常见 / 四取代立体中心合成路径极长→ 浪费一周 docking 评审。SynCraft 直接针对最后一步——让 LLM 在保留 3D 结合模式的前提下预测最小化的原子级编辑把好看不中用的分子拉到可合成 仍结合。二、论文核心机制逻辑推理与图编辑解耦2.1 为什么不用 LLM 直接生成 SMILESLLM 输出新 SMILES 长期饱受语法脆弱性困扰——一个括号错位全局错写 30 原子的 SMILES 失败率很高。SynCraft 的核心创新是逻辑推理与图编辑彻底解耦SMILES PDB → 1. RAG 检索 5 个 cliff-pair 相似坏→好案例 → 2. Vina PLIP 把 3D 接触翻译成自然语言约束 → 3. LLM CoT 推理GLM-5.3/Gemini/DSv4/GPT-5.2 都行 [REASONING] 分析合成障碍 [EDITS] 8 类原子级操作 → 4. RDKit reconstruct_from_sequence 确定性执行 → 5. Vina 重对接验证结合模式未崩2.2 8 类原子级编辑操作论文 Table S2操作签名3,272 cliff-pair 分布DEL_ATOM[map_num]5,329ADD_ATOM[new_id, symbol]4,920MUTATE_ATOM[map_num, new_symbol]—DEL_BOND/ADD_BOND/CHANGE_BOND[a, b, type]ADD_BOND 5,668 / DEL_BOND 496 / CHANGE_BOND 119SET_CHIRAL/SET_BOND_STEREO[id, tag]SET_CHIRAL 4,720 / SET_BOND_STEREO 17STOP[]终止为什么用 JSON 而非 SMILES每条命令只动 1 个元素失败也只是局部回滚不会整体崩。2.3 Interaction-aware promptingPLIP 把关键接触翻译成自然语言约束喂给 LLM[CRITICAL BIOLOGICAL CONSTRAINTS; PRESERVE] - Atom with map number [10] forms a critical Hydrogen Bond with LYS43.A - Atom with map number [15] participates in Pi-Stacking with HIS163.A ...LLM 生成编辑时避开这些不能动的原子——RIPK1 案例救回 42 个 shelved 分子81% 保留 ≥50% 关键接触74% Vina 持平或更优。三、5 项关键数字基准TanimotoSynCraft最强基线Pocket2Mol 0.542.7%ChemProjector ~30%Pocket2Mol 0.628.4%ReaSyn 15.4% / SynFormer 14.1%ResGen 0.544.7%—ResGen 0.629.1%22.0%LLM 通用性Pocket2Mol 0.5—39-66%4 后端—4 个 LLM 后端实测全部 39-66% 远超基线gemini-2.5-pro/gpt-5.2cloudsway 代理/deepseek-v4-pro/deepseek-v4-flash——架构设计的优越性不是单一模型涌现。四、3 大实战案例4.1 PLK1 lig-886与人类专家策略一致AI 生成的高分候选含2,5-二甲基哌嗪会引入 2 个手性中心 → 最多 4 种立体异构体混合物。SynCraft LLM 推理“该修饰建议通过移除环上的两个甲基来解决将该片段彻底简化为非手性、对称的哌嗪环。”论文 Figure 3 显示 SynCraft 严格执行该编辑而人类资深专家最终合成的化合物 IIP0944 采用完全相同设计——去甲基保留纯哌嗪环。4.2 RIPK1把被雪藏的高分候选救回来42 个对接分数极高但合成部门判定难度过大被放弃的候选启用 interaction-aware prompting 重审案例 1难直接偶联的 C-C 键 → 氧醚键连接保留 Asp156 等关键氢键网络案例 2刚性稠环 → 平面嘧啶骨架保留氢键受体拓扑统计81%34/42保留 ≥50% 关键接触74%31/42Vina 持平或更优。4.3 Mpro 端到端 agent skillTargetDiff 生成 47 个 Mpro 候选化学软件评估仅1 个可直接合成。SynCraft 全自动化跑完“成功拯救其中70%32/46的不可合成候选物”Vina 打分分布几乎完美重叠——整体活性未发生降级。五、如果你想用其它LLM那就源码改造把 GLM-5.3 加进 skill pipeline仓库原配pipeline.py的 SUPPORTED_LLMS 只有论文测过的 3 个 LLMgemini-2.5-pro / gemini-3.1-pro / deepseek-v4-pro分支路由只认deepseek-v4-pro走带对接约束的脚本其他走 Gemini 脚本。国产 GLM-5.3z.ai 直连默认不在内——以下是我把 GLM-5.3 加进去的完整 diff。5.1 改动总览两条路线接入 GLM-5.3 有两条路线先选路线再动手路线 Apatch 原版推荐路线 B新建_procopy论文复现保真做法直接在原inference_dsv4.py上改 4 处复制出_pro系列新文件再改涉及文件inference_dsv4.pyinference_dsv4_bioactivity.pypipeline.py新建inference_dsv4_pro.py/inference_dsv4_pro_bioactivity.pypipeline.py优点快、无冗余文件、升级仓库时 diff 清晰原版一字未动论文复现锚点完整讲解顺序5.2 - 5.4改动 → 调用 → 验证5.5附录仅 2 处差异两条路线的共同前提是pipeline.py认得glm-5.3路线 A 的改动 4路线 B 见 5.5 差异 2分歧只在 inference 脚本本身。本文实测以路线 A 为主线。5.2 在原inference_dsv4.py上改4 处不新建_pro版——直接 patch 原inference_dsv4.py即可接入 GLM-5.3。注意inference_dsv4_bioactivity.py的_make_client()和worker_task()都是文件内 inline 定义不复用主脚本所以改动 1/2 要整体复制过去--model保持requiredTrue不必改pipeline 显式传rescue_llm。改动 1_make_client()加 env var fallback必改def _make_client(): base os.environ[DSV4_BASE_URL] - key os.environ[DSV4_API_KEY] key (os.environ.get(DSV4_API_KEY) or os.environ.get(GLM_API_KEY) or os.environ.get(OPENAI_API_KEY) or ) if not key: raise RuntimeError(No API key. Set DSV4_API_KEY / GLM_API_KEY / OPENAI_API_KEY)为什么不改会怎样你的 key 在~/.bashrc是export GLM_API_KEY***原版os.environ[DSV4_API_KEY]拿不到 →KeyError 崩。OpenAI 2.x SDK 还会同时校验OPENAI_API_KEY所以加 3 层 fallback 才稳。改动 2worker_task()加 GLM thinking 分支必改extra_kwargs {} if reasoning_effort: if model_name.startswith(cloudsway-gemini) or gemini in model_name.lower(): extra_kwargs[extra_body] {thinking: {type: enabled, level: reasoning_effort}} elif model_name.lower().startswith(glm-): # z.ai OpenAI-compat: GLM-5.x uses thinking field, NOT reasoning_effort extra_kwargs[extra_body] {thinking: {type: enabled}} else: extra_kwargs[reasoning_effort] reasoning_effort为什么不改会怎样z.ai 的 OpenAI-compat endpoint 用的是thinking字段reasoning_effort会被 z.ai 服务器 422 拒所以 GLM 必须走extra_body{thinking:...}不能走 OpenAI 的reasoning_effort字段。改动 3--modelargparse 默认值推荐改-p.add_argument(--model, requiredTrue, helpModel name as expected by the endpoint.) p.add_argument(--model, defaultglm-5.3, helpModel name as expected by the endpoint. Default: glm-5.3 (z.ai Coding). Pass deepseek-v4-pro / cloudsway-gpt-5.2 / deepseek-v4-flash etc to override.)为什么不改会怎样原版requiredTrue必须显式传。改 default 后直接python inference_dsv4.py --output ...就能跑对 GLM 用户友好。pipeline 走 subprocess 时显式--model rescue_llm覆盖所以默认值不影响 skill 调用。改动 4pipeline.pySUPPORTED_LLMS 分支skill 集成必改SUPPORTED_LLMS { gemini-2.5-pro: Google Gemini 2.5 Pro (API-only). thinking_modehigh., gemini-3.1-pro: Google Gemini 3.1 Pro (API-only)., deepseek-v4-pro: DeepSeek V4 Pro — MIT OPEN-WEIGHTS. Reproducible long-term., glm-5.3: Zhipu GLM 5.3 (z.ai Coding endpoint). Direct HTTP, MIT-style license. Uses extra_body{thinking:...}, not reasoning_effort., } -if rescue_llm deepseek-v4-pro: # DSv4-pro and GLM-5.3 both go through the bioactivity flow (Vina PLIP). if rescue_llm in (deepseek-v4-pro, glm-5.3): inference_script inference_dsv4_bioactivity.py else: inference_script inference_bioactivity_constrain.py为什么不改会怎样SUPPORTED_LLMS 没 glm-5.3 →_validate_llm(glm-5.3)直接 raise ValueError。_bioactivity版把改动 1env fallback 改动 2GLM thinking 分支复制进inference_dsv4_bioactivity.py——它的_make_client()/worker_task()与主脚本各自独立定义改主脚本不会传导。5.3 调用方式用户视角# DSV4_* env两条路线都吃这个 export DSV4_BASE_URLhttps://api.z.ai/api/coding/paas/v4 export DSV4_API_KEY$GLM_API_KEY python inference_dsv4.py \ --input input.json --dataset P2M --output out.jsonl \ --pass-k 5 --num-processes 8 # 默认 modelglm-5.3无需 --model注意DSV4_BASE_URL必须设_make_client()硬读它只设OPENAI_*会 KeyErrorkey 丢了不致命——fallback 链DSV4_API_KEY → GLM_API_KEY → OPENAI_API_KEY兜底。bashrc里有 key 的兜底方案针对 Hermes 沙箱 env 透传不可靠def _load_key() - str: 从 ~/.bashrc / ~/.zshrc / ~/.profile fallback 读 GLM_API_KEY。 if os.environ.get(GLM_API_KEY): return os.environ[GLM_API_KEY] for rc in (~/.bashrc, ~/.zshrc, ~/.profile): with open(os.path.expanduser(rc)) as f: for line in f: if line.startswith(export ) and GLM_API_KEY in line: val line.split(, 1)[1].strip().strip().strip() if val and not val.startswith(*): return val return 验证兜底env -u GLM_API_KEY python run_glm53.py ...仍能跑通5/4 PASS 80%。5.4 验证脚本# 1) 单分子 smoke test4 处改动后必跑 export DSV4_BASE_URLhttps://api.z.ai/api/coding/paas/v4 export DSV4_API_KEY$GLM_API_KEY python src/inference_dsv4.py \ --input assets/unsolved.json --dataset P2M \ --output _test.jsonl --pass-k 1 --num-processes 1 \ --max-tokens 8192 --reasoning-effort high # 预期: 1 分子 ~150s 完成, statusTrue, edits JSON 落盘 # 2) skill smoke test确认没破坏旧路径 cd skill python -m pytest tests/test_smoke.py -v # 预期: 7/7 PASSED实测 5 分子 batch4/5 PASS (80%)avg ~158s/call34-326s。5.5 【路线 B】与路线 A 的全部差异仅 2 处路线 B 复制_pro系列新文件、原版一字不动。相对路线 A 只有两点不同差异 1inference_dsv4_pro_bioactivity.py的 docstring 命令名line 18- python3 inference_dsv4_bioactivity.py \ python3 inference_dsv4_pro_bioactivity.py \--model仍requiredTruepipeline 显式传rescue_llm不会被默认值污染_make_client()与 pro 版同源自动继承 env fallback。差异 2pipeline.py分支路由的脚本名换成_pro版if rescue_llm in (deepseek-v4-pro, glm-5.3): - inference_script inference_dsv4_bioactivity.py # 路线 A inference_script inference_dsv4_pro_bioactivity.py # 路线 BSUPPORTED_LLMS 加glm-5.3的 diff 与路线 A 改动 4 完全相同不再重复。5.6 【两路线通用】run_glm53.py——本地 ad-hoc wrapper为什么需要这个pipeline.py走subprocess.run(cmd, ...)multiprocessing.PoolHermes 沙箱启动子进程时 env var 偶尔丢_make_client()fallback 已加但 subprocess 路径下仍可能中招。本地 ad-hoc 跑用 inlineworker_task保证 GLM-5.3 端到端跑通GLM_BASE_URL https://api.z.ai/api/coding/paas/v4 # 直连 MODEL glm-5.3 def _load_key() - str: 从 ~/.bashrc / ~/.zshrc / ~/.profile fallback 读 GLM_API_KEY。 if os.environ.get(GLM_API_KEY): return os.environ[GLM_API_KEY] for rc in (~/.bashrc, ~/.zshrc, ~/.profile): with open(os.path.expanduser(rc)) as f: for line in f: if line.startswith(export ) and GLM_API_KEY in line: val line.split(, 1)[1].strip().strip().strip() if val and not val.startswith(*): return val return # ... 加载 key 后 os.environ[DSV4_BASE_URL] GLM_BASE_URL os.environ[DSV4_API_KEY] key from inference_dsv4 import worker_task # 直接 inline 调用 worker_task绕过 subprocess multiprocessing.Pool用法python3 run_glm53.py CC(O)Nc1ccc(O)cc1 # 单分子 python3 run_glm53.py --input /tmp/glm53_input.json --dataset P2M # 批量六、本地复现核心引擎 GLM-5.3 实测6.1 实测环境一个 syncraft conda env 全包项值操作系统Ubuntu 22.04.5 LTSconda envsyncraftPython 3.12.14磁盘占用1.3 GBrdkit2026.3.1完整依赖openbabel / biopython / pdb2pqr / vina / meeko / plip / openai / loguru / httpx / pydantic / litellm / tqdm / gemmi5 个 pre-prepared 受体7L12 / 7YDX / 2YAC / 5mo4 / 8F2BLLMGLM-5.3z.ai Coding 直连6.2 一键安装实测通过conda create -n syncraft python3.12 -y conda activate syncraft conda install -c conda-forge -y rdkit openbabel numpy biopython pdb2pqr scipy pip install vina1.2.2 meeko0.5 plip2.3 openai1.0 \ httpx0.25 loguru pydantic2.0 pip install tqdm litellm gemmi # setup.sh 漏装, README 提了没跟 cd skill pip install -e . cd ..3 个或许要踩的坑biopython 包名Bio/大写import Bio不import biopythonmeeko 需要 scipy先装 scipy 再装 meeko否则RuntimeError: MoleculePreparation requires scipysetup.sh 漏装 3 个 depstqdm / litellm / gemmi跑pytest tests/test_smoke.py全补齐后7/7 PASSED6.3 核心引擎100 个 cliff-pair round-tripimport sys, json; sys.path.insert(0, src) from utils import reconstruct_from_sequence from rdkit import Chem examples json.load(open(assets/reasoning.json))[:100] ok 0 for ex in examples: src ex[source] m Chem.MolFromSmiles(src) if not m: continue for j, a in enumerate(m.GetAtoms()): a.SetAtomMapNum(j1) try: res reconstruct_from_sequence(Chem.MolToSmiles(m), ex[edits], sanitizeTrue) if res and res.get(mol): ok 1 except: pass print(fRound-trip: {ok}/100) # Round-trip: 100/1006.4 GLM-5.3 推理实测5 分子z.ai 直连调用链run_glm53.py → inference_dsv4.py:worker_task(modelglm-5.3) → _make_client() → DSV4_BASE_URLhttps://api.z.ai/api/coding/paas/v4 → DSV4_API_KEY$GLM_API_KEY (bashrc fallback) → OpenAI(...) → z.ai Coding endpoint → extra_body{thinking: {type: enabled}} ← GLM 用这个, 不是 reasoning_effort5 分子实测#分子status耗时editsGLM 诊断1复杂吲哚烷多手性✅317s6×DEL_ATOM两个手性中心建议全面简化2吲哚✅63s3 DEL 2 ADD 2 ADD_BONDNH 稳定性问题3acetaminophen✅34s3 ADD 3 ADD_BOND酚 -OH 是 developability 风险4咖啡因❌326s3 次解析失败LLM 返回无[REASONING]块5protocatechuyl alcohol✅49sADD_ATOM ADD_BOND邻苯二酚易氧化通过率 4/580%avg ~158s/call34-326s。#1 真实 LLM 推理节选“The primary synthetic liability in the source molecule is the chiral secondary alcohol on the amide side chain… would require an enantioselective route… the secondary alcohol itself is a classic metabolic soft spot…”——与论文 PLK1 案例去甲基消除手性冗余同款策略。⚠️ 沙箱 env 透传坑Hermes 终端启子进程时DSV4_BASE_URL/DSV4_API_KEY偶尔丢OpenAI 2.x SDK raiseMissing credentials。run_glm53.py从~/.bashrcfallback 重读env -u GLM_API_KEY python run_glm53.py仍能跑通。skill pipeline 内的同款问题见 6.5 阶段④ bug#4。6.5 端到端打通9 个上游 bug 与实测结果把rescue_llmglm-5.3走完整 skill 流程Vina → PLIP → GLM → RDKit 重放 → Vina 重对接上游仓库 9 个 bug 按数据流顺序逐个爆雷——全部与 GLM 无关是 bio 脚本在新环境下的兼容问题#阶段症状根因 → 修复1① VinaFileNotFoundError: vinapip vina 只有 Python API 无 CLI → conda-forge 装 SYNCRAFT_VINA_BINpipeline.pychild_env 注入 PATH6② 拼 complex PDBPLIP 接触的原子索引全错位 1base_idx取 PDB 最后一行——那是TER记录 → 扫全文取最大 ATOM serialextract_interaction.py:937② 拼 complex PDBPLIPexcluded_ligands/空报告meeko 写的配体行是ATOM残基名UNLPLIP 只认HETATM非 UNL → 重写为HETATMLIGPDB col 18-208② 拼 complex PDBPLIP 空报告最难找与 #7 叠加PDBQT 元素列写的是 AutoDock typeA/OA/HDOpenBabel 键感知失败 → 配体碎成 11 个 1-原子残基被 PLIP 尺寸过滤 → 映射回标准元素A→C, OA→O, HD→H…重写该列2③ PLIP 解析FileNotFoundError: plipPool worker 丢 PATH同 #1 机制→SYNCRAFT_PLIP_BIN child_env5③ PLIP 解析跑完找不到 reportPLIP 3.x 输出pdb_stem_report.xml非裸report.xml→ glob*_report.xml3④ GLM 推理Failed to load assets/reasoning.json子进程 cwd 下相对路径失效 →--golden-examples显式传绝对路径pipeline.py:3204④ GLM 推理DSV4_BASE_URL/API_KEY must be set子进程 env 透传丢失 →child_env {**os.environ}pipeline.py:3369⑤ RDKit 重放edit 落错原子产物原料静默失效_apply_edits用 enumerate 重编号LLM 引用的是sml_mapped编号 → 优先传 rescue 记录的sml_mappedpipeline.py:350修复后端到端全绿acetaminophen → RIPK1 7YDX路线 A pass_k2阶段输出① Vina 对接dock_original -5.438 kcal/mol②③ PLIP 提取酚 OHatom 12↔ MET95.A 氢键注入[CRITICAL BIOLOGICAL CONSTRAINTS; PRESERVE]④ GLM-5.3 推理识别 paracetamol 骨架 NAPQI 毒性风险避开 PLIP 标记的酚 OH⑤ RDKit 重放 过滤MUTATE_ATOM ADD_ATOM ADD_BOND→CS(O)(O)Nc1ccc(O)cc1dock -5.438 →-5.553反升 0.12sim0.46 →successTrue化学解读乙酰苯胺 →甲磺酰苯胺Ar-NH-COCH₃ → Ar-NH-SO₂CH₃——一步磺酰化可合成消除 NAPQI 毒性代谢物且 PLIP 标记的酚 OHMET95 氢键未动。pass_k 对照实测同分子同 seedpass_k耗时GLM-5.3 输出结果193 sSTOPsuccessFalse2254 sMUTATE_ATOM ADD_ATOM ADD_BONDsuccessTrue生产用途建议 pass_k≥2。修改分布src/extract_interaction.py6 处 skill/syncraft/pipeline.py5 处 src/inference_dsv4.py3 处 src/inference_dsv4_bioactivity.py1 处详见 5.2。原版备份inference_dsv4.py.orig.bak。6.6 仓库 6 个 inference 脚本的 LLM 支持速查脚本支持的 modelinference_enhanced.pygemini/gemini-2.5-proinference_bioactivity_constrain.pygemini/gemini-2.5-proinference_dsv4.py已 patchglm-5.3默认/cloudsway-gpt-5.2/deepseek-v4/deepseek-v4-flashinference_dsv4_bioactivity.py已 patchglm-5.3/deepseek-v4-proinference_dsv4_pro.py路线 B copyglm-5.3默认inference_dsv4_pro_bioactivity.py路线 B copyglm-5.3/deepseek-v4-progemini-3.1-pro不是笔误——是论文 Table 1 用的 Gemini 系列最新推理模型Google 公开 API 暂不暴露。七、局限与边界SimpRetro 找得到路线 ≠ 实验室一定能合成——判据是 SimpRetro 30 分钟搜逆合成路线高收率/稳定性/纯化都未过实验验证Interaction-aware constraint ≠ 实测 affinity——PLIP 翻译的必须保留是几何接触预测不是 ΔG 实验值手写 edit path 极易踩雷——atom-map 编号必须与 LLM 看到的sml_mapped一致编号错位正是 6.5 阶段⑤ bug#9 的根因。正确用法让 LLM 给或跑IterativeMCSExtractor让仓库帮你算GLM-5.3 解析失败咖啡因 3 次 retry 都无[REASONING]/[EDITS]块仓库 fallback 只重发请求未改 model 或 prompt沙箱子进程 env 透传不可靠根因是 Pool worker 与 subprocess 链路丢 env/PATH已在 pipeline.py 用child_env {**os.environ}显式注入修掉见 6.5 阶段④ bug#4极端场景仍建议run_glm53.pywrapper 兜底八、待追踪锚点真实 prospective 测试——AI4AI 提议固定合成预算比较丢弃 / template projection / SynCraft 修复三条路线数据 archive 公开——论文配套数据 Figshare 10.6084/m9.figshare.33201870解析失败 fallback——加 model 切换或 prompt 改写避免 3 次 retry 全失败参考来源Junren Li, Luhua Lai. SynCraft. Nature Machine Intelligence, 2026. DOI 10.1038/s42256-026-01304-xarXiv:2512.20333完整方法稿SynCraft-Core GitHubZenodo release: 10.5281/zenodo.21869222Figshare 数据集: 10.6084/m9.figshare.33201870第一作者主页 junren.li系列导航上一篇 SynCraft中南大学版: 合成路线规划与 ADMET 评估一体化平台——论文详解加 Linux 离线部署实录 专栏全集开源小分子生成和设计实践我的专栏蛋白 / 多肽分子模拟 / 动力学分子对接 / CADD / 工具其他开源蛋白结构推理预测分子模拟基础UCSF DOCK系列agent智能体系列开源蛋白生成方法实践分子动力学模拟-AmberrDock系列化学大模型介绍2025蛋白药物设计-原理与案例剖析分子动力学模拟-GromacsLeDock系列我胡师兄说药开源多肽设计模型和方法实践結合自由能CADD中的机器学习模型siRNA药物设计模型开源多肽性质预测高效计算基本配置小分子药物设计-原理与案例剖析ASO药物设计模型多肽药物设计-原理与案例剖析作用于DNA/RNA的药物设计实践开源小分子生成和设计实践开源药代动力学模拟软件