让 3 个 AI 编程代理搭建同一条 CUT&Tag 流程：谁更适合生物信息学

AI 编程代理不只是根据指令补全几行代码，而是能够规划文件结构、调用命令行工具并生成工作流的系统。本文关注的对象包括 Biomni、Claude Code 和 Codex，比较它们能否把一段生物信息学需求，转化为可执行、可检查、可复现的分析流程。

之所以选择 CUT&Tag，是因为这类测序分析同时涉及样本元数据、多个专业软件、质量控制和结果汇总。研究任务要求代理构建一条基于 Nextflow DSL2 的流程。Nextflow 是用于组织可复现计算任务的工作流框架，DSL2 则是其支持模块化流程定义的语法。流程覆盖双端测序质控、接头和低质量序列 trimming、比对、过滤、去重复、信号轨迹生成、单样本及分组 peak calling、对照感知的分组合并、注释、FRiP 计算、deepTools 可视化和最终 MultiQC 报告。

其中，FRiP 通常用于衡量落在峰区域内的有效片段比例；MultiQC 则负责把多个工具输出的质量指标汇总为报告。它们看似只是流程末端的统计和展示环节，却依赖前面各步骤对文件、样本分组和计数口径的正确传递。

同一任务如何比较

三套系统接收相同的、采用 CRAFT 风格组织的详细提示词，并与作者手工编写的参考流程进行对照。评估并不只看目录是否完整或文档是否易读，还关注流程是否实现了指定分析、报告中的读数是否与参考结果一致，以及分组处理、资源传递和质量控制输出是否符合预期。

根据摘要，三套系统都生成了外观合理的流程实现，但都没有完全满足任务要求。共同问题是：虽然执行了某种形式的分组级合并，却没有产出要求中的合并分组报告；单样本 MultiQC 报告中的指标也与参考报告存在差异。

初步结果与核验边界

摘要称，Codex 在主要比对后读数方面最接近参考流程，但总读数统计和报告结构仍不同；Claude Code 生成的最终报告覆盖内容较广，却混用了不同阶段的 mapping 统计，不能直接视为数值正确；Biomni 的文档表现被评价为较强，但读数一致性较差，部分问题还需要具备 Nextflow 经验的人员才能定位。

这些信息来自预印本提供的摘要，尚不能替代对具体版本、访问方式、套餐限制、提示词、重复实验次数以及相同数据、容器和参考基因组的独立复核。

我先承接前半部分，补充流程落地、验证方法、适用边界与发布前需核对的事实。

这项比较真正考验的，不是代理能否生成一套目录和若干脚本，而是能否把“分析意图”落实为可验证的流程契约。若要复现或进一步评估，建议先固定输入样本表、双端 FASTQ、参考基因组及索引、容器镜像和 Nextflow 配置，再分别运行三套实现。所有流程应使用相同资源限制，并保存版本、命令行参数、日志和输出文件清单；否则，读数差异可能来自环境或参数，而不一定来自代理能力。

验证时不要只检查流程是否成功结束。应逐步核对每个样本的输入配对关系、过滤和去重复后的文件、比对统计、峰文件、FRiP、BigWig 轨迹及 MultiQC 字段；随后确认分组规则、对照样本和合并后的峰及报告是否真正存在。对同一指标还要先统一分母和阶段，例如“总 reads”“比对 reads”与“过滤后 reads”不能混用。若出现空文件、通道匹配失败、容器内找不到索引或报告缺少样本，优先检查元数据列名、Nextflow channel 结构、路径挂载和资源参数传递。

从实际使用看，代理更适合快速搭建骨架、生成模块说明和补充常规命令；关键参数、分组策略、对照设计和最终统计仍应由熟悉 CUT&Tag 与 Nextflow 的人员审阅。对于生产任务，可将人工参考流程、nf-core 组件或已有机构模板作为基线，再让代理处理局部模块，而不是直接把整条流程投入分析。三套系统的具体版本、访问方式、套餐限制、提示词全文及重复运行次数，原摘要并未完整交代，发布前请核对。

原始来源： https://www.biorxiv.org/content/10.64898/2026.09.11.751004v1?rss=1