从卖工具到卖结果，本土 EDA 的窗口在哪里？

本文转载自公众号“科研汪的自我修养”

想象一个 POC 评审会。

本土工具刚跑完一批 case，报告看起来也不错。

你讲完结果，客户负责人没有立刻问价格，也没有问愿不愿意深度合作，而是先问了一句：

这个 case，Cadence / Synopsys 上是什么结果？

这句话，就是过去很多本土 EDA 公司绕不开的现实。

国产替代当然重要。没有它，很多本土 EDA 公司连进门机会都没有。

但做过 EDA 的人都知道，进门机会和主流程信任之间，隔着很远。

客户愿意试，不等于愿意把关键路径交给你；
愿意买，不等于愿意在关键路径上给你足够高的付费锚点；
愿意支持国产，不等于 tapeout 前敢把最后责任压在你身上。

所以本土 EDA 长期面对一个很拧巴的局面：

你必须证明自己足够像三大家，才有资格进门；又必须证明自己不只是替代品，才有可能进入主流程。

但只要评分表仍由三大家定义，你就很难摆脱被它们定价的命运。

这些证明当然都要做：

你要在更多 case 上跑得稳，要让结果足够接近甚至超越三大家，要让 flow 接上客户已有的脚本、数据库、IP 体系和验证环境，也要让客户相信，真出了问题，找得到人、追得到因、修得动。

问题在于，只要还在这张评分表里竞争，本土 EDA 就很容易陷入一种苦苦追赶：

POC 很多，深度替换很慢；服务做得很重，产品溢价不高；客户愿意给机会，但关键节点还是先问一句：和三大家比怎么样？

现在，Agentic EDA 来了。

前两篇其实已经铺了两层地基。

第一篇

讲的是：EDA 当然会被 AI 重估，但它不是普通 SaaS。它真正贵的地方，不只是代码和界面，而是工具执行、工程证据和 signoff 信任。

第二篇

讲的是：IC Agent 的护城河不在聊天入口，而在设计意图、工程资产、工具引擎、流程闭环和 signoff 信任这些工程控制点。

这篇再往下一层。

如果 EDA 的价值会被重估，IC Agent 的地权会被重新分配，那下一个问题就是：

在这个新格局里，本土 EDA 的窗口在哪里？

我在上一篇展开过一个判断：

Agentic EDA 未必会压缩 EDA 行业价值，反而可能把价值池做大。

原因很简单，过去 EDA 公司卖 seat、license、工具模块，很容易被放进采购表格里比功能、比价格、比兼容性；但 Agentic EDA 如果真的能交付结果，客户买的就不只是“我有一个工具”，而是：

“我能不能帮你缩短一次 debug”
“我能不能关掉一个 coverage hole”
“我能不能把一次 ECO 风险讲清楚”
“我能不能把一段验证证据组织成评审能接受的包”。

计价锚点一旦从“工具有没有”移动到“结果交没交出来”，EDA 的价值就会从工具预算，往项目周期、工程人力、tapeout 风险和 signoff 信任那边挪。

换句话说，Agentic EDA 有可能把 EDA 从“卖工具能力”，推向“卖工程结果”。

这对三大家是机会，对本土 EDA 也是机会。只是两边能抓住的机会，不是同一种。

它到底会给本土 EDA 带来一个新窗口，还是让这条路变得更残酷？

我的判断是，两者都会发生。

如果所谓 Agentic EDA 只是让 AI 更方便地调用现有 EDA 工具，三大家大概率会更强。

因为真实工程越往深处走，越离不开完整工具链、客户 flow、signoff 信任、跨工具数据和责任边界。

但如果 Agentic EDA 让一部分价值从“买工具”转向“买结果”，本土 EDA 可能第一次有机会不再只回答“我和三大家差多少”，而是先回答另一个问题：

这个工程问题，我能不能帮你交出来？

这才是本土 EDA 在 Agentic EDA 时代最值得讨论的窗口。

本土 EDA 的窗口 = 结果交付 × 专业 subagent

这不是一个精确公式，而是给后面讨论立一根钉子：不要先去做一个“中国版 Super Agent”，而要在某个真实工程断点上，把问题交付到可判断、可复查、可继续行动。

不是弯道超车，也不是继续做边角料，而是竞争单位变了：过去客户买的是工具，现在某些场景里，客户可能开始买一个可验收的工程闭环。

三大家不是同一种打法

先说三大家。

很多讨论会把 Cadence、Synopsys、Siemens 放在一起，统称为“三大家”。

这在传统 EDA 讨论里没问题，但在 Agentic EDA 里，最好拆开看。

先说明一下，下面不是给三家公司做完整战略画像，而是从公开叙事里抓它们在 Agentic EDA 上最突出的相对重心。

真正的公司战略一定比一句话复杂；但正因为三家的重心不同，本土 EDA 才不能简单问“我要不要也做一个 Agent 平台”，而应该先问：我到底要占哪个工程判断节点？

从公开叙事看，Cadence 是三家里最明确把 Super Agent 放到前台的一家。

它明确在讲 agentic AI、super agents、virtual engineers，也在讲从设计规划、验证、物理实现到 signoff 的多步骤 workflow 编排。

它的说法不是“我给你一个聊天助手”，而是把 Agent 放进 Cadence 自己的工具链、物理模型和 signoff-accurate results 里。

这条路很有野心。

但要分两层看。

第一层，如果 Cadence 在自己的工具栈里做垂直闭环，成功概率不低。

因为它有工具，有数据流，有客户习惯，有 signoff 语义，也有把 AI 塞进既有产品的能力。比如让 Agent 在 Cadence 自己的仿真、验证、物理实现和 signoff 工具之间做编排，这件事天然有优势。

第二层，如果 Cadence 想成为客户项目组的全流程 cockpit，难度很大。

原因不在技术 demo，而在组织边界。

大客户的 flow 很少是纯 Cadence flow。它里面有多家工具，有内部脚本，有历史数据库，有 IP 管理系统，有项目管理系统，有公司自己的设计规范、权限体系和责任边界。更关键的是，客户未必愿意把任务编排权、数据边界和最终责任交给单一 EDA 供应商。

所以 Cadence 的 Super Agent 在自家栈内可能很强，但要成为客户项目组的总控大脑，难度比 demo 大得多。

越像 Super Agent，越要跨越工具边界；越像客户 cockpit，越要跨越组织边界。

前者难，后者更难。

再看 Synopsys。

至少从 DSO.ai、VSO.ai、TSO.ai 这条公开产品线看，Synopsys 更像把传统强工具变得更聪明。

DSO.ai 是 design space optimization，帮你在巨大的设计空间里做 PPA 优化。VSO.ai 是 verification space optimization，帮你做覆盖率收敛、冗余减少、coverage RCA。

TSO.ai 是 test space optimization，围绕 pattern count、ATPG turnaround、测试成本这些指标做优化。

这当然很强。只是它的底色仍然是工具思维，而且这是褒义。

EDA 本来就需要工具思维。没有深工具，没有真实 engine，没有客户长期打磨出来的 flow，Agentic EDA 很容易变成嘴上聪明、工程上发虚。

Synopsys 的优势恰恰在这里：它把 AI 做进具体工具、具体指标、具体优化问题里。这种路线不性感，但可靠。

它的问题也在这里：如果 AI 始终停留在每个工具内部做优化，价值仍然被传统工具边界框住。它能让发动机更聪明，却未必重新定义驾驶舱。

至少从 DSO.ai、VSO.ai、TSO.ai 看，Synopsys 的 AI 更像把发动机做得更聪明，而不是先去抢驾驶舱。

这可能是更稳的路，但未必是最能改写商业模式的路。

Siemens 这条线：

公开叙事里最值得注意的是另一件事：它更强调 multi-tool、multi-agent workflow orchestration，也强调 third-party tools、guardrails、custom workflow 和 enterprise infrastructure。

这条叙事和 Cadence 不太一样。

Cadence 更像说：我有很强的工具栈，我来做 super agent。

Synopsys 更像说：我把每个强工具都变得更智能。

Siemens 至少在叙事上更像说：我提供一个可接入、可治理、可编排的 workflow agent 底座。

这条路可能没那么容易被市场一眼看懂，但它有一个现实优势：客户本来就是多工具、多流程、多组织边界的。

一个强调开放编排和治理边界的 agent framework，未必最炫，但可能更贴近真实落地。

叙事是一回事，落地是另一回事。

能不能真的跨第三方工具形成客户信任，还要看产品深度。

但这一点至少提醒我们，三大家在 Agentic EDA 上不是同一种打法：

Cadence 押 Super Agent，
Synopsys 押 tool-native AI，
Siemens 更像押 workflow orchestrator。

这三个方向都会给本土 EDA 带来压力。它们留下的缝，也不一样。

本土 EDA 不该上来做“中国版 Super Agent”

如果三大家都在动，本土 EDA 应该怎么做？

不是说本土 EDA 永远不能做平台。

而是说，现阶段最危险的答案，是做一个“中国版 Cadence Super Agent”。

听起来很豪迈，也很容易出 PPT。

国产 IC Agent 平台，全流程智能设计，统一调度多工具，从 spec 到 signoff 一站式交付。

问题在于，这个位置太大了。

它既要打三大家的完整工具链，又要拿到客户内部 flow，又要接客户脚本、IP、数据和项目管理系统，还要承担总控层的责任边界。

更麻烦的是，对于每个有一定规模的设计公司，大概率都会搭一个自己的 Agent cockpit。

它可能不一定很漂亮，但它会接公司自己的代码库、IP 库、验证环境、脚本系统、项目管理系统和权限体系。它会决定任务怎么拆，数据怎么流，哪些信息能给外部 agent，哪些必须留在内部。

外部 EDA 公司、IP 公司、startup，可以作为 subagent 被接进来。

但总控权，大客户会很谨慎。

所以本土 EDA 最危险的姿势，是把自己想象成客户项目组的总控大脑。

更现实的位置，是成为某个关键节点上不可替代的专业 subagent。

别急着抢 cockpit，先抢专业判断节点。这听起来没那么宏大，但商业上可能更实在。

因为结果型 Agent 的价值，不一定来自“我控制全流程”，也可以来自“这个关键问题只有我交得出来”。

比如：

regression failure 聚类和根因定位。
coverage closure 里的洞察和修复建议。
formal counterexample 的解释和设计意图反推。
CDC/RDC warning 的分层、排序、waiver 和修复闭环。
DFT/ATPG 的失败诊断和 pattern debug。
ECO 影响分析和候选修复。

这些点看起来不如 Super Agent 大，但如果能交付结果，就会离客户付费更近。

本土 EDA 的新窗口，在于把某个工程摩擦做深，做到可验收、可复查、可复用。

本土 EDA 也不是同一种起手式

这里还要再往下走一步：不能把“本土 EDA”当成一个整体。

这几年国内已经出现了一批比较领先的 EDA 公司，但它们的起点完全不同。

有的起点在全定制、模拟、版图、制造和封装协同；
有的起点在验证、debug、formal、原型验证和硬件仿真；
有的起点在器件建模、工艺仿真和 DTCO；
还有一些是非常垂直的点工具和专业分析能力。

所以，本土 EDA 的 Agentic 窗口，不是一个统一窗口。

它取决于每家公司手里原本沉淀了什么资产：工具资产、工艺资产、验证资产、系统级 debug 资产，还是客户现场服务资产。

不同资产，应该长出不同 Agent。为了避免把它们混成一团，我更愿意把本土 EDA 看成四种起手式。

更麻烦，也更有机会的是，它们面对的客户工程路径也在分叉。

过去谈 EDA，大家很容易默认一条全球化、相对统一的先进工艺演进路径：先进节点往前走，工具、IP、PDK、signoff 标准围着头部 foundry 和头部客户转。

现在不是这样了。

先进节点还在往前走，但成熟工艺、特色工艺、先进封装、chiplet、3DIC、本土供应链、不同 foundry 的 PDK 和设计规则，也都在变得更重要。

这不是简单的“谁更先进，谁更落后”。

它意味着不同地区、不同客户、不同工艺平台之间，开始出现更多工程路径分叉。

而工艺一分叉，设计方法就会分叉；设计方法一分叉，工具 flow、模型、规则、验证重点、signoff 证据也会分叉。

所以 Agentic EDA 时代，本土 EDA 的机会，不取决于谁喊得更像平台，而取决于它手里原本沉淀的是哪类工程资产，以及这些资产能不能贴住正在分叉的工程路径。

第一类，是全定制、模拟、版图、制造、封装和 3DIC 相关的平台型厂商。

这类公司手里真正值钱的，是 PDK、器件模型、版图规则、寄生参数、DRC/LVS、仿真回归、工艺约束和设计约束之间那一整套灰色经验。

它们的 Agentic 机会，更多在 analog/layout/process 这些深水区。

比如，模拟电路设计里有大量经验判断：

这个拓扑为什么选？
这个尺寸为什么调？
这个 corner 为什么过不去？
版图迁移时哪些规则看起来是 DRC，实际背后是工艺和可靠性约束？
先进封装和 3DIC 里，芯片、封装、热、供电、互连之间的约束怎么一起看？

这些东西过去很难做成一个标准按钮。

但 Agent 可以把它们变成一类 design/process/layout agent。

这个故事不适合写成“AI 帮你从 spec 生成芯片”，更现实的说法是：

AI 帮工程师缩短工艺、模型、版图和设计意图之间的反馈周期。

第二类，是验证、调试和系统级确认型厂商。

这里再声明一句利益相关：本汪在验证相关 EDA 公司任职，所以这一段请打个折听。

但也正因为如此，我对验证、debug 和系统级确认这条线的一线感受会多一些。

这类最接近结果型 Agent 的逻辑，因为验证天然围绕失败展开。

失败会留下 log、waveform、coverage、counterexample、assertion、testplan、bug record、rerun 结果。

只要这些东西能被组织起来，就天然有机会形成 Agent loop。

数字验证、前端验证、原型验证、硬件仿真和系统级验证，应该放在一起看。

它们工具形态不同，客户场景不同，但 Agentic 机会的底层逻辑是一样的：

失败能不能被解释，场景能不能被回放，修复能不能被验证，最后能不能留下证据。

区别只是层级不同。

数字前端验证更靠近 testbench、assertion、coverage、formal、simulation、debug 和 bug record。

原型验证、硬件仿真和系统级验证更靠近编译失败、分割不合理、映射出错、接口连错、软硬件协同 bring-up、trace 太长看不动，以及某个系统场景无法稳定复现。

但它们都不该只讲“加速验证”。

验证类 Agent 不是多生成几个 testbench，或者多生成几条 assertion。

生成当然有用，但真正的机会在：

failure taxonomy、
debug pattern、
coverage closure、
counterexample explanation、
rerun strategy 和 evidence package。

也就是说，它不是“帮你写更多测试”，而是“帮你证明问题被发现、被理解、被修复、被关掉”。

这类厂商如果能把验证工具、验证管理、debug、formal、仿真、覆盖率、原型系统、硬件资源约束、trace 和客户现场经验连起来，非常有机会做出很深的专业 subagent。

风险当然也在。

如果最后只是把验证工程师的脚本助手包装成 Agent，就很容易被大模型和客户内部自动化吞掉。

它必须往“验证结果交付”走。

第三类，是器件建模、工艺仿真和 DTCO 型厂商。

这类在大众叙事里可能没有 RTL writer 热闹，但门槛可能更高。

它不太像聊天 Agent，也不太像 coding agent，更像 process/model/design loop agent。

这里的核心资产不是代码，而是模型和反馈：

测试数据怎么变成器件模型？
工艺窗口怎么影响电路性能？
模型质量如何影响 SPICE 仿真可信度？
设计端的需求又如何反过来推动工艺参数、模型抽取和 DTCO trade-off？

这些问题离普通数字前端工程师的日常很远，但它们非常 EDA，而且数据、模型、验证门槛都很高，适合做成 tool-native Agent。

第四类，是垂直点工具和专业分析型厂商。

这一类和第二类会有交叉。

我把验证、debug 和系统级确认单独拎出来，是因为它们更容易长出完整闭环；这里说的是更窄的专业分析节点。

比如：

CDC/RDC、
DFT/ATPG、
ECO、
SI/PI、
EM/IR、
低功耗、
安全检查、
封装协同等。

这些方向看起来窄，但并不等于没前途。问题在于是否会变成能提供独特价值的专业 subagent。

另外还要单独提一句综合、布局布线和物理设计相关工具。它们不是边缘点工具，而是数字实现主流程的一部分。

也正因为它们太靠近 P&R、STA、signoff 和客户主 flow，Agentic 机会不能讲成泛泛的“一键实现”。

更现实的窗口，是在实现收敛的局部闭环里做深：

综合约束检查、QoR regression 归因、congestion / timing / power 问题定位、ECO 候选修复、变更影响评估，以及特定工艺和客户 flow 下的可复查证据。

这类 Agent 的关键，不是会不会调用实现工具，而是能不能解释一次收敛为什么失败、下一步该动哪里、动完以后证据是否足够支撑评审。

所以，本土 EDA 的 Agentic 机会不是一句“本土更懂本土客户”就能概括的。

它要看每家公司手里到底沉淀了什么：

工具资产、流程资产、工艺和模型资产、验证资产、系统级 debug 资产，还是客户现场反复打磨出来的服务资产。

不同资产，应该长出不同 Agent。

全定制/模拟/制造/封装类，不必急着讲数字前端总控；
验证、debug、原型和系统级确认类，不该停在 testbench/assertion 生成或者“加速验证”；
建模/DTCO 类，不必追逐聊天入口；垂直点工具类，不该满足于被调用。

工艺路径分叉，会放大本土 EDA 的局部工程地权。

过去三大家最强的地方之一，是它们沉淀了全球主流先进工艺和头部客户 flow 的事实标准。

这个优势不会消失。

但当更多项目开始围绕本土工艺、特色工艺、先进封装、系统级集成和特定应用做优化时，客户需要的不只是“通用最优工具”，还需要“贴着这条工艺路径和这类项目约束走”的工程闭环。

如果本土 EDA 只是追三大家的通用工具能力，当然很辛苦。

但如果它能在某些本土工艺、本土封装、本土 IP、本土客户 flow 里，把模型、规则、验证、调试和证据连成闭环，它争的就不只是“国产替代”，而是一条正在分叉出来的工程路径里的反馈闭环。

这也是为什么全定制、建模、DTCO、封装协同、系统级验证这些方向，不能只当成边缘点工具看。

工艺越分叉，越需要把“空间上的工艺差异”转成“时间上的快速反馈”。

这个问题后面可以单独展开，这里先按住不岔开。

当工艺路径不再只有一条，EDA 的价值会越来越体现在缩短反馈周期；Agentic EDA 正是在把反馈周期产品化。

这也是本土 EDA 讨论里最容易被忽略的一点：

本土 EDA 的分化，不是 Agentic EDA 之后才开始的。Agentic EDA 只是把这种分化放大了。

旧工具转 Agent，点工具会分化

从产品形态看，一条路径是旧工具长出 Agent。

这类机会最好理解。

传统 EDA 工具本来就有客户场景、有输入输出、有工具反馈，也有大量服务经验。

但点工具不会集体逆袭。

浅的点工具会被吞噬，深的点工具才可能变成专业 subagent！

什么叫浅？

只提供底层 API，等着别人调用。只报一堆 warning，不参与工程判断。

只生成一段代码，不负责验证。只做局部功能，但不掌握 workflow、evaluator、evidence 和 result delivery。

这种点工具很危险。未来客户自己的总控 Agent、三大家的平台型 Agent，或者某个上层 workflow Agent，都可能把它变成一个可替换插件。

它被调用了，但价值不一定留在它手里。

什么叫深？

它占住一个高频、高痛点、可闭环的工程任务。有真实工具反馈，知道怎么判断结果，也能把服务经验沉淀成 taxonomy、workflow、evaluator、证据模板和 Agent loop。

它不只是告诉你“这里有个问题”，还能把问题往前推，直到“这个结果可以被验收”。

这里不需要再列一遍工具名单。

判断标准其实很简单：

它是不是把一次失败推进到 root cause、修复建议、回归验证和评审证据。

只会生成 assertion，不够；
只会总结 log，不够；
只会把 warning 翻译成人话，也不够。

真正的价值在 triage 和闭环：

哪些是真问题，
哪些是噪声，
哪些今天必须修，
哪些可以 waiver，
修复会不会引入新问题，
waiver 的证据能不能被复查。

无论是验证、CDC、DFT、ECO，还是功耗、timing、物理实现辅助，最后都要回答同一个问题：

能不能在真实 flow 旁边，形成一个可复查、可 rerun、可解释的局部闭环。

所以，点工具不是没前途，是浅的点工具没前途。

深的点工具，可能正是未来最值钱的专业 subagent。

还有一类机会，过去根本没有工具

Agentic EDA 还有另一类机会：

过去 EDA 工具链里没有对应工具，但项目里一直有人在做。

比如读 spec、拆接口约束、写 RTL、根据失败反馈改 RTL、做 design review，或者把 log、coverage、counterexample、waiver、rerun 结果整理成评审证据。

过去我们有仿真器、综合工具、formal engine、lint、CDC、debug 工具和 IDE，但并没有一个真正像“初级 RTL 工程师”一样理解设计意图、写代码、根据反馈修改代码的工具；也没有一个真正像“资深设计评审人”一样，提前告诉你这段 RTL 为什么未来会难验证、难综合、难维护的工具。

所以全新的 EDA Agent 机会，不一定来自替代某个已有工具，也可能来自产品化工程师过去用经验连接的那段空白。

RTL writer 是最容易被看到的一类，但它不是本文重点。

纯写 RTL 的护城河不一定深，大模型和通用 coding agent 会持续进步，单纯“根据一句话生成一段 RTL”很可能会被基础模型能力吞掉。

真正有价值的 RTL writer，必须理解 spec、接口约束、项目代码风格、时序/功耗/面积意图，并且接入验证反馈、修复和 rerun。

相比 RTL writer，我更看重 RTL debugger。

debug 比生成更靠近真实工程。生成可以从空白开始，debug 必须面对现实：

读 log，看 waveform，解释 counterexample，定位 root cause，
判断这是 RTL 问题、testbench 问题、约束问题，还是 spec 理解问题。

然后给 patch，跑回归，确认影响范围，最后留下证据。

一个够深的 RTL debugger，价值不是指出“这里可能有 bug”，而是把 failure、waveform、RTL diff、testbench 约束、历史相似 case 和 rerun 结果连起来，最后告诉你：

这是设计 bug、约束 bug，还是 spec 误解。

它也不只是给一个 patch，而是给出“为什么是这个 root cause、为什么这个 patch 没有破坏其他路径、为什么 rerun 结果足够支撑评审”的证据链。

这件事一旦做深，就不再是“AI 会不会写代码”的问题，而是“AI 能不能进入工程反馈闭环”的问题。

Design review / code review agent 也很值得看。

很多风险不是仿真跑挂了才存在，而是在代码写出来的那一刻就已经埋下了：

reset/clock 有没有隐患？
protocol 有没有边界条件？
CDC/RDC 风险是不是提前暴露？
低功耗意图有没有被破坏？
这段代码是否容易验证、可综合、可维护？

这类 Agent 卡在“写完代码”和“验证爆炸”之间。

如果做得好，它可以把一部分风险提前拦在验证之前。

Spec-to-design intent agent 也重要，只是不一定容易产品化。

很多设计意图并不清楚地躺在文档里，它散落在 spec、接口约定、会议纪要、架构师脑子、历史项目代码和验证计划里。

Agent 如果能把这些模糊输入沉淀成 assumption、interface contract、corner case、约束和验证目标，它的位置可能比单纯写 RTL 更靠前。

Evidence compiler / signoff packet agent 听起来不性感，但很重要。

真实项目里，很多时候不是没有结果，而是结果散在 log、coverage report、counterexample、waveform、waiver、bug tracker、rerun 记录、修复说明和评审意见里。

一堆文件放在那里，不叫证据。能把它们组织成项目评审能看、工程师能复查、管理者敢签字的证据包，才叫证据。

这类 Agent 不一定对应传统 EDA 工具，但非常接近 Agentic EDA 的核心，

因为它回答的是：这个结果凭什么可信？

全新 Agent 机会对 startup 和本土 EDA 都有吸引力。

它不要求一开始就拥有完整传统工具链，但边界也很清楚：

只做生成，很容易被基础模型或通用 coding agent 吞掉；
越靠近公司内部架构和总控流程，越容易被 Design House 自己做；
越能接真实工具反馈、完成修复闭环、留下可复查证据，越可能形成专业 subagent。

RTL writer 看起来热闹，RTL debugger、design reviewer、evidence compiler 可能更值钱。

集成类 Agent：需求真，但独立公司要谨慎

还有一类看起来特别适合 Agent：SoC/IP/Flow 集成。

这个需求太真了。

IP 接入、interface 检查、clock/reset 一致性、constraint sanity check、版本依赖、脚本适配、flow 编排、smoke test、集成错误定位，这些工作又碎又烦，而且大量消耗工程时间。

所以很多人会觉得，集成类 Agent 可能是最大机会。

我反而觉得要谨慎。

越靠近 SoC/IP/Flow 集成，越靠近一个 IC Design House 的内部操作系统：

内部代码库、
IP 库、
脚本体系、
项目节奏、
权限边界、
数据安全、
责任归属，

全都在里面。

大中型设计公司大概率会自己搭总控 Agent，小型 Design House 确实可能采购这种能力。

但小客户确实有需求，客单价、续费能力、项目复杂度和服务成本之间，却未必天然支撑一个高天花板的独立产品公司。

所以集成类 Agent 不是没有机会，只是机会更可能换一种形态：

成为大中型 Design House 的内部平台，成为 EDA 公司或服务公司的交付加速器，或者在外部市场里做标准化检查、标准化诊断和标准化闭环，比如：

IP 接入一致性检查、
interface/clock/reset/constraint sanity check、
SoC 集成后的 smoke test 自动化、
配置和版本依赖检查、
约束冲突定位、
集成错误 root cause triage。

集成类 Agent 的需求很真，但越靠近客户内部操作系统，越容易被客户自己做；越能沉淀成标准检查、标准诊断、标准闭环，才越像可规模化的 EDA 产品。

国产替代、数据、服务，都是入口

说到这里，我们可以回到本土 EDA。

很多人会说，本土 EDA 有三个优势：国产替代、离客户近、有服务能力。

我同意这些都是优势。

但它们都是入口，不是护城河。

国产替代可以给本土 EDA 一个进门机会，这很重要。

没有这个入口，很多产品连被真实项目试用的机会都没有。

但进门以后，客户最终还是会问：

结果能不能交付？
证据能不能复查？
出了问题谁负责？

国产替代可以让客户愿意试你一次，它不能替你完成工程验收。

再说数据。

这几年大家喜欢讲“数据是护城河”。

放在 EDA 里，这句话要非常小心。

IC 设计数据高度敏感。

大多数客户不会允许外部公司把原始设计数据带走、汇总、训练。

就算你长期贴近客户现场，也不能简单推出“所以我天然有数据优势”。

真正能沉淀的，往往不是原始数据，而是现场形成的 failure taxonomy、debug pattern、工具反馈解释、evaluator、验收模板和证据组织方式。

换句话说：

在 EDA 里，数据不是躺在数据库里的金矿，而是嵌在工具反馈、工程决策和责任边界里的闭环。

最后说服务。

本土公司离客户近，响应快，愿意私有化部署，愿意适配非标准 flow，这确实是优势。

但如果每次都靠专家人肉兜底，Agent 只是更贵的咨询。

咨询可以赚钱，但咨询不等于产品护城河。第一次可以靠服务进去，第二次必须靠产品留下。

所谓产品化，不是把专家的经验写进一份 PPT，也不是把常见问题塞进知识库。

而是把客户现场反复出现的工程摩擦，沉淀成 workflow、failure taxonomy、tool API、evaluator、证据模板、Agent loop，以及权限、trace、rerun、report 这些机制。

只有这样，本土 EDA 的服务优势才可能从“人肉补洞”变成“产品复利”。

本土 EDA Agent 八问

所以，判断一个本土 EDA Agent 值不值得看，我建议问八个问题。

第一，它解决的是哪个高频、高痛点的具体工程闭环？

别只问“有没有 Agent”，先问它到底卡在哪个工程摩擦上。是 regression failure triage，coverage closure，counterexample explanation，CDC waiver，ECO 影响分析，还是系统级 bring-up？如果任务不高频、不痛、不靠近真实项目节奏，就很难形成持续价值。

第二，它是旧工具 Agent 化，还是过去没有工具形态的工程角色产品化？

这两类机会的打法不一样。旧工具 Agent 化，要看它能不能把工具反馈推向工程判断；新角色产品化，要看它是不是把过去靠工程师经验连接的空白变成了可复用流程。

第三，反馈从哪里来？

是真实 simulator、formal engine、debug tool、STA、DFT flow、emulation/prototype 系统给反馈，还是模型自己给自己打分？Agentic EDA 的“agentic”，不在于它会说话，而在于它行动以后能读到真实反馈。

第四，结果怎么验收？

有没有 root cause、rerun、coverage delta、counterexample explanation、ECO impact、evidence report 这些可复查东西？它能不能给出修复建议、完成 rerun、评估影响范围，而不是只把 log 总结一遍？

第五，服务经验怎么沉淀？

有没有 workflow、failure taxonomy、tool API、evaluator、证据模板和 Agent loop？如果每次都靠专家现场兜底，那它更像咨询；只有沉淀成机制，才像产品。

第六，它占住的是判断节点，还是只开放底层 API？

它掌握的是 workflow、evidence、result delivery，还是只是等别人调用的工具接口？这个位置会不会被客户内部总控 Agent 或三大家主流程平台吸收？这决定了价值留不留得住。

第七，它贴住的是哪条工程路径？

是先进节点、成熟工艺、特色工艺、先进封装、chiplet / 3DIC、本土 foundry、本土 IP，还是某类客户 flow？如果它不能说明自己贴住了哪条路径，就容易退回通用工具对标。