从已知参考继续优化
ForgeKernel 的仓库工作流从现有 kernel 出发，先运行、计时和 profile，再让架构 agent 提炼优化里程碑。它要解决的是搜索反复碰同样硬件限制、以及只微调参数无法越过架构平台期的问题。源码可见、黑盒参考和无参考生成是不同入口，不能将它们当相同信息预算。
第一个里程碑 M0 决定 kernel 切分、tile、warp 分工、寄存器与共享内存预算及常驻数据。门槛通过后，后续步骤在该结构内调优；测量显示必须换结构才能推进时，再回到 M0。这样把昂贵架构选择与局部改动分开，而不是允许每轮随意重写全部方案。
内外循环怎样保存可靠进展
内循环由编码 agent 实现一个决策，GPU job 进行正确性检查、参考对照计时和 profile，失败候选被撤回。外循环在长期无改善、决策图耗尽或门槛卡住时重新定价优化方向，并运行探针修订计划。参考实现、里程碑与硬件知识库有不同职责：里程碑描述约束和决策，不直接携带参考实现正文；经过探针验证的通用机制才进入跨算子知识库。
确认更快的 kernel 可提升为下一代参考，复制任务语义、形状和输入形成自足下一轮。停止依据是同一 GPU job 确认比率的噪声范围，原文设置至少 1.5% 下限；停滞意味着本轮未找到可信改善，不是证明已经达到硬件极限。
阅读仓库结果时保持版本边界
冻结 README 描述 27 算子结果，却把 News 中论文链接指向 JustGoal。后者是只给目标的基线研究，不能用它的数字替代参考驱动工作流的实验证据。仓库的 RMSNorm 示例是把九次 PyTorch kernel 启动融合为一次，给出 B200 上特定运行结果；它也不能说明面对高度优化专家参考会有相同收益。
我的理解是，适用场景是已有可执行参考、明确输入形状和容差，并能承受数小时 GPU 与模型搜索成本的算子优化。知识库要求硬件探针，恰好提醒读者：语言解释不等于硬件事实。本文保留这一机制说明，性能结论则应跟对应论文版本、参考实现与同 job 测量绑定。
来源：原始工程文章