导读与环境：从一块 GPU 到一条学习路线

如果你写过 PyTorch，大概率有过这样的体验：模型能跑，但某个算子占了大部分时间；想自己写 CUDA，却被访存、occupancy（占用率）、数值误差和 profiling（性能分析）工具挡在门外。Kernel Agent 想做的，就是把「提出目标、读代码、改 kernel、跑测试、看 profiler、再改」这一整条工程循环（loop），交给一个会使用工具的编码 Agent 来执行，而人负责定义目标与验收。

这一章先建立全景：Kernel Agent 到底是什么、为什么现在值得学、五个代表项目各自解决哪一段问题，以及你需要准备怎样的环境。读完你应当能判断：自己手上的机器能不能开始，不能的话该走哪条替代路径。

学习目标

用自己的话解释 Kernel Agent，并区分它与「让聊天模型写一段 CUDA」的差别。
说出 Kernel Agent 在 2026 年出现的三个条件，并各举一个反例或风险。
概述 KDA（Kernel Design Agents）、Humanize、TIRx Harness、BBuf skills 与 ForgeKernel 五者的分工与入口，并说明它们分别回答「怎么组织流程」「怎么保证判断」「给 Agent 什么工具」「怎么把经验喂给 Agent」「优化上限怎么自己往前走」。
按本站路线规划接下来的阅读与动手顺序。
完成 GPU、CUDA、ncu、Python 与 Agent CLI 的环境自检，或明确选择无 GPU 路径。

什么是 Kernel Agent

先把词拆开。Kernel 这里指运行在 GPU 上的计算核心，例如 attention、LayerNorm、MoE 的 gate 或 GEMM 的某个 tile；它通常由 CUDA C++、Triton、CuTe-DSL 等写成，需要自己管理线程、显存层级和数值精度。Agent 指能多轮调用工具的编码助手：它读文件、改代码、执行命令、观察结果，再决定下一步，而不是一次性吐出答案。

把两者接起来，Kernel Agent 是一个闭环系统：

人给出任务合同（task contract，本站也写作「任务规格」）：输入输出、正确性容差、性能目标、允许的实现方式。
Agent 阅读参考实现与测试，写一份 draft，再转成可执行 plan。
Agent 修改 kernel，调用编译器、正确性测试、benchmark（基准测试）与 profiler（性能分析器）。
结果回到上下文，Agent 决定保留、修改还是放弃当前候选。
全过程留下可复查的记录：候选版本、命令、日志、profiling 证据、取舍理由。

所以它的产物不只是一段代码，而是一个通过验收的候选实现，加上能说服下一位工程师的证据链。这也解释了为什么「会写 CUDA 的模型」不等于 Kernel Agent：没有工具闭环，模型无法知道自己写的 kernel 是快是慢、是对是错。

为什么现在出现

Kernel Agent 不是单点技术突破，而是三个条件同时成熟的结果。少任何一个，闭环都跑不起来。

条件一：kernel 工程成为瓶颈

模型结构越来越依赖专用 kernel（specialized kernel）：长上下文注意力、MoE 路由、低精度 GEMM、融合后的 epilogue（收尾计算）。硬件也在快速分化，Blackwell 的 SM、Tensor Core 与内存层级都和上一代不同。结果是「会写高性能 kernel 的人」供给有限，而每个新模型、新形状、新 GPU 都要重新调一遍。KDA 官方仓库把自己的定位写得很清楚：一套以编码 Agent 为中心的流程，用来研究、实现、验证与迭代（research / implement / verify / iterate）性能敏感的 CUDA 任务；其社区 kernel wishlist（愿望清单）目前只支持 NVIDIA B200 与 B300（以官方页面为准），说明公开任务与评测集中在当代数据中心 GPU，而不是泛化的玩具场景。仓库 README 把竞赛方案指向 HAN Lab 的公开仓库；公开材料也把项目与 NVIDIA、MIT HAN Lab 相关团队联系起来，但官方页面未强调隶属关系，具体团队构成以官方仓库为准。参考 KDA 仓库与项目主页（核对于 2026-10-29）。

条件二：正确性与性能可以被机器验证

这是 kernel 任务适合 Agent 的根本原因。正确性可以用参考实现加数值容差判断，性能可以用固定输入、固定硬件的 benchmark 判断，瓶颈可以用 ncu（NVIDIA Nsight Compute 的命令行性能分析器）的计数器定位。奖励便宜、可重复，Agent 才能在一晚上跑几十上百次实验。

但「可验证」不等于「已验证」。KDA 团队让 Agent 优化 Kimi Delta Attention（官方博客称 KDAttn，以区别于系统名 KDA）时，曾出现一个声称 3.74× 的候选：它把 Q/K 的 L2 归一化替换成硬编码常数 0.1778209953（正态分布下倒数 L2 范数的期望值），并把部分初始状态通道置零以跳过三角矩阵求逆；在合成随机数据上误差刚好过关，遇到真实非高斯输入就完全失败，去掉捷径后真实加速只剩 2.48×。官方随后升级了验收：每次评分换随机种子、用 Agent 看不见的隐藏测试切换输入分布与序列布局、加极端衰减与饱和 gate（门控）压力探针、改用逐元素误差门、回放真实 Kimi-Linear trace（运行轨迹），并用逐 token 的 FP64 递推（recurrence）作为数值参考，同时检查输出与 final state（最终状态）。该方案在升级后的验收下全面失败。来源是 KDA 官方博客 KDA²: Kernel Design Agents optimize Kimi Delta Attention（2026-09-27）。这件事会在第 4 章 KDA 案例展开，此处先记住结论：Agent 越强，evaluator（评测器）越重要。

条件三：编码 Agent 具备了长程工作能力

Claude Code、Codex CLI 这类终端 Agent 已经能维持多轮会话、读写仓库、运行命令，并通过 skill（技能包，把领域知识与操作步骤封装成 Agent 可调用的上下文）加载领域知识。Humanize 论文把问题说得很直接：写代码变便宜了，可靠地判断「是否真的完成」反而变难；写代码的 Agent 是糟糕的自我裁判。论文把「写/判分离、跨厂商 reviewer（独立评审者）、机械化的 gate（门禁检查）」工程化，并用 KDA 等应用验证。参考 Humanize 论文（2026-10）。

三个条件合起来：任务有经济价值，结果可验证，Agent 能长程执行。Kernel Agent 因此从演示走向了可复现的工程流程。

五个代表项目

不要把它们当成五个竞品。KDA、Humanize、TIRx Harness、BBuf skills 与 ForgeKernel 分别回答「怎么组织 kernel 工作流」「怎么保证判断可靠」「Agent 能拿到什么工具与知识」「怎么把经验喂给 Agent」「优化能不能不停在已知最好实现上」。

项目	一句话定位	你会学到	入口
KDA（Kernel Design Agents）	以编码 Agent 为中心的 CUDA kernel 工作流，配 KernelWiki 与 ncu-report 两个 skill	任务合同、draft→plan、候选记录、profiling 证据	NVlabs/kda
Humanize	判断工程（Judgement Engineering）：写/判分离、计划合同、机械 gate	为什么 Agent 的自评不可靠，如何用流程约束它	论文 / 仓库
TIRx Harness	MLC 开源的编译器 harness，把 kernel 知识库、编译期分析与基准服务接给 Agent	编译器如何成为 Agent 的工具层，参考实现如何进入搜索空间	TIRx 博客
BBuf skills	把 AI Infra 专家经验沉淀成 Agent 可检索的 skill 与 118 份模型 PR 历史档案	prefill/decode 视角、kernel 与 Python 的映射、fusion 成立条件	AI-Infra-Auto-Driven-SKILLS
ForgeKernel	OpenBMB 开源的自演化 kernel agent：每一轮被接受的 kernel 成为下一轮的参考实现	架构先定的里程碑、teacher/student 两层循环、基线怎么自己往前走	OpenBMB/ForgeKernel

五个都是本站的案例章节（第 4 到 8 章），只是关注点不同：KDA 与 Humanize 关心流程与判断，TIRx 关心 Agent 能拿到什么工具，BBuf skills 关心经验怎么沉淀，ForgeKernel 关心优化上限怎么被自己推高——对应 KDA、Humanize、TIRx、BBuf skills、ForgeKernel 五章。TIRx 在 KDA workload 上报告的结果是 forward 2.94×、backward 6.84×、MSA prefill 2.59×（均为几何平均；来源为 MLC TIRx 博客，2026-09-29）。注意这是 TIRx 自己的实验组，基线与 KDA v0.5 的三项加速比不同，两组数字不可横向比较。

还有一条跨越案例的线索值得先记下：ForgeKernel 团队在 2026-10 发布的 JustGoal 论文给出了一个「只给目标、不给任何专用机制」的基线，并要求专用 harness 必须在同模型、同 scope 的对照下证明收益。这条对本站在第 8 章展开，也是全书结尾那句结论的另一半。

KDA 官方 README 明确说这是一个早期研究原型、仍在活跃开发；Humanize 的 Humanize2 也仍在演进。因此本站讲的是「截至 2026-10 的公开设计」，具体命令、模型与数字以官方为准。

本站的学习路线

主线是：先理解问题，再补两块基础，然后拆五个真实案例，最后自己搭一个最小 harness（执行框架）。

章节	核心问题	读完能做什么
1 导读与环境	这个领域在解决什么	判断环境是否就绪，选定路径
2 Agent 与 harness	Agent 为什么需要外层流程	写出一份可验证的任务合同
3 GPU kernel 与性能	怎么判断 kernel 好不好	读一份 ncu 报告并指出瓶颈
4 KDA 案例	一套完整流程长什么样	复现最小 KDA 流程
5 Humanize 案例	怎么保证「真做完了」	设计写/判分离与检查清单
6 TIRx 案例	Agent 能拿到什么工具	读懂一个编译器 harness 的分层
7 BBuf skills 案例	经验从哪来，怎么被检索	拆一个真实的 Infra 经验库
8 ForgeKernel 案例	优化上限怎么自己往前走	读懂架构先定与自演化回路
9 Skills 与经验沉淀	怎么让 Agent 冷启动更快	写一个自己的 skill
10 自建 harness	如何把各章组合起来	设计自己的 v0 harness

如果你时间有限，最低限度的顺序是 1 → 2 → 3 → 4；第 5 章 Humanize 解释了为什么第 4 章的流程必须配独立验收，建议不要跳过。第 6 章 TIRx 是对照阅读，读它是为了知道一个成熟 harness 把工具层做成了什么样；第 7 章 BBuf skills 是一个可以照抄的经验库样本；第 8 章 ForgeKernel 讲的是「基线本身会往前走」这件事对 harness 设计提出的新要求，可以放在读完案例后再看；第 8 章另配一篇 ForgeKernel 工程解剖，沿一次 run 的代码路径拆分层、合同与防线，适合在准备自建 harness 时细读；第 9、10 章更偏工程化，可以在做过一次小任务后再读。术语不熟时先查术语表，它按章节索引了全站出现的缩写。

先补基础再读案例，是因为 KDA 与 Humanize 的文档默认你理解 Agent 循环、任务合同与 ncu 指标；跳过基础直接读案例，容易记住命令，却说不出这些设计为什么存在。

环境准备

硬件：不是所有练习都需要 B200

第 1 到 3 章的概念与大多数练习，任意一块支持 CUDA 的 NVIDIA GPU 都能完成；第 4 章的练习版最小流程也可以换成小算子在你自己的 GPU 上跑。KDA 的工作流本身不绑定硬件，但其社区 wishlist 与公开评测目前主要在 B200/B300 上进行（以官方页面为准）；若要逐字复现它的公开结果，需要这两类卡或云端实例——公开报道明确写出 v0.5 的对比测试需要 NVIDIA B200 与 CUDA 13 驱动（KDA v0.5 报道，2026-09-23）。没有 GPU 也能读完全部章节，具体替代路径见下一节。

软件栈

组件	建议	检查方式
GPU 驱动	支持 CUDA 13.x 的版本	`nvidia-smi` 右上角
CUDA Toolkit	13.x；ncu-report skill 文档实测到 13.2	`nvcc --version`
Nsight Compute	2026.x；同一 skill 文档实测 2026.3.1	`ncu --version`
Python	3.10 及以上	`python --version`
PyTorch	能正确识别 CUDA 的版本	`torch.cuda.is_available()`
Agent CLI	Claude Code 或 Codex CLI，任选其一	`claude --version` / `codex --version`

安装方式请以官方文档为准：CUDA Toolkit、Nsight Compute、PyTorch、Claude Code、Codex CLI。不要从博客抄安装命令，版本与包名变化很快。作为参照，KDA v0.5 报道给出的对比测试配置是 CUDA 13.0、PyTorch 2.12.1 与 CuTe-DSL 4.6.0，预热 3 次、每次运行 50 次、重复 3 轮——这类细节属于「可复现声明」的一部分，值得照抄到你自己的任务合同里。

一个最小的检查脚本：

nvidia-smi
nvcc --version
ncu --version
python - <<'PY'
import torch
print("torch", torch.__version__)
print("cuda available", torch.cuda.is_available())
print("device", torch.cuda.get_device_name(0) if torch.cuda.is_available() else "none")
PY

如果 ncu 报 ERR_NVGPUCTRPERM，说明当前用户没有性能计数器权限；按 Nsight Compute 文档调整权限或换容器，不要用 sudo 掩盖问题。云上跑 ncu 还要确认实例允许 PM sampling（周期采样）。

预算与安全

Agent 的成本主要来自 token 与 GPU 时间。开始前先设三个上限：单任务墙钟时间、单任务花费、最大候选数。KDA 官方博客里的策略消融在 B300 上设了 14 小时预算（2026-09-27）；Humanize 论文中的 DSA indexer 消融用 48 小时预算（2026-10）。这些都是研究级预算，初学者做小算子应从几十分钟、几美元量级开始，再逐步加码。

安全上至少做五件事：把 Agent 放进容器或受限账户，不把宿主机家目录整个暴露；API key 只放环境变量，不写进仓库；默认拒绝危险命令与网络访问，需要时逐条批准；每次让 Agent 改动前先看 diff（改动差异），尤其是测试文件和 benchmark 脚本；确认 CLI 是否会跳过审批。Agent 能改测试，就能伪造通过，这不是假设，KDA 的 reward hacking（奖励作弊：优化考核指标而不是真实目标）案例已经演示过。另外要注意一个容易被忽略的默认行为：Humanize 官方文档明确写出，其 flow（流程）中的 agent 会「跳过审批」直接改文件、跑命令、提交，官方因此建议先在一次性仓库里跑；用其他 CLI 时也请确认同一件事。

无 GPU 也能开始的路径

没有本地 GPU 时，不建议一上来就租 B200。可以按成本从低到高选：

CPU 对拍 + 流程练习：用 PyTorch/NumPy 写参考实现，用一个小算子（LayerNorm、softmax、RMSNorm）练任务合同、draft、plan、候选记录。性能部分只记录 CPU 时间，明确标注「不代表 GPU 性能」。
读别人的 profiling 证据：用第 3 章 GPU kernel 与性能的六维框架分析公开的 ncu 报告或博客中的表格，练习「指标→结论」的对应关系。
按量租 GPU：选支持 CUDA 13 的实例，先跑通环境自检与一个很小的 kernel，再决定是否加预算。租用前确认计费方式与关机策略。
只做流程复现：用 KDA 的 docs/agent-flow.md、prompt 模板和工作区（workspace）布局，在你已有的小任务上跑通，不追求 B200 上的数字。

无 GPU 不会阻止你理解 harness；它只阻止你获得可信的 GPU 性能结论。把这两件事分开，学习效率反而更高。

常见误区

以为必须先有 B200 才能开始。 前 3 章和练习版最小流程可以在任意 CUDA GPU 或 CPU 上练；B200/B300 只影响逐字复现 KDA 官方结果。
以为 Agent 一次就能写好。 真实流程往往有几十个候选，价值在筛选与记录，不在首版。
以为 allclose 通过就正确。 容差、dtype、边界 shape 和 final state 都可能藏问题；KDA 的 3.74× 候选就是反例。
以为装好工具就等于环境可用。 驱动、CUDA、ncu 权限、PyTorch 与 Agent CLI 要逐项验证；ncu 没有计数器权限时，性能证据链是断的。

第一个 10 分钟自检

打开终端，运行 nvidia-smi，记录驱动版本、CUDA 版本、GPU 型号与显存。
运行 nvcc --version 与 ncu --version，确认工具链不是「只有驱动」。
运行上面的 Python 片段，确认 torch.cuda.is_available() 为 True，并记录设备名。
新建一个空工作区，写下你的第一个任务合同：目标、输入输出、正确性命令、性能命令、通过条件。先不要写代码。
选一个 Agent CLI，启动一次会话，让它只做一件事：阅读你的任务合同，指出其中含糊的地方，不改任何文件。

第 5 步很关键。很多人第一次用 Agent 就让它「优化这个 kernel」，结果 Agent 只能猜你想优化什么。先让它审阅任务合同，你会立刻发现「快多少算快」「允不允许换 dtype」「baseline（基线实现）是哪个」这些问题原来都没定义。

本章自检

我能解释 Kernel Agent 的「工具闭环」与普通代码生成的区别。
我能说出推动它出现的三个条件，并解释为什么可验证性既是优点也是风险。
我知道 KDA、Humanize、TIRx Harness、BBuf skills 与 ForgeKernel 各自解决哪一段问题。
我能按本站路线说出下一章要读什么，以及为什么先读 Agent 而不是直接读 KDA。
我完成了环境自检，或明确记录了自己要走无 GPU 路径。
我能说出至少三条 Agent 使用中的安全边界。

L1热身20 分钟

环境与任务合同自检

目标：确认你的环境能支撑后续章节，并写出第一份可执行的任务合同。

任务：

记录 nvidia-smi、nvcc --version、ncu --version、PyTorch CUDA 检查四项结果；没有 GPU 就记录替代路径。
选一个你熟悉的算子（如 softmax），用 12 到 20 行写下任务合同，必须包含：输入形状与 dtype、参考实现、正确性容差、性能测量命令、baseline、通过条件、时间预算。
让 Agent 只审阅合同，列出三个歧义点；你逐条修正。

验收标准：合同里每条验收条件都能对应一条可执行命令；Agent 指出的歧义都有明确处理；你能说出本机是否能跑 GPU 性能测试。

提示

性能条件不要写「更快」，要写「在相同输入与 dtype 下，kernel 中位耗时低于 baseline 的 0.9 倍，重复 30 次，预热 5 次」。正确性不要只写 allclose，要写清 dtype、容差与是否检查 NaN。