核心信息

- 原文标题: Is Agentic AI Ready for Real-World Hardware Engineering? A Deep Dive with Phoenix-bench

- 研究问题: 面向软件工程构建的 Agentic AI 能否迁移到真实的仓库级硬件工程任务

- 基准: Phoenix-bench

- 数据规模: 511 个经过验证的 Verilator 实例，来自 114 个 GitHub 仓库

- 任务输入: 真实 GitHub issue 与完整 Verilog/SystemVerilog 仓库

- 验证方式: Docker 固定的 EDA 环境、fail-to-pass 测试与 pass-to-pass 测试

- 评测对象: 4 个商业编码 Agent、8 种开源 Agentic 结构、4 种 LLM backbone

- 主要指标: resolved rate、文件级与模块级 precision/recall

- 最佳产品 Agent 结果: Claude Code 的 resolved rate 为 38.6%

- 代表性开源结果: OpenHands 搭配 GPT-5.2 的 resolved rate 为 33.9%

- 关键发现: 软件任务中的高性能不能直接迁移到硬件任务；主要瓶颈集中在跨模块定位、信号流追踪和多文件修复

- 作者: Qingyun Zou1、Feng Yu1、Hongshi Tan1、Jiahao Cui1、Bingsheng He1、Weng-Fai Wong1

- 机构: National University of Singapore

- 发表时间: 13 May 2026（arXiv v1）

- 领域: arXiv cs.AR

- 论文链接: https://arxiv.org/abs/2605.15226

摘要

论文考察面向软件工程设计的 Agentic AI 是否能够处理真实硬件仓库中的工程问题。现有硬件代码基准通常只隔离评测模块生成、局部修复或调试等子任务，较少同时要求智能体浏览完整仓库、依据模块层级和信号流定位问题、调用可执行 EDA 流程验证，并提交维护式补丁。

为此，作者构建了 Phoenix-bench，包含来自 114 个 GitHub 仓库的 511 个经过验证的 Verilator 实例。每个实例都配有开发者补丁、设计流程标签、fail-to-pass 与 pass-to-pass testbench，以及固定版本的 Docker EDA 环境。论文在统一验证器下评测商业和开源智能体，并通过文件级 oracle localization 和单轮 testbench 日志反馈分析失败来源。

实验显示，软件智能体从 SWE-bench Verified 迁移到 Phoenix-bench 后，解决率下降 37 至 58 个百分点。文件级定位提示只带来 1.4% 的提升，而一次测试反馈可以使 resolved rate 提升 42% 至 45%。这些结果表明，硬件工程中的主要挑战并非单纯生成语法正确的 RTL，而是沿模块实例化链追踪信号传播、判断真正的修改位置，并通过 EDA 反馈完成行为闭环。

背景与问题

软件编码 Agent 通常围绕函数、调用图和文件依赖展开搜索与修改。在 SWE-bench 一类任务中，智能体往往可以从 issue 描述定位到出错函数，再通过局部补丁修复行为。但硬件描述语言描述的是由多个并行模块构成的电路网络。模块之间通过端口和信号连接，一个下游模块中暴露出的错误现象，真正原因可能位于信号传播路径上的上游模块。

因此，硬件仓库级修复不是简单地将编程语言从 Python 换成 Verilog/SystemVerilog。智能体需要理解模块层级、实例化关系、端口连接、时钟与复位行为，以及 testbench 和构建脚本之间的关系。一个有效补丁还必须避免破坏原本已经正确的功能。

已有基准主要存在三类边界。VerilogEval、RTLLM、RTLFixer 和 HDLdebugger 偏向孤立模块的生成、修复或调试；RTL-Repo 与 MHRC-Bench 虽然引入仓库上下文，但主要使用补全任务和 exact match；HWFixBench 已经关注仓库级补丁，却使用 LLM judge，覆盖范围也较有限。Phoenix-bench 将问题推进到真实 issue 驱动的仓库维护，并使用可执行 EDA 流程判断补丁是否有效。

创新点

本文的核心创新是把硬件代码评测组织成完整的工程闭环：真实 issue、完整仓库、跨设计阶段的问题、仓库级补丁，以及由 EDA 工具执行的确定性验证。

Phoenix-bench 的每个实例同时包含 fail-to-pass 和 pass-to-pass 测试。前者要求开发者补丁能够修复缺陷，后者要求智能体补丁不能破坏原本通过的行为。这样的评价方式不仅检查“目标错误是否消失”，也检查补丁是否造成回归。

数据构建采用从 GitHub 仓库和 issue 到 pull request、代码修改和 Docker runner 的筛选流程。最终语料保留 Design、Verification、Environment & Toolchain、Physical & Implementation 和 Documentation 五类问题，并将其映射到 ASIC/FPGA 设计流程，如图2所示。

Phoenix-bench 的任务边界覆盖仓库导航、层级化定位、EDA 执行验证和维护式补丁，而不是独立 RTL 片段的生成。图1展示了智能体从真实 issue 出发修改 Verilog/SystemVerilog 仓库，并接受 Docker 化 EDA 测试的完整任务链路，如图1所示。

一句话总结

Phoenix-bench 表明，软件编码 Agent 的能力尚不能直接迁移到真实硬件工程，硬件任务的主要瓶颈是跨模块信号流定位和基于测试反馈的多文件维护，而不是单纯的语言模型生成能力。

方法主线

Phoenix-bench 的构建从至少拥有 50 个 star 的 Verilog/SystemVerilog GitHub 仓库开始，随后保留与 pull request 明确关联、且确实修改硬件产物的 issue，并去除重复或不完整案例。最终得到 511 个同步 runner 实例，覆盖 114 个仓库。

每个实例通过分层 Docker 镜像固定环境：基础镜像提供 EDA 工具链，仓库镜像安装项目依赖，实例镜像固定具体问题对应的代码快照。验证工具包括用于周期精确仿真的 Verilator、用于部分 SystemVerilog 构造的 Icarus Verilog、负责解析与 elaboration 的 Surelog，以及用于综合和检查的 Yosys。

测试流程要求智能体根据 issue 修改仓库，然后执行两类测试。fail-to-pass 检查目标缺陷是否从失败变为通过；pass-to-pass 检查原本通过的行为是否仍然保持。主要评价指标是 resolved rate，同时统计文件级和模块级定位 precision/recall，以区分“找到了文件”和“找到了真正需要修改的模块”。

问题类别对应不同设计阶段。Design 主要包括 RTL 功能、规格一致性和质量结果问题；Verification 包括 testbench、assertion 和 simulation build failure；Environment & Toolchain 包括模拟器兼容性、构建脚本和工具调用；Physical & Implementation 包括 timing warning、latch inference 和资源使用；Documentation 则覆盖 README、注释和 API 描述，如图3所示。

完整同步语料共生成 71,048 个 TESTCASE: 检查。补丁覆盖率围绕开发者补丁实际触及的代码计算，包括修改行、Verilator branch/toggle points，以及补丁局部的 function 或 scope entries。图表中的统计将 Phoenix-bench 的 511 个 Verilog/SystemVerilog 实例与 SWE-bench Verified 的 500 个 Python 实例进行对照。

关键结果

商业 Agent 在同一 Docker EDA verifier 下的 resolved rate 较为接近，但定位行为和资源消耗存在明显差异。Claude Code 的 resolved rate 最高，为 38.6%，File Recall 为 54.2%，Module Recall 为 48.3%，平均每个实例使用 432k tokens。OpenAI Codex 的 resolved rate 为 38.0%，File Precision 为 41.2%，Module Precision 为 49.7%，平均使用 326k tokens。Gemini CLI 的 resolved rate 为 37.4%，平均使用 254k tokens；GitHub Copilot coding agent 为 32.7%，File Precision 为 47.8%，平均 token 使用量最低，为 148k，如表2所示。

如表3所示。

开源 Agent 中，GPT-5.2 下的 OpenHands resolved rate 为 33.9%，SWE-agent 为 27.8%，Agentless 为 18.8%，ExpeRepair 为 11.7%。OpenHands 的 File Recall 为 50.7%，但 Module Recall 为 45.0%；SWE-agent 对应为 49.4% 和 44.5%。文件召回率高于模块召回率，说明硬件任务中找到相关文件并不等于覆盖全部需要修改的模块。

在 SWE-bench Verified 与 Phoenix-bench 的对比中，代表性系统的解决率下降 37 至 58 个百分点。mini-SWE-agent 搭配 GPT-5.2 时，SWE-bench Verified 的结果为 72.8%，Phoenix-bench 仅为 14.5%；OpenHands 搭配 Qwen3-Coder-480B 时，Phoenix-bench 为 32.3%，下降幅度约为 37 个百分点，如图6所示。

硬件补丁的复杂度也显著高于软件补丁。SWE-bench 的 gold patch 中位数为 1 个文件、1 个 hunk 和 7 行代码，多文件补丁占 14.2%；Phoenix-bench 的对应中位数为 4 个文件、7 个 hunks 和 65 行代码，多文件补丁占 73.1%。随着补丁复杂度从 T1 Easy 提升到 T3 Difficult，Codex 的解决率从 53.9% 降至 30.5%，Claude Code 从 53.9% 降至 29.8%，OpenHands+GPT-5.2 从 47.7% 降至 26.7%。

一次测试平台反馈带来的收益明显高于单纯的文件级提示。对于三个交互式 Agent，加入一轮 testbench 日志反馈后，resolved rate 提升 42% 至 45%，如表5所示。

深度分析

失败阶段统计显示，Claude Code 的失败由 29.9% No Edit、47.1% Localization Failure 和 22.9% Repair Failure 构成；OpenHands+GPT-5.2 对应为 29.9%、47.3% 和 22.8%。两者约 77% 的失败发生在未编辑或没有覆盖全部目标文件的阶段，只有约 23% 属于已经到达全部目标文件后的修复错误。

这说明硬件任务的首要瓶颈是定位链路过早停止。智能体可能找到出现症状的下游文件，却没有继续沿模块实例化关系和信号流追踪到真正的上游缺陷。即使已经知道相关文件，也可能遗漏文件内部的目标模块、连接端口或需要协调修改的其他模块。

问题类别进一步强化了这一判断。两个智能体的失败中，设计类问题约占 60%，其中控制流与 FSM 缺陷最集中：Claude Code 的设计失败中有 152/203 个属于该子类别，OpenHands+GPT-5.2 为 162/217 个。Verification 类失败主要来自 testbench 缺陷，Claude Code 为 32/43 个，OpenHands+GPT-5.2 为 34/45 个。Physical & Implementation 类问题则集中于时钟、复位、跨时钟域和平台集成。

定位范围与成本之间存在直接权衡。OpenHands 处理全部 511 个实例约消耗 673M tokens；KGCompass 和 Agentless 的总消耗低于 40M tokens；ExpeRepair 约消耗 106.9M tokens。更广泛的搜索和更深的交互可以提高召回率，但会显著增加 token 消耗，如图5所示。

文件级 oracle localization 仅使 Claude Code 的解决率提升 1.4%。文件提示挽救了 120 个原本失败的案例，却在原本通过的快照上引入了 113 个回归案例，最终净增加 7 个解决案例。原因在于文件列表只能缩小搜索范围，不能说明具体应该修改哪一行、哪个操作符或哪条信号路径；同时，它还可能诱发智能体对不必要文件进行修改。

相比之下，testbench 日志包含执行结果和行为约束，能够同时提示缺陷出现的位置以及修复后应满足的行为。因此，一轮可执行反馈比静态文件提示更接近真实硬件调试过程，也更能帮助智能体从“定位”进入“正确修复”。

局限

Phoenix-bench 当前验证范围截止到综合阶段，未继续纳入 place-and-route 和 clock-tree synthesis，因为这些后端阶段无法在跨仓库环境中进行确定性执行。

基准主要依赖 Verilator 及其他开源 EDA 工具链，并通过 Docker 固定工具版本、项目依赖和代码快照。该设计提高了结果可比性，但评价重点集中在能够被这套执行环境稳定验证的任务上。

实验中的文件级 oracle 只提供相关文件，不能提供具体逻辑位置和修改方向。其有限收益以及伴随的回归案例说明，文件级信息不足以替代模块级、信号级和行为级推理。

此外，商业 Agent 的产品接口、模型选择和内部编排保持黑盒，论文能够比较其端到端工程结果，但难以将所有差异进一步归因到单一模型能力、搜索策略或反馈机制。

总结

Phoenix-bench 将真实 GitHub issue、完整 Verilog/SystemVerilog 仓库、跨设计流程问题、仓库级补丁和 Docker 化 EDA 验证整合为一个硬件工程基准。实验结果显示，软件工程 Agent 在硬件任务上的性能会大幅下降，且下降幅度并不只由 backbone 能力决定。

最主要的失败发生在未编辑或定位不完整阶段。硬件缺陷往往沿并行模块和信号流跨层级传播，补丁也更常涉及多个文件、多个 hunk 和更长的代码范围。文件级定位提示的收益有限，而测试执行反馈能够带来 42% 至 45% 的相对解决率提升，说明硬件 Agent 需要更深入的结构化定位、持续交互和基于 EDA 行为反馈的修复闭环。