Agent接管EDA工作流，不只寫腳本！浙大打通真實芯片設計閉環

新智元報道

編輯：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