百万行EDA工具源码,AI自己改自己

ABC 这个被学术界和工业界广泛使用的逻辑综合工具，包含超过 120 万行 C 代码、4000 多个源文件、四层分层抽象。过去二十年里，无数研究者在它之上做扩展，却很少有人真正改动其核心——代价太高，牵一发而动全身。

这篇论文干了一件听起来有点离谱的事：让 agent 直接上手改 ABC 的源码，而且是改整个集成代码库，改完还能编译出单一可执行文件、保留原有命令接口。论文把这套系统命名为 Multi-Agent Self-Evolved ABC，号称是第一个自我进化的逻辑综合框架。

ABC 为什么难改

逻辑综合是硬件设计流程的核心环节，负责把布尔网络变换成面向 ASIC 或 FPGA 的具体实现，涉及逻辑优化与工艺映射两个紧耦合阶段，两者都是 NP-hard 问题。ABC 作为事实上的学术与工业研究平台，积累了 cut-based mapping、布尔改写、flow-tuning 等几十年的算法创新。

但这些年 ABC 的改进越来越难。论文点出了三个原因：代码库已增长到数百万行、数千个相互依赖的 C 文件，一个子系统的微小改动往往会因共享数据结构和紧耦合不变量而不可预测地扩散；在人工驱动的开发下，QoR 改进已经触及饱和点，现代流程中大量固定决策之间的交互高度依赖具体电路；人类工程师创建、集成、验证一个启发式往往需要数天甚至数周。

[Figure 1: 面向 ABC 的多 agent 自进化框架总览] 专门化的 LLM agent 分别进化不同子系统（flow 优化、核心算法、映射），每轮迭代需经过编译、形式化 CEC 验证和完整 QoR 评估；规划 agent 负责全局决策，编码 agent 负责具体修改，所有 agent 共享同一套规则库和统一评估管线。

方案：三个专职 agent + 形式化等价性守门

论文没有用一个”全能 agent”去改整个 ABC，而是把工作拆成三个领域对齐的编码 agent：

Flow Agent 负责 flow 调度与 pass 编排层，初始种子是 FlowTune 的 C 实现。Mapper Agent 针对工艺映射子系统，初始工作目录直接从 vanilla ABC 的 src/map/mapper 克隆，其初始规划参考了 SLAP 的 cut-selection 思路，用于定位和修改 cut 剪枝、枚举与代价评分启发式。Logic Minimization Agent 聚焦工艺无关优化，工作在 src/base/abci/。

三个 agent 共享同一个目标：在不改变功能语义的前提下提升整体 QoR。每个 agent 都由 Claude Sonnet 4.5 驱动，分为 Planning 与 Coding Agent 两个角色——前者制定子系统修改策略，后者生成 diff 并编辑代码库。

一个值得注意的设定是：只有 cycle 0 由人工提供上下文（包括代码库 profiling、结构化 Markdown 教程、子系统初始化），此后所有进化都由 agent 自主规划和执行。人工干预只在连续十次以上因编译错误或等价性检查失败时才触发。

预进化阶段：让 agent 先读懂整个生态

论文在正式进化前设置了一个预进化阶段，由一个自主 agent 系统调研大量开源项目和研究原型，覆盖三类：flow tuning、工艺映射算法、工艺无关优化算法。agent 会评估每个仓库的质量、可扩展性，以及与自我进化闭环的潜在协同，重点关注能否与 ABC 完整集成。

在 flow tuning 方面，agent 注意到许多基于学习的 flow 优化器把 ABC 当黑盒二进制来用，依赖 PyTorch 等外部 ML 框架驱动 pass 选择，这对仓库级代码进化几乎没有价值。相比之下，FlowTune 是作为一个完整集成的综合命令实现在 ABC 内部的，接口清晰、目录模块化，因此被选为 flow 层探索的骨干。

在工艺映射方面，agent 的分析发现外部方法大多依赖与仓库内代码结构不兼容的外部学习框架，直接复用不可行。于是 agent 转而利用从代码库本身提取的架构知识，精确定位 cut 枚举、剪枝和代价评分所在的核心区域，把外部实现的价值转化为结构性指引而非直接代码集成。

进化循环怎么转

每一轮进化按固定顺序推进。

规划阶段由一个单独的 Planning Agent 统领全局：解读上一轮 QoR 反馈、聚合各编码 agent 的假设与变更提案、决定下一步进化哪个子系统。cycle 0 时，规划 agent 会拿到三份材料：由 agent 自己在预进化阶段生成的仓库级 profiling；一份由作者撰写的高度结构化的 Markdown 教程，详述如何添加新函数、注册新命令、修改现有数据结构；以及从 abc -h、在线文档中提炼的综合流程说明。论文特别提到：用 Markdown 而非自然语言提供这些材料，显著提升了 agent 的可靠性，因为结构化格式鼓励程序化推理并减少幻觉。

编码阶段，三个 agent 在互不重叠的目录中工作，所有改动都只发生在各自指定的目录内，以避免冲突并保留 ABC 的架构不变量。为了与原有构建系统完全兼容，每个 agent 生成的模块都遵循仓库的 module.make 结构和 Makefile 约定，这套约定是规划 agent 在 cycle 0 的仓库 profiling 阶段自行学到的。

编译与正确性预检阶段，修改后的仓库先被编译，编译失败时错误日志返回给编码 agent 进入自调试循环。关键在于接下来的一步：形式化组合等价性检查（CEC）。

[Table 1: 每轮评估采集的 QoR 指标] 主要优化目标包括基于 ASAP7 7nm 的 STA Timing (Worst Slack) 和 Post Buffer/Sizing Area；辅助结构性指标包括 AIG #nodes/#edges/#depth、mapper 预 buffer 面积与延迟估计、cut 枚举统计、每个 pass 的结构增量、LUT 映射结果等。

形式化反馈：降低 token 浪费的关键

一条错误的改写规则、映射代价更新或 AIG 操作，都可能悄无声息地污染综合后的网表，并用虚假的 QoR “改进”误导评估器。论文引用 SATLUTION 的经验，指出这类失败会导致大量 LLM 循环被浪费、反复回滚、收敛性恶化。

论文的做法是：在任何 QoR 评估之前，每次代码修改后都先做形式化组合等价性检查。由于进化后的算法不改动 retiming 或时序行为，CEC 对所有 benchmark 都是完备的：组合电路直接检查，时序电路通过单帧有界模型（BMC 深度为 1）形式化验证每个寄存器之前组合逻辑的等价性。具体使用 ABC 框架中的 cec 和 dsat 命令，在每轮迭代的优化前后对所有设计执行 CEC。任何不匹配或 SAT 反例都会立即终止当前迭代并把修正反馈给下一轮规划。

基准评估与规则库的自我进化

一旦通过正确性验证，演化后的 ABC 版本会在大规模分布式工作流下被评估，目标是最大化每轮迭代的反馈密度。每个设计会在八种不同流程下被综合，这是一个完整的消融套件，用于暴露修改后的算法在多种优化机制下的行为差异。这些流程覆盖优化、映射、buffering、gate-sizing 等策略变体，全部基于 ASAP7 7nm PDK。

每个 benchmark 和流程都会采集最终 QoR 指标（post-mapping 面积、STA 时序分析、关键路径延迟）以及从 ABC 直接提取的大量中间结构性信号（AIG 节点数、深度、边数、mapper 级面积与延迟估计、内部遍历统计、每个 pass 的结构增量）。由此系统会计算一个标量 reward 和一个详细的 QoR delta 向量。改进被吸收进全局”冠军”版本；回归触发即时回滚；部分改进（如深度降了但 pre-buffer 面积略升）如果规划器判断与其他正在进化的子系统有协同潜力，也可以被有条件保留。

论文还给出一个很有意思的机制——自我进化的规则库。规则库不仅承担正确性守护，还为每个子系统提供具体的修改策略约束。规划器会持续评估这些规则是否过度限制、是否与 QoR 反馈中涌现的模式错位。当某条规则持续阻挡有益编辑时，规划器可以提出对这条规则的可控放松或细化，前提是满足全局安全约束。这让系统可以从早期的保守行为，逐步过渡到后期更具探索性的结构性修改。

一条值得反复咀嚼的话

论文在结论中留下了一句值得反复读的话：

agent 表现良好的前提是被充足的领域知识所引导；agent 在本工作所研究的 EDA 问题上的成功并非凭空而来，而是建立在 EDA 社区几十年基础性贡献之上——是那些奠基性的算法、工具和知识库，让今天的 agent 得以站在其上继续构建。

换句话说，这不是一个”AI 自动发明 EDA”的故事，而是一个”AI 在人类几十年积累的启发式之上做结构化放大”的故事。论文自己也坦承：agent 擅长在 ABC 已有结构先例的算法方向上做精细化（调整被忽略的阈值、增强深度感知的评分、引入条件启发式），而尝试引入完全新颖的算法构造往往失败，典型失败包括编译错误、段错误、无法自我调试的微妙正确性违规。

迪迦怎么看

论文把仓库级、agentic、自我改进的工具开发作为一种新范式提出来。它的价值不在于替代 EDA 工程师，而在于提供一种可以 7×24 不知疲倦地探索算法变体、在形式化正确性守门下持续迭代的能力——这恰恰是人类工程师最稀缺的资源。

有趣的是，论文观察到进化出的 agent 即使接触了异质的外部研究仓库，在生成新 C 代码时也会压倒性地收敛到 ABC 原生代码风格：头文件布局、命名约定、Abc_Print 使用模式、缩进、宏驱动的默认值，几乎与手写的 ABC 组件难以区分。这暗示着 LLM 在大型遗留代码库上的一个隐藏优势——它会自动学习并尊重既有代码文化。

但这条路的真正门槛，恐怕不是 LLM 本身，而是：你有没有一个像 ABC 这样经过几十年社区锤炼的代码库，让 agent 有东西可以站上去。

原文标题：Autonomous Evolution of EDA Tools: Multi-Agent Self-Evolved ABC

原文链接：https://arxiv.org/abs/2604.15082