信息速览
生命科学里的分析，绝大多数不是一个人从头写的程序，而是一串别人写好的工具首尾相接。测序读段要清洗、比、定量、注释，每一步都有若干候选软件，各自的输入格式、输出格式、参数命名互不相同。做完一轮分析，隔半年想复现，第一个卡住的地方往往不是算法，而是「当时用的是哪个工具、什么版本、参数怎么填」——这句话在论文的方法部分常常只有半行。
bio.tools 就是为这半行存在的。它不存数据，存的是软件的描述：某个工具做什么操作、吃什么格式、吐什么格式、主页在哪、该引哪篇论文。这些信息被压进一套受控的结构里，用 EDAM 本体把「操作」「数据类型」「文件格式」变成机器能比较的词，于是你可以问「有哪些命令行工具能做多序列比对、并且接受 FASTA 输入」这种问题，并且得到一个可以复制的答案。
但它是一本人写的登记册，不是一台自动运行的仪器。条目由社区贡献与编辑审核混合产生，同一工具可能有不止一条记录，有的条目描述的软件早已迁移，有的记录停更多年而软件还在发版。这种「登记册与现实的偏离」不是缺陷报告里的一条，而是使用它的前提。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 官方名称 | bio.tools |
| 运营方 | ELIXIR（欧洲生命科学基础设施），由多个欧洲节点与编辑团队共同维护 |
| 定位 | 软件与数据资源登记册，不是数据集 |
| 起步时间 | 2014 年前后上线，2019 年在《基因组生物学》上首次系统介绍 |
| 记录规模 | 官方 2026 年论文口径 32,950 条（官方页面称） |
| 贡献者 | 同一论文口径 14,729 位 |
| EDAM 标注总量 | 同一论文口径 211,404 条 |
| 标注四类 | 主题 110,223 / 功能 77,988 / 数据类型 11,902 / 格式 11,291 |
| 核心标准 | biotoolsSchema（记录的字段结构）+ EDAM 本体（概念的受控词表） |
| 主键 | biotoolsID，持久标识，记录删除后仍保留 |
| 主要字段 | 名称、短描述、工具类型、功能（输入→操作→输出）、链接、文献、贡献者、许可、收费、平台、语言、文档 |
| 工具类型分布 | 命令行工具 9,546 / 网页应用 7,667 / 库 5,840 / 数据库门户 2,583 / 桌面应用 2,050 等十余类 |
| 取数方式 | 网页界面 + REST API（JSON，另支持 XML、JSON-LD、YAML） |
| 分页 | 每页 50 条，全量需翻页 |
| 许可 | 登记册免费公开；EDAM 本体为 CC BY-SA 4.0；单条工具的许可随工具而定 |
| 最大的坑 | 记录描述的是「元数据被编辑时」的状态，不是软件今天的状态 |
§1 它要解决的具体麻烦
1.1 复现失败最常见的落点是「工具身份不明」
想象一个具体的场景：某篇 2021 年的论文在方法部分写「比对采用行业标准流程，参数按软件推荐」。两年后，一个临床研究团队想在这批样本上复现它的差异表达结果，同时想把它迁移到自己医院的队列上。他们照做，跑出来的基因排序和原文差得很远。
排查到最后，问题不在统计方法，也不在样本，而在「行业标准流程」这五个字。原作者用的比对器有三个常用分支，分支之间对错配的罚分不同；量化步骤有两个版本，其中一个版本改了默认的双端处理逻辑；甚至有一步用的其实是一个五年前就不再更新的工具。这些信息在论文里一个字都没有。
bio.tools 能解决的是这一层的三分之一：它至少把「这个工具是什么、做什么操作、吃什么格式」写成了结构化字段。你能拿原文里出现的工具名去查，查到它的功能描述、主页、引用文献，确认它与你手上那个工具是不是同一个东西。剩下的三分之二——版本、参数、运行环境——得回到软件自己的仓库与文档里去补。
所以它的定位是明确的：它是追查工具身份的第一站，不是复现分析的完整答案。
1.2 三条常见的错误期待
期待一：把它当成软件下载站。 下载链接指向工具自己的主页、仓库或包管理器，登记册不托管任何可执行文件。点链接就离开了 bio.tools，装不装得上取决于那个工具自己。把「有这条记录」当作「有人维护、能装上」，是这里最常见的一次误判。
期待二：把它当成软件质量的评分表。 记录里没有评分字段，只有工具类型、平台、许可、收费这类描述。官方确实加了基于大模型的候选打分，但那衡量的是「这条记录值不值得花时间审」，不是「这个软件值不值得用」。把编辑侧的分流分数当质量分，是第二种误判。
期待三：把它当成实时同步的目录。 记录里的日期是元数据被编辑的时间，不是软件发布时间。2024 年更新过描述的工具，可能对应 2013 年就没再发版的程序；2016 年后没再动过的记录，对应软件可能一直在更新。两个方向都会发生。
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 确认论文里提到的工具到底是哪一个 | 名称、主页、文献 DOI、功能描述 | 基本够 |
| 知道这个工具吃什么格式、吐什么格式 | EDAM 数据类型与格式标注 | 够，但标注深度不一 |
| 找一个能做某操作的替代工具 | 按 EDAM 操作与数据格式筛选 | 够，这是它的强项 |
| 判断两个工具能不能接成流水线 | 输入输出格式的机器可读描述 | 需要自己比对，不是现成结论 |
| 这个工具的当前版本号 | 没有强制版本字段 | 不够 |
| 软件的下载与安装 | 只给外链，不托管 | 需另找 |
| 软件的质量或准确度评价 | 无评分字段 | 不够 |
| 软件是否仍在维护 | 日志显示最近编辑时间 | 只能间接推断 |
| 软件许可与是否收费 | 有字段，但官方承认二者常不一致 | 部分够 |
| 一份可以直接喂给模型的结构化工具清单 | API 可批量导出 JSON | 够 |
| 中文学科术语 | 无，全英文 | 不够 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 追一篇临床论文的方法部分，只写了工具名没写版本 | 用工具名查到主页与引用文献，缩小候选范围 | 到主页或代码仓库看发版记录，锁定论文发表前后的版本 |
| 设计一个新流程，每步都要选工具，候选太多 | 按 EDAM 操作 + 输入格式 + 工具类型三重筛 | 对筛出的候选逐个看标注完整度，再决定试用顺序 |
| 平台上要展示「本院可用软件目录」 | 用集合与领域字段组织子集，API 取结构化清单 | 建立内部镜像，定期同步，别在前端实时打它的 API |
| 做软件使用情况的文献计量 | 批量导出记录，按贡献者、主题、类型统计 | 记录导出时间与快照口径，写成方法学说明 |
| 想引用一个工具但不确定该引论文还是引程序 | 记录里同时有文献与链接字段 | 引论文，同时在方法部分写明版本与访问日期 |
| 拿到一份老流程，名字全对但跑不通 | 查工具是否已被新项目取代、主页是否已迁移 | 回到记录里的链接逐个验证可达性 |
| 想给某个软件补一条缺失的记录 | 开放注册与认领机制 | 走分面向导提交，通过 schema 校验后入库 |
1.5 一句话判断
bio.tools 回答的是「这个工具是谁、它做什么、它吃什么吐什么」，不回答「它好不好、它现在是什么版本、它在你的机器上能不能跑」。前三问交给它，后三问必须自己走完。
1.6 不适合谁：四条边界
把它当成软件质量排行榜的人，不适合用。 它没有评分，也不打算有。检索结果的默认排序参考的是匹配度与文献计量，与软件的可靠性无关。按结果第一条直接用，等于把「被人写在最前面」当成「最值得信任」。
需要精确版本与依赖清单的人，不适合把它当唯一依据。 复现一个流程需要的锁版本信息在容器镜像、包管理器锁文件与代码仓库的 tag 里。登记册给的是「这是哪个工具」，容器给的是「这是哪个构建」。两者不能互相替代。
做中文界面或中文知识库的人，要注意它的词表是英文的。 EDAM 概念的名称、定义、同义词全是英文，登记册的描述字段也以英文为主。要在中文环境里用它，得自建一层术语映射，而这层映射的成本常常被低估。
想把它当权威软件清单来排名或评比的人，不适合。 覆盖不均与标注深度不一是社区贡献模式的固有结果，官方论文自己也把它列为局限。拿它做「某领域工具数量统计」时，你统计到的是「被收录的数量」，不是「存在的数量」。
§2 数据构成与规格
2.1 一条记录由什么组成
一条 bio.tools 记录不是一张扁平的表格，而是分层的。最外层是条目标识与归属信息，中间层是功能描述，内层是各种外链与标签。
| 层 | 内容 | 是否强制 | 备注 |
|---|---|---|---|
| 标识层 | biotoolsID、名称、短描述 | 是 | 标识符持久，删除后仍保留 |
| 分类层 | 工具类型、平台、语言 | 类型必填，其余可选 | 受控词表 |
| 功能层 | 输入（数据+格式）→ 操作 → 输出（数据+格式） | 核心，常不完整 | 用 EDAM 概念 |
| 溯源层 | 文献、贡献者、致谢、创建与编辑时间 | 部分必填 | 决定可信度 |
| 可得层 | 主页、下载、仓库、容器、文档、培训 | 至少一项 | 决定能不能真的拿到 |
| 政策层 | 许可、收费、可访问性 | 可选 | 官方承认常不自洽 |
| 组织层 | 集合、领域、社区 | 可选 | 用于分主题浏览 |
这些层的重要性不是平级的。对追查工具身份的人来说，溯源层与可得层才是真正决定能不能复现的两层；对做流程编排的人来说，功能层才是核心。同一份记录，不同的用法看的是不同的地方。
2.2 字段与记录的完整字典
下表的字段按用途归组，右侧说明的是「这个字段在什么情况下会让你误判」。字段名沿用 biotoolsSchema 的英文书写，中文只作解释。
| 字段 | 层 | 取值形态 | 说明与常见陷阱 |
|---|---|---|---|
| biotoolsID | 标识 | 字符串，如 blast |
持久标识，删除后不复用；但不是版本号 |
| name | 标识 | 自由文本 | 常与软件品牌名一致，也常带变体写法 |
| description | 标识 | 一两句英文 | 近年部分由大模型生成后经编辑审核 |
| toolType | 分类 | 受控词表，十余种 | 命令行、网页应用、库、数据库门户等 |
| topic | 分类 | EDAM 主题概念列表 | 描述研究领域，可多个，跨领域工具常标不全 |
| operation | 功能 | EDAM 操作概念列表 | 描述执行什么变换，是替代工具检索的主键 |
| function.input | 功能 | 数据概念 + 格式概念 | 常只填数据不填格式，导致格式比对失效 |
| function.output | 功能 | 数据概念 + 格式概念 | 同上 |
| homepage | 可得 | URL | 失效率最高的字段，迁移后常未更新 |
| download | 可得 | URL 列表 | 指向包管理器或发行页，不托管文件 |
| repository | 可得 | 代码托管 URL | 判断是否还在维护的第一手线索 |
| link | 可得 | 类型 + URL 列表 | 文档、培训、容器、镜像等 |
| publication | 溯源 | DOI + 文献元数据 | 有的记录列多篇，有的只列首发论文 |
| credit | 溯源 | 人名 + 类型 | 区分开发者、贡献者、编辑 |
| contributor | 溯源 | 账号 + 编辑时间 | 多人编辑时最早最晚时间差很大 |
| elixirPlatform / elixirNode | 组织 | 受控值 | 与欧洲节点相关，非欧洲机构多为此项空 |
| license | 政策 | 自由文本 | 官方承认与收费字段常不一致 |
| cost | 政策 | 免费 / 付费 / 未知 | 「免费」不等于可自由再分发 |
| accessibility | 政策 | 如开放、需注册 | 与 cost 是两件事 |
| operatingSystem | 分类 | 受控词表 | 只填了 Linux 而实际也支持 macOS 的情况常见 |
| language | 分类 | 受控词表 | 指实现语言，不是界面语言 |
| documentation | 可得 | URL 列表 | 判断标注是否可信的旁证 |
| collectionID / domain | 组织 | 标识符 | 同一工具可属于多个集合 |
这张表必须说清楚边界：官方 API 在本次核验的条件下无法用脚本直取，记录级的完整字段清单没有逐项确认，上表按官方论文正文与接口说明整理。表里没有列出的字段，不等于不存在；表里列出的字段，也不保证每条记录都填了。要在生产环境依赖某个字段，请以实际接口返回为准。
2.3 一条记录的完整解剖
下面这份 JSON 是按 biotoolsSchema 的结构手写的示例，字段名与层级与官方文档一致，取值是示意值。它的作用是让你看清「输入→操作→输出」这组关系是怎么被写进结构的。
{
"biotoolsID": "example_aligner",
"name": "Example Aligner",
"description": "Pairwise aligner used as a worked example in this article.",
"toolType": ["Command-line tool"],
"topic": [
{"term": "Sequence analysis", "uri": "http://edamontology.org/topic_0080"}
],
"function": [
{
"operation": [
{"term": "Sequence alignment", "uri": "http://edamontology.org/operation_0292"}
],
"input": [
{"data": {"term": "Sequence", "uri": "http://edamontology.org/data_2044"},
"format": [{"term": "FASTA", "uri": "http://edamontology.org/format_1929"}]}
],
"output": [
{"data": {"term": "Sequence alignment", "uri": "http://edamontology.org/data_0863"},
"format": [{"term": "SAM", "uri": "http://edamontology.org/format_2573"}]}
]
}
],
"homepage": "https://example.org/example-aligner",
"download": ["https://example.org/example-aligner/download"],
"repository": "https://example.org/example-aligner.git",
"publication": [
{"doi": "10.0000/example.2021.001", "pmid": "00000000", "type": "Primary"}
],
"license": "MIT",
"cost": "Free of charge",
"operatingSystem": ["Linux", "macOS"],
"language": ["C"],
"documentation": ["https://example.org/example-aligner/docs"]
}
三个细节值得停一下。
第一，function 是一个数组，不是单值。一个工具常常同时具备多个功能，例如比对与建索引。判断「它能不能做某件事」时，要遍历整个数组，不能只看第一项。
第二，input 与 output 里，data 和 format 是两个独立的概念层级。EDAM 把它们分得很细：数据类型说的是「这是一段序列」，格式说的是「这段序列写成了 FASTA 文件」。这种分离是流程编排能够自动化的基础，也是标注不全时最常缺的那一块——很多记录只填了数据类型，没填格式。
第三，publication 带 type 字段，用来区分首发论文、后续改进、使用方法等。有的记录只列了首发论文，而这恰恰是最容易过时的那一篇：后续的分支、重新实现、重大版本，往往对应另一篇文献。
2.4 规模与构成的几个口径
bio.tools 的规模数字有一套相对清晰的官方口径，这是它比多数社区型资源更好的地方：官方论文的统计表明确写了「本表数字取自官方 /api/stats 端点」。
| 口径 | 数值 | 含义 |
|---|---|---|
| 记录总数 | 32,950 | 登记的条目数，不是不同的软件数 |
| 贡献者总数 | 14,729 | 提交过或编辑过记录的人数 |
| EDAM 标注总量 | 211,404 | 四类标注的合计 |
| 其中主题标注 | 110,223 | 平均每条记录三项以上 |
| 其中功能标注 | 77,988 | 操作概念，平均每条两项以上 |
| 其中数据类型标注 | 11,902 | 明显少于前两类 |
| 其中格式标注 | 11,291 | 与数据类型标注接近 |
| 有无工具类型标注 | 31,943 | 覆盖绝大多数记录 |
| 有无文献标注 | 33,827 | 多于记录总数，说明存在一条记录多篇文献 |
| 有无操作系统标注 | 53,692 | 一条记录可挂多个平台 |
| 有无代码可得性标注 | 48,322 | 同上，一条记录多个仓库链接 |
| 有无文档标注 | 17,408 | 覆盖约一半 |
| 有无可访问性标注 | 9,138 | 覆盖不到三成 |
| 有无社区标注 | 16,277 | 约一半 |
| 有无下载标注 | 6,571 | 覆盖不到两成 |
这张表最有信息量的一行是数据类型与格式：它们的数量都只有一万一出头，而主题与功能都是五位数的高位。换算下来，大约三分之二的记录没有有效的数据类型标注。这一点直接决定了它的能力边界——它擅长的检索是「按领域找工具」「按操作找工具」，不擅长的是「按格式找工具」与「自动拼装流水线」。
第二有信息量的行是文献标注数多于记录总数。这说明同一工具常常有不止一篇文献被登记，也说明「一条记录对应一篇论文」这个直觉不成立。
§4.5 的案例里那两条记录的分歧，正是这张表能提前预警的那类问题：功能标注齐全的一条与只有主页的一条，在字段表上的差别一眼可见。
第三是下载标注只覆盖不到两成。这一条要小心解读：它不代表八成工具拿不到，而是说明记录里不常填下载地址，因为很多工具通过包管理器分发，不必单列下载页。把「没有下载字段」当成「不可用」，是这张表最容易引出的误读。
2.5 工具类型与同类资源的字段差异
工具类型是最能反映登记册性质的字段。官方统计给出十六个取值，下表列出前五与其余合计。
| 工具类型 | 数量 | 占比 | 典型形态 | 复现时的注意点 |
|---|---|---|---|---|
| 命令行工具 | 9,546 | 约 29% | 编译后二进制或脚本 | 依赖与编译选项是复现关键 |
| 网页应用 | 7,667 | 约 23% | 浏览器访问的服务 | 服务下线则记录失效 |
| 库 | 5,840 | 约 18% | 供其他程序调用的代码包 | 版本漂移最隐蔽 |
| 数据库门户 | 2,583 | 约 8% | 查询界面与数据源 | 数据版本与软件版本分离 |
| 桌面应用 | 2,050 | 约 6% | 带图形界面的程序 | 界面版本难以在命令行复现 |
| 其余十一类合计 | 5,264 | 约 16% | 脚本、工作流、套件、插件等 | 边界模糊，归类常不一致 |
「其余十一类」里有几类值得单独提：工作流、套件、插件、本体、SPARQL 端点。套件与插件的归类不一致是这套资源上的一个真实摩擦点：一个工具既可以算「套件」，也可以算「库」，取决于提交者当时怎么想。做计数统计时，工具类型不是互斥的硬分类。
与同类资源的字段差异，可以按「存什么」来看：
| 维度 | bio.tools | Bioconda | BioContainers | Galaxy 工具库 | WorkflowHub |
|---|---|---|---|---|---|
| 存什么 | 软件描述 | 包配方与构建 | 容器镜像 | 可执行的工具封装 | 工作流描述 |
| 核心标识 | biotoolsID | 包名 + 版本 | 镜像摘要 | 工具封装标识 | 工作流标识 |
| 是否有 EDAM 标注 | 有，四类 | 无 | 部分继承 | 部分 | 部分 |
| 是否有版本字段 | 无强制字段 | 有，强约束 | 有，摘要固定 | 有 | 有 |
| 是否托管可执行物 | 不托管 | 托管配方 | 托管镜像 | 不托管 | 不托管 |
| 与 bio.tools 的关系 | 本体 | 引用其标识 | 引用其标识 | 引用其标识 | 引用其标识 |
这张表说的是一件明确的事：bio.tools 是这一组资源里的「描述层」，其他几个是「构建层」与「执行层」。描述层回答「这是什么」，构建层回答「怎么装」，执行层回答「怎么跑」。任何一层单独都不足以复现。
§3 身份：它在生物信息学版图里站的位置
3.1 它补的是「软件的可发现性」这一环
生物信息学的资源大致可以按「存什么」分三类。存观测的，如基因表达数据库、蛋白结构库；存知识的，如通路库、本体；存工具的，就是登记册这一类。第三类长期是最混乱的一类，因为软件不像数据那样有强制提交的政策，也不像知识那样有明确的策展主体。大量工具的存在形式是「某实验室主页上的一个压缩包」。
bio.tools 的出现把第三类资源从「网页索引」升级成了「结构化登记」。这件事的价值不在于它收了多少条，而在于它把「软件」这个对象拆成了可以比较的属性：它做什么操作、处理什么数据、支持什么平台、由谁贡献、引哪篇文献。一旦这些属性变成字段，就能被检索、被筛选、被程序读取、被别的服务复用。
官方论文里有一句话点明了这个转变的性质：软件信息只有被策展、被标准化、并以网络服务的形式交付，才可能被充分利用。这句话的潜台词是——工具的可发现性本身就是一个基础设施问题，不是搜索引擎能顺带解决的事。
3.2 三层结构：描述层、构建层、执行层
理解 bio.tools 最有效的框架，是把它放进 ELIXIR 研究软件生态的三层结构里。
| 层 | 代表服务 | 回答的问题 | 与 bio.tools 的接口 |
|---|---|---|---|
| 描述层 | bio.tools、ToolFinder、领域门户 | 这是什么、做什么 | 本层 |
| 构建层 | Bioconda、BioContainers、Debian Med | 怎么装、装哪一版 | 引用 bio.tools 标识做交叉链接 |
| 执行层 | Galaxy、WorkflowHub | 怎么串起来跑 | 用 bio.tools 标识自动注释步骤 |
| 评价层 | OpenEBench | 可用性、引用量等指标 | 从 bio.tools 记录跳到评价页 |
| 培训层 | TeSS | 哪里能学 | 记录里的培训链接 |
官方论文给出了一组具体的交叉引用数：Galaxy 用了 502 个 bio.tools 标识，Debian Med 用了 357 个，Bioconda 用了 1,784 个，BioContainers 用了 1,134 个，ToolFinder 用了 526 个。这几个数的量级差异本身就是信息：同一批标识在不同服务里覆盖差了三到五倍，「被 bio.tools 收录」与「被构建层收录」是两件独立的事。
3.3 维护结构与编辑分工
bio.tools 的运营主体是 ELIXIR，但实际的生产者是三类人。
第一类是工具开发者本人。他们最清楚自己的软件做什么，通过分面向导提交记录，并可以申请认领已有记录的所有权，以便日后更新。
第二类是社区贡献者与领域策展人。他们把同领域的工具整理成集合或领域视图，例如蛋白组学、罕见病这类专题。领域视图不改变记录本身，只提供一个视角。
第三类是编辑团队。他们处理文献挖掘产出的候选、复核机器生成的描述、解决归属争议。官方论文给了 2024 年 2 月的一次具体操作：文献挖掘与模型打分产出 159 个候选，人工复核后压到 85 个，其中 65 个被另一位编辑按旧流程确认，16 个标记待查，4 个被认为不值得收录；对这 4 个再做更细的核查后发现，其中 1 个网页已不可用，另外 3 个其实合格。
这段记录暴露了机制的精度：人工复核把 159 压到 85，压掉接近一半，而被压掉的里面又有几个是误杀。自动候选远不足以直接入库，人工复核也不是绝对可靠。
3.4 三条身份线：描述层、元数据上游、社区项目
把 bio.tools 当成一个整体，会看不清它。它其实同时扮演三个角色。
角色一：面向人的检索界面。 这是大多数人对它的印象——打开网页，输入关键词或 EDAM 概念，得到一列工具。
角色二：面向程序的元数据上游。 这是它近年的重心。官方论文明确说它已成为「上游元数据源」，被生态内其他服务复用做同步与交叉链接。对做平台的人来说，这个角色比第一个重要得多。
角色三：一个社区项目。 记录由社区贡献，领域视图由社区创建，改进意见在每年的欧洲生物信息学黑客松上讨论。它的质量上限由社区的活跃度决定，不由运营方的预算决定。
三种角色各有一套风险：检索者怕排序误导，集成者怕字段缺失与标识漂移，贡献者怕时间白投。§4 与 §7 就在这三条线上展开。
§4 质量：记录描述的到底是哪个时点
4.1 一条记录的生命周期有四个不同的时间
这是使用 bio.tools 最需要建立的一个直觉：一条记录上有四个时间，它们各自意味着不同的事情，混起来就会误判。
| 时间 | 含义 | 容易误判成 |
|---|---|---|
| 记录创建时间 | 条目第一次入库 | 软件首次发布 |
| 记录编辑时间 | 元数据最后一次被改 | 软件最后一次更新 |
| 文献发表时间 | 引用论文的出版年 | 软件当前版本对应的论文 |
| 软件实际发版时间 | 只在代码仓库或主页可见 | 记录编辑时间 |
四个时间常常彼此相隔数年：2024 年编辑过的记录，可能对应 2014 年发版后就没动过的程序；2016 年入库后没再改过的记录，对应的软件可能一直在更新。
判断工具是否还在维护，不能看记录时间，要看记录里的仓库链接：最后提交在何时、有无未处理议题、有无近年发版。三个信号登记册里没有，仓库里全有。
4.2 三种「偏离」，以及各自的识别方法
社区贡献 + 编辑审核的混合模式，稳定地产生三类偏离。每一类都有具体的识别方法，不靠猜测。
| 偏离类型 | 表现 | 识别方法 | 危害 |
|---|---|---|---|
| 重复条目 | 同一工具两条记录，名称近似、主页一致 | 按主页 URL 或文献 DOI 去重 | 检索结果重复，计数虚高 |
| 迁移未同步 | 记录仍指向旧主页或旧仓库 | 逐个访问记录里的链接，看是否跳转 | 按旧地址装到废弃版本 |
| 描述滞后 | 记录停更多年，软件仍在发版 | 对比记录编辑时间与仓库最近提交 | 误判软件已死，选错替代方案 |
第四类偏离值得单独说：被取代但未标注。当一个工具被新项目继承（改了名字、并入了另一个套件、把仓库搬到新组织），旧记录常常不会被删除。原因在官方论文里有一句直接说明——记录可以被管理员删除，但持久标识符会保留下来，删除记录的信息也仍保存在生态的历史里。这条设计保证了标识符不会指向「不存在」，代价是你无法靠标识符消失来判断工具已被放弃。
这是本文反复要强调的一点：在这套资源里，「记录还在」这件事不构成「工具还在」的证据。
4.3 标注深度不均的三个层级
同样是「有记录」，标注的完整度可以差出三个量级。
| 层级 | 特征 | 大致能做什么 | 识别信号 |
|---|---|---|---|
| 骨架级 | 只有名称、主页、类型 | 知道它存在 | 功能字段为空 |
| 功能级 | 有操作与数据类型 | 找替代、初步拼流程 | 缺格式标注 |
| 完整级 | 操作、数据类型、格式齐全，文献与文档齐备 | 自动流水线编排、格式兼容性判断 | 字段几乎无空项 |
官方论文里那个例子正好说明完整级的价值：检索「命令行工具 + 多序列比对操作 + FASTA 输入」，得到 11 个工具。这个检索能成立，前提是那批记录同时填了工具类型、操作与输入格式三项。换一个标注不全的子领域，同样的检索会漏掉大半。
对做流程编排的人来说，这个差异是决定性的。只填了数据类型、没填格式的记录，无法参与「输出格式是否匹配输入格式」的判断；而格式标注只覆盖了三分之一的记录（按 §2.4 的换算）。
4.4 五个维度的评分
这里的评分按本文自定的五个维度给出，是相对同类资源的判断，不是官方评分，也不构成对软件的推荐。
| 维度 | 评分 | 依据 | 主要缺口 |
|---|---|---|---|
| 覆盖面 | A- | 近三万三千条记录，覆盖生命科学主要分支 | 子领域之间疏密不均 |
| 结构化程度 | A | biotoolsSchema 约束 + EDAM 四类标注，机器可读 | 格式与数据类型标注只覆盖约三分之一 |
| 标识稳定性 | A | 持久标识，删除后不复用 | 稳定的是标识，不是内容 |
| 时效性 | C+ | 有持续编辑与文献挖掘补录 | 描述滞后与迁移未同步普遍存在 |
| 取数便利度 | B- | 有文档化的 REST API，支持多种格式 | 站点前置脚本质询，纯脚本客户端受阻 |
分数的排列本身就是结论：它的强项在「结构」，弱项在「时效」与「取数」。这与社区型登记册的常见形态一致，也决定了它该被当作「起点」而不是「终点」。
4.5 案例：两条 MAFFT 记录与一次版本回溯
为了把上面的抽象讲成具体的形状，下面这个案例按真实工作流的结构组织，工具名用官方论文里举过的那个，记录细节为示意。
第一步，检索。 一个团队要复现某篇 2019 年论文的多序列比对，原文只写了「用 MAFFT 默认参数」。他们在 bio.tools 检索这个名称，得到不止一条结果：一条是命令行工具类型、功能标注齐全、挂了两篇文献；另一条名称带后缀、类型标为网页应用、只有主页与一句描述。
第二步，判断该用哪条。 两条记录的主页指向同一个项目的不同入口。命令行那条的文献列表里有首发论文与一篇使用方法文章，网页应用那条只列了首发论文。按 §4.2 的重复识别方法，他们以主页域名与文献 DOI 比对，确认两者描述的是同一个软件的不同分发形态，不是两个工具。此时真正该拿来写进方法部分的是命令行那条，因为只有它能锁版本、锁参数。
第三步，回溯版本。 记录里没有版本字段。他们从记录里的代码仓库链接进去，看发版记录，找到 2019 年论文发表前后对应的两个版本，再比对这两个版本的默认参数说明，确认它们在比对策略的默认值上确实不同——这解释了为什么他们最初照「默认参数」跑，结果和原文对不上。
第四步，修正与回写。 他们把自己的发现整理成一段描述补充，通过认领机制编辑那条命令行记录，把「默认策略在某两个版本间变更」写进描述字段。这一步是这套资源的正常使用方式：它不是只读的目录，使用者本身是它的维护者之一。
§4.5 的案例之所以值得反复引用，是因为它一次走完了这套资源的四个正确用法：检索定位、去重判断、版本回溯、回写修正。四步里没有一步能在登记册内部单独完成——第三步必须去仓库，第四步必须回到登记册。这种「一半在里面、一半在外面」的工作方式，就是使用它的常态。
4.6 DAIMS 二十四项逐项评分
上表是横向比较，下表是纵向拆解。按 DAIMS 框架的常见维度逐项给判断，✅ 记 1 分、⚠️ 记半分、❌ 记 0 分，满分 24。
| # | 维度 | 判 | 依据 |
|---|---|---|---|
| 1 | 资源唯一标识 | ✅ | 服务名与入口稳定，长期未变 |
| 2 | 条目持久标识 | ✅ | biotoolsID 持久，删除后不复用 |
| 3 | 版本化 | ⚠️ | 记录有编辑时间，无统一发布版本号 |
| 4 | 元数据标准 | ✅ | biotoolsSchema 明文定义字段结构 |
| 5 | 元数据完整性 | ⚠️ | 主题与功能覆盖高，格式与下载覆盖低 |
| 6 | 字段字典 | ✅ | 字段语义与受控词表有文档 |
| 7 | 数据模式 | ✅ | 有正式 schema 并做入库前校验 |
| 8 | 机器可读格式 | ✅ | JSON 为主，另支持 XML、JSON-LD、YAML |
| 9 | 接口可得 | ✅ | 有文档化的 REST 接口 |
| 10 | 批量导出 | ⚠️ | 分页每页 50 条，全量需数百次请求 |
| 11 | 许可明确 | ⚠️ | 登记册免费，单条工具的许可靠提交者填写 |
| 12 | 许可机器可读 | ⚠️ | 许可字段为自由文本，非标准 URI |
| 13 | 溯源 | ✅ | 文献、贡献者、编辑时间齐备 |
| 14 | 引用规范 | ⚠️ | 无逐条强制引用模板，需自行组合 |
| 15 | 来源声明 | ✅ | 记录里可查贡献者与文献 |
| 16 | 更新频率声明 | ⚠️ | 有文献挖掘的月度节奏，无全库更新承诺 |
| 17 | 缺失值说明 | ✅ | 字段级为可选，空即代表未标注 |
| 18 | 质量控制声明 | ✅ | schema 校验 + 人工复核 + 模型排序三关 |
| 19 | 覆盖说明 | ✅ | 官方论文自陈覆盖不均 |
| 20 | 文档完整性 | ✅ | 有接口表、流程说明、用户旅程 |
| 21 | 示例与教程 | ✅ | 论文给出可复制的检索 URL 与接口示例 |
| 22 | 社区支持 | ✅ | 年度黑客松、GitHub 议题、领域社区 |
| 23 | 长期保存承诺 | ⚠️ | 十余年持续运行，但无第三方归档镜像 |
| 24 | 伦理与合规声明 | ⚠️ | 软件登记不涉个人数据，合规条款较简 |
总分 19 / 24，约 79%。
这个分型很有辨识度：标准与流程一路绿灯，交付与许可一路黄灯。它说明这套资源把力气花在了「怎么把描述写对」上，没花在「怎么让人一次性拿全」。做学术检索的人更在意前者，做工程集成的人更头疼后者，这也是 §5 那条「增量同步优于全量遍历」的由来。
§5 取数：怎么把记录拿到手上
5.1 三条通道与各自的适用场景
| 通道 | 入口 | 适用 | 限制 |
|---|---|---|---|
| 网页界面 | https://bio.tools/ |
人工检索、浏览、单条查看 | 界面由前端渲染，脚本抓取拿到的是空壳 |
| REST API | https://bio.tools/api/tool |
批量取数、程序化筛选 | 前置脚本质询，纯脚本客户端被拦 |
| 统计端点 | https://bio.tools/api/stats |
拿总量与分类计数 | 本次核验未打通 |
| 单条导出 | 记录页的导出按钮 | 单条记录的 JSON | 需人工操作 |
| 生态镜像 | Bioconda、Galaxy 等引用方 | 反查标识是否被下游采用 | 只覆盖被引用的那部分 |
5.2 接口清单
官方论文给出的端点表是理解这套 API 最可靠的依据。下表按用途重排，并补上「是否需要认证」。
| 用途 | 方法 | 端点 | 说明 | 认证 |
|---|---|---|---|---|
| 列出全部工具 | GET | /api/tool |
分页，每页 50 条 | 否 |
| 全文检索 | GET | /api/tool/?q=alignment |
跨字段模糊匹配 | 否 |
| 按属性筛选 | GET | /api/tool/?topic= 加概念名 |
主题、操作、类型、语言、许可、集合等 | 否 |
| 单条记录 | GET | /api/tool/:id |
按 biotoolsID 取完整记录 | 否 |
| 列出全部领域 | GET | /api/d/all |
领域视图清单 | 否 |
| 单个领域 | GET | /api/d/:name |
领域视图详情 | 否 |
| 注册表统计 | GET | /api/stats |
总量与分类计数 | 否 |
| 新增记录 | POST | /api/tool |
提交新条目 | 是 |
| 更新记录 | PUT | /api/tool/:id |
修改已有条目 | 是 |
| 删除记录 | DELETE | /api/tool/:id |
删除条目，标识保留 | 是 |
两个使用细节值得记住。第一，官方论文说界面上的检索 URL 可以直接转成 API URL，方式是在路径中插入 /api 段。这意味着在浏览器里调好筛选条件后，把地址栏的地址改一处就能程序化复用，不必重新学一套参数名。第二，检索默认是模糊匹配，加引号变严格匹配；EDAM 概念既可以按名称查，也可以按概念标识查。
5.3 分页与全量遍历的现实
每页 50 条，三万条记录意味着近七百页。这是所有批量取数的起点，也是所有批量取数的问题所在。
| 参数 | 值 | 后果 |
|---|---|---|
| 每页条数 | 50 | 固定，官方未提可调 |
| 总页数 | 约六百六十页 | 全量需数百次请求 |
| 排序默认 | 按匹配度 | 逐页翻页时顺序稳定，但内容会随更新变化 |
| 可用排序 | 名称、更新时间、入库时间、引用量、出版日期 | 做增量同步时按更新时间倒序最实用 |
逐页遍历有一个不易察觉的坑：如果两次请求之间有条目被新增或删除，后面的页码会发生位移，导致漏取或重取。稳妥的做法不是从头翻到尾，而是按更新时间窗口切片，每次只取「编辑时间在某个区间内」的记录，把全量重建变成增量同步。
5.4 用 Python 走一遍检索
下面这段代码在能执行 JavaScript 的前提下工作，它做的是「按主题与操作筛选，取回结构化记录并落盘」。取值全部为形式参数之外的真实路径，唯一需要你自己填的是输出目录。
import json
import pathlib
import urllib.parse
import urllib.request
BASE = "https://bio.tools/api/tool"
OUT = pathlib.Path("biotools_dump")
OUT.mkdir(exist_ok=True)
def fetch(url):
#-- 部分网络环境下站点会前置脚本质询，这一步需在允许执行脚本的客户端里跑
req = urllib.request.Request(url, headers={"Accept": "application/json"})
with urllib.request.urlopen(req, timeout=60) as resp:
return json.loads(resp.read().decode("utf-8"))
def search(topic, operation, page=1):
params = {
"topic": topic,
"operation": operation,
"page": page,
"format": "json",
}
url = BASE + "?" + urllib.parse.urlencode(params)
return fetch(url)
payload = search("Sequence analysis", "Multiple sequence alignment", page=1)
print("本页条数:", len(payload.get("list", [])))
print("总记录数:", payload.get("count"))
print("总页数:", payload.get("count", 0) // 50 + 1)
for item in payload.get("list", []):
tool_id = item.get("biotoolsID")
if not tool_id:
continue
(OUT / f"{tool_id}.json").write_text(
json.dumps(item, ensure_ascii=False, indent=2), encoding="utf-8"
)
print("已落盘:", len(list(OUT.glob("*.json"))))
这段代码里有三个判断值得解释。
payload.get("count") 是总数，官方在搜索响应里给这个字段；分页总数用它除以每页条数估算，不要硬编码页数。
payload.get("list") 是当页记录数组，字段名沿用旧版的写法；新版接口如返回字段名不同，改这一处即可。
写入文件时按 biotoolsID 命名，这样重复运行不会产生重复文件，天然做了去重。
5.5 增量同步：按编辑时间切片
全量遍历既慢又容易错位，工程上更常用的是按编辑时间切片。
import datetime as dt
import json
import urllib.parse
import urllib.request
BASE = "https://bio.tools/api/tool"
def window(start, end, page=1):
params = {
"sort": "lastUpdate",
"ord": "desc",
"page": page,
"format": "json",
}
url = BASE + "?" + urllib.parse.urlencode(params)
req = urllib.request.Request(url, headers={"Accept": "application/json"})
with urllib.request.urlopen(req, timeout=60) as resp:
data = json.loads(resp.read().decode("utf-8"))
keep = []
for item in data.get("list", []):
stamp = (item.get("lastUpdate") or "")[:10]
if start <= stamp <= end:
keep.append(item)
return keep
today = dt.date(2026, 10, 26)
week_ago = today - dt.timedelta(days=7)
rows = window(week_ago.isoformat(), today.isoformat())
print("本周编辑过的记录:", len(rows))
for row in rows[:5]:
print(row.get("biotoolsID"), row.get("lastUpdate"))
按更新时间倒序取，一旦遇到早于时间窗口的记录就停，这是把「翻完所有页」压成「只翻落在窗口内的页」的标准做法。注意 lastUpdate 这个字段名同样以实际返回为准。
5.6 用 EDAM 本体做本地词表对齐
登记册的检索依赖 EDAM 概念的标识。要在本地把中文术语映射到 EDAM 概念，得先把本体下载下来。
#-- EDAM 的稳定版与滚动版分开提供，做可复现的对齐要用稳定版
curl -sL -o EDAM_stable.owl https://edamontology.org/EDAM_stable.owl
curl -sL -o EDAM_stable.tsv https://edamontology.org/EDAM_1.25.tsv
ls -lh EDAM_stable.owl EDAM_stable.tsv
#-- 稳定版的版本号写在文件名里，本次下载到的是 1.25
head -3 EDAM_stable.tsv
awk -F'\t' 'NR>1{print $NF}' EDAM_stable.tsv | sort | uniq -c | sort -rn | head
TSV 版本比 OWL 更适合快速做术语表，因为每一行就是一个概念，列里带名称、标识、类型。用它建一张「概念标识 → 英文名 → 你的中文名」的三列表，是所有本地化工作的第一步。
5.7 与下游构建层的标识反查
登记册里的标识有没有被真正用起来，可以反过来查。Bioconda 的配方里如果引用了 bio.tools 标识，说明这个工具在构建层也被接住了。
#-- 拉取 Bioconda 配方索引，检查其中带 bio.tools 标识的比例
curl -sL -o bioconda.json https://api.anaconda.org/package/bioconda/bioconda-recipes
python3 -c "import json;d=json.load(open('bioconda.json'));print(d.get('name'),d.get('latest_version'))"
#-- 检索引了 bio.tools 的配方文本（需先拿到 recipes 归档）
grep -rl "identifiers.org/biotools" . 2>/dev/null | head -5
这一步的意义在于：记录里有、构建层里没有的工具，装它得自己解决依赖。这是选型时最容易被忽略的一环。
5.8 把本地缓存做成可复查的表
平台侧最终需要的不是一堆 JSON，而是一张能定期复查的表。下面这段把落盘的记录压成关键列，便于逐条核对。
import json
import pathlib
rows = []
for path in sorted(pathlib.Path("biotools_dump").glob("*.json")):
item = json.loads(path.read_text(encoding="utf-8"))
funcs = item.get("function") or []
ops = sorted({o.get("term") for fn in funcs for o in fn.get("operation", [])})
ins = sorted({f.get("term") for fn in funcs
for x in fn.get("input", []) for f in x.get("format", [])})
outs = sorted({f.get("term") for fn in funcs
for x in fn.get("output", []) for f in x.get("format", [])})
rows.append((
item.get("biotoolsID"),
(item.get("toolType") or ["未标注"])[0],
",".join(ops) or "未标注",
",".join(ins) or "缺格式",
",".join(outs) or "缺格式",
"有" if item.get("repository") else "无",
))
#-- 先按「是否缺格式标注」排序，缺的排前面，便于集中处理
rows.sort(key=lambda r: (r[3] != "缺格式", r[0]))
for r in rows[:15]:
print(" | ".join(str(x) for x in r))
print("共", len(rows), "条，其中缺输入格式", sum(1 for r in rows if r[3] == "缺格式"), "条")
这一段的最后一行是全部的重点：它把「缺格式标注的比例」变成你自己库里一个可复查的数，而不是依赖别人给的百分比。登记册的规模数字会随论文更新，你自己库里那个比例不会。
§6 与库内条目的关系
6.1 关系图谱
bio.tools 在本库里的位置比较特殊：它不是数据源，而是数据源的使用说明书存放处。库内几乎每一条生物信息学数据集，背后都有一串工具，而这一串工具的目录在这里。
| 库内条目 | 关系 | 怎么配合 |
|---|---|---|
| Gene Ontology | 同属本体层 | GO 描述基因功能，EDAM 描述软件功能，两者在注释体系里并列 |
| Reactome | 下游数据 | 通路分析常用工具在 bio.tools 有记录，可反查其输入输出格式 |
| BioModels | 侧翼 | 模型库存方程，登记册存解方程的软件 |
| ChEMBL | 下游数据 | 化学信息学工具的同名记录可直接查 |
| InterPro | 下游数据 | 结构域注释工具的入口 |
| KEGG | 下游数据 | 通路映射工具多在此登记 |
| PubTator Central | 上游输入 | 其文献标注服务是文献挖掘管线的近亲 |
| 本库内所有测序类数据集 | 使用关系 | 处理这些数据要用的工具，目录在 bio.tools |
最值得配的一对是 Gene Ontology 与 EDAM。两者都是本体，都被用于给资源打语义标签，区别在于标注对象：GO 标的是基因产物的功能，EDAM 标的是软件的主题、操作与数据。做跨库检索时，这两套概念常需要一起用。
6.2 检索路径
四条入口，各管一段。
| 入口 | 地址 | 适用 | 限制 |
|---|---|---|---|
| 主检索 | https://bio.tools/ |
关键词或概念起手 | 排序影响判断 |
| 概念浏览 | 网页内 EDAM 概念面板 | 按主题逐层下钻 | 需知道大致领域名 |
| 领域视图 | 记录组织成的主题集合 | 看某领域全貌 | 由社区创建，覆盖不全 |
| API | https://bio.tools/api/tool |
批量、程序化 | 前置脚本质询 |
| EDAM 本体 | https://edamontology.org/ |
对齐术语、理解概念层级 | 本体本身不含工具 |
§7 质量评估与局限性
7.0 阅读本节前的一个前置校正
在下任何判断之前，先拆掉一个最常见的误判：不能用评价数据集的标准来评价这个登记册。数据集的完整性问的是「样本有没有缺列、缺了多少」，登记册的完整性问的是「有没有这个工具、它的描述准不准」。前者可以用空值率量化，后者不能——一条只有名称和主页的记录，描述的是一个真实存在的工具；一条字段填满但主页已失效的记录，描述的可能是三年前就不存在的东西。字段齐不齐，与记录对不对，是两件事。
第二个校正关于「数量」的读法。三万条记录不等于三万种软件。同一工具的多条记录、同一软件的不同分发形态、被同一项目继承的旧名称，都会各自占一条。任何基于记录数的统计，都要先说明「数的是记录」。
第三个校正关于时间基准。本节引用的规模数字来自 2026 年发表的官方论文，其统计表注明取自官方统计端点；而那个端点在本文的核验条件下没能打开。所以本页给的是「论文写作时点的官方口径」，不是今天的实时快照。这两者之间的差，本页不猜。
7.1 五维评分
| 维度 | 评分 | 一句话理由 |
|---|---|---|
| 元数据完整度 | B+ | 六成记录有主题与功能标注，数据类型与格式标注意外偏低 |
| 描述准确性 | B | 有 schema 校验与人工复核，但复核本身有误杀与漏放 |
| 标识与溯源 | A- | 持久标识 + 文献 + 贡献者，溯源链完整 |
| 时效性 | C+ | 补录活跃，但存量记录的描述滞后没有系统性修复 |
| 可编程性 | B- | 接口齐全且文档化，但站点对脚本客户端设了门槛 |
7.2 三个最该知道的结构性局限
局限一：覆盖不均不是可以靠时间填平的偏差。 官方论文把「子领域覆盖不均、标注深度不一、互操作元数据缺口」列为社区型登记册的典型局限，并把它写进了自己的讨论部分。这意味着它不是某个季度的短板，而是模式的属性。做任何一个子领域的覆盖率调查，得到的都是「被收录的比例」，这个比例与领域的社区活跃度强相关，与工具的实际数量弱相关。
局限二：没有强制的版本与生命周期字段。 本文在核验中未能确认记录级别是否存在专门表达「已废弃」「已迁移」的状态字段；官方 API 打不开，schema 的完整字段表没有逐项核对。这种情况下，正确的做法是把「记录的状态」当成需要自己判断的事情，而不是当成一个可以直接读的字段。判断依据是 §4.2 那张表里的三个信号：链接可达性、仓库活跃度、文献时间。
局限三：机器生成的描述已经进入记录。 官方论文说自 2024 年 1 月起引入大模型做候选排序，模型同时为每个工具生成一两句描述。含义是：网页上某句读起来很顺的描述，可能是模型写的。要紧的判断，回到文献与仓库核实。
7.3 已知的、可枚举的偏差
| 偏差 | 表现 | 后果 | 缓解 |
|---|---|---|---|
| 收录选择偏差 | 热门领域与欧洲节点关注的领域收录密 | 冷门领域工具被低估 | 换用领域专门库交叉验证 |
| 贡献者活跃度偏差 | 开发者主动认领的记录更新快 | 无主记录长期停更 | 优先选有近期编辑的 |
| 标注深度偏差 | 大工具多人补，小工具无人补 | 检索结果偏向知名工具 | 按操作检索而非按名称 |
| 描述生成偏差 | 部分描述由模型生成后经人工过目 | 表述流畅但细节可能不实 | 关键字段回查文献 |
| 分类归属偏差 | 套件与库、网页应用与门户边界模糊 | 按类型计数不可靠 | 统计时说明归类口径 |
| 生命周期偏差 | 迁移与废弃没有统一的状态表达 | 记录数虚高，旧工具看似仍在 | 以链接与仓库活动为准 |
7.4 外部验证矩阵
| 验证方向 | 谁做的 | 结论 | 对本文的意义 |
|---|---|---|---|
| 规模与结构 | 官方 2026 年《核酸研究》论文 | 记录总数、贡献者数、四类标注数、工具类型分布 | 本文全部规模数字的一手出处 |
| 策展流程精度 | 同上（2024 年 2 月案例） | 159 个候选经人工复核压到 85 个，其中 4 个误杀 | 说明自动管线与人工复核都不完美 |
| 文献挖掘的降噪 | 同上（Pub2Tools） | 关键词层级与排除词组合把检索量降约九成六 | 说明候选池的质量起点 |
| 生态复用 | 同上（交叉引用统计） | Galaxy 502、Bioconda 1,784 等 | 说明描述层的实际渗透率 |
| 领域覆盖 | 2021 年蛋白组学专文 | 该子领域收录超千条记录 | 说明单领域可做到较密的覆盖 |
| 字段自洽性 | 同上（讨论段） | 许可与收费字段常不一致，许多免费许可未显式标为免费 | 字段填了不代表彼此一致 |
7.5 它为何能持续：描述层比构建层更容易被沿用
bio.tools 能活十余年，靠的不是数据量，也不是技术。三万条记录放在生物数据库生态里并不显眼，它的技术栈也不特殊：一个 Python 后端、一个前端单页应用、一个搜索引擎、一个把前端渲染成静态页的服务。这些都能被复制。
它靠的是三件互相支撑的事。
第一件是描述层的位置本身。构建层的服务会变——包管理器会换代、容器平台会换代、工作流引擎会换代，但它们都需要一个地方去查「这个工具是什么」。描述层的更换成本比构建层高得多，因为一旦下游开始引用标识，更换标识就等于让所有交叉链接失效。这种「被引用」形成的锁定，比任何技术优势都稳固。
第二件是贡献者的自我利益。开发者愿意花时间提交记录，因为记录能让自己的软件被检索到、被引用、被培训材料引用。这不是慈善，是可见性换来的回报。官方论文里那句「希望以此激励开发者参与」说的就是这个机制。
第三件是编辑劳动的低成本维护。相比于从零建立一套工具目录，先有社区存量、再用文献挖掘补漏、再用模型排序分流，是一条边际成本递减的路径。人工复核仍然不可省，但它只需处理被筛到跟前的那百来条，不必面对整个生态。
最容易被低估的是第一件。它解释了这套资源在「时效性」评分不高时仍被大量服务依赖的原因：下游要的是稳定标识与稳定字段，不是最新描述。 这个错位既是它能持续的原因，也是记录会过时的原因——同一机制，两面。
§8 生态位与历史
8.1 十余年，四个阶段
| 阶段 | 时间 | 关键事件 | 对使用者的影响 |
|---|---|---|---|
| 建立 | 2014 年前后 | 作为 ELIXIR 的核心服务上线，提出用本体描述软件 | 软件第一次有了可检索的结构化描述 |
| 定型 | 2019 | 《基因组生物学》发文系统介绍，确立跨欧洲协作模式 | 记录字段与分类体系趋于稳定 |
| 扩展 | 2020–2023 | 领域视图大量出现，与构建层、执行层的交叉引用增加 | 成为多个服务的元数据上游 |
| 半自动化 | 2024–2026 | 引入文献挖掘 + 模型排序 + 编辑复核的流水线，接口文档化 | 补录速度提升，同时引入生成式描述 |
官方自述它是面向生命科学软件发现与策展的网络服务，已运行十余年。十余年在软件生态里很长，同一时期倒掉的包管理器与工具目录不在少数。
8.2 名字与术语的由来
EDAM 全称是数据处理与管理的本体，名字本身就是定位说明：它描述的不是生物学事实，而是「对数据做了什么处理」。这个取向决定了它的四个分区：主题、操作、数据类型、格式。前三者对应「谁在什么领域做什么变换」，最后一者对应「数据写成什么样子」。
理解这一点很重要，因为很多人第一次看 EDAM 会把它当成生物学术语表。它不是。EDAM 里没有基因名、没有蛋白名、没有疾病名，有的只是「操作」「数据类型」「格式」这类过程性概念。工具描述之所以能跨领域比较，靠的正是这种「只描述过程不描述对象」的设计。
8.3 它和其他「工具目录」的区别
「工具目录」这个词覆盖了很多东西。期刊的工具专栏、实验室主页的软件列表、包管理器的索引、工作流平台的内置工具库，都算。bio.tools 与它们的差别在三点。
第一，它有本体标注。其他目录大多只有名称与一句话描述，无法做「按操作找替代」这类检索。
第二，它有持久标识与溯源链，期刊专栏的条目会随改版消失，登记册的标识不会。
第三，它是开放贡献的，任何人都能提交、认领、编辑，这带来广度，也带来一致性上的代价。
8.4 它在 AI 时代的两个新角色
第一个角色是工具调用的知识底座。当模型被要求「完成一个分析任务」时，它需要知道有哪些工具、各自吃什么格式。bio.tools 的结构化记录正好是这类知识的现成形态。官方论文也提到记录页嵌了 schema.org 的标记，便于搜索引擎与语言模型提供方做结构化抓取。
第二个角色是训练数据的出处标注对象。同一篇论文里提到「用某工具分析」，文献挖掘流程把它变成一条候选记录；反过来说，一条记录也能告诉你这个工具出现在哪些文献里。这种双向关系对做科学文献理解的任务是有用的。
但这两个角色都有一道共同的坎：记录描述的是工具，不是工具的用法。 模型知道某个工具能做比对，不等于知道该怎么调参。把登记册当成工具使用知识的来源，会得到一个「知道名字、不会使用」的系统。这一点在 §7.2 的第三局限里已经埋了伏笔。
§9 使用指引
9.1 三种角色的路径
| 角色 | 目标 | 最短路径 | 要避开的坑 |
|---|---|---|---|
| 复现者 | 追清一篇论文用了什么工具 | 记下工具名 → 检索 → 比主页与文献 → 去仓库锁版本 | 拿记录里的描述当方法描述 |
| 流程设计者 | 选工具、拼流水线 | 按操作 + 输入格式 + 类型三重筛 → 看格式标注是否齐全 | 拿只填了数据类型的记录做格式匹配 |
| 平台工程师 | 建内部软件目录 | API 增量同步 → 按更新时间切片 → 本地缓存 | 前端实时打外部 API；逐页全量遍历 |
三种角色的分界，与 §4.5 的案例里那四步大致对应：复现者走前两步，流程设计者走第二步，平台工程师走第四步之后的部分。
9.2 一条最短的可用流程
从零到「确认这个工具该怎么引用」，五步。下面这段可以整段跑，前提是网络环境允许执行脚本，且本机有 curl 与 Python。
#-- 1. 建工作目录
mkdir -p biotools_work && cd biotools_work
#-- 2. 先确认接口是否可达：能拿到 JSON 才继续
curl -s -o probe.json -w "%{http_code} %{content_type}\n" \
"https://bio.tools/api/tool/?q=alignment&format=json"
head -c 200 probe.json
#-- 3. 若上一步返回的是 HTML 而不是 JSON，说明撞上了脚本质询
grep -qi "javascript" probe.json && echo "被脚本质询拦下，改用浏览器或离线快照"
#-- 4. 下载 EDAM 稳定版词表，用于把概念名与标识对上
curl -sL -o EDAM_stable.owl https://edamontology.org/EDAM_stable.owl
curl -sL -o EDAM_1.25.tsv https://edamontology.org/EDAM_1.25.tsv
wc -l EDAM_1.25.tsv
#-- 5. 从词表里挑出你要的操作概念标识，供检索参数使用
grep -i "multiple sequence alignment" EDAM_1.25.tsv | head -3
import json
import pathlib
#-- 把第 2 步拿到的响应读进来，先确认它是不是 JSON
probe = pathlib.Path("probe.json").read_text(encoding="utf-8", errors="ignore")
if probe.lstrip().startswith("{"):
data = json.loads(probe)
print("总数:", data.get("count"))
first = data.get("list", [{}])[0]
print("第一条:", first.get("biotoolsID"), "|", first.get("name"))
print("工具类型:", first.get("toolType"))
print("主题:", [t.get("term") for t in first.get("topic", [])])
print("文献数:", len(first.get("publication", [])))
else:
print("响应不是 JSON，长度", len(probe), "，需改用其他通道")
这段流程的第三步是最容易被跳过的一步，也是最该先做的一步。取数脚本失败时，最难排查的是「到底是站点拒绝还是参数写错」；先跑一次探测，把这两件事分开，后面所有调试都会快。
9.3 引用方式
引用一条记录与引用整个登记册是两件事。
引用单条记录时，至少写清四样：biotoolsID、访问日期、你从记录里取用的字段、以及该工具实际的版本号（这个版本号必须来自软件自己的仓库，不能来自记录）。只写工具名不足以让别人复现你的选择，因为同名记录可能不止一条。
引用整个登记册时，通行的做法是引官方的方法学论文。2026 年《核酸研究》那篇是最新的平台介绍，其中说明了接口、策展流程与统计口径；2019 年《基因组生物学》那篇是首次系统介绍，常被用来说明这个资源的由来。两篇都在本页附录 C 里给出了 DOI。
许可方面要分清三层：登记册本体的访问与复用是免费的、公开的；EDAM 本体采用 CC BY-SA 4.0，这意味着你基于它做的衍生词表要沿用同一许可；单条工具的许可由该工具自己决定，记录里的许可字段只作参考，真要再分发软件得看软件仓库里的许可文件。
§10 AI 使用声明
| 项 | 内容 |
|---|---|
| 本篇性质 | 由千方医数集依据公开一手资料编纂的知识性说明，非软件推荐，也非医学建议 |
| 主要来源 | ELIXIR 与 bio.tools 官方论文（2026 年《核酸研究》开放全文）、EDAM 本体官网页面 |
| 数字来源 | 官方论文统计表（注明取自官方统计端点）与 EDAM 官网下载页 |
| 现场核验 | 2026-10-26 对 bio.tools 首页与 /api/tool 路径做了 HTTP 探测，均返回脚本质询页 |
| 未核验 | 记录级字段的完整清单；是否存在表达废弃或迁移的状态字段；实时总数 |
| 未覆盖 | 网页界面的检索语法细节；领域视图的完整清单；单条记录的字段实值 |
| 生成式内容 | 官方已确认部分记录描述由大模型生成后经编辑审核，引用描述前须回查文献 |
| 更新预期 | 规模数字随官方论文更新，引用时请注明所依据的年份与统计端点 |
常见误读（避坑清单）
| 常见说法 | 实际情况 | 证据 |
|---|---|---|
| 「bio.tools 是一个数据集」 | 它是软件登记册，记录里没有任何观测数据 | 官方定位为软件与数据资源的元数据登记 |
| 「登记册里的记录数就是软件数」 | 同一工具可能多条记录，同一记录可对应多个分发形态 | 官方论文指出社区贡献是唯一来源 |
| 「记录里的更新日期就是软件更新时间」 | 那是元数据被编辑的时间 | 记录字段语义 |
| 「搜到第一条就直接用」 | 默认排序参考匹配度与文献计量，与可靠性无关 | 官方论文列出的排序选项 |
| 「没有下载链接说明工具不可用」 | 下载字段只覆盖不到两成，多数工具通过包管理器分发 | 官方统计的下载标注计数 |
| 「标注齐全就代表描述准确」 | 有字段填满但主页已失效的记录 | 官方论文承认时效性问题 |
| 「被删除的记录就不存在了」 | 标识符保留，历史保留 | 官方论文对删除行为的说明 |
| 「记录里的描述一定是人写的」 | 2024 年起部分描述由大模型生成后经编辑审核 | 官方论文的策展流程说明 |
| 「可以拿它做某领域工具总量统计」 | 统计到的是被收录数，不是存在数 | 官方论文自述覆盖不均 |
| 「API 能稳定供脚本批量拉取」 | 站点前置脚本质询，纯脚本客户端被拦 | 2026-10-26 现场探测 |
FAQ
问：bio.tools 是数据集吗？
答：不是。它保存的是软件的描述信息，不是测量数据。每条记录告诉你某个工具做什么操作、吃什么格式、吐什么格式、主页在哪、引用哪篇论文，但不含任何样本、序列或影像。
问：同一个工具在 bio.tools 里出现两条记录怎么办？
答：先比较两条记录的采信时间与标注完整度，再看主页地址与论文 DOI 是否一致。如果一条是历史遗留、主页已失效，优先用另一条；如果两者其实是同一个工具的两个分支，按实际使用的那个分支取。
问：bio.tools 能直接告诉我某个工具的最新版本吗？
答：不能作为依据。登记册里没有强制的版本字段，记录里的更新时间指的是元数据被编辑的时间。要知道实际版本，得回到该工具的主页、代码仓库或包管理器。
问：为什么我用 curl 请求 API 拿到的是网页？
答：站点前置了 JavaScript 质询，纯脚本客户端会被拦下并返回一段需要执行脚本才能通过的页面。浏览器访问正常，脚本访问需要能执行 JavaScript 的客户端，或改用离线快照。
问：EDAM 的四类标注分别管什么？
答：主题管研究领域，操作管数据变换，数据类型管处理什么信息，格式管写成什么文件。四类合起来，才能判断两个工具能否首尾相接。
问：它和 Bioconda 是什么关系？
答：两个层次。bio.tools 描述软件是什么，Bioconda 负责把软件打包成可安装的版本。Bioconda 的配方里会引用 bio.tools 标识，实现交叉链接；但引用是自愿的，覆盖并不完全。
问：为什么很多记录缺格式标注？
答：格式标注在 EDAM 里是独立概念，填起来比数据类型更费力，且要填两处（输入与输出）。官方统计里数据类型与格式标注都在一万一出头，明显低于主题与功能。
问：它的描述是英文的，有中文版吗？
答：没有。EDAM 概念与记录描述均为英文。要建中文界面，需自建术语映射层，把 EDAM 概念标识对应到中文名。
问：能用它判断一个软件是否还在维护吗？
答：只能间接判断。记录里有代码仓库链接，看仓库的最后提交、议题状态与发版记录，比看记录编辑时间可靠得多。
问：它在什么时候会给出错误答案？
答：三种情形最典型：检索结果的第一条不是最好的那条；记录描述滞后于软件现状；某个子领域根本没被收录。三种情形都不报错，只是让你得到不完整的图景。
问：为什么官方要做文献挖掘和大模型打分？
答：因为纯靠人工提交追不上软件增长的速度。文献挖掘负责从论文里找出新工具，模型负责给候选排优先级，编辑只处理排在前面的那百来条。这套分工把人力用在最值钱的一步。
问：我可以把它的数据做成自己的产品吗？
答：登记册本体可自由访问与复用；EDAM 本体为 CC BY-SA 4.0，基于它做的衍生要沿用同一许可；单条工具的许可是另一回事，要单独看。
术语表
| 术语 | 中文 | 一句话解释 |
|---|---|---|
| bio.tools | 生命科学软件登记册 | 收录软件与数据资源描述的服务 |
| ELIXIR | 欧洲生命科学基础设施 | 运营 bio.tools 的跨国组织 |
| EDAM | 数据处理与管理本体 | 描述软件功能的受控概念体系 |
| biotoolsSchema | 工具记录模式 | 约束记录字段与取值的技术规范 |
| Topic | 主题 | EDAM 的第一分区，描述研究领域 |
| Operation | 操作 | EDAM 的第二分区，描述数据变换 |
| Data | 数据类型 | EDAM 的第三分区，描述处理什么信息 |
| Format | 格式 | EDAM 的第四分区，描述文件写法 |
| biotoolsID | 工具标识 | 记录的持久主键，删除后不复用 |
| toolType | 工具类型 | 命令行、网页应用、库等分类 |
| function | 功能 | 输入→操作→输出的组合描述 |
| collection | 集合 | 一组工具的标签化归集 |
| domain | 领域 | 带额外元数据的专题集合 |
| curation | 策展 | 人工审核并补全记录的过程 |
| Pub2Tools | 文献转工具管线 | 从论文批量找出候选工具的流程 |
| Europe PMC | 欧洲文献数据库 | 文献挖掘的文献来源 |
| ELIXIR RSEc | 研究软件生态 | 汇聚软件元数据与构建资源的网络 |
| OpenEBench | 开放评价平台 | 给工具提供可用性与引用量指标 |
| TeSS | 培训平台 | 提供工具相关培训材料 |
| Bioconda | 生信包管理器频道 | 把工具打包成可安装版本 |
| BioContainers | 容器镜像库 | 提供可直接运行的容器 |
| WorkflowHub | 工作流登记册 | 存放可复现流程描述 |
| Galaxy | 工作流平台 | 用可视化方式串起工具 |
| ToolFinder | 工具查找器 | 澳大利亚机构做的检索前端 |
| FAIR | 可发现可访问可互操作可复用 | 数据与软件管理的通行原则 |
附录 A：核心数字核对表
| 项 | 值 | 来源 | 来源层级 |
|---|---|---|---|
| 记录总数 | 三万二千余 | 官方 2026 年论文统计表 | 论文全文 |
| 贡献者总数 | 一万四千余 | 同上 | 论文全文 |
| EDAM 标注总量 | 二十一万余 | 同上 | 论文全文 |
| 主题标注 | 十一万余 | 同上 | 论文全文 |
| 功能标注 | 七万七千余 | 同上 | 论文全文 |
| 数据类型标注 | 一万一千余 | 同上 | 论文全文 |
| 格式标注 | 一万一千余 | 同上 | 论文全文 |
| 命令行工具数 | 九千五百余 | 同上 | 论文全文 |
| 文献挖掘降噪比例 | 约九成六 | 官方论文方法段 | 论文全文 |
| 每月待审候选数 | 一百至两百 | 同上 | 论文全文 |
| 2024 年 2 月复核样本 | 159 → 85 | 同上 | 论文全文 |
| EDAM 稳定版号 | 1.25 | EDAM 官网下载页 | 官方页面 |
| EDAM 许可 | CC BY-SA 4.0 | EDAM 官网页脚 | 官方页面 |
| 官网首页探测（2026-10-26） | 返回脚本质询页 | 本次探测 | 现场核验 |
附录 B：数字的来源分层
第一级：官方页面。 包括 EDAM 官网的下载列表、稳定版号、许可声明与页面更新时间。这类信息当场可见，你现在就能重做，问题只在于它代表的时间点。
第二级：官方论文与开放全文。 包括记录总数、贡献者数、四类标注数、工具类型分布、策展流程的具体数字。这类数字有明确出处，并且论文注明了统计来源，可信度高，但仍是论文写作时点的快照。
第三级：未核实。 包括记录级字段的完整清单、是否存在的状态类字段、实时总数、单条记录的字段实值。这几项受限于本次核验的网络条件，本文一律不给具体值，只说明判断方法。
附录 C：完整参考文献
- Mendes AIS, Ménager H, Palmblad M, et al. bio.tools: an expanded web service for research software in the life sciences. Nucleic Acids Research, 2026. DOI: 10.1093/nar/gkag420
- Ison J, Ienasescu H, Chmura P, et al. The bio.tools registry of software tools and data resources for the life sciences. Genome Biology, 2019. DOI: 10.1186/s13059-019-1772-6
- Ienasescu H, Li K, Kafkas S, et al. biotoolsSchema: a formalized schema for bioinformatics software description. GigaScience, 2021. DOI: 10.1093/gigascience/giaa157
- Ison J, Kalas M, Jonassen I, et al. Community curation of bioinformatics software and data resources. Briefings in Bioinformatics, 2020. DOI: 10.1093/bib/bbz075
- Kern F, Aparicio JT, Baber J, et al. Proteomics Software in bio.tools: Coverage and Annotations. Journal of Proteome Research, 2021. DOI: 10.1021/acs.jproteome.0c00978
- EDAM 本体官网：
https://edamontology.org/（2026-10-26 访问） - bio.tools 服务入口：
https://bio.tools/（2026-10-26 访问）
附录 D：判断一条记录值不值得采信
下面这段是一件工具，不是完整流程，它把 §4 的三类偏离压成一次检查。输入是一条记录及其可访问性探测结果，输出是一个判断与理由。
import datetime as dt
def triage(record, homepage_alive, repo_last_commit, now=None):
"""返回 (采信度, 理由)。只判断记录是否可信，不判断软件是否好用。"""
now = now or dt.date(2026, 10, 26)
reasons = []
#-- 门槛一：主页可达。主页失效是迁移未同步最直接的信号
if not homepage_alive:
return "低", "主页不可达，先排除迁移或下线"
#-- 门槛二：功能字段是否足以参与格式匹配
funcs = record.get("function") or []
has_format = any(
f.get("format") for fn in funcs for f in (fn.get("input") or []) + (fn.get("output") or [])
)
if not funcs:
reasons.append("无功能字段，无法用于流程编排")
elif not has_format:
reasons.append("缺格式标注，只能做粗筛")
#-- 门槛三：仓库活跃度。用最近提交判断软件是否还在维护
if repo_last_commit:
gap = (now - repo_last_commit).days
if gap > 1825:
reasons.append(f"仓库最近提交在 {gap // 365} 年前")
else:
reasons.append("无仓库链接，无法判断维护状态")
#-- 门槛四：描述可能有生成成分，文献列表是否只有首发论文
pubs = record.get("publication") or []
if len(pubs) <= 1:
reasons.append("仅一条文献，注意后续版本可能另有论文")
if len(reasons) >= 3:
return "低", "; ".join(reasons)
if reasons:
return "中", "; ".join(reasons)
return "高", "主页可达、功能完整、仓库近五年有提交"
now = dt.date(2026, 10, 26)
sample = {
"biotoolsID": "example_aligner",
"function": [{"operation": [{"term": "Sequence alignment"}],
"input": [{"data": {"term": "Sequence"}, "format": [{"term": "FASTA"}]}],
"output": [{"data": {"term": "Sequence alignment"}, "format": [{"term": "SAM"}]}]}],
"publication": [{"doi": "10.0000/example.2021.001"}],
}
print(triage(sample, homepage_alive=True, repo_last_commit=dt.date(2025, 6, 1), now=now))
print(triage(sample, homepage_alive=False, repo_last_commit=None, now=now))
这段程序的第四个判断（文献条数）容易被忽略。它不是说文献少就一定不好，而是在提醒：只列了首发论文的记录，描述的往往是那个软件最早的形态，后续的分支与重写未必在这条记录里体现。
附录 E：如果只记五件事
第一，它是登记册，不是数据集。 它告诉你工具是谁、做什么、吃什么吐什么，不给你任何测量数据。这个定位错一次，后面所有期待都会连带错。
第二，记录上的时间是编辑时间，不是版本时间。 想知道软件今天是什么状态，只能去它的仓库看提交与发版。这是全文最该记住的一条。
第三，三类偏离要主动查。 重复条目、迁移未同步、描述滞后。识别方法都很朴素：比对主页与文献做去重，逐个访问链接看可达性，比对记录时间与仓库活跃度。
第四，它的强项是「按操作找工具」，弱项是「按格式拼流程」。 数据类型与格式标注只覆盖约三分之一，这决定了自动化编排能做到哪一步。
第五，它一半在里面，一半在外面。 登记册只完成定位与初筛，版本、参数、依赖要回仓库。§4.5 的案例四步里，第三步在仓库，第四步回到登记册，缺一步都不算用完。
编辑说明
本页由千方医数集 AI 写作代理编纂。核验方式为：读取官方 2026 年《核酸研究》论文的开放全文与其统计表，访问 EDAM 本体官网下载页与说明页，对 bio.tools 的首页与 API 路径做 HTTP 探测。未对登记册做全量下载与逐条统计。
本页的规模数字来自官方论文统计表，该表注明取自官方统计端点。本次核验中该端点未能以脚本方式打通：站点对脚本客户端返回的是需要执行 JavaScript 才能通过的质询页，首页与 API 路径均如此。因此记录级的字段清单与状态字段的有无，本页标为未核实，讨论停留在结构与机制层面。
关于「是否存在表达已迁移或已废弃的状态字段」，本页没有下结论。官方论文的局限段提到覆盖不均与互操作元数据缺口，未展开记录级的生命周期字段；本次核验也未能打开接口逐项核对。故 §4.2 只给识别方法，不给字段名。
正文中出现的工具名为官方论文举例所用，具体记录内容为示意，不构成对任何软件的评价或推荐。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- hgnc — 共享标签：基因组学与多组学 / 医疗NLP
- rnacentral — 共享标签：基因组学与多组学 / 医学问答与基准
- rfam — 共享标签：基因组学与多组学 / 医学问答与基准
- cpic — 共享标签：基因组学与多组学 / 医学问答与基准
- i2b2-n2c2-nlp — 共享标签：医学问答与基准 / 医疗NLP
- bioasq — 共享标签：医学问答与基准 / 医疗NLP
- medquad — 共享标签：医学问答与基准 / 医疗NLP
- cblue — 共享标签：医学问答与基准 / 医疗NLP
- pharos — 共享标签：基因组学与多组学 / 医疗NLP
- blurb — 共享标签：医学问答与基准 / 医疗NLP
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
