北京
2026年7月12日，一位開發者在GitHub上翻遍了所有開源倉庫，最終確認了一個事實：在酶生成設計中，沒有任何一個工具能獨立于方法或實驗室，用一種統一的方式把多個生成器的產出放在一起比較。那些號稱“基準測試”的腳本，要么和自家模型焊死，要么根本不管催化活性。于是，EnzyOrchestra v0.1.0 被推上了主分支。
酶生成設計早已不是能不能產出結構的問題。RFdiffusion、ProteinMPNN、Boltz?1 這一批工具已經把蛋白質骨架生成卷到了新高度，真正卡住前進腳步的是驗證環節。每個課題組都守著自己的一套評估腳本：用自己定的指標、自己選的閾值，只評價自家生成器產出的那批酶。如果你想問“針對同一個理論酶，哪個生成器整體表現更好”，現階段答案是“沒法比”。因為大家連“好”的定義都沒有對齊，比較就成了各說各話。
EnzyOrchestra 想做的就是把這層隔板拆掉。它不綁定任何一種生成方法，也不依賴實驗室條件，純粹是一個包裹在外的驗證層。在它內部，多個生成器（RFdiffusion2、ProHiFlo、AgentPLM）可以被同時調度起來，生成各自的酶結構，然后統一送到幾個“神諭”模塊里打分。這些神諭模塊相當于預配好的評價器，專門看一個酶設計在催化性能上是否靠譜。重要的是，生成器是被“編排”而不是被“導入”的——整個工具永遠不會把某個生成器當作運行庫直接引入，而是通過子進程調用，或者干脆吃預先生成好的PDB文件。這么設計就是為了杜絕和任何一個生成方法藕斷絲連，保證這套驗證流水線能真正跨方法運行。（當然，生成器本身的可執行文件和算力還是需要你自己準備。）
整個使用流程被壓縮成了兩個命令。如果想端到端跑一遍，用 run 模式：它會依次執行生成、驗證、出報告三步。如果手頭已經有了之前跑出來的結果，只想給出一份漂亮的對比表格，就用 report 模式，直接從結果集渲染一份馬克當或HTML報告，跑到哪里都不需要GPU。一個典型的干運行指令是：enzybench run --config enzybench_demo_config.json --dry-run --out report.html，它靠內置的夾具PDB文件就能把全流程走通，不用真去調用任何外部生成器。對應的報表渲染是：enzybench report --input enzybench_demo_config.json --format markdown，結果直接打印到標準輸出。
驗證打分的維度被精確化成了四個催化相關的指標。第一個是 pLDDT，反映結構層面的折疊置信度。第二個是 ΔΔG，即折疊能量變化，當前默認用一套開源的啟發式算法來估計，不需要額外商業軟件。第三是溶解性預測，輔助判斷這個酶能不能在表達體系里好好待著。第四是 CAI（密碼子適應指數），為異源表達做一些密碼子層面的優化參考。最終輸出的報告就是一張大表格，列標題依次為生成器名稱、pLDDT、ΔΔG、溶解性、CAI。你可以用馬克當格式離線審閱，也可以選HTML版本直接共享給團隊。
v0.1.0 作為一個功能性最小可行產品，已經被實際運行驗證過。代碼覆蓋率從第一個提交起就設了門禁——pytest --cov-fail-under=80，任何沒測到80%的地方都會直接阻斷合入。安全方面，SonarCloud 上暴露的5個原始漏洞（包括SHA指紋鎖定、路徑穿越 S8707、鎖文件問題）全部被關閉，相關證據通過 API 提交。針對無GPU的持續集成場景，工具提供了干運行模式，靠著內建夾具就能完成端到端冒煙測試，不依賴任何外部二進制文件。
不過開發者也很坦誠地劃出了三條邊界。第一，EnzyOrchestra 不做生物學驗證。干運行模式下看到的那些 ΔΔG 和 pLDDT 數值全部來自合成夾具，只是用來驗證流水線能不能跑通，不能用來推斷任何真實酶的性能。第二，它不替代濕實驗，也不打算提供實驗級的自由能數據。第三，它只是一個編排和比較層，生成能力本身仍然依賴你所選擇的生成器。換句話說，它的定位就是讓跨生成器的比較從“不可能”變成“可以標準化執行”，但絕不承諾幫你判斷哪個酶真的會工作。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
