英伟达的一篇有趣新论文。

看起来智能体编码正在进入硬件设计领域。

HORIZON 将硬件设计视为仓库级别的代码演化。一个 Markdown 框架被编译成一个项目包，其中包含领域知识、可执行评估器、接受谓词以及 git/运行时策略。然后，智能体会独立地演化一个工作树。

这是一个强大的模式，因为硬件设计需要可执行的检查。验证器框架成为了智能体与设计任务之间的真正接口。

该论文报告称，在多个硬件设计套件上实现了 100% 的基准完成率，即使你不从事 EDA 工作，这也值得关注。

论文: https://arxiv.org/abs/2606.28279

在我们的学院学习构建高效的 AI 智能体: https://academy.dair.ai

作为仓库级代码演化的智能体硬件设计

来源: https://arxiv.org/html/2606.28279 Cunxi Yu NVIDIA Research & Chenhui Deng NVIDIA Research & Nathaniel Pinckney NVIDIA Research & Brucek Khailany NVIDIA Research

摘要

我们提出了 HORIZON，一个自我演化的智能体框架，它将硬件设计视为仓库级别的代码演化。一个 Markdown 框架被编译成一个项目包，其中包含领域知识、一个可执行评估器、一个接受谓词以及一个 git/运行时策略；一个无需人工干预的智能体循环随后会演化一个独立的 git 工作树，利用仓库操作进行状态管理、跟踪和重放。这将仓库规模自我演化的先前工作从 EDA 软件系统扩展到了硬件设计工件本身。我们在 ChipBench、RTLLM、Verilog-Eval 和九个 CVDP 类别上评估了我们的方法，通过完全无需人工干预的智能体循环，在所有套件上实现了 100% 的基准完成率。然而，我们并不声称智能体 AI 用于硬件设计的问题已解决：这些基准只是针对芯片设计中更广泛工程问题的受控代理。第5节 (https://arxiv.org/html/2606.28279#S5) 审视了当前研究的局限性，并指出了开放的研究挑战。

1 引言

可执行的设计任务暴露了单轮代码生成的局限性。一个有用的智能体必须将候选工件放置在一个可运行的工作区内，调用领域工具，解释失败原因，并修改工件直到满足明确的接受条件。RTL 设计是一个尖锐的测试案例：正确性依赖于周期级行为、复位和接口约定、位宽以及仿真器反馈，因此仅仅是语法上正确的 Verilog 是不够的。

我们的动机来自仓库规模的代码自我演化。AlphaEvolve 表明，带有自动评估器的 LLM 可以改进算法内核 (Novikov et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib1)); SATLUTION 将此想法扩展到完整的 SAT 求解器仓库 (Yu et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib2)); ABCEvo 将其应用于 ABC 逻辑综合系统 (Yu et al., 2026 (https://arxiv.org/html/2606.28279#bib.bib3))。在所有情况下，智能体都会演化一个版本控制的软件工件，并且仅当有可执行的证据支持时才接受更改。缺失的一步是硬件：先前的仓库级自我演化改变的是工程师运行的程序，而不是工程师创建的硬件设计。

在这里，我们提出一个问题：“硬件设计本身是否可以被当作仓库级代码演化来管理？” 受先前工作的启发 (Yu et al., 2026 (https://arxiv.org/html/2606.28279#bib.bib3), 2025 (https://arxiv.org/html/2606.28279#bib.bib2))，HORIZON 将一个设计问题转变为一个自包含的 git 工作树，并带有一个可执行的接受门控。一个结构化的 Markdown 框架指定了目标、领域知识、评估器和接受谓词；一个引导智能体将其编译成一个项目包；然后一个无需人工干预的智能体循环编辑、评估、提交或拒绝候选版本。在这个设计中，Git 并非偶然的记账工具。它提供了独立的演化环境和跟踪基础：diff 暴露状态变化，提交定义了接受的检查点，日志和笔记存储了评估器的证据，仓库历史成为了智能体搜索过程的可重放记录。

这个框架比本文中的基准测试更广泛。用于硬件设计的智能体 AI 包括架构探索、微架构、验证规划、物理设计交互、EDA 软件以及方法论开发；我们不声称 RTL 智能体的问题已解决。我们使用 RTL 基准作为受控的、可执行的代理，用于研究仓库管理的反馈是否能驱动收敛。评估范围涵盖 ChipBench、RTLLM、Verilog-Eval 以及九个 CVDP 类别，包括完成、修改、复用、测试台激励、检查器和断言生成以及调试 (Pinckney et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib4))。

本文做出了三项贡献。首先，我们介绍了 HORIZON，一个将硬件设计任务托管为隔离的、版本控制的、自动评估的仓库（而非一次性提示）的框架。其次，我们展示了这种 git 原生的自我演化循环可以将完整的 RTL 基准套件的通过率提升到 100%，唯一残留的失败可追溯到已知的规范-框架不匹配。第三，我们分析了生成的轨迹，包括 token 消耗和测试生成覆盖率，并表明一旦可执行反馈使正确性收敛，主要的研究瓶颈就变成了收敛效率和验证质量。

2 背景与相关工作

为什么 RTL 对语言模型来说很难。

RTL 生成不同于普通的代码补全，因为输出定义了必须满足时序和位精确行为的硬件。模型必须推断数据路径宽度、有限状态机转换、复位约定、就绪-有效协议、存储器行为以及通常在自然语言中描述不充分的边界情况。一个语法上有效的模块只是起点；有用的自动化必须将生成与编译、仿真、波形或轨迹检查以及修复连接起来。

RTL 专用模型与数据。

一系列工作致力于改进生成器本身。早期研究在 Verilog 语料库上微调开源模型，并确立了领域适应的重要性：VeriGen 整理了大型 HDL 训练数据并基准测试了开源和闭源模型 (Thakur et al., 2024 (https://arxiv.org/html/2606.28279#bib.bib10))，RTLCoder 发布了一个开源数据集和一个轻量级模型，在 RTL 生成上超越了 GPT-3.5 (Liu et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib11))，ChipNeMo 跨芯片设计任务对 LLM 进行了领域适应 (Liu et al., 2023 (https://arxiv.org/html/2606.28279#bib.bib12))。最近的工作更侧重于数据质量和推理：OriGen 使用带有自我反思的代码到代码增强 (Cui et al., 2024 (https://arxiv.org/html/2606.28279#bib.bib13))，CraftRTL 构建了包括非文本表示在内的正确性构造合成数据 (Liu et al., 2024 (https://arxiv.org/html/2606.28279#bib.bib14))，ScaleRTL 扩展了 RTL 推理数据并增加了测试时推理，改进了 Verilog-Eval 和 RTLLM (Deng et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib6))。这些方法提高了首次尝试的准确性，但本身并未定义智能体应如何针对可执行框架进行迭代。

迭代与智能体 RTL。

另一类补充工作在生成器之上增加了工具使用和迭代。AutoChip 驱动一个生成-编译-仿真反馈循环 (Thakur et al., 2023 (https://arxiv.org/html/2606.28279#bib.bib15)); RTLFixer 使用检索增强的、ReAct 风格的调试来修复语法错误 (Tsai et al., 2024 (https://arxiv.org/html/2606.28279#bib.bib16)); VerilogCoder 使用任务与电路关系图进行规划，并通过基于 AST 的工具跟踪波形来定位功能错误 (Ho et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib17)); MAGE 将设计分解到多个协作智能体上，使用高温采样和基于检查点的调试 (Zhao et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib18)); ACE-RTL 将一个 RTL 专用生成器与一个前沿模型反射器和协调器配对，在修复步骤中演化提示上下文 (Deng et al., 2026 (https://arxiv.org/html/2606.28279#bib.bib5))。这些系统表明验证反馈显著提高了正确性，但每个系统都是围绕针对单个模块的生成-修复流水线构建的。HORIZON 是补充性的且更为通用：它不依赖于底层生成器，而是指定如何将整个问题托管为一个版本化仓库，使用原生 git 操作来组织和门控修复循环，并驱动整个基准套件完成，这样任何骨干模型都可以根据收敛性（而不仅仅是首次尝试的准确性）进行评估。

RTL 设计与验证基准。

Verilog-Eval 和 RTLLM 是广泛使用的 RTL 生成基准，对于衡量基本的规约到 RTL 能力仍然有用 (Liu et al., 2023 (https://arxiv.org/html/2606.28279#bib.bib7); Lu et al., 2024 (https://arxiv.org/html/2606.28279#bib.bib8)); ChipBench 以及诸如 OpenLLM-RTL 这样的整合套件汇集了更多的生成问题 (Liu et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib9))。然而，CVDP 论文认为早期的套件日益饱和，且过于狭窄，无法代表真实的硬件设计工作流 (Pinckney et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib4))。CVDP 包含 783 个人工编写的问题，涵盖 13 个任务类别。其代码生成方面包括 RTL 代码补全、自然语言规约到 RTL、代码修改、模块复用、代码检查或质量改进、测试台激励生成、检查器生成、断言生成以及调试。其理解方面包括 RTL/规约对应、测试台/测试计划对应以及技术问答。

CVDP 还区分了非智能体和智能体设置。非智能体问题在单轮中提供提示和相关上下文，而智能体问题则被打包成迷你仓库，旨在供可以检查文件并调用工具的 Docker 化智能体使用。该基准报告在质量过滤后包含 617 个非智能体问题和 166 个智能体问题。作者强调，最先进的一次性模型在面向验证的任务（如测试台生成、检查器生成、断言生成和错误修复）上尤其困难。这使得 CVDP 非常适合评估智能体是否能够通过执行反馈改进其首次尝试的模型准确性。

代码仓库上的自我演化智能体。

另一条独立的工作线将代码库本身视为智能体演化的对象。AlphaEvolve 将 LLM 与自动评估器和一个演化循环相结合，以隔离内核的规模发现和改进算法 (Novikov et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib1))。SATLUTION 将其扩展到完整的仓库规模，在严格的正确性保证和分布式运行时反馈下演化整个 C/C++ SAT 求解器仓库，同时自我演化其自身的演化规则，最终超越了人类设计的 SAT 竞赛获胜者 (Yu et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib2))。ABCEvo 将此想法带入 EDA，使用协调的 LLM 智能体在正确性和 QoR 驱动的评估循环下自主重写百万行的 ABC 逻辑综合系统 (Yu et al., 2026 (https://arxiv.org/html/2606.28279#bib.bib3))。这三者都在共同原则下演化 EDA 或科学软件（工程师运行的程序），即只有通过了可执行的正确性检查并改善了测量行为的候选更改才是有用的。HORIZON 将相同的仓库自包含、证据门控原则应用于硬件方面：它不是演化求解器或综合内核，而是演化被测设计、RTL 源文件、测试平台和验证工件，作为通过 git 工作树自动构建的任务。这允许一个协议涵盖每个任务的 RTL 生成、完成和修复，并使 HORIZON 能够“按原样”处理 RTL 基准问题，而无需将其重新表述为软件工程的替代问题。

Git 作为智能体基础架构。

与我们实现密切相关的是最近利用版本控制本身作为 LLM 智能体脚手架的趋势。EvoGit 仅通过一个基于 Git 的系统发育图（记录完整的版本谱系）来协调分散的编码智能体种群，无需共享内存或显式消息传递 (Huang et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib19))。Git Context Controller 将智能体的上下文从瞬时的 token 流提升为持久的、版本控制的记忆，使用显式的 commit、branch 和 merge 操作来处理长期软件任务 (Wu et al., 2025 (https://arxiv.org/html/2606.28279#bib.bib20))。两者都证明了 git 语义（分支、谱系和检查点）天然适合组织智能体探索，但两者都针对软件工程：分别是协作代码生成和上下文管理。HORIZON 同样坚信 git 是正确的底层技术，并且同样将每次尝试记录为带有关联评估器证据的提交，但将其应用于不同的目的：将单个硬件设计问题托管为一个自包含的、验证门控的仓库，其历史双重作为可重放的体验轨迹。我们将其视为趋同性证据，表明仓库原生智能体正成为一种新兴范式，而非单一领域的技巧。

3 HORIZON 框架

系统概述。

图1 (https://arxiv.org/html/2606.28279#S3.F1) 总结了 HORIZON。核心思想是将硬件设计问题像软件演化问题一样管理：设计、上下文、框架以及带有正确性门控的评估器都位于一个隔离的 git 工作树中，进展表现为仓库状态的变化，而不是断开的对话轮次。用户提供一个结构化的 Markdown 框架；一个引导智能体将其编译成一个项目包，这是控制平面，固定了任务、领域技能、可执行评估器、正确性门控以及 git/运行时策略。此后，一个自包含的智能体循环无需进一步的人类输入即可演化工作树。每个周期生成或编辑候选工件，运行评估器，对结果进行评分，然后提交新版本或记录失败。原生 git 函数同时提供隔离和可追溯性：diff 暴露提议的状态变化，提交定义接受的检查点，日志恢复轨迹，笔记/运行时摘要附加评估器证据。同一机制旨在托管多样化的芯片设计工作，包括 RTL、EDA 软件研究以及方法论或流程探索。在本文中，我们实践了 RTL 实例化；更广泛的设计空间主张是一个框架目标，而非已完成的实证验证。

从框架到可执行任务。

HORIZON 将语言模型智能体视为作用于可执行工作空间的策略。该框架并非特定于 RTL 或 EDA 自我演化：任何具有持久 git 工作树、机器可检查反馈和版本化工件的任务都可以用相同的方式组织。唯一必需的用户输入是一个结构化的 Markdown 框架，其中可以包含高层意图、仓库上下文、预期的工件、评估标准以及领域知识。领域感知的框架特别有用，因为它们暴露了难以仅从文件推断的不变量、工具约定和失败模式。

引导