Biomni 完整教學

Repository: https://github.com/snap-stanford/Biomni Stars: 3399 | Forks: 618 | Language: Python | License: Apache License 2.0 官網: https://biomni.stanford.edu | 論文: bioRxiv 2025.05.30.656746

1. 專案概覽 (Project Overview)

1.1 這是什麼

Biomni 是史丹佛大學 SNAP（Stanford Network Analysis Project）團隊開發的一個通用型生物醫學 AI agent (general-purpose biomedical AI agent)。它的核心主張很簡單：把 large language model (LLM; 大型語言模型) 的推理能力、retrieval-augmented planning (檢索增強規劃) 與 code-based execution (基於程式碼的執行) 三者結合，讓一個 agent 能夠自主執行橫跨多個生物醫學次領域的研究任務——從設計 CRISPR screen (CRISPR 篩選實驗)、進行 scRNA-seq annotation (單細胞 RNA 定序註解)，到預測藥物的 ADMET properties (Absorption, Distribution, Metabolism, Excretion, Toxicity; 吸收/分布/代謝/排泄/毒性性質)。

用一句話理解：Biomni 把「生物資訊分析師的工作流程」封裝成一個可以用自然語言下指令的 agent——你不用自己寫 20 行 Python 呼叫 Ensembl API 再手動整理輸出，而是直接說「幫我查這個基因的所有已知 variant」，Biomni 會自己規劃步驟、選工具、寫程式碼、執行、再把結果組織成報告。

1.2 研究團隊與動機

論文引用資訊：

 1@article{huang2025biomni,
 2  title={Biomni: A General-Purpose Biomedical AI Agent},
 3  author={Huang, Kexin and Zhang, Serena and Wang, Hanchen and Qu, Yuanhao and
 4          Lu, Yingzhou and Roohani, Yusuf and Li, Ryan and Qiu, Lin and
 5          Zhang, Junze and Di, Yin and others},
 6  journal={bioRxiv},
 7  pages={2025--05},
 8  year={2025},
 9  publisher={Cold Spring Harbor Laboratory}
10}

團隊背景是史丹佛 SNAP 實驗室（以知識圖譜、圖神經網路與生物醫學 AI 聞名，例如 PrimeKG、TxGNN 等專案的出身地）。Biomni 延續了該實驗室「將複雜生物醫學知識結構化、再用 AI 驅動決策」的一貫路線，差別在於 Biomni 把重心從「單一預測模型」轉移到「通用 agent 框架」——它不是一個訓練好只會做一件事的模型，而是一個可以呼叫上百種工具、資料庫與 protocol (實驗協定) 的執行環境 + 推理引擎組合。

1.3 解決什麼問題、為什麼重要

生物醫學研究長期存在一個落差：知識散落在數百個資料庫、工具、論文與實驗協定裡，即便是資深研究者也需要花大量時間在「找對的工具」「讀懂 API 文件」「拼湊資料格式」這類非核心的工作上，才能真正進入「思考科學問題」的階段。Biomni 想解決的正是這個落差：

• 工具發現成本高：一個問題可能牽涉 genomics（基因體學）、pharmacology（藥理學）、pathology（病理學）等十幾個子領域的工具，沒人能記住全部 API。
• 跨資料庫查詢繁瑣：ClinVar、cBioPortal、GEO、ChEMBL 等資料庫的 schema 與查詢語法互不相同。
• 實驗設計需要領域知識：像「如何設計一個 CRISPR screen」這種任務，需要結合統計知識與濕實驗（wet-lab）protocol 知識。

Biomni 用一個 agent 把這些「工具選擇」「程式碼撰寫」「知識檢索」的認知負擔接管過去，讓科學家可以用自然語言表達研究意圖，直接得到可執行、可驗證的分析結果與 testable hypotheses（可驗證假說）。

1.4 三大技術支柱如何協同運作

論文標題點出的三個關鍵字——LLM reasoning、retrieval-augmented planning、code-based execution——並非各自獨立的功能,而是刻意設計成互相彌補彼此弱點的組合:

• LLM reasoning（大型語言模型推理）單獨使用的弱點:LLM 擅長理解自然語言意圖、擅長「知道有哪些方法論存在」,但容易產生 hallucination（幻覺,即編造不存在的數據或事實),尤其在需要精確數值(如基因座標、藥物劑量)的場景風險更高。
• Retrieval-augmented planning（檢索增強規劃)如何補強:在 LLM 開始推理前,先從真實工具庫與知識庫檢索「確實存在且可驗證」的資源,讓 LLM 的規劃建立在真實可用的素材上,而非憑空想像。
• Code-based execution（基於程式碼的執行)如何補強:即使 LLM 規劃正確,若只用文字描述「應該得到什麼結果」仍可能與事實脫節;讓 LLM 產生「可執行的程式碼」並真的跑起來、拿到真實輸出,是把「說得出來」與「做得出來」之間的落差縫合起來的關鍵機制。

三者組合起來,形成一個閉環:規劃依賴檢索到的真實資源 → 執行驗證規劃是否可行 → 執行結果回饋給下一輪規劃。這正是第 2 節架構圖中「Plan → Code → Execute → Observe」迴圈的設計初衷。

1.5 在 snap-stanford 生態系中的定位

Biomni 可以視為 SNAP 實驗室從「圖譜/預測模型」路線延伸到「agentic 系統」路線的旗艦專案。它與同實驗室其他知識圖譜類專案（如藥物知識圖譜相關研究）互補：那些專案提供結構化知識，而 Biomni 提供如何使用這些知識執行任務的推理與執行框架。目前專案仍在活躍開發中（相對頻繁更新），並有對外的 web UI（biomni.stanford.edu）、Slack 社群、以及自己的 reasoning model（Biomni-R0）與 benchmark（Biomni-Eval1），顯示這已經從「一篇論文的程式碼」演化成一個平台級的生態系。

2. 核心架構 (Core Architecture)

2.1 整體系統架構圖

flowchart TB
    U["使用者 / User
自然語言任務描述"] --> A1["A1 Agent
(biomni/agent/a1.py)"]

    subgraph core["核心推理層 Core Reasoning Layer"]
        A1 --> LLM["LLM 介接層
(biomni/llm.py)
Claude / GPT / Gemini / Bedrock / Custom"]
        A1 --> SG["LangGraph StateGraph
(規劃-執行-觀察迴圈)"]
        A1 --> RET["Tool Retriever
(biomni/model/retriever.py)"]
    end

    subgraph knowledge["知識與工具層 Knowledge & Tool Layer"]
        RET --> TR["Tool Registry
(18+ 領域工具模組)"]
        RET --> KH["Know-How Library
(協定與最佳實踐 md)"]
        RET --> DL["Data Lake
(~11GB 預下載資料集)"]
        TR --> DB["Database 查詢層
(ClinVar/ChEMBL/GEO/cBioPortal...)"]
    end

    subgraph exec["執行層 Execution Layer"]
        SG --> REPL["Python REPL 沙盒
(run_python_repl)"]
        SG --> RCODE["R 程式執行
(run_r_code)"]
        SG --> BASH["Bash Script 執行
(run_bash_script)"]
    end

    subgraph ext["外部整合 External Integration"]
        A1 --> MCP["MCP Servers
(Model Context Protocol)"]
        A1 --> GRADIO["Gradio Web UI"]
    end

    TR -.提供工具給.-> SG
    KH -.檢索相關知識.-> A1
    REPL --> OUT["執行結果 / 假說 / 報告
(含 PDF 匯出)"]
    RCODE --> OUT
    BASH --> OUT

    style A1 fill:#4A154B,color:#fff
    style OUT fill:#2d7d46,color:#fff

2.2 關鍵模組說明

2.3 資料流：一次 agent.go() 呼叫發生了什麼

sequenceDiagram
    participant User as 使用者
    participant A1 as A1 Agent
    participant Retr as Tool Retriever
    participant LLM as LLM (推理)
    participant Exec as 執行沙盒 (Python/R/Bash)
    participant DB as 外部資料庫/資料湖

    User->>A1: agent.go("設計 CRISPR screen...")
    A1->>Retr: 依任務語意檢索相關工具 + know-how
    Retr-->>A1: 回傳候選工具清單 + 協定文件
    A1->>LLM: 組合 prompt（任務 + 工具說明 + 知識）
    LLM-->>A1: 產生下一步計畫（含要執行的程式碼）
    A1->>Exec: 執行程式碼（呼叫工具函式）
    Exec->>DB: 查詢資料庫 / 讀取資料湖檔案
    DB-->>Exec: 回傳資料
    Exec-->>A1: 回傳執行結果（stdout / dataframe / 圖檔）
    A1->>LLM: 將觀察結果餵回，判斷是否需要下一步
    LLM-->>A1: 繼續規劃 或 給出最終答案
    A1-->>User: 回傳完整推理鏈 + 最終結果/假說

2.4 設計哲學與技術選擇分析

為什麼用 LangGraph 而非自寫迴圈？ Biomni 用 langgraph.graph.StateGraph 建立「規劃 → 執行 → 觀察」的有狀態迴圈（AgentState 內含 messages 與 next_step）。這代表：

• Agent 的每一步都是可追蹤的 state transition（狀態轉換），方便除錯與可視化。
• 相較於單純的 while 迴圈手刻 ReAct pattern，LangGraph 提供了 checkpoint（MemorySaver）機制，讓長任務可以中斷續跑。

為什麼工具數量龐大卻要用 Retriever？ Biomni 內建橫跨 18 個生物醫學子領域（biochemistry、genomics、immunology、pathology、pharmacology…）的工具函式，數量可能達數百個。如果每次都把全部工具塞進 LLM 的 system prompt，會：

1. 浪費大量 token（成本與延遲都上升）
2. 稀釋 LLM 對真正相關工具的注意力，降低選擇準確率

因此用 ToolRetriever 依任務語意先做一次 embedding-based（嵌入式）篩選，只把「可能相關」的工具與 know-how 文件送進 context——這是一種典型的 RAG（Retrieval-Augmented Generation; 檢索增強生成） 應用在「工具選擇」而非「知識問答」場景的變體。

Code execution 而非純文字回答：Biomni 讓 LLM 產出的是「要執行的程式碼」而不是「直接說出答案」。這個選擇的好處是：分析結果來自實際執行（例如真的呼叫了 ClinVar API、真的跑了一次 pandas 過濾），而非 LLM 憑記憶編造數字——這在生物醫學這種容錯率極低的領域尤其重要。但代價是需要一個安全的執行沙盒（見第 8 節安全性討論）。

Commercial mode 的資料集分流設計：A1.__init__ 會依 commercial_mode 參數決定載入 env_desc.py（含所有資料集，含非商業授權）或 env_desc_cm.py（僅商業可用資料集）。這是一個簡單但重要的特殊情況消除——不是在執行期一個個檢查授權，而是在載入期就換一整份資料字典，讓下游程式碼完全不用知道「商業/學術」的區別。

2.5 18 個領域工具模組總覽

biomni/tool/ 目錄下每個檔案對應一個生物醫學子領域，並各自搭配一份 tool_description/ 下的 API schema 檔（供 LLM 讀懂函式簽名與用途）。完整清單：

值得注意的是 protocols.py 底下直接內嵌了數十份 Addgene 與 Thermo Fisher 的濕實驗 protocol 全文（如「Western Blot」「Gibson Assembly」「CRISPR Library Amplification」），這些不是 API 呼叫，而是知識檢索對象——agent 在規劃濕實驗步驟時，會把這些協定當作可引用的參考文本，而非執行對象。這說明 Biomni 的「工具」概念其實涵蓋兩種本質不同的東西：可執行的函式與可檢索的知識文件，兩者共用同一套 retriever 機制被統一檢索、但用途完全不同。

2.6 支援的 LLM 供應商總覽

biomni/llm.py 的 SourceType 抽象出以下供應商，讓同一套 agent 邏輯可以無痛切換推理引擎：

3. 安裝與設定 (Installation & Setup)

3.1 環境需求

• Python：需搭配專用 conda 環境（biomni_e1），因為 Biomni 依賴大量生物資訊工具鏈（R 套件、CLI 工具如 samtools/blast 等），環境非常龐大。
• 磁碟空間：Data lake（資料湖）首次執行會自動下載約 11GB 資料。
• API Key：至少需要一組 LLM 供應商的 API key（預設建議 Anthropic Claude）。
• GPU：非必需，除非自行架設 Biomni-R0 推理模型的本地 SGLang 伺服器。

3.2 完整安裝步驟

 1# 1. 取得專案並依 biomni_env/README.md 建立巨型 conda 環境
 2git clone https://github.com/snap-stanford/Biomni.git
 3cd Biomni
 4bash biomni_env/setup.sh          # 建立 biomni_e1 環境（含 R + CLI 生資工具）
 5
 6# 2. 啟用環境
 7conda activate biomni_e1
 8
 9# 3. 安裝 biomni 官方 pip 套件
10pip install biomni --upgrade
11
12# 或直接從 GitHub 主線安裝最新版
13pip install git+https://github.com/snap-stanford/Biomni.git@main

3.3 API Key 設定（.env 方式，推薦）

1cp .env.example .env

編輯 .env：

 1# 必填：至少一組 LLM 供應商 key
 2ANTHROPIC_API_KEY=your_anthropic_api_key_here
 3
 4# 選填：其他供應商
 5OPENAI_API_KEY=your_openai_api_key_here
 6GEMINI_API_KEY=your_gemini_api_key_here
 7GROQ_API_KEY=your_groq_api_key_here
 8
 9# 選填：指定預設 LLM 來源
10LLM_SOURCE=Anthropic
11
12# 選填：AWS Bedrock
13AWS_BEARER_TOKEN_BEDROCK=your_bedrock_api_key_here
14AWS_REGION=us-east-1
15
16# 選填：資料路徑與逾時設定
17# BIOMNI_DATA_PATH=/path/to/your/data
18# BIOMNI_TIMEOUT_SECONDS=600

3.4 資料集下載與準備

Biomni 的 agent 在第一次初始化時，會自動檢查並下載必要的 data lake 檔案（約 11GB）。若只是要測試核心邏輯、不需要真的跑資料查詢，可以關閉自動下載：

1from biomni.agent import A1
2
3# 跳過自動下載，加快初始化速度（適合開發/測試）
4agent = A1(path='./data', llm='claude-sonnet-4-20250514', expected_data_lake_files=[])

3.5 安裝流程視覺化

flowchart TD
    S1["1. git clone Biomni"] --> S2["2. bash biomni_env/setup.sh
建立 biomni_e1 conda 環境
(含 R + CLI 生資工具鏈)"]
    S2 --> S3["3. conda activate biomni_e1"]
    S3 --> S4["4. pip install biomni --upgrade
或 pip install git+...@main"]
    S4 --> S5["5. 設定 .env
(至少一組 LLM API key)"]
    S5 --> S6{"是否需要
立即跑真實分析?"}
    S6 -->|是| S7["A1(path='./data')
觸發 11GB data lake 自動下載"]
    S6 -->|否，先開發測試| S8["A1(expected_data_lake_files=[])
跳過下載，快速啟動"]
    S7 --> S9["開始下達自然語言任務"]
    S8 --> S9

    style S2 fill:#4A154B,color:#fff
    style S7 fill:#16213e,color:#fff

3.6 常見問題排解

4. 核心概念詳解 (Key Concepts)

4.1 用「一個新來的博士後」來類比 Biomni

想像你請了一位剛加入實驗室的博士後（postdoc），Ta 很聰明（LLM 推理能力），但還不熟悉實驗室的工具箱和資料庫。Biomni 的架構就是給這位博士後配了三樣東西：

1. 一本工具手冊索引（Tool Retriever + Tool Registry）：不用背下所有工具，遇到任務時先翻索引找出「可能有用的幾樣工具」。
2. 一疊實驗室 SOP（Know-How Library）：像是「如何設計 sgRNA」「如何做單細胞註解」這類老手才知道的訣竅，遇到相關任務會自動被抽出來參考。
3. 一台可以自己動手做實驗的工作站（Python/R/Bash 執行沙盒）：不是嘴巴說說，而是真的寫程式、跑分析、看結果，再決定下一步。

這三樣東西透過 LangGraph 組成的「思考→動手→看結果→再思考」迴圈整合起來，就是 Biomni 的 agent loop。

4.2 核心概念關係圖

flowchart LR
    subgraph input["輸入"]
        T["自然語言任務
Task Description"]
    end

    subgraph reasoning["推理循環 (ReAct-like Loop)"]
        direction TB
        P["Plan
規劃下一步"] --> C["Code
產生可執行程式碼"]
        C --> E["Execute
在沙盒中執行"]
        E --> O["Observe
觀察執行結果"]
        O --> P
    end

    subgraph support["支援系統"]
        RTool["Tool Retriever
依語意選工具"]
        RKnow["Know-How Retriever
依語意選協定"]
    end

    T --> P
    RTool -.注入相關工具.-> P
    RKnow -.注入相關知識.-> P
    O --> Done{"任務完成?"}
    Done -->|否| P
    Done -->|是| Result["最終結果 / 假說"]

    style reasoning fill:#1a1a2e,color:#fff
    style support fill:#16213e,color:#fff

4.3 幾個容易搞混的名詞

• Data Lake（資料湖） vs Database（資料庫查詢）：Data lake 是預先下載到本地的靜態資料檔案（如參考基因體、already-processed datasets），適合離線快速讀取；database 模組（biomni/tool/database.py）則是即時對外部 API（ClinVar、ChEMBL、cBioPortal 等）發送查詢，兩者互補、由 agent 依任務動態選用。
• Tool（工具） vs Know-How（訣竅）：Tool 是「可執行的函式」（例如「呼叫 BLAST」），know-how 是「非結構化的文字知識」（例如「做 BLAST 之前應該先過濾掉哪些序列品質問題」）。Tool 決定「能做什麼」，know-how 決定「該怎麼做得好」。
• A1 vs Biomni-R0：A1 是 agent 框架本身（可以搭配任何 LLM），Biomni-R0 是團隊訓練的專用推理模型（基於 Qwen-32B 做強化學習），是「可以插入 A1 框架的其中一種大腦」，不是取代 A1。

4.4 Commercial Mode 的直觀理解

Biomni 內建的資料集有些帶有限制商業使用的授權。與其在執行時逐筆檢查授權（複雜、容易漏判），Biomni 選擇在agent 初始化時就整批切換成兩份完全獨立的資料字典（env_desc.py 學術版 / env_desc_cm.py 商業版）。這就像是圖書館分成「開放借閱區」與「僅限館內閱覽區」兩個書架，你進門選了走哪一區，就不用擔心中途誤拿到不該拿的書。

4.5 Config 三層覆寫機制的直觀理解

Biomni 的設定系統（biomni/config.py）採用三層優先序，類似「公司規章 > 部門規定 > 個人習慣」的概念：

flowchart TD
    ENV["環境變數
(.env / export)"] --> DEFAULT["default_config
全域預設值"]
    DEFAULT --> CTOR["A1() 建構子參數
單一 agent 覆寫"]
    CTOR --> RUNTIME["實際生效設定"]

    DEFAULT -.同時影響.-> DBQUERY["資料庫查詢邏輯"]
    CTOR -.只影響.-> AGENTREASON["該 agent 的推理"]

    style RUNTIME fill:#2d7d46,color:#fff

這裡最容易踩的坑（也是官方文件特別強調的一點）：直接對 A1(llm=...) 傳參數只會改變這個 agent「自己怎麼想」，不會影響它內部呼叫資料庫查詢時用的模型。如果想要「整套系統從頭到尾都用同一個模型」，必須修改 default_config，而不是只改建構子參數。這類似於——你交代一位新來的博士後「你自己做研究時用方法 A」，但 Ta 委託技術員做資料庫查詢時，技術員還是照著實驗室既有的 SOP（default_config）走，除非你同時去修改實驗室 SOP 本身。

4.6 Tool Retriever 如何避免「工具過載」

一個直觀的數字感受：Biomni 橫跨 18 個領域、加上跨資料庫查詢模組，工具函式總數可能達到數百個。若把每個工具的完整函式簽名、docstring、參數說明都塞進單次 LLM 呼叫的 system prompt，保守估計會佔用數萬 token——不只成本高，還會讓 LLM 在「數百個選項裡挑一個」時準確率下降（這是 in-context 工具選擇的已知弱點）。

ToolRetriever 的解法是把「工具選擇」重新定義成一個小型的 語意搜尋問題：先把每個工具的描述做 embedding（向量嵌入），任務進來時只取語意上最相近的一小批候選（例如 top-k），再把這一小批的完整說明送進 LLM。這跟 AIKT 的 graphify（Layer 4）用知識圖譜索引取代整份程式碼庫塞進 context 的思路是同一個原理——先窄化搜尋空間，再精讀，而不是每次都全部攤開。

5. 使用方式與程式碼範例 (Usage & Code Examples)

5.1 基礎用法：初始化與第一個任務

 1from biomni.agent import A1
 2
 3# 初始化 agent；path 是資料存放位置，llm 指定使用的模型
 4# 首次執行會自動下載 data lake（約 11GB），可用 expected_data_lake_files=[] 跳過
 5agent = A1(path='./data', llm='claude-sonnet-4-20250514')
 6
 7# 用自然語言下達研究任務——agent 會自主規劃、寫程式碼、執行、回報
 8result = agent.go(
 9    "Plan a CRISPR screen to identify genes that regulate T cell exhaustion, "
10    "generate 32 genes that maximize the perturbation effect."
11)

執行後，agent 會在內部完成：檢索相關的 CRISPR/immunology 工具 → 檢索 sgRNA 設計相關 know-how → 產生候選基因清單的程式碼 → 執行並驗證 → 輸出結果與推理過程。

5.2 進階用法：切換 LLM 供應商與設定

 1from biomni.config import default_config
 2from biomni.agent import A1
 3
 4# 建議做法：修改全域預設值，確保 agent 推理與資料庫查詢用同一套設定
 5default_config.llm = "gpt-4"
 6default_config.timeout_seconds = 1200  # 拉長逾時，因應長時間分析
 7
 8# 之後建立的所有 agent 都會沿用這個預設
 9agent = A1()
10
11# 若只想覆寫「這個 agent 本身推理」用的模型（不影響資料庫查詢）
12agent_custom = A1(
13    llm="claude-3-5-sonnet-20241022",
14    source="Anthropic",
15)

若要對接自建的 LLM 服務（例如透過 vLLM/SGLang 架設的自訂端點）：

 1from biomni.agent import A1
 2
 3agent = A1(
 4    llm="biomni/Biomni-R0-32B-Preview",
 5    source="Custom",
 6    base_url="http://localhost:30000/v1",
 7    api_key="EMPTY",
 8)
 9
10agent.go("Plan a CRISPR screen to identify genes regulating T cell exhaustion")

5.3 實際應用場景：scRNA-seq 註解 + 假說生成

 1from biomni.agent import A1
 2
 3agent = A1(path='./data', llm='claude-sonnet-4-20250514')
 4
 5# 輸入單細胞資料路徑，讓 agent 自動完成 annotation + 產生生物學假說
 6agent.go(
 7    "Perform scRNA-seq annotation at ./data/pbmc_10k_filtered.h5ad "
 8    "and generate meaningful hypothesis about immune cell subtype composition"
 9)
10
11# 匯出完整推理與分析過程為 PDF 報告，方便存檔/分享給合作者
12agent.save_conversation_history("scrna_annotation_report.pdf")

5.4 Gradio Web UI：無程式碼互動介面

1from biomni.agent import A1
2
3agent = A1(path='./data', llm='claude-sonnet-4-20250514')
4agent.launch_gradio_demo()
5# 需先安裝相容版本： pip install "gradio>=5.0,<6.0"
6# 預設服務於 http://localhost:7860

5.5 MCP（Model Context Protocol）擴充工具

1from biomni.agent import A1
2
3agent = A1()
4
5# 掛載外部 MCP server（例如自訂資料庫查詢工具）
6agent.add_mcp(config_path="./mcp_config.yaml")
7
8# MCP 工具會自動加入 agent 的可選工具集
9agent.go("Find FDA active ingredient information for ibuprofen")

5.6 常見任務類型速查表

Biomni 官方展示了三大類典型任務，以下整理它們觸發的內部工具模組與大致產出：

5.7 檢視 Agent 的完整推理鏈

由於 Biomni 底層用 LangGraph 的 StateGraph 管理狀態，agent.go() 回傳的不只是最終答案，還包含完整的「規劃→執行→觀察」訊息序列。這對除錯與驗證分析可靠性非常關鍵：

1from biomni.agent import A1
2
3agent = A1(path='./data', llm='claude-sonnet-4-20250514')
4agent.go("Find FDA active ingredient information for ibuprofen")
5
6# 匯出成 PDF，包含每一步驟的程式碼、執行結果與 LLM 推理說明
7# 適合作為研究紀錄存檔或提供給合作者/審查者檢視
8agent.save_conversation_history("ibuprofen_fda_lookup.pdf")

這種「把完整推理鏈匯出成可審閱文件」的設計，對應到需要可追溯性（traceability）的研究場景相當重要——你不會只拿到一個數字答案，而是拿到「agent 怎麼一步步得到這個答案」的完整記錄，方便事後複查是否有邏輯錯誤或資料誤用。

6. 進階應用場景 (Advanced Use Cases)

6.1 藥物性質預測：ADMET pipeline

1agent.go(
2    "Predict ADMET properties for this compound: "
3    "CC(C)CC1=CC=C(C=C1)C(C)C(=O)O"
4)

這類任務會觸發 pharmacology.py 工具集，串接 SMILES 解析、既有 ADMET 預測模型與 ChEMBL/DrugBank 類資料庫比對，最終產出結構化的性質報告——適合藥物開發早期的快速篩選（可與 AIKT 的 tu-plan-generator（L19）互補，見第 7 節）。

6.2 使用 Biomni-Eval1 做能力評測

1from biomni.eval import BiomniEval1
2
3evaluator = BiomniEval1()
4# 433 個實例、涵蓋 GWAS 因果基因辨識、稀有疾病診斷等 10 種生物推理任務
5score = evaluator.evaluate('gwas_causal_gene_opentargets', 0, 'BRCA1')

在導入 Biomni 到正式研究流程前，可先用這套 benchmark 驗證你選用的 LLM 在特定任務類型上的表現，避免盲目信任 agent 輸出。

6.3 與 Know-How Library 共同演化：貢獻自己的 SOP

Biomni 開放社群貢獻 know-how 文件（如 know_how/single_cell_annotation.md）。對於有固定分析流程的實驗室，可以把內部 SOP 轉寫成 know-how 文件掛進系統，讓 agent 在處理對應任務時自動採用團隊慣例的分析步驟——這比每次在 prompt 裡重複貼上規則更穩定、更可版本控管。

6.4 效能與最佳實踐

• 先用 expected_data_lake_files=[] 快速迭代：開發階段不需要每次都等 11GB 資料下載完成。
• 善用 commercial_mode：若專案涉及商業應用（如新藥開發合作），一開始就設定 commercial_mode=True，避免後期才發現用到限制授權的資料集需要重新分析。
• 拉長 timeout_seconds：複雜的多步驟分析（如全基因體掃描）預設 600 秒可能不夠，建議依任務複雜度調整到 1200 秒以上。
• 安全性務必留意：見第 8 節，Biomni 目前以「完整系統權限」執行 LLM 產生的程式碼，正式環境務必隔離。

6.5 與其他生物資訊工具鏈整合：pylabrobot 範例

tutorials/examples/pylabrobot.ipynb 展示了 Biomni 與 PyLabRobot（開源實驗室自動化框架）的整合可能性——這代表 Biomni 的野心不只停留在「乾實驗（dry-lab）資料分析」，也延伸到「濕實驗（wet-lab）自動化執行」的銜接：

 1# 概念示意（實際細節請參考官方 notebook）
 2from biomni.agent import A1
 3
 4agent = A1(path='./data', llm='claude-sonnet-4-20250514')
 5
 6# agent 產生的實驗設計可進一步轉換為 PyLabRobot 可執行的
 7# liquid-handling（液體處理）指令序列，串接到實體機器人工作站
 8agent.go(
 9    "Design a serial dilution protocol for a dose-response assay "
10    "using a 96-well plate, compatible with automated liquid handlers"
11)

這種「從自然語言 → 實驗設計 → 機器人可執行指令」的鏈路，是 agent 系統從純資訊分析走向「閉環自動化實驗室（closed-loop automated lab）」的關鍵一步，也是 Biomni 團隊在 lab_automation.py 模組背後真正想解決的問題。

6.6 MCP Server 雙向整合：Biomni 作為工具提供者

前面第 5.5 節示範了 Biomni 消費外部 MCP server 的用法。反過來，Biomni 也可以扮演 MCP server 的角色，把自己的工具集暴露給其他 AI 系統呼叫（見 tutorials/examples/expose_biomni_server/）：

1# run_mcp_server.py 概念用法
2# 讓 Biomni 的生醫工具集透過 MCP 協定對外暴露
3# 供任何支援 MCP 的 client（包含 Claude Desktop、其他 agent 框架）呼叫
4python tutorials/examples/expose_biomni_server/run_mcp_server.py

這個雙向 MCP 能力，是評估「是否要把 Biomni 接入 AIKT」時的一個重要切入點——理論上可以不直接內嵌 Biomni 的巨型 conda 環境，而是讓 Biomni 以獨立 MCP server 的形式運行（例如在隔離容器內），AIKT 端只需要一個 MCP client 即可呼叫，大幅降低整合的環境相依複雜度（詳見第 7.4 節的風險評估）。

7. 與 AIKT 的關聯分析 (AIKT Integration Analysis)

7.1 定位判斷

Biomni 與 AIKT 屬於互補而非重疊的兩套系統：AIKT 是「知識擷取、索引、教學生成、研究流程編排」的 28 層 CLI 工具集，本身不執行生物醫學分析；Biomni 是「執行生物醫學分析任務」的 agent。兩者的交集點在於：Biomni 本身可以作為 AIKT 知識庫裡的一筆知識資產（透過 gh-tutorial-qd 消化成教學），也可以作為 AIKT 未來擴充「執行層」的候選工具。

7.2 可作為 AIKT 資料來源或分析工具？

作為資料來源：是，且已經在發生。 本次任務本身就是 Layer 12（gh-tutorial-qd）把 Biomni 這個 repo 轉成教學文件、放進 projects/repo-snap-stanford/tutorials/，這是最直接的整合——Biomni 的知識（架構、用法、benchmark）被吸收進 AIKT 的知識庫。

作為分析工具：概念上可行，但需要謹慎評估。 若 AIKT 使用者的研究任務涉及具體的生物醫學資料分析（例如「幫我對這批基因做 GWAS 因果推論」），理論上可以把 Biomni 當作一個「執行後端」呼叫。但 Biomni 需要完整巨型 conda 環境與大量系統權限（見第 8 節安全警告），與 AIKT 目前「CLI-first、輕量 script 入口」的設計哲學有落差，直接內嵌並不合適。

7.3 適合包裝此專案的 AIKT Layer

flowchart TB
    subgraph aikt["AIKT 系統"]
        L2["L2 ai-gh-save
GitHub repo → inbox md"]
        L9["L9 paper-search
學術搜尋"]
        L12["L12 gh-tutorial-qd
repo → 教學全套"]
        L18["L18 research-pipeline-v2
多輪研究 pipeline"]
        L19["L19 tu-plan-generator
藥物開發計畫"]
        L26["L26 layer-creator
新增專屬 layer"]
    end

    subgraph biomni["Biomni 系統"]
        B1["A1 Agent
自主生醫任務執行"]
        B2["Biomni-Eval1
能力評測 benchmark"]
        B3["Know-How Library
協定/SOP"]
        BR["論文 bioRxiv
2025.05.30.656746"]
    end

    BR -->|論文全文擷取| L9
    biomni -->|repo 架構+用法| L2
    L2 --> L12
    L12 -->|已完成:本教學| OUT1["projects/repo-snap-stanford/
tutorials/01-Biomni.md"]

    L19 -.需要 ADMET/藥物性質數據時可參考.-> B1
    L18 -.多輪研究若涉及濕實驗設計.-> B3

    style OUT1 fill:#2d7d46,color:#fff
    style B1 fill:#4A154B,color:#fff

具體對應：

7.4 潛在整合場景與價值評估

1. 教學資產（已實現，高價值、低風險）：把 Biomni 的架構、API 用法轉成雙語教學文件，供團隊內部學習或未來評估是否採用。
2. 研究情報來源（中價值、低風險）：透過 paper-search 追蹤 Biomni 團隊後續論文（如 Biomni-R0 technical report、Biomni-E2 社群共建進度），了解該領域 agent 框架的演進方向。

7.5 結論

Biomni 目前最務實的定位是 AIKT 知識庫裡的一份高品質教學資產與研究情報來源，而非可以直接掛載執行的分析引擎。若團隊未來有明確的生物醫學分析自動化需求，可以此教學文件為基礎，評估是否新增獨立 Layer 並搭配容器化隔離。

8. 優缺點與生態系定位 (Strengths, Limitations & Ecosystem Position)

8.1 核心優勢與創新點

• 真正的跨領域覆蓋：18 個生物醫學子領域工具模組（biochemistry、genetics、genomics、immunology、pathology、pharmacology、synthetic_biology 等），加上上百個資料庫 schema（ClinVar、ChEMBL、cBioPortal、GEO、gnomAD、dbSNP 等），廣度在同類開源 agent 中相當罕見。
• Retriever 驅動的工具選擇：不是暴力把所有工具塞進 context，而是用檢索機制動態篩選，兼顧擴展性（可以持續加工具而不爆 token）與準確性。
• Know-How Library 是差異化亮點：多數 agent 框架只給工具，Biomni 額外提供「怎麼把工具用好」的實驗協定與最佳實踐知識，這是把「隱性知識」顯性化、可檢索化的實際做法。
• 多 LLM 供應商中立：透過 biomni/llm.py 的統一介面，同一套 agent 邏輯可以換用 Claude、GPT、Gemini、Bedrock、本地 Ollama 或自訓練的 Biomni-R0，不綁定單一供應商。
• 自建 benchmark（Biomni-Eval1）：433 個實例、10 種生物推理任務，讓「這個 agent 到底行不行」有客觀量化依據，而非只靠 demo 展示說服人。
• 開放治理模式：明確的貢獻指南、社群共建 Biomni-E2 的公開號召、貢獻者可列名共同作者的誘因設計，顯示團隊有意識地在經營一個長期生態系而非發布即棄的論文程式碼。

8.2 目前限制與改進空間

• 安全性是最大隱憂：官方文件明確警告「Biomni 目前以完整系統權限執行 LLM 產生的程式碼」，可以存取檔案、網路與系統指令。這代表在正式環境使用必須自行做沙盒隔離，官方目前未內建這層防護，對非資深工程背景的生物學家使用者是實質風險。
• 環境安裝成本高：巨型 conda 環境 + R 套件 + CLI 工具鏈 + 11GB data lake，安裝門檻遠高於一般 pip 套件，對輕量試用不友善。
• 授權碎片化：Biomni 本身 Apache 2.0，但整合的工具/資料庫可能帶有更嚴格的商業授權，需要使用者自行逐一檢視——commercial_mode 緩解了一部分但無法完全消除這個負擔。
• 版本凍結說明：README 明確指出「此開源釋出版本凍結於 2025 年 4 月 15 日」，與線上 web 平台版本有落差，代表 repo 版本可能落後於團隊內部持續迭代的正式產品。
• 工具品質不均：專案自己在 Contributing Guide 中承認「許多現有工具尚未最佳化，歡迎修正替換」，說明大量工具是快速堆疊出來的廣度優先產物，深度與穩定性仍有成長空間。

8.3 與同領域工具的比較

Biomni 補的是「探索階段」的空缺——研究者還不確定要用哪個工具、哪個資料庫時，用自然語言快速試探；一旦分析流程確定下來，仍建議轉換成 Nextflow/Snakemake 這類版本可控、可重現的正式 pipeline。

8.4 適用場景建議

• 適合：跨領域文獻/資料庫快速查詢、CRISPR/scRNA-seq 等常見分析的初步探索、生成待驗證的研究假說、教學與內部知識庫建設。
• 需要額外把關：涉及病患隱私資料或機敏商業資訊時，務必先做沙盒隔離與人工審核輸出，不宜直接信任 agent 自動執行的程式碼。
• 不建議：需要嚴格法規遵循可重現性的正式臨床/監管送件分析（如 pre-IND、NDA 相關資料處理）——這類場景建議走傳統可審計 pipeline，Biomni 更適合作為早期探索或交叉驗證的輔助工具。

8.5 生態系演進脈絡：從 E1 到 E2、從 A1 到 R0

理解 Biomni 目前所處階段，有助於判斷它的成熟度：

flowchart LR
    E1["Biomni-E1
現行環境
(18 領域工具+資料湖)"] -->|社群共建 call for contributors| E2["Biomni-E2
下一代環境
(進行中)"]

    A1Agent["A1 Agent 框架
(可搭配任何 LLM)"] -->|訓練專用推理模型| R0["Biomni-R0
Qwen-32B + RL
(工具使用/多步推理專精)"]

    Eval1["Biomni-Eval1
433 實例/10 任務類型"] -.評測.-> A1Agent
    Eval1 -.評測.-> R0

    style E1 fill:#16213e,color:#fff
    style E2 fill:#0f3460,color:#fff,stroke-dasharray: 5 5
    style R0 fill:#4A154B,color:#fff

README 自陳「Biomni-E1 只觸及生物醫學行動空間的表面」，並公開號召社群共建 Biomni-E2、承諾對重大貢獻者提供論文共同作者資格。這代表：(1) 目前的工具廣度雖然已經橫跨 18 個領域，但團隊自己認為深度與完整度仍在早期階段；(2) 專案採用開放治理模式吸引長期社群投入，而非閉門開發——這對評估「值不值得長期投資學習/整合這個工具」是正面訊號，但也意味著 API 與工具集在未來版本可能有較大變動，值得留意 CHANGELOG 與版本號。

8.6 一句話總結

Biomni 是目前開源生態系中廣度最突出的生物醫學 AI agent 框架之一——它用檢索驅動的工具選擇 + 知識庫 + 程式碼執行迴圈，把「博士後等級的跨領域工具箱」封裝成自然語言可驅動的介面；但它的安全模型（完整系統權限執行程式碼）與環境安裝成本目前仍偏向研究原型階段，正式導入生產環境（尤其是涉及機敏資料或法規遵循的場景）前，務必先完成沙盒隔離與人工審核機制。

附錄 A：A1() 建構子完整參數表

附錄 B：關鍵檔案索引