AutoDNA 登 Nature：11000 步自主实验，AI 实验室跑通了什么

一句话结论：上海交通大学 IPADS 实验室与化学化工学院联合打造的自驱动实验室 AutoDNA（装置名思源一号）登上《自然》正刊，AI 智能体自主调度 20 多类仪器、连续执行超过 11000 步实验操作，人工只需补充试剂和维护硬件——它把「AI 只做计算、湿实验还得靠人」这个长期格局往前推了一大步。

斯坦福大学 biomedical data science 系的 James Zou 在《自然》的 News & Views 里写下了这件事的分量。AI 在科学里一直很有用，但绝大多数时候指的是计算侧的活儿——分析数据、做预测、翻文献。真正要动液体的湿实验是另一回事：一个 AI 系统可以在几分钟内设计出一个有生物活性的分子，但要把它测出来，可能要花上几周甚至几个月，还得占用大量人力。AutoDNA 的意义在于，它开始弥合「提出实验」和「做实验」之间的这道缝。

论文题为《An AI-native experimental laboratory for autonomous biomolecular operations》，2026 年 11 月 4 日在线发表于《自然》，同一天配发了两篇新闻报道。研究团队来自上海交通大学 IPADS 实验室陈海波、王肇国，以及化学化工学院与变革性分子前沿科学中心的樊春海、王飞。美国北卡罗来纳州立大学的化学工程师 Milad Abolhasani 评论说，这套系统的自主程度以及它接纳各种实验室设备的能力都很突出，未来的科学将包含大量自主实验室。

为什么「外挂式」架构走不通

在讲 AutoDNA 之前，得先说清楚已有的自主实验室卡在哪里。此前的 AI 自主科学实验室通常是这么搭的：专家先配置好仪器、规定好实验流程、设定好优化规则，然后把 AI 接进去，负责文献检索、方案生成或者数据分析这类局部环节。

这种外挂式的做法能提升单个环节的效率，但整体上难以适应生物分子实验的特点——流程复杂、仪器型号多样、对实时执行与环境稳定性的要求都很高。Nature 那篇 News 里引用了共同作者、上海交通大学计算机科学教授陈海波的表述：在很多已有系统里，人类专家仍然必须负责配置仪器，AI 只是被加进来处理流程中的一小部分。

AutoDNA 的做法是从零开始就以 AI 为中心设计，通过模型、实验与仪器的协同设计，让 AI 与自动化系统在一个端到端、多用户框架里共同演化。论文的措辞是 co-design of models, experiments and instruments——这不是给旧系统加外挂，而是重新设计整个系统边界。

原子服务：把仪器变成模型能调用的东西

这套系统最关键的技术设计是「原子服务」。

系统把复杂的实验任务拆成一串环节：文献检索、试剂选择、方案设计、代码生成、硬件执行、结果分析、迭代优化。多个专业智能体根据实验进展协同工作，各自负责其中一段。

难点在于仪器的异构性。机械臂、加热摇床、荧光计、离心机各有各的调用方式，底层协议完全不同。AutoDNA 的做法是把仪器能力提炼成适合模型理解和调用的原子服务——用自然语言说明加上统一的代码接口，告诉每一台设备能做什么、怎么调用，从而屏蔽不同型号仪器的底层差异。模型据此组合设备能力，生成并修正跨设备的控制代码。

硬件侧提供微米级定位和微升级液体处理能力，执行与调度系统负责程序检查、仪器状态跟踪和资源调度。平台还集成了基于 OpenHarmony 操作系统的控制终端。这一点值得留意：国产开源操作系统进入实验室自动化的控制层，是这套装置区别于此前多数自主实验室的一个细节。

开源仓库拆开看：四个组件怎么装

更实用的一点是，AutoDNA 的代码已经开源在 GitHub 的 IPADS-X/AutoDNA 仓库，采用 Apache 2.0 协议，当前 Star 数 16。它把整套系统拆成四个组件，看架构图很直观。

四个组件之间的链路是：UI 通过 HTTP 与 WebSocket 连 AutoDNA-python，AutoDNA-python 用 JSON 协议连 Scheduler，Scheduler 通过 PLC 指令下发到 Firmware。README 里明确写了整个安装过程预计约需一小时。

软件前置要求相当具体。操作系统推荐且仅在 Ubuntu 22.04 上测试过；UI 组件需要 Node.js 18 以上与 pnpm 9.5 以上；AutoDNA-python 需要 Python 3.11 以上；Scheduler 需要兼容 C++17 的编译器和 CMake 3.5 以上。此外必须配置 GEMINI_API_KEY 环境变量——整个 AI 引擎是接在 Google Gemini 上的。

安装步骤大致是：克隆仓库后，先在 UI 目录跑 pnpm install，再在 AutoDNA-python 目录执行 pip install -r requirements.txt 并导出 GEMINI_API_KEY，接着在 Scheduler 里用 mkdir build、cmake ..、make 编译。运行阶段需要开四个终端，依次启动 Modbus 服务、Scheduler、AutoDNA-python 的 server.py 和 UI 的 pnpm dev。

默认访问入口是：UI 在 http://localhost:3010，AutoDNA API 在 http://localhost:8081，Scheduler 的 WebSocket 在 http://localhost:8080。没有真实硬件时可以跳过 Modbus 服务，但完整复现论文实验需要配套仪器。

智能体的分工在 README 里列得很清楚：Literature Agent 负责科学文献检索与分析，Protocol Agent 负责实验方案设计与优化，Reagent Agent 管试剂库存，Code Agent 负责生成实验室自动化的 Python 代码。示例提示词放在 AutoDNA-python/scientist/prompts/ 目录下，官方演示的提示词是 user_prompt_rpa.md。一个示例工作流的运行时间大约是 15 分钟到 1 小时，这还没算上真正执行硬件操作的时间。

四个验证场景：数据存储、癌症检测与并发加速

论文在四个代表性应用上验证了 AutoDNA，每个都对应一个可核对的硬指标。

数据存储那个场景的具体做法是用 DNA 的四种碱基 A、C、G、T 当作「字母」来编码信息。研究者选了一句经常被误传为霍金名言的句子：Intelligence is the ability to adapt to change。整个写入-读回循环由系统自动完成，读出的数字内容与原始完全一致。

KRAS G13D 是一个在临床上已经被检出的突变位点。用它做验证的意义在于，系统不只是做出了个理论上的预测，而是找到了一个现实中确实存在、并且可以被独立检验的结果。

并发执行的 3.2 倍加速来自一个端到端的核酸检测服务流程。这项指标对应的现实痛点很直接——多用户同时提交实验需求时，平台靠多用户框架来组织调度和资源分配，把原本串行的等待变成并行。

规模：11000 步和 20 多类仪器

AutoDNA 自主编排超过 20 种类型的仪器，在一个项目中完成超过 11000 步操作，涵盖核酸合成的核心环节，包括合成、转录、扩增和测序。

11000 步这个数字值得放在一起看。每一个步骤都要经过「生成调用代码、下发到仪器、等待完成、读取结果、判断下一步」的完整闭环，中间任何一次状态判断失误都会让整条链断掉。系统在这个规模上把人工介入压缩到只有硬件维护一件事——补充试剂和耗材。这正是论文强调的那条边界：人不是不参与，而是参与的部分被推到了「后勤」而非「决策」。

从论文图示看，系统有六个主要场景的完整工作流：架构总览、核酸检测服务的端到端自主流程、酶促 DNA 合成的自主优化流程、并发实验请求管理、DNA 数据存储服务、以及端到端癌症检测。

数据与代码可查：Zenodo 与 GitHub

论文承诺的可复现性做得比较到位。酶促 DNA 合成与 DNA 数据存储实验产生的测序数据，连同智能体的相关输出，都存放在 Zenodo（DOI 10.5281/zenodo.20624108）。参考基因组用的是 hg38，从 NCBI Datasets 下载。代码在 GitHub 的 IPADS-X/AutoDNA 仓库，论文使用的版本同样固定在 Zenodo 上。

这意味着第三方可以在同一套代码和同一批数据上重跑验证，而不必依赖作者的私有环境。对自主实验室这个领域来说，这一步的意义可能不亚于实验本身——过去大量自驱动实验室的结果因为环境不公开而难以被第三方检验。

和其他 AI 造实验的工作怎么比

把它放进整个赛道的坐标系里看会更清楚。

《自然》论文的参考文献里列了这条技术脉络上的关键节点：2020 年 Nature 的移动机器人化学家，2023 年 Nature 的大语言模型驱动自主化学研究，2024 年 Nature 的自主移动机器人探索合成化学，以及 2025 年 Science 的机器人辅助探索化学反应空间，还有 2025 年 Nature 那篇虚拟实验室——多个 AI 智能体设计的 SARS-CoV-2 纳米抗体，以及 2025 年《自然》综述里那句「自我驱动实验室在化学与材料科学中的兴起」。

AutoDNA 属于这条脉络上偏生物分子方向的一支。它的差异化不在于单项能力，而在于两点：一是「AI 原生」的架构设计，把人从仪器配置环节里彻底抽走；二是仪器异构性的处理方式，原子服务加统一代码接口这套做法，让 20 多类设备可以被同一套模型逻辑驱动。

横向对比同期的几类工作会更直观。微软 Project Quine 用生物学世界模型在一个周末里筛出数千个抗癌候选物，那是纯计算侧的筛选；Anthropic 自建湿实验室并收购 Coefficient Bio，走的是把人和自动化结合的实验室自建路线；Periodic Labs 的材料模型 Neon 用 1300 张 H200 训练，目标是替代真实实验数据做材料预测。这些都在压缩「从想法到验证」的时间，但 AutoDNA 走的是更彻底的一段——它把验证本身也交给智能体。

该怎么看这件事：三个现实的限制

论文的乐观结论需要一个清醒的注脚。第一，人工介入虽然只剩维护，但维护本身是持续的、不可省略的。补充试剂和耗材在真实实验室里从来不是可以忽略的工作量，只是它不再需要判断力。第二，系统的模型层依赖 Google Gemini，并且需要真实硬件的完整配套才能复现论文级别的实验。仓库 README 里那句「没有硬件组件也能运行，但功能受限」说得很直接，演示跑得起来和验证 KRAS 突变是两件事。

第三，这套系统目前的能力边界在分子生物学，且集中在核酸相关操作。化学合成、材料筛选这些方向上的自主实验室，论文也把它列为未来的延伸方向而不是已验证的部分。对关注这条赛道的人来说，AutoDNA 更像是一个架构范式的样本，而不是可以直接照搬的产品。

常见问题

AutoDNA 和此前那些「AI 做实验」的系统有什么不同？

核心区别在于架构起点。此前的自主实验室是把 AI 接到已经配置好的实验流程上，AI 只处理文献检索、方案生成或数据分析等局部环节。AutoDNA 从设计之初就让模型、实验流程与仪器协同设计，把仪器能力抽象成统一接口的原子服务，人工从「配置仪器、规定流程」的环节被彻底抽离。这是论文反复强调的 AI-native 与 add-on 之间的差别。

AutoDNA 的代码可以自己跑起来吗？

可以跑通软件流程。仓库采用 Apache 2.0 协议开源，需要 Ubuntu 22.04、Node.js 18 以上、pnpm 9.5 以上、Python 3.11 以上、C++17 编译器和 CMake 3.5 以上，安装约需一小时，运行时开四个终端分别启动 Modbus 服务、Scheduler、AutoDNA-python 和 UI，并用 GEMINI_API_KEY 接上模型。但要复现论文里的合成优化、DNA 数据存储、癌症检测这些实验结果，需要配套 20 多类真实仪器。

论文发表后第三方能验证吗？

可以。酶促 DNA 合成与 DNA 数据存储实验的测序数据，以及智能体产生的输出，都存放在 Zenodo，DOI 为 10.5281/zenodo.20624108，代码仓库在 GitHub 的 IPADS-X/AutoDNA，论文使用的版本同样在 Zenodo 上做了固定。第三方可以在同一套代码和数据上重跑检验，这在此前自主实验室研究中相对少见。

小结

AutoDNA 证明了一件此前被反复质疑的事：AI 智能体不只能提方案，还能真的把实验做出来，而且规模不小——20 多类仪器、11000 步以上的操作、人类只管后勤。合成产出率追平专家优化、并发加速 3.2 倍、DNA 数据存储精确还原、KRAS G13D 突变被识别并验证，这四项结果里任何一项单拿出来都够分量。

它更大的意义可能在于「science-as-a-service」这个提法所指向的方向。当实验系统本身成为可部署、可调用的服务，AI 生成假设到 AI 执行验证之间的那段距离，就不再需要靠人力去硬填。论文正文引用了《自然》一篇文章里那句关于机器贡献应当被认可的讨论——在一个连「谁来署名」都要重新讨论的领域，能让机器独立完成两万步操作这件事，性质上是完全不同的。

相关阅读

• 微软 Project Quine：首个生物学世界模型如何在一个周末筛出抗癌候选物
• AI 制药赛道升温：Anthropic 自建湿实验室并收购 Coefficient Bio
• Periodic Labs 发布材料模型 Neon：用真实实验数据训练，1300 张 H200 挑战强模型
• 分子之心 MMDesign 深度：19 项目 94.7% 成功率与 GPCR 全命中