上一篇拆 Linxira Bio SDK 时立了个论点：它赌的是”用测试过的实现，不生成新脚本”。但那篇停在仓库结构和态度上，有个最直接的问题没回答：**我敲下 linxira-bio sequence stats tiny.fa --json 到屏幕上出现结果，中间到底发生了什么？**这篇就钻进去看数据怎么流。写这篇时我对照的是仓库 v1.0.1 的 README 与文档树，能力边界以正式分支 release 为准。

本系列共三篇：第一篇（概览与观点） · 第二篇（执行链路，即本篇）· 第三篇（约束机制）。

一、三条入口：CLI、worker，和还没发布的 SDK

拆 CLI 的时候我漏了一层。仓库里除了 linxira-bio 这个 CLI，还有一个 linxira-bio-worker：给它一个 JSON 任务文件，它照着跑。README 里的示例长这样——

1
cargo run -p linxira-bio-worker -- tests/fixtures/jobs/sequence-stats.json

这意味着调用同一个能力有三条路：人在终端敲命令；agent 按 skills/ 里的指令拼命令；程序直接投递任务文件。前两条是交互式的，第三条才是”不生成脚本”的完全体——任务文件是声明，不是代码，谁投的都一样跑，结果一样过同一套 schema 校验。很多工具链只做了第一条路，然后管这叫自动化。而 Bio SDK 把 Python SDK 压到”CLI 合约稳定后再发布”，恰恰是因为前两条路还没被证明稳：入口可以有三个，合约只能有一个。

二、一条命令的旅程：从参数到结果信封

以 sequence stats tiny.fa --json 为例，中间有四站：

  1. 参数进 CLI，解析成对某个能力的调用请求；
  2. capabilities/ 目录查路由——能力全部带版本号（这里是 sequence.stats.v1），机器可读的能力目录就是一张路由表：名字、版本、输入约束、输出形状都在上面；
  3. **engine/ 的 Rust 运行时执行计算（**文档说未来会有 benchmark 支撑的 C++ 内核），不碰你的 shell，不临时拼脚本；
  4. 按 schemas/ 里的 JSON Schema 输出统一信封，--json 拿到的就是它，export table 再把它变成 CSV/TSV/JSONL/XLSX。

想自检的时候有两个专门命令：doctor --json 报环境健康状态，capabilities --json 列出当前版本实际可用的能力和版本号。这两条是整个体系 transparency 的钥匙——你不需要读源码就知道”我现在有什么、每个能力到哪个版本”。顺带一提，能力覆盖比我上一篇列的还多一条：alignment short-read reference.fa reads.fastq aligned.bam --threads 4 --json，比对本身也是能力，不止 QC。

三、”确定性指标”到底是什么意思

README 反复用 deterministic 这个词形容它的指标计算。具体到使用者的体感是三件事：同样的输入文件，今天跑和下个月跑，每个数字一致；换一台机器跑，一致；谁（人还是 agent）发起的调用，一致。这三条正好对得上第一篇吐槽的三个痛点——README 上能跑、交给别人报错、重跑结果不一样。

值得强调的是边界：确定性说的是”指标计算”这一层，不承诺上游数据的生物学质量。fastq qc 会告诉你 reads 有多差，但不会把差 reads 变好。这层划分让”结果可复现”和”结论可复现”分开——前者是 SDK 的责任，后者永远是分析者的责任。

四、从结果 JSON 到表和图：GUI 不是预览器，是能力的画图端

上一篇的故事停在”结构化 JSON”，但分析不能止于表。linxira-bio-ui 这个无 WebView 的原生 Rust GUI 会按能力类型直接出图：FASTA、FASTQ、SAM、BED 交集、表达矩阵、VCF、PDB 摘要，各有一套对应的 capability-aware 图表。关键在于它画的是能力的计算结果，不是拿原始文件现场发挥——画图端和计算端共享同一套 schema，所以”算出来的”和”画出来的”不会打架。

结构这块还能把 PDB/mmCIF 渲染成骨架、球棍、空间填充三种样子，PNG 导出固定 1600×1000，而且是原子写入：写完就是完整一张图，不存在导出失败只留半张的情况。一个容易漏的边界：mmCIF 只是查看器的输入格式，不是分析能力，能力清单里没有它——GUI 能打开不等于 CLI 能算。DATA_FORMATS.md 里那张 read/inspect/analysis/export 四列矩阵就是干这个的：每种格式在”可读、可预览、可分析、可导出”四个维度上分别打勾，边界写死，不靠猜。

五、本地包络：先测，超了再迁移

上一篇提过执行模型：本地优先，实测的 CPU 时间、内存、GPU、数据库、存储五类资源超过”本地执行包络”才考虑迁移（本地 GPU → 机构调度器 → 经批准的云端）。这篇补上它的两翼：

  • 下界有例子：结构查看器把解压后的 PDB/mmCIF 限制在 128 MiB、10 万原子以内——这不是随便拍的数，是”本地渲染必须画得动”的物理边界，每个能力都该有这样一条线；
  • 上网有门：浏览器在线服务只是连接器，要过三道关——显式用户操作门、人工控制的认证、绝不存储或自动填充账号凭据。

这套设计的本质是把”要不要出本地”变成一个可审计的决定：理由必须是测量值，出口必须是用户点过头的那几扇门。

收束

跟着一条命令走完全程，最深的印象是”一条道”：三条入口汇到同一张能力路由表，执行完汇进同一个结果信封，再从信封分流到表、图、结构视图。入口的多样性是给使用者留的，输出的单一性是给生态留的——下游写一个解析器就能吃所有能力的输出，这才是”不生成脚本”能成立的技术前提。至于这条道凭什么不烂尾，就是第三篇要拆的约束机制了。