# 从研究问题到运行中的工作流：AI Agent 如何让科学家告别"翻译"苦力活
> 一个遗传学家想比较欧洲和非洲人群在 HLA 区域的突变模式。听起来简单？但要把这句话翻译成一个能在 Kubernetes 集群上跑的、包含 118 个并行任务的有向无环图（DAG），他需要查基因坐标、写数据提取命令、配并行参数、部署容器——大约 30-50 分钟，还需要两种不同的专业知识。
这篇来自 AGH University of Krakow 的论文提出了一个优雅的解决方案：让 AI Agent 来做这个"翻译官"，但不是让 LLM 直接生成工作流，而是用一种精巧的三层架构，把 LLM 的"不确定性"关在笼子里。
## 科学家的隐形负担
科学工作流管理系统（如 Pegasus、Nextflow、Snakemake、Galaxy）已经非常成熟了。给定一个工作流规范——通常是一个 DAG——它们能自动处理任务调度、容错、数据传输和资源管理。
但问题在于：**谁来写这个 DAG？**
答案是：科学家自己。一个研究问题如"比较欧洲和非洲人群在染色体 1-5 上的突变模式"需要被翻译成具体的计算步骤：
- "欧洲人群" → 1000 Genomes 代码 EUR
- "染色体 1-5" → 需要下载对应的 VCF 文件
- "突变模式" → 选择 variant calling 分析类型
- 集群有 48 个 vCPU → 并行度设为多少？
这个翻译过程需要**领域知识**（知道 EUR 是什么代码、HLA 区域的坐标是什么）和**基础设施知识**（知道怎么用 tabix 提取数据、怎么部署到 Kubernetes）。在大多数实验室里，这两种知识分属不同的人。
论文指出了三个后果：
1. **准入门槛高**：不懂基础设施的科学家用不了工作流系统
2. **容易出错**：搞混了人群代码，错误就会传播到结果中
3. **不可复现**：翻译逻辑是隐含的，每次都要重新"猜"
## 三层架构：把不确定性关在笼子里
论文的核心思想可以用一句话概括：**让 LLM 只做它擅长的事（理解自然语言），让确定性代码做它擅长的事（生成可复现的工作流）。**
具体来说，架构分为三层：
### 语义层（Semantic Layer）：LLM 的舞台
LLM 负责把自然语言翻译成一个**结构化意图**（ResearchIntent）——一个 JSON schema，包含人群代码、染色体、基因组区域、分析类型等字段。比如：
```json
{
"analysis_type": "population_comparison",
"populations": ["EUR", "AFR"],
"chromosomes": [6],
"regions": [{"name": "HLA", "chromosome": 6, "start": 28477797, "end": 33448354}],
"focus": "all_variants"
}
```
关键点：**LLM 只负责"理解"，不负责"执行"。** 它不需要知道集群有几个 CPU、数据有多大、怎么部署容器。
### 确定性层（Deterministic Layer）：代码的领地
给定一个 ResearchIntent，确定性代码生成器产出完全相同的 DAG。**同一个意图永远产出同一个工作流。** 这保证了可复现性。
### 知识层（Knowledge Layer）：领域专家的智慧
这是论文最巧妙的设计。领域专家（遗传学家、数据工程师）用 **Markdown 文件**编写"技能"（Skills），编码：
- **词汇映射**："European" → EUR，"British" → GBR
- **基因组坐标**："HLA region" → chr6:28477797-33448354
- **优化策略**：用 tabix 提取 HLA 区域只需 50MB，下载整条 6 号染色体需要 943MB
这些 Skills 不需要任何 ML 专业知识，就是普通的 Markdown 文档，可以版本控制、可以审计、可以由领域专家直接维护。
## 四个 Agent 的协作流水线
整个系统由四个 Agent 协作完成：
1. **Conductor（指挥家）**：用户入口，接收自然语言查询，路由到对应的 Workflow Composer，管理多轮对话，强制人工审批
2. **Workflow Composer（工作流作曲家）**：查询 Skills + LLM 提取意图，生成工作流计划
3. **Deployment Service（部署服务）**：创建 Kubernetes 命名空间，下载数据到持久存储，测量实际数据大小和可用 CPU
4. **Execution Sentinel（执行哨兵）**：监控运行中的工作流，检测异常
流水线分六个阶段：
1. **路由**：Conductor 分类查询领域
2. **工作流规划**：Composer 提取意图，生成计划
3. **用户验证**：科学家审批计划（可修改）
4. **基础设施准备**：部署服务准备环境
5. **延迟工作流生成**：用实际测量值（而非估计值）校准并行度，生成最终 DAG
6. **执行审批**：展示摘要，科学家批准后提交执行
**延迟生成**是一个特别精巧的设计：工作流 DAG 不是在规划阶段就生成的，而是等到基础设施准备好、测量了实际数据大小和 CPU 数量之后才生成。这样并行度参数就是基于真实数据而非估计值。
## 实验结果：数据说话
论文在 1000 Genomes 群体遗传学工作流上做了全面评估。
### 意图提取准确率
用 150 个自然语言查询（分 5 个难度等级）测试三个模型：
| 配置 | Claude Opus 4.6 | GPT-5.4 | GPT-4.1-mini |
|------|-----------------|---------|--------------|
| 无 Skills (S0) | 44.0% | 39.3% | 27.4% |
| 词汇 Skills (S1) | 80.0% | 78.7% | 70.7% |
| 策略 Skills (S2) | 57.3% | 48.7% | 40.0% |
| 全部 Skills (S3) | **83.3%** | **80.0%** | 62.0% |
Skills 把准确率从 44% 提升到 83%——将近翻倍。其中词汇映射表贡献最大（+36pp），因为 LLM 的训练数据里不一定有精确的 GRCh37 坐标。
### 数据传输节省
通过 Skills 中编码的 tabix 区域提取策略：
| 基因区域 | 完整 VCF | 实际下载 | 节省 |
|----------|---------|---------|------|
| HLA (chr6) | 13 GB | 1.57 GB | 88% |
| BRCA1 (chr17) | 1.3 GB | 23 MB | 98% |
| HBB (chr11) | 2.1 GB | 1.4 MB | 99.9% |
**总体节省 92% 的数据传输。** 对于小基因区域，节省超过 99.9%。
### 端到端性能
三个复杂度递增的查询在 3 节点集群（48 vCPU）上执行：
- LLM 开销：11-14 秒（占总时间不到 3%）
- LLM 成本：每次查询低于 $0.001
- 所有查询意图提取全部正确（5/5 字段）
- 零失败任务
对比手动操作：专家需要 30-50 分钟完成同样的工作，而且需要两种不同的专业知识。
## 我的思考
这篇论文最打动我的，是它对 LLM 能力的**清醒认知**。
现在很多论文和产品都在鼓吹"让 LLM 直接生成代码/工作流/一切"，但这篇论文的作者们选择了另一条路：**承认 LLM 的不确定性，然后用架构来约束它。**
他们的核心洞察是：LLM 擅长理解自然语言的语义，但不擅长生成精确的、可复现的输出。所以，与其让 LLM 直接生成工作流 DAG（同一个 prompt 可能产出不同的 DAG），不如让它只做"意图提取"——把自然语言翻译成一个结构化的中间表示。然后，用确定性代码从这个中间表示生成 DAG。**同一个意图永远产出同一个工作流。**
这让我想到软件工程中的一个经典原则：**关注点分离**（Separation of Concerns）。语义理解和确定性执行是两个不同的关注点，应该用不同的机制来处理。
Skills 的设计也很有启发性。它们本质上是**人类可读的知识编码**——领域专家用 Markdown 写的文档，既供 AI Agent 查询，也供人类审计。这比 RAG（检索增强生成）更可靠（确定性路由 vs. 非确定性相似度搜索），比 fine-tuning 更轻量（编辑一个 Markdown 表格 vs. 重新训练模型），比 few-shot prompting 更持久（版本控制的文档 vs. 每次都要重新注入的示例）。
当然，论文也有局限。评估只在 1000 Genomes 一个工作流上进行，推广到其他领域（如天文学、气候模拟）还需要验证。T4（参数不足的查询）和 T5（对抗性查询）的准确率仍然较低，说明系统在处理模糊或无效输入时还有改进空间。此外，Skills 的编写和维护本身也需要领域专家的持续投入。
但作为一个概念验证，这篇论文展示了 AI Agent 在科学计算中的一个务实方向：**不是取代科学家，而是消除科学家和计算基础设施之间的"翻译"负担。** 这才是 AI for Science 应该有的样子。
---
论文：[From Research Question to Scientific Workflow: Leveraging Agentic AI for Science Automation](https://arxiv.org/abs/2604.21910)
作者：Bartosz Balis, Michał Orzechowski, Piotr Kica, Michał Dygas, Michał Kuszewski
机构：AGH University of Krakow & Sano Centre for Computational Medicine
代码：[https://github.com/hyperflow-wms/1000genome-workflow](https://github.com/hyperflow-wms/1000genome-workflow)
