NVIDIA ACE-RTL 论文精读RTL 专用模型进入 Agent 闭环为什么能把 Spec-to-RTL APR 推到 96.15%1. 论文信息来自哪里应该怎么引用1.1 基本信息1.2 BibTeX 引用1.3 中文参考文献写法2. 这篇论文到底在解决什么问题路线一训练一个“懂 RTL”的专用模型路线二让通用大模型进入 Agent 闭环ACE-RTL 的核心问题3. 论文结构怎么组织4. ACE-RTL 的核心创新点创新一第一次把 RTL 专用模型放到“持续迭代”的 Agent 核心位置创新二训练数据直接对齐 Agent 在真实循环中的动作创新三把 Agent 的核心从“多角色编排”转向“上下文演化”创新四用多条随机调试轨迹并行换取更短的首次成功时间5. 方法详解Generator、Reflector 和 Coordinator 如何协同5.1 Generator真正负责 RTL 生成和修复的专用模型5.2 Reflector不直接写代码而是把失败解释清楚5.3 Coordinator全文最关键、也最容易被低估的组件5.4 三个组件为什么能够真正接起来6. 方法如何支撑创新点7. 实验设计作者如何证明 ACE-RTL 有效7.1 为什么选择 CVDP而不是只看 VerilogEval7.2 对比对象是否足够强7.3 主结果完整 ACE-RTL 到底提升了多少8. 消融实验真正贡献最大的组件是谁8.1 只有仿真反馈也会提升8.2 最大增益来自 Coordinator8.3 Restart 不是可有可无8.4 专用 Generator 和上下文演化是互补的9. 两个案例Agent 是如何从“反复失败”走向正确的9.1 案例一64b/66b Decoder9.2 案例二Clock Jitter Detection10. Parallel Scaling五路并行为什么只增加了 1.12 倍 Token11. VerilogEval 结果说明了什么12. 这篇论文有哪些局限12.1 目前验证的是功能正确性不是完整 FPGA 工程闭环12.2 论文没有处理 testbench 生成12.3 不使用波形使细粒度时序 Bug 仍然困难12.4 训练和部署成本并不低12.5 合成数据质量仍然存在不确定性12.6 APR 不能被当成单次准确率13. 对 RTL Agent 和 FPGA 工具开发有什么启发启发一训练或提示设计必须覆盖 Agent 的真实动作空间启发二不要把原始日志直接塞回模型启发三Agent Memory 不是聊天记录而是可执行的工程历史启发四Restart 应该是正式控制策略启发五并行搜索不是简单多开几个进程启发六功能通过只是第一道门14. 最终评价这篇论文最值得记住的是什么参考文献先说结论ACE-RTL 最值得关注的并不是简单地“再训练一个更懂 Verilog 的模型”而是把RTL 专用模型、通用推理模型、仿真反馈和跨轮次上下文真正接成了一个闭环。它提出了一个很有工程味的观点Agent 的能力不只取决于模型够不够强还取决于系统能否把每一次失败整理成下一次修改真正用得上的上下文。1. 论文信息来自哪里应该怎么引用1.1 基本信息论文标题ACE-RTL: When Agentic Context Evolution Meets RTL-Specialized LLMs作者Chenhui Deng、Zhongzhi Yu、Guan-Ting Liu、Nathaniel Pinckney、Brucek Khailany、Haoxing Ren研究机构NVIDIA论文来源arXiv 预印本arXiv 编号arXiv:2602.10218主要分类Computer Science - Hardware Architecturecs.AR交叉分类Machine Learningcs.LG论文主页https://arxiv.org/abs/2602.10218PDFhttps://arxiv.org/pdf/2602.10218DOIhttps://doi.org/10.48550/arXiv.2602.10218目前能够确认的是这是一篇发布在 arXiv 上的预印本。论文正文并未标注已被某个会议或期刊接收因此在介绍时更稳妥的写法是“来自 NVIDIA 研究团队的 arXiv 论文 ACE-RTL”1.2 BibTeX 引用misc{deng2026acertl, title {ACE-RTL: When Agentic Context Evolution Meets RTL-Specialized LLMs}, author {Chenhui Deng and Zhongzhi Yu and Guan-Ting Liu and Nathaniel Pinckney and Brucek Khailany and Haoxing Ren}, year {2026}, eprint {2602.10218}, archivePrefix {arXiv}, primaryClass {cs.AR}, doi {10.48550/arXiv.2602.10218} }1.3 中文参考文献写法DENG C, YU Z, LIU G T, et al. ACE-RTL: When Agentic Context Evolution Meets RTL-Specialized LLMs[EB/OL]. arXiv:2602.10218, 2026. DOI:10.48550/arXiv.2602.10218.2. 这篇论文到底在解决什么问题过去几年LLM 生成 RTL 大致形成了两条路线。路线一训练一个“懂 RTL”的专用模型这类工作会使用 Verilog、SystemVerilog、设计说明和代码推理数据对模型进行微调例如 RTLCoder、CraftRTL、OriGen、ScaleRTL。优势很直接更熟悉 RTL 语法更容易掌握时序逻辑、状态机、握手协议等硬件语义模型规模可以明显小于前沿通用大模型。但问题也很明显很多 RTL 专用模型主要训练的是Specification → RTL也就是“读需求然后第一次把代码写出来”。真实工程中的 Agent 却不只做第一次生成。它还要读已有代码 → 根据新需求修改 → 根据仿真错误定位问题 → 修复上一轮生成的 Bug → 再次验证如果训练阶段只学过“从零生成”推理阶段却要求模型“持续编辑和调试”训练任务和 Agent 行为之间就会出现明显错位。路线二让通用大模型进入 Agent 闭环另一条路线是使用 GPT、Claude 等通用大模型接入模拟器、波形分析器和多 Agent 编排让模型根据验证结果反复修改 RTL。VerilogCoder 和 MAGE 就属于这一方向。这类方法的优势是长上下文能力强多步推理和指令遵循更好能够读取工具日志并规划下一步动作。但它们缺少从大规模 RTL 数据中学到的专门硬件知识。遇到复杂时序、协议细节、状态转移和边界条件时通用推理能力并不一定能够替代领域训练。ACE-RTL 的核心问题因此这篇论文真正提出的问题是能不能让 RTL 专用模型负责“写和改”让前沿通用模型负责“分析和组织”再通过一个持续演化的上下文把两者连接起来图片来自原文这也是 ACE-RTL 的切入点它不是在两条路线中二选一而是尝试把两者的优势拼到同一个 Agent 循环中。3. 论文结构怎么组织这篇论文只有 7 页但结构非常紧凑基本按照“问题—方法—证据—局限”展开。章节主要内容在论证链中的作用Introduction两类既有路线及其互补缺陷定义研究问题并给出统一框架的动机BackgroundRTL 专用模型、RTL Agent、评测基准说明训练任务错位、上下文缺失和旧基准饱和等问题ACE-RTL FrameworkGenerator、Reflector、Coordinator、Parallel Scaling给出完整方法Experiment主结果、消融、案例、并行扩展、VerilogEval分层验证每个组件是否真的有效Failure Analysis时序诊断、规格歧义、波形缺失说明当前边界和未来方向Conclusion总结收束全文阅读时最重要的不是单独记住每个模块而是跟住作者的完整论证链两类路线各有短板 ↓ 训练一个适合 Agent 循环的 RTL Generator ↓ 用 Reflector 解释仿真失败 ↓ 用 Coordinator 累积历史并判断是否重启 ↓ 通过并行轨迹缩短首次成功时间 ↓ 用主实验、消融和案例逐层验证4. ACE-RTL 的核心创新点论文可以概括为四个主要创新。创新一第一次把 RTL 专用模型放到“持续迭代”的 Agent 核心位置以往 RTL 专用模型往往被当作一次性的代码生成器输入规格输出 RTL任务结束。ACE-RTL 的 Generator 不只负责第一次生成还要在后续迭代中读取当前 RTL仿真错误期望值与实际值差异历史修复建议上一轮修改结果。然后继续编辑或调试代码。这意味着专用模型从“静态生成器”变成了 Agent 闭环中的持续执行者。创新二训练数据直接对齐 Agent 在真实循环中的动作作者没有只构造 Spec-to-RTL 数据而是把训练任务统一为X → C*其中正确实现记为C*输入X有三种形式S → C* # Specification-to-RTL (S, C_base) → C* # Editing (S, C_bug) → C* # Debugging这里S是设计规格C_base是功能不完整、需要扩展的基础实现C_bug是包含错误、需要修复的实现。这个设计很关键。因为 Agent 在第二轮之后面对的通常不再是“只有规格”而是“规格 当前代码 失败信息”。训练数据覆盖编辑和调试后Generator 才能真正适应后续迭代。创新三把 Agent 的核心从“多角色编排”转向“上下文演化”论文认为Agent 最重要的职责不是不断增加角色而是动态构造正确的上下文让生成模型知道已经尝试过什么、哪里失败、什么不能再重复以及下一步应该改什么。因此ACE-RTL 引入 Coordinator持续维护一个 self-evolving context。它不仅记录历史还会判断当前轨迹是否已经陷入停滞并在必要时触发 restart。创新四用多条随机调试轨迹并行换取更短的首次成功时间ACE-RTL 不把希望全部压在一条初始代码和一条调试轨迹上而是同时启动多个独立流程同一个 Specification ├── Process 1初始 RTL A → 调试轨迹 A ├── Process 2初始 RTL B → 调试轨迹 B ├── Process 3初始 RTL C → 调试轨迹 C └── ...任意一个流程通过全部测试后其余流程立即终止。它优化的不是总计算量而是time-to-first-success尽快找到第一份正确实现。5. 方法详解Generator、Reflector 和 Coordinator 如何协同图片来自原文ACE-RTL 的主流程可以压缩成下面这条链Specification ↓ Generator 生成或修改 RTL ↓ iverilog 编译并运行测试 ↓ 通过 ── 是 ──→ 输出代码 │ 否 ↓ Reflector 分析错误和信号差异 ↓ Coordinator 更新调试历史与上下文 ↓ 判断继续局部修复还是 Restart ↓ 新的上下文重新送入 Generator5.1 Generator真正负责 RTL 生成和修复的专用模型ACE-RTL-Generator 基于Qwen2.5-Coder-32B-Instruct微调。作者先从公开仓库和开源硬件项目中收集约 500 万份 RTL 脚本然后依次进行去重删除网表等机器生成产物过滤过短或过长模块保留约 302000 行的样本使用 Icarus Verilog 做语法验证使用 Jaccard 相似度做基准去污染相似度大于 0.8 的样本被移除。经过清洗后保留约 15.7 万份高质量 RTL 种子。在这些种子的基础上作者使用 GPT-OSS-120B 和 DeepSeek-R1 等模型生成三类训练数据规格到 RTL代码编辑代码调试。调试样本中的 Bug 不是只改几个语法符号而是尽量模拟真实 RTL 错误例如状态机转移错误时序或握手协议违例计数器 off-by-one边界条件和溢出处理缺失。随后数据还要经过语法检查、基准去污染和 LLM-as-Judge 语义一致性评分。评分低于 3 分的样本会被丢弃最终得到约 170 万条训练数据。这里还有一个值得注意的选择作者没有使用大规模 Chain-of-Thought 轨迹做监督训练。原因是 Agent 循环会反复调用 Generator冗长推理会显著增加每轮延迟。作者更希望 Generator 快速接收“增强后的规格”直接输出修改后的 RTL。这说明模型训练目标不是追求最长的可见推理而是服务于系统级闭环效率。5.2 Reflector不直接写代码而是把失败解释清楚每轮候选 RTL 都会通过iverilog编译并运行测试。如果失败系统先把日志整理成结构化反馈包括Primary error to fix - Error message - Expected vs. Actual - Signal involved Error Analysis Fix GuidanceReflector 使用 Claude4-Sonnet同时读取设计规格当前 RTL结构化仿真反馈。它的任务不是直接替代 Generator 重写代码而是完成两件事把表面错误追溯到可能的逻辑原因给出高层修复指导。这种分工减少了通用大模型直接生成 RTL 时可能出现的领域偏差也让专用模型继续承担它最擅长的代码修改工作。5.3 Coordinator全文最关键、也最容易被低估的组件Coordinator 同时承担“记忆”和“控制”两种职责。第一它会累积跨轮次调试历史Iteration i - 遇到了什么错误 - Reflector 给了什么指导 - Generator 做了什么修改 - 修改后结果如何这能防止系统每一轮都像第一次看到问题一样重复已经失败的修复。第二它会监测调试轨迹是否停滞。当同一个主要错误连续多轮存在而且测试结果没有实质改善时Coordinator 不再要求 Generator 在旧代码上继续打补丁而是触发 restart丢弃当前实现保留从失败中提炼出的高层经验让 Generator 根据规格和澄清后的约束重新生成一份实现。这比简单的“清空上下文重来”更合理因为系统不是忘掉失败而是丢弃已经陷入局部最优的代码但保留从失败轨迹中学到的设计约束。5.4 三个组件为什么能够真正接起来这篇论文的方法设计中有一个非常漂亮的接口对齐从 Generator 的视角看Coordinator 生成的自演化上下文本质上像一份不断增强的规格说明其中加入了当前失败症状需要修改的行为已经验证无效的方案新发现的隐含约束。而 Generator 在训练时恰好学过 Editing 和 Debugging 数据。也就是说训练阶段的数据形态 ↕ 对齐 Agent 阶段的上下文形态这才是 ACE-RTL 能够把“专用模型”和“上下文演化”组合起来的根本原因。6. 方法如何支撑创新点把论文的创新主张、具体机制和实验验证放到一起看会更清楚。创新主张对应方法论文中的验证证据RTL 专用模型可以成为 Agent 核心而不只是一次性生成器用生成、编辑、调试三类数据训练 GeneratorStandalone Generator 在代码修改任务上比 GPT-5 高 21.45 个百分点完整 ACE-RTL 又进一步提升Agent 的关键在于跨轮次上下文而不是单轮反馈Coordinator 累积错误、建议、修改和结果消融中加入 Coordinator 后平均 APR 从 62.17 提升到 83.47局部修复会陷入停滞需要可控重启检测重复失败并保留经验后重新生成完整模型相较无 restart 版本从 83.47 提升到 89.84Clock Jitter 案例展示了逃离停滞过程并行随机轨迹能够降低首次成功延迟五个独立流程并行任一成功即停止平均迭代数从 11.30 降至 4.08速度提升 2.77 倍Token 仅增至 1.12 倍领域知识和通用推理是互补关系RTL Generator Claude4 Reflector/CoordinatorACE-Claude4 平均 APR 为 83.92完整 ACE-RTL 为 89.84这张表也说明论文并不是只给出一个总分。它通过主结果、消融、案例和成本分析把每个组件的作用分别拆开验证。7. 实验设计作者如何证明 ACE-RTL 有效7.1 为什么选择 CVDP而不是只看 VerilogEval论文认为VerilogEval 和 RTLLM 中很多任务较短、较独立近年的强模型已经逐渐把这些基准“做饱和”了。因此主实验使用 CVDP-v1.0.2并选择四类任务CVDP 类别任务题目数量cid002Code Completion94cid003Specification-to-RTL78cid004Code Modification55cid016Code Debugging35合计 262 道问题覆盖算术单元片上通信协议存储层次DSP 内核控制逻辑。每道问题独立运行 5 次。论文报告两个指标Pass1独立运行的平均一次成功率Agentic Pass Rate至少被某次 Agent 运行成功解决的问题数占全部问题数的比例。APR 更适合描述多轮、多次尝试的 Agent 覆盖能力但它不能被直接理解成“单次生成准确率”。7.2 对比对象是否足够强论文共比较 14 个基线覆盖四类模型开源通用模型Llama4-Maverick、DeepSeek-v3.1、DeepSeek-R1、Kimi-K2、Qwen3-Coder-480B闭源前沿模型o4-mini、GPT-5、Claude4-SonnetRTL 专用模型RTLCoder、CodeV、OriGen、CraftRTL、ScaleRTLRTL AgentMAGE。为了尽量公平MAGE 使用的通用模型同样设置为 Claude4-Sonnet论文还额外测试了把 ACE-RTL-Generator 放入 MAGE 的版本。7.3 主结果完整 ACE-RTL 到底提升了多少图片来自原文从 APR 看四个任务的结果如下任务最强对比方法 APRACE-RTL APR绝对提升Code Completion46.81%80.85%34.04 个百分点Spec-to-RTL55.13%96.15%41.02 个百分点Code Modification70.91%90.91%20.00 个百分点Code Debugging62.86%91.43%28.57 个百分点其中最显眼的是 Spec-to-RTL55.13% → 96.15%提升了41.02 个百分点。但更值得注意的其实是另外两点。第一ACE-RTL-Generator 单独使用时已经很强。它在 Code Modification 上取得 65.09% 的 Pass1而 GPT-5 为 43.64%高出 21.45 个百分点。这直接说明 Editing 数据确实改变了模型对代码修改任务的适应性。第二旧有的小型 RTL 专用模型在 CVDP 上并没有天然优势。RTLCoder、CodeV、CraftRTL 等模型在多个任务上的成绩明显落后于前沿通用模型。这说明“训练过 Verilog”不等于“能够处理长规格、复杂上下文和持续调试”。领域模型是否有效关键还要看训练数据是否覆盖真实工作流。8. 消融实验真正贡献最大的组件是谁图片来自原文四类 CVDP 任务的平均 APR 为方法平均 APRGenerator单独使用54.35%ACE-RTL without Coordinator62.17%ACE-RTL without restart83.47%ACE-Claude483.92%完整 ACE-RTL89.84%这组消融非常有信息量。8.1 只有仿真反馈也会提升从 54.35% 到 62.17%说明让模型根据仿真结果持续修复本身就比单次生成更有效。8.2 最大增益来自 Coordinator从 62.17% 到 83.47%提升超过 21 个百分点。这说明真正改变 Agent 行为的不只是“再调用一次模型”而是保留跨轮次调试历史让后续修复建立在前面失败的基础上。8.3 Restart 不是可有可无从 83.47% 到 89.84%说明部分失败轨迹不是继续局部修改就能救回来。对于已经形成错误架构的代码最合理的动作可能不是再打一个补丁而是带着新理解重新生成。8.4 专用 Generator 和上下文演化是互补的ACE-Claude4 使用相同的 ACE 框架但把 RTL 专用 Generator 替换为 Claude4平均 APR 为 83.92%完整 ACE-RTL 达到 89.84%。这说明只有专用模型不够只有通用推理和 Agent 框架也不够两者结合才是论文想证明的重点。9. 两个案例Agent 是如何从“反复失败”走向正确的图片来自原文9.1 案例一64b/66b Decoder这个模块需要对混合模式数据流进行位对齐提取。ACE-RTL 很快通过了 9 个测试但最后一个测试长期无法通过。系统并没有因为“已经 9/10”就继续做毫无方向的局部微调。Reflector 对比了期望输出和实际输出并结合规格推断解码逻辑中存在一个没有被明确写出的隐式对齐变换。在这个高层行为被补充到修复指导后Generator 修改提取逻辑剩余测试立即通过。这个案例证明 Reflector 的价值不是简单复述报错而是从信号差异中提炼设计行为。9.2 案例二Clock Jitter Detection这个模块通过比较时钟边沿间隔和阈值来检测抖动。前面的多轮修改都保留了同一个根本错误在还没有建立有效基准间隔之前就提前执行了抖动检测。Generator 虽然不断产生不同写法但这些代码只是“语法上不同”时序语义上的错误并没有改变。Coordinator 发现多轮断言模式相同测试通过数长期没有改善当前轨迹已经停滞。于是它触发 restart并保留一条关键经验在执行 jitter detection 之前必须先确认已经获得完整、有效的第一次测量间隔。经过两次 restartGenerator 最终引入 validity flag把检测推迟到首个完整区间之后全部测试通过。这个案例非常直观地说明随机性只有和停滞检测、经验保留结合起来才会从“反复碰运气”变成“有控制的搜索”。图片来自原文10. Parallel Scaling五路并行为什么只增加了 1.12 倍 Token论文在推理时启动 5 个并行 ACE-RTL 流程每个流程最多 30 次迭代温度为 1.2。图片来自原文结果如下设置平均 APR平均迭代数速度相对 Token不使用 Parallel Scaling89.84%11.301.00×1.00×使用 Parallel Scaling89.84%4.082.77×1.12×看上去同时运行 5 条轨迹Token 应该接近 5 倍但实际只有 1.12 倍。论文给出的解释是单轨迹运行到后期时自演化上下文会越来越长每一次调用都更贵并行策略虽然启动了更多流程却经常能在较早迭代就出现成功轨迹因此每条轨迹的上下文都没有膨胀到很长。这里需要准确理解作者的主张它没有声称总计算量一定更低它证明的是在这组实验中可以用很小的 Token 增量换取明显更短的首次成功时间。这是一种延迟—成本权衡而不是“免费加速”。11. VerilogEval 结果说明了什么在 VerilogEval-Human-v2 上CraftRTL Pass168.0%Claude4 Pass173.0%ACE-RTL-Generator Pass173.8%VerilogCoder APR94.2%MAGE APR95.5%ACE-RTL APR95.5%。ACE-RTL 与 MAGE 并列达到 95.5%。这个结果的意义不是再次拉开巨大差距而是说明 ACE-RTL 在更复杂的 CVDP 上取得优势后并没有失去对传统短任务的适应性。同时这也提醒我们在已经接近饱和的基准上95.5% 和 95.5% 很难继续区分方法优劣因此 CVDP 主实验比 VerilogEval 更能体现论文的创新价值。12. 这篇论文有哪些局限一篇真正的论文阅读不能只看最高分也要看它没有覆盖什么。12.1 目前验证的是功能正确性不是完整 FPGA 工程闭环ACE-RTL 的主要工具是iverilog实验核心是能否通过功能测试。论文没有进一步评测综合是否通过时序是否收敛面积和功耗是否合理是否存在不可综合结构形式验证结果FPGA 上板行为。因此它证明的是“Agent 能更有效地找到通过测试的 RTL”还不能直接等价为“生成了可以进入生产流程的高质量 RTL”。12.2 论文没有处理 testbench 生成CVDP 实验使用已有测试框架。作者明确把 testbench generation 和主观评测留到未来工作。这降低了变量数量有利于专门研究 RTL 生成与修复但也意味着 ACE-RTL 还没有解决当验证环境本身需要 Agent 创建时如何保证测试不是错误的也不会被待测代码“骗过”12.3 不使用波形使细粒度时序 Bug 仍然困难论文有意只使用文本化仿真反馈以验证领域训练和规格推理本身的作用。作者也承认剩余失败中有一类需要细粒度时序诊断纯文本日志不足以定位真正的 timing bug。波形是自然的下一步但论文提出了一个很重要的警告波形不能代替规格推理否则 Agent 可能只对测试中观察到的行为做过拟合。12.4 训练和部署成本并不低Generator 使用 32 个节点、每个节点 8 张 A100 训练总训练开销约 1 万 GPU 小时推理阶段还依赖 Claude4-Sonnet API。这说明 ACE-RTL 的思路很有价值但完整复现并不是普通团队可以轻易完成的。12.5 合成数据质量仍然存在不确定性训练样本经过语法检查、去污染和 LLM-as-Judge 过滤作者也人工检查了部分 Judge 结果并迭代提示词。不过论文没有进一步给出大规模人工核验比例、不同任务的数据分布以及语义错误率。因此170 万条数据的规模很清楚数据中“真正复杂且高质量”的比例仍需要更多公开细节支持。12.6 APR 不能被当成单次准确率APR 衡量的是多轮、多次 Agent 搜索后能够覆盖多少道题。它适合衡量 Agent 的最终解题覆盖率却会同时受到以下因素影响并行进程数量最大迭代次数温度Token 预算停止条件。因此阅读 96.15% 时必须连同“5 个并行流程、每个最多 30 轮”一起理解。13. 对 RTL Agent 和 FPGA 工具开发有什么启发这篇论文对工程实践最有价值的部分不一定是训练一个 32B 模型而是下面这些系统设计原则。启发一训练或提示设计必须覆盖 Agent 的真实动作空间如果 Agent 要做生成、修改、修 Bug、重构、验证后再修改那么训练集、示例库或 Skill 模板就不能只有需求 → 完整代码应该显式加入基于现有 RTL 的增量修改根据仿真日志修复协议错误时序边界状态机和计数器错误不完整实现到完整实现。启发二不要把原始日志直接塞回模型Reflector 的价值在于把工具输出转成主要错误 涉及信号 期望与实际 原因分析 修复建议对于 Vivado 或 Vitis HLS Agent同样应该把长日志转成结构化事实例如编译错误位置仿真失败断言WNS/TNS关键路径LUT/FF/BRAM/DSPII、Latency未满足的完成门。启发三Agent Memory 不是聊天记录而是可执行的工程历史真正有用的历史应该记录错误 → 诊断 → 修改 → 验证结果而不是把全部对话机械拼接到下一轮。上下文要能够回答哪些假设已经被证伪哪些修改有效哪些错误仍未解决当前版本相对上一版改变了什么是否已经出现停滞启发四Restart 应该是正式控制策略很多 Agent 循环失败不是模型不会写代码而是系统只允许它在越来越糟的实现上继续修补。合理的 restart 需要同时做到丢弃错误实现保留已经确认的约束换一条结构不同的实现路线重新执行完整验证。启发五并行搜索不是简单多开几个进程并行轨迹要想真正有意义需要保证初始方案具有差异性各轨迹状态隔离验证标准一致任一通过即可安全停止记录每条轨迹的成本和证据。否则只是在并行地产生相似错误。启发六功能通过只是第一道门ACE-RTL 的完成条件是通过功能测试。对于真正的 FPGA Agent还应继续扩展为多级完成门语法 / Lint ↓ 功能仿真 ↓ 综合 ↓ 实现与时序 ↓ 资源与约束 ↓ 必要时上板验证这属于从论文方法向工程系统的自然延伸上下文演化不仅要记住仿真错误还要记住综合、时序和资源证据。14. 最终评价这篇论文最值得记住的是什么ACE-RTL 的成绩很亮眼但真正值得记住的不是某一个 96.15%而是三个更普遍的判断。第一领域模型和通用推理模型不是替代关系而是分工关系。第二Agent 的核心能力不只是调用工具而是能否把工具反馈沉淀为跨轮次、可执行的上下文。第三**失败轨迹本身是一种资产。**系统既要从失败中积累约束也要有能力在局部修复无效时放弃当前实现重新探索。从这个角度看ACE-RTL 并不只是“一个更强的 Verilog 生成模型”。它更像是在回答一个更重要的问题怎样把一个会写 RTL 的模型变成一个能够持续观察、诊断、修改和验证的 RTL 工程 Agent它还没有走到综合、时序、PPA、波形和硬件验证但已经把“模型—工具—上下文—重启—并行搜索”之间的关系讲得相当清楚。对于正在研究 Verilog 代码生成、RTL 自动修复、FPGA Agent 或 EDA 智能体的人这篇论文值得重点阅读。参考文献[1] Chenhui Deng, Zhongzhi Yu, Guan-Ting Liu, Nathaniel Pinckney, Brucek Khailany, Haoxing Ren.ACE-RTL: When Agentic Context Evolution Meets RTL-Specialized LLMs. arXiv:2602.10218, 2026.论文主页https://arxiv.org/abs/2602.10218关键词ACE-RTL、Verilog、SystemVerilog、RTL 代码生成、Agentic Context Evolution、硬件大模型、FPGA Agent、EDA Agent、LLM for Hardware