1. 为什么我要用 AI Agent 去啃 RISC-V 软件栈这块硬骨头RISC-V 和 AI 芯片这两个词放在一起本身就带着一种未来已来的张力。但真正动过手的人都知道从一颗 RISC-V 核到一块能跑 AI 推理的芯片中间隔着的不是一道沟而是一整片沼泽——这片沼泽就是软件栈。工具链、编译器后端、运行时、算子库、驱动、固件、模型部署框架每一层都能单独写一本书而它们之间的接口又极其挑剔错一个字节的对齐就可能让你在板子上看到一串毫无意义的乱码。我最初接触这个方向的时候想法很朴素既然 AI Agent 现在这么能写代码、能查文档、能自我纠错那能不能让它帮我把这套软件栈造出来注意这里的造不是让 Agent 凭空生成一个 GCC而是让它承担起胶水层、适配层、验证层的大量重复性智力劳动——这些恰恰是软件栈开发中最耗人、最容易出错、又最没有成就感的部分。这个系列导读要解决的就是怎么把 AI Agent 真正用起来这个问题。市面上讲 AI Agent 的文章要么停留在什么是 Agent、Agent 和 LLM 有什么区别这种科普层面要么直接跳到用 Spring AI 搭一个企业级 Agent 平台这种工程层面中间那段最关键的——Agent 如何在一个高度专业、强约束、有硬性正确性要求的领域里干活——几乎没人认真讲。RISC-V AI 芯片软件栈就是这样一个绝佳的试验场它有明确的规范RISC-V ISA 手册、ABI 规范、有可验证的正确性标准跑通测试用例、比对黄金参考、有大量结构化的重复工作指令编码、寄存器分配、算子映射同时又有足够高的门槛让 Agent 的幻觉无处遁形。适合读这个系列的人我大致画个像你最好对计算机体系结构有基本概念知道什么是 ISA、什么是流水线、什么是内存一致性你最好写过一点 C 或者汇编理解指针和寄存器不是玄学你最好对 AI Agent 有实际使用经验不是只看过 demo而是被它的胡言乱语坑过。如果你三者都具备那这个系列会让你少走至少半年的弯路。如果你只具备其中一两项也没关系我会在关键处补足背景但你要有心理准备——这不是一篇三分钟上手的爽文。先把这个系列的定位说清楚它不是 RISC-V 的入门教程也不是 AI Agent 的科普。它是一条工程实践路线讲的是我如何把 AI Agent 拆解成不同角色嵌入到 RISC-V AI 芯片软件栈的开发流程里让它在每个环节承担明确的责任并且用可验证的方式保证它不跑偏。整个系列会覆盖从工具链适配、算子库生成、到端到端模型部署验证的完整链路每一篇都会给出具体的 Agent 配置思路、提示词结构、验证方法和踩坑记录。2. 先厘清概念AI Agent、LLM、AI 模型到底谁是谁在动手之前必须先把几个被网络热词搅浑的概念理清楚。我见过太多人把AI Agent和大模型当成同义词用结果在设计系统时把该分层的东西揉成一团最后既不好调试也不好扩展。这一节我用最直白的方式把它们拆开并且说明在 RISC-V 软件栈这个场景里每一层各自扮演什么角色。2.1 LLM 是大脑但不是人LLMLarge Language Model大语言模型本质上是一个条件概率分布给定一段文本它预测下一个 token 最可能是什么。你熟悉的 DeepSeek、GPT 系列、Claude 系列、Qwen 系列都属于 LLM。它们的能力来自海量文本上的预训练表现为能续写、能翻译、能总结、能写代码但它们的局限也同样明显没有持久记忆、没有行动能力、不能主动获取新信息、无法保证输出的事实正确性。在 RISC-V 软件栈开发里LLM 能干什么它能读懂 RISC-V 规范文档的片段能根据指令描述生成编码表能把一段 C 代码翻译成汇编草稿能解释报错信息。但它不能自己去跑一遍编译器验证生成的编码对不对不能自己打开手册翻到第 300 页确认某个 CSR 的位域定义也不能在发现错误后自动重试。这些不能正是 Agent 要补上的。2.2 AI 模型是个更大的筐AI 模型这个词比 LLM 宽泛得多。一个做算子调度的强化学习策略网络是 AI 模型一个做指令级功耗预测的回归模型也是 AI 模型一个做缺陷检测的卷积网络还是 AI 模型。在 AI 芯片语境下AI 模型经常特指被部署到芯片上运行的那个神经网络比如一个量化后的 ResNet、一个 YOLO 变体、一个 Transformer 的某几层。这和作为开发工具的 LLM 完全是两码事但热词把它们混在一起导致很多初学者一头雾水。我在这个系列里会严格区分两种用法当我说AI 模型时默认指待部署到 RISC-V AI 芯片上的推理模型当我说LLM或大模型时指驱动 Agent 的语言模型。这个区分很重要因为前者是我们要处理的对象后者是我们使用的工具。2.3 Agent 是LLM 手脚 记忆 目标AI Agent 的核心定义我倾向于用一句话概括一个能感知环境、做出决策、执行动作、并根据反馈调整策略的自主系统。它和裸 LLM 的区别在于四个附加组件工具调用能力Agent 能调用外部函数或命令比如执行riscv64-unknown-elf-gcc、读取文件、查询数据库、运行测试脚本。记忆机制短期记忆保存当前任务的上下文长期记忆保存跨任务的经验和知识避免每次都从零开始。规划能力把一个大目标拆解成子任务序列并在执行过程中根据中间结果动态调整。反馈闭环执行动作后观察结果判断是否达成子目标失败则重试或换策略。把这四点映射到 RISC-V 软件栈开发上就非常具体了Agent 调用工具链编译代码、读取编译日志、根据报错修改源码、重新编译、跑测试用例、比对输出、记录成功或失败的修改模式。这一整套流程裸 LLM 做不了但 Agent 可以。2.4 一张表看清三者关系概念本质在 RISC-V 软件栈项目中的角色典型代表LLM文本概率模型提供语言理解与生成能力是 Agent 的大脑DeepSeek、GPT、Claude、QwenAI 模型广义的机器学习模型待部署到芯片上的推理负载量化 ResNet、YOLO、Transformer 层AI AgentLLM 工具 记忆 规划执行软件栈开发任务的自主工作单元基于上述 LLM 构建的编码/验证 Agent提示不要试图用一个 Agent 干所有事。软件栈开发涉及编译、验证、调试、文档、测试等多个性质差异极大的环节单一 Agent 的提示词会膨胀到无法维护。后面我会讲怎么按角色拆分。3. RISC-V AI 芯片软件栈到底包含哪些层要指挥 Agent 干活你得先知道活有哪些。很多人对软件栈的理解停留在编译器 驱动这在通用 CPU 上勉强够用但在 AI 芯片上远远不够。AI 芯片的软件栈是一条从模型到硅片的完整通路任何一层缺失或错位都会导致模型跑不起来或者跑得极慢。我按从上层到下层的顺序把这条通路拆开讲。3.1 模型层与图优化层最上层是模型本身通常来自 PyTorch、ONNX 或 TensorFlow。模型不能直接扔给芯片中间要经过图优化算子融合、常量折叠、死代码消除、布局转换。这一层的输出是一个经过简化的计算图算子数量减少、内存访问模式更规整。这一层 Agent 能帮上什么忙图优化规则往往是模式匹配 替换比如Conv BiasAdd ReLU 融合成一个 ConvReLU。这类规则数量多、形式重复非常适合让 Agent 根据已有规则模板批量生成新规则再由人工审核。我实测下来Agent 生成规则草稿的可用率大概在六成左右剩下四成需要修正但即便如此也比从零手写快得多。3.2 算子库与内核层图优化之后每个算子都要有对应的内核实现。在 RISC-V AI 芯片上这些内核可能跑在向量扩展单元上、可能跑在专用的矩阵加速器上、也可能回退到标量核。算子库的质量直接决定芯片的实际性能。这一层是 Agent 最能发挥价值的地方之一。原因有三第一算子实现有明确的数学定义正确性可验证第二不同算子之间有大量结构相似性Agent 可以举一反三第三性能优化有明确的指标周期数、访存次数Agent 可以根据 profiling 结果迭代。但要注意Agent 生成的向量化代码经常在边界处理上出错比如尾部元素、非对齐访问、溢出情况这些必须用测试用例兜住。3.3 运行时与调度层算子有了还需要一个运行时来管理内存、调度任务、处理同步。AI 芯片通常有多个计算单元运行时要把计算图切分、分配到不同单元、插入同步点、管理片上内存的分配与复用。这一层的逻辑复杂且高度依赖具体硬件Agent 在这里更多是辅助角色——帮你看懂硬件手册、生成配置模板、检查资源冲突而不是直接生成调度算法。3.4 驱动与固件层再往下是驱动和固件负责和硬件寄存器打交道。这一层对正确性要求极高一个位写错就可能导致芯片挂死。Agent 在这一层的使用要非常谨慎我通常只让它做两件事根据寄存器手册生成结构化的寄存器定义头文件以及把已有的驱动代码翻译成另一种风格。核心的时序逻辑和中断处理还是得人来写。3.5 工具链与编译后端贯穿所有层的是工具链。RISC-V 的工具链虽然成熟但针对 AI 扩展指令比如自定义的矩阵乘指令、向量指令往往需要自定义编译后端。这意味着你要改 LLVM 或 GCC 的后端添加指令选择模式、寄存器分配约束、调度模型。这是整个软件栈里门槛最高的部分也是 Agent 辅助价值最微妙的部分——它能帮你理解后端代码结构、生成模式匹配的草稿但后端改错的代价极高必须配合大量回归测试。3.6 各层与 Agent 适配度对照软件栈层次主要工作Agent 适配度建议使用方式模型层/图优化算子融合、图重写高批量生成优化规则草稿算子库/内核算子实现、向量化高生成实现 测试驱动迭代运行时/调度内存管理、任务调度中辅助理解硬件、生成配置驱动/固件寄存器操作、中断低仅生成头文件、翻译代码工具链/后端指令选择、寄存器分配中低辅助理解 草稿人工主导这张表是我踩了不少坑之后总结出来的。一开始我试图让 Agent 包办驱动层结果它生成的寄存器操作序列看起来头头是道实际跑起来直接把芯片送进了异常状态。后来我调整策略把 Agent 的权限按层收紧效率反而上去了。4. 把 Agent 拆成角色我的多智能体分工方案单一 Agent 干整个软件栈是我早期犯的最大错误。提示词越写越长最后变成一本几百页的操作手册Agent 在里面迷失方向经常在编译任务里突然开始讨论驱动寄存器。后来我改用多智能体分工每个 Agent 有明确的职责边界、专属工具集和输出格式整体效率提升非常明显。这一节讲我的分工方案和背后的设计逻辑。4.1 为什么必须分工上下文窗口是硬约束LLM 的上下文窗口再大也是有限的而且随着上下文增长模型对中间信息的注意力会衰减。软件栈开发涉及的知识面极广把 RISC-V 规范、LLVM 后端文档、算子数学定义、硬件寄存器手册全塞进一个 Agent 的上下文结果就是它什么都记得一点、什么都做不精。分工的本质是上下文隔离每个 Agent 只加载自己职责范围内的知识只保留自己任务的记忆。编译 Agent 不需要知道寄存器手册算子 Agent 不需要知道调度策略。这样每个 Agent 的上下文都保持精简决策质量显著提高。4.2 我的五个核心 Agent 角色经过反复调整我稳定下来五个角色覆盖软件栈开发的主要环节规范解析 Agent负责读 RISC-V ISA 手册、ABI 规范、硬件寄存器手册把非结构化文档转成结构化的查询接口。它的输出是指令编码表CSR 位域定义ABI 调用约定这类结构化数据供其他 Agent 调用。编译适配 Agent负责工具链相关任务包括编译报错分析、后端模式匹配草稿生成、编译选项调优。它的工具集包括编译器命令、日志解析器、回归测试脚本。算子生成 Agent负责根据算子数学定义生成内核实现包括标量版本和向量版本。它的工具集包括参考实现、测试用例生成器、正确性比对脚本。验证 Agent负责跑测试、比对结果、定位失败原因。它不生成代码只做验证和报告保持独立性避免自己写自己验的偏差。文档 Agent负责把开发过程中的决策、接口、坑点整理成文档供团队查阅。它的输入是其他 Agent 的执行日志和人工注释。这五个角色不是孤立的它们通过一个共享的任务队列和产物仓库协作。规范解析 Agent 产出的编码表编译适配 Agent 和算子生成 Agent 都能读取算子生成 Agent 产出的内核验证 Agent 负责测试验证 Agent 发现的失败模式反馈给对应的生成 Agent 迭代。4.3 角色之间的通信协议多 Agent 协作最容易出问题的地方是接口不一致。A Agent 输出的格式B Agent 读不懂整个流水线就断了。我的做法是强制所有 Agent 的产物使用结构化格式JSON 或 YAML并且为每类产物定义 schema。比如规范解析 Agent 输出的指令编码表schema 大致是这样{ instruction: vadd.vv, extension: V, encoding: { opcode: 1010111, funct3: 000, funct6: 000000 }, operands: [vd, vs1, vs2], description: 向量加法逐元素相加 }有了 schema下游 Agent 就能可靠地解析。我还会让验证 Agent 专门检查 schema 合规性不合规的产物直接打回不让它污染下游。4.4 一个真实的协作流程示例举个具体例子我要为芯片添加一条自定义的矩阵乘加指令mma.wv并让算子库支持它。整个流程是这样的规范解析 Agent 读取硬件手册中mma.wv的描述生成结构化编码定义和语义说明。编译适配 Agent 根据编码定义在 LLVM 后端生成指令选择模式的草稿并跑回归测试确认没有破坏已有指令。算子生成 Agent 根据语义说明生成矩阵乘加算子的内核实现先用标量版本验证数学正确性再替换为mma.wv指令版本。验证 Agent 跑算子测试用例比对数值结果与黄金参考报告误差和性能数据。文档 Agent 把整个流程的决策、代码、测试结果整理成文档。这个流程里人工介入的点主要是审核编译后端的改动和最终的性能调优其余环节 Agent 可以自主完成大部分工作。我实测下来一条新指令从手册到算子库可用周期从原来的一周多压缩到两三天。4.5 分工带来的一个意外好处分工之后我发现一个额外的好处故障定位变容易了。单一 Agent 出错时你很难判断是知识不足、工具用错还是规划失误。分工之后每个 Agent 的职责单一出错时能快速定位到具体环节。比如算子数值不对先看验证 Agent 的测试用例是否覆盖了边界再看算子生成 Agent 的实现是否有溢出再看规范解析 Agent 的语义理解是否有偏差。这种可定位性在复杂系统开发里比单纯的效率提升更宝贵。5. 让 Agent 不胡说验证闭环与幻觉抑制AI Agent 在 RISC-V 软件栈这种强正确性要求的场景里最大的敌人是幻觉。它会自信满满地生成一段看起来完全合理的指令编码实际上 opcode 位域全错它会声称某个算子已经通过测试实际上测试根本没跑。这一节讲我怎么构建验证闭环把幻觉压到可接受的范围。5.1 幻觉在软件栈开发中的三种典型表现我总结下来Agent 的幻觉在这个领域主要有三种事实性幻觉编造不存在的指令、错误的寄存器编号、错误的位域定义。这类幻觉最危险因为看起来最像真的。过程性幻觉声称执行了某个操作比如我已运行测试实际上没有调用工具或者调用了但忽略了失败结果。过度自信对不确定的事情给出确定性的结论比如这个优化一定能提升性能而不提供任何数据支撑。这三种幻觉的抑制策略不同但核心思路一致用外部可验证的事实约束 Agent 的输出。5.2 事实性幻觉的抑制以规范为唯一真相源事实性幻觉的根源是 Agent 在回忆而不是查询。LLM 的训练数据里可能有 RISC-V 规范的片段但不完整、可能过时、可能混淆不同版本。解决办法是切断回忆路径强制查询路径。我的做法是所有涉及指令编码、寄存器定义、ABI 约定的问题Agent 必须通过规范解析 Agent 提供的查询接口获取禁止直接凭记忆回答。查询接口背后是结构化的规范数据库数据来源是官方手册的解析结果。Agent 的提示词里明确写任何指令编码必须来自query_instruction_encoding工具的返回结果不得自行推断。这个约束执行起来需要一点技巧。Agent 有时候会偷懒明明有工具可用却直接回答。我的应对是在验证 Agent 里加一道检查如果产物里包含指令编码但执行日志里没有对应的查询调用直接判定为不合规打回重做。几次之后Agent 就学会了必须先查再答。5.3 过程性幻觉的抑制工具调用日志强制留痕过程性幻觉更隐蔽因为它涉及 Agent 的自我报告。Agent 说测试通过了你怎么知道它真的跑了测试我的做法是所有工具调用强制留痕并且验证 Agent 独立检查日志。具体来说每个 Agent 的工具调用都会写入一个结构化日志包含调用时间、工具名、参数、返回码、输出摘要。验证 Agent 在验收时不信任生成 Agent 的自我报告而是直接读日志。如果生成 Agent 说测试通过但日志里没有测试调用记录或者返回码非零直接判定失败。这个机制还有一个副作用它让 Agent 的行为变得可审计。出问题时我能回溯整个执行链路看到每一步的实际输入输出而不是只看 Agent 的总结。这在调试复杂问题时非常有用。5.4 过度自信的抑制要求提供证据链过度自信的抑制靠证据要求。我在提示词里规定任何性能声明必须附带 profiling 数据任何正确性声明必须附带测试用例和比对结果任何优化建议必须附带前后对比。没有证据的声明验证 Agent 一律标记为未验证不计入最终结论。这条规则执行初期Agent 的输出会变得很啰嗦到处贴数据。但习惯了之后它会自动筛选出真正需要证据的关键结论输出反而更精炼。更重要的是它逼着 Agent 在下结论之前先找证据这个思维链的转变是幻觉抑制的关键。5.5 验证闭环的整体架构把上面几点串起来我的验证闭环大致是这样环节负责方验证手段失败处理事实查询规范解析 Agent结构化规范数据库查询失败则拒绝回答代码生成编译/算子 Agent编译通过 单元测试失败则迭代或上报正确性验证 Agent黄金参考比对误差超阈值则打回性能验证 AgentProfiling 数据无数据则标记未验证过程合规验证 Agent工具调用日志无日志则判定不合规这套闭环不是一次建成的是我在反复被 Agent 坑之后逐步补上的。每补一个环节Agent 的可靠性就上一个台阶。到后来我甚至敢让 Agent 在无人值守的情况下跑一整夜的算子生成和测试第二天早上看报告就行。5.6 一个具体的幻觉案例与修复说个真实的例子。早期我让 Agent 生成 RISC-V 向量指令的编码它给出了一条vadd.vv的编码opcode 写成了1010110少了一位。这个错误非常隐蔽因为1010110看起来也很像合法的 opcode。验证 Agent 比对规范数据库时发现了不一致打回重做。但生成 Agent 第二次还是错因为它觉得自己记得是对的。后来我改了提示词明确要求生成编码前必须先调用query_instruction_encoding并把返回结果原样粘贴到输出中再基于返回结果做后续处理。这个原样粘贴的要求很关键它让 Agent 无法绕过查询。改完之后这类错误基本消失了。6. 从零搭建这套 Agent 工作流的实操路径前面讲的是设计思路这一节讲怎么落地。我会给出一个从零开始的搭建路径包括环境准备、Agent 框架选型、提示词结构、工具封装、以及跑通第一个任务的完整步骤。这套路径是我实际用过的不是纸上谈兵。6.1 环境准备你需要什么先说硬件和基础软件。开发 RISC-V AI 芯片软件栈你至少需要一台开发机建议 32GB 内存起步因为编译 LLVM 和跑仿真都很吃内存。RISC-V 工具链可以从源码编译也可以用预编译版本。我建议从源码编译因为后面要改后端。一个 RISC-V 仿真器比如 QEMU 的 RISC-V 版本用于快速验证。如果手头有 FPGA 开发板可以跑真实的 RTL 仿真但初期用 QEMU 就够了。Python 环境用于写 Agent 的工具函数和测试脚本。Agent 框架方面选择很多。我试过几种最后稳定在一套基于函数调用的轻量框架上。核心要求是支持工具调用、支持多轮对话、支持结构化输出、支持日志记录。不需要太重的编排引擎因为软件栈开发的流程相对固定用代码显式编排反而更可控。6.2 提示词结构我用的四段式模板每个 Agent 的提示词我用四段式结构角色定义你是谁你的职责边界是什么你不做什么。知识范围你可以访问哪些规范、文档、代码库通过什么工具访问。工作流程接到任务后你的标准步骤是什么每步的输入输出是什么。输出规范你的产物格式是什么必须包含哪些字段禁止哪些行为。这个结构的关键是边界清晰。角色定义里明确不做什么比做什么更重要。比如算子生成 Agent 的提示词里写你不负责验证自己的输出验证由独立的验证 Agent 完成。你不得声称测试通过只能报告你执行了哪些操作。6.3 工具封装把命令行变成 Agent 能调用的函数Agent 调用工具本质是调用函数。你需要把常用的命令行操作封装成有明确输入输出的函数。我封装的核心工具包括compile_riscv(source, flags)编译 RISC-V 代码返回编译日志和产物路径。run_qemu(binary, args)在 QEMU 里运行返回输出和退出码。query_instruction_encoding(name)查询指令编码返回结构化数据。run_test_case(test_id)跑指定测试用例返回通过与否和详细结果。profile_kernel(kernel, input_shape)跑性能测试返回周期数和访存统计。每个工具函数都要有清晰的返回格式和错误处理。Agent 最怕的是工具返回一堆非结构化文本它解析不了就开始瞎猜。我的做法是工具统一返回 JSON包含status、data、error三个字段。6.4 跑通第一个任务生成一个向量加法算子理论讲够了跑一个具体任务。目标是让算子生成 Agent 生成一个 RISC-V 向量加法算子并通过验证。第一步准备算子定义。我写一个 YAML 文件描述算子name: vadd signature: void vadd(const float* a, const float* b, float* c, int n) semantics: c[i] a[i] b[i] for i in [0, n) constraints: - n 可能不是向量长度的整数倍 - 指针可能非对齐第二步算子生成 Agent 读取定义生成标量版本和向量版本。标量版本用于验证数学正确性向量版本用于性能。第三步验证 Agent 生成测试用例覆盖正常情况、边界情况n0、n1、n 非对齐、非对齐指针。跑测试比对结果。第四步如果向量版本失败验证 Agent 报告失败模式算子生成 Agent 根据报告迭代。这个任务我实测下来Agent 通常在两到三轮迭代内能跑通。第一轮常见的问题是尾部处理错误第二轮修正后基本能过。整个过程人工只需要审核最终代码中间迭代全自动。6.5 扩展到完整软件栈的路线图跑通单个算子之后可以逐步扩展先覆盖常见算子加法、乘法、卷积、池化、激活建立算子库基础。再接入图优化让 Agent 生成融合规则。然后接入编译后端让 Agent 辅助生成自定义指令的模式匹配。最后接入端到端模型部署跑一个完整的模型推理验证。每一步都要保持验证闭环不要因为赶进度跳过测试。我见过太多项目在后期因为早期跳过的测试而付出惨重代价。7. 踩过的坑与几条硬核经验这一节不讲理论只讲我实际踩过的坑和总结出的经验。这些内容在官方文档里找不到但每一条都是用时间和调试换来的。7.1 不要让 Agent 碰它验证不了的东西这是我用血换来的第一条经验。Agent 的能力边界不是由它的知识决定的而是由它能否验证自己的输出决定的。它能验证的就放手让它做它验证不了的就必须人工介入。具体到软件栈算子实现能验证跑测试比对数值所以可以放手编译后端改动能部分验证跑回归测试所以要半放手驱动时序逻辑难以自动验证需要硬件在环所以必须人工主导。我早期试图让 Agent 全自动改驱动结果芯片挂死好几次后来老老实实把这块收回人工。7.2 测试用例的质量决定 Agent 的上限Agent 生成的代码质量很大程度上取决于测试用例的质量。测试覆盖不到的地方就是 Agent 幻觉的温床。我后来养成了一个习惯先让 Agent 生成测试用例人工审核补充边界情况再让 Agent 生成实现。测试先行实现跟上这个顺序不能反。边界情况尤其重要。向量算子的尾部处理、非对齐访问、溢出、NaN 传播这些是 Agent 最容易出错的地方也是测试必须覆盖的地方。我通常会专门写一组刁钻的测试用例专门用来抓 Agent 的边界错误。7.3 提示词里的禁止比要求更有效我对比过两种提示词风格一种全是你要做什么一种包含大量你不要做什么。后者效果明显更好。原因很简单LLM 倾向于过度完成你让它生成代码它会顺便帮你优化、帮你加注释、帮你改接口结果偏离了原始需求。明确的禁止项能有效约束这种倾向。我的提示词里常见的禁止项包括不得修改函数签名不得引入未在依赖列表中的头文件不得声称测试通过不得凭记忆回答指令编码。每一条禁止项背后都是一次实际的翻车。7.4 日志是你的救命稻草多 Agent 系统出问题时如果没有详细日志你根本不知道发生了什么。我从项目一开始就强制所有 Agent 的工具调用、决策、产物都写日志日志按任务 ID 组织可以完整回溯。日志的另一个用途是训练和改进。我会定期分析日志找出 Agent 最常犯的错误然后针对性地改提示词或加验证规则。这个迭代过程持续了几个月Agent 的可靠性就是这样一点点磨出来的。7.5 人工审核的位置要选对全自动不是目标人机协作效率最大化才是。人工审核要放在代价最高、最难自动验证的环节。我的做法是算子实现自动验证人工只看最终报告编译后端改动人工审核 diff驱动代码人工主导Agent 只做辅助。这个分工不是固定的随着 Agent 可靠性的提升人工审核的范围可以逐步缩小。但缩小之前必须有足够的测试覆盖和日志证据支撑。7.6 一个关于性能优化的教训最后说个性能优化的教训。早期我让 Agent 做算子性能优化它给出的方案在微基准上确实快但接入完整模型后整体性能反而下降。原因是它只优化了单个算子没有考虑算子间的数据布局和内存复用。后来我调整策略性能优化必须在完整模型层面验证不能只看微基准。Agent 的优化建议要经过端到端测试确认整体收益后才采纳。这个教训让我明白局部最优不等于全局最优Agent 再聪明也需要正确的评价指标引导。8. 这个系列接下来会写什么这个系列不是一篇孤立的文章而是一条完整的实践路线。接下来我会按软件栈的层次逐篇展开每个环节的 Agent 应用细节。第二篇会聚焦规范解析 Agent讲怎么把 RISC-V 手册和硬件文档转成 Agent 可查询的结构化知识库包括文档解析、schema 设计、查询接口实现。第三篇讲算子生成 Agent从最简单的向量加法到复杂的卷积和注意力机制给出完整的生成-验证-迭代流程。第四篇讲编译适配 Agent重点是如何让 Agent 辅助 LLVM 后端的指令选择和寄存器分配以及怎么用回归测试兜住风险。第五篇讲验证 Agent包括测试用例生成、黄金参考比对、失败模式分类。第六篇讲端到端集成把前面所有 Agent 串起来跑通一个完整的模型推理。每一篇都会给出可复现的步骤、具体的提示词结构、工具封装代码和踩坑记录。我不会写成教科书而是写成一份工程日志——记录我实际怎么做的、为什么这么做、哪里做错了、后来怎么改的。如果你也在做 RISC-V 或者 AI 芯片相关的软件栈开发或者你正在探索 AI Agent 在专业领域的落地方式这个系列应该能给你一些直接可用的参考。我不敢说这套方法是最优的但它是我实际跑通并且还在持续迭代的。软件栈开发这件事没有银弹但有更聪明的干法。AI Agent 就是当下我能找到的、最值得投入的那个更聪明的干法。 AI Agent 如何啃下 RISC-V AI 芯片软件栈：多智能体分工与验证闭环实践
1. 为什么我要用 AI Agent 去啃 RISC-V 软件栈这块硬骨头RISC-V 和 AI 芯片这两个词放在一起本身就带着一种未来已来的张力。但真正动过手的人都知道从一颗 RISC-V 核到一块能跑 AI 推理的芯片中间隔着的不是一道沟而是一整片沼泽——这片沼泽就是软件栈。工具链、编译器后端、运行时、算子库、驱动、固件、模型部署框架每一层都能单独写一本书而它们之间的接口又极其挑剔错一个字节的对齐就可能让你在板子上看到一串毫无意义的乱码。我最初接触这个方向的时候想法很朴素既然 AI Agent 现在这么能写代码、能查文档、能自我纠错那能不能让它帮我把这套软件栈造出来注意这里的造不是让 Agent 凭空生成一个 GCC而是让它承担起胶水层、适配层、验证层的大量重复性智力劳动——这些恰恰是软件栈开发中最耗人、最容易出错、又最没有成就感的部分。这个系列导读要解决的就是怎么把 AI Agent 真正用起来这个问题。市面上讲 AI Agent 的文章要么停留在什么是 Agent、Agent 和 LLM 有什么区别这种科普层面要么直接跳到用 Spring AI 搭一个企业级 Agent 平台这种工程层面中间那段最关键的——Agent 如何在一个高度专业、强约束、有硬性正确性要求的领域里干活——几乎没人认真讲。RISC-V AI 芯片软件栈就是这样一个绝佳的试验场它有明确的规范RISC-V ISA 手册、ABI 规范、有可验证的正确性标准跑通测试用例、比对黄金参考、有大量结构化的重复工作指令编码、寄存器分配、算子映射同时又有足够高的门槛让 Agent 的幻觉无处遁形。适合读这个系列的人我大致画个像你最好对计算机体系结构有基本概念知道什么是 ISA、什么是流水线、什么是内存一致性你最好写过一点 C 或者汇编理解指针和寄存器不是玄学你最好对 AI Agent 有实际使用经验不是只看过 demo而是被它的胡言乱语坑过。如果你三者都具备那这个系列会让你少走至少半年的弯路。如果你只具备其中一两项也没关系我会在关键处补足背景但你要有心理准备——这不是一篇三分钟上手的爽文。先把这个系列的定位说清楚它不是 RISC-V 的入门教程也不是 AI Agent 的科普。它是一条工程实践路线讲的是我如何把 AI Agent 拆解成不同角色嵌入到 RISC-V AI 芯片软件栈的开发流程里让它在每个环节承担明确的责任并且用可验证的方式保证它不跑偏。整个系列会覆盖从工具链适配、算子库生成、到端到端模型部署验证的完整链路每一篇都会给出具体的 Agent 配置思路、提示词结构、验证方法和踩坑记录。2. 先厘清概念AI Agent、LLM、AI 模型到底谁是谁在动手之前必须先把几个被网络热词搅浑的概念理清楚。我见过太多人把AI Agent和大模型当成同义词用结果在设计系统时把该分层的东西揉成一团最后既不好调试也不好扩展。这一节我用最直白的方式把它们拆开并且说明在 RISC-V 软件栈这个场景里每一层各自扮演什么角色。2.1 LLM 是大脑但不是人LLMLarge Language Model大语言模型本质上是一个条件概率分布给定一段文本它预测下一个 token 最可能是什么。你熟悉的 DeepSeek、GPT 系列、Claude 系列、Qwen 系列都属于 LLM。它们的能力来自海量文本上的预训练表现为能续写、能翻译、能总结、能写代码但它们的局限也同样明显没有持久记忆、没有行动能力、不能主动获取新信息、无法保证输出的事实正确性。在 RISC-V 软件栈开发里LLM 能干什么它能读懂 RISC-V 规范文档的片段能根据指令描述生成编码表能把一段 C 代码翻译成汇编草稿能解释报错信息。但它不能自己去跑一遍编译器验证生成的编码对不对不能自己打开手册翻到第 300 页确认某个 CSR 的位域定义也不能在发现错误后自动重试。这些不能正是 Agent 要补上的。2.2 AI 模型是个更大的筐AI 模型这个词比 LLM 宽泛得多。一个做算子调度的强化学习策略网络是 AI 模型一个做指令级功耗预测的回归模型也是 AI 模型一个做缺陷检测的卷积网络还是 AI 模型。在 AI 芯片语境下AI 模型经常特指被部署到芯片上运行的那个神经网络比如一个量化后的 ResNet、一个 YOLO 变体、一个 Transformer 的某几层。这和作为开发工具的 LLM 完全是两码事但热词把它们混在一起导致很多初学者一头雾水。我在这个系列里会严格区分两种用法当我说AI 模型时默认指待部署到 RISC-V AI 芯片上的推理模型当我说LLM或大模型时指驱动 Agent 的语言模型。这个区分很重要因为前者是我们要处理的对象后者是我们使用的工具。2.3 Agent 是LLM 手脚 记忆 目标AI Agent 的核心定义我倾向于用一句话概括一个能感知环境、做出决策、执行动作、并根据反馈调整策略的自主系统。它和裸 LLM 的区别在于四个附加组件工具调用能力Agent 能调用外部函数或命令比如执行riscv64-unknown-elf-gcc、读取文件、查询数据库、运行测试脚本。记忆机制短期记忆保存当前任务的上下文长期记忆保存跨任务的经验和知识避免每次都从零开始。规划能力把一个大目标拆解成子任务序列并在执行过程中根据中间结果动态调整。反馈闭环执行动作后观察结果判断是否达成子目标失败则重试或换策略。把这四点映射到 RISC-V 软件栈开发上就非常具体了Agent 调用工具链编译代码、读取编译日志、根据报错修改源码、重新编译、跑测试用例、比对输出、记录成功或失败的修改模式。这一整套流程裸 LLM 做不了但 Agent 可以。2.4 一张表看清三者关系概念本质在 RISC-V 软件栈项目中的角色典型代表LLM文本概率模型提供语言理解与生成能力是 Agent 的大脑DeepSeek、GPT、Claude、QwenAI 模型广义的机器学习模型待部署到芯片上的推理负载量化 ResNet、YOLO、Transformer 层AI AgentLLM 工具 记忆 规划执行软件栈开发任务的自主工作单元基于上述 LLM 构建的编码/验证 Agent提示不要试图用一个 Agent 干所有事。软件栈开发涉及编译、验证、调试、文档、测试等多个性质差异极大的环节单一 Agent 的提示词会膨胀到无法维护。后面我会讲怎么按角色拆分。3. RISC-V AI 芯片软件栈到底包含哪些层要指挥 Agent 干活你得先知道活有哪些。很多人对软件栈的理解停留在编译器 驱动这在通用 CPU 上勉强够用但在 AI 芯片上远远不够。AI 芯片的软件栈是一条从模型到硅片的完整通路任何一层缺失或错位都会导致模型跑不起来或者跑得极慢。我按从上层到下层的顺序把这条通路拆开讲。3.1 模型层与图优化层最上层是模型本身通常来自 PyTorch、ONNX 或 TensorFlow。模型不能直接扔给芯片中间要经过图优化算子融合、常量折叠、死代码消除、布局转换。这一层的输出是一个经过简化的计算图算子数量减少、内存访问模式更规整。这一层 Agent 能帮上什么忙图优化规则往往是模式匹配 替换比如Conv BiasAdd ReLU 融合成一个 ConvReLU。这类规则数量多、形式重复非常适合让 Agent 根据已有规则模板批量生成新规则再由人工审核。我实测下来Agent 生成规则草稿的可用率大概在六成左右剩下四成需要修正但即便如此也比从零手写快得多。3.2 算子库与内核层图优化之后每个算子都要有对应的内核实现。在 RISC-V AI 芯片上这些内核可能跑在向量扩展单元上、可能跑在专用的矩阵加速器上、也可能回退到标量核。算子库的质量直接决定芯片的实际性能。这一层是 Agent 最能发挥价值的地方之一。原因有三第一算子实现有明确的数学定义正确性可验证第二不同算子之间有大量结构相似性Agent 可以举一反三第三性能优化有明确的指标周期数、访存次数Agent 可以根据 profiling 结果迭代。但要注意Agent 生成的向量化代码经常在边界处理上出错比如尾部元素、非对齐访问、溢出情况这些必须用测试用例兜住。3.3 运行时与调度层算子有了还需要一个运行时来管理内存、调度任务、处理同步。AI 芯片通常有多个计算单元运行时要把计算图切分、分配到不同单元、插入同步点、管理片上内存的分配与复用。这一层的逻辑复杂且高度依赖具体硬件Agent 在这里更多是辅助角色——帮你看懂硬件手册、生成配置模板、检查资源冲突而不是直接生成调度算法。3.4 驱动与固件层再往下是驱动和固件负责和硬件寄存器打交道。这一层对正确性要求极高一个位写错就可能导致芯片挂死。Agent 在这一层的使用要非常谨慎我通常只让它做两件事根据寄存器手册生成结构化的寄存器定义头文件以及把已有的驱动代码翻译成另一种风格。核心的时序逻辑和中断处理还是得人来写。3.5 工具链与编译后端贯穿所有层的是工具链。RISC-V 的工具链虽然成熟但针对 AI 扩展指令比如自定义的矩阵乘指令、向量指令往往需要自定义编译后端。这意味着你要改 LLVM 或 GCC 的后端添加指令选择模式、寄存器分配约束、调度模型。这是整个软件栈里门槛最高的部分也是 Agent 辅助价值最微妙的部分——它能帮你理解后端代码结构、生成模式匹配的草稿但后端改错的代价极高必须配合大量回归测试。3.6 各层与 Agent 适配度对照软件栈层次主要工作Agent 适配度建议使用方式模型层/图优化算子融合、图重写高批量生成优化规则草稿算子库/内核算子实现、向量化高生成实现 测试驱动迭代运行时/调度内存管理、任务调度中辅助理解硬件、生成配置驱动/固件寄存器操作、中断低仅生成头文件、翻译代码工具链/后端指令选择、寄存器分配中低辅助理解 草稿人工主导这张表是我踩了不少坑之后总结出来的。一开始我试图让 Agent 包办驱动层结果它生成的寄存器操作序列看起来头头是道实际跑起来直接把芯片送进了异常状态。后来我调整策略把 Agent 的权限按层收紧效率反而上去了。4. 把 Agent 拆成角色我的多智能体分工方案单一 Agent 干整个软件栈是我早期犯的最大错误。提示词越写越长最后变成一本几百页的操作手册Agent 在里面迷失方向经常在编译任务里突然开始讨论驱动寄存器。后来我改用多智能体分工每个 Agent 有明确的职责边界、专属工具集和输出格式整体效率提升非常明显。这一节讲我的分工方案和背后的设计逻辑。4.1 为什么必须分工上下文窗口是硬约束LLM 的上下文窗口再大也是有限的而且随着上下文增长模型对中间信息的注意力会衰减。软件栈开发涉及的知识面极广把 RISC-V 规范、LLVM 后端文档、算子数学定义、硬件寄存器手册全塞进一个 Agent 的上下文结果就是它什么都记得一点、什么都做不精。分工的本质是上下文隔离每个 Agent 只加载自己职责范围内的知识只保留自己任务的记忆。编译 Agent 不需要知道寄存器手册算子 Agent 不需要知道调度策略。这样每个 Agent 的上下文都保持精简决策质量显著提高。4.2 我的五个核心 Agent 角色经过反复调整我稳定下来五个角色覆盖软件栈开发的主要环节规范解析 Agent负责读 RISC-V ISA 手册、ABI 规范、硬件寄存器手册把非结构化文档转成结构化的查询接口。它的输出是指令编码表CSR 位域定义ABI 调用约定这类结构化数据供其他 Agent 调用。编译适配 Agent负责工具链相关任务包括编译报错分析、后端模式匹配草稿生成、编译选项调优。它的工具集包括编译器命令、日志解析器、回归测试脚本。算子生成 Agent负责根据算子数学定义生成内核实现包括标量版本和向量版本。它的工具集包括参考实现、测试用例生成器、正确性比对脚本。验证 Agent负责跑测试、比对结果、定位失败原因。它不生成代码只做验证和报告保持独立性避免自己写自己验的偏差。文档 Agent负责把开发过程中的决策、接口、坑点整理成文档供团队查阅。它的输入是其他 Agent 的执行日志和人工注释。这五个角色不是孤立的它们通过一个共享的任务队列和产物仓库协作。规范解析 Agent 产出的编码表编译适配 Agent 和算子生成 Agent 都能读取算子生成 Agent 产出的内核验证 Agent 负责测试验证 Agent 发现的失败模式反馈给对应的生成 Agent 迭代。4.3 角色之间的通信协议多 Agent 协作最容易出问题的地方是接口不一致。A Agent 输出的格式B Agent 读不懂整个流水线就断了。我的做法是强制所有 Agent 的产物使用结构化格式JSON 或 YAML并且为每类产物定义 schema。比如规范解析 Agent 输出的指令编码表schema 大致是这样{ instruction: vadd.vv, extension: V, encoding: { opcode: 1010111, funct3: 000, funct6: 000000 }, operands: [vd, vs1, vs2], description: 向量加法逐元素相加 }有了 schema下游 Agent 就能可靠地解析。我还会让验证 Agent 专门检查 schema 合规性不合规的产物直接打回不让它污染下游。4.4 一个真实的协作流程示例举个具体例子我要为芯片添加一条自定义的矩阵乘加指令mma.wv并让算子库支持它。整个流程是这样的规范解析 Agent 读取硬件手册中mma.wv的描述生成结构化编码定义和语义说明。编译适配 Agent 根据编码定义在 LLVM 后端生成指令选择模式的草稿并跑回归测试确认没有破坏已有指令。算子生成 Agent 根据语义说明生成矩阵乘加算子的内核实现先用标量版本验证数学正确性再替换为mma.wv指令版本。验证 Agent 跑算子测试用例比对数值结果与黄金参考报告误差和性能数据。文档 Agent 把整个流程的决策、代码、测试结果整理成文档。这个流程里人工介入的点主要是审核编译后端的改动和最终的性能调优其余环节 Agent 可以自主完成大部分工作。我实测下来一条新指令从手册到算子库可用周期从原来的一周多压缩到两三天。4.5 分工带来的一个意外好处分工之后我发现一个额外的好处故障定位变容易了。单一 Agent 出错时你很难判断是知识不足、工具用错还是规划失误。分工之后每个 Agent 的职责单一出错时能快速定位到具体环节。比如算子数值不对先看验证 Agent 的测试用例是否覆盖了边界再看算子生成 Agent 的实现是否有溢出再看规范解析 Agent 的语义理解是否有偏差。这种可定位性在复杂系统开发里比单纯的效率提升更宝贵。5. 让 Agent 不胡说验证闭环与幻觉抑制AI Agent 在 RISC-V 软件栈这种强正确性要求的场景里最大的敌人是幻觉。它会自信满满地生成一段看起来完全合理的指令编码实际上 opcode 位域全错它会声称某个算子已经通过测试实际上测试根本没跑。这一节讲我怎么构建验证闭环把幻觉压到可接受的范围。5.1 幻觉在软件栈开发中的三种典型表现我总结下来Agent 的幻觉在这个领域主要有三种事实性幻觉编造不存在的指令、错误的寄存器编号、错误的位域定义。这类幻觉最危险因为看起来最像真的。过程性幻觉声称执行了某个操作比如我已运行测试实际上没有调用工具或者调用了但忽略了失败结果。过度自信对不确定的事情给出确定性的结论比如这个优化一定能提升性能而不提供任何数据支撑。这三种幻觉的抑制策略不同但核心思路一致用外部可验证的事实约束 Agent 的输出。5.2 事实性幻觉的抑制以规范为唯一真相源事实性幻觉的根源是 Agent 在回忆而不是查询。LLM 的训练数据里可能有 RISC-V 规范的片段但不完整、可能过时、可能混淆不同版本。解决办法是切断回忆路径强制查询路径。我的做法是所有涉及指令编码、寄存器定义、ABI 约定的问题Agent 必须通过规范解析 Agent 提供的查询接口获取禁止直接凭记忆回答。查询接口背后是结构化的规范数据库数据来源是官方手册的解析结果。Agent 的提示词里明确写任何指令编码必须来自query_instruction_encoding工具的返回结果不得自行推断。这个约束执行起来需要一点技巧。Agent 有时候会偷懒明明有工具可用却直接回答。我的应对是在验证 Agent 里加一道检查如果产物里包含指令编码但执行日志里没有对应的查询调用直接判定为不合规打回重做。几次之后Agent 就学会了必须先查再答。5.3 过程性幻觉的抑制工具调用日志强制留痕过程性幻觉更隐蔽因为它涉及 Agent 的自我报告。Agent 说测试通过了你怎么知道它真的跑了测试我的做法是所有工具调用强制留痕并且验证 Agent 独立检查日志。具体来说每个 Agent 的工具调用都会写入一个结构化日志包含调用时间、工具名、参数、返回码、输出摘要。验证 Agent 在验收时不信任生成 Agent 的自我报告而是直接读日志。如果生成 Agent 说测试通过但日志里没有测试调用记录或者返回码非零直接判定失败。这个机制还有一个副作用它让 Agent 的行为变得可审计。出问题时我能回溯整个执行链路看到每一步的实际输入输出而不是只看 Agent 的总结。这在调试复杂问题时非常有用。5.4 过度自信的抑制要求提供证据链过度自信的抑制靠证据要求。我在提示词里规定任何性能声明必须附带 profiling 数据任何正确性声明必须附带测试用例和比对结果任何优化建议必须附带前后对比。没有证据的声明验证 Agent 一律标记为未验证不计入最终结论。这条规则执行初期Agent 的输出会变得很啰嗦到处贴数据。但习惯了之后它会自动筛选出真正需要证据的关键结论输出反而更精炼。更重要的是它逼着 Agent 在下结论之前先找证据这个思维链的转变是幻觉抑制的关键。5.5 验证闭环的整体架构把上面几点串起来我的验证闭环大致是这样环节负责方验证手段失败处理事实查询规范解析 Agent结构化规范数据库查询失败则拒绝回答代码生成编译/算子 Agent编译通过 单元测试失败则迭代或上报正确性验证 Agent黄金参考比对误差超阈值则打回性能验证 AgentProfiling 数据无数据则标记未验证过程合规验证 Agent工具调用日志无日志则判定不合规这套闭环不是一次建成的是我在反复被 Agent 坑之后逐步补上的。每补一个环节Agent 的可靠性就上一个台阶。到后来我甚至敢让 Agent 在无人值守的情况下跑一整夜的算子生成和测试第二天早上看报告就行。5.6 一个具体的幻觉案例与修复说个真实的例子。早期我让 Agent 生成 RISC-V 向量指令的编码它给出了一条vadd.vv的编码opcode 写成了1010110少了一位。这个错误非常隐蔽因为1010110看起来也很像合法的 opcode。验证 Agent 比对规范数据库时发现了不一致打回重做。但生成 Agent 第二次还是错因为它觉得自己记得是对的。后来我改了提示词明确要求生成编码前必须先调用query_instruction_encoding并把返回结果原样粘贴到输出中再基于返回结果做后续处理。这个原样粘贴的要求很关键它让 Agent 无法绕过查询。改完之后这类错误基本消失了。6. 从零搭建这套 Agent 工作流的实操路径前面讲的是设计思路这一节讲怎么落地。我会给出一个从零开始的搭建路径包括环境准备、Agent 框架选型、提示词结构、工具封装、以及跑通第一个任务的完整步骤。这套路径是我实际用过的不是纸上谈兵。6.1 环境准备你需要什么先说硬件和基础软件。开发 RISC-V AI 芯片软件栈你至少需要一台开发机建议 32GB 内存起步因为编译 LLVM 和跑仿真都很吃内存。RISC-V 工具链可以从源码编译也可以用预编译版本。我建议从源码编译因为后面要改后端。一个 RISC-V 仿真器比如 QEMU 的 RISC-V 版本用于快速验证。如果手头有 FPGA 开发板可以跑真实的 RTL 仿真但初期用 QEMU 就够了。Python 环境用于写 Agent 的工具函数和测试脚本。Agent 框架方面选择很多。我试过几种最后稳定在一套基于函数调用的轻量框架上。核心要求是支持工具调用、支持多轮对话、支持结构化输出、支持日志记录。不需要太重的编排引擎因为软件栈开发的流程相对固定用代码显式编排反而更可控。6.2 提示词结构我用的四段式模板每个 Agent 的提示词我用四段式结构角色定义你是谁你的职责边界是什么你不做什么。知识范围你可以访问哪些规范、文档、代码库通过什么工具访问。工作流程接到任务后你的标准步骤是什么每步的输入输出是什么。输出规范你的产物格式是什么必须包含哪些字段禁止哪些行为。这个结构的关键是边界清晰。角色定义里明确不做什么比做什么更重要。比如算子生成 Agent 的提示词里写你不负责验证自己的输出验证由独立的验证 Agent 完成。你不得声称测试通过只能报告你执行了哪些操作。6.3 工具封装把命令行变成 Agent 能调用的函数Agent 调用工具本质是调用函数。你需要把常用的命令行操作封装成有明确输入输出的函数。我封装的核心工具包括compile_riscv(source, flags)编译 RISC-V 代码返回编译日志和产物路径。run_qemu(binary, args)在 QEMU 里运行返回输出和退出码。query_instruction_encoding(name)查询指令编码返回结构化数据。run_test_case(test_id)跑指定测试用例返回通过与否和详细结果。profile_kernel(kernel, input_shape)跑性能测试返回周期数和访存统计。每个工具函数都要有清晰的返回格式和错误处理。Agent 最怕的是工具返回一堆非结构化文本它解析不了就开始瞎猜。我的做法是工具统一返回 JSON包含status、data、error三个字段。6.4 跑通第一个任务生成一个向量加法算子理论讲够了跑一个具体任务。目标是让算子生成 Agent 生成一个 RISC-V 向量加法算子并通过验证。第一步准备算子定义。我写一个 YAML 文件描述算子name: vadd signature: void vadd(const float* a, const float* b, float* c, int n) semantics: c[i] a[i] b[i] for i in [0, n) constraints: - n 可能不是向量长度的整数倍 - 指针可能非对齐第二步算子生成 Agent 读取定义生成标量版本和向量版本。标量版本用于验证数学正确性向量版本用于性能。第三步验证 Agent 生成测试用例覆盖正常情况、边界情况n0、n1、n 非对齐、非对齐指针。跑测试比对结果。第四步如果向量版本失败验证 Agent 报告失败模式算子生成 Agent 根据报告迭代。这个任务我实测下来Agent 通常在两到三轮迭代内能跑通。第一轮常见的问题是尾部处理错误第二轮修正后基本能过。整个过程人工只需要审核最终代码中间迭代全自动。6.5 扩展到完整软件栈的路线图跑通单个算子之后可以逐步扩展先覆盖常见算子加法、乘法、卷积、池化、激活建立算子库基础。再接入图优化让 Agent 生成融合规则。然后接入编译后端让 Agent 辅助生成自定义指令的模式匹配。最后接入端到端模型部署跑一个完整的模型推理验证。每一步都要保持验证闭环不要因为赶进度跳过测试。我见过太多项目在后期因为早期跳过的测试而付出惨重代价。7. 踩过的坑与几条硬核经验这一节不讲理论只讲我实际踩过的坑和总结出的经验。这些内容在官方文档里找不到但每一条都是用时间和调试换来的。7.1 不要让 Agent 碰它验证不了的东西这是我用血换来的第一条经验。Agent 的能力边界不是由它的知识决定的而是由它能否验证自己的输出决定的。它能验证的就放手让它做它验证不了的就必须人工介入。具体到软件栈算子实现能验证跑测试比对数值所以可以放手编译后端改动能部分验证跑回归测试所以要半放手驱动时序逻辑难以自动验证需要硬件在环所以必须人工主导。我早期试图让 Agent 全自动改驱动结果芯片挂死好几次后来老老实实把这块收回人工。7.2 测试用例的质量决定 Agent 的上限Agent 生成的代码质量很大程度上取决于测试用例的质量。测试覆盖不到的地方就是 Agent 幻觉的温床。我后来养成了一个习惯先让 Agent 生成测试用例人工审核补充边界情况再让 Agent 生成实现。测试先行实现跟上这个顺序不能反。边界情况尤其重要。向量算子的尾部处理、非对齐访问、溢出、NaN 传播这些是 Agent 最容易出错的地方也是测试必须覆盖的地方。我通常会专门写一组刁钻的测试用例专门用来抓 Agent 的边界错误。7.3 提示词里的禁止比要求更有效我对比过两种提示词风格一种全是你要做什么一种包含大量你不要做什么。后者效果明显更好。原因很简单LLM 倾向于过度完成你让它生成代码它会顺便帮你优化、帮你加注释、帮你改接口结果偏离了原始需求。明确的禁止项能有效约束这种倾向。我的提示词里常见的禁止项包括不得修改函数签名不得引入未在依赖列表中的头文件不得声称测试通过不得凭记忆回答指令编码。每一条禁止项背后都是一次实际的翻车。7.4 日志是你的救命稻草多 Agent 系统出问题时如果没有详细日志你根本不知道发生了什么。我从项目一开始就强制所有 Agent 的工具调用、决策、产物都写日志日志按任务 ID 组织可以完整回溯。日志的另一个用途是训练和改进。我会定期分析日志找出 Agent 最常犯的错误然后针对性地改提示词或加验证规则。这个迭代过程持续了几个月Agent 的可靠性就是这样一点点磨出来的。7.5 人工审核的位置要选对全自动不是目标人机协作效率最大化才是。人工审核要放在代价最高、最难自动验证的环节。我的做法是算子实现自动验证人工只看最终报告编译后端改动人工审核 diff驱动代码人工主导Agent 只做辅助。这个分工不是固定的随着 Agent 可靠性的提升人工审核的范围可以逐步缩小。但缩小之前必须有足够的测试覆盖和日志证据支撑。7.6 一个关于性能优化的教训最后说个性能优化的教训。早期我让 Agent 做算子性能优化它给出的方案在微基准上确实快但接入完整模型后整体性能反而下降。原因是它只优化了单个算子没有考虑算子间的数据布局和内存复用。后来我调整策略性能优化必须在完整模型层面验证不能只看微基准。Agent 的优化建议要经过端到端测试确认整体收益后才采纳。这个教训让我明白局部最优不等于全局最优Agent 再聪明也需要正确的评价指标引导。8. 这个系列接下来会写什么这个系列不是一篇孤立的文章而是一条完整的实践路线。接下来我会按软件栈的层次逐篇展开每个环节的 Agent 应用细节。第二篇会聚焦规范解析 Agent讲怎么把 RISC-V 手册和硬件文档转成 Agent 可查询的结构化知识库包括文档解析、schema 设计、查询接口实现。第三篇讲算子生成 Agent从最简单的向量加法到复杂的卷积和注意力机制给出完整的生成-验证-迭代流程。第四篇讲编译适配 Agent重点是如何让 Agent 辅助 LLVM 后端的指令选择和寄存器分配以及怎么用回归测试兜住风险。第五篇讲验证 Agent包括测试用例生成、黄金参考比对、失败模式分类。第六篇讲端到端集成把前面所有 Agent 串起来跑通一个完整的模型推理。每一篇都会给出可复现的步骤、具体的提示词结构、工具封装代码和踩坑记录。我不会写成教科书而是写成一份工程日志——记录我实际怎么做的、为什么这么做、哪里做错了、后来怎么改的。如果你也在做 RISC-V 或者 AI 芯片相关的软件栈开发或者你正在探索 AI Agent 在专业领域的落地方式这个系列应该能给你一些直接可用的参考。我不敢说这套方法是最优的但它是我实际跑通并且还在持续迭代的。软件栈开发这件事没有银弹但有更聪明的干法。AI Agent 就是当下我能找到的、最值得投入的那个更聪明的干法。