本文转载自公众号“科研汪的自我修养”
想象一个评审会。
老板刚看完一个 RTL Agent demo，转头问产品负责人：以后是不是不用这么多人了？
这句话听起来很残酷，其实和最近软件股承压背后的问题，是同一个问题。表面上，这是市场风格切换。往深一点看，它问的是一个更刺痛码农的问题：如果 AI 都会写代码了，码农甚至软件公司的稀缺性还剩多少？
这不是技术圈自己吓自己。MarketWatch 在 2026 年 7 月初提到，iShares Expanded Tech-Software Sector ETF 年内仍下跌 11.4%，而芯片相关指标年内上涨 76.3%；Barron's 同期也在讨论，AI 会不会削弱传统软件公司的长期价值。
但这篇不是股评。市场涨跌背后有一堆因素：利率、财报、周期、资本开支、出口管制，随便拎一个出来都能讲半天。
我真正想问的是：
当 AI 改变了软件的生产方式，软件的价值到底会被重新定价到哪里？
这个问题一落到 EDA 上，味道就不一样了。因为 EDA，本质上也是软件，而且是半导体行业里最贵、最关键、最难替换的软件之一。
所以问题来了：
如果 AI coding 正在重估普通软件，EDA 凭什么例外？
如果 AI agent 能读 spec、写 RTL、改 testbench、跑工具、debug，EDA 的价值会不会也被打薄？
我觉得，这才是 Agentic EDA 真正值得讨论的地方。它不是又一个“AI 会不会写 Verilog”的问题。
它问的是：
EDA 的价值，到底来自生成代码，还是来自让工程师敢相信结果？
普通 SaaS 被 AI coding 冲击，最容易被打到的是哪一层？代码生成、前端界面、报表、自动化脚本、内部工具、各种 CRUD。
当然，普通 SaaS 也不是没有护城河。数据、流程、权限、生态、客户迁移成本，都很重要。
但 AI coding 首先冲击的，确实是那些主要靠“把人要写的代码和流程，包装成一个更顺手的软件产品”的软件层。AI 一旦能写代码、接 API、改流程，这一层的稀缺性就会被重新评估。
但 EDA 不是这么简单。
EDA 的价值，粗略拆开看，至少有三层：
1
第一层，是Interface，代码和界面。
GUI、脚本、Tcl flow、报告生成、自动化入口，很多都在这一层。这一层会被 AI 改，而且会改得很快。
2
第二层，是Engine，工具执行。
simulation、formal、synthesis、P&R、STA、power analysis、CDC、lint，这些东西背后不是几段漂亮代码，而是算法、物理模型、工艺知识和多年工程经验。
3
第三层，是Trust，验证和 signoff 信任。
也就是客户敢不敢把结果放进 tapeout 流程里；出了问题能不能解释、复现、追责；修完以后怎么证明没有引入新问题。
如果一个软件的价值主要在第一层，AI 来了，它确实容易被打爆。
但如果一个软件的价值在第三层，也就是让一个高风险工程结果变得可信，那 AI 来了，它未必更便宜，反而可能更贵。
因为生成越便宜，验证就越贵。答案越容易出来，判断答案能不能用的人就越值钱。
所以，讨论 Agentic EDA 时，别急着问：“AI 会不会写 RTL？”这个问题太浅。
应该先问：AI 生成设计之后，谁能证明它对？
想象一个很常见的 demo。你给一个 Agent 输入一段 spec。十分钟以后，它吐出一段 RTL。
再过一会儿，它补了几个 testbench，跑了几个简单 case，波形看起来也还行。现场当然会兴奋。老板会兴奋，投资人会兴奋，做 demo 的人更兴奋。
然后你只需要问一句：这东西，你敢放进 tapeout 流程里吗？
空气可能就安静了。因为所有做过芯片的人都知道，“能跑几个 case”和“能签字进入生产流程”，中间隔着一条大河。
一个模块能过几个 directed tests，不等于它满足 spec。
能在一个简单 testbench 里跑通，不等于 corner case 没问题。
仿真能过，不等于 coverage 足够。
coverage 上去了，不等于 assertion 完整。
前端看着没问题，不等于 timing、power、area、CDC、formal、ECO 后面不炸。
举个很小的例子。
Agent 写了一个 FIFO，看起来仿真能过，empty / full 也能翻转。
但问题是：
reset 边界处理对吗？
almost_full 和 backpressure 的关系对吗？读写同时发生时，指针更新对吗？
跨时钟域时，有没有 CDC 风险？formal 能不能证明不会 underflow / overflow？
coverage 有没有打到 wrap-around、burst、stall、reset-interrupt 这些 case？
这时候你会发现，真正的问题不是“AI 会不会写 FIFO”。真正的问题是：这个 FIFO 凭什么被相信？
所以，把 Agentic EDA 理解成 RTL Agent，是最省事、也最容易误导的想象。RTL Agent 有价值。但它只是一个动作器。不是 Agentic EDA 的本体。
Agentic EDA 不应该是：
prompt -> RTL
它至少应该是：
它要能读目标，拆任务，调用工具，读取反馈，定位错误，提出修复，留下证据，最后服务于人的 signoff 判断。这才叫闭环。否则，它只是一个更会写代码的生成器。
这里要先把一个类比拆开。现在很多人理解 IC Agent，会下意识拿 Coding Agent 类比。这个类比有帮助，但也很危险。
Coding Agent 的典型闭环是什么？改代码，跑测试，修 CI，提 PR。这套东西在软件里很自然。
因为软件有几个优势：反馈快，部署快，回滚快，线上还能继续修。但芯片不是这样。芯片设计面对的是 spec、RTL、testbench、assertion、coverage、timing、power、area、PPA tradeoff、formal、signoff evidence。
反馈更慢，代价更高，约束更多。更关键的是，一些错误一旦进了硅，就不是“发个 patch”那么简单。所以 IC Agent 不应该追求 Coding Agent 式的“无人自治”。
至少在相当长一段时间里，它更合理的形态不是“自动写完、自动合并、自动负责”。它更像证据管理员、约束导航员、流程调度员，或者说，一个懂工具边界、懂验证资产、懂失败记录的工程副驾驶。这不是说 IC Agent 永远不会更自动化。
恰恰相反，它会越来越自动化。但在芯片设计里，最高级不一定是“完全无人”。最高级是：它能让人放心签字。
human-in-the-loop 在这里不是落后。它是责任链的一部分。你可以让 Agent 做更多事，但你不能让责任凭空消失。
很多人默认，Agentic EDA 最先爆发的地方，会是 design generation。也就是让 AI 替工程师写模块、改 RTL、搭架构。这当然重要。
但我更愿意押另一个方向：Agentic EDA 的第一主战场，不是 design generation，而是 verification、debug 和 RCA。RCA，就是 root-cause analysis，根因分析。
先说个利益相关：本汪在一家做验证的公司任职，屁股决定脑袋，这个判断你可以打着折听。但也正因为坐在这儿，我每天看到的，都是一线团队真实的卡点。
为什么押验证？
因为真实团队最痛的，往往不是"没人能写出一段代码"，而是：
这个 failure 从哪来？
这个 assertion 为什么炸？
这个 regression 为什么昨天过今天不过？
这个 coverage hole 是 spec 漏了、test 漏了，还是 design 真有问题？
这个 fix 是真修了，还是只是把一个 bug 推到了另一个角落？
这些问题，才是工程里的时间黑洞。设计生成当然有价值，但它的输出如果不能被验证系统接住，就只是更多待审查的候选答案。AI 让设计候选变多，但不会自动让可信结果变多。
而 verification、debug、RCA 这几个环节，恰好特别适合 Agent 先切进去
1
它有结构化反馈：
pass / fail，coverage delta，assertion failure，waveform，log，formal counterexample
2
它重复度高：
regression triage、failure clustering、log reading、test generation、coverage closure
很多不是没有智力含量，而是太耗碎片时间。
它还离钱近：验证时间、debug 时间、signoff 压力，都是芯片项目里真金白银的成本。
公开客户案例也挺说明问题。Cadence 在 ChipStack 的官方材料里引用了几组客户反馈：
Altera 提到在某些区域 verification effort 约 10X 减少，并获得更深的 functional coverage；
Tenstorrent 提到，在三个月、三个 critical design blocks 的评估中，formal verification time 最高减少 4X；
NVIDIA 提到 automated formal test plan generation。
这些数字当然不能外推成所有项目、所有模块、所有团队都能 4X 或 10X。
但它们至少说明一件事：公开案例里最硬的收益点，并不只是“RTL 写得更快”，而是 verification、formal、coverage 和 test plan。
所以请记住这句话：Agentic EDA 的第一桶金，很可能不在“替你设计”，而在“替你把设计放到证据链上”。
所谓 Agentic，不是替你多写几版设计。而是失败以后，它能带着证据回来。
这个判断并不是我们硬拗出来的。你看几个公开材料就会发现，行业叙事已经不再停留在“我能生成 RTL”。
更准确地说，Agentic EDA 也不应该被理解成“RTL 这一层的 Agent”。RTL generation 当然重要，但它只是芯片设计流程里最容易被展示、也最容易被误读的那一段。
真正的 Agentic EDA，可能会长在很多地方：
架构探索；
spec 理解；
IP 集成；
verification planning；
testbench、assertion、coverage；
simulation / formal debug；
PPA 分析和优化；
ECO；
signoff evidence；
甚至项目流程、知识库维护和失败经验沉淀。
也就是说，Agentic EDA 不是一个“RTL 写手”，而是一组会逐渐渗进芯片设计流程的工程能力。问题不在于它到底先落在哪个环节。问题在于：它落到任何环节之后，能不能形成闭环？
Cadence 的 ChipStack，讲的是从 specification 和 high-level description 出发，创建并验证设计，覆盖 coding、testbench、test plan、regression、debug、auto-fix，还要调用底层 EDA tools。
Synopsys 的 AgentEngineer，也不是只讲 RTL generation。它讲的是 multi-agent engineering workflow，强调 planning、tool execution、verification planning、testbench creation，以及 human engineers 的 oversight 和高层判断。
这就很说明问题。真正懂芯片流程的人，都不会把 Agentic EDA 讲成“更会写 Verilog 的 Copilot”。
越接近真实生产，越绕不开工具反馈、验证资产、debug、trace、权限、安全和责任链。所以，Agentic EDA 真正值得争的是：谁能把这些东西做成客户敢用、团队能复用、出了问题能追责的工程系统？
Prompt engineering 对 Agentic EDA 有用。但它不是核心资产。再往前说一步，单纯专用模型也不够。
当然，懂 RTL、懂 spec、懂 assertion、懂 log、懂 waveform 的专用模型会很重要。但如果一个系统只有“更懂硬件的模型”，还远远不够。因为 Agent 工程的主流讨论已经往前走了一步。
早期大家热衷讲 prompt engineering。后来大家发现，真要让 Agent 干活，问题不在那几句话写得多漂亮。问题在于你有没有给它搭一个能工作的 harness。
Harness 是什么？在 Agent 语境里，你可以粗暴理解成：模型外面那整套让它能干活的工程夹具。上下文怎么喂进去，工具怎么接，权限怎么管，状态怎么存，结果怎么评估，错误怎么暴露，日志怎么留，什么时候停下来。
这些东西合在一起，才是 harness。
然后还有 loop。Loop 也不是“让模型一直循环跑”这么简单。
它指的是一个 Agent 能不能在一次行动之后，拿到反馈，再决定下一步：修复、重试、换工具、升级给人，或者停止。
所以，Agent 真正难的地方，不是 prompt，而是：harness engineering 和 loop engineering。
这句话放到 EDA 里，就特别扎实。EDA 的 harness 是什么？
不是一个聊天框。而是一个可执行的工程环境。它至少包括：
spec、RTL、testbench、assertion、coverage、log、waveform、timing report 的组织方式；
simulator、formal、lint、CDC、STA、P&R 的工具接口；
权限、sandbox、版本、seed、trace、diff、replay 的工程约束。
你看 HORIZON 这类研究原型，真正有意思的也不是“又能写一段 Verilog”。
它把硬件设计看成 repository-level code evolution，强调 executable evaluator、acceptance predicate、隔离工作区、状态管理、trace 和 replay。
这背后的意思很直白：Agentic EDA 的问题，不只是生成动作，而是生成之后有没有可执行评估、可回放轨迹和可验收标准。
EDA 的 loop 又是什么？不是“模型生成一版 RTL”。
而是：
也就是跑仿真，读 failure，定位 root cause，改 design 或约束，再跑 regression，看 coverage delta，记录证据，最后回到 signoff 判断。
没有 harness，Agent 接触不到真实世界。没有 loop，Agent 无法从失败中修正。
没有 evidence，Agent 无法进入 signoff 责任链。
这就需要一堆比 prompt 更硬的东西：constraint engineering、verification asset engineering、tool integration、feedback signal design、failure trace、signoff rubric。
AiEDA 这类工作从另一个侧面说明了同一件事：AI-EDA 的基础设施问题，首先是 flow engine、file format、data extraction、data storage 这些东西太碎。
没有数据、接口和 trace 的基础设施，模型再强，也很难稳定接进真实工程流。说白了，prompt 决定一次回答的姿势。Harness 决定它能接触什么世界。
Loop 决定它能不能在这个世界里反复做对。一个 prompt 写得再漂亮，如果它不能调用 simulator、formal、lint、CDC、STA，不能读取 coverage，不能解释 assertion failure，不能把 repair 和证据记录下来，它就很难进入真实流程。这也是为什么我对“提示词秘籍”一直比较警惕。
在普通办公场景里，prompt 写得好，确实能立刻提升产出。但在 EDA 里，真正的问题不是“这句话怎么问模型”。
真正的问题是：
模型拿什么判断自己错了？
错了以后拿什么修？
修完以后拿什么证明？
证明以后谁敢签字？
如果这些问题没有答案，prompt 再漂亮，也只是把 demo 做得更顺。
说到这里，可能有人会问：那是不是未来 Agentic EDA 就会一路冲到无人 tapeout？
我不这么看。
更可能的落地顺序，是一层一层往真实流程里长。
1
第一阶段，read-only。
读 spec，读 log，读 waveform，做 failure clustering 和 regression triage。这个阶段不改设计，只帮工程师把问题看清楚。
2
第二阶段，suggestive。
提出 fix，生成 assertion，补 coverage，写 test，但由工程师审查。这个阶段开始给方案，但不直接负责。
3
第三阶段，supervised execution。
在 sandbox 里自动 patch，自动 rerun，自动比较结果，自动记录 evidence。这个阶段开始闭环，但边界、权限和退出条件要清楚。
4
第四阶段，signoff assistant。
不是替人签字，而是把人签字所需的证据链组织好。
那以后怎么判断一个 Agentic EDA 系统是不是有真东西？别先问“它会不会写 RTL”。
这套方法，可以叫：Agentic EDA 五问
1
第一，它面向的目标是什么？
是 spec？是 coverage？是 debug？是 PPA？还是 signoff？
目标越具体，越容易进入工程闭环。如果一个系统什么都能聊，但说不清它优化哪个工程目标，那多半还停在 copilot 层。
2
第二，它能调用什么工具？
是只会生成文本，还是能调用 simulator、formal、lint、CDC、STA、P&R？
Agentic EDA 的“agentic”，不在于它说话像人，而在于它能行动，并且行动后能读取工具反馈。
3
第三，它拿什么反馈判断对错？
是 test result、coverage、assertion failure、timing report、power report，还是模型自己说“我觉得对”？
如果判断标准来自模型自评，那你要非常小心。在芯片设计里，“我觉得对”不算证据。
4
第四，它失败后如何修复？
能不能定位 root cause？能不能修改设计或约束？能不能重新跑流程？能不能解释这次修复影响了什么？
只会生成，不会修复，不是闭环。
5
第五，它能留下什么证据？
trace、log、diff、coverage delta、失败样本、决策记录，有没有？
没有证据，就没有信任。没有信任，就没有 signoff。
这五个问题，其实也是判断 EDA 价值会被 AI 重估到哪里的五个问题。
一个系统越靠近后面几问，越像 Agentic EDA。越只停留在“生成答案”，越只是一个好用的生成器。按这五问，你大致可以把市面上的系统分成四档：
RTL generator，主要解决“写出来”。
EDA copilot，主要解决“问得顺、查得快、改得方便”。
workflow automation，主要解决“流程能跑起来”。
agentic closed loop，才开始解决“行动、反馈、修复、证据和 signoff 怎么连成闭环”。
所以回到标题。AI 正在重估软件，EDA 凭什么例外？
我的答案是：EDA 当然不会例外。Agentic AI 一定会重估 EDA。
但它重估的方式，不是简单把 EDA 变便宜，也不是简单把工程师替掉。它会把 EDA 的价值从“谁能生成更多设计候选”，推向“谁能组织更可靠的验证闭环”。
换句话说，生成会变便宜。
验证资产会变贵。工具接口会变贵。工程 trace 会变贵。failure history 会变贵。signoff rubric 会变贵。
而人的价值，也会随之迁移。
不是每一步都亲手做。而是定义目标，设置约束，审查证据，承担最后的判断。别再问 AI 会不会替代工程师。
先问：谁定义目标？谁设约束？谁审证据？谁做 signoff？
这几个问题不解决，Agentic EDA 就只能停在炫技。这几个问题一旦解决，EDA 的价值不是被打没，而是会被重新分配。
未来 EDA 的稀缺性，不是“生成一个答案”，而是把答案放进可复现、可解释、可追责的工程系统里。
最后也留个问题给你：你觉得 Agentic EDA 最先真正落地的环节，会是设计、验证、debug，还是 regression triage？
以及，你现在看到的 AI EDA demo，最缺的是生成能力，还是验证闭环？
如果用一句话收束这篇文章，我会这么说：Agentic EDA 的问题，不是能不能行动，而是行动之后，能不能被审计。
