上周我干了一件蠢事把一段需要反复微调的 RISC-V 向量汇编代码交给一个只会按模板替换的脚本去批量生成。结果不用说它把指令语义理解错差点让我怀疑自己是否还适合继续做 RISC-V AI 芯片的软件栈。后来我换了个思路——不是用脚本而是用 AI Agent 来驱动整个软件栈的建设过程。这篇文章就是这个系列的开篇导读我会告诉你 AI Agent、RISC-V、AI 芯片、软件栈这四件事是怎么拧成一股绳的。可能很多人跟我一样一听到“AI 芯片”首先想到的是 GPU 或者专门的大算力加速卡但如果把目光放到边缘侧、端侧推理RISC-V 架构正在成为一股不可忽视的力量。它开源、可扩展、授权费低而且允许你塞进自定义指令去加速特定算子。可问题在于架构漂亮不代表能跑起来真正决定一块芯片好不好用的是它周围那一大坨软件栈。这也是我想用 Agent 来“造”软件栈的原因与其让工程师把精力耗费在无穷无尽的代码生成、编译报错、寄存器对齐这些体力活上不如让智能体把重复环节吃掉我们只负责做判断。这个系列不是学院派的知识梳理而是我自己从 0 到 1 踩坑的记录。所以这篇导读会先把边界说清楚AI Agent 到底能帮到什么程度RISC-V AI 芯片的软件栈由哪些层构成我们要做的最小闭环是什么以及哪些坑我已经替你踩过。1. 为什么我会想把“写软件栈”这件事交给 AI Agent1.1 软件栈里的“体力活”真的比想象中多写过 RISC-V 软件栈的人应该都有感触指令选择、ABI 规则、通用寄存器与向量寄存器分配、栈帧布局、链接脚本、启动代码、中断向量表……每一项背后都有大量模式化代码但这种模式化不是套公式而是需要理解硬件约束。比如 RISC-V 的调用约定里a0-a7 传参t0-t6 是临时寄存器但你得小心某些扩展指令会不会悄悄污染它们向量扩展引入 v0-v31 的同时还要用 vtype 寄存器控制元素宽度与向量长度。这些约束如果不搞清楚编译器生成的汇编分分钟跑飞。之前我做自动化无非是 Python 脚本加正则表达式模板。坦白讲生成一批“看起来对”的代码很容易但一旦参数组合变多、分支逻辑变多脚本就开始崩。因为脚本是单向的它不会看编译回执不会看运行结果更不会在出错之后调整策略。这正是“自动化”和“Agent”的分水岭。AI Agent 不是简单的文本生成器它内部天然是“生成→执行→观察→修正”的循环。你给它一个任务它先拆解然后调用工具去执行再读取执行结果最后根据反馈决定是补丁还是重写。这个架构放在“编译代码→看报错→改代码”这种场景里几乎就是量身定做的。1.2 “DeepSeek 到底是 Agent 还是模型”这个问题其实问到了点子上很多朋友把 AI Agent 和 LLM 混为一谈看到热搜词里挂着“DeepSeek 属于哪个”就知道这个概念有多混乱。简单说DeepSeek 这类产品是 LLM大语言模型是“大脑”它负责理解问题、生成文本和代码、给出判断。而 AI Agent 是“大脑 手脚 眼睛”除了生成它还能执行 Shell 命令、读写文件、操作 Git、调用编译器、读取日志从而形成完整闭环。DeepSeek 可以被封装成 Agent 里的推理引擎但 Agent 的价值不在于底层模型有多强而在于任务怎么拆解、工具怎么定义、验证怎么做。我会在这个系列中默认使用一套可替换底层模型的 Agent 框架今天用 DeepSeek 也好用其他开源模型也好核心逻辑是一样的。这里要强调一个容易被忽略的点LLM 本身并不具备稳定执行任务的能力。你让它写一段 RISC-V 汇编它可能写得很好但你不会自动知道它对不对。Agent 的价值在于把这段输出放到编译器里跑一遍让报错信息成为下一轮输入进而逼着模型修正。没有闭环验证LLM 只是玩具有了闭环验证LLM 才变成生产力。1.3 为什么软件栈这个场景特别适合 Agent 先跑起来因为软件栈开发天然就是“生成→编译→报错→修改→再编译”的循环。Agent 最擅长的就是这个循环。你让 Agent 写一首诗很难自动验证好坏但让它生成一个算子 kernel你可以编译、链接、在模拟器或 FPGA 上跑测试输入输出对不上就是不对。这种“明确的成功标准”是 Agent 落地的第一土壤。另一个原因是 RISC-V 生态还在成长期资料不像 x86/Arm 那么集中很多 spec 碎片化地散落在 GitHub、邮件列表和博客里。Agent 可以把检索、整理、对比版本差异这类杂活接过去把工程师从网页切换中解放出来。说实话我最初也没有想用它来写核心算法只打算让它搭个交叉编译环境结果发现它连“下载工具链时选哪个版本”这种问题都能理得明明白白于是才决定把整个系列方向往“造软件栈”上引。2. RISC-V AI 芯片的软件栈先把地图画清楚2.1 软件栈不是“一个编译器”而是一条链很多人一提软件栈就想到编译器但 AI 芯片的软件栈远比“编译器”三个字复杂。从上层到底层大致要经过这样几条链应用算法层PyTorch、TensorFlow、TFLite 训练的模型模型转换与量化层把 FP32 模型导出为 ONNX再做量化、剪枝、蒸馏推理引擎 / 运行时层负责算子调度、内存分配、多核分发算子库层GEMM、Convolution、Softmax、LayerNorm、各种量化算子编译器后端层LLVM/GCC 的 RISC-V 后端做指令选择、寄存器分配、指令调度驱动与运行时环境HAL、用户态驱动、设备初始化Boot 与硬件寄存器层启动代码、时钟配置、外设初始化。对 AI 芯片来说关键瓶颈往往在“模型转换→算子落地”的中间层。通用编译器很难覆盖自定义指令的全部优化空间所以你需要亲手写算子库和调优工具而这一层恰恰是最繁琐、最容易出错的。2.2 哪些环节适合 Agent 介入哪些不适合我在确定系列范围前先把软件栈的每个环节以及 Agent 的介入方式梳理了一遍。下面这张表是我自己的选型底稿软件栈层典型工作Agent 介入方式介入难度建议构建环境拉取工具链、写 CMake/Makefile自动安装依赖、修复编译配置低首选试点汇编/算子生成编写 RVV kernel、内联汇编根据注释生成初稿人工 review中先以辅助为主模型转换PyTorch 导出 ONNX、量化编写脚本、检查维度与数值误差低可以全自动编译器后端指令选择、寄存器分配、pass 编写辅助搭框架、写测试用例高不建议直接改二进制/反汇编反汇编、符号分析、镜像对比调用工具并解释结果低适合日常排查硬件调试OpenOCD、GDB、寄存器采集辅助生成脚本、分析日志中需要真人确认这张地图就是后续所有文章的索引。你会发现越靠近“构建”和“脚本”的环节Agent 越可靠越靠近“硬件时序”和“架构权衡”的环节Agent 越需要人兜底。我的原则是能用脚本定义验收标准的就让 Agent 去试验收标准很难定的宁可自己做。2.3 一个“最小可跑 AI 模型”的软件栈长什么样这个系列的主线我定为一个“在 RISC-V 模拟器上跑通手写数字识别 CNN”的最小闭环。听起来不复杂但链条很完整把 PyTorch 训练好的模型转成 ONNX再转到自定义指令格式写卷积、ReLU、全连接这些算子的 RVV 实现链接成一个可执行文件在 QEMU 的 RISC-V 仿真环境上跑起来最后输出正确概率。为什么选这个目标因为它的规模刚刚好。太小了比如只做一个向量加法接触不到软件栈全貌太大了比如直接跑 YOLO环境配置就能把系列拖死。手写数字识别 CNN 的算子种类有限但已经覆盖了量化、GEMM、内存搬运、向量循环这些核心难点跑通之后后续扩展 Transformer 类模型也就有了基础。整个系列所有 Agent 实验都会围绕这条主线展开。3. 从 0 到 1 搭建“最小 AI 芯片软件栈 Agent”的骨架3.1 一个可落地的 Agent 架构先给结论我不打算一上来就上“多智能体编排平台”而是用一个最简单的单线程循环把闭环跑起来。核心组件只有五个大模型负责推理和生成计划、工具集Shell、文件读写、Git、编译命令、上下文管理记录系统提示、用户任务、每轮工具输出、任务拆解器把大任务拆成可执行子任务、验证器执行测试用例判断成功或失败。用伪代码看整个骨架就只有这么一点点def agent_loop(task, context, tools, validator, llm, max_iterations10): context.add(任务, task) for i in range(max_iterations): plan llm.decompose(context.get_messages()) for step in plan: result tools.execute(step[tool], step[args]) context.add(工具输出, result) if validator.validate(result): context.add(状态, 该步骤通过) else: context.add(状态, 该步骤失败) context.add(失败信息, result.error) break # 进入下一轮重新计划 if validator.is_task_complete(context): return context.final_answer() return 迭代超时需要人工介入这段代码虽然简化但已经点出了 Agent 成功的三个关键一是工具必须真实可执行不能只是“假装调用”二是验证器要给出明确反馈不能只让模型自己判断对错三是上下文管理要清晰否则模型会在五轮之后忘记最初目标。我会在系列的第三篇里给出完整可运行的 Python 工程。3.2 为什么我建议先做“单点 Agent”而不是一上来就做全自动平台我曾经犯过一个典型错误想做一个“输入算法模型就自动生成整个软件栈”的万能 Agent结果发现所有工具串起来之后非常混乱。一次任务生成几十个文件编译失败后反复修改产生了大量无用改动最后我只能把整个工作目录删掉重来。教训是Agent 的能力边界需要用“单点”一个一个验证。我推荐先做一个“单点 Agent”比如让它根据头文件接口自动生成单元测试脚手架然后编译运行并汇报结果。这个单点有明确的输入输出而且结果容易衡量。或者让它把一段 C 代码改写成 RVV 内联汇编然后用测试数据跑结果对比。这类单点跑通之后再逐步添加工具把它组合成多步流水线风险会小很多。还有一点每个 Agent 都带“护城河”也就是至少一个硬性验证步骤而不是只看文本是否符合预期。文本生成是软的编译通过和数值匹配是硬的。没有硬验证Agent 就是自嗨。3.3 把系统提示词写成“岗位说明书”很多初学者搭 Agent 时系统提示词只写一句“你是资深嵌入式工程师”。这种提示词在简单对话里够用但到了多轮工具调用场景模型很快就会忘记规则。我现在的做法是像给实习生写任务清单一样写系统提示词明确目标、约束、可用工具、验收标准。举个例子给算子生成 Agent 的提示词大致是你是一名 RISC-V 嵌入式工程师。当前工作目录是/workspace/rvv_ops。可用命令有make、qemu-riscv64、riscv64-unknown-elf-gcc。生成汇编时必须遵循 RISC-V 调用约定使用vsetvli动态配置向量长度。每次修改文件后必须执行make test验证数值是否正确。不要为了美化代码而额外重构不要在最终回答里输出“我完成了”之类的话直接输出测试结果。这样写看起来絮叨但模型反而更听话。因为它的行动边界被框住了后面每一轮迭代都有一致的约束。这个模板是我在这个系列里最想分享的细节之一因为很多时候 Agent 表现不稳定不是模型不够强而是“岗位说明书”写得不够清楚。4. 打通“模型转换—算子生成—在仿真/真实芯片上跑通”的链路4.1 第一步让 Agent 帮你搭建模型转换工作流我最初是把 Agent 当成“脚本生成器”来用的。比如 PyTorch 导出 ONNX 时总会遇到某些算子不支持或输入维度不匹配让它去修脚本确实比我手工查文档快很多。但后来我意识到单纯生成脚本还不够模型转换必须有一个“校验器”把关。具体来说我会让 Agent 生成一个转换脚本完成 PyTorch 模型到 ONNX 再到自定义 IR 的流程同时保留每个 tensor 的形状和数据类型断言。转换完成之后再把转换前后的模型输入同一个随机样本对比每一层输出的数值误差。一旦误差超过阈值Agent 必须自动分析是量化问题、维度问题还是算子映射问题。这一步有一个很典型的坑Agent 很可能生成能运行但结果错误的脚本。你看着它跑完了没有报错就以为转换正确。但真实推理时精度差得离谱。原因往往是量化参数传错或者某些层被错误折叠。所以我的建议是数值校验收紧比宽松好宁愿多花几分钟跑一轮全量对比也不要为了省事直接进入算子生成阶段。4.2 第二步让 Agent 生成一个可用的向量算子当模型转换链路通了接下来就是最核心的算子落地。以最简单的 int8 向量加法为例我要让 Agent 生成一个符合 RVV 规范的实现。它第一版生成出来的代码通常会长这样#include riscv_vector.h void add_int8(const int8_t *src1, const int8_t *src2, int8_t *dst, int n) { size_t avl n; const int8_t *s1 src1; const int8_t *s2 src2; int8_t *d dst; while (avl 0) { size_t vl __riscv_vsetvl_e8m1(avl); vint8m1_t v1 __riscv_vle8_v_i8m1(s1, vl); vint8m1_t v2 __riscv_vle8_v_i8m1(s2, vl); vint8m1_t vd __riscv_vadd_vv_i8m1(v1, v2, vl); __riscv_vse8_v_i8m1(d, vd, vl); s1 vl; s2 vl; d vl; avl - vl; } }这段代码看起来是对的但你要注意几个细节vsetvl必须在循环内根据剩余元素数动态设置否则大数组会被截断e8m1表示 8 位元素且使用一个向量寄存器组如果元素宽度变化vtype 也要跟着变。Agent 第一版常常把vsetvl放在循环外或者漏掉avl - vl导致死循环。这些问题只有放到真实测试数据里跑才能暴露。所以我不会把 Agent 生成的算子直接拿进镜像而是要求它同时生成一套测试向量包含边缘情况数组长度为 1、为 17、为 256、为 1027然后逐个跑结果比对。只有当所有长度都通过这个算子才算“候选可用”最后再交给工程师 review 性能。这一步非常关键因为 Agent 可以帮你完成代码框架但“silent bug” 必须靠测试数据才能抓出来。4.3 第三步建立自动在 QEMU 上验证的闭环算子写完不可能每次都去真板子上跑先在 QEMU 的 RISC-V 模拟器上验证是效率最高的。我会让 Agent 自动执行qemu-riscv64运行测试程序输入测试向量比对输出。一旦失败Agent 会读取 stdout、stderr甚至反汇编工具的输出然后定位到具体循环或具体行。这种“反馈驱动”的闭环比让 Agent 凭空猜要可靠得多。QEMU 跑通后才轮到真实芯片。真机验证会带来 QEMU 里不存在的麻烦内存映射、DMA 对齐、外设初始化甚至中断优先级。到这个阶段Agent 可以辅助生成 OpenOCD 脚本和 GDB 命令但最终必须有人盯着硬件行为。我的建议是把“在真板上跑通”作为一个硬性门禁不让 Agent 直接控制开发板烧录至少不把烧录器权限直接交给它以免出现误操作。5. 这个系列里我会踩的坑以及给你的避坑清单5.1 RISC-V 资料不够多Agent 容易一本正经胡说你让一个 LLM 写 x86 汇编它的训练数据多到可以脱口而出但换成 RISC-V尤其是指令扩展还在演进的场景它就容易编造规范。我遇到过 Agent 非常自信地解释“RISC-V 的立即数编码是 16 位”实际上 I 型立即数只有 12 位并带符号扩展。这种错误靠编译器和反汇编能揪出来但如果你直接拿它的解释去写代码就会浪费一晚上调一个不存在的 bug。对策很简单让 Agent 引用 spec 条款或者给 Agent 挂一个 RISC-V 文档 RAG 知识库。我会在系列里把 RISC-V ISA spec 的关键章节切碎灌进一个向量库让 Agent 在回答底层问题之前先检索。同时提醒一点RISC-V 的 V 扩展 1.0 在 2021 年才冻结很多旧博客写的vsetvl语法和新版本并不一致。Agent 拿老资料当依据是常有的事只能用版本号约束它。5.2 编译报错信息是 Agent 的陷阱GCC 在遇到模板元编程或者内联汇编问题时报错信息经常非常抽象甚至直接抛出 “internal compiler error”。这时候 Agent 会陷入一个可怕的循环它看不懂报错只能靠猜测改源码越改越乱。我曾让一个 Agent 连续改了 7 轮只是为了绕过一个其实来自链接脚本的符号未定义错误最后它把函数体都删了。为了避免这种情况我现在会给每个 Agent 加两个硬限制一是最大迭代轮数默认 5 轮超出后强制停止并生成一份“尝试日志”交给人类二是每轮必须输出“假设、尝试、结果”三段式信息。这两条规则大大减少了原地打转的概率。另外我会让 Agent 在拿到报错后先做结构化分析打印errno、行号、预处理文件片段而不是直接猜重写方案。5.3 硬件验证不是 Agent 能完全替代的最容易让人兴奋过头的是Agent 在 QEMU 上跑通了所有测试你以为大功告成。但真实芯片和 QEMU 的差异往往藏在你想不到的地方。最简单的例子是内存对齐和 Cache 行为QEMU 可能默认 8 字节对齐而真实芯片对 16 字节对齐有硬性要求Agent 生成的代码在模拟器上毫无问题上板就段错误。所以我不建议让 Agent 直接操作开发板。更好的方式是建立两级门禁第一级在 QEMU 上做功能和数值验证第二级在真实芯片上以“烧录—运行—回传日志—由人工确认”的方式验证。在这个流程里Agent 负责分析回传日志、生成诊断建议但最终拍板的人必须是你自己。这不是不信任 Agent而是硬件的错误往往难以从日志中自动定位盲目让 Agent 修改会引入更多未知风险。5.4 什么时候应该放弃用 Agent最后聊一个反直觉的问题不是所有事情都适合交给 AI Agent。当你想让 Agent 设计一套全新的指令集编码或者决定 ABI 是否应该改动时我劝你放弃。这类问题需要架构师在硬件和软件之间做权衡Agent 只能辅助草拟候选方案最终决定必须由人来拍板。另一个信号是当你发现 Agent 生成的代码有超过 90% 你都需要手动重写时说明任务定义得不够清楚。这时候不要急着换更强大的模型先把任务拆小直到 Agent 的“初稿”至少能留下 50% 可用的代码再考虑扩展其边界。这个阈值是我个人的体感不一定科学但足够提醒你Agent 不是魔法它只是把“体力活”转化为“明确验收”。6. 适合谁来读、按什么顺序读这份系列导读6.1 哪些人会从这套系列中获得真金白银我不是在一篇文章里把完整技术栈教完这个系列更适合有明确动机的人。如果你是嵌入式软件工程师正在做 RISC-V 方向但资料稀缺这个系列能给你一套 Agent 辅助开发的方法论让你少掉头发如果你是 AI 框架工程师想了解算子如何落地到非 GPU 架构这里的模型转换和算子生成案例会给你直观参考如果你是 AI Agent 应用开发者正在寻找一个有硬验收标准的实战场景那这个系列几乎是最佳练习场——因为软件栈开发不像写诗对就是对错就是错。当然这个系列不是零基础教程。你至少需要懂 C 语言和基本计算机体系结构最好用过 Linux 命令。如果你连编译工具链都没有配置过可能会觉得我跳过了很多步骤。我会尽量补齐但不会为了照顾零基础而放慢主线节奏。6.2 推荐的阅读路径如果你只想快速了解 Agent 能做什么可以先读第二章的软件栈地图然后跳到第四章的算子生成案例。如果你想在自己的环境里复现整套实验建议按照第三章的骨架先搭一个单点 Agent把环境准备做扎实再往模型转换和算子验证推进。如果你是资深工程师对构建环境已经很熟悉可以直接关注第五章的避坑清单尤其是那些“Agent 在模拟器上通过但在真板子上失败”的真实案例。随后再去读后续文章中关于真机调试的部分我相信会比自己从头试错快很多。6.3 后续系列的内容预告既然叫系列导读我就把后续的文章列表先摆出来让你有个预期Agent 开发环境与工具链配置LLM API、Shell 工具、QEMU 安装教 Agent 读懂 RISC-V 指令集RAG 知识库的搭建与检索策略自动生成并验证 RVV 算子第一个完整单点 Agent 实战让 Agent 完成从 ONNX 到二进制镜像的端到端转换把 Agent 接入真实开发板单板部署与结果回环多 Agent 协作模拟“硬件工程师”与“软件工程师”双角色共同完成接口定义与验证。这些文章不会只是顺顺利利的教学我会把自己失败的路径也贴出来包括哪个补丁把测试搞挂了、哪句提示词让 Agent 沦为了废话生成器。因为这些东西才是 AI Agent 开发真正值得记录的地方。最后说一点我在这个系列里最想强调的不要幻想 AI Agent 能直接“造”出完整软件栈。更好的定位是把它当作一个可以无限加班、但需要你定义验收标准的执行助理。我在过去两周的尝试里最大的收获不是节省了多少时间而是被迫把软件栈的各个环节拆得更清楚——因为只有拆到机器能够验证的程度Agent 才能真正帮上忙。如果你也准备用 Agent 碰 RISC-V建议从最小的闭环开始先让程序跑起来再谈让 Agent 独立。