新智元报道

编辑：LRST

【新智元导读】从「会写Tcl」，到「能真正推进设计优化流程」，大模型正第一次以Agent形态进入真实EDA工具链。

大模型正在快速进入工程研发现场。

但在 EDA（电子设计自动化）领域，真正难的从来不是「生成一段脚本」，而是让模型能够稳定接入真实工具、持续调用原子能力、理解分析结果，并据此推进下一步优化。

行业真正需要的，不是一个「会聊天的脚本助手」，而是一个能够围绕目标持续分析、执行、纠偏和迭代的EDA Agent。

近日，浙江大学集成电路学院卓成团队构建了OpenClaw + FluxEDA联合架构：以前者作为大模型 Agent 的编排层，以后者作为面向真实EDA shell的统一执行底座，打通从Skills、MCP到端到端优化闭环的关键链路。

论文链接：https://arxiv.org/pdf/2603.25243v1

这套系统已经能够稳定接入时序分析、逻辑综合、仿真验证和物理实现等典型EDA工具，并在Post P&R 自动化ECO、标准单元库子库优化等任务中，完成连续分析与优化闭环。

一句话概括：EDA，终于开始从「AI 辅助写命令」，走向「Agent自主推进流程」。

为什么这件事会首先发生在浙大？

这背后并不是一支只做「LLM + 脚本生成」的团队。浙江大学集成电路学院卓成团队长期深耕电子设计自动化（EDA）、AI for EDA、设计技术协同优化（DTCO）以及集成电路智能制造等核心领域。

团队曾在 EDA 国际顶级会议 ICCAD 上斩获最佳论文奖，实现了中国内地高校作为第一完成单位在该奖项上零的突破。

更关键的是，团队的研究有着完整、真实的产业中试级支撑。依托吴汉明院士牵头的全国唯一12 英寸CMOS集成电路产教融合公共创新平台，很多研究不再停留在 benchmark、脚本 demo 或实验室里的概念验证，而是能够直接放到真实工艺、中试和流片链路中去做闭环验证。

正是基于这些真实的产业场景，团队前期已成功推出 FabGPT 等代表性成果，探索了多模态大模型在晶圆缺陷检测、根因分析及工艺知识问答中的深度应用。如果说FabGPT是团队在AI 赋能制造领域的深厚积累，那么文中介绍的 OpenClaw与FluxEDA，则进一步将探索前沿推进到了AI赋能 EDA的底层智能执行基础设施与闭环优化层面。

这是一条扎根真实产线、面向智能 EDA 未来、不断向前延伸的硬核研究路线。

为什么EDA真的需要Agent底座？

过去几年，LLM+EDA相关工作层出不穷，但很多还停留在三个层面：

• 生成Tcl / Python脚本；

• 做一个能问答的 EDA 助手；

• 在 benchmark 上完成局部优化 demo。

这些工作有价值，但距离真实工业流程还有明显距离。因为真正的数字芯片设计流程，不是调用一次命令就结束，而是一个跨工具、跨步骤、跨上下文的持续执行闭环。

现实问题也很直接：

• 工具入口分散，Tcl / Python / Shell交织；

• 接口不统一，能力边界不清晰；

• 运行状态难维护，长上下文难持续；

• 工具环境复杂，直接暴露给模型风险极高。

这也是为什么「让模型写脚本」并不等于「让模型做EDA」。

图1：FluxEDA范式转变

OpenClaw + FluxEDA：给 EDA Agent 装上「大脑」和「神经系统」

围绕这一目标，团队提出了 OpenClaw + FluxEDA的联合架构：

• OpenClaw扮演「大脑」角色，负责基于 Skills 组织流程、维持全局上下文、做任务编排与策略决策；

• FluxEDA则像「神经系统」，负责把真实 EDA 工具链转化为 Agent 可以稳定调用、可发现能力、可持续运行的执行环境。

FluxEDA并不是简单「包一层 API」。它打通了从TCL gateway、Socket RPC 协议、Python/C++ SDK、CLI 到MCP Server的完整链路，将散落在不同 shell 中的工具能力整理成结构化、可注册、可调用的原子 API，让上层 Agent可以通过统一的api_*接口持续驱动真实工具流程。

更关键的是，它解决了一个现实问题：如何让大模型安全地操作真实 EDA 工具？

FluxEDA并不直接向模型暴露 EDA shell，而是通过MCP + Skill机制，对可调用能力进行显式约束。模型只能调用预先声明的原子接口，在真实工具与 Agent 之间建立一层能力沙箱。

这带来两个直接收益：

• 保证流程稳定运行，降低直接操作复杂工具带来的风险；

• 把复杂EDA上下文「关进笼子里」，节省Context空间，让模型更聚焦于策略规划与优化决策。

图2：FluxEDA系统框架图

图3：FluxEDA+OpenClaw——大模型「自主接管」真实芯片设计和优化迭代流程

实战一

Post P&R自动化 ECO

在真实的 Post P&R 时序分析流程中，FluxEDA 驱动的 Agent 已经能够完成一整套连续操作：

• 读取设计；

• 设置propagated_clock和case_analysis；

• 生成baseline timing报告；

• 抽取setup / hold关键路径；

• 判断问题成因与可能修复方向。

真正值得关注的，不是它「调用了几个命令」，而是它已经形成了围绕真实post-P&R timing问题的连续分析闭环。

根据材料中的实验结果，Agent 在迭代过程中展现出了清晰的战术意识：

• 优先集中修复setup违例；

• 当收益趋于平台期时及时止损；

• 再转入hold清理；

• 在保持核心时序收益的同时完成最终收尾。

最终结果也相当亮眼：

• Setup TNS从-37.36提升到-34.78；

• Hold THS从-1.329降到0.000；

• Hold违例路径从4条降为0条。

这意味着，Agent 已经不只是「能看报告」，而是开始具备围绕真实后端 ECO 任务做连续判断和修复推进的能力。

图4：FluxEDA驱动的自动P&R后ECO修复

实战二

Cell 种类直降76%

如果说自动化ECO展示的是Agent 的「连续修复能力」，那么标准单元库子库优化展示的则是它的「结构洞察能力」。

在工艺和设计早期，工程师往往需要先定义标准单元库的spec。一个非常实际的问题是：

能否针对某个具体电路，裁剪出一个极简子库，让Cell Family类型尽可能少，同时面积和性能尽量接近全库结果？

在这个案例中，FluxEDA配合综合与时序分析工具，让Agent从最小化子库出发，以面积为目标展开探索；随后再从面积较优的候选方案出发，继续做时序恢复与候选比较。

最终交付结果很有冲击力：

• 相比全库baseline，网表Cell种类从128种降到30 种；

• 种类压缩幅度达到76%；

• 总面积从14651缩减到13659；

• WNS 仅出现轻微折损。

这说明，Agent已经不只是「会跑综合」，而是开始具备面向设计结构的分析和搜索能力。

图5：FluxEDA驱动的自动标准单元库子库优化

这件事真正重要在哪？

今天我们讨论大模型进入EDA，最容易陷入的误区是：把「会写命令」误认为「会做流程」。

但对EDA来说，真正稀缺的能力从来不是单点命令生成，而是：

• 对真实工具环境的稳定接入；

• 对分析结果的持续理解；

• 对复杂流程的跨步骤编排；

• 对优化方向的动态调整；

• 对任务目标的连续推进。

而FluxEDA的意义，恰恰就在于它把这些原本割裂的部分组织成了一个统一的系统层，让上层Agent不再直接面对分散的shell和杂乱的工具入口，而是能够在Skills和MCP支撑下，围绕完整任务持续执行。

这意味着，端到端 EDA 不再只是停留在概念层面的愿景。至少在若干代表性的分析与优化任务上，大模型 Agent 已经开始真正进入真实工具链，并承担主要执行闭环。

从「会写脚本」到「能真正执行流程」

FluxEDA并不是又一个泛泛而谈的 「AI+EDA」 概念包装，而是一套已经打通关键系统链路、并在真实案例中验证过代表性流程的Agent执行底座。

结合OpenClaw，这套系统完成了三件关键事情：

• 用Skills组织 EDA 流程；

• 用MCP打通标准化调用；

• 用FluxEDA承接真实工具执行。

它推动的，不只是一次接口改造，而是一种工作流范式转变：

从「能写脚本」，走向「能真正执行流程」；从单点能力，走向系统能力；从随机试错，走向结构洞察驱动的自动化优化。

面向未来，这套 Agentic EDA 工作流还有望进一步引入跨域协同与 physically-aware 的高阶探索能力，继续推动设计制造一体化技术发展。

对于IC行业来说，一个更值得期待的时代或许正在到来：大模型不再只是坐在工具链外「出主意」，而是开始真正走进芯片设计现场，成为流程中的执行者。

结语

真正的分水岭，从来不是模型能不能说得更像工程师，而是它能不能真正做工程师在做的事。

现在，FluxEDA给出的答案已经很明确：Agent进入真实IC行业，不再只是想象。

参考资料：

https://arxiv.org/pdf/2603.25243v1

秒追ASI