智能体EDA落地实践：从验证收敛到流程自动化的真实复盘

刚过去的这个流片节点，验证团队连续三周没在凌晨两点前离开工位。我坐在旁边看他们把同样的波形翻来覆去地查，一个断言漏了，回归测试跑完一整轮才发现，然后改测试平台、重新跑、再等着覆盖率数据吐出来。那个瞬间我意识到，真正卡住芯片项目的不是某个工具不够快，而是从“发现问题”到“定位问题”再到“修改验证环境”这个循环里，人的参与密度太高了。

后来我开始在一部分流程里引入智能体，也就是把大语言模型接到EDA工具链上，让它自己读日志、改脚本、补断言、跑回归。“智能体 EDA”这个名字听起来挺玄，但拆开看就是：让AI不再只是聊天框里帮你写一段Verilog，而是能自己调用仿真器、综合工具、覆盖率工具，根据返回结果决定下一步做什么。这篇东西不是概念堆砌，而是我基于几个内部试验项目做的复盘——智能体到底能在数字芯片设计流程里干哪些活，哪些地方纯属自嗨，哪些地方已经能省真金白银的人力，以及我判断未来两三年它会怎么演化。

1. 这个“曙光”到底照亮了哪一段设计流程

1.1 数字芯片设计里最贵的是“人肉循环”

很多人一听到“自主数字芯片设计”，第一反应是让AI从架构定义一路干到GDSII。但真在项目里泡过的人都知道，数字设计流程里最耗人力的从来不是某一单点工具，而是设计和验证之间的来回拉扯。

以我参与过的中规模SoC项目为例，整个流程大致分几个阶段：微架构定义、RTL开发、模块级验证、系统级验证、综合与形式验证、后端物理设计、签核。前面几步听起来名字很多，但实际人头最密集、周期最不可控的是验证。因为每一个功能点都要被翻译成测试用例，每个测试失败都要去区分是RTL的bug、测试平台的bug还是环境配置的bug。查一个失败用例，熟练工程师平均要花半小时到几个小时，而且这期间大量时间是在盯仿真日志和波形，而不是在设计本身。

传统EDA解决的是“给定验证目标后怎么更快跑完”，但它没有解决“下一轮验证目标是什么”这件事。这个决策权一直握在验证工程师手里，于是项目一紧张，所有人都在做同一件事：跑回归、看报告、猜遗漏、改环境。这就是我说的“人肉循环”。

智能体EDA真正切入的，就是这里。它不试图一步到位把芯片设计全过程自动化，而是把循环中每一个“用眼睛看”的步骤改成“由模型推理后调用工具”的步骤。仿真日志不用人逐行读了，覆盖率报告不用人盯着找空洞了，甚至断言补全这种需要理解设计意图的工作也可以交给智能体先出一版，再由工程师审阅。

1.2 从“AI辅助生成代码”到“AI自主驱动流程”

前几年我们见过大量AI写代码的尝试，那些工具本质上还是单点辅助：你给模型一个模块描述，它给你一段Verilog，然后人就接手了。问题在于，接手之后的工作量往往比从零开始写还大。因为模型生成的代码没有经过验证闭环，你不知道它哪里会翻车，必须为每一行代编造一套测试来确认行为。

智能体EDA带来的变化是结构性的：模型不再是一个被动的问答器，而是流程里的一个执行者。它能看工具返回的结果，能根据结果调整自己的下一步动作，能在一个任务内部分解出“写测试平台—编译—跑仿真—读覆盖率—补断言—重跑”这样一条长链路。

我举一个具体例子。某次我需要给一个总线桥模块补齐分支覆盖率，传统做法是打开覆盖率报告，人工看哪些分支没走到，然后回去写定向测试。用智能体做的时候，我只需要给它两个入口：一份设计文件、一份覆盖率报告，再给它一个能调用的仿真命令接口。它会先读报告里哪些条件和分支覆盖率为零，再对照RTL代码推断为什么走不到，然后生成一段SystemVerilog测试代码，调用仿真器跑通，重新出报告，直到它认为自己把能补的都补了。整个过程我不需要碰代码，只需要最后审一遍它的改动和覆盖率数字。

这个场景能跑通，不是因为某个大模型特别聪明，而是因为整个链路被设计成了“工具可调用、中间产物可解析、结果可验证”。这也是我在这篇文章里最想强调的观点：智能体EDA不是模型决定的，而是由“模型+工具接口+验证反馈”这个闭环决定的。

1.3 适用边界：不是所有环节都适合马上智能体化

要说清楚曙光出现在哪里，也得说清楚它暂时照不到哪里。

从我的实践看，适合智能体化的环节有三个特征：第一，任务的上下文可以被数字化编码，也就是代码、日志、报告本身就能作为输入；第二，任务有明确的验证标准，也就是跑没跑对、覆盖率高不高是客观可判的；第三，任务允许试错和重试，毕竟模型不可能一次就对。

反过来看，微架构设计决策这种高度依赖项目背景、历史经验、商业考量的环节，目前智能体的参与度很低。它可能帮你列出几种架构方案的利弊，但真要拍板用哪种缓存一致性协议，还是得靠人。物理设计阶段的布局布线同样不适合直接交给通用智能体，一方面是因为工具本身的接口复杂碎片化，另一方面是因为这个阶段的最优解高度依赖工艺库和项目约束，模型很难凭通用语料推理出来。

所以我的判断是：智能体EDA的“曙光”首先照亮的是介于RTL设计和验证之间的那一段区域，以及各类流程脚本自动化的场景。等这段区域被打磨成熟，再慢慢向两端延伸。

2. 智能体不是ChatGPT套壳：技术栈的四个质变点

2.1 从“会聊天”到“会调用工具”

两年前我们尝试让大模型直接写Verilog的时候，最痛苦的问题是：模型写出来的代码没有经过工具链的验证，它自己也不知道这段代码能不能综合、能不能通过仿真。你把它的话当参考可以，当代码用就太危险了。

现在主流大模型都支持工具调用能力，也就是模型在生成自然语言回答的同时，可以输出一个结构化的调用请求，比如“运行这条命令”“读取这个文件”“返回这段日志的摘要”。这个能力放到EDA场景里就是质变：模型不再凭记忆瞎写，而是可以自己拉起仿真器，跑完看结果，发现编译错误后再修再跑。整个过程形成一个感知—行动—反馈的环路，这才是“智能体”和“聊天机器人”的分水岭。

我在内部搭的试验框架里，智能体拿到的工具列表大致是这样的：读取文件、列出目录、执行仿真命令、执行综合命令、运行覆盖率收集、查询最近日志的指定行段、执行lint检查。每一条工具背后都是真实的EDA工具链，只是被封装成了统一的调用接口。模型通过文本描述理解当前状态，决定调用哪个工具，然后读取返回结果进入下一步推理。

这听起来简单，但实际上需要解决一个关键问题：工具返回的信息往往是几百几千行的日志，直接塞给模型既浪费上下文窗口，又会干扰推理。我们的做法是先在外面做一层轻量解析，把日志里的错误行、警告行、覆盖率摘要提取出来，转成结构化的短文本再交给模型。这一步非常关键，直接决定了智能体后续行为的准确度。

2.2 长上下文允许“设计意图”被携带

早期用大模型做代码生成，一个很大的限制是上下文窗口太短。芯片模块动辄几千行RTL，加上约束文件、测试平台、历史修改记录，很容易就把窗口撑爆。

近一年长上下文能力的提升，让智能体能在一个任务内携带足够多的工程信息。比如验证某个IP核的DMA功能，我可以直接把RTL源码、现有测试平台的结构、关键接口信号说明、甚至最近的bug记录都丢进上下文里。模型在做覆盖率分析和断言补全的时候，就不再是凭空猜测信号语义，而是真正基于设计代码里的逻辑来推理。

不过这里要泼一盆冷水：上下文长不代表模型能有效利用这么长的上下文。实测下来，一个模块的RTL超过两千行之后，模型对深层依赖关系的理解质量会明显下降。我常用的缓解手段是“分层喂给”——第一次只给模块接口定义和关键状态机，让模型先建立整体结构认知，再逐步补充内部实现细节。这本质上是在模拟一个工程师阅读陌生代码的顺序，效果比一次性堆全部代码好得多。

2.3 任务规划与失败重试机制

单次工具调用再准，离“自主设计”也还很远。真正让智能体变得可用的是任务规划能力：面对一个模糊的指令，比如“帮我提高这个模块的语句覆盖率”，模型能自己拆解出多个子步骤，并按照依赖关系排列执行顺序。

我们的试验框架里加了一个简单的规划器，智能体在开始动手前先输出一份“行动计划”，里面包含步骤序号、每步打算用的工具、期望的输出和判断标准。比如：

1. 解析当前覆盖率报告中低于阈值的目标语句列表
2. 对照RTL代码找出每条语句的控制条件
3. 分析现有测试平台中哪些激励序列可能覆盖这些条件
4. 生成一份新的定向测试代码
5. 编译并运行回归
6. 重新生成覆盖率报告，比较提升幅度

失败了也不怕，关键在于重试策略不能是“换个说法再来一次”，而是要先读取失败原因，再定位是激励写错了、约束有冲突还是路径根本没被激活。这个“失败原因驱动的重试”目前在简单场景下成功率已经能到七八成，但复杂场景下仍然需要人介入判断。

2.4 人类反馈在环：把判断权留在工程师手里

我见过不少团队对智能体的期望是“丢个任务进去，早上来验收”。我觉得在数字芯片设计这种安全攸关的领域，这种想法本身就危险。智能体EDA现阶段最健康的使用方式，是人做决策、智能体做执行。

“反馈在环”指的是工程师不需要逐行盯着智能体的工作，但要在关键成果点检查它的产出。比如测试代码生成后先走一遍lint，再让工程师快速review关键激励序列的意图；覆盖率报告更新后，工程师要判断新增覆盖点是有效覆盖还是测试平台的自嗨。这套机制既能保证进度，又不会让错误产出在无人审查的情况下溜到下游。

我自己的习惯是给智能体设定明确的“检查点”：哪些中间产物必须停下来等我确认，哪些可以自主推进。比如修改RTL这种高风险动作必须经过确认，而跑回归、收集覆盖率这种无风险操作可以全自动批量执行。检查点设得好，智能体的自主度可以放得很高，同时安全性也没有大幅下降。

3. 按流片节点拆解：四类智能体真正能落地的场景

3.1 RTL设计智能体：从自然语言到可综合代码的边界

RTL设计智能体是外界讨论度最高的，也是实际落地难度排第二的。必须承认，让智能体直接根据一句“实现一个AXI转APB桥”写出完整可综合代码，在今天已经可以做到七八十分的水平。但它离“可放心交给后端”还有明显差距，主要原因是可综合性、时钟域处理、面积时序优化这些隐性要求，模型很难从通用语料里学到。

我从实践里总结的合理用法是：让智能体负责第一版模板生成和接口占位，人负责约束补充和关键路径设计。比如一个跨时钟域模块，智能体能很快搭好两个时钟域各自的寄存器传输逻辑，但异步FIFO的深度、水线设置、跨时钟握手信号的同步策略，还是需要工程师把约束写清楚之后智能体才能往下做。

价值点在于，原本写第一版框架需要两三天，现在半天能出来，而且格式规范、命名清楚、注释完整。省下来的时间被用在了真正需要人的地方，比如边界条件下的时序分析，比如跨模块交互的一致性验证。

RTL设计智能体的另一个价值藏在重构里。项目后期经常要把一个大模块拆成两个小模块，或者调整某一组信号的处理逻辑。这种工作机械性强、出错率高，交给智能体做很划算。它能先分析端口依赖，再生成重构后的代码骨架，然后自动比较重构前后仿真结果是否一致，极大降低了这种改动引入回归bug的概率。

3.2 验证智能体：测试平台生成与覆盖率收敛

验证是我认为目前智能体落地价值最大、见效最快的地方，没有之一。原因很简单：验证任务天然具备“目标可量化、结果可判定、迭代频次高”三个特点，正好是智能体最擅长处理的类型。

验证智能体做的事情主要有四块。第一块是测试平台骨架生成，给定DUT的接口列表，智能体能生成一个基本可用的testbench框架，包含时钟复位生成、信号初始化、典型激励序列。第二块是定向测试补充，给定覆盖率报告中未覆盖的分支信息，智能体能结合RTL代码理解条件逻辑，生成针对性的激励。第三块是断言收集，智能体可以扫描RTL中的关键状态和时序关系，自动生成一份SVA断言初稿，帮助实时监控违例。第四块是失败用例初步诊断，仿真失败时智能体能先做日志分析，圈定可能出问题的信号和时序范围，减少人肉排查的定位时间。

这里面我个人最看重的是第二块和第三块的联动。覆盖率报告让智能体知道自己“偏科”在哪里，断言则让智能体知道自己改的测试代码有没有真正踩到目标逻辑。两者组合起来，形成了一个对智能体完全客观的秘密反馈机制，让它不需要依赖人的主观感觉就能判断自己做得对不对。

实测下来，一个中规模IP核的语句覆盖率从85%拉高到95%左右，人力投入可以降到以前的三分之一。但代价是智能体跑的回归次数会变多，因为它的激励生成策略偏“广撒网”，很多测试的有效性不高。

3.3 流程脚本智能体：把碎片化工具链粘起来

真正做过项目的工程师都知道，芯片设计流程里最零碎的工作既不是写RTL，也不是跑验证，而是维护那一堆脚本：不同工具的配置、文件列表的生成、版本间的路径切换、日志关键信息的提取。这些脚本单个看都很简单，但组合起来极其容易出错，而且一旦出错，报错信息往往很隐蔽。

流程脚本智能体是我最早推上生产的智能体类型。它读入一个任务的描述，比如“对这版RTL跑一遍lint，并和上一版对比警告数量的变化”，然后自动生成对应的脚本、执行、解析结果、输出一份简明报告。由于这类任务的验证标准非常明确，出错后也能立刻通过工具返回的信息暴露出来，所以智能体的可靠性很高。

这类智能体还有一个容易被忽略的好处：它天然促成了工具链的标准化。以前每个工程师有自己的脚本习惯，换个人就可能跑不出同样的结果。现在统一由智能体按规范生成和执行脚本，流程的一致性大幅提升，出问题时的排查范围也被限制到了数据本身而不是脚本写法。我甚至觉得，流程脚本智能体才是整个智能体EDA里投入产出比最高的品类，只是因为它太不起眼，很少有人把它当成一个独立的架构来讨论。

3.4 设计空间探索智能体：在PPA之间自动权衡

设计空间探索向来是资深架构师和高性能工程师的看家本领，也是智能体比较难入场的领域。难在两点：一是探索空间太大，组合起来天文数字；二是评价某一种配置的优劣需要跑完综合甚至布局布线，成本太高。

但我最近看到一些不错的做法，让智能体在探索过程中扮演“实验管理员”的角色。它根据目标（比如功耗降低10%、时序不变），生成一组候选配置参数，然后批量调度综合任务，把每个配置的结果收集起来，对比PPA数据后自动选出下一轮采样方向。这本质上是用智能体替代了工程师不断“改参数—跑综合—看报告”的体力活，而探索策略本身仍由人定。

这样做的收益在于，工程师的注意力被释放到了更有价值的环节上，比如分析某一组配置为什么功耗异常、某一条路径为什么迟迟收不紧。探索智能体做出的结果用来展示趋势，而不是替代工程判断。设计空间探索不会有那种一夜之间给你一个完美微架构的神话，但确实能让团队在同样的时间里多看几个方案，这对后端优化来说已经是实打实的效率提升。

下表总结了四类智能体在我试验中的表现：

4. 实测过程：某教学用处理器核的验证收敛，智能体参与后发生了什么

4.1 任务设定与工具链搭建

为了不空谈概念，我挑一个完整的实测案例来拆解。这里用某教学用处理器核项目做代称，它的规模大概八千行RTL，包含取指、译码、执行、访存、写回五级流水线。项目目标是把模块级语句覆盖率从82%拉到95%以上，同时不引响回归测试失败。

工具链方面，我用了一个开源快速仿真器配合标准覆盖率收集工具，智能体通过自定义接口读取覆盖率数据库，并以命令行的方式驱动编译和回归。所有工具调用都被封装成统一接口，不直接暴露给模型操作系统权限，避免它乱跑命令。

任务分成两个阶段。第一阶段是“覆盖率空洞分析”，智能体需要读覆盖率报告，列出所有未覆盖语句对应的源码位置和控制条件。第二阶段是“定向激励补全”，智能体要为这些空洞生成测试代码，逐条清掉。整个过程我会在每个检查点介入审阅，但不直接写代码。

4.2 人机分工与检查点设置

我一开始就给这次实验设了几个明确的检查点，避免智能体在错误方向上跑太久：

1. 覆盖率空洞列表出来后，由我人工确认哪些空洞值得补、哪些是死代码可以忽略
2. 智能体提交第一批新测试代码后，我先审阅它的激励意图是否合理，再决定是否批量合入
3. 每完成两轮覆盖率迭代，我要对比一次新增覆盖点和新增断言，看是否存在“虚假覆盖”

检查点设好之后，我没有再逐行盯它的操作。智能体由规划器驱动，按着自己生成的行动计划执行。每完成一个步骤会更新一份状态文件，内容包括当前覆盖率、最近一次改动、失败记录、下一步计划。这让我随时能回溯它在干什么。

4.3 三轮迭代的真实进展

第一轮智能体用了大概四十分钟，主要是在解析覆盖率报告和逐条对照源码条件。它提交了一份挺准确的分析：未覆盖的高优先级空洞集中在分支预测失败恢复路径和写回级的数据旁路逻辑上。这两个区域共同特点是有很多组合条件，现有测试平台几乎没有针对性的激励序列。

第二轮它开始真正生成测试代码。这里出现了一个我预判到的现象：模型倾向于生成“覆盖点很多但行为重叠”的激励，也就是用几组几乎一样的配置反复冲刷同一个分支。语句覆盖率涨了一些，但有效新增覆盖点没有想象中多。我在检查点2介入了，要求它增加随机化约束的比重，减少常量配置重复。

第三轮加入随机化约束后，覆盖率提升明显变快。从85%一路拉到93%左右，耗时约两个半小时，期间自动跑了四十多轮回归。唯一一次编译错误是智能体把某个信号位宽写错了，它在读取编译日志后自己定位到修改行并完成回滚，没有造成额外的人工介入。

4.4 这套做法在真实项目里的“涉险点”

实测效果好归好，但我也得把风险说透。

最让我警惕的一个问题是“为覆盖率而覆盖率”。智能体可能会生成大量能触达未覆盖语句的激励，但这些语句本身只是状态机里的某一条分支，并不代表一个真实业务场景被验证过了。比如它可能通过一组完全不可能在真实使用中出现的信号组合，把某条覆盖率空洞填上了。这种覆盖对芯片质量毫无帮助，反而会误导团队对验证完备性的判断。

我处理的办法是给智能体加了一条规则：新增测试必须附上一句话说明“模拟了什么业务场景”，由我判断这个场景是否真实存在。如果只是拼接信号硬凑路径，我会直接打回。这条规则让覆盖率数字回归了它的本来意义，而不是成为智能体刷分的游戏。

另一个风险在于断言质量的把控。智能体自动生成的SVA断言初稿，有不少是“永真”或者“恒假”的无意义断言，放到仿真里既不报错也不报错，占用了运行资源却没有安全价值。我要求所有新增断言必须经过静态审查，同时删除那些没有触发过的断言。这个过程虽然增加了一点人工负担，但对保护下游签核环节的安全性必不可少。

5. 越自主越要兜底：智能体EDA的反直觉难点

5.1 幻觉代码比语法错误更危险

智能体生成的代码如果语法错误，编译阶段就会被拦截，反而不是大事。真正危险的是那种看着完全正常、能通过仿真、甚至能获得覆盖率，但行为语义和设计意图相悖的代码。

我在一次试验里让智能体补全一个AXI总线的读数据返回路径测试，它生成了一段看似合理的激励，仿真也通过了，覆盖率还涨了。但我一细看，发现它把读地址通道里的id信号固定成了常量，这意味着它测的只是某一个 outstanding 事务的场景，其余id交错情况完全没有覆盖。如果我没发现这个问题，这段“成功”的测试就会让团队误以为这块逻辑已经验证充分。

应对幻觉代码，我的经验是两条腿走路。一是在提示词里明确要求智能体对测试动机给出解释，不做无理由的激励生成；二是在仿真环境里构建一套基于行为模型的检查器，自动验证激励序列是否真的覆盖了设计意图。前者降低幻觉产生概率，后者兜底拦截漏网之鱼。

5.2 覆盖率指标的局限性：收敛不等于正确

由智能体驱动覆盖率收敛会带来一个很微妙的认知陷阱：项目组看到覆盖率曲线漂亮地爬升，信心大增，但曲线本身不会告诉你“没测到的地方是不是恰好是隐患最严重的地方”。

真实的芯片bug分布并不均匀。功能复杂、接口交互密集的区域和冷门异常路径是有bug的高发地带。通用覆盖率工具只会统计代码语句、分支、条件、状态机的遍历情况，不会去评估这些遍历在语义上的重要性。所以智能体如果被设定成“只优化覆盖率数字”，它很可能把力气花在容易触达但并不重要的路径上，反而放过了那些难测但关键的场景。

解决这个问题的思路，是在智能体的目标函数里显式加入“关键场景优先”的约束。比如把异常注入、数据一致性检查、跨模块接口的边界情形设定为高优先级任务，即使这些场景的覆盖率增长慢，也要保证它们被充分执行。否则我们只是在用更高的覆盖率数字掩盖一个未经验证的核心风险点。

5.3 物理设计阶段的硬约束与工具私有数据

智能体EDA在RTL和验证环节的自主度提升已经能看到明确收益，但到了综合之后尤其是布局布线阶段，问题就不一样了。物理设计过程中大量信息沉淀在图形化界面里和工程师的大脑中，比如为什么某条关键路径要绕开某个区域、为什么某个单元的尺寸选择要偏离标准库推荐值，这些经验很难被显式表达成智能体可以理解的输入。

还有一个更现实的问题，商业物理设计工具的脚本接口虽然开放，但很多内部数据结构和分析结果并不适合直接用文本方式传给模型。智能体需要“看”的内容很大一部分是版图上的视觉信息，而现有文本接口只能提供部分数字指标。这导致物理设计阶段的自主化进度明显慢于前端设计验证。

我不认为物理设计会被智能体彻底接管。更可能出现的形态是，智能体负责跑大量可并行的实验组合，人负责从结果里挑出合理方向并修正约束。这样至少能把最耗时的“等结果”环节缩短，让工程师把精力挪到真正需要经验和直觉的地方。

5.4 数据机密性与私有IP保护

这个问题时常被低估，但它在实际推广时可能成为最大的拦路虎。芯片设计企业的RTL代码、架构文档、验证IP是核心商业机密，一旦流出到外部模型服务，后果不堪设想。很多团队不敢把智能体EDA用起来，不是不相信技术能力，而是过不了数据安全这一关。

我认为可以落地的路径有三条。第一条是私有化部署开源模型，把推理环境完全放到企业内部网络，虽然前期工程成本高，但数据不出门，适合涉密项目。第二条是数据脱敏流程，把RTL中的信号名、模块名、注释性描述全部替换成随机代号后再送进模型，输出结果再映射回来，这个方法可以适配部分外部API场景。第三条是对外发内容做严格的白名单控制，只允许发送脱敏后的有限片段，比如某几个函数的覆盖率报告摘要，而不是完整代码。

技术可行性从来不是智能体EDA的瓶颈，数据安全和流程合规才是。这块如果没想清楚，后面落地越深风险越大。

6. 我的路线图判断：从流程自动化到设计自主化的三步走

6.1 第一步：把回归、脚本、报告解析做成Agent可调用的标准工具

现阶段绝大多数团队最该做的不是训练更好的模型，而是把现有工具链的接口统一化、结构化。智能体的手脚是工具调用，如果仿真、综合、覆盖率工具都只能由人肉敲命令驱动，那智能体再聪明也无处下手。

我建议从三个地方入手。第一是日志解析标准化，把不同工具的输出统一成机器可读的结构化格式。第二是回归系统接口化，让智能体能够通过API提交编译、仿真、覆盖率收集任务并获取结果。第三是中间产物规范化，比如覆盖率报告、综合报告、时序报告都要有固定格式，便于智能体做跨阶段分析。

这一步不需要太强的模型就能见效，因为任务本身确定性高、闭环清晰。但它是一切后续工作的地基。我们内部做完这一步之后，智能体的开发效率大概提升了一个数量级，很多过去需要为每个任务单独写胶水代码的场景都不复存在。

6.2 第二步：让“覆盖率/时序/功耗目标”成为智能体迭代的闭环信号

当工具接口全部打通后，下一步就是设计目标驱动的自主迭代。这里的核心思路是把项目验证计划中的量化目标翻译成智能体可以读取的反馈信号。覆盖率不足就自动生成新激励，时序违例就尝试调整综合约束，功耗超标就探索一组新的实现策略。

这一步最大的价值是让智能体的行为不再依赖人的即时反馈，而是由项目客观数据驱动。当智能体跑完一轮动作后，它能从覆盖率数据库、时序报告里看到自己带来的变化，并据此决定是继续深挖还是转战下一个目标。这才是真正意义上的“自主”雏形。

但我要强调，这一步必须在第一步的标准化基础上做，否则智能体面对的是七零八落的数据，很难形成连续迭代。跳过基础设施直接上大模型，最后得到的只会是一个豪华版聊天机器人。

6.3 第三步：设计意图的形式化表达与多智能体协同

再往远看，智能体EDA的下一个瓶颈是“设计意图的表达”。现在人类工程师给智能体的指令大多是模糊的自然语言，比如“提高这个模块的性能”。模型只能靠猜来补全没说明白的约束，结果自然难以让人满意。

如果把设计意图用一种结构化、可验证的形式表达出来，情况会完全不一样。比如用约束文件描述接口协议规则，用属性描述时序要求，用覆盖率清单描述必须验证的功能点。智能体拿到这些结构化意图之后，就不再需要猜测“用户想要什么”，而是可以直接围绕这些约束做推理和行动。这个方向我认为会是一个新的基础设施类别，会决定智能体EDA能走多远。

多智能体协同看起来更远，但从我的实验看，不同职能智能体之间的结构化通信其实已经可以低成本实现。RTL设计智能体产生的代码变更自动触发验证智能体跑覆盖率分析，验证智能体发现的问题自动返给设计智能体做修复建议，这里的瓶颈不在技术而在标准的建立。如果全行业能形成一套智能体间交换“设计状态、验证状态、问题描述”的通用格式，那么一个真正的多智能体协同设计循环才会成为可能。

我个人对智能体EDA的态度是：不要期待它一夜之间把芯片设计自动化，但绝对要重视它让每一轮设计循环变得更快、更便宜这件事。先让智能体把验证收敛、脚本维护、回归分析这些脏活累活接过去，再一步步把更大的决策空间交给它，这是我看下来最稳健也最能产生实际收益的路径。

回到开头说的那个场景，那些在凌晨两点还盯着波形的验证工程师，未来两三年里可能真的可以早点回家。那些被“人肉循环”吞掉的时间，会被解放出来，重新用回到真正需要人类判断力的设计决策上。这才是“智能体EDA的曙光”落到现实里的样子。