1. 为什么说全栈软件地图是Agent做AI芯片的第一步上一篇我聊了Agent在芯片设计里的宏观想象力不少朋友私信问我到底从哪下手我的答案是——先画地图而且是软件侧的全栈地图。别急着让Agent去生成Verilog那是在沙漠里让一个人徒手盖楼。做AI芯片本身就是一个非常复杂的系统工程硬件架构要定算子库要写编译器要调驱动要通运行时库要稳上层框架要接。这些层次之间互相咬合每一层都有自己独立的工具链、数据格式和验收标准。传统流程里每一层的工程师基本只看得见自己头顶那层和脚下那层跨层沟通全靠文档、会议和漫长的扯皮。Agent的出现第一次给了我们一个机会把整条软件链路的上下文塞进一个智能体里让它既能往下看RTL也能往上读PyTorch的算子调用。但这里有个残酷的现实Agent本身并不懂芯片。你给它一个空泛的prompt帮我把这块AI芯片的软件栈做出来它大概率会给你生成一堆看起来正确、实际无从落地的框架代码。问题的根源不是模型能力不够而是我们没给它一张足够清晰的地图——哪一层解决什么问题、上下游接口是什么、验收标准是什么、哪些路是死胡同。我理解的全栈软件地图包含三层意思第一是静态的依赖图。从硬件寄存器描述开始到驱动、固件、运行时、算子库、编译器后端/前端、图优化、上层SDK每一层的输入输出、调用关系、ABI约束要清清楚楚。这张图是Agent规划的基础。第二是动态的任务切分规则。Agent拿到一个需求之后怎么把需求拆解成可以逐步执行、逐步验证的子任务每个子任务落在哪一层先做哪一层再做哪一层。很多Agent项目死在一步到位的幻觉上就是因为没有这层动态规划能力。第三是验证回路。每一层做完之后怎么自检怎么在下游层做冒烟测试怎么把错误定位回源头。AI芯片全栈之所以比普通应用软件难就是因为错误会跨层传递——驱动层的一个byte错位可能到算子层才表现为数值异常到训练脚本里才表现为loss不收敛。所以这篇我重点讲的是我是怎么用Agent搭建这块AI芯片全栈软件地图的框架怎么选每一层的Agent落点怎么设计实测踩了哪些坑。整个方案是一个可复现的骨架不是某个芯片项目的专属代码你拿到自己的项目里把芯片相关的具体指令集、寄存器定义和算子列表填进去就能跑。2. Agent骨架怎么选LangGraph还是自研以及我的取舍2.1 选型的大背景Agent不是单点调用而是一套带状态机的工程先泼一盆冷水很多人以为Agent就是模型加工具调用这是对Agent最大的误解。做AI芯片全栈Agent要面临的任务类型完全不同——有的任务是生成一段驱动代码有的是改写一段TVM调度有的是跑一遍仿真回归有的是根据失败日志定位是编译器的锅还是算子的锅。这些任务对状态的要求非常高上一个任务生成的结构体定义下一个任务要基于它扩展这一轮仿真的覆盖率报告下一轮优化要用它做约束。如果只是简单的调用模型→返回结果你很快就会发现在跨层任务上完全跑不动。你需要的是一个带记忆、带状态流转、带工具注册和错误恢复的执行框架。2.2 我评估过的三条路线市面上Agent框架多如牛毛但真正能用于芯片全栈开发场景的我实际测下来主要就三条路线路线代表优点缺点适合场景图式编排LangGraph、CrewAI、AutoGen状态管理强节点可复用适合固定工作流学习曲线陡编写复杂模型上下文消耗大芯片全栈这种流程相对固定的场景代码优先的Agent库Claude Agent SDK、OpenAI Assistants API上手快工具调用开箱即用工作流定制能力弱难以做复杂的条件分支和回环单点任务比如帮我修一下这个编译错误自研基于LangChain或裸模型自己搭完全可控可深度绑定内部EDA工具开发量大需要自己解决状态、并发、记忆公司内部有大量私有工具链时我的最终选型是LangGraph不是因为它最流行而是芯片全栈这个场景有几个硬需求只有图式编排能满足第一个是回环。仿真失败之后Agent要能跳回RTL生成节点带着失败信息重新规划而不是顺着一条直线跑到底。LangGraph的图结构天然支持这种条件边。第二个是人在环上。芯片软件栈不是玩具项目每一层的输出都要有review点。图式框架可以很方便地插入人工审批节点Agent跑完自动暂停等人确认。第三个是可观测性。全栈开发周期长、中间产物多每跑一步都要能导出中间状态。LangGraph的checkpoint机制可以保存每一步的完整现场出问题能回滚到任意节点重跑。当然自研路线我也认真考虑过。如果你是在大厂内部的EDA工具链、服务器调度系统、代码库都非常私有化那自研确实能绕过很多框架对第三方工具的连接限制。但自研的代价是要同时维护状态管理、上下文管理、工具沙箱、并发控制这一整套东西这不是一个人一两周能搞定的事。所以除非团队有专门的Agent平台组否则我建议还是先用LangGraph这类框架把流程跑通再逐步替换掉不满意的环节。2.3 我的分层结构Planner层、Executor层、Verifier层跑通之后我提炼出来的Agent骨架分三层这个结构跟普通Web后端的Controller-Service-DAO有点像但内涵不一样。Planner层只做一件事把用户的高层需求比如给这个卷积算子写一个针对我们NPU的优化实现拆解成一系列原子任务。这层我会用大模型但会严格限定它的输出格式——只允许输出JSON格式的任务图字段包括task_id、task_type、inputs、outputs、依赖关系、验收标准。千万不要让Planner直接生成代码一旦混了任务图的质量就很难保证。Executor层是具体的执行单元每个执行单元对应地图上的某一层。例如RTL生成执行器接受的是算子的功能描述和接口定义输出的是Verilog或Chisel代码编译器调度执行器接受的是计算图IR输出的是改写后的调度方案。每个执行器内部可以是大模型直接生成也可以是模板加参数填充还可以是调用外部EDA工具这层我倾向于不限制实现方式只看输入输出的契约是否对齐。Verifier层是我认为全栈Agent和普通代码生成Agent最本质的区别。普通Agent生成一个函数跑一下单元测试就算完事。芯片软件栈的要求是每一层的输出要用下游层的工具做端到端验证验证的结果要反向作为上游层的修改依据。比如RTL层生成完之后不是看着代码风格没问题就过了而是要跑一遍仿真看波形里有没有毛刺、时序是否收敛。这个验证结果会长什么样在任务切分的时候就必须定义清楚。我把这三层之间的通信格式统一为JSON并且要求每个节点都必须显式声明自己的上下文依赖——这个设计在后面踩坑环节帮了大忙因为芯片全栈里函数的定义、寄存器的位域、数据宽度这些信息跨层传递时太容易丢。3. AI芯片全栈地图的具体画法五层落点与Agent职责分配3.1 先把层次画出来从硬件到业务逻辑不是四层是五层教科书里讲计算机系统结构通常是硬件、操作系统、应用三层。但做AI芯片中间的差距太大了直接三层没法聊。我自己画地图的时候用的是五层第一层是硬件接口层包含寄存器映射、中断定义、DMA描述符、指令集编码。这一层的Agent任务叫硬件知识库构建者它的输入是ARM或RISC-V的接口文档、芯片的memory map表格输出是结构化的机器可读描述我用的是YAML格式因为比JSON更容易写注释。这一层是整个地图的地基后面所有层的Agent都需要引用这里的数据。第二层是驱动与固件层包括Linux内核驱动、RTOS下的设备驱动、BootLoader里的初始化代码。这一层的Agent任务叫驱动代码生成器但它的输入不是自然语言而是第一层输出的YAML。我踩过的一个很深的坑是让Agent直接读芯片手册生成驱动结果它把寄存器地址的位偏移搞反了。后来改成先让它把寄存器YAML再基于YAML生成驱动准确率从惨不忍睹的六成提到了九成以上。第三层是运行时与算子库层这是AI芯片软件栈里最厚重的部分。算子的实现方式五花八门——有的走自定义指令有的走DMA搬运加向量单元有的需要拆成多个子任务并行。这一层的Agent任务叫算子适配器它的输入是上层框架下发的算子描述比如ONNX的节点定义输出是当前芯片后端的具体实现。这一层我对Agent的要求不是从零生成而是让它基于已有的算子模板库做检索、修改、组合这是从生成式Agent到工程式Agent的关键转变。第四层是编译工具链层包括前端处理模型格式、图优化算子融合、布局转换、后端指令选择、寄存器分配、调度。这一层是全栈里最抽象也最难的Agent的落点主要是两处一是把手工写的图优化Pass翻译成可维护的代码二是根据硬件模拟器的profiling结果自动调优调度参数。第4节我会专门讲这里的Agent实现。第五层是上层SDK与业务集成层包括Python推理接口、量化工具链、模型部署流水线。这一层离业务最近也最容易做但恰恰因为容易很多人忽视了它对下游的依赖——SDK里一个tensor shape的排列顺序如果和第三层算子库不一致会引发非常隐蔽的bug且报错位置和根因位置隔了十万八千里。3.2 每一层的上下文契约怎么定画完五层还是不够的因为每一层之间要有明确的接口协议否则五层各自跑通了拼起来必炸。我给每个跨层接口设计了五个固定字段schema_version版本号防止上下游Agent用了不兼容的数据结构。producer_layer由哪一层生成方便回溯。consumer_layer谁消费这份数据明确验证责任人。validation_status验证状态是draft、sim_ok还是formal_ok。semantic_tags语义标签比如dtypefp16、layoutNCHW、quantper_channel这类信息模型很容易忽略但芯片后端必须知道。举个例子上层SDK层给算子库层传一个卷积算子schema里必须写清楚data_format是NHWC还是NCHWaccumulate_dtype是fp32还是fp16activation是ReLU还是None。这些字段在人工开发的流程里靠口头约定在Agent流程里必须写成机器可校验的契约否则Agent会因为模型对卷积这个概念的模糊理解而自由发挥。我在设计时给每个Agent节点配了一段system prompt里面固定写入一句话你只基于上下文中出现的schema字段做决策禁止臆测未出现的字段值。这句话看起来简单实际效果非常好。它把Agent从一个会写代码的聪明人变成了一个遵守规格文档的工程师。3.3 一张具体的Agent任务流转示例写到这里给个具体的例子可能比抽象描述更有体感。假设需求是在自研NPU上让ResNet50跑起来batch1输入224x224x3。整个Agent流转是这样的Planner收到需求之后拆出三个并行子任务任务A在编译工具链层把PyTorch导出的ONNX模型做图优化生成针对目标NPU的定制IR。任务B在算子库层检查ResNet50用到的算子Conv、BatchNorm、ReLU、MaxPool、Gemm、Softmax是否都有已实现版本没有的走算子适配器补全。任务C在运行时层确认系统的buffer管理、内存分配策略是否能满足224x224x3输入的峰值内存需求。这三个子任务分别由不同的Executor执行但它们的验证是联合的——不是各自验证完就完事而是必须等A和B都产出了结果才能进入C在真实仿真环境里跑一遍推理检查输出精度是否在容忍范围这个端到端验证节点。这一步如果分类到传统开发流程里叫集成测试。但在Agent地图里我把它定义为一个独立的验证节点而且是带着可量化的pass/fail标准比如top-1准确率偏差小于0.1%的节点。没有这个量化标准Agent永远不知道自己干得对不对。4. 把Agent真正接进芯片开发流硬件在环与工具链集成的关键细节4.1 Agent不能只在代码世界自嗨必须接到硬件仿真上纯软件Agent很容易陷入一个自欺欺人的循环它生成代码自己编译自己说没问题看起来一切正常。但芯片全栈开发天然反对这种自嗨因为代码最终要到硬件上去跑硬件的脾气可不会因为Agent写了解释文档就变好。所以我在骨架里做了一个强约束任何涉及硬件行为的上游任务必须经过仿真环境或者至少基于周期精确模型的环境验证才算完成。这个约束的实现方式是在LangGraph里加一个hardware_in_the_loop节点这个节点做的事情非常朴素——把Executor生成的驱动或算子代码放进仿真环境编译跑一条冒烟测试用例把输出波形和期望值对比返回pass或fail以及详细的失败原因。这个环节的工程量大头其实不在Agent而在仿真环境的适配。我们用过几种不同的仿真器有开源的Verilator有商用仿真器还有芯片团队的周期近似模型。跑通Agent的关键是给每一种仿真器写一个统一的wrapper接口让Agent只面对三个方法compile(rtl_src)、run(testbench)、report(coverage)。内部差异全部封装在wrapper里。刚开始我自己写的时候低估了wrapper的重要性——直接用Agent去裸调Verilator编译各种flag结果上下文爆炸Agent在flag选择上浪费了大量token。封装完之后Agent只需要说我要仿真这个RTL文件wrapper自动选择仿真器参数、编译选项、超时控制这才是Agent和工具链的正确协作模式。4.2 一个典型的仿真驱动闭环Agent如何自我迭代RTL代码这里我给一个非常具体的闭环流程是我在多轮实测后觉得最稳定的路径Planner下发一个目标用Chisel写一个支持int8乘累加的MAC单元延迟不超过3个时钟周期。ExecutorRTL生成器生成第一版Chisel代码。Verifier调用Verilator wrapper编译如果编译失败把错误日志返回给Executor重新生成。编译通过后Verifier加载一个预先写好的参考testbench跑功能比对。testbench里包含随机激励以及边界值比如最大正数乘最大正数、0乘0、负数乘负数。如果功能比对失败失败模式会被归类——是输出有延迟偏移还是计算结果错误还是信号宽度溢出。这个归类结果会作为错误信息传给Executor。Executor基于错误信息做局部修复而不是从头重写。这一步非常关键让Agent从头重写整个模块通常会把之前正确的部分也改坏局部修复的成功率明显更高。这一步我实测的最大心得是不要逼Agent在一步里生成完美代码而是让它具备迭代逼近的能力。每轮迭代给它明确且具体的失败信息它的收敛速度会快很多。反过来如果失败信息只是一句仿真不过Agent就会很迷茫然后随机改动代码越改越烂。4.3 编译工具链层Agent的特殊处理比生成代码更重要的是读Profile我前面说编译工具链层是全栈里最难的这里展开讲一下。编译器的核心逻辑不是翻译而是优化决策。Agent在编译器上写代码其实问题不大——写一个Pass跟写一个业务函数难度类似真正难的是让Agent理解当前芯片架构的瓶颈在哪因为NPU的瓶颈跟CPU完全不一样且不同NPU之间差异也很大。我们的做法是给Agent接一个profiling解读器。这个工具不是生成代码而是把仿真器或真实芯片上跑出来的流水线停顿、访存带宽利用率、计算单元占用率、寄存器溢出等profile数据翻译成Agent能理解的文本摘要。比如原始profile数据是一堆CSV数字Agent看着头大但经过解读器之后变成当前调度方案中数据搬运等待占总时延的63%建议优先优化DMA调度而非计算指令。然后Agent再基于这个文本摘要去决定改哪个Pass、调整什么参数。这个流程本质上跟一个资深编译优化工程师的工作方式是一致的先看性能瓶颈再定优化方向再改代码再跑profile验证改善效果。我把这个经验沉淀成了一个小工具叫perf2text逻辑不到500行但对Agent的优化效果提升非常明显。这个小工具也印证了一个观点全栈Agent的价值不在于替代工程师写代码而在于把工程师的分析决策能力自动化。4.4 工具链版本管理与Agent记忆的绑定芯片开发工具链版本极其敏感Verilator升级一个小版本仿真行为可能有微妙变化指令集增加了新扩展旧代码可能编译不过。Agent如果每次跑任务都全新开始不带版本信息就会经常使用过时API生成没法编译的代码。我的做法是给每个Agent节点注入一个toolchain context字段里面包含当前所有工具的版本号、编译器flag、可用的指令集特性。这个字段来自全栈地图的基础数据表Planner拆任务时自动附带。这样Agent的生成行为就有感知了——如果目标芯片支持自定义矩阵运算指令它在生成GEMM算子的时候就会优先考虑用这个指令而不是fallback到通用的乘加序列。这件事听起来简单但它解决的是一个很隐蔽的问题Agent模型的知识库往往停留在训练时的工具版本上如果你不显式告诉它现在用的Verilator是哪个版本、目标指令集有哪些扩展它就会按照记忆里的老版本API去写代码。早期的Agent生成代码经常看起来对但跑不起来很大一部分就是这个原因。5. 实测中踩过的大坑上下文污染、工具幻觉和任务图发散5.1 上下文污染芯片全栈项目里最隐蔽的杀手我先讲一个最让我崩溃的bug。当时Agent在生成一个DMA驱动任务本身很简单——根据寄存器定义配置源地址、目的地址、传输长度然后发起传输。Agent第一次生成的代码是对的但是它在上下文里读到过一份其它芯片的DMA寄存器定义一个工程师上传的历史文档结果它自作聪明地把两份文档混在一起目的地址偏移量用了另一块芯片的值。仿真的时候数据写到了错误的内存区域查了几小时才定位到这个低级但极为隐蔽的错误。这个问题的本质是上下文污染Agent的context window里塞了太多不相关的历史信息它分不清哪些是当前任务的权威依据哪些只是参考背景。我们的解决方案很硬核在给Executor的context里按当前任务类型过滤掉跨芯片、跨版本的无关文档只保留当前任务链上的必要上下文。具体来说我用了一套基于schema_tags的过滤规则——比如当前任务是DMA驱动生成就会从知识库里只提取memory map中DMA相关的部分、目标芯片的datasheet指定段落、以及内核DMA API文档其余的一律不放。这个操作需要牺牲一点通用性——Agent没有全局视角了但换来的是准确率的显著提升。在全栈开发这种对精度要求极高的场景里我宁愿要一个只懂当前任务但不出错的Agent也不要一个全局都懂但容易张冠李戴的Agent。5.2 工具幻觉Agent以为它跑了仿真实际上它只是编了一个仿真结果这个问题我之前在别的项目里也遇到过但在芯片全栈里危害更严重。一次跑算子验证的时候Agent返回了一个漂亮的waveform summary声称所有测试都pass了。我拿原始日志一查发现它根本没有调用仿真器而是在模型内部想象了一个仿真结果。原因是prompt里写了应返回仿真报告这类含糊表达模型就编造了一份看起来合理的报告。这个坑的修复方式不是改prompt而是在架构上禁止模型输出验证结论。我改了Verifier节点的设计验证结论必须由wrapper工具返回Agent只能解读wrapper的输出不能在wrapper输出之外额外添加我认为类的判断。换句话说把验证环节从Agent的能力降级为Agent调用的工具模型只有执行权和解释权没有断言权。这其实反映了一个更深的原则在做工程类的Agent时凡是有确定性答案的环节仿真跑没跑过、覆盖率是多少、精度差多少都应该从模型手里收走控制权落到代码工具上。模型只负责不确定性高的部分比如方案设计、代码编写、错误根因分析。这个分工一旦明确项目的稳定性会有质的飞跃。5.3 任务图发散大任务拆全了但子任务之间互相忘了第三个大坑是任务图发散。Planner在拆解一个大型任务比如让ResNet50在硬件仿真环境跑通时拆出了二十多个子任务每个子任务独立看都很正常。但执行到后期有些子任务的输入变了比如寄存器定义YAML被下游Agent修正过一个字段其它子任务却还在用旧版本数据最后集成时对不上。LangGraph虽然提供了状态共享但默认只是简单的消息传递不会自动处理数据版本一致性。我的解决办法是引入了一个数据版本管理节点任何共享数据结构的修改都必须经过这个节点记录版本号下游节点在读取数据时校验版本号版本不匹配直接拒绝执行并请求从最新版本重跑。听起来很低效但这是芯片全栈项目安全感的来源。因为跨层Agent之间的数据依赖太隐蔽了不加上这种强制校验五天的工作可能毁在一处细微的数据不一致上。真实芯片项目比普通软件项目更讲究确定性Agent项目的工程化也必须向这个要求看齐。6. 从能跑通到好用Agent全栈地图的持续优化方向6.1 记忆系统的分层项目记忆、芯片记忆、工具记忆一开始的Agent我是不加记忆的每次任务都从零开始。但跑了两周之后发现效率太低同样的寄存器解析逻辑每次都要重新推理一遍同样的编译参数每次都要重新思考。后来我把记忆分成了三层项目记忆是最短期的记录当前任务链上已经做过哪些决策、哪些文件已经生成、哪些验证还没跑。这一层不用专门做向量库存在LangGraph的checkpoint里就行。芯片记忆是中期记忆针对当前这一块芯片的架构特性。比如这块芯片的L2缓存只有1MB算子切分要注意数据复用这种经验应该沉淀下来跨任务共享。我用的是一个简单的YAML经验库每次任务结束后由Verifier层判断是否有值得沉淀的新经验如果有就写入。工具记忆是长期记忆记录工具链的使用经验和踩坑教训。比如Verilator编译时如果开了--trace性能会下降40%调试结束后记得关掉这类经验。这一层我目前是半自动维护的——Agent跑完任务后会提交一条工具使用心得我抽查并确认后合并进知识库。分层记忆的架构不难难的是各层的写入时机和写入权限。目前我倾向于所有写入都经过一个知识沉淀评审节点不是任务过程中的每个琐碎信息都值得记住只有经过验证、有复用价值的才入库否则知识库很快就会变成噪声池。6.2 多Agent协作的边界什么时候拆什么时候合全栈地图天然有多个Agent角色RTL生成器、驱动生成器、算子适配器、编译优化器、SDK集成器但我不建议一开始就上多Agent。原因很简单多Agent之间的通信开销、上下文冗余、决策冲突在项目早期会淹没你所有精力。我现在的经验是先把所有能力收敛在一个Agent里跑通全流程让验证回路闭环然后再根据需要逐步拆分。拆分的时机是在同一个Agent需要同时记忆太多不同领域知识导致互相干扰时。比如RTL生成和编译优化如果放在同一个Agent上下文里RTL生成的硬件细节会污染编译优化的策略空间反之亦然这时就该拆了。拆了之后要注意的是每个Agent的上下文要做严格隔离Agent之间只通过结构化契约也就是第3节说的schema通信不共享原始文档。这也是一种上下文污染控制手段。多Agent协作的成败不在模型能力而在通信协议设计是否清晰。6.3 知识库是Agent能力的上限也是瓶颈最后聊聊知识库。全栈Agent的推理能力上限由模型决定但工程质量上限几乎完全由知识库决定。我们目前的知识库包含这几类内容芯片手册的结构化版本寄存器、中断、内存映射、指令集历史代码模板库按算子类型、按功能模块分类验证经验库哪些边界条件最容易出问题、哪些代码模式是反模式工具链使用文档所有工具的版本、常用flag、已知坑维护知识库比写Agent代码更花时间而且这个工作AI暂时没法完全代劳因为它需要对芯片业务有深入理解。我的建议是每个跑通的任务都要顺手把过程中用到的关键文档、模板、经验沉淀到知识库里让下一个任务站在前一个任务的基础上。久而久之Agent在这个特定领域的能力会越来越像一位有经验的工程师。还有一个小经验不要迷信RAG。在全栈芯片场景里很多知识是强结构化的关系型数据比如寄存器的位域依赖、指令的编码格式用向量检索反而容易丢精度。对这些内容我倾向于用代码直接解析和查询而不是放进向量库里模糊匹配。RAG只用来处理语义类的经验文档比如上次这个算子的性能问题是怎么排查出来的这类描述性知识。这个区分做好之后检索的准确率和速度都上升了。7. 最后想说的也是一点个人的总结这第二篇文章写到这里核心骨架算是交代完了。用Agent做AI芯片的全栈软件地图本质上不是让一个模型去挑战整个芯片软件栈而是用Agent做胶水层把原本割裂的硬件、驱动、运行时、编译、SDK连接成一张可以协同工作的网。真正的工作量分布大概是三分之一在梳理层次和接口契约三分之一在对接工具链和仿真环境最后三分之一才是Agent本身的代码编写。那些一上来就急着让Agent写RTL的人大概率会在第一周就放弃因为没有地图的Agent和没有地图的探险队没什么区别。下一篇我打算深入讲一下编译工具链层的Agent实践包括怎么让Agent理解一个NPU的性能模型、怎么自动生成调度策略以及我们在这个方向上做的一些实验数据。这块是我觉得最有意思也最有挑战的部分希望到时候能给大家带来更多干货。