EDA+Agent赛道真相：从RTL生成到Harness工程实践

1. 当EDA赛道涌进一批"钓鱼佬"，到底在钓什么

"EDA界的Codex赛道挤满钓鱼佬"——这个标题第一次看到的时候我笑了很久，但笑完之后发现它精准得可怕。所谓"钓鱼佬"，指的是那些并不真正做芯片设计、也不打算把工具做成产品，而是盯着EDA这个赛道里的流量、融资故事、开源热度、榜单排名去"下钩"的人。他们钓的不是鱼，是关注度、是估值、是简历上的一行字。

而"Codex赛道"这个词更有意思。Codex原本是代码生成模型的代名词，放到EDA语境里，它指的是用大模型/Agent去理解、生成、修改RTL、网表、约束、脚本乃至版图这一整条技术路线。关键词里出现的EDA、Codex、RTL、Agent、Cadence，基本就把这条赛道的骨架画出来了：底层是EDA工具链（Cadence、Siemens EDA、立创EDA等），中间是RTL这类硬件描述语言，上层是Agent这种能自主规划、调用工具、迭代验证的智能体。

我写这篇东西，不是要嘲讽谁。恰恰相反，我自己也在这条赛道里摸爬滚打过，踩过的坑足够填满一个标准单元库。我想做的是把"钓鱼佬"现象背后的真实技术图景拆开给你看：这条赛道到底在解决什么问题、Agent做RTL生成的真实难点在哪、为什么那么多人挤进来却做不出能用的东西、以及如果你真想认真做，应该从哪个角度切入。

适合读这篇的人有三类：一是想入局EDA+AI的工程师，二是被各种"AI自动生成芯片"新闻搞晕的从业者，三是想判断这个方向值不值得投入的学生和转行者。我会尽量说人话，把那些被营销话术包裹的概念还原成能上手的东西。

先给一个我自己的判断：EDA+Agent这条赛道，技术上是真需求，商业上是真难做，舆论上是真泡沫。三者同时成立，这才是它有意思的地方。

2. 拆开"Codex赛道"：EDA里到底哪些环节能被Agent接管

2.1 从RTL到GDSII，Agent能插手的节点比想象中少

很多人一提"AI做EDA"，脑子里浮现的是"我说一句话，芯片就设计好了"。这个想象和现实之间的差距，大概等于"我会背乘法口诀"和"我能证明费马大定理"之间的差距。

真实的芯片设计流程粗略分：规格定义 → 架构设计 → RTL编码 → 功能验证 → 逻辑综合 → 布局布线 → 时序签核 → 物理验证 → 流片。Agent目前能比较靠谱介入的，其实集中在RTL编码、验证用例生成、脚本编写、日志分析与debug这几个环节。再往后走，综合和布局布线的优化空间被工具厂商的算法锁得很死，Agent更多是"调参助手"而不是"决策者"。

为什么？因为后端环节的每一步都有明确的物理约束和数学优化目标，Cadence、Siemens EDA这些工具内部跑了十几年的启发式算法和求解器，一个通用Agent想在这上面超越它们，性价比极低。反倒是前端那些"需要人写代码、需要人读日志、需要人查文档"的脏活累活，才是Agent的甜区。

我见过太多项目一上来就喊"端到端自动生成芯片"，结果Demo里跑的是一个玩具级的计数器，连时序约束都没加。这不是技术路线问题，是对流程复杂度缺乏敬畏。

2.2 RTL为什么是Agent最现实的切入点

RTL（Register Transfer Level）是硬件描述的核心抽象层，Verilog/SystemVerilog/VHDL都属于这一类。它有几个特点，天然适合Agent：

• 有明确的语法和语义：不像自然语言那么模糊，模型容易学到结构。
• 有海量公开语料：GitHub上的开源IP、各种教程、竞赛题，训练数据不缺。
• 有可自动化的验证闭环：写完RTL可以跑仿真，仿真结果能自动判断对错，这就给了Agent自我迭代的信号。
• 模块化程度高：一个FIFO、一个仲裁器、一个状态机，都是相对独立的单元，适合分而治之。

关键词里出现的"modelsim中能不能查看RTL电路图""8位同步SAR ADC在Cadence中的设计"这类搜索，其实反映的就是真实工程师的日常：他们要的是能看懂、能验证、能复用的RTL，而不是一段看起来很美但综合不过的代码。

Agent在这里的价值，不是替代工程师写RTL，而是把"写-测-改"这个循环加速。一个熟练工程师写一个AXI-Lite从机可能要半天，Agent生成初版加人工修正可能只要一小时，剩下的时间用来做架构权衡。这才是合理的预期。

2.3 Agent和Harness的区别，决定了你的项目能不能落地

热词里有个"harness和agent区别"，这个问题问得非常到位，因为它直接决定了一个EDA+AI项目是玩具还是产品。

简单说：Agent是"会思考、会决策、会调用工具"的主体，Harness是"约束Agent行为、提供工具接口、管理上下文和状态"的外壳框架。打个比方，Agent是司机，Harness是车+交规+仪表盘。你光有一个聪明的司机，没有车、没有路、没有油，他哪儿也去不了。

在EDA场景里，Harness要负责的事情包括：

我见过的最典型的失败案例，就是有人拿一个通用Agent框架，接了个仿真器，就宣称"AI自动设计芯片"。跑起来之后Agent生成一段RTL，仿真报错，它读不懂波形和日志，就开始瞎改，改到第十轮还在原地打转。问题不在模型，在于Harness没有把"错误信号"翻译成Agent能理解的反馈。

3. 钓鱼佬的三种典型姿势，以及他们为什么钓不到鱼

3.1 姿势一：套壳Demo，专钓不懂行的人

这是最常见的一种。拿一个开源大模型，套一个聊天界面，喂几段Verilog教程，然后录一个视频：输入"帮我写一个UART"，输出一段能跑的代码。视频剪得很漂亮，配乐很燃，标题写着"颠覆EDA"。

问题在于，UART这种模块在GitHub上有几万个现成实现，模型大概率是背出来的，不是"设计"出来的。你换一个稍微偏门的需求，比如"带奇偶校验和可配置波特率的UART，且要满足某工艺下的时序约束"，它立刻露馅。

这种姿势能钓到流量，钓不到真实用户。因为真正的工程师一试就知道深浅，而他们才是付费和传播的核心人群。

3.2 姿势二：堆参数、刷榜单，专钓投资人

第二种更"高级"一点：找一个RTL生成的数据集，把模型微调一遍，然后在某个自建benchmark上刷一个高分，发一篇论文或者一份BP，宣称"我们的RTL生成准确率超过XX%"。

这里有个巨大的陷阱：RTL生成的"准确率"是个极其容易注水的指标。如果你的测试集和训练集同分布，如果你的判定标准只是"语法正确"，如果你的任务只是"补全一行assign"，那准确率可以刷到很高，但毫无意义。

真正有意义的指标应该是：生成的设计能否通过功能仿真、能否综合、能否满足时序、面积功耗是否可接受。这四个门槛一卡，很多"高分模型"直接归零。我建议任何看这类项目的人，第一句话就问："你的benchmark里，有多少设计是真正跑完了综合和时序签核的？"

3.3 姿势三：蹭开源、蹭社区，专钓简历

第三种是学生和转行者居多：fork一个开源EDA+AI项目，改改README，加几个star，然后写进简历"参与EDA智能体开发"。这本身不算错，学习嘛，但问题是很多人只停留在改README的层面，对底层原理一问三不知。

我面试过这样的人，问他"你的Agent怎么处理仿真失败的情况"，答"就重新生成一次"。再问"如果连续失败十次呢"，答"那就……再生成一次"。这就是典型的没有Harness思维。

钓鱼佬的共同问题是：他们钓的是"看起来像"，而不是"真的能用"。而EDA这个领域，恰恰是"看起来像"和"真的能用"之间隔着一条马里亚纳海沟的领域。

4. 想认真做，Harness该怎么搭：一份可落地的思路

4.1 先定义"成功"，再谈Agent

任何EDA+Agent项目，第一步不是选模型，是定义什么叫成功。这个定义必须可自动判定，否则Agent无法自我迭代。

以"生成一个满足规格的FIFO"为例，成功标准可以拆成：

1. 语法检查通过（verilator lint / iverilog编译）
2. 功能仿真通过（给定测试激励，输出符合预期）
3. 综合通过（yosys或商业综合器无错误）
4. 时序满足（在给定约束下无违例）
5. 面积/功耗在预算内

这五条里，前三条可以完全自动化，第四条需要综合器+STA工具，第五条需要工艺库。建议新手从1-3条做起，把闭环跑通，再逐步加码。别一上来就追求全流程，那是给自己挖坑。

4.2 工具链的最小可用组合

如果你想自己搭一个EDA Agent的Harness，下面这套组合是我实测下来门槛最低、反馈最快的：

• 仿真：Icarus Verilog（iverilog）+ VVP，轻量、开源、启动快
• 波形：GTKWave，配合VCD文件，方便Agent解析信号
• Lint：Verilator，速度快，报错信息结构化程度高
• 综合：Yosys，开源，能给出资源占用和简单时序估计
• 版本管理：Git，每次Agent修改都commit，方便回滚和对比

商业工具（Cadence、Siemens EDA）当然更强，但它们的license成本和脚本复杂度，会让你的迭代速度慢一个数量级。前期用开源工具把逻辑跑通，后期再考虑接商业工具，这是我踩过坑之后的建议。

4.3 把"错误日志"翻译成Agent能吃的信号

这是整个Harness里最核心、也最容易被忽略的一环。仿真器吐出来的日志是给人看的，格式混乱、信息冗余。Agent直接读原始日志，很容易抓错重点。

我的做法是写一层日志解析器，把仿真输出结构化成JSON：

# 伪代码示意：把iverilog仿真输出解析成结构化信号 import re def parse_sim_log(log_text): result = { "compile_ok": False, "sim_ok": False, "errors": [], "mismatches": [] } if "error" not in log_text.lower(): result["compile_ok"] = True # 提取不匹配的测试用例 for line in log_text.splitlines(): if "MISMATCH" in line: result["mismatches"].append(line.strip()) if "ERROR" in line: result["errors"].append(line.strip()) result["sim_ok"] = len(result["errors"]) == 0 and len(result["mismatches"]) == 0 return result

有了这个结构，Agent拿到的就不是一大坨文本，而是"编译过了、仿真没过、第3个测试用例在t=120ns时输出期望0x1A实际0x1B"这种精确信号。反馈越精确，Agent收敛越快，这是铁律。

4.4 循环控制：别让Agent无限自我感动

Agent最容易犯的毛病是"我改了，我觉得对了"。所以Harness必须有一个硬性的循环上限和收敛判据。

我的经验参数：

• 单次任务最大迭代轮数：8-12轮
• 连续3轮无改进（错误数不下降）：强制退出，交人工
• 每轮必须记录：改了什么、为什么改、结果如何
• 超过预算（token或时间）：中断并保存状态

这些参数不是拍脑袋，是我在几十次跑飞之后总结的。没有上限的Agent循环，等于烧钱机器。

5. 那些搜索热词背后，藏着真实工程师的痛点

5.1 "cadence瞬态仿真不收敛"——Agent能帮上忙吗

这个搜索词特别真实。瞬态仿真不收敛是模拟电路设计的经典噩梦，原因可能是初始条件、步长设置、模型问题、电路拓扑本身。传统做法是工程师凭经验一项项排查。

Agent在这里的价值，不是"一键解决"，而是把排查清单结构化，并自动尝试常见修复。比如：

• 检查是否有悬空节点
• 检查是否有理想电压源短路
• 尝试放宽reltol/abstol
• 尝试调整初始条件

这些操作在Cadence里都有对应的脚本接口，Harness可以把它们封装成Agent可调用的"修复动作"，让Agent按优先级尝试。这比让Agent"重新生成电路"靠谱得多，因为问题往往不在电路本身，而在仿真设置。

5.2 "cadence仿真器件未定义"——典型的上下文缺失

这个错误通常是因为模型库没加载、工艺库路径不对、或者器件名拼写问题。对Agent来说，这是一个上下文管理问题：它需要知道当前工程用了哪个工艺库、库文件在哪、器件命名规则是什么。

所以Harness里必须有一个"工程上下文"模块，记录这些元信息，并在Agent每次操作前注入。没有上下文的Agent，就像一个不知道自己在哪个工地的工人，工具都认不全。

5.3 "立创EDA AI生成"和"嘉立创EDA画PCB教程"——另一条战线

热词里立创EDA、嘉立创EDA出现的频率很高，这说明EDA+AI的战场不只在高端芯片，也在PCB和中小规模设计。立创EDA这类工具的用户基数大、门槛低、需求碎片化，反而是AI辅助最容易见效的地方。

比如"立创EDA快速调整布线间距""立创EDA原理图里的棱形图案是什么意思"这类问题，都是典型的高频、低难度、可自动化的咨询。一个接入了知识库和操作API的Agent，完全可以胜任这类助手角色。这条战线的商业价值，可能比"AI设计CPU"更实在。

5.4 "agent安全"和"agent anywhere"——被低估的基础设施

"agent安全"这个词值得单独说。在EDA场景里，Agent能改文件、能跑命令、能调用工具，一旦失控，轻则工程损坏，重则资源被占满。所以权限隔离、操作审计、沙箱执行是必须的。

我自己的做法是：Agent的所有文件操作都在一个独立的workspace里，通过Git管理，任何修改都可回滚；所有命令执行都有超时和资源限制；关键操作（如删除、覆盖）需要显式确认。这些不是"高级功能"，是及格线。

6. 如果你要入局，我给几条不客气的建议

6.1 别做"通用EDA Agent"，做"某个环节的专家"

通用Agent是巨头的游戏，个人和小团队进去就是送。但某个具体环节——比如"AXI总线协议验证用例生成""时序约束自动补全""综合日志智能分析"——这些细分场景，需求真实、边界清晰、容易做出差异化。

我认识一个团队，就专做"RTL lint错误的自动修复"，把常见lint规则和修复模式做成知识库，Agent只负责匹配和改写。听起来很窄，但客户付费意愿很强，因为这是工程师每天都要面对的重复劳动。

6.2 把"可验证"当成第一原则

EDA和纯软件不一样，硬件设计的对错是可以被严格验证的。这是你的优势，也是你的枷锁。优势在于你能拿到明确的反馈信号，枷锁在于你糊弄不过去。

所以任何功能，先问："我怎么自动验证它是对的？"如果答不上来，这个功能就不该做。不能验证的AI功能，在EDA里等于不存在。

6.3 别迷信模型规模，Harness的质量决定上限

我见过太多人把精力全花在"换更大的模型""微调更好的权重"上，结果Harness一塌糊涂，Agent再聪明也使不上劲。实际上，在EDA这种强约束场景里，Harness的设计质量对最终效果的影响，往往大于模型本身的差距。

一个好的Harness，能让中等模型跑出优秀结果；一个烂的Harness，能让最强模型变成复读机。这个投入产出比，一定要算清楚。

6.4 尊重领域知识，别用纯软件思维硬套

最后一条，也是最容易被忽视的：EDA是有几十年沉淀的领域，很多"看起来冗余"的流程，背后都有血泪教训。比如为什么要做形式验证、为什么要做DFT、为什么要留时序余量，这些不是官僚主义，是工程现实。

一个不懂硬件的纯软件团队做EDA Agent，最容易犯的错就是"觉得这些步骤可以跳过"。跳过的结果，就是Demo很美、流片很惨。要么自己补硬件知识，要么找一个真正做过芯片的合伙人，没有第三条路。

7. 关于这条赛道，我自己的几点体会

写了这么多，最后说点掏心窝的话。

EDA+Agent这条赛道，现在确实挤满了钓鱼佬，但这不代表赛道本身是假的。恰恰相反，越是有人钓鱼的地方，越说明水里有真鱼。问题在于，你能不能分辨哪些是真需求、哪些是伪需求，能不能沉下心把Harness这种"不性感但决定成败"的活干好。

我自己在这个方向上的体会是：慢就是快。别急着做端到端，别急着刷榜单，先把一个最小闭环跑通——生成一段RTL、自动仿真、自动分析、自动修正、自动验证。这个闭环哪怕只覆盖一个FIFO，只要它是真的能跑、能复现、能扩展的，就比一百个漂亮的Demo有价值。

还有一个很实际的建议：多和一线工程师聊天。他们每天在搜索框里敲的那些词——"瞬态仿真不收敛""器件未定义""布线间距怎么调"——才是这条赛道真正的需求地图。钓鱼佬盯着榜单，认真做事的人盯着这些搜索词。方向对不对，从你关注什么就能看出来。

至于那些还在钓鱼的，随他们去吧。水退了，谁在裸泳一目了然。而你要做的，是在水退之前，把真正能用的东西做出来。