芯片人看AI:我做了一个月ECO,一个工具让我重新思考了整个流程

约12000字 · 阅读约22分钟

有一次做ECO，我花了整整一个月。

不是那种改一行代码跑一遍flow的轻松活。是那种bug列表排了一串，三四个bug要合在一起改，改完之后手动做ECO，每一个patch都要反复确认逻辑对不对、等价性能不能过、后端能不能接的苦差事。

而且踩了一堆坑。

版本用错了，改了半天发现基线不对，等于白干。逻辑找错了，定位的module根本不是出bug的地方，改了等于没改。最折腾的一次是等价性检查的SVF文件用错了，工具报了一堆diff，我花了一整天排查，最后发现不是逻辑的问题，是我自己配置文件搞错了。

一个月。三四个bug。改完验证完归档完。

ECO这三个字，做过的人都知道，那是流片前最煎熬的日子。

后来我实在受不了了，开始折腾工具。试了一圈之后，找到一个国产ECO工具，彻底改变了我对ECO这件事的理解。然后我又在这个工具之上搭了一套Agent系统，把整个ECO流程从「人扛」变成了「Agent扛」。

但在聊这些之前，先说说ECO到底是什么，为什么这么痛苦。

---

一、ECO到底是什么？为什么这么痛苦？

先给不了解芯片的朋友解释一下。

芯片设计的流程很长。从写RTL代码到最终交付版图给工厂生产，中间要经过综合、DFT插入、布局布线、时序分析、物理验证等十几个步骤。每一步跑完都会产出一堆数据文件，后面的步骤依赖前面的结果。整个链条像一条流水线，任何一环改动，后面都要跟着动。

ECO的全称是Engineering Change Order，工程变更指令。就是在后端已经做到一定程度之后，你需要改前端RTL的逻辑。可能是修bug，可能是改功能，可能是客户临时改了需求。

但问题是，后端已经跑完了。你改了RTL，理论上应该从头重跑一遍整个流程。但时间不允许，流片的deadline就在那卡着。所以你需要做的是，只改必要的地方，让后端的增量修改尽可能小。

ECO就是在已完工的房子上改装修，而不是拆了重盖。

痛苦在哪？三个字，定位、修改、验证。

定位。bug的现象你知道，但出bug的module在哪？光定位这个环节，有时候就要花好几天。复杂的芯片层级很深，信号从顶层传到底层可能经过十几级例化，你要一层一层剥开去找。

修改。找到了怎么改？改多了后端不接，patch太大了布局布线要重跑。改少了bug没修干净。要找到那个「刚刚好」的修改量，非常考验经验。而且你要考虑的不只是逻辑对不对，还要考虑timing能不能收敛、scan chain会不会断、DFT覆盖率会不会掉。

验证。改完了得证明你没改出新的bug。等价性检查，对比修改前后的网表，确认逻辑功能完全一致。这一步出了问题最抓狂，diff报出来的是一堆门级的比较结果，你得一个一个去看。而且这里有一个很tricky的事情，你修改的只是SYN阶段的网表，但后端用的是DFT网表和P&R网表。所以你得把修改从SYN一路传递到DFT再到P&R，每一个阶段都要做等价性检查。

这引出了ECO里一个很核心的概念，stage-based verification。你的芯片设计流程保留了几级网表，ECO就要分几个阶段来做。最简单的是2-stage，SYN网表和P&R网表。复杂一点的是3-stage，SYN、DFT、P&R三级。最复杂的是4-stage，加上Floorplan网表。ECO必须按顺序做，先SYN再到DFT再到P&R，不能跳级。每一级的等价性检查通过了，才能进入下一级。

我那次一个月的ECO，就是定位、修改、验证三个环节反复循环。定位错了重来，修改大了返工，验证报diff排查到半夜发现是SVF文件搞错了。

二、ezeco：一个重新定义ECO的工具

那个月之后我做了一个决定，不能再这么干了。

做ECO的工程师都知道，市面上的ECO工具就那么几个，大厂的有，国产的也有。但实际用下来，各有各的痛点。有的跑时间太长，有的自动化程度不够还需要手工辅助，有的跑出来的patch不理想甚至动到不该动的地方。

后来我接触到了ezeco，奇捷科技（Easy-Logic Technology）的ECO工具。这是一家2014年成立的EDA公司，总部在香港，研发中心在深圳，专门做functional ECO。国产EDA公司不少，但专门深耕ECO这一个点做深做透的，我了解的不多。他们从2018年拿到第一个订单，到现在已经有超过40家客户，包括龙芯、飞腾这些国内头部芯片公司。

用了之后我的感受是，这个工具不只是在做ECO这件事，它重新定义了ECO应该怎么做。下面我详细拆解。

2.1 GTECH Flow：从根源上改变ECO的精度

这是我觉得ezeco最聪明的设计，也是它跟其他ECO工具最大的区别。

传统的ECO工具是怎么找ECO点的？对比修改前后的RTL。但这里有个问题，RTL经过综合工具优化之后，门级网表的结构跟RTL已经面目全非了。综合工具做了大量的优化，寄存器合并、逻辑重定时、资源共享，RTL里的一行代码在网表里可能对应完全不同的结构。所以直接对比RTL来找ECO点，准确度有限。

ezeco换了一个思路。它对比的不是RTL，而是GTECH netlist。

GTECH是RTL综合过程中elaboration之后直接生成的中间网表，未经综合工具任何优化。你可以把它理解为RTL的「直译」版本，结构跟RTL一一对应，没有经过任何变换。Old GTECH和New GTECH对比出来的差异，就是RTL修改在门级最真实的映射。2024年DAC上ezeco专门展示了这个GTECH flow。

这样做的好处是什么？对比出来的ECO点更准确，也更符合手工修改的思维方式。而且GTECH对比不受结构差异的影响，比如不同的clock gating tree、不同的pipeline结构，这些在传统网表对比里会造成大量噪声，但在GTECH层面不存在这个问题。

还有一个实际的好处。传统flow里你需要同时提供old RTL、new RTL、old netlist、new netlist。GTECH flow里你只需要提供old GTECH和new GTECH，输入更简洁，出错的机会更少。

2.2 Stage-Based Flows：覆盖所有设计场景的内置Flow

ezeco提供五种内置的stage-based ECO flow，每种对应一种常见的ASIC设计场景。这个设计思路跟我一直讲的Flow方法论不谋而合，好的flow应该是标准化的、可复用的、降低人为错误的。

1-stage ECO flow。适合小规模数字电路，比如mixed-signal ASIC里的数字模块。这种场景ECO请求频繁但改动范围小，ECO窗口期短，1-stage flow直接在P&R网表上做ECO，快速出结果。

2-stage ECO flow（两种变体）。第一种适合传统前后端分工的模式，前端覆盖RTL到DFT，后端只管P&R。第二种适合需要RTL handoff的场景，设计过程中RTL直接交给实现团队。

3-stage ECO flow。适合大规模数字ASIC，比如手机应用处理器、网络交换芯片。SYN、DFT、P&R三级网表都保留，ECO按顺序做，每一级都做等价性检查，风险最小化。

4-stage ECO flow。适合超大规模ASIC，比如GPU或AI服务器芯片。在3-stage的基础上加了Floorplan网表这一级。因为这种芯片block很多，block之间的距离会影响patch的timing，Floorplan阶段的物理引导可以帮你在P&R之前就调整好patch逻辑的位置。2025年DAC上ezeco推出了stage-based ECO design environment，根据Easy-Logic的数据，这些内置flow把ECO turnaround time减少了50%以上。

2.3 Learning ECO和i-Learning：让手工修改也能自动传递

这个功能解决了一个很实际的问题。

有时候简单的ECO，工程师可以手工改综合网表，改几个gate、调几根线就行了。但问题是你手工改了SYN网表之后，DFT网表和P&R网表怎么办？它们跟SYN网表的结构完全不一样，有scan chain插入、有物理布局信息，你不可能用同样的方式手工改。所以你需要一种方式，把你在SYN阶段的手工修改「传递」到下游stage。

ezeco的Learning ECO就是做这个的。你手工改了SYN网表，ezeco通过对比你的修改版和原始版，自动学习出修改点，然后把这些修改自动应用到DFT和P&R网表上。你不需要重新综合，后续stage的ECO结果跟手工修改几乎一致。

更进一步的i-Learning ECO，在Learning的基础上做迭代优化。每次迭代都用上次的结果作为基准，通过逻辑重构、门级行为识别、patch逆向工程等手段逐步缩小patch电路。每一轮都比上一轮更精炼。你可以指定迭代次数，比如ezeco -3syn config -il 3就是做3轮迭代优化。工具会先跑一轮标准ECO，然后自动跑3轮learning，每一轮都试图在前一轮的基础上把patch缩小。

什么时候需要i-Learning？常规ECO跑出来的patch太大、层级设计导致跨层patch优化失败、RTL和门级混合block导致跨block优化失败，这些情况i-Learning能帮你把patch磨到最小。代价是跑的时间更长。

2.4 Inference Flow（Second ECO）：等价性检查失败的救星

还有一个让我觉得很贴心的功能。

ECO做完之后，等价性检查报了non-equivalent points，怎么办？传统做法是回去检查你的ECO约束、检查GTECH对比是否完整、检查层级结构有没有漏掉什么。很痛苦，因为你不知道到底是ECO没做好，还是约束设错了，还是GTECH对比漏了。

ezeco的Inference Flow（早期版本叫Second ECO）直接用等价性检查报出来的non-equivalent points作为输入，再跑一轮ECO。它的base netlist不是原始网表，而是上一轮ECO产出的「有缺陷的」网表。相当于在上一轮结果的基础上做修补，针对性解决那些non-equivalent的点。

这在实际使用中非常好用。很多时候等价性检查差一两个点，用Inference Flow补一轮就过了，不用从头重跑。

2.5 多参数并行与Effort级别

ezeco有多种算法并行计算，不同参数的时间复杂度和优化效果各不相同。三档effort，fast用来验证输入是否正确，通常十分钟到半小时，这一档不是为了得到好的结果，是帮你快速确认配置文件没有填错。normal是最常用的模式，一到三个小时。weekend跑更久，几小时到十几小时，但一定能得到工具能力范围内的最优解。工具跑完会在log里打印是否获得了最优解，如果normal模式提示没有获得最优解，你可以切到weekend模式再试。

还有一个不可忽视的因素，作为国产EDA公司，奇捷的技术支持响应很快，遇到问题可以快速对接甚至现场支持。在ECO这种争分夺秒的场景下，技术支持的响应速度有时候比工具本身还重要。

用了ezeco之后，我最大的感受是，ECO这件事从「人扛」变成了「工具扛」。大部分ECO可以自动化完成，不用再人工硬啃。

不是工具帮你省了一点时间，是工具改变了整个ECO的工作方式。

三、ECO Flow实战：从安装到等价性检查

上面讲了ezeco的各种flow设计，可能有些抽象。这一节我用一个3-stage flow的例子，把整个ECO过程从头到尾走一遍，让你看看一个完整的ECO项目到底要经过哪些步骤。

Step 0，安装和准备。

安装license，然后在工作目录下运行ezeco -gen_scripts。这个命令会生成一个压缩包easyeco_scripts.tar.gz，解压之后就是所有需要的脚本模板。如果这个命令能正常生成，说明license安装成功。如果报红字错误，说明license没装好，联系IT或Easy-Logic的AE。

Step 1，准备输入文件。

你需要准备以下文件。

Library文件。Liberty格式的库文件（.lib），不能是.db格式。你可以指定每个lib的路径，也可以给一个lib list文件。

GTECH网表。Old GTECH和New GTECH。这一步很关键，你需要用综合工具分别生成修改前后的GTECH netlist。ezeco的安装包里自带了GTECH DesignWare的Verilog库文件ez_gtech_cell.v。如果你不知道怎么生成GTECH，ezeco的scripts目录下有dc和genus的综合模板可以参考。

各级网表。New SYN网表（修改后RTL重新综合的结果）、Old SYN、Old DFT、Old P&R。注意New DFT和New P&R不需要你提供，ECO就是帮你生成这些。

SVF/JSON文件。综合过程中生成的优化记录文件。DC用SVF，Genus用JSON。这些文件记录了综合工具做了哪些优化操作，等价性检查需要这些信息。

DFT约束。Scan chain相关的pin约束，确保ECO过程中scan chain不被破坏。有三种方式可以设置，直接填pin值、读约束文件、或者直接读formal verification脚本让ezeco自动提取。

Step 2，填写配置文件。

所有信息填到一个文件里，ezeco_input.config。这是唯一需要你手动编辑的文件。Library路径、GTECH路径、网表路径、SVF路径、DFT约束、top module名、输出路径、effort级别，全部在这里设置。文件本身有详细的注释引导你填写。

Step 3，按顺序执行ECO。

3-stage flow的执行顺序是这样的。

先在SYN stage做ECO。

ezeco -3syn ezeco_input.config

这一步用GTECH对比找出ECO点，然后在Old SYN网表上打patch，生成ECOed SYN网表。

然后在DFT stage做ECO。

ezeco -3dft ezeco_input.config

这一步读取SYN ECO产出的ECO points script，在Old DFT网表上做相应的修改。注意ECO points是自动从SYN stage传递过来的，你不需要手动指定。

最后在P&R stage做ECO。如果是pre-mask，用-3prepr。如果是post-mask（metal-only ECO），用-3postpr。

Step 4，等价性检查。

这是验证ECO结果正确性的关键步骤，也是整个ECO流程里最考验耐心的环节。

等价性检查用的是formal verification工具，业界主流的两个，一个是Conformal LEC（属于某家大EDA厂），一个是Formality（属于另一家大EDA厂）。两个工具的原理一样，都是通过形式化方法证明两个设计的逻辑功能完全等价，但风格和操作方式有一些差异。

Conformal LEC用的是Golden vs Revised的概念，把修改前的设计定义为Golden（基准），ECO后的设计定义为Revised（修改版），然后做逻辑锥比对。它的优势是对大规模设计的处理能力比较强，支持hierarchical verification。Formality用的是Reference vs Implementation的概念，逻辑类似，但它跟Design Compiler是同一家工具链，SVF文件可以直接读取，不需要额外转换。用DC综合的项目通常用Formality更方便。

不管是哪个工具，做ECO等价性检查都有一些共同的要点。你需要正确设置SVF/JSON文件，这些文件记录了综合工具的优化操作，没有它们formal工具无法理解网表跟RTL之间的映射关系。DFT相关的pin约束要设对，scan enable之类的信号要正确disable，否则scan chain的逻辑差异会报一堆假diff。clock gating建模可能需要额外处理，综合工具插入的clock gating cell在formal工具里需要正确建模。多比特寄存器的声明也很重要，综合工具会把单比特寄存器合并成多比特的，如果formal工具不知道这个映射关系，也会报假diff。

因为改动是从SYN到DFT到P&R逐级传递的，所以等价性检查也是逐级验证。New RTL（或New SYN）vs ECOed SYN，确认SYN stage的ECO正确。然后ECOed SYN vs ECOed DFT，确认DFT stage的传递正确。最后ECOed DFT vs ECOed P&R，确认P&R stage的传递正确。

为什么要逐级做，而不是直接New RTL vs ECOed P&R？因为P&R网表跟RTL之间的差异太大了，经过综合优化、DFT插入、物理实现，结构已经面目全非。直接对比的话，formal verification几乎不可能通过，你需要写大量的约束和特殊处理。逐级做的好处是，相邻stage之间的差异较小，formal verification更容易通过，写验证脚本的难度也低得多。如果哪一级出了问题，你只需要定位到那个stage，不用从头排查。

在实际操作中，等价性检查最耗时的不是跑工具本身，而是debug diff。工具报了non-equivalent points，你得分析是真diff还是假diff。真diff说明ECO没做好，逻辑确实不等价。假diff通常是约束设置不对，SVF文件遗漏、DFT约束不完整、clock gating建模不准确，都会导致假阳性。区分真假diff需要你对设计本身和formal工具的机制都有足够的理解。这也是为什么后面我要做Verification Agent，把这部分经验沉淀下来。

如果等价性检查报了non-equivalent points怎么办？这时候就用前面提到的Inference Flow，拿那些non-equivalent points做输入再补一轮ECO。不需要从头重跑，只需要在当前stage做一次修补。

整个流程画成图，是这样的。

New GTECH vs Old GTECH → ECO Points
↓
SYN ECO Old SYN → ECOed SYN	DFT ECO Old DFT → ECOed DFT	P&R ECO Old P&R → ECOed P&R
↓ ECO points传递	↓ ECO points传递	↓ 输出最终结果
LEC: New RTL vs ECOed SYN Formality / Conformal LEC	LEC: ECOed SYN vs ECOed DFT Formality / Conformal LEC	LEC: ECOed DFT vs ECOed P&R Formality / Conformal LEC
如果LEC报non-eq → Inference Flow修补（不需要从头重跑）

图，3-stage ECO Flow。GTECH对比找ECO点，逐级传递，逐级验证。LEC不过则Inference Flow修补。

ezeco还会自动生成后续操作需要的Tcl命令和增量DEF文件，方便你直接在后续工具里使用ECO结果，不需要手动转换格式。从输入到输出到验证到后续工具对接，一条龙。

四、给好工具加个包装：Design Agent

ezeco好是好，但有一个现实的问题。

它是命令行工具。配置文件有一堆参数要填，library路径、GTECH路径、SVF路径、DFT约束、effort级别、post-mask参数……前端Designer面对这些参数头都大了。而且命令行界面没有实时反馈，出错了不知道哪一步出了问题，只能翻log。根据我之前做的统计，单次配置耗时大约30分钟，错误率高达20%。新人上手的学习周期大约一周。

我在Lint那篇里聊过一个理念，好的flow应该降低使用门槛，让不熟悉工具的人也能正确使用。ezeco本身是个好工具，但用好工具需要包装。

所以我做了一件事，搭了一个Design Agent的雏形，ECO是其中的一个子Agent。这个Design Agent不是什么大工程，但解决了几个很实际的痛点。

Web界面。做了一套Web端的可视化配置界面。可折叠分组，参数按类别组织，library一组、netlist一组、DFT约束一组。每个参数有输入指引和格式提示。原来填配置文件要30分钟还容易出错，现在几分钟搞定。Web的好处是团队成员不用安装任何东西，浏览器打开就能用。新人的学习周期从一周缩短到一天。

多参数并行执行。这是我觉得最有用的一个功能。ezeco有多个可调参数，不同参数组合产生的ECO效果不一样。三档effort各有用途。串行跑多组参数对比太耗时了。Design Agent里我做了并行调度，多组参数同时跑，跑完直接对比结果。这让多方案对比的效率大幅提升。

实时监控。终端输出解析，ANSI彩色终端输出实时刷新到Web界面。以前你不知道ECO跑到哪一步了，只能等。现在界面上一目了然，当前在哪个stage、跑了多久、有没有报错。错误率降低了大约80%。

参数标准化。JSON加Shell脚本实现参数标准化，配置可以保存、加载、分享给团队其他成员。新人不需要从头学，一键加载别人的配置就能开始。还做了自动报告生成和智能推荐功能，根据历史记录推荐effort级别和参数组合。

这个Design Agent的开发过程本身也值得多聊两句，因为它是一个AI辅助开发的真实案例。

我用了DeepSeek、元宝、Qwen这几个大模型，帮我生成了大约75%以上的代码。而且95%的生成代码可以直接使用。Web前端的框架代码、终端颜色解析、多进程管理、折叠动画，这些我本来要写好几天的东西，AI帮我几个小时就搞定了。整个GUI框架的开发周期，从预期的两周缩短到了三天。

AI辅助开发有三个层次。第一层是代码生成，你描述需求，它帮你写框架。第二层是功能实现，遇到终端颜色解析这种专业问题，AI直接给出完整方案。第三层是问题解决，并行执行时输出混乱这种debug难题，描述一下现象，AI十分钟给出解决方案。

这不是AI替我写代码，是AI放大了我的能力。我提供业务逻辑和设计思路，AI负责把思路变成可运行的代码。这跟我一直在讲的Flow理念是一致的，好的工具不是让人变成工具的奴隶，而是让人的想法能快速落地。

五、从Design Agent到真正的Agent

聊到这里，你可能已经看出来了。

Design Agent是我手工搭的一个「半自动化」系统。Web界面、并行调度、实时监控，这些都是在帮人更好地操作工具。但它还是一个被动的工具，你点一下它跑一步。

真正的Agent应该是什么样？

之前我做过一个AI驱动的芯片流程自动化Agent系统。那个项目让我想清楚了很多事。下面我把整个设计思路完整地展开。

5.1 为什么要用Master-Agent架构？

最直觉的做法是用一个Agent干所有事，把所有能力写在一个超长的Prompt里。这个方案我试过，不行。Prompt太长了LLM容易混乱，把诊断逻辑和执行逻辑混在一起，一个地方出错整个系统崩溃。而且所有能力耦合在一起，想优化某个环节，改了Prompt可能影响其他功能。

Master-Agent架构的核心思想是，一个Master Agent做路由，多个Sub-Agent各做各的专业事。每个Agent只做一件事，Prompt更精准，专注于特定领域的任务处理。诊断不准，只改Diagnostic Agent，不影响其他模块。加新功能，加个新Agent就行。

这个架构在之前的Agent系统里已经验证过了。从验证流程到Lint流程，Master做路由的思路是可复用的。

5.2 NLP任务解析：让用户用自然语言就能操作

Agent系统的入口是一个NLP解析器。用户说「帮我做个ECO」「跑一下normal effort」「ECO失败了帮我看看log」，系统要能理解这些自然语言，转换成可执行的操作。

我对比过三种方案。规则引擎准确快速，但覆盖不了所有情况。Fine-tune模型最准确，但需要大量标注数据，不现实。最后选了Prompt工程，用结构化输出加置信度机制来做。意图识别准确率能做到92%，平均响应时间2到3秒。

关键是，NLP解析不是独立运行的，它跟Master Agent是配合的。NLP先做一轮粗解析，把自然语言变成结构化的意图加参数，然后Master Agent根据解析结果做路由，决定分发给哪个Sub-Agent。这个设计保证了NLP解析的容错性，即使解析不够准确，Master Agent还能根据上下文做二次判断。

5.3 ECO Agent的五个角色

ECO作为整个Design Agent系统的一个子Agent，内部又是一个完整的Master-Agent架构。五个角色，各有分工。

▶ Master Agent（主控）——理解用户意图，做路由。用户说「帮我做个ECO」，Master理解这是ECO任务，把它分发给ECO Sub-Agent。Master负责所有Agent的调度和协调，它本身不做专业的事，只做路由。这一层我用一个通用能力强的大模型，比如DeepSeek或者GPT-4级别的模型。它的核心能力是理解上下文和做出正确的分发决策。

▶ Diagnostic Agent（诊断Agent）——这是整个ECO Agent里最智能的部分。它的工作是分析ECO失败的log，定位问题出在哪。是版本搞错了？SVF配置不对？ECO点没找对？patch太大？是GTECH对比阶段就出了问题，还是ECO执行阶段才失败的？它需要读log、分析error message、理解工具的输出格式、给出诊断建议。这一层我用推理能力最强的模型，比如Claude Opus或者Gemini级别的。我踩过的那些坑，版本用错、逻辑找错、SVF配错，如果Diagnostic Agent在，它能直接告诉你「你的SVF文件版本不对，请检查第5行的路径」。这个能力不是锦上添花，是能省掉一整天排查时间的生产力工具。

▶ Execution Agent（执行Agent）——调用ezeco跑ECO。根据用户意图自动组装命令，选择stage和effort级别，提交到集群执行，收集结果。多参数并行调度也在这一层。这一层基本是脚本和工具调用，不需要多强的LLM，甚至可以用一个轻量模型来组装命令就行。重要的是执行逻辑的可靠性，不是LLM的推理能力。

▶ Verification Agent（验证Agent）——跑等价性检查，分析diff。如果报了diff，它要区分是真diff还是配置diff。所谓真diff，是逻辑真的不等价，说明ECO没做好。配置diff，是SVF或约束设置差异导致的假阳性，逻辑其实是对的。这一步如果做好，至少能省掉一整天的排查时间。这一层需要一个擅长代码和逻辑分析的模型。

▶ Knowledge Agent（知识Agent）——维护ECO知识库，记录每次ECO的过程和结果。哪个module改了什么、用了什么effort、跑了多久、哪些参数组合效果最好、遇到过什么坑、怎么解决的。下次遇到类似的bug，直接检索历史经验。Knowledge Agent还有一个重要的职责，就是为新项目推荐ECO策略。根据历史数据，告诉你「这个类型的修改，上一次normal effort就搞定了，不需要跑weekend」。这一层用一个擅长总结和检索的模型就够了。

画成架构图。

Master Agent 理解意图 · 路由分发 · 协调全局
↓
Diagnostic Agent 分析log · 定位问题 · 区分错误类型	Execution Agent 调用ezeco · 多参数并行 · 集群调度	Verification Agent 等价性检查 · diff分析 · 真假diff区分
诊断失败自动降级 →	失败则重试 →	不过关则反馈 ↑
Knowledge Agent 记录经验 · 检索历史 · 推荐策略（贯穿全程）

图，ECO Sub-Agent的Master-Agent架构。Master路由，三个专业Agent各司其职，Knowledge Agent贯穿全程。

5.4 不同角色用不同的LLM

这是整个架构里最关键的技术决策。

为什么不同的Agent要用不同的LLM？因为每个角色对LLM的要求不一样。Diagnostic Agent需要分析ECO失败的log、定位问题，这需要更强的代码理解和逻辑推理能力，用强推理模型。Execution Agent调用工具跑ezeco，这一步甚至不需要LLM，脚本就能干。Verification Agent需要分析diff和诊断问题，这需要擅长代码分析的模型。Knowledge Agent需要做知识检索和归纳，这需要擅长总结的模型。Master Agent需要理解自然语言和路由决策，用一个通用能力强的大模型就够。

如果用一个模型干所有事，Prompt会非常长，LLM容易混乱，一个地方出错整个系统崩溃。这是实际项目中踩过的坑。

学术界也在验证这个方向。2025年ACL上一篇叫MasRouter的论文，专门研究了Multi-Agent System里的LLM路由问题。它提出了一个级联控制器网络，先决定协作模式，再分配角色，最后给每个Agent选最合适的LLM。实验显示在HumanEval上比SOTA方法节省52%的开销。另外一篇叫xRouter的论文，用强化学习训练了一个路由器，根据任务难度动态选择不同档位的模型。还有一篇叫Pick and Spin的论文，在四个不同规模的模型上做了实验，发现智能路由加动态编排比静态部署的准确率高21.7%，延迟低33%，成本低25%。

这些数据很能说明问题。不同的Agent用不同的LLM，不是省钱的问题，是每个模型有自己的擅长度，让每个Agent用最适合它的模型做最合适的事，整体效果最好。

5.5 三级降级策略

AI最大的问题是不稳定。今天准确明天可能出错。所以每个环节都要有降级方案。

我设计的是三级降级。第一级是AI模式，所有Agent正常运行，NLP解析+Master路由+Sub-Agent执行。第二级是规则模式，AI不可用的时候，退回到基于规则的命令匹配。你说「做ECO」，系统用正则匹配识别意图，直接调脚本执行。第三级是传统模式，连规则都覆盖不了的情况，退回到手动执行。命令行操作，跟没有Agent系统一样。

保证系统永远可用，AI挂了流程还能跑。降级策略保证的是，即使AI不可用，你的工程流程不会中断。这是系统可靠性，不是AI价值的否定。

没有AI你能干活，有AI你的效率是另一个量级。降级是兜底，不是退路。

六、Agent在芯片落地的深度思考

上面讲了架构设计。这一节我想跳出具体的ECO场景，聊聊Agent在芯片设计落地这件事本身。这是我过去两年一直在思考的问题。

6.1 Agent落地的三个层次

从我自己的实践来看，Agent在芯片设计中的落地可以分三个层次。

第一层，工具包装层。就是把现有的命令行工具包一层友好的界面，加上智能配置、实时监控这些。Design Agent做的就是这一层。它的核心价值是降低使用门槛、减少人为错误。这一层的技术难度不高，但实际效果最直接。新人上手快了、配置错误少了、多方案对比效率高了。

第二层，智能诊断层。在第一层的基础上加上AI的理解能力。工具跑失败了，Agent能自动分析log、定位问题、给出建议。Designer不需要自己去翻几百行的log找error。这层的核心挑战是诊断的准确率。芯片EDA工具的log格式非常复杂，不同工具的输出风格完全不同，而且很多时候真正的错误原因藏在warning里面，不是error里面。

第三层，自主决策层。Agent不只是诊断问题，还能自主做出决策。ECO跑完了patch太大，Agent自己决定切到i-Learning模式。等价性检查报了diff，Agent自己判断是真diff还是假阳性，如果是假阳性就自动调Inference Flow修补。这一层目前还在探索中，因为芯片的容错率太低了，自主决策的风险很大。

6.2 不只是ECO，是一套通用的Agent方法论

我在之前的Agent系统项目里验证过，Master-Agent架构从验证流程到Lint流程到ECO流程，是可复用的。Master做路由，Sub-Agent做专业事，三级降级保证永远可用。

不只是ECO，芯片设计的很多环节都可以用同样的思路来做Agent化。寄存器规范检查，Designer用自然语言描述需求，Agent自动检查配置是否符合规范。Memory选型，根据设计需求自动推荐，综合考虑面积、功耗、timing。波形调试，上传波形文件，用自然语言描述你要查什么信号，Agent直接返回结果。综合约束生成，根据设计特点和timing目标自动生成约束文件。这些场景有一个共同特点，它们背后都有成熟的工具和结构化的数据，AI做的是让这些能力变得「可对话」。

这也引出了一个通用的Agent落地原则。不是什么都要从头搭，而是在已有的工具和数据之上加一层AI的理解和交互能力。你的寄存器数据库已经有了，你的memory选型工具已经有了，你的波形解析器已经有了。Agent不需要替代这些，它做的是连接和理解。把用户意图翻译成工具能执行的指令，把工具的输出翻译成人能理解的结论。

这也是我一直强调的判断标准。把AI去掉之后，你的工具还是能跑，只是没那么方便、没那么智能。AI不是产品本身，而是产品的能力放大器。这个标准很重要，它能帮你区分什么是真正的Agent化，什么是包装成AI的传统工具。

6.3 我的规划：下一步做什么

说说我接下来的规划。

短期，完善ECO Agent的闭环。当前Design Agent还停留在第一层（工具包装层）。下一步是把Diagnostic Agent和Verification Agent真正跑起来。特别是Verification Agent的真假diff区分能力，这是实际需求最强烈的。每次等价性检查报diff，都要花大量时间人工分析。如果Agent能自动区分哪些是真diff需要关注、哪些是假阳性可以忽略，效率提升是立竿见影的。

中期，知识库的积累与复用。Knowledge Agent不只是记录历史，更重要的是把经验结构化。每次ECO的输入特征（什么类型的修改、涉及哪些module、修改量多大）和输出结果（用了什么effort、patch多大、等价性检查是否一次通过）都记录下来。积累足够数据之后，Agent可以根据当前ECO的特征自动推荐策略，「根据历史经验，这种类型的修改建议直接用normal effort，不需要先跑fast验证」。

长期，探索Agent的自主决策边界。这是最前沿也是最困难的部分。让Agent在哪些环节可以自主做决策，哪些环节必须人来确认，这条线怎么划。我目前的想法是，诊断和建议可以让Agent自主做，但最终的执行确认必须人来签字。芯片流片的成本太大了，完全自主的Agent目前不现实。但随着Agent一次一次正确地做出决策，信任是会逐步建立的。今天你检查它的每一步输出，明天你只检查最终结果，后天你可能只看一个summary就够了。信任的积累是一个渐进的过程。

6.4 Agent落地的几个现实挑战

规划归规划，现实里有几个绕不过去的挑战。

第一个是知识库的质量。Agent的智能程度取决于你喂给它什么。如果历史记录都是垃圾，Agent推荐出来的策略也是垃圾。所以知识库的结构设计、数据质量控制、更新维护机制，这些「脏活」比AI模型本身更重要。

第二个是多Agent之间的协作效率。Master-Agent架构理论上很优雅，但实际运行中，Agent之间的通信开销、上下文传递、错误传播，这些都是工程问题。Diagnostic Agent分析完log之后，怎么把结论高效地传递给Execution Agent？格式不对就要人工干预，反而增加了负担。

第三个是安全性和权限控制。Agent能调用ezeco跑ECO，那它能直接修改P&R网表吗？能直接提交到版本管理吗？权限怎么控制？芯片设计流程中的每一步都有严格的签核流程，Agent的操作需要纳入这个流程，而不是绕过它。Tool-in-the-Loop的思想在这里就特别重要，工具在循环里，Agent在工具之上，人随时准备接手但不需要一直盯着。

第四个是跨公司、跨项目的可迁移性。我在这家公司搭的Agent系统，换一家公司能用吗？不同公司的flow不一样、工具链不一样、网表格式有差异、DFT策略不同。Agent需要足够灵活，能适配不同的设计环境。这也是为什么ezeco的stage-based flow设计思路值得借鉴，它把设计流程的差异性封装成了不同的flow variant，Agent系统也应该有类似的适配层。

七、这不是我一个人的想法

聊到这，你可能会想，这套东西是不是就我在自嗨？

不是。2025到2026年，Agentic EDA这个领域发生了质变。

2025年底，一篇发表在arXiv上的综述论文「The Dawn of Agentic EDA」系统性地梳理了这个领域的演进。论文里有一句话我觉得特别到位，「传统AI优化的是扳手（工具），Agentic AI要自动化的是使用扳手的工程师。」这跟我一直说的AI-Native思想是一致的，不是给旧流程加AI，而是为AI重新设计流程。

论文里还提到了一个有意思的框架叫ChatEDA，用层级控制器的方式让Agent自主编排RTL-to-GDSII流程。它微调了一个LLaMA-2模型来做任务规划，成功率达到了98.3%。另一个框架叫REvolution，用进化计算的方式让Agent维护一组设计变体，迭代优化，最终实现了24.5%的功耗降低和24.0%的通过率提升。

2026年3月，Siemens发布了Fuse EDA AI Agent，号称业界首个能跨完整EDA流程进行自主编排的Agent系统。从设计构思到制造签核，全覆盖。Samsung已经在用。同一年6月，Cadence宣布ChipStack AI Super Agent达到L5级别自主度，能独立执行芯片设计和验证流程。NVIDIA的工程师用这个系统跑数百个仿真，声称RTL验证速度提升40倍以上，把验证周期从几周压缩到一天以内。

还有一个让我印象深刻的项目叫Design Conductor 2.0。2026年4月发布的版本，80小时内自主完成了一个LLM推理加速器的设计，从概念到FPGA验证到物理实现，全程无人干预。80小时。传统流程这个工作量可能需要几个人月。

还有一个跟ECO直接相关的进展。2026年3月，一篇叫FluxEDA的论文提出了一个有状态的Agent-EDA基础设施层。传统的Agent调用EDA工具都是脚本级别的，每次调用都是独立的。FluxEDA做了一个统一的执行网关，让Agent可以在持久的工具上下文中进行多步优化。论文里直接验证了两个场景，一个是自动化post-route timing ECO，一个是标准单元子库优化。

Agent对EDA的改变不是增量，是数量级的跃迁。ECO只是其中一个缩影。

八、现实的边界

聊了这么多，我必须踩一脚刹车。

ECO这件事，不管用什么工具，有些边界目前是绕不过去的。

常量变化的ECO。如果RTL里有信号从正常值变成了constant value（tie 0或tie 1），目前所有ECO工具都不如手工修改。因为综合工具会优化掉constant信号，导致ECO工具很难准确定位修改点。这不是ezeco的问题，是所有ECO工具共同的困难。

Flatten all的block。如果block是flatten all的情况，各种ECO工具的效果都不理想。ezeco提供了Learning ECO模式来缓解这个问题，但仍然需要手工修改SYN阶段的网表。

改动特别复杂的情况。如果修改涉及面非常广，不管用什么工具，给出的ECO patch都会很大。patch太大了后端不一定能满足timing，可能需要重新做部分物理设计。

信任。这是最微妙的一点。芯片流片的成本是几百万到几千万美元级别的。不管ezeco跑出来的结果多好，不管Agent编排多自动化，最终的patch你得亲自看、亲自确认、亲自签字。信任是靠一次一次成功积累出来的，没法速成。

但这些边界在缩小。Design Conductor 2.0已经证明了Agent可以自主完成从概念到物理实现的完整流程。Cadence的ChipStack达到了L5自主度。FluxEDA验证了有状态的Agent-ECO闭环。这些进展正在一点一点把「需要人来做」的边界往外推。

九、ECO之外

写到这里，我想跳出ECO聊几句。

这一篇的叙事线索是这样的，手工做ECO被虐了一个月，到找到ezeco这个工具，到基于ezeco做Design Agent，到用Master-Agent架构设计真正的ECO Agent，再到Agent在芯片落地的三个层次和现实挑战。这不是一个工具推荐的故事，是一个工程方法论的演进。

手工ECO是最原始的方式，靠人的经验和耐力硬啃。ezeco是工具辅助的阶段，人还是主导，但工具帮你做了最苦最累的活。Design Agent是流程标准化的阶段，好工具被包装成人人能用的平台。Agent编排是下一阶段，平台变成自主运行的系统，人从操作者变成监督者。

这条线跟我第一篇文章讲的AI-Native思想是完全一致的。不是给旧流程加AI，而是为AI重新设计流程。ECO流程在ezeco阶段已经被重塑了一次，GTECH flow替代了传统RTL对比。在Design Agent阶段又被标准化了一次，Web界面替代了命令行。到了Agent编排阶段，整个流程会变成自主闭环的。

而贯穿这些阶段的，是Tool-in-the-Loop的思想。ezeco本身就是Tool-in-the-Loop的最佳实践，它把等价性检查、patch优化这些工具嵌入到了ECO执行循环内部。Design Agent把并行调度、实时监控这些能力加了进来。Agent编排会在这些工具之上加一层自主决策，而且不同角色用不同的LLM，让每个环节都用最合适的模型做最合适的事。

芯片是我的视角，但AI做工程这件事，不限于芯片。

任何「定位难、修改难、验证难」的工程任务，都是同一个方法论可以适用的场景。有没有AI，效率是不同量级的。

---

写在最后

这一篇聊了一个非常具体的话题，ECO。但我想说的不只是ECO。

从一个真实的一个月ECO经历出发，到找到ezeco这个改变局面的工具，到理解GTECH flow为什么从根本上改变了ECO的精度，到基于ezeco搭建Design Agent，再到用Master-Agent架构设计真正的Agent系统。不同角色用不同的LLM，三级降级保证可用，NLP让用户用自然语言就能操作。这是一条完整的工程演进路线，不是想象，是我亲历的。

而Agentic EDA领域的进展告诉我，这个方向不只是我在做。Siemens的Fuse Agent、Cadence的ChipStack L5、Design Conductor 2.0、FluxEDA，都在验证同一件事，Agent对EDA的改变是数量级的。ECO只是其中一个缩影。

降级策略是我们的系统思维，保证AI挂了流程不中断。但主叙事不是降级，是AI带来的生产力代差。没有AI你能干活，有AI你的效率是另一个量级。

Tool-in-the-Loop。工具在循环里，Agent在工具之上，人随时准备接手但不需要一直盯着。

下一篇见。

---