本文转载自公众号“科研汪的自我修养”
Agent 跑了一晚上，第二天给你甩出来一堆东西：几十个 testbench，几百条 assertion，一批 coverage item，还有一张看起来很漂亮的 dashboard。
老板一看，眼睛亮了。这不就是效率起飞吗？
过去一个验证工程师要写几天的东西，现在 Agent 一晚上就吐出来了。
再往后想一步，如果 testbench 可以生成，assertion 可以生成，coverage point 可以生成，formal property 也可以生成，那验证是不是也会变得很便宜？
这个问题很自然。
上一篇结尾我留了个问题：结果交付出来以后，客户凭什么信？
这篇来还这笔债。
前几篇我们一直在讲，AI 会让生成变便宜，所以验证会更重要。
但这里马上会冒出一个反问：验证自己也依赖生成啊。
测试要生成，断言要生成，覆盖项要生成，验证计划也要生成。
既然 AI 连这些都能做，为什么验证不会一起变便宜？
这就是这篇想讨论的悖论。
前面几篇我们已经把 IC Agent 的版图铺开了：有写 RTL 的，有调 EDA 工具的，有做 workflow orchestration 的，有做 debug 的，也有接近 signoff 的。
本文不再泛讲所有 IC Agent，而是把镜头拉近，只看一类最容易被低估、但可能最早进入生产价值区的 Agent：
验证类 Agent。
也就是围绕 testbench、assertion、coverage、formal、regression、debug、RCA、signoff 这条链展开的 Agent。
为什么它值得单独讲？
因为验证天然比很多环节更接近闭环。
它有工具反馈，有 failure，有 RCA，有 regression，有最后敢不敢签字的责任边界。
一个 RTL writer 写完代码以后，价值还要往后传很远；但一个验证类 Agent 如果真的能解释失败、关闭风险、组织证据，它离“交付结果”就近得多。
所以这篇的判断很直接：
再往前推一步：
这里的“证明”，不是狭义的 formal proof，而是工程意义上的 evidence。
它要能说明：这个验证材料从哪里来，跑在什么环境下，失败如何归因，修复如何验证，最后是否足以支持人做下一步判断。
一个 Agent 生成了一堆 testbench 和 assertion，当然有用。但验证负责人不会只问“生成了没有”，对方还会追问“我凭什么信”。
这些东西从哪条 spec 来？
覆盖了哪个风险？
跑完以后留下什么证据？
失败说明什么？
修复后有没有进入 regression？
最后谁敢拿它们支持 signoff 判断？
没有这些问题，所谓验证自动化，很可能只是把“没人敢信的材料”变多了。
这里其实有三层东西：材料、资产、证据，先分清楚会省很多口水。
生成出来的东西，先只是材料。
能被挂到 spec / risk 上，能被工具执行，能留下反馈，才开始像资产。
经过 RCA、repair、rerun，并且能支撑 signoff 判断，才叫证据。
所以，这篇讲的证据链，不是项目结束时整理出来的一份漂亮报告。它是 Agent 决定下一步动作时必须依赖的运行时接口。
Agent 看到 coverage hole，要不要补 test？
看到 assertion failure，要查 design、property 还是 constraint？
看到 regression failure，要定位 diff、查历史 failure，还是升级给人？
这些决策，都必须依赖证据链。
先承认一件事。AI 确实会让很多验证材料变便宜。
写一个 directed test，生成一批 UVM sequence，补几条 assertion，根据 spec 草拟 test plan，分析 coverage hole 后给出候选测试，这些事大概率都会被 Agent 大幅加速。
公开材料里也能看到这个方向，比如：
Cadence 对 ChipStack 的公开客户材料里，最容易被转述的数字恰恰不是“AI 写 RTL 多快”，而是和 verification、formal、coverage 相关；
Altera 提到某些区域 verification effort 约 10X 减少；
Tenstorrent 提到在三个月、三个 critical design blocks 的 formal verification 评估里 verification time 最高减少 4X；
NVIDIA 的引用则涉及 automated formal test plan generation。
这些数字当然要打个折看。它们来自厂商公开材料，有特定场景、特定评估和“约 / 最高”的边界，不能写成行业普遍规律。
但方向很有意思：Agentic EDA 最先冒出硬价值的地方，往往不只是生成 RTL，而是验证、formal、coverage、test plan 这些离工程闭环更近的位置。
所以，不要低估生成验证材料这件事。
它一定有价值。只是它还停在第一层价值。
验证这个词，听起来像一个动作，其实至少分成几件事。
先生成 testbench、assertion、coverage item、formal property，再把它们组织进 simulation、formal、emulation、regression 这些执行流程里。
AI 最先压低成本的，大概率是“生成验证材料”和“组织执行入口”这两层。
但要小心，底层执行本身不一定自动变便宜。
simulation、formal、emulation、regression 仍然有计算成本、调度成本和维护成本。生成越多，后面的去重、归因和证据组织压力反而可能更大。
你还要判断这些材料有没有用：对应哪条 spec？覆盖哪个风险？有没有误测和漏测？
你还要判断风险有没有关掉：
coverage closure 是不是等于 risk closure？
一个 coverage hole 到底是 test 不够、constraint 不对、spec 漏了，还是场景本来不可达？
最后，你还要留下可复查的工程证据：seed、log、waveform、counterexample、RCA、fix diff、rerun result、signoff rubric。
真正卡住生产系统的，往往是这些后半段。
这也是为什么很多“AI 做验证”的 demo 看起来很热闹，但一放到真实项目里就跑不动了。
demo 里最容易展示的是生成：
你看，我把 spec 丢进去，它给我生成了 testbench；
你看，我让它看 RTL，它给我补了 assertion；
你看，它还能根据 coverage hole 生成新的测试。
这些都挺好。
只是验证负责人真正关心的，通常是另一组问题。
它生成的 assertion 是在证明 design，还是在证明一个错误理解？
它补出来的 test 是真的覆盖了风险，还是把 coverage 数字刷得更漂亮？
它报出来的 failure 是 design bug，testbench bug，还是 constraint 写错了？
它修完以后，哪些 case 需要重跑？哪些历史 failure 要对照？哪些证据要留下来，才够下一轮评审使用？
这些问题不解决，生成越快，验证债可能越大。
所谓验证债，不是嫌 test 多。
它指的是，每一个新生成的验证材料，都会带来新的审查、执行、归因和维护成本。
你生成一百条 assertion，就多了一百条需要确认语义、约束、覆盖范围和误报风险的对象。
你生成一千个 test，就多了一千个需要调度、去重、归因和回归管理的对象。
如果没有证据链，Agent 看起来是在帮你关闭风险，实际上可能只是在制造更多“看起来像资产的候选材料”。
拿一个最土的 FIFO 举例。
你让 Agent 看一段 FIFO RTL，让它生成 testbench。
它很可能很快就能覆盖 empty、full、push、pop 这些基本场景。再聪明一点，它会想到 simultaneous read/write，会想到 underflow、overflow，会想到 reset 前后状态。
这已经比很多手写第一版测试快了。
但这还不是验证闭环。
真正要问的是另一组问题：
这个 FIFO 的行为，从哪份 spec 来？
empty/full 的边界条件是什么？
simultaneous read/write 在特殊状态下到底应该怎么处理？
如果 coverage hole 出现了，它是 test 漏了、spec 没说清楚，还是设计里存在不可达状态？
如果 formal 给出一个 counterexample，它说明 property 写错了、constraint 太松了，还是 design 真有问题？
你看，测试生成只是把候选资产摆上桌。
验证闭环要做的，是给这些材料挂来源、跑工具、留反馈、做归因、进回归。
testbench 不是天然可信的。assertion 也不是天然可信的。coverage item 同样不是。
它们都要被挂到某个 spec 或 risk 上，被工具执行，被结果反馈，被失败归因，被修复动作接住，最后被纳入 regression 和 signoff 判断。
所以，一个 FIFO testbench 真正进入验证系统，关键不在于它“生成得像样”，而在于它能回答：它来自哪条 spec，覆盖哪个风险，跑出了什么反馈，失败如何归因，修复后如何进入 regression guard。
否则它们只是文件。甚至可能是漂亮的噪声。
这件事在 regression 里更明显。
一个 failure 被修掉了，不等于风险关闭了。
你至少还要知道：
当时的 seed 是什么？
log 里真正的报错点在哪？
waveform 里第一个异常信号是什么？
RCA 认为根因是什么？
修复 diff 改了哪里？
rerun 了哪些 case？
有没有加 regression guard 防止同类问题回来？
如果这些信息散在文件夹、聊天记录、个人脑子和临时报告里，Agent 下一次遇到类似 failure，还是得从头再分析一遍。
这也是验证类 Agent 和普通 coding agent 很不一样的地方。
写软件时，一个 coding agent 改完代码，跑测试，测试过了，很多场景下已经能给人比较强的信号。
芯片验证不是这样。
这里的“测试过了”经常只是故事的开头：测了什么？没测什么？约束是不是合理？覆盖是不是有意义？失败是不是被正确解释？修复是不是引入了新风险？
所以，别把验证类 Agent 想象成“自动写 testbench 的小助手”。
那只是入口。
验证类 Agent 真正要进入生产系统，必须从“生成材料”走向“组织证据”。
这里要给本文的核心概念下一个定义。
所谓验证证据链，不是项目最后做汇报时整理的一份漂亮报告。
它是一条贯穿 Agent 行动过程的链：
spec / risk → verification asset → run → evidence → RCA → repair → regression → signoff judgment
每一环都要回答一个很朴素的问题。
spec / risk：为什么要测这个？
verification asset：这个 testbench、assertion、coverage item、formal property 从哪里来？
run：它在什么环境、什么版本、什么配置下被执行？
evidence：执行后留下了什么？pass/fail、coverage delta、assertion failure、counterexample、waveform？
RCA：失败说明什么？是 design bug、testbench bug、constraint bug，还是 spec 歧义？
repair：修复动作是什么？diff 在哪里？谁做的判断？
regression：修复有没有进入回归？有没有防止同类问题回来？
signoff judgment：这些证据够不够支持人做下一步判断？
注意，这条链不是为了最后好看。
它是 Agent 做下一步动作时必须依赖的运行时接口。
看到 coverage hole，Agent 要决定：
补 test，改 constraint，查 spec，判定 unreachable，还是升级给验证负责人？
看到 assertion failure，Agent 要决定：
查 design，查 property，查环境配置，还是先找历史相似 failure？
看到 regression failure，Agent 要决定：
定位近期 diff，对照上一次 passing run，聚类同类失败，还是直接交给人？
修复以后，Agent 要决定：
rerun 哪些 case，比较哪些指标，留下哪些证据？
这些都不是一句 prompt 能解决的。
它需要工具反馈，需要工程状态，需要历史记录，需要判断标准，也需要边界清楚的升级机制。
所以我更希望看到的验证类 Agent，不是先给自己贴一个“自主设计”的大标签，而是老老实实把几件事做扎实：有可执行的评估器，有清楚的验收条件，有隔离的运行环境，有可回放的操作轨迹，也有失败后能追到根因的证据记录。
换成 EDA 语言，就是 Agent 每走一步，都要能被工具和规则检查，被验收条件约束，并留下可回放轨迹。
一个最小可行的证据链，大概长这样：
Agent 生成了一条 assertion。它不能只把代码贴出来，还要说明这条 assertion 对应 spec 里的哪一条约束。
然后 formal 跑出一个 counterexample，Agent 要先判断这是 design 真错、property 写错，还是 constraint 放得太松。
如果是 design bug，它要能指到相关 RTL diff；如果是 property bug，它要改 property 并解释为什么改。
修完以后，相关 case 要 rerun，结果要进入 regression guard，最后留下一条 evidence record：来源、动作、失败、根因、修复、复跑结果，都能被人查到。
里面每一步都不复杂。
但少了任何一步，它都容易从“验证闭环”退回“生成材料”。
没有证据链，Agent 只能生成、调用、总结。
有了证据链，Agent 才能行动、反馈、修复、回放，并在不确定时升级给人。
人也不用每次从零解释所有碎片，而是审证据、审边界、审判断。
这就是我说的，证据链不是最后的报告，而是 Agent 的运行时接口。
这也意味着，验证类 Agent 的护城河，关键不在谁有更多数据，而在谁能把数据组织成判断机制。后面我们会回到这个问题。
证据链一旦立起来，很多老概念都会被重新估价。
第一个就是 coverage。
过去 coverage 很容易变成 KPI。
功能覆盖率多少，代码覆盖率多少，哪些指标达标了，哪些还没达标。
项目会上大家盯着数字，数字越接近 100%，心里越踏实。
但做过验证的人都知道，coverage closure 不等于 risk closure。
Coverage KPI 当然有用，它是项目管理需要的仪表盘；只是这个仪表盘本身，不是风险关闭的充分证明。
覆盖率高，不代表风险真的关掉了；覆盖率低，也不代表每一个 hole 都值得补。
真正重要的是解释 coverage。
一个 coverage hole 到底意味着什么？
是 spec 漏了，test 漏了，constraint 写错了，场景不可达，还是 design 真的有问题？
如果 coverage 只是 KPI，Agent 看到 hole 就会本能地补测试。补到最后，数字可能好看了一点，验证系统却变得更臃肿、更难维护。
如果 coverage 是导航地图，Agent 看到 hole 后要先判断路况：这条路该不该走？是地图漏标了，还是路被封了，还是前方真的有坑？
Synopsys VSO.ai 公开材料里讲 coverage guidance、coverage RCA，以及从 RTL / stimulus 推断 coverage gap；
Cadence Verisium 讲 coverage boost、test failure triage、RCA、passing/failing comparison；
Siemens Verification IQ 讲 requirements traceability、coverage、regression、metrics dashboard。
它们的共同点不是“coverage 数字很重要”这么简单，而是 coverage 正在被放进更完整的工程判断流程里。
在 Agentic EDA 里，coverage 的价值不应该只是告诉你“还差多少”，还应该告诉 Agent 下一步做什么：补 test，改 constraint，查 spec，解释 unreachable，定位 design bug，或者升级给人。
不能驱动下一步行动的 coverage，只是一个数字。
能驱动下一步判断的 coverage，才是导航地图。
第二个会被重估的，是 failure。
很多团队对 failure 的本能反应是：快点清掉。
这个反应当然没错。
项目赶 deadline，谁也不想看一堆红色 regression report。
问题是，如果 failure 只被当成要清掉的噪音，它里面最值钱的东西就丢了。
真实项目里，最值钱的往往不是第一版 test，而是失败之后留下来的信息。
seed、log、waveform、counterexample、assertion failure、RCA、fix diff、rerun result、regression guard，这些东西合在一起，才是 failure trace。
如果没有 failure trace，Agent 每次遇到问题都像第一次遇到问题。它可以很聪明地分析一遍，但很难稳定复用团队过去的经验。
如果 failure trace 被组织成 taxonomy 和可检索的证据链，事情就不一样了。
Agent 看到一个 failure，不是从一堆 log 里盲猜，而是先问：
这类 failure 过去出现过吗？
当时 root cause 是什么？
是 design 改动引入的，还是 testbench 老问题？
类似 waveform 里第一个异常点在哪里？
历史上这种修复有没有副作用？
上次 rerun 了哪些 case？
这就是工程记忆。
所以 failure 不只是 bug 列表。
它是下一轮闭环的病历。
病历不是为了证明你生过病，而是为了让下一次诊断更快、更准、更少走弯路。
验证类 Agent 真正的学习，也不应该只发生在模型参数里。
更现实、更可控、更适合企业落地的学习，恰恰发生在 failure taxonomy、debug pattern、RCA template、regression guard 这些工程资产里。
模型会变，工具会变，项目会变。
但一个团队怎么理解 failure，怎么分类 failure，怎么从 failure 走到修复，再怎么把修复沉淀进 regression，这套东西会越来越值钱。
第三个会被重估的，是反证机制。
AI 生成候选答案越便宜，系统越需要快速排除错误。
换个更工程化的说法，就是校准机制越值钱。
这句话放在验证里尤其重要。
AI 可以生成 assertion，但 assertion 本身也可能错。
它可能误解 spec，可能漏掉前提，可能把环境约束写得过强，也可能写出一个永远不会触发的漂亮摆设。
AI 可以生成 test，但 test 也可能错。它可能测了一个无意义场景，可能把 design 的正确行为误判成 failure，也可能为了刷 coverage 引入一堆维护成本。
AI 可以生成 patch，但 patch 更可能错。因为芯片设计里，局部修复经常会挪动风险，而不是消灭风险。
所以越是生成便宜，越不能只相信生成。
你需要 formal property、counterexample、assertion failure、bounded proof、等价检查、仿真对照、regression comparison 这些能把错误逼出来的机制。
这里的反证，不是非要证明某个命题为假，而是把候选答案放进工具、规则和流程里，让错误尽快暴露，让边界尽快清楚。
这不是说 formal 会取代 simulation，也不是说 property 是万能答案。
我的意思更朴素：Agentic EDA 真要进入生产，不能只靠会生成，还要靠能被证伪。
芯片设计里的 Agent 不能只会提出答案，还必须不断被工具、规则、仿真、形式化方法和真实流程校准。
这就是硬件和很多软件场景的差别。
软件里有些错误可以上线后修，可以灰度，可以回滚。芯片不是这样。
芯片越往 tapeout 靠近，错误越贵，回滚越痛，责任越硬。
所以验证类 Agent 的核心能力，不能只是多给几个候选答案。
它要能把候选答案放到反证机制里，让错误尽快暴露，让边界尽快清楚，让人知道什么时候该信，什么时候不该信，什么时候必须升级。
生成能力决定 Agent 能提出多少答案。
反证机制决定这些答案有没有资格进入工程流程。
说到这里，可以回到一个产业问题。
验证类 Agent 的护城河在哪里？
很多人第一反应是数据。
谁有更多 log，更多 waveform，更多 coverage report，更多 bug record，谁就更有优势。
这个判断有一半是对的。
数据当然重要。没有真实项目数据，没有工具反馈，没有 failure 历史，Agent 很难进入深水区。
但只说“数据多”是不够的。
上一篇说过，数据不是金矿。放到验证里，这句话会变得更具体。
真实项目里的数据，常常散在不同工具、不同文件格式、不同脚本、不同数据库和不同工程师的习惯里。
log、waveform、coverage report、RCA、聊天记录、bug 系统、代码 diff、回归脚本，经常各管各的。
它们只有被组织进判断流程，才开始从存储成本变成工程资产。
真正值钱的是把它们组织成判断机制。
evaluator：什么输出算好，什么输出不够？
failure taxonomy：失败怎么分类？哪些优先级最高？哪些可以合并？哪些必须升级？
debug pattern：某类 failure 通常对应什么 root cause？第一时间应该看哪里？
evidence template：什么证据能进入评审？哪些只是中间噪声？
signoff rubric：什么情况下可以继续往下游走？什么情况下必须停下来？
这几个东西，比“我有多少数据”更接近护城河。
举个很小的例子。
一个像样的 failure taxonomy，至少要能区分 design bug、testbench bug、constraint bug、spec ambiguity、tool/config issue。
否则 Agent 看到失败，只能泛泛地说“可能需要进一步分析”。
一个像样的 signoff rubric，也至少要回答：
哪些 coverage hole 可以接受，哪些必须关闭，哪些必须升级给人；
哪些 assertion failure 可以归为环境问题，哪些必须追到设计责任；
哪些修复必须进入 regression guard，哪些只是一次性修补。
这些东西看起来不如大模型性感，但它们才是验证类 Agent 能不能进生产系统的骨架。
他不关心你看过多少 waveform，他关心你能不能更快定位问题。
他不关心你存了多少 coverage report，他关心你能不能告诉他哪个 hole 真有风险。
他不关心你生成了多少 assertion，他关心你能不能解释这些 assertion 从哪来、覆盖什么、什么时候失效、失败后说明什么。
这也是验证类 Agentic EDA 公司可能拥有更高天花板的地方。
过去很多 EDA 工具卖的是能力：我能仿真，我能调试，我能跑 formal，我能看 coverage。
Agentic 时代，如果能交付的是结果，价值锚点就变了：我帮你缩短 debug，我帮你解释 failure，我帮你关闭 coverage risk，我帮你把 signoff 证据组织到可以评审。
从工具能力到工程结果，中间隔着的就是证据链。
那对一个工程团队来说，怎么判断自己是不是真的在建设验证证据链？
这里给一个简单框架，叫“验证证据链六问”。
1
第一问：这个验证材料从哪条 spec 或风险来？
这一问防止无源测试。
如果一个 test、assertion、coverage item 说不清自己对应哪条 spec、哪个场景、哪个风险，那它就只是一个候选文件。它可能有用，但还没进入证据链。
2
第二问：它覆盖了什么场景，没覆盖什么场景？
这一问防止 coverage 幻觉。
覆盖不是一个数字，而是一张风险地图。你不仅要知道覆盖了什么，还要知道没覆盖什么，以及为什么没覆盖。
3
第三问：它运行后产生了什么反馈？
pass/fail、coverage delta、assertion failure、counterexample、waveform，这些都不是附件，而是 Agent 判断下一步的输入。
没有反馈，生成就是孤立动作。
4
第四问：失败后有没有 RCA、fix diff、rerun result？
这一问把失败变成资产。
没有 RCA，failure 只是红灯。没有 fix diff，修复不可追踪。没有 rerun result，没人知道风险是不是真的回落。没有 regression guard，下次还会回来。
5
第五问：这些证据够不够支持人做 signoff 判断？
这一问把 Agent 输出接到人的责任边界。
Agent 可以生成、执行、总结、建议，但最后能不能往下走，仍然要有人判断。人的判断不应该建立在“我感觉差不多”上，而应该建立在可复查、可解释、可追责的证据链上。
6
第六问：这条经验有没有沉淀成下一次可复用的 guard？
它可以是 regression guard、failure taxonomy、debug pattern、coverage rule，也可以是 signoff checklist。如果经验只是一次性处理 failure，而没有沉淀成 guard，它就还没有变成组织级验证资产。
这六问不是为了把流程搞复杂。恰恰相反，它是为了防止团队被“生成很多东西”迷住。
六问答不上来，生成越快，验证债越大。
以后你看一个验证 Agent，不要先问它能生成多少 testbench、多少 assertion、多少 coverage item。
先问它：
生成出来以后，能不能回答这六个问题？
如果不能，它仍然只是一个很能干的生成器。
如果能，它才开始像一个可以进入生产系统的验证 Agent。
写到这里，可能有人会问：如果 Agent 能生成测试，能跑 regression，能读 log，能做 RCA，验证工程师的位置在哪里？
我的答案是：位置会变，但不会消失。
过去很多验证工程师的时间，被消耗在写脚本、补测试、跑回归、翻 log、看 waveform、整理报告这些具体动作里。
Agent 进入以后，这些动作会被加速，甚至部分被接管。
但越是这样，人的位置越要往上移。
人要定义什么算证据：什么叫覆盖了这个风险，什么叫 failure 已经被解释清楚，什么叫 fix 没有引入新问题，什么情况下 Agent 可以继续行动，什么情况下必须停下来升级，什么证据足够支持 signoff。
验证里的 human-in-the-loop，并不是自动化不够强时的临时妥协。它本来就是责任边界的一部分。
这些问题，才是验证类 Agentic EDA 里人的新位置。
所以这篇不是在说，验证工程师以后不用写测试了。
恰恰相反。
当 AI 让写测试变便宜以后，验证工程师真正值钱的部分会更清楚地露出来：定义风险，组织证据，解释失败，设置边界，做最终判断。
工具会越来越会生成，Agent 会越来越会执行。
但生产系统最终需要的，是一条能被复查、能被回放、能被追责的证据链，而不是一堆看起来很像答案的材料。
这也是我对验证类 Agent 的基本判断：
Agentic EDA 的验证命门，不是生成更多测试，而是让每一次生成、执行、失败、修复和判断，都能进入证据链。
生成越便宜，证明越值钱。
