从研究问题到运行中的工作流：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，包含人群代码、染色体、基因组区域、分析类型等字段。比如：
{
"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
作者：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