从源码到 GPU：三层系统如何协作

先确定程序从哪里开始

做 GPU DSL 时，很容易先把设备、tile 和 launch 参数列成一个配置，再用配置生成 Kernel。FlagLang 当前选择的入口是用户编写的源码：函数体表达域、数据流、存储关系和执行顺序，编译器再寻找能实现这些语义的目标路径。

@F.kernel 捕获具名程序；一个 Module 可以组织多个 Kernel。公开 compile 接收捕获后的 Kernel 或 Schedule。工具链目录和产物目录是编译环境选项，不是另一套算子语义。Agent 提出的候选也必须通过同一条源码入口。

三者的职责

FlagLib 是代数基础，不是另一个算子库。FlagLang 将 Axis、IndexSpace、Layout、DomainMap 和 Schedule 组织为可验证的程序；FlagKernel 则检验这些接口能否表达 GEMM、softmax 和 attention 等真实计算。这里的图表示职责与调用关系，不是说全部数据沿三个盒子依次执行。

用户表达关系，编译器选择实现

在 GEMM 中，作者声明行、列、归约轴，建立 A、B、C 的域，表达 contraction 和结果转换。目标实现涉及哪些物理 view、传输、存储生命周期和具体 Atom，由解析与降级路径继续处理。

因此，用户给出一个计算需求，与后端支持它，是两件事。语言能够捕获某种表达，不保证每个目标都有实现。解析失败应暴露缺失条件，而不是悄悄换成另一个算法或外部 Kernel。

为什么还要一套独立算子库

编译器内部测试可以直接构造 IR，但那不能证明用户 API 好用。FlagKernel 的算子源码只使用公开的 flaglang 与 flaglang.lib 接口；设备测试与运行 harness 才能调用编译器内部设施。

这条边界把“内部可以拼出来”与“作者可以写出来”分开。增加算子时暴露出的表达缺口，应该回到语言和编译器修复，而不是在算子源码里绕过前门。

目前该如何理解成熟度

本地目录中同时存在研究预览文档与较新的开发接口。预览面向限定的 H20 环境和固定示例；开发源码中的新能力并不自动进入冻结安装包。本文描述职责与当前源码，不把文档中的历史设备记录当作本轮重新验证，也不宣称通用多后端完备性。