1. 这个系列到底想干什么先讲清楚目标和边界RISC-V 和 AI 芯片这两个词单独拿出来都不新鲜。前者是开放指令集架构后者是当下算力需求最旺盛的硬件方向。但把这两个东西放在一起再加上“AI Agent”和“软件栈”就变成了一个非常具体、也非常有挑战的工程命题能不能让 AI Agent 参与到一颗 RISC-V AI 芯片的软件栈构建过程中从工具链适配、驱动开发、算子库移植到上层推理框架的对接形成一条可复现的路径。这个系列导读要解决的不是“AI 能不能写代码”这种泛泛而谈的问题而是一个更落地的场景当你手里有一颗 RISC-V 架构的 AI 加速芯片或者你正在基于某个 RISC-V 核做 AI 加速器的原型验证软件栈这一层的工作量往往被严重低估。编译器后端要适配自定义指令运行时要做内存管理和任务调度算子库要针对特定矩阵乘单元做手写优化推理框架要接上自定义后端。这些活儿传统上靠人一行一行啃周期长、门槛高、容易出错。AI Agent 在这里的角色不是替代芯片架构师而是承担那些重复性高、模式化强、但细节繁琐的软件栈构建任务。比如根据指令集手册自动生成汇编模板、根据硬件寄存器描述生成驱动骨架、根据算子数学定义生成候选实现并做自动调优、根据框架后端接口生成适配层代码。这个系列就是围绕这些具体环节展开把每一步的思路、工具选型、实操过程和踩坑经验拆开来讲。适合谁看如果你是对 RISC-V 和 AI 芯片感兴趣的学生或工程师想了解软件栈到底包含哪些层次这个系列能给你一张完整的地图。如果你已经在做相关开发想看看 AI Agent 能不能帮你省掉一些体力活这里有具体的操作路径和边界说明。如果你只是听说过 AI Agent 但不知道它在硬件软件栈这种硬核领域能干什么这个系列会用实际案例告诉你它能干什么、不能干什么、以及为什么。注意这个系列讨论的是 AI Agent 在软件栈构建中的辅助作用不涉及任何芯片设计本身的自动化。Agent 不负责 RTL 生成、不负责物理设计、不负责验证签核。它的战场在软件层。2. 为什么是 RISC-V 加 AI 芯片加 AI Agent 这个组合2.1 RISC-V 软件栈的现状与痛点RISC-V 的生态这几年进步很快但软件栈的成熟度和 ARM、x86 相比还有明显差距。这个差距不是靠一两个大厂就能填平的因为它涉及的面太广编译器、调试器、操作系统、驱动、中间件、应用框架每一层都需要针对 RISC-V 做适配和优化。具体到 AI 芯片场景问题更突出。AI 加速器通常有自己的指令扩展比如向量扩展、矩阵乘加指令、自定义的量化指令。这些扩展在 RISC-V 标准里可能还没有完全定型或者虽然有标准但各家实现有差异。编译器后端要支持这些指令需要写大量的 pattern matching 和指令选择逻辑。运行时要做异构内存管理因为 AI 芯片往往有独立的片上缓存和外部内存。算子库要针对特定硬件微架构做手写汇编或 intrinsic 优化这部分工作极其依赖经验。传统做法是招一批有编译器背景、有体系结构背景、有 AI 框架背景的工程师分头啃。但现实是同时具备这三方面经验的人很少培养周期很长。而且很多工作是“一次性”的适配完这颗芯片换一颗又要重来一遍。这就给 AI Agent 的介入留下了空间。2.2 AI Agent 在软件栈构建中的能力边界先说清楚 AI Agent 在这个场景里能做什么。基于当前的技术水平Agent 比较擅长的是代码生成与转换根据指令集手册、寄存器手册、算子数学定义生成汇编模板、驱动骨架、算子候选实现。模式识别与批量处理识别代码中的重复模式批量生成适配层代码比如为几十个算子生成统一的接口封装。自动调优根据性能计数器反馈自动调整算子实现中的参数比如循环展开因子、分块大小、寄存器分配策略。文档理解与提取从 PDF 手册、HTML 文档中提取指令编码、寄存器地址、时序约束等结构化信息。测试用例生成根据算子定义生成边界测试、随机测试、覆盖率测试用例。它不擅长的是微架构设计决策比如缓存层次怎么设计、流水线怎么排这些需要人类架构师的经验和直觉。跨层权衡比如为了某个算子性能是否要修改指令集定义这涉及硬件软件协同设计Agent 做不了这种决策。非确定性调试遇到时序相关、并发相关的 bugAgent 的排查能力有限。性能瓶颈的根因分析Agent 可以收集数据但根因定位往往需要人类对系统的整体理解。这个系列在讲每个环节时都会明确标出哪些部分 Agent 可以独立完成哪些部分需要人类介入哪些部分 Agent 只能做辅助。2.3 为什么现在做这件事是有意义的三个条件同时成熟了。第一RISC-V 的软件栈工具链已经足够开放LLVM、GCC、QEMU 都有 RISC-V 后端Agent 有东西可以操作。第二AI 芯片的算子库和推理框架接口逐渐标准化ONNX、TVM、MLIR 这些中间表示提供了统一的切入点。第三AI Agent 的代码生成能力在 2024 年到 2025 年有了质的提升尤其是对汇编、C 模板、Python 绑定这类代码的生成质量已经可以进入实用阶段。这三个条件缺一不可。没有开放的编译器基础设施Agent 无从下手。没有统一的中间表示Agent 生成的代码无法对接上层框架。没有足够强的代码生成能力Agent 产出的东西没法用。现在这三个条件都具备了所以这个系列讨论的内容是有现实可行性的。3. 系列的整体架构从工具链到推理框架的完整链路3.1 软件栈的分层模型一颗 RISC-V AI 芯片的软件栈从下到上大致可以分成这几层层次主要内容Agent 介入程度工具链层编译器后端、汇编器、链接器、调试器高大量模式化代码驱动与运行时层设备驱动、内存管理、任务调度中骨架可生成逻辑需人工算子库层矩阵乘、卷积、激活、归一化等高候选实现可自动生成和调优图编译与优化层计算图切分、算子融合、内存规划中策略可辅助决策需人工推理框架适配层后端注册、张量抽象、执行引擎对接高接口代码可批量生成应用与测试层模型部署、精度验证、性能基准中测试用例可生成分析需人工这个分层不是绝对的不同芯片架构会有差异。比如有些 AI 芯片把图编译和算子库合并在一起有些把运行时和驱动合并。但大体上这个分层能覆盖大多数 RISC-V AI 芯片的软件栈结构。3.2 系列文章的编排逻辑这个系列会按照软件栈的层次从下往上讲。每一篇聚焦一个层次讲清楚这个层次要解决什么问题、Agent 能怎么帮忙、具体怎么操作、遇到什么问题怎么排查。第一篇讲工具链层重点是编译器后端的指令选择与调度。Agent 在这里的主要任务是根据指令集手册生成 LLVM TableGen 描述、根据指令语义生成 SelectionDAG pattern、根据微架构参数生成调度模型。这部分工作传统上非常耗时因为要写大量重复的 pattern而且容易出错。Agent 可以批量生成候选 pattern人类工程师做筛选和验证。第二篇讲驱动与运行时层重点是寄存器操作和内存管理。Agent 可以根据寄存器手册生成读写函数、根据内存映射生成地址转换代码、根据任务描述生成调度骨架。这部分的关键是保证生成的代码符合硬件时序要求所以 Agent 产出的东西必须经过严格验证。第三篇讲算子库层这是 Agent 最能发挥价值的地方。给定一个算子的数学定义和目标硬件的指令集Agent 可以生成多个候选实现然后通过自动调优找到最优版本。这部分会详细讲怎么设计调优循环、怎么定义搜索空间、怎么利用性能计数器反馈。第四篇讲图编译与推理框架适配层重点是计算图到硬件的映射。Agent 可以辅助做算子融合决策、内存分配策略生成、后端接口代码生成。这部分会讲怎么把 TVM 或 MLIR 的中间表示对接到底层算子库。第五篇讲测试与验证包括精度测试、性能基准、回归测试。Agent 可以生成测试用例、分析测试结果、定位精度异常。这部分会讲怎么设计测试策略让 Agent 生成的测试真正能发现问题。3.3 每篇文章的固定结构为了让这个系列有统一的阅读体验每篇文章会按照以下结构组织问题定义这个层次要解决什么问题为什么难传统做法是什么。Agent 介入点哪些环节可以交给 Agent哪些必须人工。实操过程具体的操作步骤包括工具配置、提示词设计、代码生成、验证方法。踩坑记录实际操作中遇到的问题和解决方法。效果评估Agent 介入后效率提升多少质量如何还有什么不足。这个结构不是死的会根据具体内容调整。但核心是每篇都要有可复现的操作路径不能只讲概念。4. 核心实操环节预览Agent 到底怎么用4.1 工具链适配从指令手册到 LLVM 后端编译器后端适配是软件栈里最硬核的部分之一。以 LLVM 为例要支持一套新的 RISC-V 指令扩展需要做这几件事第一在 TableGen 里定义指令的编码、操作数、汇编格式。这部分工作非常模式化每条指令都要写一段描述。如果指令集有上百条指令手写会非常痛苦。Agent 可以读取指令集手册自动生成 TableGen 描述。实际操作时可以把手册里的指令表转成结构化数据然后让 Agent 按照 LLVM 的 TableGen 语法生成代码。第二定义指令选择 pattern。LLVM 的 SelectionDAG 需要把中间表示映射到目标指令。比如一个向量加法要映射到自定义的向量加指令。Agent 可以根据指令语义生成 pattern但需要人类工程师检查 pattern 的覆盖范围和优先级。第三定义调度模型。如果芯片有流水线需要告诉编译器每条指令的延迟和吞吐。Agent 可以根据微架构文档生成调度模型但微架构参数往往需要实测校准。这部分的关键是Agent 生成的代码必须经过严格验证。编译器后端的 bug 非常隐蔽可能导致生成的代码功能正确但性能极差或者在某些边界情况下出错。所以每生成一批代码都要跑完整的测试套件。实操心得让 Agent 生成 TableGen 代码时最好先给它几个手写的样例让它学习风格和约定。直接让 Agent 从零生成格式错误会很多。另外生成的 pattern 要按优先级排序避免冲突。4.2 算子库开发自动生成加自动调优算子库是 AI 芯片软件栈里最影响性能的部分。以矩阵乘法为例在 RISC-V AI 芯片上可能有专门的矩阵乘加指令也可能用向量指令组合实现。不同的实现方式性能差异很大而且最优实现取决于矩阵大小、数据类型、内存布局等多个因素。传统做法是手写几个版本然后根据经验选择。但这样覆盖的场景有限而且换一颗芯片就要重写。Agent 介入后可以这样做第一步让 Agent 根据算子的数学定义和目标指令集生成多个候选实现。比如对于矩阵乘法可以生成基于向量指令的版本、基于矩阵乘加指令的版本、基于分块策略的版本。每个版本用不同的循环顺序、分块大小、寄存器分配策略。第二步设计自动调优循环。把候选实现编译后在目标硬件或模拟器上运行收集性能数据。然后根据性能反馈让 Agent 调整参数生成新的候选实现。这个循环可以自动跑很多轮直到性能收敛。第三步把最优实现固化到算子库里同时保留调优日志方便后续复现和迁移。这部分的关键是搜索空间的设计。如果搜索空间太大调优时间会很长。如果太小可能找不到最优解。Agent 可以根据硬件参数和算子特征自动缩小搜索空间。比如根据寄存器数量限制分块大小的上限根据缓存大小限制分块策略。4.3 推理框架对接批量生成适配代码推理框架适配层的工作量往往被低估。一个主流推理框架可能有几百个算子每个算子都要对接到底层算子库。如果手动写适配代码工作量巨大且容易出错。Agent 在这里可以批量生成适配代码。具体做法是把框架的算子接口定义和底层算子库的接口定义都提取出来让 Agent 做映射。比如框架里的conv2d算子要映射到算子库里的conv2d_nhwc或conv2d_nchw取决于数据布局。Agent 可以根据接口签名和文档自动生成映射代码。这部分的关键是接口描述的准确性。如果框架接口文档不完整Agent 生成的代码可能有问题。所以实际操作时往往需要先补全接口描述再让 Agent 生成代码。另外生成的代码要经过单元测试确保每个算子的输入输出符合预期。4.4 测试与验证让 Agent 生成能发现问题的测试测试是软件栈质量的重要保障。但写测试用例很枯燥尤其是边界测试和随机测试。Agent 可以根据算子定义和硬件特性生成有针对性的测试用例。比如对于量化算子Agent 可以生成覆盖不同量化范围的测试数据包括最大值、最小值、零、非对称分布等。对于矩阵运算Agent 可以生成不同形状的矩阵包括非对齐尺寸、奇异矩阵等。对于内存操作Agent 可以生成跨页访问、对齐和非对齐访问的测试。这部分的关键是测试 oracle 的设计。Agent 生成的测试用例需要有参考实现来比对结果。参考实现可以是 CPU 上的高精度实现也可以是数学上的精确计算。如果参考实现本身有问题测试就失去了意义。5. 常见问题与排查技巧实录5.1 Agent 生成的代码编译不过怎么办这是最常见的问题。Agent 生成的代码往往在语法上接近正确但细节上有偏差。比如 LLVM TableGen 的语法很严格少一个分号、多一个括号都会报错。排查思路是先看编译错误信息定位到具体行。如果是语法错误让 Agent 根据错误信息重新生成那一部分。如果是类型错误检查 Agent 是否理解了操作数的类型约束。如果是链接错误检查生成的符号名是否符合约定。避坑技巧让 Agent 生成代码时要求它同时生成对应的测试用例。这样编译不过时可以先用测试用例验证语法再集成到主代码库。5.2 Agent 生成的代码功能正确但性能差这个问题在算子库开发中很常见。Agent 生成的代码可能逻辑正确但没有利用硬件的关键特性比如没有用向量指令、没有做循环展开、没有做数据预取。排查思路是用性能分析工具定位热点看时间花在哪里。检查生成的汇编代码看是否使用了预期的指令。如果没用向量指令检查 Agent 是否知道向量指令的存在和用法。如果用了但性能差检查数据布局和内存访问模式。实操心得让 Agent 生成算子实现时最好给它提供目标硬件的指令集摘要和微架构参数。如果 Agent 不知道硬件有什么能力它只能生成通用代码性能自然上不去。5.3 Agent 生成的测试用例覆盖不全Agent 生成的测试用例往往偏向常规情况对边界情况和异常情况覆盖不足。排查思路是用覆盖率工具检查测试覆盖了哪些代码路径。针对未覆盖的路径手动补充测试用例或者让 Agent 针对特定路径生成测试。检查测试数据是否覆盖了所有边界值比如最大值、最小值、零、非对齐值。避坑技巧让 Agent 生成测试用例时明确要求它覆盖边界情况。比如“请生成覆盖以下情况的测试输入为零、输入为最大值、输入为最小值、输入为非对齐尺寸、输入包含 NaN”。5.4 Agent 不理解硬件时序约束在驱动和运行时开发中硬件时序约束非常关键。比如某个寄存器写入后需要等待几个周期才能读某个内存操作需要屏障指令。Agent 往往不理解这些约束生成的代码可能违反时序要求。排查思路是检查生成的代码是否包含必要的等待和屏障。如果缺少检查 Agent 是否知道这些约束的存在。把时序约束以明确的形式告诉 Agent比如“寄存器 A 写入后必须等待至少 10 个周期才能读寄存器 B”。实操心得硬件相关的约束最好以结构化形式提供给 Agent比如表格或配置文件。自然语言描述容易遗漏结构化数据更可靠。5.5 Agent 生成的代码风格不统一当多个 Agent 或多个会话生成代码时风格可能不一致。比如命名约定、注释格式、错误处理方式。这会给后续维护带来麻烦。排查思路是制定代码风格规范包括命名、注释、错误处理、日志格式。在提示词中明确要求 Agent 遵循规范。用代码格式化工具和静态检查工具做统一处理。避坑技巧给 Agent 提供几个手写的样例文件让它模仿风格。比单纯用文字描述规范更有效。6. 这个系列后续还可以怎么扩展这个系列目前规划了五篇覆盖从工具链到测试的主要环节。但软件栈构建还有很多值得探讨的方向后续可以根据读者反馈扩展。比如多 Agent 协作一个 Agent 负责生成代码一个负责验证一个负责调优它们之间怎么分工、怎么通信、怎么解决冲突。这在复杂软件栈构建中很有价值因为单个 Agent 的能力有限多个 Agent 可以互相补位。比如Agent 与 CI/CD 的集成怎么把 Agent 生成的代码自动接入持续集成流程怎么设计自动化测试和性能回归怎么在代码审查中引入 Agent 辅助。这部分偏工程化但对实际项目落地很重要。比如跨芯片迁移当软件栈从一颗 RISC-V AI 芯片迁移到另一颗时Agent 能复用什么、需要重新生成什么、怎么降低迁移成本。这是很多团队面临的现实问题。比如安全与可靠性Agent 生成的代码怎么保证没有安全漏洞怎么做形式化验证怎么在关键系统中使用。这部分偏学术但对高可靠性场景很有意义。如果你对这个系列感兴趣可以从第一篇开始看。每篇都是独立的但按顺序看能形成完整的知识链路。实际操作中遇到问题欢迎在评论区交流我会尽量回复。