用 AI Agent 在 QEMU 上搭建 RISC-V AI 芯片实验台的全过程

最近一直在折腾 RISC-V AI 方向的东西。手上没有真正的开发板又想验证一条指令、一个算子、甚至一套软件栈能不能在目标芯片上跑通最后的落点基本都会指向 QEMU。但 QEMU 环境搭建这件事说简单也简单说麻烦是真麻烦——交叉工具链、链接脚本、启动流程、rootfs、QEMU 启动参数任何一个环节出问题后面全线卡住。这次我试着把整个搭建过程丢给一个 AGENT 来干让它去读文档、写脚本、跑命令、自己看报错然后改最后在模拟器里拉起了一块可供 RISC-V AI 芯片做实验的实验台。这篇文章就把整个过程拆开聊一聊我是怎么设计任务的、AGENT 实际做了哪些事、在哪些地方翻车了、最后怎么救回来的。如果你也想用 AI Agent 帮你搞环境搭建或者正在纠结怎么在 QEMU 上跑 RISC-V 的 Linux 和 PyTorch这篇应该能给你一些可以直接抄的思路。1. 为什么我会把环境搭建整个丢给 AGENT1.1 从配置地狱说起做 RISC-V 开发环境的人应该都有过这种体验网上教程一大把但每一篇的QEMU版本、工具链版本、内核版本都不一样。照着 A 教程配好了工具链B 教程的启动参数又在 qemu-system-riscv64 上报错Unsupported machine type。最难受的是报错信息往往根本看不懂——它不是告诉你哪一步错了而是让你自己去理解 QEMU 内部对设备树的解析逻辑。我之前搭过一次折腾了整整两个晚上。第二天的状态就是不想再看终端不想再看手册觉得自己像一台没有文档的机器在给另一台机器调参。这次我决定换个思路反正环境搭建本质上是查资料、写命令、看报错、修正、再跑的循环这恰好是 AGENT 最擅长的事情。我只需要给它一个足够清晰的目标再给它一台能跑的机器它就能自己迭代。传统环境搭建的核心痛点是人肉同步状态。你看了教程、改了配置、跑了命令、看到报错然后你需要在脑子里更新一下当前环境到底是什么状态再决定下一步。这个状态更新过程其实非常耗精力尤其当你同时要兼顾工具链版本、内核配置、rootfs 类型的时候。AGENT 的好处在于它天然会把每一步操作和执行结果记录下来等于替你维护了一份环境状态日志。哪怕它中途崩了你也能从日志里复盘它到底干到了哪一步。1.2 AGENT 到底是替我做还是带我一起做实际用下来我的体会是AGENT 更接近一个动手能力很强、偶尔会自作聪明的实习生而不是一个全自动机器人。布置任务的时候你把背景讲清楚、验收标准写明确它能干得很漂亮。但如果你自己也没想清楚什么叫搭好了它就会在某个奇怪的方向上越走越远。这次我给了它一个非常明确的目标在 QEMU 上拉起一个能跑 Linux 并能安装 PyTorch 的 RISC-V 环境。验收标准是能启动到 shell能执行 uname能运行 Python 并 import 指定模块。有了这个目标之后AGENT 开始自己去查 QEMU 对 RISC-V 虚拟机的支持情况去看哪种 machine type 最合适去对比 OpenSBI 和直接加载 kernel 的区别。我在旁边做的事情更多是审核它的方案把不合理的路径掐掉。换句话说AGENT 负责把怎么做的细节全部填充掉我负责确认做出来的东西是不是我想要的。这个分工模式在环境搭建这种过程繁琐但验收标准相对清晰的任务上效率高得惊人。2. 动手之前想清楚 QEMU 这块模拟芯片要提供什么2.1 AI 芯片实验台到底需要哪些能力用 QEMU 搭建 RISC-V AI 芯片实验台这句话听起来很唬人实际拆开看就三层需求。第一层指令集支持。我要验证的 AI 负载最终要跑在 RISC-V 上至少 CPU 得支持 RV64GC最好还能带 V向量扩展因为很多 AI 算子的优化都是围绕向量指令展开的。QEMU 的-cpu rv64默认配置支持 RISC-V 的 IMAFDC 扩展如果要向量扩展得在 CPU 型号里显式打开或者用-cpu rv64,vtrue这样的方式。这一层决定了我能不能在模拟器里跑裸机和 Linux 内核。第二层系统能力。如果要跑完整 LinuxQEMU 的virtmachine type 是最稳的选择。它自带 PLIC 中断控制器、virtio 总线、串口等外设而且设备树是 QEMU 自己生成的不用我们手工维护。对 AI 芯片实验来说virt 平台就像是块标准开发板能把软件栈快速跑起来先把功能调通。第三层AI 软件的运行能力。跑 AI 负载需要用 Python、PyTorch 这样的用户态软件这要求 rootfs 里有完整的 glibc、Python 解释器和依赖库。光能启动内核还不够得把用户态的生态环境也铺好实验台才算真正能用。这三层需求直接决定了 AGENT 的整个任务分解方向。如果目标只是验证一条汇编指令的效果那可以用裸机 最小启动代码连内核都不用加载。但我要的是AI 芯片实验台那就必须走到完整 Linux 用户态 AI 框架这一层。2.2 QEMU 的三种玩法AGENT 帮我把差异列清楚了在让 AGENT 干活之前我让它先做了一次方案对比。它从资料库里找出 QEMU 模拟 RISC-V 的三种典型方式我整理成一张表模拟方式能模拟到什么程度适用场景典型限制qemu-system-riscv64系统模式完整 SoC、中断、外设、virtio、多核跑 Linux 内核、驱动、完整软件栈启动慢QEMU 层开销大qemu-riscv64用户态模式单个用户进程的 RISC-V 指令翻译快速跑交叉编译好的程序、跑 Python 单元测试无法验证系统调用之外的内核交互qemu-riscv64 自定义设备模型某个特定外设或芯片扩展调试自定义指令或 AI 加速器需要改 QEMU 源码工作量大对AI 芯片实验台这个目标来说用户态模式适合做算子正确性验证系统模式适合做完整的软件栈集成验证。两个都保留、配合使用效果最好。AGENT 给出的建议是先用用户态模式快速验证工具链和 Python 环境再用系统模式跑完整镜像。这里有个很重要的点AGENT 可以做资料采集和方案对比但最终怎么拍板还是得靠我自己想清楚实验台的目标。因为同样是环境搭建有人想要的是嵌入式系统调试环境有人想要的是深度学习模型的推理环境这两者的路径完全不同。如果一开始就丢给 AGENT不给它需求边界它大概率会做出来一个什么都像但什么都不完全对的环境。2.3 为什么我最终放弃了真板子手头没有真芯片这是核心原因。但有真板子的人我也建议先在 QEMU 上把软件栈跑通再上板。真板子的价值在真实外设行为比如 PCIe 控制器、DMA 引擎、真实带宽瓶颈这些都是 QEMU 模拟不了的。但我现在的实验目标是验证 AI 算子的正确性、软件栈的可行性而不是跑基准测试、测量硬件性能。用 QEMU 搭实验台最大的好处是可以随时把整个环境格式化了重新来——rootfs 坏了、内核配置乱了、环境变量污染了删掉镜像重新生成就行真板子可没这么潇洒。而且 QEMU 支持快照可以在跑 AI 负载之前保存一份干净的镜像状态。每次实验结束-loadvm就能回到初始状态这对反复调试软件栈来说几乎是一种奢侈。AGENT 在这个阶段的作用是帮我把QEMU 真板定义这类资料整理出来让我在对比时不用自己翻一晚上文档。3. AGENT 正式接管从零拉起 QEMU 启动链路3.1 我给 AGENT 的第一份任务书和 AGENT 协作的第一课是学会写任务书。我见过太多人让 AGENT 干活失败不是因为工具不行而是因为指令里全是帮我搭个环境这种模糊需求。AGENT 不是神仙它没法替你定义合适的环境是什么意思。我当时给的任务书大约是这样目标在 Ubuntu 主机上用 QEMU 模拟 RISC-V 64 位 virt 机器跑起一个 Linux 系统。 验收标准qemu-system-riscv64能启动到登录 shell不使用图形界面内核版本和 rootfs 信息能在启动后通过命令行查询到启动参数和所用镜像文件完整记录到/root/env_setup.log。 环境限制主机内存 16GB磁盘空间 200GB优先使用系统已安装的软件包如需编译源码限制单个任务编译时间不超过 60 分钟。为什么这样写因为验收标准是能启动到 shell这个标准足够简单AGENT 知道什么时候算完成。同时我给了环境限制避免它在某个编译任务上耗时过久。任务书里没有对它说你去用 buildroot 或者 busybox——因为我希望它自己去选我只审核结果不限定过程。AGENT 最终选择了 busybox 生成精简 rootfs理由是更快、依赖更少这个选择很合理因为它只是一个实验台的内核环境不需要完整的发行版。3.2 链接脚本是怎么被 AGENT折腾出来的从一个裸内核镜像到能在 QEMU 上启动中间有个关键环节链接脚本。RISCV 的链接脚本link.ld要告诉链接器代码段、数据段放哪从哪里开始执行。AGENT 第一次生成的链接脚本让我印象深刻因为它自己从riscv64-linux-gnu-ld --verbose里找到了系统默认脚本然后照葫芦画瓢改出了一个极简版本。OUTPUT_ARCH(riscv) ENTRY(_start) MEMORY { RAM (rwx) : ORIGIN 0x80000000, LENGTH 256M } SECTIONS { . 0x80000000; .text : { *(.text.init) *(.text*) } .rodata : { *(.rodata*) } .data : { *(.data*) } .bss : { *(.bss*) } /DISCARD/ : { *(.eh_frame) } }看到ORIGIN 0x80000000我挺意外的因为 QEMU 的virt机器默认把 DRAM 映射到0x80000000这个地址写对了代码烧进去才能被 CPU 取到。你再想想如果让人手工写这个链接脚本第一次大概率会从0x00000000开始然后怎么调都进不了引导。AGENT 之所以能选对地址是因为它直接在 QEMU 的源码和文档里搜到了内存映射信息而不是靠猜。不过链接脚本只是第一步。真正让这块虚拟芯片跑起来还需要一段启动汇编设置栈指针、清 BSS、跳转到 C 语言入口。AGENT 在这个环节犯了个典型错误——它生成的启动代码忘了设置全局指针寄存器gp导致后面的 C 代码访问全局变量时总线错误。这个错误很隐蔽因为它不会在编译阶段报错只会在运行阶段触发异常。当时我盯着日志看发现它在反复修改启动汇编最后自己意识到是gp的问题。这个排查过程花了大概十五分钟如果换了人来查可能得对着寄存器规范手册翻半天。三言两语解释一下为什么必须设栈指针RISC-V 的栈是向下生长的sp寄存器必须指向合法的内存区域否则每次函数调用保存返回地址都会写入一个非法地址。AGENT 生成的启动代码里用了la sp, _stack_top然后在链接脚本里为栈留了 4MB 空间。这类细节很多新手写的裸机代码里都缺但 QEMU 启动时不会给你任何温柔的提示直接就是无响应。3.3 那行 QEMU 启动命令每个参数都值得较真AGENT 最终生成并验证通过的启动命令大概长这样qemu-system-riscv64 \ -machine virt \ -cpu rv64 \ -smp 4 \ -m 2G \ -bios fw_payload.elf \ -kernel Image \ -append root/dev/vda rw consolettyS0 \ -drive filerootfs.img,formatraw,ifvirtio \ -nographic逐个拆开看每个参数都对应一个之前踩过的坑。-machine virt指定机器类型virt 是 QEMU 针对 RISC-V 虚拟化支持的通用板卡自带了 virtio-mmio 总线、PLIC 中断控制器、串口、RTC 等设备。它不需要我们手动去构建设备树因为 QEMU 会自动生成一个符合规范的内核设备树。-cpu rv64默认是一般 RV64GC 配置。凡是涉及 AI 向量指令的场景要改成-cpu rv64,vtrue否则运行带向量扩展的二进制会直接非法指令。我们调试 PyTorch 的算子时很多情况就是吃了 CPU 特性没开全的亏。-bios fw_payload.elf和-kernel Image同时出现其实是一种比较常用的组合先用 OpenSBI 作为固件层再由它把 Linux 内核加载起来。OpenSBI 提供了 M 模式的运行环境和设备树传递逻辑不然你的内核要在 S 模式下裸奔少了一个重要的中间层。-append root/dev/vda rw consolettyS0是传给内核的命令行参数告诉它根文件系统在哪个设备上以及把控制台输出到串口。-nographic把串口重定向到当前终端这是 headless 环境的标配。这套参数不是我手动调出来的AGENT 在跑测试时遇到问题后自己改的。它每次启动失败都会把 QEMU 输出抓下来跟文档对照定位到具体参数的错误原因。我当时主要做的是批准或驳回它每次修改——比如它曾试图在-append里加consolehvc0我查了一下它给的参考来源发现 virt 机器在这个配置下用串口设备更合适就驳回了。4. 在模拟 AI 芯片上装 PyTorch这步最能检验 AGENT4.1 RISC-V 上 PyTorch 的真实情况系统能启动之后实验台的下一步是在上面搭 PyTorch。这时候 AGENT 遇到了它整个过程中最头疼的问题PyTorch 官方并没有提供 RISC-V 架构的预编译 wheel 包。你去 pip install torch得到的提示基本是找不到匹配的发行版。原因其实很好理解PyTorch 的底层依赖了 Intel MKL、CUDA、AVX 这些 x86 特有的优化库官方发布流程没有为 RISC-V 构建产物。想在 RISC-V 上跑有几个选择第一用源码编译。从 GitHub 拉 PyTorch 源码用 riscv64 工具链交叉编译。但这个工程量太大哪怕在 x86 主机上交叉编译一次也要几个小时在 QEMU 的虚拟环境里编译更是等到天荒地老。第二用网友或第三方工程构建好的 RISC-V wheel。有人维护了针对 RISC-V 的 PyTorch 构建但版本更新慢、依赖库版本也未必匹配。第三先验证核心算子不装完整 PyTorch。用 torch 内部依赖的一些基础库或者用轻量级的替代方案先跑通 AI 算子的计算流程。AGENT 做了一个让我觉得很务实的决策它先查了官方 issue 和社区讨论确认没有可靠的 wheel 之后没有硬着头皮去编译完整 PyTorch而是转向验证这个环境能不能跑通 AI 相关的 Python 库和 NumPy。因为实验台的底层目标是验证 AI 算子的正确性而不是验证 PyTorch 的安装流程。能用 PyTorch 更好但首先要保证基础数学库能正常工作。4.2 AGENT 在装 Python 依赖时踩到的一个暗坑在用户态模式qemu-riscv64下跑交叉编译出来的 Python 解释器时AGENT 遇到一个诡异的报错Illegal instruction (core dumped)。这条报错本身没什么信息量但它反复出现而且出现的时机毫无规律——有时候是 import numpy有时候是执行一段简单的循环。排查过程很有意思。AGENT 先尝试换 Python 版本无效。再尝试重新编译无效。最后它把报错二进制通过readelf -A查指令集扩展标签发现编译时默认带了V向量扩展指令但在 QEMU 用户态模式下运行某个依赖库时CPU 型号没开向量扩展。我之前说过qemu-riscv64和qemu-system-riscv64的 CPU 模型设置是独立的前者默认更保守。AGENT 的修复方式是给用户态模拟器显式加上 CPU 选项设置环境变量让计算库不触发向量指令路径。这个坑让我意识到一个问题在模拟环境里搭 AI 软件栈指令集扩展一致性比真机更关键。真机上的扩展是确定的但 QEMU 的 user-mode 和 system-mode 默认配置不一样很容易出现system 模式能跑user 模式崩了的情况。AGENT 能在日志里对比两种模式下的 CPU 特性定位效率比人肉翻文档高很多。4.3 在模拟器上验证 AI 推理流程的实际效果经过几轮折腾最终的实验台形态是这样的组件选型备注CPU 模型rv64, vtrue支持向量扩展满足 AI 算子验证系统模式qemu-system-riscv64 virt跑完整 Linux 内核与 rootfs用户态模式qemu-riscv64 自定义 CPU快速运行交叉编译的 Python/NumPy运行库NumPy / 自定义算子PyTorch 暂缓等待社区构建根文件系统busybox 精简 glibc减少开销可随时重建我拿一个小规模的矩阵乘加运算做了验证流程是在 x86 主机上写算子源码用 riscv64 工具链交叉编译再拷到 QEMU 用户态里执行。整个过程不需要启动完整的 Linux 系统单条算子的验证时间从分钟级降到了秒级。如果需要验证内核模块、驱动交互、系统调用路径再切换到 system 模式跑完整镜像。两个模式配合使用实验台的效率比单靠一个模式高很多。这段经历让我对实验台这个概念有了新的理解。它不是说模拟出一个 AI 芯片的外壳而是模拟出一个可以随时验证想法的环境。AGENT 在这个阶段的价值是帮我把验证流程自动化了——它把交叉编译、拷贝、执行、比对结果这几个步骤封装成脚本我只需要改算子代码跑一遍脚本就完事。5. AGENT 翻车现场三个典型事故与救火过程5.1 事故一沙盒里下载工具链被无声拒绝AGENT 在环境搭建初期做过一件事下载 RISC-V 交叉工具链。它选择了从源代码仓库下载预编译压缩包再解压但整个过程没有产生任何文件。它反复检查磁盘空间、校验网络都看不出问题最后卡在一步无限重试。我看日志才发现它的执行环境是受限沙盒对某些网络端口的访问是受限的。压缩包下载请求被静默丢弃AGENT 还以为是自己命令写错了。后来我直接在主机侧帮它下载好工具链压缩包放到共享目录让它在沙盒里只做解压和配置问题一下解决了。教训很简单AGENT 执行环境的网络策略、权限模型和宿主环境不一样这种环境自身限制很难靠 AGENT 自己发现需要人从外部介入。以后我只要发现它反复执行某个下载命令但一直没结果会先手动检查沙盒网络策略而不是让它闷头重试。5.2 事故二agent execution terminated due to error这个报错想必用过 AGENT 编程工具的人都见过。有一段时间它执行任何命令都会走到这个错误终止——不是命令本身报错而是执行进程被整体中断。第一次遇到我以为是命令写错了。但看完整日志发现是 AGENT 在单个回合里塞了太多操作它试图在一个长命令里同时完成内核编译、rootfs 制作、镜像装配。这个命令的执行时间超过了沙盒进程的超时阈值然后整个执行进程被强制终止。AGENT 自己对这种超时是无能为力的因为它不知道沙盒的时限是多少。我的修复方式是把它的大命令拆成一系列小步骤每个步骤单独执行每步之间有明确的中间产物。这一步表面上是在教 AGENT 编程习惯实际上是在适应沙盒的物理约束。从那时起我也意识到给 AGENT 分配任务时要把单个任务执行时间不可超过 X 分钟写进任务书因为它自己不会主动控制单个命令的复杂度。5.3 事故三沙盒更新与无法发送消息背后的真相有一段时间工具提示沙盒更新中然后 AGENT 直接无法发送消息。一开始我以为是网络问题但后来发现这类工具的后端沙盒有版本更新机制更新期间会话的执行环境会被重建进程被冻结。AGENT 卡在等待某个文件生成但那个文件所在的沙盒已经被替代了。这种问题没有太多优雅的解决办法就是把任务拆得更碎、保留中间产物这样沙盒更新后可以从最近的中间状态继续不需要全部重来。我后来在任务书里经常加一句话每一步完成后都把环境状态写入日志以便恢复。这话看起来像废话但当真遇到沙盒重建时它省了我大量时间。5.4 harness 与 AGENT 的职责边界这问题必须搞清楚热词里经常看到harness 和 agent 区别我对这个话题特别有感触。很多人在用 AI 工具时看到失败就怪这个 AGENT 不行但实际上问题往往出在 harness 那一层。harness 是 Agent 运行时的壳负责工具调用、沙盒管理、记忆存储、上下文窗口轮换、执行进程超时控制。AGENT 是壳里的大脑负责推理、决策、生成下一步动作。环境搭建过程中遇到的很多诡异问题本质是 harness 配置问题——沙盒网络受限、超时阈值太短、上下文窗口不够、工具链路径不对。AGENT 能做的只是在 harness 给定的框架内想办法。拿我这次的沙盒举例harness 决定了 AGENT 能访问哪些目录、能执行哪些命令、有没有 sudo 权限。AGENT 在里面再聪明也突破不了 harness 给定的边界。所以当你看到 AGENT 反复执行同一条命令都不成功时不妨先停一停去看看 harness 层的配置而不是单纯让 AGENT 换措辞重试。6. 实测结论与给想照抄的人的建议6.1 把 AGENT 用在环境搭建上的正确姿势这次完整走下来我认为 AGENT 做环境搭建的价值不在于省掉人工而在于把过程透明化。它每一步都留日志每个决定都有出处你可以事后复盘为什么当时那么选。这比绝大多数人手动敲命令留下的记忆要可靠得多。但它的能力边界也很明显它不知道你的实验目标不知道你的验收标准更不知道你的时间预算。所以正确的协作方式是——你负责定义什么算完成AGENT 负责把完成路径上所有细节填充掉。我的做法是每次分配任务前写一段非常具体的任务书包含目标、验收标准、环境限制、优先级。这听起来麻烦但比起让 AGENT 瞎跑半小时省太多时间。6.2 哪些事交给 AGENT 划算哪些事别偷懒我列一个自己的清单适合交给 AGENT 的资料检索与方案对比查某个 machine type 的支持情况、查某个库在 RISC-V 上是否有预编译包。可验证的重复操作交叉编译脚本、rootfs 生成、启动参数调试只要有明确验收标准。日志分析从 QEMU 输出、内核 panic 日志中提取关键错误信息并给出解释。自动化脚本生成把一连串操作包装成一个可复用的脚本。不适合交给 AGENT 的模糊需求比如搭一个适合 AI 芯片的环境它不知道你要跑什么负载、用什么框架。需要真实硬件交互的操作比如烧录真机、测量功耗、确认物理外设时的调试。涉及大量不可逆操作的步骤比如格式化磁盘、删除整个镜像仓库这种我会手动确认不让 AGENT 直接执行。6.3 后续还能怎么扩展这套实验台现在这个实验台已经能跑 Linux、能执行交叉编译的 AI 算子、能在用户态快速验证 Python 计算库。后续我再想加东西也不会推倒重来而是沿着现有框架扩展。一个方向是接入真实的 RISC-V 向量指令优化把某个算子用内联汇编写成 RVV 向量版本然后在 QEMU 上对比向量化和非向量化的运行结果验证正确性。QEMU 虽然不能精确模拟性能但能帮你验证指令序列的语义是否和预期一致这对算子开发来说是刚需。另一个方向是加进更多 AI 算子库的支持比如把 ONNX Runtime 在 RISC-V 上交叉编译跑通。如果社区后续提供更完善的 PyTorch RISC-V 构建也能直接替换掉当前实验台上的验证路径而不需要改底层环境。我个人最大的体会是环境搭建最怕的不是复杂而是不可见。AGENT 把整个过程变成了一份可复现、可复盘、可断点续跑的记录这比它替你省下多少小时更有价值。如果你也打算用 AGENT 搭一套类似的实验环境记住一件事就好——先写清楚什么算搭好了再让 AGENT 开始折腾。