#和铂医药##晶泰控股#
BPL：给生物实验发明一门标准语言
2026 年 5 月，恩和科技在 bioRxiv 上发布了论文，正式介绍了 BPL（Biology Protocol Language，生物协议语言） 及其配套管线 BPL-COGEN。

论文标题：Towards Autonomous Biology: Compiler-Verified Protocols as a Foundation for Real-World AI Execution
论文地址：http://t.cn/AXSfvhgQ

如果把生物学实验比作软件工程，那么目前行业的状态，大概相当于所有程序员都在用自然语言描述代码逻辑，然后期待另一个人能看懂并手动执行。BPL 要做的就是为生物实验提供一套等价于编程语言的形式化表达体系。

BPL 的架构分为六层，层层递进，每一层都在消除自然语言固有的某类模糊性。

声明层（Layer 1）是程序的材料清单。所有试剂、库存浓度、耗材类型、执行目标（人工操作或机器人），在这里必须以精确的物理属性声明。如此一来，就不再有「适量 CaCl₂」这样的模糊描述了，而是必须写明：固体还是溶液，浓度是多少，用哪种容器。

生物原生类型系统（Layer 2）是 BPL 最具独创性的设计。它覆盖 9 个物理基础维度（体积、质量、温度、时间、浓度、物质的量、压力、速度、长度），支持约 40 种实验室常用单位，并在编译时进行量纲分析。

这意味着什么？如果有人写了「向容器中转移 50 mg 液体」，即把质量单位给了体积参数，编译器会直接报错。所有物理常识都能被形式化为语言级别的约束，让这些错误在编译阶段就能被拦截。

这层设计直接呼应了那个典型失败案例：OpenAI 与 Ginkgo 合作的实验报告中，GPT-5 曾在细胞无蛋白合成实验里建议将水的用量设为负值。这是一个物理上不可能的操作。对于这类错误，Alex 直接回应说：「BPL 就是干这个事的。这种问题会被卡掉，会被打回来。」

14 种实验意图（Layer 3）是 BPL 与实验室操作之间的桥梁。恩和科技系统分析了 150 篇发表于 Nature Protocols、JoVE 和机构 SOP 库的协议，识别出覆盖分子生物学、生物化学、分析化学 95% 以上操作的 14 个原子操作单元：transfer（转移）、mix（混合）、incubate（孵育）、run_pcr（PCR 扩增）、centrifuge（离心）、pick_colonies（挑菌）……其中有一个值得单独说明的意图，是 manual，即保留人工操作的接口。

Alex 解释了这个设计的工程考量：「我们考虑到 human in the loop 的情况会发生。我已经有自动化仪器可以完成许多任务，但人类或未来的灵巧手在中间可能也会做一些 validation 等事情——这些事情就可以变成 manual。」这是一种务实的工程妥协：某些步骤本质上无法被完全形式化，但 manual 意图的存在让它们依然在 BPL 的管理框架之内。

容器状态引擎（Layer 4）实时追踪程序运行过程中每一个容器的状态（当前体积、内容物组成、温度、物理形态）并在每次操作后自动更新。这个设计来自恩和科技自身多年积累的工程实践。Alex 说：「我们以前 Cell2Cloud 铸造厂每一个 96 孔板，每一个 well 都有它的 status，它现在到底是在什么样的状态——加了多少，减了多少，状态全部都有。这些东西需要判断，所以它最后就形成了 BPL 底层的 entities。这些不是理论设计，是从我们真实代码库里面抽象出来的，而且它是好用的。」

信任模型与合规层（Layer 5）定义了一个三级信任体系：Declared（用户声明值）、Calibrated（仪器校准值）、Verified（操作员签名+哈希链审计）。GLP、GMP 和 21 CFR Part 11 的合规注解是 BPL 的原生语言特性，而不是附加的文档要求。

控制流（Layer 6）支持条件分支、循环迭代、并行执行块和结构化错误恢复，让 BPL 能够处理非线性的、响应式的实验工作流。

在架构图之外，还有一个贯穿始终的能力：意图降低层（intent lowering）将高层操作编译为平台特定的执行原语。同一份 BPL 源代码，可以输出给人类操作员的逐步操作指南，也可以直接生成机器人液体处理工作站的指令文件，还可以进入仿真后端验证——源代码不需要任何修改。这就是「硬件无关的可移植性」在工程上的真正实现：协议意图与执行平台彻底解耦。

值得注意的是，BPL 语法经过了 14 次大版本迭代，以 150 篇公开发表的协议为验证语料库，并积累了 1175 个测试用例。因此，BPL 是从真实的实验室场景中迭代打磨出来的。

【BPL-COGEN：LLM × 编译器，实现闭环自校正】
BPL 解决的问题是「协议应该长什么样」，但下一个问题更现实：让科学家从头学一门编程语言并不现实。

所以恩和科技构建了 BPL-COGEN：一条将自然语言实验方案自动转译为 BPL 代码的管线。它的核心机制是一个「生成—验证—修复」的闭环。

BPL-COGEN 的架构由一个经过专门微调的 30B 参数语言模型 BPL-Nano-30B（基于 Nemotron 架构，以 2714 条精选数据微调而成）和一个确定性编译器联合驱动。二者构成了一个持续迭代的反馈系统。

整个管线分五个阶段运行。首先是输入归一化：原始 SOP 文档输入后，系统自动提取结构，并通过双语别名匹配将文档中的试剂和设备名称与本地库存对应，确保生成的声明对应实际可用的物理资源。

然后是代码生成：归一化文档、完整的 BPL 语法规范（463 行 Lark PEG 表示法）、章节结构和资源目录，共同构成发给 BPL-Nano-30B 的提示词。语法规范逐字包含，而非摘要——因为研究发现，对语法做任何形式的压缩都会显著降低模型首次生成时的语法合规率。

接下来，核心来到三关编译器验证：每个候选 BPL 程序都必须依次通过解析关（验证语法合规性）、语义关（检查单位一致性、类型安全性、状态连贯性）、规划/验证关（将高层意图降低为有向无环图形式的执行原语，验证依赖关系和硬件能力兼容性）。

这三关的背后是一套六级编译流水线构成的 BPL 编译器架构。

具体来说，源代码首先会经过 Lark PEG 语法解析，生成带类型信息的抽象语法树（AST）；随后进入量纲分析模块，在 9 个物理基础维度上完成单位一致性检查；语义分析阶段则负责标识符解析、容器状态追踪，以及 Declared→Calibrated→Verified 的信任级别推进；意图降低层则能将约 15 种高层实验意图编译为约 20 种执行原语；最终由调度引擎生成 DAG（有向无环图）执行计划，并根据目标平台（人工操作、机器人、仿真）分别输出对应的执行指令。整套编译器由 9 个 AST 模块构成，以 1175 个测试用例保障各层的独立可测试性。这种分层架构意味着：每一类错误都会在最早能够被发现的层级被捕获，并给出精确的诊断定位。

任何一关失败，编译器就会输出一个结构化 JSON 诊断，其中包含错误码、严重等级、源码位置（精确到行号和列号），以及针对性的修复建议。这个诊断作为上下文化的修复提示返回给语言模型，最多循环 3 次，形成诊断驱动修复循环。

这是这套架构最重要的设计选择。Alex 做了个类比：「它就有点像 Cursor 一样，自己去跑，跑完了如果不行，就报错，返回来让模型再重新生成，如果可以，就进到实验室。」

这样一来，正确性的保障就从单一语言模型转移到了模型与编译器的协同系统。LLM 负责语义理解和代码生成，编译器负责确定性的物理验证，两者各司其职，形成互补。

最终通过所有验证的程序会输出五类确定性产物：版本可控的 BPL 源码、含有依赖关系的 DAG 执行计划、体积追踪和单位转换审计报告、工作流可视化图、以及逐步容器状态追踪记录。

http://t.cn/AXSfvhgH