关键词：GPU 算子优化、Nsight Compute 性能剖析、AI 编码智能体、多后端自动调优、策略记忆机制

近期，一个关于“NPU 算子悖论”的讨论引起了关注：一位能在指令集难用、文档匮乏的国产 NPU 上写出媲美 NVIDIA GPU 性能的开发者，其技术能力理应比同等水平的 CUDA 开发者更强。然而现实是，这类开发者的薪酬往往低于互联网大厂的同行。由此推导出一个矛盾：他若转向互联网大厂开发算子，薪酬可能翻倍；若转向 NVIDIA 或平头哥 PPU，开发负担又能显著减轻。

这一“悖论”的背后，直指一个行业痛点：GPU/NPU 算子调优，长期以来被视为一项高度依赖手工、难以规模化复制的“手艺活”。

工程师们被困在枯燥的循环中：面对 Nsight Compute 中数十项晦涩的硬件性能计数器反复揣摩，手动推断性能瓶颈，小心翼翼地调整计算分块（tile shape）或内存访问模式，然后运行基准测试、查看报告，如此周而复始。最令人沮丧的是，好不容易在一个算子上积累的优化经验，几乎无法系统性地迁移到下一个算子上——每一次优化都近乎从零开始。

这也解释了为何国产 NPU 领域的资深开发者价值被低估：因为他们的生产力被手工作坊式的调试工具所束缚。

那么，如果存在一个系统，能够自动完成 “编译-验证-测速-剖析-提出假设-生成新版本-再验证” 的完整闭环，并且——它还能记住哪些策略有效、哪些是无效的尝试，情况将会如何？

GPU 算子自动化优化与验证的全流程框架。流程始于 Preflight 环境检查，涵盖 GPU、Torch 等配置核验，接着进行正确性验证与基准测试，未通过则标记拒绝。通过后开展分层 NCU 剖析，结合知识库生成优化方案，迭代产出算子版本，并记录策略结果、记忆优化经验。若未达上限则循环优化，直至触发上限后选出最优版本，最终输出结构化产物与报告，全程支持 CUDA, CUTLASS, Triton 等三类后端，实现从检测到优化的闭环自动化流程。

cuda-optimized-skill 正是这样一个项目。它并非又一个 GPU 内核模板库，而是一个面向 AI 编码智能体 的“优化技能包”，旨在将算子调优从依赖人类专家经验，升级为数据驱动、可复现、且具备记忆能力的工程系统。

接下来，我们将首先以最快的方式运行它，然后深入其代码，探究这套系统是如何被设计的。

本文目录

• 一、快速上手：从零开始运行首次优化
  • 1.1 环境准备
  • 1.2 最快体验：单条命令运行基准测试
  • 1.3 完整体验：单条命令启动多轮迭代优化
  • 1.4 仅检查环境，不运行基准测试
  • 1.5 在 AI 智能体中使用（推荐方式）
• 二、架构总览与设计理念
  • 2.1 项目定位：非库，乃“技能”
  • 2.2 三后端统一：一套流程，三种实现
• 三、基准测试引擎：统一的性能度量基础
  • 3.1 CUDA/CUTLASS 的签名解析与自动装配
  • 3.2 Triton 后端的约定式接口
  • 3.3 正确性验证：性能提升必须以正确为前提
• 四、迭代编排引擎：optimize_loop.py 的精密流水线
  • 4.1 每轮迭代的强制流程
  • 4.2 两阶段 NCU 剖析策略
  • 4.3 Preflight：启动前的安全检查
• 五、策略记忆机制：让 AI 避免重复错误
  • 5.1 问题：AI 的“遗忘”与“固执”
  • 5.2 指纹计算与分类判定
  • 5.3 两级记忆：当前运行与全局
• 六、最优版本选择：严格的资格筛选
• 七、实战效果：CUTLASS Softmax 优化案例
• 总结与技术价值

一、快速上手：从零开始运行首次优化

技术解析固然重要，但“先运行起来”是程序员的第一直觉。本章将以最简步骤，引导你在三种场景下快速体验该系统的核心能力。

1.1 环境准备

你需要一台配备 NVIDIA GPU 的机器，并确保以下工具就绪：

“`bash

基础依赖：Python 3.8+、PyTorch（CUDA 版本）、nvcc、ncu

python -c “import torch; print(torch.cuda.is_available())” # 应输出 True
nvcc –version # CUDA/CUTLASS 后端需要
ncu –version # 所有后端的性能剖析需要
“`

随后克隆项目：

bash
git clone https://github.com/KernelFlow-ops/cuda-optimized-skill.git
cd cuda-optimized-skill

1.2 最快体验：单条命令运行基准测试

如果你已有一个 CUDA kernel 文件（例如 my_kernel.cu，其中暴露了 extern "C" void solve(...) 接口），只需一行命令即可完成编译、运行与性能测量：

“`bash

基础示例：仅进行性能基准测试

python skills/optimized-skill/kernel-benchmark/scripts/benchmark.py my_kernel.cu
–M=4096 –N=4096
“`

脚本将自动检测 GPU 架构，使用 nvcc 将其编译为共享库，分配 CUDA 张量并执行基准测试。若你同时提供了一个 Python 参考实现，通过添加 --ref 参数即可同步验证计算正确性：

“`bash

正确性验证、基准测试与加速比对比

python skills/optimized-skill/kernel-benchmark/scripts/benchmark.py my_kernel.cu
–ref=my_ref.py –M=4096 –N=4096
“`

对于 Triton 用户，流程同样简洁：

bash
python skills/optimized-skill/kernel-benchmark/scripts/benchmark.py my_triton_kernel.py
--backend=triton --ref=my_ref.py --M=4096 --N=4096

提示：当未指定 --backend 参数时，脚本会根据文件后缀自动推断后端类型：.py 文件使用 Triton，.cu 文件使用 CUDA。

1.3 完整流程：单命令启动多轮迭代优化

核心能力在于多轮迭代优化。一条命令即可启动“基准测试 → NCU 性能剖析 → 策略记忆 → 生成下一版本”的完整闭环：

“`bash

CUDA 算子：执行 3 轮迭代优化

python skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py my_kernel.cu
–ref=my_ref.py –max-iterations=3 –M=4096 –N=4096

CUTLASS 算子：执行 3 轮迭代优化

python skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py my_cutlass.cu
–backend=cutlass –ref=my_ref.py –max-iterations=3 –M=4096 –N=4096

Triton 算子：执行 3 轮迭代优化

python skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py my_triton.py
–backend=triton –ref=my_ref.py –max-iterations=3 –M=4096 –N=4096
“`

其中，--max-iterations 是除算子文件外唯一必须提供的参数。执行完成后，系统会在算子文件同目录下生成 optimize_runs/run_YYYYMMDD_HHMMSS/ 目录，其中包含每一轮的基准测试结果、NCU 报告、优化建议以及最终摘要。

1.4 环境预检：仅验证环境配置

若需确认运行环境是否就绪，可通过添加 --preflight-only 参数执行一次完整的环境检查：

bash
python skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py my_kernel.cu
--max-iterations=1 --preflight-only

此操作将生成 preflight_check.md 和 preflight_check.json 报告，详细列出 GPU 型号、驱动版本、nvcc/ncu 路径、PyTorch CUDA 状态等关键信息，便于快速定位环境问题。

1.5 与 AI 智能体集成（推荐方式）

本项目设计初衷是作为 AI 编码智能体的“技能包”。若你使用的智能体（如 Claude Codex）支持技能调用，可通过以下方式便捷使用：

@optimized-skill 使用此技能对 my_kernel.cu 进行优化，迭代次数为 3 次。

智能体会自动调用 optimize_loop.py，解析每一轮的 NCU 报告，生成下一版算子代码，并在策略记忆的引导下持续迭代，直至达到指定轮数或性能收敛。

二、架构总览与设计理念

2.1 项目定位：非传统库，而是“优化技能”

传统 GPU 算子优化库（如 CUTLASS、Triton）主要提供算子实现本身。而 cuda-optimized-skill 提供的是优化过程的标准化编排能力——其核心假设是存在一个上游的 AI 编码智能体（当前面向 Claude Codex），由智能体负责“理解代码、提出优化方案、生成新版本算子”；本项目则负责“执行基准测试、获取 NCU 报告、判定策略有效性、记录经验教训”。

项目代码组织在 skills/optimized-skill/ 目录下，包含四个核心子模块：

skills/optimized-skill/
├── kernel-benchmark/ # 统一的基准测试入口
├── ncu-rep-analyze/ # NCU 性能剖析与诊断
├── operator-optimize-loop/ # 多轮迭代主编排引擎
└── reference/ # 按后端组织的优化知识库
├── cuda/
├── cutlass/
└── triton/

这四个模块的关系可概括为：知识库（reference）驱动优化建议，基准测试与 NCU 提供性能证据，优化循环（optimize-loop）完成闭环编排，策略记忆沉淀迭代经验。

2.2 三后端统一：一套流程，覆盖三种编程范式

项目同时支持三类主流的 GPU 编程后端：

• CUDA：原生 .cu 文件，需暴露 extern "C" void solve(...) 接口。
• CUTLASS：同样为 .cu 文件，但基于 NVIDIA CUTLASS 模板库实现。
• Triton：Python .py 文件，需暴露 setup() 与 run_kernel() 接口。

三者共享完全相同的评测、剖析与迭代流程，区别仅在于编译方式和优化策略的来源。这种设计的优势在于：AI 智能体无需关心底层后端的差异，只需按照统一协议提供算子文件，优化引擎便能自动完成后续所有工作。

三、基准测试引擎：统一的性能度量基座

3.1 CUDA/CUTLASS 的签名解析与自动装配

基准测试引擎（benchmark.py）是整个系统的“度量衡”。对于 CUDA/CUTLASS 后端，它实现了一项关键技术：自动解析 C 函数签名，并动态构造调用参数。

“`python

来源：skills/optimized-skill/kernel-benchmark/scripts/benchmark.py

def parse_solve_signature(cu_file: str):
“””从 extern “C” void solve(…) 中提取参数列表”””
with open(cu_file, “r”, encoding=”utf-8″) as f:
content = f.read()

pattern = r'externs+"C"s+voids+solves*(([sS]*?))s*{'
match = re.search(pattern, content)
if not match:
    raise ValueError(f'Cannot find 'extern "C" void solve(...)' in {cu_file}')

raw = match.group(1)
raw = re.sub(r"/*.*?*/", "", raw)      # 移除块注释
raw = re.sub(r"//[^n]*", "", raw)       # 移除行注释
raw = " ".join(raw.split())              # 标准化空白字符

params = []
for token in raw.split(","):
    # ... 逐参数匹配类型和名称
    is_const = "const" in token
    # 指针参数 → 自动分配 CUDA tensor
    # 整型参数 → 从命令行维度参数中读取

“`

该函数通过正则表达式从 .cu 源代码中提取 solve(...) 函数的参数签名，并根据参数类型自动分配 GPU 内存。具体规则如下：
* 指针参数（如 float*）会自动映射为 PyTorch CUDA 张量。其中，const 修饰的指针被视为输入，非 const 指针被视为输出。
* 整型参数（如 int M, int N）则从命令行参数（如 --M=4096 --N=4096）中获取。

这意味着，只要 CUDA kernel 遵循标准的 solve(...) 接口，基准测试引擎就能零配置地构建完整的测试环境，包括输入张量的分配与随机初始化，以及输出张量的捕获。

3.2 Triton 后端的约定式接口

对于 Triton 后端，基准测试引擎采用“约定大于配置”的策略。

“`python

来源：skills/optimized-skill/kernel-benchmark/scripts/benchmark.py

def _setup_triton(solution_file, dim_values, seed=None):
module = load_python_module(solution_file, “_triton_kernel_module”)
# 要求模块必须定义 setup() 和 run_kernel() 函数
prepared = module.setup(**setup_kwargs)
# setup() 返回 {“inputs”: {…}, “outputs”: [“out”]}
reference_inputs = prepared.get(“inputs”)
outputs = prepared.get(“outputs”)
“`

Triton 模块需要实现两个约定的函数：
* setup()：负责构造输入/输出张量，并声明输出张量的名称。
* run_kernel()：负责执行内核。

这种设计使得基准测试引擎无需了解 Triton 内核的任何实现细节，实现了与后端的解耦。

3.3 正确性验证：性能提升不能以牺牲正确性为代价

基准测试引擎内置了一套严格的正确性验证流程。当用户提供了参考实现时，引擎会执行以下步骤：
1. 使用相同的随机种子和输入数据，分别运行待测内核和参考实现。
2. 逐张量对比输出，计算最大误差、平均误差和相对误差。
3. 一旦验证失败，立即终止测试，不会产生任何性能数据。

“`python

来源：skills/optimized-skill/kernel-benchmark/scripts/benchmark.py

def _validate_outputs(kernel_tensors, ref_tensors, output_params, atol, rtol):
all_pass = True
for pname, ptype in output_params:
kt = kernel_tensors[pname].float()
rt = ref_tensors[pname].float()
match = torch.allclose(kt, rt, atol=atol, rtol=rtol)
if not match:
all_pass = False
# 报告第一个错误位置和具体数值差异
diff_mask = ~torch.isclose(kt, rt, atol=atol, rtol=rtol)
bad_idx = diff_mask.nonzero(as_tuple=True)[0]
“`

这一设计原则至关重要：性能优化的前提是保证正确性。在后续的迭代编排中，未能通过正确性验证的版本会被自动标记为 rejected，永远不会被选为最优版本。

四、迭代编排引擎：optimize_loop.py 的精密流水线

4.1 每轮迭代的强制流程

迭代编排引擎 optimize_loop.py 是整个系统的核心，其设计目标是确保每一轮迭代都可复现、有完整证据链、结果可追溯。

“`python

来源：skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py

def main() -> int:
# 1. 解析参数，推断后端
backend = infer_backend(solution_file, args.backend)

# 2. 创建/恢复 run 目录
run_dir = ensure_run_dir(solution_file, args.run_dir)

# 3. 初始化策略记忆
strategy_memory = ensure_strategy_memory(manifest, scope_key, global_memory_file)

# 4. Preflight 环境检查
preflight = collect_preflight(args, benchmark_script, solution_file, ref_file, backend)

# 5. 快照当前算子版本
snapshot_file = iter_dir / f"{solution_file.stem}_v{iteration}{solution_file.suffix}"
shutil.copy2(solution_file, snapshot_file)

# 6. 运行 benchmark
bench_res = run_command(bench_cmd, benchmark_stdout, benchmark_stderr)

# 7. 运行 targeted NCU（5 个关键 section）
# 8. 运行 full NCU（--set full）
# 9. 导入 NCU 报告为文本
# 10. 判定策略成败，更新记忆
# 11. 选出当前最优版本
# 12. 生成结构化 summary

“`

每一轮迭代都会生成一个独立的 iter_v{i}/ 目录，其中包含算子快照、基准测试结果 JSON、NCU 报告（targeted 和 full）、诊断文本、迭代摘要等完整产物。整个优化过程的最终输出目录 optimize_runs/run_YYYYMMDD_HHMMSS/ 正是由此逻辑生成的。

4.2 两阶段 NCU 剖析策略

NCU（Nsight Compute）剖析被设计为两阶段，以平衡效率与信息完备性。

第一阶段：Targeted 剖析
此阶段仅采集 5 个最关键的性能指标 section，以较低开销快速定位核心瓶颈。

“`python

来源：skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py

TARGETED_SECTIONS = [
“LaunchStats”,
“Occupancy”,
“SpeedOfLight”,
“MemoryWorkloadAnalysis”,
“SchedulerStats”,
]

def build_targeted_ncu_cmd(args, bench_cmd, out_prefix):
cmd = [args.ncu_bin, “–target-processes”, “all”,
“–profile-from-start”, “on”,
“–launch-skip”, str(args.launch_skip),
“–launch-count”, str(args.launch_count)]
for section in TARGETED_SECTIONS:
cmd.extend([“–section”, section])
cmd.extend([“-o”, str(out_prefix), “-f”])
cmd.extend(bench_cmd)
return cmd
“`

第二阶段：Full 剖析
此阶段使用 --set full 采集所有可用性能指标，提供完整的性能画像，用于深入分析。

python
def build_full_ncu_cmd(args, bench_cmd, out_prefix):
cmd = [args.ncu_bin, "--target-processes", "all",
"--profile-from-start", "on",
"--launch-skip", str(args.launch_skip),
"--launch-count", str(args.launch_count),
"--set", "full"]
# ...

采用两阶段设计的原因是 --set full 模式的开销巨大，其运行时间可能比 targeted 模式长 5 到 10 倍。而 targeted 模式选定的 5 个核心 section 已能覆盖 90% 以上的常见性能瓶颈诊断场景。

4.3 Preflight：启动前的安全网

五、策略记忆机制：避免重复探索与无效尝试

5.1 核心挑战：智能体的“遗忘”与“执念”

在没有策略记忆机制的情况下，AI智能体在多轮优化迭代中容易陷入两种低效模式：

1. 遗忘：在后续轮次中，重新提出已被验证为无效或失败的优化策略。
2. 执念：在已不适用的情况下，仍反复推荐某个曾经有效的特定优化方向。

策略记忆机制旨在系统性地解决这两个问题，通过记录历史策略及其结果，引导智能体进行更高效的探索。

5.2 策略指纹与结果判定

每一轮优化迭代的策略会从生成的提案文档中被提取并计算唯一指纹，以便于精确识别和匹配。

“`python
// 来源：skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py

def extract_strategy_tags(proposal_path: Path) -> list[str]:
“””从 optimization_proposal.md 中提取 ## Strategy tags 下的标签列表”””
content = proposal_path.read_text(encoding=”utf-8″)
# 解析 Markdown 中 “## Strategy tags” section 下的 “- tag” 行
# …

def build_strategy_fingerprint(backend: str, tags: list[str]) -> str:
canonical = {“backend”: backend, “tags”: tags}
raw = json.dumps(canonical, sort_keys=True, ensure_ascii=False)
return hashlib.sha1(raw.encode(“utf-8”)).hexdigest()[:16]
“`

每个已执行策略的结果会根据性能测试和正确性验证被自动分类为以下三类之一：

python
def classify_strategy_outcome(record, previous_record):
# benchmark 失败 → rejected
if record.get("benchmark_rc") != 0:
return ("rejected", "benchmark_failed")
# 正确性失败 → rejected
if bench.get("has_reference") and correctness.get("passed") is False:
return ("rejected", "correctness_failed")
# NCU 失败/缺失 → rejected
# 比上一轮更快 → positive
if current_median < previous_median:
return ("positive", "faster_than_previous")
# 否则 → negative
return ("negative", "slower_or_equal_to_previous")

5.3 两级记忆存储结构

策略记忆被设计为两级存储，以平衡当前任务的特异性与历史经验的复用性：

• 当前任务记忆：存储在 run_manifest.json 文件的 strategy_memory.current_run 字段中，记录本次优化循环中的所有策略尝试。
• 全局历史记忆：存储在独立的 global_strategy_memory.json 文件中，按作用域（scope key）进行隔离，形成可跨任务查询的策略知识库。

“`json
// 来源：skills/optimized-skill/operator-optimize-loop/strategy-memory/global_strategy_memory.json

{
“version”: 1,
“scopes”: {
“cutlass__cutlass_softmax__cutlass_softmax_ref__auto_arch__339090bb90fe”: {
“positive”: {
“693f19f37331ba8b”: {
“tags”: [“register_cached_exp”, “rowwise_softmax_shape_specialization”,
“thread_retile_128”, “vectorized_float4_io”],
“last_outcome”: “positive”,
“last_reason”: “faster_than_previous”,
“evidence”: {
“baseline_median_ms”: 0.14894,
“current_median_ms”: 0.10317
}
}
},
“negative”: {
“f5f0e39777db3029”: {
“tags”: [“keep_vectorized_single_pass”, “register_fragment_expansion”,
“retile_64_for_higher_ilp”],
“last_outcome”: “negative”,
“last_reason”: “slower_or_equal_to_previous”
}
}
}
}
}
“`

在下一轮迭代开始时，系统会自动合并两级记忆，生成约束：

“`python
// 来源：skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py

def merge_strategy_constraints(run_memory, global_scope):
blocked = set(run_memory[“negative”].keys()) | set(run_memory[“rejected”].keys())
preferred = set(run_memory[“positive”].keys())
# 再合并全局记忆
blocked.update(global_scope[“negative”].keys())
preferred.update(global_scope[“positive”].keys())
return {“blocked”: sorted(blocked), “preferred”: sorted(preferred)}
“`

blocked 列表中的策略指纹会被显式禁止再次使用，preferred 列表中的策略则会被优先融合。这相当于为 AI 智能体构建了一个“集体记忆”，使其不仅能记住当前任务的经验，还能跨任务复用。

六、最优版本选择：严格的资格赛

并非每个产生性能数据的版本都有资格参与“最优版本”的评选。评选规则非常严格：

“`python
// 来源：skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py

def choose_best_iteration(iterations):
candidates = []
for item in iterations:
# 条件 1：full NCU 报告必须存在
if ncu_required and not item.get(“full_report_exists”):
continue
# 条件 2：有 reference 时，正确性必须通过
if bench.get(“has_reference”) and not correctness.get(“passed”):
continue
# 条件 3：必须有有效的 median 和 average
if kernel.get(“median_ms”) is None or kernel.get(“average_ms”) is None:
continue
candidates.append(item)
# 排序：median 最低 → average 最低 → 更早的版本优先
return min(candidates, key=lambda item: (
item[“benchmark_result”][“kernel”][“median_ms”],
item[“benchmark_result”][“kernel”][“average_ms”],
item[“iteration”],
))
“`

此处的设计哲学如下：

1. full NCU 报告是硬性要求：没有完整的性能剖析证据，即使性能数据再出色也不予认可。
2. 正确性一票否决：速度更快但结果错误，直接淘汰。
3. 排序优先看 median 而非 average：因为中位数对性能噪声更具鲁棒性。

这与前文提到的“一条命令跑通”的简洁体验形成了鲜明对比：入口极简，标准极严。

七、实战效果：CUTLASS Softmax 优化案例

项目仓库中记录了一个真实的优化案例：使用 CUTLASS 后端对 softmax 算子进行多轮迭代优化，对标 PyTorch 原生 softmax 实现。实际执行命令非常精简：

bash
python skills/optimized-skill/operator-optimize-loop/scripts/optimize_loop.py
example/cutlass_softmax.cu
--backend=cutlass --ref=example/cutlass_softmax_ref.py
--max-iterations=3 --rows=4096 --cols=1024

从 global_strategy_memory.json 中可以观察到完整的优化轨迹。[[IMAGE_X]]

| 版本 | 策略标签 | 结果 | Kernel 中位耗时 (ms) |
| :— | :— | :— | :— |
| v0 | baseline | positive | 0.14894 |
| v1 | vectorized_float4_io, thread_retile_128, register_cached_exp | positive | 0.10317 |
| v2 | retile_64_for_higher_ilp, register_fragment_expansion | negative | 0.14587 |
| v3 | approximate_exp_path, revert_to_128_tile, arithmetic_only_tuning | positive | 0.10245 |

v2 尝试通过将 tile 大小缩小至 64 来提高指令级并行度（ILP），结果却导致了性能回退。该策略的指纹 f5f0e39777db3029 已被记录为 negative，后续将不再被采用。

v3 则基于历史记忆，回退到已被 v1 验证有效的 128 tile 策略，并同时尝试了近似 exp 路径。最终，kernel 中位耗时从 0.14894ms 降至 0.10245ms，延迟降低 31.2%，相对于 PyTorch 参考实现的加速比达到 2.04倍。

此案例清晰地展示了策略记忆机制的价值：v3 能够做出正确决策，正是因为它“记住”了 v1 的成功与 v2 的失败。

总结与技术价值

cuda-optimized-skill 项目的核心贡献，并非在于编写出某个极快的 CUDA kernel，而在于它重新定义了 GPU 算子优化的工作范式：

1. 从人类经验驱动到数据证据驱动：每一轮优化决策都基于基准测试数据和硬件性能计数器（如 NCU 报告）的具体数值，而非依赖工程师的直觉。
2. 从一次性手工调优到可复现的自动化闭环：通过一条命令即可启动包含预检、基准测试、性能分析、策略生成与下一版本迭代的完整流水线，每一步都产生结构化的中间产物。
3. 从“调完就忘”到有记忆的持续进化：策略记忆机制使得优化经验能够跨轮次、跨任务沉淀下来，让 AI 智能体在实践中不断学习，越用越“聪明”。
4. 从单一后端到多后端统一编排：CUDA、CUTLASS、Triton 等后端共享同一套评测与迭代框架，降低了在多后端之间切换和优化的认知负担。

在 AI 编码智能体快速发展的当下，本项目指出了一个值得关注的方向：AI 不仅能生成代码，还能像经验丰富的性能工程师一样，系统性地对代码进行优化——前提是为其配备正确的“工具”与“记忆”。

关注“鲸栖”小程序，掌握最新AI资讯