TIRx：编译器作为 Agent 的工具层

前两章分别回答了「流程怎么排」和「判断怎么可靠」。但两个问题都默认了一件事：Agent 手里有工具。编译器能不能被当成一个可反复调用的分析器？参考实现能不能变成搜索空间的一部分？基准能不能在另一台机器上跑，而 Agent 还留在原地？本章用 MLC 开源的 TIRx Harness 做对照——一个把编译器本身变成 Agent 工具层的完整开源例子。

MLC 在博客里把问题说得很具体：Agent 的 token 浪费，不是浪费在搜索上，而是浪费在围绕优化的不确定性上——代码会怎么降到硬件、时序相关的失败怎么诊断、并发活动把测量搅成什么样。四样东西缺一不可：可预期的底座、执行之外的分析工具、可复用的知识、受控的评测。这四样，正好就是 harness 的全部内容。

学习目标

分清 TIRx 编译器栈与 TIRx Harness 两件事。
说清负载契约、TIRx-lite、编译期分析、知识库、KCoral 基准服务各自解决什么问题。
用具体例子解释编译期分析能抓到哪些 benchmark 测不出来的问题。
正确解读 TIRx 与 KDA 官方的两组加速比，说明为什么不能并列。
为自己的 harness 列出一份工具层清单，并标出缺口。

两条路线，只差一个词

名字	是什么	主要面向
TIRx	基于 Apache TVM 的硬件原生 ML kernel DSL 与编译器栈：写 kernel 的语言与编译器	手工写 kernel 的人、生成 kernel 的 Agent，以及把多段 kernel 融成 megakernel 的系统
TIRx Harness	建在 TIRx 之上的 harness：编译器底座 + 工具 + 知识库 + 基准服务	让 Agent 写出正确且快的 GPU kernel 的那一层

TIRx 编译器栈于 2026-06-22 由 Apache TVM 社区发布，用 @T.jit / @T.prim_func 风格的 Python DSL 写 kernel，定位是「硬件原生」（编排、同步、角色划分、内存布局留在源码里）与「编译器可见」（执行范围、张量布局、tile 原语分派暴露给编译器）。它把 Triton 这样的高层 DSL 往下编译，位置低于 TileLang 这类系统。

Harness 是另一层。官方 README 对它的定义是「a compiler harness combining a minimal stable compiler foundation, a knowledge base, tools, and a benchmark server」——注意这四样是并列关系：编译器只是其中一件，知识库与基准服务同样是必需品，缺了任何一件，Agent 都只能凭感觉判断。

Harness 的工具层

TIRx Harness 的分层：负载契约定义对错，Agent 在 skills 引导下工作，工具层负责写 kernel、做编译期分析与查资料，KCoral 持有 GPU 统一计时打分——因此 Agent 可以留在本机。

负载契约：一份可注册的任务契约

workload contract（负载契约）定义正确性与性能。在仓库里它是一份 YAML，放在 evolution/tasks/<name>.yaml，字段包括：任务名与 workload_dir、kernel 创作方式（TIRx-lite 还是交给 Agent 自由写）、sota_baseline.name（baseline 由谁担任）、spec（不可变的数学、张量、接口、正确性与计分契约），以及可选的 bench_timeout_s 与 banned_paths（哪些路径不许改）。运行开始时，它会被渲染进这次运行的 PROMPT.md 第 1 节。

这份结构值得逐条抄：

sota_baseline.name 把 baseline 写死在契约里，Agent 改不了——正好堵住第 5 章那个「拿自己第一版当 baseline」的坑。
banned_paths 就是「禁止事项」，而且是机械判定，不是靠 Agent 自觉。
spec 声明不可变，意味着「什么算对」在开工前就定死了。

仓库里的 kda_forward 契约是个好例子：12 个计分 case，得分是相对在线 FlashKDA baseline 的 12 个加速比的几何平均；另有 12 个只查正确性、不计分的探针，覆盖深 gate、边界与「输出投毒」。把「投毒探针」写进契约，等于把 reward hacking 的防线前置到任务定义里。

TIRx-lite 与编译期分析：编译器成为检查器

TIRx-lite 是建在 TIRx 中间表示之上的 DSL，负责 kernel 创作。它是 README 列出的第一件工具，另两件是编译期分析与 KCoral。

编译期分析是最值得学的一层。README 列出的能力是三类检查——同步（synchronization）、内存竞争（memory races）、数值行为（numerical behavior）；博客补充了更多：不需要 GPU 的数值模拟，以及 NCU 与 IKET 的 profiling 接入。

这三件事恰好是 kernel 任务里 benchmark 最容易漏掉的：

同步问题通常不会立刻崩，而是表现为「偶尔慢一点」或「结果对但更慢」；
内存竞争是典型的假加速温床：不加同步，结果照样对，只是靠运气，benchmark 也照样过；
数值行为（是否溢出、精度损失多少）在编译期就能看到，不必等 benchmark 跑完才发现这一版不能要。

博客里有一个例子，恰好是本章论点的最强证据：同步分析抓出了一个潜伏的 mbarrier 生成 bug，而这个 bug 能通过 benchmark 测试。 也就是说，有一类错误在你们熟悉的验收流程里根本不会被发现——它不违反正确性，只是让结果偶尔出错。KDA 官方博客把升级后的验收称为 acceptance gauntlet，六道 gate 覆盖隐藏测试、极端输入、真实 trace 与 FP64 参考；如果其中一部分能前移到编译期，Agent 产出的无效候选会少得多。 把「跑完再看」换成「先查再跑」，是工具层最直接的收益。

知识库：保存具体实现，而不是 Agent 的摘要

知识库存放 kernel zoo（博客称超过 60 个 TIRx kernel）与 PTX 文档。关键在它存的是具体实现：通过验证的 kernel 与运行记录被当作可复用的产物保留下来，后面的运行可以直接在上面继续，而不是每次重新写一遍。

换成 KDA 的语言，这就是 KernelWiki 加上候选记录的组合。差别在「可检索」和「具体」两点：知识库不是一份越写越长的笔记，而是有入口、有结构、能被 Agent 在冷启动时直接命中的东西。

Harness 还内置了三个 skill：tirx-wiki（查知识库）、tirx-debug-kernel、tirx-profile-kernel——正好对应「查资料 → 调试 → 性能分析」这条链路。第 9 章 Skills 与经验沉淀会专门讲怎么把经验组织到能被调用的粒度。

KCoral：基准服务与远程执行是同一件事

最后一件是基准服务。README 说 KCoral 用于远程执行：「keep your agent on one machine and run GPU work on another」；博客说得更具体——KCoral 持有 GPU、集中调度请求，并返回测量结果与产物。

所以「基准服务」和「远程执行」不是两个功能：正因为计时发生在 KCoral 控制的机器上、用同一条路径，远程执行才是自然结果。这解释了一件容易想不通的事——为什么一个「让 Agent 写 kernel」的框架会自带一套基准服务？因为可比性要求所有候选走同一条计时路径；Humanize 论文记录过那个真实案例：KDA 里的 Claude 把自己写的第一版 kernel 当成 baseline，超过之后宣布完成，官方 baseline 根本没比。

和 KDA、Humanize 放在一起看

层	KDA	Humanize	TIRx Harness
流程与候选管理	draft → plan → 候选 → 记录	计划合同 + builder/reviewer 轮次	由 harness 与 skills 约定
判断的可靠性	Verifier 对照验收标准复核证据	写/判分离 + 跨厂商 reviewer + 机械 gate	负载契约 + 编译期分析
Agent 手里的工具	ncu-report、KernelWiki 两个 skill	多 CLI、hook 与脚本	TIRx-lite、编译期分析、知识库、KCoral

一句话：KDA 与 Humanize 主要在「流程与判断」这一层做文章，TIRx 主要在「工具层」这一层做文章。

但有一个细节值得注意，它说明这三者不是竞品而是可叠加：MLC 公开的那些运行，用的正是 Humanize 2 的 flame chase 流程，harness 文档也把 Claude Code、Codex 与 Humanize 列为三种可选的 agent 前端。换句话说，工具层选 TIRx、编排层用 Humanize，是官方都在跑的组合方式。第 10 章自建 harness 会讲怎么把这些零件装成一台自己能运转的机器。

公开结果怎么读

公开结果有两组，出自两个不同的实验，不要混着说。

第一组来自 MLC 自己的博客（2026-09-29），是几何平均加速比：KDA forward 2.94×、KDA backward 6.84×、MSA prefill 2.59×、MSA decode 3.99×、KDA decode 1.33×、MLA 1.71×、VSA 1.68×，区间是 1.33× 到 6.84×。它比较的基线是每个 workload 各自优化过的参考实现，用的是 GPU kernel 时间而不是端到端应用延迟；基线版本取自 2026-09-25 至 09-26 的一次「策展扫描」，仓库里每个任务的 sota_baseline.name 写明了具体是谁（KDA forward 对 FlashKDA，KDA backward 对 Flash Linear Attention，VSA 对 FlashInfer 的 BSA attention，等等）。硬件方面博客只写「NVIDIA Blackwell GPUs」，仓库契约里写的是 B200（sm_100）。

第二组来自 KDA 官方博客（2026-09-27）：官方在 B300 上以 FlashKDA 为 baseline，最终通过加固后验收的结果里，KDA + TIRx 是 2.96×、KDA + CAKE（PTX 版）2.94×、KDA + CAKE（CuTe 版）2.85×。

两组数字不能横向比较：baseline 定义、测量口径、硬件与 workload 家族都不一致。还有一个更隐蔽的坑：MLC 博客里的 2.94× 和 KDA 官方博客里的 2.94× 完全是两回事——前者是 KDA forward 相对 FlashKDA，后者是 CAKE 的 PTX 写法。看到「2.94×」时，先问它出自哪篇文章、跟谁比、测的是 kernel 时间还是端到端延迟。

还有一个位置值得注意：在 KDA 官方的评测里，TIRx 是被当作「一种可被 Agent 驾驭的 kernel 写法」来用的——KDA 团队让 Agent 生成 TIRx kernel，再与用 CAKE、CUDA C++ 等写法产出的候选放在一起比。这说明 TIRx 在那条路线里的位置是可被 Agent 驾驭的实现形式，而不是「替代整条流程的方案」。

给自己的 harness 列一份工具清单

这是本章最实用的产出。照着上面的工具层，问自己六个问题：

该有的能力	它挡住什么	没有它时的最小替代
可注册、可复用的负载契约	对错标准漂移（阈值被改松）	一份不可修改的 `task.md` + 一份 `acceptance.yaml`
baseline 由契约指定	拿 Agent 自己的第一版当基线	baseline 写死 commit 与命令，且在 Agent 的可写范围之外
受约束的 kernel 写法	语法级与结构级错误	固定模板 + 编译告警当作硬门禁
编译期分析	随机出现的竞争与同步问题	候选通过后至少跑一遍 `compute-sanitizer --tool racecheck`
知识库存具体产物	重复劳动、无效候选	可检索的 PR 档案 + 候选记录
统一计时路径	口径不一致造成的假加速	一个所有候选共用的 `bench.py`，输出 JSON

如果这六项里有四项答不上来，说明你的 harness 目前只是「让 Agent 写代码」，还不是「让 Agent 写对」。

版本、许可与成熟度

Harness 目前是 0.1.x 的早期原型（PyPI 上的 tirx-harness 为 0.1.2.post2，tirx-kernels 与 kcoral 同为 0.1.x）。博客自己提醒：基准结果可能「在几天的尺度上」就发生变化。所以这一章讲的数字都有保质期，以官方仓库与博客为准。

许可方面需要分开看：TIRx 本身随 Apache TVM 分发（Apache-2.0），tirx-kernels 标注为 Apache License 2.0；但 harness 仓库根目录没有 LICENSE 文件，PyPI 页面上也没有许可元数据——这一项以官方为准。TIRx 编译器栈发布时的 PyPI 包是 apache-tvm 0.25.0，如今已到 0.27.0.post1，harness 会锁定具体版本。

常见误区

把 TIRx 当成又一个「更快的 kernel 库」。 它是工具层，产出是流程与证据，不是一个可以直接调用的算子。
以为装了 harness 就不用自己写验收。 负载契约必须由你定义，harness 只负责执行它，不会替你判断什么算对。
把两组加速比并列成「TIRx 的成绩」。 2.94× 与 2.96× 出自两篇文章、两套 baseline、两份测量口径；两篇各自的 2.94× 也是两回事。
把 harness 当成 Humanize 的替代品。 MLC 公开的运行用的就是 Humanize 2 的 flame chase，两者是叠加关系。
忽略编译期分析。 竞争与同步错误在 benchmark 里常表现为「不稳定」，很容易被当成机器抖动放过——博客里那个通过了 benchmark 的 mbarrier bug 就是例子。
以为远程执行只是省事。 它真正的价值是把 Agent 的位置与 GPU 的位置解耦，而且必须和「统一计时路径」绑定才有意义。

本章自检

我能分清 TIRx 编译器栈与 TIRx Harness。
我能说出工具层各部分分别解决什么问题。
我能举出两类 benchmark 测不出来的问题，并说明编译期分析为什么能抓到。
我知道 2.94× 与 2.96× 分别出自哪篇文章，为什么不能并列。
我为自己的 harness 列出了工具清单，并标出了缺哪一项。

练习

L2基础40 分钟

为你的 harness 列一份工具层清单

目标：把 TIRx Harness 的工具层翻译成你自己任务的「缺什么」，并给每项缺口一个本周就能落地的最小替代。

任务：

选一个小 kernel 任务（softmax、LayerNorm 或向量加），写下你当前的 harness 已有的能力，逐项对照下表六个问题：负载契约、baseline 指定方式、受约束写法、编译期分析、知识库、统一计时。
对每个「没有」写出一个最小替代方案，例如「没有编译期分析 → 候选通过后至少跑一遍 compute-sanitizer --tool racecheck」。
挑出你认为最容易被忽略的一项，说明缺了它，Agent 最可能产出哪一类假加速。
写一份 workload contract 草稿：任务名、输入 shape 与 dtype、baseline（带 commit 与运行命令）、正确性判据与容差、性能判据（warmup、重复次数、取哪个统计量）、禁止事项、墙钟上限。

验收标准：六项能力各有一句结论（已有 / 部分 / 缺失）；每个缺口都有可执行的最小替代；你指出的那类假加速能被一条具体命令拦住；contract 里每一条都能对应到一条命令或一个可检查的文件。

无 GPU 替代：本题不需要 GPU。编译期分析一项可用 CPU 上的 ThreadSanitizer 或等价检查工具替代，性能判据改用耗时中位数即可。

提示

列清单时按「这项能力挡住了哪种错误」来想，而不是按「这项技术听起来多先进」。负载契约挡的是对错标准漂移；baseline 指定方式挡的是「拿自己第一版当基线」；受约束写法挡的是语法级与结构级错误；编译期分析挡的是随机出现的竞争与同步问题；知识库挡的是重复劳动；统一计时挡的是口径不一致的假加速。

写不出「禁止事项」这一栏，通常说明你还没想清楚哪些东西不能被 Agent 改动——先从测试文件、baseline 文件和阈值文件开始列。