夜雨聆风
过去几年，如果我们谈 AI4Bio，最容易被讨论的往往是模型本身。
AlphaFold 改变了结构预测，RFdiffusion 和 ProteinMPNN 推动了蛋白设计，ESM、Evo、Borzoi、AlphaGenome 这类模型又把生成和预测能力扩展到了蛋白、基因组和调控序列。
但真正做过设计任务的人会知道，真实项目很少是“调用一个模型”就结束的。
一个蛋白设计项目，可能同时需要生成序列、预测结构、评估界面、筛掉不稳定构象、避免 off-target、再通过多轮打分和筛选找到可实验测试的候选。一个调控元件设计项目，也可能同时涉及 DNA 生成、表达预测、剪接预测、细胞类型特异性、motif 过滤和实验 readout。
所以，AI4Bio 现在遇到的一个新问题是：
模型越来越多，但模型之间并不会自动协作。
这也是 Arc Institute 最近这篇 Proto 工作想回答的问题。
今天要讲的这篇文章来自 Arc Institute 和 Stanford，通讯作者是 Brian Hie。Brian Hie 过去几年一直在做 generative biology、蛋白语言模型和生物设计相关工作。Arc Institute 本身也很值得关注，它的定位不是传统单一高校实验室，而是一个介于学术研究、工程平台和生物医学转化之间的新型研究机构。
这次他们提出的 Proto，不是又训练了一个更大的模型，而是提出了一种面向 generative biology 的高层编程语言。
Arc Institute 在介绍 Proto 时，用了一句很有传播性的表达：
Imagine programming protein, DNA, and RNA systems.
想象一下，我们可以像写程序一样，设计蛋白、DNA 和 RNA 系统。
这句话很吸引人，但也容易被误解。
它不是说复杂生命系统已经可以像软件一样被完全编程，也不是说大语言模型已经能直接替代生物学家完成设计。Proto 真正想解决的问题是：当 AI4Bio 进入多模型、多目标、多模态时代之后，我们需要一种方式，把分散的模型组织成可执行、可组合、可迭代的生物设计程序。
换句话说，Proto 的重点不是“又一个 AI 生物模型”。
它更像是 AI4Bio 时代的一层基础设施。
一、AI4Bio 的瓶颈，正在从“没有模型”变成“不会组合模型”
过去几年，AI4Bio 的进展很大。
蛋白结构预测有 AlphaFold 系列，蛋白设计有 ProteinMPNN、RFdiffusion、ESM3，基因组方向有 Evo、Borzoi、AlphaGenome，RNA 和剪接方向也出现了越来越多专门模型。
如果只看模型列表，这个领域似乎已经非常繁荣。
但真正做一个设计项目时，问题会立刻变得复杂。
你可能需要一个模型生成候选序列，一个模型预测结构，一个模型评估结合界面，一个模型判断表达或剪接，一个模型检查 off-target，再用某种优化算法在这些分数之间搜索。
每个模型都有自己的依赖环境、输入输出格式、硬件要求和运行方式。很多时候，一个项目的第一步不是科学问题本身，而是先把模型装起来、跑起来、接起来。
Proto 作者在采访里提到，过去他们做生物设计项目时，最开始一周，甚至两三周，经常都花在 setup 上：调用每个模型，处理依赖冲突，平衡硬件资源，保证迭代循环不会出错。
这其实是很多 AI4Bio 研究者都熟悉的痛点。
模型越来越多，但模型之间并不会自动协作。工具越来越强，但工具链并没有自然形成。每个实验室都在写自己的胶水代码，而一个隐蔽的实现错误，就可能让后续实验测试付出很大代价。
所以，Proto 要解决的第一个问题不是“能不能再训练一个更强的模型”，而是：
这些已经存在的模型，能不能被更可靠地组合起来？
这是它作为基础设施的意义。
二、Proto 把复杂设计任务压缩成四个基本组件
Proto 的核心概念并不复杂。
它把一个生物设计任务拆成四类东西：
sequence：要设计的分子序列，可以是 DNA、RNA、蛋白，也可以是 ligand。
generator：负责提出候选，比如蛋白语言模型、基因组语言模型、diffusion 模型、inverse folding 模型，甚至随机突变。
constraint：负责判断候选是否符合目标，比如结构置信度、结合分数、剪接预测、染色质可及性、motif、GC content。
optimizer：负责引导搜索，比如 MCMC、rejection sampling、beam search、gradient descent。
这四个词看起来很简单，但它们把很多原本完全不同的 AI4Bio 任务统一到了同一个语言里。
设计一个蛋白 binder，可以写成 sequence + generator + binding/structure constraints + optimizer。
设计一个细胞系特异性剪接元件，也可以写成 sequence + mutation generator + splicing constraints + optimizer。
设计 promoter-repressor pair，则是 DNA sequence 和 protein sequence 的联合设计，再加上 promoter activity、DNA binding、specificity、dimerization 等 constraints。
也就是说，Proto 并不是替你规定某一种设计方法，而是提供一种描述设计方法的语言。
它让研究者可以把一个复杂目标拆成更标准的程序结构：
要设计什么？
用什么模型生成？
用什么指标判断？
用什么优化策略迭代？
这听起来像工程问题，但对 AI4Bio 很关键。
因为一个领域真正成熟的标志，往往不是每个人都能写出一次性的脚本，而是大家开始共享接口和工作流。
三、它真正改变的是“模块化”的位置
传统合成生物学有一个很重要的思想：模块化。
比如把 promoter、RBS、coding sequence、terminator 当成标准零件，再把它们组合成 circuit。这个思想推动了很多合成生物学的发展。
但复杂生物系统的问题在于，序列模块并不总是像乐高一样可拼接。
一个 promoter 换到不同上下文里，行为可能改变；一个蛋白结构域拼到另一个蛋白上，折叠和功能可能出问题；一个调控元件能不能工作，也取决于细胞状态、染色质环境、转录因子表达和上下游序列。
Brian Hie 在采访里说得很直接：复杂生物设计不是简单堆叠模块，因为一切都是全局耦合的。Proto 的不同之处在于，它把模块化上移了一层。
不是在序列层面组合模块，而是在概念层面组合目标。
比如你不一定手写一个具体的 DNA 元件，而是写出：
它要在某个细胞系中强表达，在另一个细胞系中弱表达；
它要被某个设计蛋白识别；
它不能包含天然转录因子 motif；
它还要满足某种结构或序列复杂度约束。
这些目标是“功能模块”，不是“序列模块”。
然后，生成模型负责把这些高层目标翻译成底层序列。
这是 Proto 最重要的思想之一：
modularity happens at the level of concepts, not at the level of sequences.
模块化发生在概念层面，而不是序列层面。
这句话其实非常适合作为理解 Proto 的核心。
我的理解是，Proto 并不是否定传统合成生物学的模块化思想，而是在 AI 模型成熟之后，把模块化从“物理零件”推进到了“功能约束”。
这可能是生成式生物设计和传统合成生物学最大的差别之一。
四、为什么这件事现在才变得可能？
如果在十年前提出“写一个目标函数，让模型帮你设计 DNA、RNA 和蛋白系统”，大概率很难实现。
因为当时缺少足够好的生成模型和预测模型。
今天情况发生了变化。
我们已经有越来越多模型可以生成生物序列，也有越来越多模型可以预测结构、表达、剪接、染色质可及性、蛋白-DNA 相互作用等功能 readout。它们都不完美，但已经强到可以在某些任务中作为有用的 constraint。
Proto 的机会正来自这里。
单个模型可能只能解决一个局部问题，但多个模型组合起来，就有可能表达更复杂的生物目标。
在作者采访中，Aditi Merchant 提到，一个模型可能擅长蛋白设计，另一个擅长 DNA，另一个擅长预测序列性质；当它们被组合起来时，就能支持比任何单一模型更广泛的设计目标。
这也是 Proto 的核心假设：
复杂生物设计不一定总要等一个端到端大模型来解决；很多时候，把多个不完美但互补的模型组织起来，已经能产生实验上值得测试的候选。
这对 AI4Bio 很重要。
因为真实生物系统本身就是多尺度的。一个治疗设计可能同时涉及递送、细胞选择性、表达调控、剪接、蛋白功能、免疫原性和安全性。很难指望一个模型一次性覆盖所有层面。
更现实的路线，是建立一个可以持续接入新模型的框架。
当新的结构预测模型出现，它可以成为新的 constraint。
当新的基因组模型出现，它可以成为新的 generator 或 constraint。
当新的优化器更高效，它可以替代原来的搜索过程。
Proto 的意义就在于，它试图成为这样一个可扩展的接口层。
这里有一个需要警惕的点：
多个模型组合，不一定天然比单个模型更可靠。
如果每个模型都有偏差，组合之后也可能只是把偏差包装得更复杂。
所以，Proto 的真正难点不只是“能不能接入更多模型”，而是如何校准这些 constraint、如何设置权重、如何避免 optimizer 只是钻模型分数的空子。
这也是后面所有 generative biology workflow 都绕不开的问题。
五、Proto 的实验结果说明了什么？
这篇文章并不只是提出概念。作者也做了两个比较有代表性的实验验证。
第一个是细胞系特异性 alternative splicing intron 设计。
他们希望设计一些 intron，使其在某个细胞系中正常剪接，在另一个细胞系中产生错误剪接，从而影响下游蛋白表达。这个任务比简单设计一个 splice donor 或 acceptor 更复杂，因为剪接受上下文、cryptic splice site 和细胞类型特异性调控共同影响。
Proto 在这里把 AlphaGenome 和 SpliceTransformer 作为 constraint，把随机突变作为 generator，用 MCMC 进行优化。最后，他们只测试了几十个候选，就获得了具有细胞系差异剪接效果的设计。
更有意思的是，一些成功设计利用了 cryptic splice sites。也就是说，模型并不是简单强化研究者预设的 canonical splice site，而是找到了一些研究者没有直接指定的机制来达成高层目标。
这说明，如果目标被定义在功能层面，生成式搜索可能会找到人类没有预先写死的解决路径。
第二个实验是 promoter-repressor pair 设计。
这个任务更难，因为它要同时设计 DNA 和蛋白。
DNA promoter 要能启动表达，又要包含可被 repressor 识别的 operator；蛋白 repressor 要特异性识别这个 DNA，但不能乱结合细胞里其他 DNA；同时整个系统还要在细菌里真正表现出转录抑制。
作者没有为这个任务专门训练一个 protein-DNA codesign 模型，而是把已有的结构预测模型、DNA-binding interface 模型和 specificity scoring 组合进 Proto。结果显示，他们在只测试几十个设计的情况下，获得了功能性 promoter-repressor pair，并且成功率在同类任务中有竞争力。
这说明 Proto 的实用价值不在于某一个模型有多强，而在于它可以把多个模型组织成一个 consensus workflow，让它们共同筛出更有可能成功的候选。
这两个实验的意义，不是说 Proto 已经可以可靠设计任意生物系统，而是说明了一件更实际的事：
在某些任务上，合理组织多个不完美模型，已经可以把候选数量从“海量筛选”压到“低 N 实验验证”。
这对 wet lab 很重要。
因为真实世界里，实验资源不是无限的。一个设计框架如果能让研究者少测一些明显不靠谱的候选，把有限测试量集中到更有希望的设计上，它就已经有实际价值。
六、agent 在这里的角色：不是做生物学家，而是做 workflow engineer
这篇文章还有一个容易被关注的点：AI agent。
但这里需要讲清楚，Proto 里的 agent 不是一个直接“发明生物系统”的智能体。
它更像是一个 workflow engineer。
因为 Proto 已经把生物设计任务标准化成 sequence、generator、constraint、optimizer 四类组件，AI coding agent 就可以在这个结构化接口上工作：根据人的自然语言目标，规划设计流程，选择模型，写 Proto 程序，运行，查看结果，再修改程序。
这件事的重要性在于，agent 不再直接面对混乱的生物学问题，而是面对一个明确的编程语言和工具接口。
这会降低 agent 出错的空间。
如果没有 Proto，agent 需要自己处理各种模型仓库、依赖环境、输入输出格式、硬件配置和脚本逻辑，很容易失败。Proto 把这些底层复杂性封装起来，让 agent 更像是在一个有规则的操作系统里工作。
所以，Proto 和 agent 的关系不是“agent 替代 Proto”，而是：
Proto 为 agent 提供了一种可操作的生物设计语言。
这可能是 AI agent 在科研中更现实的一种落地方式。
不是让 agent 直接替代科学判断，而是让 agent 在受约束的工具层中承担大量繁琐的 workflow 构建工作。
这里我的判断比较明确：
很多“AI agent 做科研”的叙事容易过度承诺，因为真实科研不仅是写代码，还包括问题定义、实验设计、机制解释和失败判断。
Proto 给 agent 找到的是一个更窄、但更现实的位置：
让 agent 处理 workflow construction，而不是替代 scientific judgment。
这比“让 LLM 直接设计蛋白”要可靠得多。
七、它不能解决什么？
Proto 的潜力很大，但边界也必须讲清楚。
第一，它受限于底层模型。
如果某个设计目标没有好的预测模型，Proto 也没有魔法。你可以把目标写进程序，但如果 constraint 本身不可靠，优化器只会把错误放大。
作者在采访里也明确说，如果你想设计的目标没有高质量模型，那就是当前路线的边界。
第二，它不能替代实验。
Proto 的目标不是让实验消失，而是让研究者不必盲目筛选成千上万个候选，而是可以先得到一小批更有理由被测试的设计。最后能不能工作，仍然要回到实验。
第三，它可能很慢。
因为 Proto 很多时候是在做 inference-time search，也就是不断调用模型、评分、接受或拒绝候选。作者也提到，某些运行可能需要半小时甚至更久。随着目标变复杂，这个成本会继续上升。
第四，它不能自动保证 objective 是正确的。
一个复杂设计任务往往有多个 constraint，但这些 constraint 怎么加权、是否校准、是否真的对应实验 readout，仍然需要研究者判断。多个模型分数加起来，看起来很严谨，但不等于真实生物功能。
这也是 AI4Bio 里最容易被忽略的问题：
我们优化的到底是生物学目标，还是模型分数？
Proto 让目标函数变得更容易编写，但不会自动保证目标函数就是对的。
这里我觉得需要保持冷静：
Proto 解决的是“如何把设计目标程序化”的问题，但没有解决“目标本身是否正确”的问题。
前者是工程问题，后者仍然是科学问题。
八、为什么 Proto 仍然重要？
即使有这些局限，我仍然觉得 Proto 代表了 AI4Bio 里一个重要趋势。
因为这个领域正在从“单模型时代”进入“系统编排时代”。
早期我们关注的是：能不能预测结构？能不能生成蛋白？能不能设计一个 binder？
现在越来越多真实任务会变成：能不能把结构、功能、表达、调控、特异性、安全性和实验可行性放进同一个设计循环？
这时，单个模型不够。 一次性脚本也不够。 我们需要一种更标准的方式来描述、组合和复用 design workflow。
Proto 的价值就在这里。
它不是终点，而是一层接口：
向下连接各种生成模型和预测模型；
向上连接研究者的设计意图和 AI agent 的编程能力；
中间用统一的 primitives 把任务组织成可执行程序。
如果未来 AI4Bio 继续发展，模型会越来越多，任务会越来越复杂，实验闭环会越来越昂贵。到那时，谁能更好地组织模型、定义目标、运行搜索、筛选候选，谁就更可能把 AI 能力转化成真实生物学结果。
从这个角度看，Proto 不只是一个工具。
它提出的是一个更底层的问题：
当我们拥有越来越多 biological AI models 时，应该用什么语言来使用它们？
这可能是未来几年 AI4Bio 很重要的一条主线。
更强的模型当然重要。
但同样重要的是，如何把这些模型组织起来，变成一个可编程、可验证、可迭代的设计系统。
Proto 的意义就在于，它把这个问题明确摆到了台前。
最后我想说，Proto 这篇文章最值得我们带走的，不是“生物系统已经可以像软件一样编程”这个结论。这个判断还太早。
更准确的说法是：
AI4Bio 正在进入一个新的阶段。模型能力仍然重要，但模型之间的接口、目标函数的定义、workflow 的复用、以及实验闭环前的候选筛选，会变得越来越重要。
也许未来的生物设计，不会只是问“我该用哪个模型”，而是会更多地问：
我该如何把这个设计目标写成一个可以被搜索、被验证、被迭代的程序？
