Biomni干了什么？怎么干的

发布于 2026/07/16 17:48更新于 2026/07/18 03:280号员工33 浏览26 访客

据论文描述，Biomni 不用依赖固定的工作流模板，就能围绕研究者提出的问题，自主拆解任务、调用工具，协助人们完成多样的生物医学研究，在遗传学、基因组学、药理学等生物医学任务中，展现出较强的泛化能力；在部分真实科研任务的表现接近人类专家，且用时更短。真实场景案例研究进一步证明，Biomni 能够解读多模态数据集、优化蛋白质稳定性、协调湿实验室仪器操作，并生成可供实验验证的实验方案。

核心要点

Phase 1 论文选取：直接沿用预印本平台的原生分类（bioRxiv 有 25 个子领域），每个取最新 100 篇。选取优先级是时效性 > 主题覆盖 > 方法学论文优先。

Phase 2 AI 提取（最关键）：PDF 解析后按章节分块，LLM 逐块处理提取四类实体——Task / Tool / Database / Software。文档里有可直接复制使用的 Prompt 模板，每类实体都有明确的 JSON Schema 字段定义。加了幻觉防护（URL 可访问性验证、包名 PyPI 交叉验证）和置信度标注。

Phase 3 去重聚合：三层匹配法——精确匹配 → Levenshtein 模糊匹配 → Embedding 语义匹配（>0.85 才标记为候选重复）。Biomni 从 ~1900 个原始任务精简到 150 个工具，这步是收敛的关键。

Phase 4 人工验证：五项验收清单——①名称清晰 ②完整文档 ③LLM 可读输出格式 ④通过测试用例 ⑤专业性门槛（<20 行代码能搞定的不收录）。领域专家 + 软件工程 Agent 协作实现。

Phase 5 环境构建：

工具统一封装为 def tool_name(query, params, data_dir) -> dict 接口，输出必须包含 LLM 可读的 log 字段
数据库分两组：有 API 的走统一自然语言查询函数（LLM 内部解析 schema 生成查询）；没 API 的下载到本地数据湖预处理为 DataFrame
Docker + Conda 容器化，版本全锁定

文档里还有成本估算（2500 篇论文 LLM 调用约 $300–800）和完整的项目目录结构模板，直接拿去就能跑。

文献驱动的工具环境构建：完整规则方案

参照 Biomni-E1 方法论，适用于任意研究领域。核心思路：用 AI 从大量论文中提取任务、工具、数据库和软件，经人工验证后构建统一的智能体执行环境。

总览

论文选取 → AI 提取 → 去重聚合 → 人工验证 → 环境构建2500篇    四类实体    消除冗余    五项清单    E1环境

指标 Biomni 参考值你的可调参数论文总数 2,500 500–5,000（视领域规模）子领域数 25（bioRxiv 原生分类） 10–30 每领域论文数 100 50–200 最终工具数 150 50–200 最终软件包数 105 50–150 最终数据库数 59 20–80

Phase 1：论文选取规则

1.1 来源平台选择

平台适合领域 API bioRxiv 生物医学有 (api.biorxiv.org) arXiv 物理/CS/数学/定量生物有 (export.arxiv.org/api/query) chemRxiv 化学有 medRxiv 医学有 (api.biorxiv.org) SSRN 社会科学部分

规则：优先选择有公开 API 的平台，便于批量获取元数据和全文。

1.2 子领域划分规则

规则 1-A：直接沿用平台原生分类

不自行定义分类，直接使用平台已有的 subject categories
bioRxiv 有 25 个分类，arXiv 有约 170 个子分类
如果平台分类过细，合并相邻子领域至 15–25 个

规则 1-B：自定义领域时的划分原则

按研究方法分（实验/计算/理论）
按研究对象分（分子/细胞/个体/群体）
按应用场景分（诊断/治疗/药物/公共卫生）
每个子领域应有足够论文量（≥50 篇/年）

1.3 论文选取标准

优先级排序（从高到低）：

时效性：取最近 12–18 个月发表的论文（确保工具是最新的）
主题覆盖度：确保子领域内不同研究方向均有覆盖
可获取性：全文 PDF 可公开下载
方法学论文优先：Methods/Software 类论文 > 纯发现类论文
引用量（辅助）：同领域内引用较高者优先

排除规则：

纯综述论文（无新方法/新工具）
仅有摘要无全文的论文
会议摘要/短通信

1.4 批量获取流程

1. 调用平台 API 获取每个子领域的论文列表
2. 按 publication date 降序排列
3. 每个领域取前 N 篇
4. 下载全文 PDF 到本地存储
5. 记录元数据（DOI、标题、作者、领域、日期、摘要）到 papers.jsonl

Phase 2：AI 提取规则（核心）

2.1 论文预处理

规则 2-A：PDF 解析

使用 pymupdf 或 marker-pdf 将 PDF 转为纯文本
保留章节结构（Title / Abstract / Introduction / Methods / Results / Discussion）
提取表格内容为文本
忽略图片（除非有 OCR 能力处理图注）

规则 2-B：分块策略

方案 A（章节分块）：按论文章节自然分割
  → 每个章节为一个 chunk
  → 适合结构规范的论文

方案 B（定长分块）：每 3000–4000 tokens 为一个 chunk
  → 重叠 200 tokens 防止截断
  → 适合超长论文或无清晰结构的论文

2.2 LLM 提取 Prompt 设计

这是整个流程的核心。以下是可直接使用的 Prompt 模板：

系统 Prompt

你是一个专业的[研究领域]文献分析专家。你的任务是阅读论文文本，
从中提取完成该研究所需的四类可操作实体：

1. Task（任务）：论文中描述的、需要专业工具或流程才能完成的研究任务
2. Tool（工具）：用于完成任务的专用工具、算法、模型或实验方案
3. Database（数据库）：论文中查询、下载或使用的公开数据资源
4. Software（软件）：论文中使用的软件包、库、框架

提取原则：
- 只提取"需要专业实现"的任务，排除简单操作（如"画散点图"）
- 同一实体在论文中多次出现只记录一次
- 尽可能提取工具的名称、URL、版本号等具体信息
- 任务要关注"重复出现的、需要专业知识的"操作
- 输出必须是严格 JSON 格式

用户 Prompt（逐块处理）

请分析以下论文文本片段，提取任务、工具、数据库和软件。

论文标题：{title}
所属领域：{category}
当前块编号：{chunk_index}/{total_chunks}

---论文文本---
{chunk_text}
---文本结束---

请按以下 JSON Schema 输出（如果没有发现某类实体，返回空数组）：

{
  "tasks": [
    {
      "name": "任务名称（动词+宾语格式，如&#39;单细胞RNA-seq注释&#39;）",
      "description": "任务目标描述",
      "input_type": "输入数据类型",
      "output_type": "输出数据类型",
      "required_tools": ["依赖的工具名称"],
      "required_databases": ["依赖的数据库"],
      "difficulty": "easy/medium/hard"
    }
  ],
  "tools": [
    {
      "name": "工具正式名称",
      "type": "wet_lab | ai_model | know_how | algorithm",
      "description": "功能描述",
      "url": "官方链接或GitHub地址",
      "version": "版本号（如提及）",
      "language": "Python/R/Bash/Other",
      "input_format": "输入格式",
      "output_format": "输出格式",
      "api_available": true/false
    }
  ],
  "databases": [
    {
      "name": "数据库名称",
      "access_type": "api | local | unknown",
      "url": "访问地址",
      "schema": "数据结构描述",
      "data_type": "存储数据类型",
      "query_method": "查询方式（REST API/SQL/下载等）",
      "size": "数据量级（如提及）"
    }
  ],
  "software": [
    {
      "name": "软件包名（pip/conda/install 名称）",
      "language": "Python/R/Bash",
      "install_cmd": "安装命令（如能确定）",
      "version": "版本号",
      "dependencies": ["依赖的其他包"],
      "primary_use": "主要用途"
    }
  ]
}

2.3 逐篇处理流程

对每篇论文 paper：
  1. 解析 PDF → 全文文本
  2. 按策略分块 → chunks[]3. 对每个 chunk：
     a. 构造 prompt（含论文上下文）
     b. 调用 LLM 提取
     c. 解析 JSON 输出
     d. 追加到该论文的 extraction_results[]4. 论文内去重：合并同一论文中跨块重复的实体
  5. 附加论文元数据（DOI、领域、日期）
  6. 输出到 extractions/{doi}.json

2.4 质量控制规则

规则 2-C：置信度标注

对每个提取的实体，要求 LLM 同时输出 confidence 字段（0.0–1.0）
置信度 < 0.5 的实体标记为 needs_review

规则 2-D：幻觉防护

工具 URL 需验证可访问性（HTTP HEAD 请求）
软件包名需验证是否存在于 PyPI/CRAN/Bioconductor
数据库名称需与已知数据库列表交叉验证
无法验证的标记为 unverified

规则 2-E：处理异常

JSON 解析失败 → 重试一次，仍失败则记录错误跳过该块
LLM 返回空结果 → 记录但不报错（某些块可能确实无工具信息）
超长论文（>30 页）→ 增加分块数，减小单块大小

Phase 3：去重与聚合规则

3.1 实体匹配策略

三层匹配法（从粗到细）：

Layer 1: 精确匹配
  → 名称完全一致（忽略大小写、空格、连字符）
  → 例: "scanpy" = "ScanPy" = "scan-py"

Layer 2: 模糊匹配
  → Levenshtein 距离 ≤ 2（处理拼写变体）
  → 包含关系（"Seurat v5" ⊂ "Seurat"）
  → 示例: "Cell Ranger" = "cellranger" = "CellRanger"

Layer 3: 语义匹配
  → 生成实体名称的 embedding（text-embedding 模型）
  → 余弦相似度 > 0.85 → 标记为候选重复
  → 人工裁定最终是否合并

3.2 任务聚合规则

规则 3-A：任务合并

语义相似度 > 0.8 的任务合并为一个通用任务
保留最具描述性的 name 和 description
合并 input_type/output_type（取并集）
frequency 字段累加

规则 3-B：任务分级

frequency >= 50（在 ≥2% 论文中出现）→ 高频任务，优先实现
frequency >= 10                      → 中频任务，备选实现
frequency < 10                        → 低频任务，记录不实现

3.3 工具/软件去重规则

规则 3-C：工具合并

同名不同版本 → 合并为一个工具，version 取最新
同名不同 URL → 保留官方/GitHub 链接
别名映射：建立别名表（如 "BLAST" = "NCBI BLAST" = "blastn"）

规则 3-D：软件包去重

同名不同语言 → 分别保留（如 Python 的 requests 和 R 的 httr）
同名不同安装方式 → 合并，记录多种安装命令
检查依赖冲突：标记有已知版本冲突的包对

Phase 4：人工验证规则

4.1 五项验收清单

每个候选工具必须通过以下全部五项检查才能收录：

# 检查项标准不通过处理 ① 名称清晰有描述性正式名称，非缩写无歧义拒绝或要求重命名 ② 完整文档有功能描述、输入输出格式、使用说明补充文档后重审 ③ LLM 可读输出输出格式为结构化文本/JSON/表格，非原始二进制设计适配器转换 ④ 通过测试用例至少 1 个端到端测试用例通过修复后重试 ⑤ 专业性门槛不能用 <20 行简单代码实现拒绝（太简单不值得封装）

4.2 专业性门槛细则

收录标准（满足任一）：

涉及复杂算法实现（如基因组比对、蛋白质折叠预测）
需要领域专业知识（如湿实验 protocol 设计）
需要专用 AI 模型（如 ADMET 预测、单细胞注释）
需要访问特定数据库且查询逻辑复杂
工作流涉及多步骤编排

拒绝标准：

简单数据库查询（SELECT * FROM ...）
基本数据可视化（画柱状图、折线图）
通用文本处理（正则匹配、字符串清洗）
简单统计计算（均值、标准差）

4.3 验证工作流

对每个候选工具 tool：
  1. 领域专家审核：
     - 检查 ①②（名称+文档）
     - 评估 ⑤（专业性）
  2. 软件工程 Agent 实现：
     - 封装为统一函数接口
     - 编写测试用例
     - 确保 ③（LLM 可读输出）
  3. 运行测试：
     - 执行测试用例
     - 验证 ④ 通过
  4. 全部通过 → 收录到 E1 环境
     任一不通过 → 标记问题，退回修改或拒绝

4.4 开发集迭代验证

构建 30–50 题的开发集（dev set），覆盖主要任务类型
用开发集驱动工具接口的迭代优化
每轮迭代后统计通过率，直到 > 90%

Phase 5：环境构建规则

5.1 工具封装规范

每个工具必须封装为统一接口：

# 工具接口模板
def tool_name(
    query: str,           # 自然语言输入
    params: dict = None,  # 可选参数
    data_dir: str = None  # 数据目录
) -> dict:
    """
    Tool: 工具名称
    Description: 功能描述
    Input: 输入格式说明
    Output: 输出格式说明

    Args:
        query: 用户的自然语言查询
        params: 可选参数字典
        data_dir: 数据存储目录

    Returns:
        dict: {
            "result": 结果内容,
            "log": 详细研究日志（LLM 可读）,
            "status": "success" | "error",
            "metadata": {...}
        }
    """# 实现return {"result": result,
        "log": detailed_log,  # 关键：LLM 可读的详细日志"status": "success","metadata": {...}
    }

关键规则：

输出必须包含 log 字段——这是给 Agent 的 LLM 看的"研究日志"
日志要详细描述执行了什么操作、产生了什么中间结果
状态码必须明确（success/error）
错误时返回可读的错误信息，而非堆栈跟踪

5.2 数据库接入规则

Group 1：Web API 数据库

条件：有公开 REST/GraphQL API 的数据库
实现方式：
  - 每个数据库一个统一函数
  - 函数接受自然语言查询
  - 内部流程：
      1. LLM 解析查询意图
      2. LLM 根据数据库 schema 生成查询语句
      3. 执行查询
      4. 格式化结果为 LLM 可读文本
  - 示例：PDB / OpenTarget / ClinVar / KEGG

Group 2：本地数据湖

条件：无 Web 界面 / 需要离线访问的数据库
实现方式：
  - 下载到本地 data lake 目录
  - 预处理为结构化 pandas DataFrame
  - 存储为 .parquet 或 .h5 格式（高效查询）
  - 提供 query 函数支持过滤/搜索
  - 示例：基因注释集 / 蛋白相互作用网络 / 本地知识库

5.3 软件包管理

规则 5-A：容器化环境

# 基础镜像
FROM continuumio/miniconda3:latest

# 创建 conda 环境
RUN conda create -n env python=3.11 r-base -y

# 安装 Python 包
RUN pip install scanpy anndata biopython ...

# 安装 R 包
RUN R -e "install.packages(c(&#39;Seurat&#39;, &#39;ggplot2&#39;, ...))"

# 安装系统工具
RUN apt-get install -y samtools bedtools ...

# 安装 CLI 工具
RUN conda install -c bioconda cellranger ...

规则 5-B：版本锁定

所有包锁定版本号（package==1.2.3）
生成 requirements.txt + environment.yml
记录每个包的版本选择理由

规则 5-C：依赖冲突处理

Python/R 混合环境用 conda 管理
冲突包使用虚拟环境隔离
提供环境验证脚本（setup.sh）

5.4 检索系统构建

为 Agent 配备工具检索能力：

对用户查询 query：
  1. 将 query 和所有工具的 description 生成 embedding
  2. 计算余弦相似度
  3. 取 Top-K（如 K=10）最相关的工具
  4. 将工具的完整文档注入 Agent 上下文
  5. Agent 基于文档选择并调用工具

附录 A：技术栈推荐

组件	推荐方案	备注
PDF 解析	pymupdf / marker-pdf marker-pdf	支持 OCR
LLM	Claude 3.5 Sonnet / GPT-4o	长上下文+结构化输出
分块	langchain TextSplitter	支持递归分块
Embedding	text-embedding-3-large	用于去重和检索
向量数据库	FAISS / Chroma	存储工具/任务
embedding 执行环境	Docker + Conda
多语言支持	数据格式 JSONL（提取结果）+ Parquet（数据湖）	高效存储
工作流编排	自定义 Python 脚本	简单可控

附录 B：成本估算

以 2500 篇论文为例：

项目	估算
论文 PDF 下载	~50GB 存储
LLM 提取调用	7500 次, 平均 3 块/篇, 300–800∣
Embedding生成	10000次， 300–800
Embedding 生成	~10000 次，~300–800∣
Embedding生成	10000次， 5 人工验证 2–4 人周环境构建 1–2 人月

附录 C：完整项目结构

project/
├── data/
│   ├── papers/              # 原始 PDF
│   ├── extractions/        # AI 提取结果 JSONL
│   ├── aggregated/         # 去重聚合后的实体
│   └── data_lake/          # 本地数据库（Group 2）
├── src/
│   ├── fetch_papers.py     # Phase 1: 论文获取
│   ├── extract.py          # Phase 2: AI 提取
│   ├── deduplicate.py      # Phase 3: 去重聚合
│   ├── validate.py         # Phase 4: 验证框架
│   └── build_env.py        # Phase 5: 环境构建
├── tools/                  # 封装好的工具
│   ├── genomics/
│   ├── proteomics/
│   └── ...
├── tests/                  # 测试用例
├── docker/
│   ├── Dockerfile
│   ├── requirements.txt
│   └── environment.yml
└── config/
    ├── categories.json     # 子领域配置
    ├── prompts/            # LLM Prompt 模板
    └── tool_registry.json  # 工具注册表