DAC 开始给 Agentic EDA 算账：最先值钱的环节并不酷|dac|eda|上下文|信号|大语言模型|工作流|调用

DAC 2026 连排三天的 TechTalk，读起来像一段罕见的行业自我纠偏。

7 月 27 日，主题是“从工具到智能体”，谈全自主 EDA 工作流；7 月 28 日，话题推进到“AI 原生 EDA 技术栈”；到了 7 月 29 日，标题突然变得克制：从热潮走向影响，agentic AI 今天到底在哪里给芯片设计创造了价值？

当然，三场演讲来自不同机构，讲者和立场也不同，不能当成一条连续的技术结论。可这组议程仍然勾出了一条清楚的观察线：行业已经不缺“agent 能调用 EDA 工具”的演示，接下来要回答的是工程账。

架构探索、RTL 质量、验证加速、物理设计优化、design closure，哪些任务能省下真金白银？哪些场景只是把人工点击换成了更多 token、GPU、许可证和重跑？数据换一个项目还能不能用？模型出错后，谁来发现、回滚和签字？

DAC 7 月 29 日这场 TechTalk 没有把重点放在某个产品上。官方摘要反复提到数据可用性、模型泛化、既有 EDA flow 集成、组织经验、生产率和设计风险。这个评价框架，比又一个“自动生成 RTL”的 demo 更接近研发负责人手里的预算表。

一条最朴素的价值线：反馈能不能闭环

Agentic EDA 很容易被讲成模型能力竞赛。模型会写多少 Verilog，会不会解释 timing report，能不能生成 Tcl，当然重要。进入真实项目后，决定价值的往往是另一个问题：它每做一步，能不能拿到可信的工具反馈，并据此修正下一步？

Phoenix-bench 给出了一个很直观的对照。这项预印本研究整理了 511 个经过验证的 Verilator 实例，来自 114 个 GitHub 仓库。研究者发现，给 agent 一个“正确文件在哪”的提示，净提升只有约 1.4 个百分点；加入一轮 testbench 日志反馈，三类 agent 的解决率提升了 42 到 45 个百分点。

这个数字不能直接搬到商业 SoC 项目。开源仓库、Verilator、benchmark 任务和企业验证环境之间差得很远。它仍然揭示了一条很实用的规律：硬件问题很少只是文本定位。bug 可能沿信号流穿过层级和多个模块，改动还要同时通过 fail-to-pass 与 pass-to-pass 测试。可执行反馈比一句“去这个文件看看”更有价值。

顺着这条线看，当前最容易产生 ROI 的任务通常没那么炫。

日志归因、失败聚类、回归结果整理、脚本候选生成、lint 问题修复、规范检索、重复性环境配置，这些工作边界窄，输出可以交给工具检查，错误也容易回滚。它们省下的是工程师查资料、切窗口、等队列、抄命令、整理报告和重复试错的时间。

一个 agent 如果能明显缩短失败分诊（failure triage）的时间，工程价值很好理解。它不需要接管整个验证环境，只要把根因候选、关联日志和建议动作排好顺序，并让工程师迅速复核。

DAC 7 月 28 日的 TechTalk 也把验证 debug 放在核心位置。演讲摘要声称，一套 agentic 架构可以在 15 分钟内生成根因分析和修复建议，并在一组生产问题上实现 70% 的首次端到端成功率。这是演讲者所在公司的口径，公开摘要没有披露样本规模、问题分布和成功定义，不能当作独立 benchmark。它仍释放了一个清楚信号：验证 debug 正被厂商当作近期最有机会兑现的入口。

架构探索：先扩大选择，再谈替人决策

架构探索天然适合 agent。候选空间大，仿真和估算工具可以提供性能、功耗、面积、带宽、延迟等反馈，很多动作又能并行执行。过去工程师没时间跑完的组合，现在可以让 agent 先生成方案、调用模型、整理结果，再把有希望的路径推到人面前。

价值主要来自两件事：增加有效试验数量，缩短每轮决策等待。

边界也很明显。架构目标很少只有一个数字。性能提升可能换来功耗、面积、软件适配、验证难度和供应链成本。早期模型还可能只是一组代理估算，离真实工作负载、微架构细节和物理实现有距离。

因此，架构探索阶段适合让 agent 做“搜索放大器”。工程师定义目标、约束和不可触碰的边界，agent 扩大候选池并留下每轮筛选依据。最终选择仍需要架构、软件、验证和实现团队共同负责。这里的 ROI 是“看过更多可信选项”，不是“模型替公司决定下一颗芯片”。

RTL 质量与验证：最靠近近期收益

RTL 质量分析处在一个舒服的位置。lint、编译、仿真、formal、CDC 检查和回归都能产生结构化反馈。agent 可以解释报告、定位上下文、生成局部修复候选，再把结果送回原工具验证。

只要权限被限制在分支或沙箱里，失败成本也相对可控。改坏了，测试会报；修复引入回归，pass-to-pass 检查会暴露；结论不稳定，还可以要求复现。

验证加速的价值同样清楚。test plan 草案、coverage gap 分析、失败聚类、波形与日志摘要、根因候选排序、回归调度，都包含大量高频、重复、上下文密集的工作。工程师真正稀缺的部分，是判断规格意图、设计高价值激励、识别环境错误和决定风险是否已经被充分覆盖。

这条边界必须守住。coverage 上升不等于规格完整，测试通过也不等于所有关键场景都被理解。复位、低功耗、CDC、安全相关逻辑和关键时序约束仍要有明确的人工 review。agent 能把证据送到人面前，不能替责任人签字。

物理设计：局部动作有价值，长周期执行仍难

物理设计也有丰富的工具反馈。拥塞、时序、功耗、面积、DRC、IR drop 等报告都可以成为下一轮动作的依据。读报告、生成 Tcl、比较多个 floorplan、尝试局部优化和处理明确 ECO，已经具备 agent 化的技术条件。

难点在于，这里是高维、多目标、长周期的优化问题。一个动作可能改善时序，却恶化拥塞或功耗；当前阶段看起来有效的选择，可能在后续 CTS、布线或 sign-off 时付出代价。工具版本、运行模式、设计数据库状态和企业脚本规范，也会改变同一句命令的含义。

PDAGENT-BENCH 的当前预印本包含 353 个任务和 11 个模型。论文摘要给出的例子显示，模型在 Innovus 脚本生成上的成绩为 42.2%，而长周期、多阶段推理仍明显受限。论文同时发现，加入人类技能约束后，端到端物理设计表现会改善。

另一项当前为 v3 的 FluxBench 预印本，把 PicoRV32 放进商用 RTL-to-GDS flow。论文摘要指出，领域技能能帮助 agent 理解子任务，却不能保证长周期流程可靠完成；工具版本或执行模式造成的 Tcl 接口不匹配，是物理设计失败的重要来源。更值得采购团队注意的是，论文提出的 Token ROI，也就是把设计改善与 token、运行时间和成本放在一起衡量的效率指标，在设计进展相近的 agent 之间最多相差 141 倍。

这些 benchmark 不能代替企业 PDK、真实 IP 和生产 flow 上的试点。它们已经足够提醒行业：会解释一份报告，与能在数十轮工具调用后保持设计状态一致，是两种能力。物理设计的近期价值更适合从局部、可回滚任务切入，逐步扩大权限。

Design closure：最值钱，也最容易算错账

Design closure 是所有愿景里最诱人的一段。时序不收敛，agent 自动查报告、改参数、重跑、比较结果；DRC 有残留，agent 生成修复、调用工具、继续迭代。工程师回家以后，机器还在推进。

7 月 27 日的 DAC TechTalk 就展示了这种“全自主”方向，覆盖 C-to-RTL-to-GDS、PPA 优化、模拟/混合信号、物理验证、DRC 修复和 SVRF deck 生成，并带出 Siemens Fuse EDA AI System 与 Fuse Agent。这里的“全自主”和“消除人工干预”来自会议演讲摘要，带有明确的厂商展示属性。

工程现场要多算几笔账。

第一笔是许可证和算力。agent 能主动发起更多实验，可能减少人工等待，也可能把 EDA 许可证、队列、GPU 和 token 消耗推高。

第二笔是重跑成本。错误动作若要到数小时后才能被发现，闭环越长，浪费越大。

第三笔是状态管理。脚本、约束、工具版本、数据库检查点和历史动作必须一致，否则 agent 可能在错误上下文里继续优化。

第四笔是审核成本。系统生成十个候选方案，工程师要花多久排除九个？如果审查成本接近人工完成成本，自动化只是把工作换了形状。

最后一笔是责任。sign-off 并不是“工具跑完了”。关键时序、物理验证、可靠性、安全和工艺相关判断，最后仍要由有权限的人确认。

Design closure 的 ROI 因此不会只看“有没有跑到 GDS”。更可靠的指标包括：有效迭代次数、达到约束的成功率、人工接管频率、每次改善的许可证与算力成本、错误回滚时间，以及最终证据是否可审计。

芯片企业该怎么选第一个场景

一个可落地的 agentic EDA 项目，可以先过六道问题。

• 任务边界是否足够窄，成功与失败能否被工具判定？

• 反馈要等几秒、几分钟还是几小时，错误会积累多远？

• agent 的动作能否在沙箱执行、逐步留痕并随时回滚？