新智元报道
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从最小化子库出发，以面积为目标展开探索；随后再从面积较优的候选方案出发，继续做时序恢复与候选比较。
关键在于，Agent并不是盲目堆单元、机械试错。它能够读取PrimeTime关键路径报告，并基于路径结构识别设计中的关键薄弱点，例如前端驱动偏弱、局部闭合能力不足以及部分低频单元冗余，再据此做有针对性的补强与剪枝。
最终交付结果很有冲击力：
相比全库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