从 RTL 到 GDSII：数字芯片开发的 MCP 适配到了哪一步？

从 Apple、NVIDIA、Qualcomm、Intel 和 AMD 的芯片研发实践出发，审视 Cadence、Synopsys、Siemens、AMD Ross 与 OpenROAD 的 AI Agent 和 MCP 适配现状。AI 正在进入数字芯片开发全流程，但从工具调用走向可信的工程闭环，还有很长的路。

引言：AI 已经进入芯片设计，但它究竟走到了哪一步？

2025 年 6 月，路透社报道了 Apple 硬件技术高级副总裁 Johny Srouji 关于芯片研发的一次演讲。他谈到，Apple 设计自研芯片的一条重要经验，是必须使用最先进的电子设计自动化（Electronic Design Automation，EDA）工具。同时，他认为生成式 AI 有潜力让工程师在更短时间内完成更多芯片设计工作。

这番话很有代表性。

我们已经习惯了让 AI 编写软件、修复错误、运行测试，甚至自主操作开发环境。但在数字芯片设计领域，情况远比普通软件开发复杂。

一段能通过编译的 C++ 代码，至少可以比较直接地运行；一段语法正确的 SystemVerilog RTL，却远远不能说明硬件已经可用。它可能包含时序竞争、跨时钟域问题、不可综合结构、错误的复位行为，或者在综合、布局布线后暴露出无法接受的功耗、面积与时序问题。

更重要的是，数字芯片不是通过一个工具完成的。

工程师需要在架构模型、RTL、仿真、形式验证、综合、可测性设计（Design for Testability，DFT）、物理实现和签核工具之间持续切换。而这些工具又往往来自不同厂商，使用不同的数据格式、命令接口、许可证系统与计算资源。

过去，工程师依靠 Tcl、Python、Makefile、Shell 脚本和内部 Flow 管理系统，将这些步骤连接起来。

如今，一种新的技术路线正在出现：让 AI Agent 理解工程目标，通过模型上下文协议（Model Context Protocol，MCP）或其他工具接口调用 EDA 软件，并根据真实的验证与物理设计结果决定下一步操作。

这篇文章试图回答三个问题：

第一，Apple、NVIDIA、Qualcomm、Intel 和 AMD 这样的芯片公司，究竟在怎样的工作流中引入 AI？

第二，从 RTL 到 GDSII，主流 EDA 软件的 AI Agent 与 MCP 适配到底推进到了什么程度？

第三，AI 会不会真正改变数字芯片工程师的工作方式？如果会，改变的核心又是什么？

资料范围：本文以截至 2026 年 10 月 18 日可查证的公开资料为依据，包括厂商公告、产品文档、官方 GitHub 仓库及公开研究。文中明确区分“厂商宣称”“公开测试”“早期试用”“官方 MCP 接口”和“已验证的工程能力”。没有公开披露，不意味着相关公司内部不存在对应技术。

一、先看五家芯片公司：相似的开发流程，不同的 AI 切入点

Apple、NVIDIA、Qualcomm、Intel 和 AMD 都在开发复杂的数字芯片，但它们并不存在一套统一、公开且完全相同的内部 EDA 工作流。

从产品形态来看，Apple 更强调软硬件协同的 SoC；NVIDIA 需要将 GPU、互连、存储和大规模计算系统联合优化；Qualcomm 长期面对移动 SoC 的性能、功耗及复杂异构模块集成；Intel 同时具有自研芯片和晶圆代工生态；AMD 则覆盖 CPU、GPU、可编程逻辑和自适应计算平台。

这些差异决定了它们采用 AI 的重点并不完全相同。

Apple：AI 被视为设计生产力，但内部部署仍不透明

Apple Silicon 的竞争力并不仅仅来自某个 CPU 核心的设计，而是来自 CPU、GPU、神经网络加速单元、片上互连、缓存、存储系统与操作系统的协同。

这意味着芯片开发的很多约束，在编写 RTL 之前就已经出现。

例如，架构团队需要判断某个计算单元究竟应该增加多少并行度，缓存容量提升能否抵消面积与功耗成本，以及某项硬件特性是否能够被软件有效利用。

这些问题可以由仿真和建模工具辅助分析，但很难仅通过生成 RTL 来解决。

2025 年的 Reuters 报道证实，Apple 高管公开表达了利用生成式 AI 提升芯片设计效率的意向。

不过，目前没有足够的公开资料，可以确认 Apple 已将某个特定 MCP Server 或 Agent 框架部署到其内部 RTL、验证或物理实现流程中。

因此，Apple 是一个很好的起点：它代表了芯片公司对 AI 生产力的明确需求，但不应该被当作 MCP 工程落地的已证实案例。

NVIDIA：从训练领域模型，走向让 Agent 使用真实 EDA 工具

NVIDIA 是五家公司中，AI 与芯片设计结合路径最清晰的代表之一。

早在 2023 年，NVIDIA Research 就发表了 ChipNeMo。

这项研究没有试图让通用语言模型直接完成整颗芯片设计，而是针对芯片研发语料和工作任务进行领域适配，研究了内部工程知识问答、EDA 脚本生成、错误报告总结等应用。

它说明了一点：芯片研发中最先适合语言模型处理的，往往不是电路本身，而是围绕电路形成的大量工程知识与操作。

2026 年，NVIDIA 与 EDA 厂商的合作进一步深入。

Cadence 在 2 月推出 ChipStack AI Super Agent 时，将 NVIDIA 列为早期部署客户之一。6 月，Cadence 又公布了基于 NVIDIA 计算和安全运行时的自主验证方案，涉及 Xcelium 仿真与 Jasper 形式验证。

Cadence 在公告中提出显著缩短 RTL 验证周期的目标，但这些属于特定部署背景下的厂商披露，不能直接外推为任意芯片项目都能获得相同比例的加速。

另一方面，Siemens 于 2026 年 3 月的公告明确表示，NVIDIA 也在其芯片开发中使用 Siemens Fuse EDA 解决方案。

这使 NVIDIA 的角色相当特殊：它既是 EDA AI 能力的使用方，也在为这些 Agent 提供模型、算力和运行环境。

如果说 ChipNeMo 展示的是“让模型理解芯片设计知识”，那么 2026 年的 Agentic EDA 展示的就是下一步：让模型能够调用芯片设计工具，并接受工具返回结果的约束。

Qualcomm：进入 Agent 评估阶段，尚不能据此推断全面生产部署

Qualcomm 的一个典型挑战，是异构 SoC 中大量模块之间的集成与验证。

在复杂的移动平台中，CPU、GPU、DSP、AI 加速器、媒体模块、片上互连及电源管理相关逻辑存在大量交互。一个局部 RTL 修改，可能影响多个验证环境或功耗状态。

因此，Agent 能否理解验证失败、协调测试、追踪信号，以及快速完成回归，可能比单纯生成代码更有价值。

在 Cadence 2026 年 2 月公告中，Qualcomm 工程副总裁明确提到正在合作评估 ChipStack，且早期结果积极。

这里需要注意措辞。

“正在评估”意味着存在实际技术接触和初步反馈，但它不等于 Qualcomm 已将 ChipStack 或 MCP 部署到全部产品线，更不意味着其内部工作流已经实现无人值守的自动签核。

Qualcomm 的案例，代表的是领先芯片公司对 Agentic Verification 的积极验证，而不是已经公开证实的全流程 MCP 化。

Intel：一个很有价值的反例——并非所有先进自动化都需要 MCP

讨论 AI 和 MCP 时，很容易忽视芯片行业已经积累了数十年的自动化能力。

Intel 在 2025 年公开介绍了内部开发的 Cobra 3 静态 RTL 分析工具。

Cobra 的主要目标并不是生成设计，而是在流片前自动检查大型 SoC 中的结构性和安全相关问题，例如信号连接、调试访问控制和模块集成要求。

Intel 公布的一个测试案例涉及超过 3 亿门规模的测试芯片：针对 500 多个 RTL 模块实例的某项集成检查，传统人工审查需要数周，而 Cobra 3 将其缩短到约四分钟。

这个数字不能直接视为整个芯片验证流程的加速比，但它说明了一件很重要的事：

成熟的领域专用自动化工具，本身就可能比通用 AI Agent 更擅长完成某些任务。

Cobra 3 还能够向 CI/CD 流程提供通过或失败的结构化结果。这样的能力恰恰可能成为未来 Agent 的底层工具。

但截至本文调研时，没有证据表明 Cobra 3 本身就是 MCP Server。

Intel Foundry 另一方面也拥有 EDA Alliance 生态，推动商业 EDA 流程与制造工艺适配。不过，代工厂认证某款 EDA 工具，同样不能直接推断 Intel 自身内部使用了该工具的 MCP 接口。

Intel 提醒我们：MCP 应当建立在高质量自动化能力之上，而不是替代已有的确定性分析工具。

AMD：同时出现在商业 ASIC Agent 和官方 FPGA MCP 两条路径上

AMD 是五家公司中，公开资料最值得拆开分析的一家。

第一条路径来自 ASIC 设计与验证。

2026 年 7 月，Synopsys 公布了与 AMD、Microsoft 合作的 Agentic EDA 工作流，涵盖自动化验证调试、根因分析以及物理实现优化。

其中，早期测试报告了约 25%–40% 的调试周期缩短。但 Synopsys 官方公告对 AMD 的表述是正在积极评估，不能把测试结果直接解释为 AMD 全公司实际生产收益。

第二条路径则来自 FPGA 和自适应 SoC 开发工具。

2026 年 9 月，AMD 正式公开了 Ross Agentic AI Assistant 及其 GitHub 仓库。

与多数停留在发布会阶段的 EDA AI 宣传不同，Ross 已经提供了相当明确的工程接口：

面向 Vivado 的官方 MCP Server；
通过 MCP 执行 Tcl、管理工具会话和读取报告；
RTL 仿真、Lint、时序方法学检查及硬件调试 Skills；
面向 VS Code、Cursor、Claude Code、Codex CLI 等客户端的适配；
Windows 和 Linux 版本的 MCP Server 下载包。

AMD 官方下载页列出了 2026.9.1 版本的可执行文件，更新时间为 2026 年 9 月 29 日。与此同时，2026.1 版 Vitis 文档仍将 Vivado MCP 标注为 Early Access，并提示通过 AMD FAE 获取访问支持。

因此，比较严谨的结论是：AMD 已公开发布 Ross 及官方 Vivado MCP 的实现、文档和下载渠道，但具体版本、访问资格和可用功能仍需以相应发行渠道为准。

还有一个边界必须明确：Vivado 是 FPGA/自适应 SoC 工具，不是 AMD 高性能 CPU/GPU ASIC 设计与流片签核流程的公开 MCP 接口。

这两条技术路线都很重要，却不能混为一谈。

五家公司的公开进展对照

公司	可核实的 AI/自动化实践	公开的 MCP 证据	当前判断
Apple	明确表达利用生成式 AI 提升芯片设计效率的意向	未确认内部 MCP 部署	方向明确，工程细节不公开
NVIDIA	ChipNeMo；与 Cadence、Siemens 的 Agentic EDA 合作	合作方案中存在明确的 MCP 架构	AI 深度参与工具与研发协同
Qualcomm	参与 Cadence ChipStack 评估	未确认内部 MCP 部署	Agentic Verification 处于公开评估阶段
Intel	内部 Cobra 3 静态 RTL 分析；Foundry EDA 生态	未确认内部 MCP 部署	成熟领域自动化，MCP 情况不公开
AMD	与 Synopsys 合作评估 ASIC Agent；发布 Ross	Vivado 官方 MCP 已公开	FPGA 工具适配明确，ASIC 内部 MCP 不公开

这里已经可以得出第一个结论：

领先芯片公司对 AI 的采用速度，不能简单通过“有没有 MCP”来衡量。

MCP 解决的是 AI 与工具之间的标准化连接问题，而不是芯片设计自动化的全部问题。

二、数字芯片的真实开发链条，比“RTL → GDSII”复杂得多

要讨论 MCP 适配，首先需要知道它究竟要适配什么。

从较高层次看，一颗数字 ASIC 的开发通常经历以下过程：

图 1：RTL → GDSII 的九阶段流水线。柱高表示公开证据下的成熟度，不是厂商评分。

配套可视化：芯片剖面、valid/ready 时序与成熟度热力图在 EDA 可视化实验。

这是一幅经过简化的示意图。现实项目中，功能验证、DFT、低功耗验证、物理设计和系统建模往往大量并行，前后端之间也存在持续的反馈，并非严格的单向瀑布式流程。

但即使在这个简化版本里，仍然可以看出几个问题。

首先，每个阶段都拥有不同的“正确性”定义。

RTL 通过语法检查，不代表不存在锁存器或跨时钟域问题；仿真回归全部通过，不代表测试覆盖了所有错误；形式验证通过，也取决于所证明的属性、假设与约束是否完整。

到了后端，问题进一步变化。综合结果满足面积限制，不保证布局布线后仍然满足时序；典型工艺角下时序通过，不代表所有多模式多工艺角（Multi-Mode Multi-Corner，MMMC）条件下都能签核。

其次，前后端使用的工具与数据格式高度异构。

阶段	典型任务	常见工具或生态	关键产物
架构设计	性能建模、设计空间探索、规格制定	SystemC、gem5、内部建模平台	架构规格、性能模型
RTL 开发	模块设计、IP 集成、参数配置	Verilog / SystemVerilog、HLS	RTL、约束、接口定义
静态检查	Lint、CDC、RDC、低功耗检查	SpyGlass、Questa、Jasper 等相关工具	违规报告、检查证据
功能验证	仿真、UVM、SVA、覆盖率分析	VCS、Xcelium、Questa	日志、波形、覆盖率
调试与 Formal	根因定位、属性证明、等价性检查	Verdi、JasperGold、VC Formal	反例、证明结果、调试证据
综合与 DFT	逻辑映射、扫描链、ATPG	Design/Fusion Compiler、Genus、Tessent、Modus 等	网表、测试结构、约束
物理实现	Floorplan、CTS、P&R、ECO	Innovus、Fusion Compiler、Aprisa、OpenROAD	DEF、网表、布局布线数据库
签核	STA、SI、DRC、LVS、IR/EM	PrimeTime、Tempus、Calibre、Pegasus 等	时序、物理规则及可靠性报告
流片与硅后	交付、Bring-up、测试与失效分析	制造交付系统、ATE、硬件调试平台	签核数据、测试结果、硅后反馈

注：上表只列举代表性工具，不表示所有列出的产品能够互换，也不表示任何一家芯片公司实际使用了表中全部工具。

对软件工程师而言，编译器通常只是开发环境中的一个组件。对数字芯片工程师而言，EDA 工具及其流程本身却占据了研发资源、验证成本和最终交付质量的核心位置。

这正是 MCP 在芯片行业面临的特殊挑战。

它不能只回答“如何调用一条命令”，还必须解决：

怎样让 Agent 理解工具之间的依赖关系、识别真正的设计失败，并且不破坏工程中已经建立的正确性边界？

三、首先分清三件事：AI 功能、Agentic EDA 和 MCP

这三个概念经常在宣传材料里被放到一起，但从工程上看，差异非常大。

AI 功能：辅助某个特定任务

例如，EDA 软件利用机器学习预测时序风险，或者通过强化学习搜索更好的布局布线参数。

这类技术可以非常成熟，也可能取得显著 PPA（Power、Performance、Area）收益。

Synopsys 的 DSO.ai、Cadence 的 Cerebrus 都属于值得关注的先例。它们说明，EDA 使用 AI 并不是从大语言模型或 MCP 出现之后才开始的。

但传统 ML 优化器通常工作在预先定义的设计空间和目标函数内，未必需要理解自然语言，更不必一定使用 MCP。

Agentic EDA：让 AI 规划并执行多步骤工程任务

Agent 的核心特征不只是生成结果，而是能够：

理解当前状态，选择工具，执行操作，分析反馈，再决定下一步。

例如：

检查这次 RTL 回归失败的根因。如果是设计缺陷，给出最小修改方案；先运行相关单元测试，再启动受影响的回归集合。

这个任务可能涉及日志分析、波形追踪、源代码定位、代码修改、重新编译及仿真。

它已经不只是一次文本生成，而是一组具有依赖关系的工程动作。

MCP：把工具能力变成标准化、可发现的接口

模型上下文协议（Model Context Protocol，MCP）提供了一套连接 AI 应用与外部工具、资源的开放协议。

它允许 Agent 发现工具及其输入参数，并通过结构化请求执行操作。

但 MCP 本身既不是大语言模型，也不是新的综合器、仿真器或布局布线算法。

一个工具拥有 Tcl、Python 或 Shell 接口，并不意味着它已经原生支持 MCP。反过来，即使开发者使用几十行代码将 Tcl 命令封装成 MCP 工具，也不意味着它已经具备可靠的工程级 Agent 能力。

可以把三者的关系理解为：

图 2：Agentic EDA 的控制层。Agent 提出动作，MCP 负责接口，EDA 引擎给出真实结果，门禁决定能否进入下一步。

在这个结构里，Agent 可以提出下一步行动，但真实的设计状态与正确性证据必须来自专业工具。

这也是理解 2026 年各大 EDA 厂商产品进展的前提。

四、EDA 三巨头：AI 已经覆盖全流程，但 MCP 的开放程度并不相同

2026 年，Cadence、Synopsys 和 Siemens 都明显加快了 Agentic EDA 的产品化。

不过，三家公司的技术路径存在一个值得关注的差异：

它们都希望 Agent 可以跨多个设计工具完成任务，但对于如何向外部 Agent 开放这些工具能力，公开披露的程度并不一致。

Siemens：目前公开资料中最明确的跨流程 MCP 架构之一

2026 年 3 月，Siemens 发布了 Fuse EDA AI Agent。

这次发布的重要性不在于“EDA 软件增加了聊天窗口”，而是 Siemens 明确描述了一种基于 MCP 的工具编排架构。

按照官方披露，Fuse 具备以下能力：

使用 MCP 连接 EDA 工具，并允许第三方工具集成；
使用 Supervisor Agent 和 Worker Agent 进行分层规划；
结合检索增强生成（Retrieval-Augmented Generation，RAG）和 EDA 专用解析器理解工程数据；
将 Agent Skills 作为可复用的工程工作流程；
对接高性能计算集群、调度系统和受控的企业环境；
提供访问控制、审计记录及人工审批节点。

更重要的是，它涉及的不是一两个孤立软件，而是 Siemens EDA 的多个核心产品。

设计阶段	Siemens 代表工具	Fuse 宣称的 Agent 能力
架构与高层设计	Catapult	架构探索、高层设计与 RTL 开发辅助
功能验证	Questa One	RTL 编写、测试平台、验证规划、调试
仿真加速与原型验证	Veloce	硬件辅助验证流程编排
物理实现	Aprisa	布局布线、时序与功耗优化
单元库与器件模型	Solido	仿真、特征化与数据生成
物理签核	Calibre	DRC 违规分析及修复辅助
可测性设计	Tessent	DFT 相关工作流自动化

这里最有价值的并不是表格中的工具数量，而是架构关系。

在传统工作流中，工程师可能需要查看 Questa 的验证报告，修改 RTL，再手工触发综合或实现，最后回到验证工具确认修改没有引入新的功能问题。

Fuse 希望让 Agent 理解这些操作之间的依赖关系，在受控环境中完成跨工具任务。

但需要强调，Siemens 宣称 Fuse 可以通过 MCP 编排整个 EDA 产品体系，不等于每一个底层 EDA 产品都有可以独立下载的通用 MCP Server。

这两件事属于不同的接口开放层次。

从工程架构看，Siemens 正在构建的更接近一个面向大型芯片研发组织的 Agentic EDA Control Plane：它不一定替代现有工具，而是在工具之上增加统一的任务理解、执行和协调能力。

Synopsys：从成熟的 AI 优化器，向可调用的专业 Agent 演进

Synopsys 很早就开始将 AI 用于 EDA 优化。

以 DSO.ai 为代表的技术，主要解决设计空间探索和实现质量优化问题。

其特点是能够在明确的设计约束与目标下，寻找更有利的 PPA 配置。

这类系统的价值并不依赖大语言模型，也不需要 MCP。

而在新一代 Agentic AI 产品中，Synopsys 的技术方向开始发生变化。

2026 年 7 月，Synopsys 与 AMD、Microsoft 的合作公告展示了两个典型工作流：

一个围绕验证失败进行根因分析、自动调试和验证闭环；另一个调用 Fusion Compiler 等工具，执行实现质量优化和收敛任务。

这里体现的是从单点优化走向多步骤执行。

但更值得关注的 MCP 证据，其实来自验证调试工具 Verdi。

在 2026 年的官方技术文章 Using AI to Debug More Quickly & Accurately 中，Synopsys 明确说明：

Verdi Assistant 可以通过 MCP 与其他 AI 应用连接，MCP Client 可以向 Verdi 请求调试服务，Verdi 则作为 MCP Server 提供相应能力。

这意味着外部 Agent 有机会通过标准协议使用 Verdi 的专业调试能力，而不必完全依赖模拟鼠标操作或者自行分析原始波形。

这比简单地让语言模型阅读仿真日志前进了一步。

例如，工程师希望追踪某个信号的驱动来源时，Verdi 本身已经拥有设计层次、信号连接、波形和调试上下文。让 Agent 调用这类能力，比要求它从海量 RTL 文本中自行猜测信号传播路径更可靠。

不过，仍然需要划清产品边界。

Verdi 提供 MCP 调试服务，并不等于 VCS、PrimeTime、Fusion Compiler 或 Synopsys 的整个数字设计工具链，都已经以同样的方式公开了完整 MCP Server。

此外，Synopsys 旗下的 Ansys 工具生态也已经出现官方 PyAEDT-MCP，用于操作 Ansys Electronics Desktop 及相关电磁、多物理场设计流程。

这是一个真实的官方 MCP 适配方向，但其主要作用对象并非数字 ASIC 的 RTL 验证和逻辑签核，不应混进数字前后端的成熟度统计。

Cadence：Agent 产品进展迅速，但公开 MCP 接口仍需区别看待

如果只讨论 Agentic EDA 的产品覆盖范围，Cadence 在 2026 年的推进同样非常积极。

2 月，Cadence 发布了 ChipStack AI Super Agent，重点是数字前端设计与验证。

4 月，Cadence 又介绍了 AgentStack 以及面向不同设计领域的 Agent 产品，其中 InnoStack 面向数字实现与签核，ViraStack 面向模拟及定制设计。

到了 9 月，Cadence 进一步发布了 RTL Generation Agent。

这款新 Agent 的目标已经不仅是依据规格生成 RTL，还包括结合 EDA 工具反馈进行面积、功耗和性能优化。

Cadence 报告称，在早期测试中，与直接使用基础语言模型生成 RTL 相比，其方案平均实现了约 24% 的面积降低和 18% 的功耗降低。

但这个结果有两个边界。

首先，它的对照组是基础模型生成的 RTL，而不是经过高级工程师充分优化的完整商业设计。

其次，测试中的功能正确性和 PPA 结果取决于具体工作负载，不能将它直接解释为所有芯片项目都能获得同样的收益。

2026 年 6 月，Cadence 还将 ChipStack 描述为具有 Level-5 Autonomy 的自主虚拟设计工程师，并强调与 Codex、Claude Code 等工具的兼容性。

不过，这里的 Level-5 是厂商自己的产品能力表述，并非行业公认的芯片设计自主化等级标准。另据 Cadence 9 月公告，扩展后的 ChipStack 和 InnoStack 能力预计于 2026 年第四季度向部分 Early Access 客户开放；已经公布产品能力，不等于所有客户现在都能使用。

同样，兼容外部 AI 开发工具，并不自动等于 Cadence 已经公开发布完整、通用的 MCP Server API。

截至本次调研，我没有找到足以核实 Cadence 面向第三方公开提供完整数字 EDA 工具链 MCP Server 的官方接口文档。

这不是说 Cadence 不支持 MCP，更不能用来推断其私有客户环境中的技术实现。它只能说明，从目前能够核查的公开材料来看，Cadence 的 Agentic EDA 产品能力已经非常明确，但其对外 MCP 接口的具体开放范围尚不透明。

这是我认为讨论 AI 适配进度时非常重要的一项区别。

将三大 EDA 厂商放在一起看

厂商	已公开的 Agentic EDA 方向	明确可核实的 MCP 落点	证据边界
Siemens	Fuse 跨工具编排；Questa、Aprisa、Calibre、Tessent 等工作流	Fuse 明确采用 MCP 编排架构；Solido 工作流有具体 MCP 调用实例	不等于每个独立工具均公开通用接口
Synopsys	AgentEngineer、验证调试、实现优化、设计空间搜索	Verdi Assistant 可作为 MCP Server	已确认特定调试接口，不代表全线工具公开
Cadence	ChipStack、InnoStack、AgentStack；从 RTL 到签核	本次检索未确认公开的通用数字 EDA MCP Server 文档	Agent 能力明确，具体 MCP 对外开放程度不明

这张表实际上揭示了两个互相独立的维度。

一个维度是 Agent 能完成多少工程任务；另一个维度是外部开发者能够通过多大范围的标准接口访问这些任务。

前者决定产品的工程能力，后者决定生态的开放程度。

二者不能混成一项简单的“AI 适配分数”。

图 3：Agent 能力与 MCP 开放度是两个独立维度。位置为定性判断，不是厂商评分。

五、一个容易被忽略的变化：官方 MCP 已经进入 FPGA 和开源 ASIC 工具链

如果只关注 Cadence、Synopsys 和 Siemens，容易形成一种印象：EDA 的 Agent 能力最终都会被封装在昂贵的商业软件内部。

但 2026 年的公开进展，实际上比这更加多样化。

1. AMD Ross：官方开放的 Vivado 工具调用层

AMD Ross 是一个非常值得关注的案例，因为它提供了较为完整的公开实现和工具参考。

在 Vivado MCP Tool Reference 中，可以看到真实的 MCP 工具定义。

例如：

MCP 工具	主要用途
`vivado_start`	创建 Vivado 会话
`vivado_connect`	连接已有会话
`vivado_execute`	执行 Vivado Tcl 命令
`vivado_status`	查看工具状态与运行进度
`vivado_log_messages`	提取结构化日志信息
`vivado_history`	查询执行历史
`vivado_lsf`	操作 LSF 集群中的 Vivado 会话
`vivado_ssh`	管理远程 Vivado 会话

AMD 还将文档检索拆成了另一个独立服务：amd-doc-search MCP Server。

这种架构设计很有意思。

一部分 MCP 工具负责“查询知识”，另一部分负责“控制设计环境”。Agent 可以先查找 AMD 文档，再连接真实 Vivado 会话执行操作。

而真正需要综合或实现时，底层执行者仍然是 Vivado。

更重要的是，AMD 已经处理了一个经常被简单 Demo 忽略的问题：EDA 任务通常不是几秒钟就能完成的同步调用。

Ross 的 Vivado MCP 文档明确涉及长时间运行任务、状态轮询、日志读取、远程会话，以及 LSF 集群作业管理。

这意味着它的设计目标不只是让 Agent 成功执行一条 Tcl 命令，而是开始考虑持续运行的真实工程环境。

当然，这并不代表所有风险都已经解决。vivado_execute 这样的工具本身具有很强的操作能力，如果不设置访问控制和执行边界，Agent 同样可能修改约束、覆盖设计数据或错误地操作工具会话。

官方 MCP 只是提供了连接方式，生产级可信性仍然取决于权限、工作流与验证机制。

2. OpenROAD-MCP：开源 ASIC 物理设计也有了原生生态中的适配项目

相比 FPGA，开源 ASIC 物理设计工具的 MCP 进展同样值得关注。

目前，The OpenROAD Project 官方 GitHub 组织下已经存在 OpenROAD-MCP 仓库。

该项目提供 MCP Server，可以连接 OpenROAD 及 OpenROAD-flow-scripts（ORFS）。

公开功能包括交互式 OpenROAD 会话管理、执行命令、查询运行历史与性能指标，以及读取物理设计报告图片。

其中两个工具的设计很有代表性：

interactive_openroad_query 主要用于查询，interactive_openroad_exec 则用于执行可能修改设计状态的操作。

这种将查询与修改操作分开的接口设计，比直接向 Agent 暴露一个不受限制的通用命令入口，更适合进一步加入权限和审计规则。

它也说明了一个趋势：

MCP 不一定需要改变 EDA 软件的核心算法，就能显著改善 AI 与既有设计工具之间的交互方式。

OpenROAD 仍然负责具体的综合后物理设计、时序分析和优化；MCP 负责让 Agent 可以使用这些能力。

不过，OpenROAD-MCP 是建立在独立开源 MCP 服务层上的适配项目，并不能因此认定 OpenROAD 的所有核心功能都已经具有同等稳定的标准化 AI 接口。

另外，开源 PDK 和参考设计上的成功，也不能直接外推到先进制程、专有工艺库及商业流片签核环境。

3. MCP4EDA：学术界已经开始研究真正的跨工具闭环

2025 年 7 月发表的预印本 MCP4EDA，研究了如何用 MCP 将 Yosys、Icarus Verilog、OpenLane、GTKWave 和 KLayout 连接起来。

它的关注点不是单个 EDA 工具，而是整个 RTL-to-GDSII 流程。

其中一个很有价值的思路，是将后端实际结果反馈给前端综合优化。

传统综合阶段作出的优化决定，不一定能够准确反映最终布线后的时序与面积。

如果 Agent 能读取后端报告，再据此调整综合策略，就有机会建立跨阶段优化闭环。

MCP4EDA 的作者报告了若干测试设计上的时序和面积改善，但这些属于研究论文中的特定实验结论，不应视为已在商业先进制程中独立证实的收益。

此外，该项目使用的 OpenLane 方案已经不是今天新建开源 ASIC 项目的唯一首选。OpenLane 后续演进出的 LibreLane 更强调可复现的流程配置、状态快照和模块化扩展。

如果今天重新设计类似实验，我更倾向于以 OpenROAD、ORFS、LibreLane 和固定版本的开放工艺库作为基础。

4. 社区适配仍然有价值，但其价值不在于 MCP 工具数量

除此之外，GitHub 上已经出现了多个不同方向的 EDA MCP 项目。

例如，社区项目 visualizer-mcp 尝试通过 Questa Visualizer 的命令通道控制波形与仿真会话；mcp-cocotb 则尝试将 Python 硬件验证环境封装为 MCP 工具。

这些项目证明，EDA 工具原有的 Tcl、Python 和命令行自动化体系，确实能够成为 MCP 适配的基础。

但其中最有意思的一点，来自 visualizer-mcp 作者自己的说明：对于非常简单的操作，让 LLM 逐次调用工具可能比直接运行现有脚本更慢，也更消耗 Token。

我认为这是一个值得认真对待的提醒。

并不是所有能够封装成 MCP 的 EDA 操作，都值得交给 Agent 执行。

当一个确定性脚本已经足够简单、稳定、可复现时，再增加一次模型推理未必能创造额外价值。

Agent 最适合的场景，应该是需要跨越多个工具、分析不确定反馈、进行选择和迭代的工作，而不是机械替代所有 Tcl 脚本。

截至 2026 年 10 月的公开 MCP 项目概览

项目	类型	MCP 证据	适用范围
Siemens Fuse	商业 EDA 企业级平台	官方明确披露 MCP 架构	跨工具、跨设计阶段编排
Synopsys Verdi Assistant	商业 EDA 专业工具	官方明确披露 MCP Server	验证与调试
AMD Ross	官方 FPGA/SoC 开发工具生态	官方 Server、文档、发行包	Vivado、Vitis 相关工作流
OpenROAD-MCP	开源 EDA 项目生态	开源 MCP Server	ASIC 物理设计
MCP4EDA	学术研究原型	研究实现与代码	开源 RTL-to-GDSII
PyAEDT-MCP	官方开源工具适配	开源 MCP Server	电磁、多物理场等相关流程

这张表还有一个重要信息：

“官方 MCP”已经不是未来概念，但“覆盖数字 ASIC 全流程、跨厂商、可复现且达到商业签核要求的统一 MCP 工作流”，仍然没有被这些公开案例充分证明。

这两句话可以同时成立。

六、截至目前，各个开发阶段究竟成熟到了什么程度？

如果把目光从厂商产品名称重新移回数字芯片研发工作本身，会发现 AI Agent 的成熟程度其实呈现明显的不均衡。

工作阶段	已有 AI / Agent 能力	公开 MCP 适配情况	我的判断
架构建模与规格制定	文档理解、脚本生成、设计空间探索	缺少可核实的通用跨厂商接口	更适合作为辅助决策
RTL 开发	RTL 生成、改写、Lint、初步 PPA 优化	AMD Ross 等已有工具入口；商业 ASIC 更多通过自有 Agent 产品	正在快速推进
CDC/RDC 与静态检查	违规分类、根因定位、修复建议	可通过专用 Agent 或工具封装调用	适合建立受控自动修复循环
功能验证	测试规划、回归编排、失败分类	Verdi 官方 MCP、Siemens Fuse、开源验证适配	近期价值最明确的方向之一
Formal 与覆盖率收敛	属性分析、反例解释、验证闭环	厂商 Agent 产品较多，外部通用 MCP 覆盖尚不透明	必须依靠专业验证引擎
仿真加速与 Emulation	任务管理、失败定位、测试组织	厂商内部编排正在推进	算力、许可和运行时间成为关键
综合与 PPA 优化	设计空间搜索、约束调优	商业 Agent 强；OpenROAD/AMD 等有可调用接口	优化能力成熟，跨工具闭环仍在发展
物理实现与 ECO	Floorplan、P&R、时序收敛	Siemens Fuse、OpenROAD-MCP 等已有证据	高价值，但执行代价高
DFT 与物理签核	报告分析、检查违规、修复辅助	商业工作流已有 Agent 集成，公开细粒度 MCP 接口有限	不能混淆辅助优化与最终签核
硅后调试	日志分析、硬件状态读取、测试编排	AMD Ross 已覆盖部分 FPGA 硬件调试场景	ASIC 硅后统一 MCP 仍缺乏公开证据

图 4：GDSII 剖面。从硅衬底、晶体管层到 M1–M6 与钝化层。层数为示意，不对应具体工艺节点。

从这张表中，可以看到一个很明显的结构。

AI Agent 最容易形成工程价值的地方，往往不是最容易生成文本的地方，而是原本存在大量重复分析、工具切换和迭代决策的地方。

例如，RTL 代码生成已经受到大量关注，但大型 SoC 的验证工作往往涉及庞大的回归测试、复杂的测试平台以及多级调试。

即使 AI 能迅速生成一个模块，工程师仍然需要验证它与规格一致、符合系统约束，而且不会破坏已有设计。

因此，我更关注 Agent 是否能减少真正完成验证收敛的时间，而不仅是缩短编写 RTL 的时间。

同样，对于物理设计，AI 的目标也不应该停留在自动执行 place、route 等命令。

真正有价值的，是让 Agent 理解时序、拥塞、功耗、面积和实现代价之间的关系，并在合理的搜索预算内完成优化。

这已经接近一个带有工程约束的决策问题，而非简单的代码生成问题。

七、比 MCP 接入更重要的，是 Agent 能否可靠完成工程任务

2026 年 10 月 14 日，NVIDIA 发布了一篇很值得细读的技术文章：

Optimizing Agent Reliability and Tool Calling Efficiency for Chip Design Using NVIDIA NeMo Gym

这项工作与 Siemens Fuse EDA AI Agent 有关，具体研究的是 Solido Characterization Suite 的自动化工作流。

它不是在生成数字 RTL，而是在根据晶体管模型和工艺条件执行标准单元特征化（Standard-Cell Characterization），生成用于后续时序与功耗分析的 Liberty .lib 文件。

这类任务非常适合说明 Agentic EDA 的难点。

为什么标准单元特征化适合 Agent？

标准单元库的生成需要考虑不同工艺、电压与温度（Process、Voltage、Temperature，PVT）组合。

在真实流程中，工程师需要配置工具、执行大量 SPICE 仿真、管理分布式作业、分析异常结果，最后生成并检查库文件。

这不是一次性的简单命令，而是一条较长的工程流程。

更麻烦的是，其中某个配置参数错误，工具并不一定会直接退出。

它可能依然生成看起来合法的 Liberty 文件，但其中缺少部分工作条件，或者某些时序、功耗数据并不正确。

如果 Agent 只检查命令是否成功退出，就可能把错误结果当作成功交付。

一个值得仔细理解的测试结果

NVIDIA 和 Siemens 使用 NeMo Gym 对这套 Agent 工作流进行评估和优化。

研究采用开放的 GF180MCU 工艺库作为基础，完整基准涉及 229 个标准单元和 36 种 PVT 条件。

但有一个容易被忽略的细节：用于迭代优化的单次 Agent 测试，并没有对全部 229 个单元展开完整执行，而是选取了两个单元、覆盖 36 种 PVT 条件。

研究团队进行了约 25 次 Rollout，并保持模型和 Agent Harness 不变，主要调整 Agent Skills 和 MCP 工具描述。

公布的结果如下：

指标	优化前	优化后
综合验证评分	约 55%	约 95%
Agent 执行轮次	155	53
平均输出 Token	约 81,000	约 29,000

这里的 95% 是特定基准下的综合验证评分，不是“95% 的芯片设计都已经能够自动完成”，也不是完整标准单元库已经达到 95% 的量产签核成功率。

更不能把这组数字直接理解为修改 MCP Schema 就能使所有 EDA Agent 的能力提升 40 个百分点。

实际优化同时涉及 Skills、工具说明、调用策略和验证反馈。

但即便如此，这仍然是目前非常有价值的一项公开工程研究。

因为它说明：在基础模型不变的情况下，Agent 如何理解和使用 EDA 工具，也会显著影响最终结果。

最值得借鉴的不是分数，而是验证方式

这项工作构建了专用验证器，检查生成的 Liberty 文件是否满足以下条件：

Coverage：所需单元和工艺角是否齐全。
Validity：文件结构是否有效，能否被工具使用。
Relative Validation：是否比参考结果引入了额外错误。
Accuracy：时序和功耗数据是否处于允许误差内。
Integrity：是否真正完成了计算，而不是复制、截断或重用已有数据。

其中部分条件被设置为硬门槛，只要不满足，最终评分就归零。

这与通常评价软件 Agent 的方式存在明显区别。

一个软件 Agent 可能因为单元测试通过而获得高分。

但是在 EDA 中，测试本身的覆盖范围、约束设置和最终产物的物理含义同样需要接受检查。

我认为，这项研究指向了 Agentic EDA 下一阶段真正重要的方向：

从追求“Agent 能完成多少工具调用”，转向追求“Agent 能交付多少经过独立验证的工程结果”。

对于芯片开发，这个变化比增加更多自然语言指令重要得多。

八、我的几个判断：MCP 会如何改变数字芯片开发？

经过前面的调查，我认为有六个趋势值得关注。

1. 验证和调试，可能比 RTL 生成更早实现规模化收益

现在最容易吸引注意力的，是从自然语言生成 Verilog。

但对于复杂 ASIC 项目，RTL 生成往往只是前端设计的一部分。

真正耗费大量时间的，是让设计持续满足规格、系统集成要求和各种验证条件。

一个普通模块的 RTL 可能很快就能完成初稿，接下来却需要花费大量时间处理：

仿真失败、约束错误、跨时钟域问题、功能覆盖率、形式验证反例，以及与其他模块集成后出现的新问题。

这些任务的共同特点是：

反馈来自工具，目标相对明确，而且需要反复分析。

恰好适合使用 Agent 对工程流程进行编排。

这也是为什么 Cadence ChipStack、Synopsys Verdi Assistant、Siemens Questa One 等产品，都把相当多的注意力投入到验证和调试上。

相比之下，架构设计中的很多问题涉及系统级取舍，往往不存在唯一的正确答案。

因此，我倾向于认为：

近期最先改变数字芯片工程师日常工作的，很可能不是自动 RTL 生成，而是自动化验证、调试和问题收敛。

这并不意味着 RTL 生成不重要，而是它的真正价值必须通过后续验证结果来衡量。

2. MCP 会降低工具接入成本，但不会让 EDA 核心技术变得廉价

MCP 的一个明显价值，是让工具具有相对统一的发现、调用和返回机制。

但这不意味着未来所有 EDA 工具都会因为采用 MCP 而变得可以互相替代。

例如，两个工具都能够通过 MCP 返回时序报告，但它们使用的时序分析模型、约束解释、寄生参数、增量分析机制和签核能力仍然可能不同。

同样，一个 Agent 可以同时连接开源物理设计工具和商业 EDA 工具，不代表两套工具具有相同的工艺支持和结果可信度。

MCP 统一的是调用方式，而不是计算能力、物理模型和工程语义。

这也是我不认为 MCP 会直接削弱头部 EDA 厂商核心壁垒的原因。

相反，随着 AI Agent 更容易操作这些软件，专业 EDA 引擎的准确性和性能可能变得更加重要。

因为 Agent 可以提出许多候选修改，但判断修改是否真正有效，最终仍然依赖能够准确反映设计约束的分析工具。

3. 最值得竞争的，可能是跨工具的工程控制层

如果把芯片设计流程分为两层，会发现未来可能形成一个很有意思的竞争结构。

底层是专业的 EDA 计算引擎：

仿真、形式验证、逻辑综合、物理实现、静态时序分析、功耗分析和物理规则检查。

上层则是工程控制层：

管理设计状态、识别问题、规划任务、分配资源、组织工具调用、保存证据，以及决定何时需要人工介入。

过去，第二层往往由芯片公司内部开发的大量脚本、流程管理系统和工程规范承担。

今天，EDA 厂商开始通过 AgentStack、Fuse、AgentEngineer 等方案，将其中一部分工作纳入自己的 Agent 平台。

与此同时，AMD Ross、OpenROAD-MCP 也展示了另一条路径：让开发者通过更开放的协议，将自己的 Agent 连接到真实设计工具。

因此，未来可能同时存在两种工程模式。

一种是EDA 厂商主导的一体化 Agent 平台，优先保证与自家工具的深度集成。

另一种是芯片设计公司自行构建的跨厂商 Agent 控制层，将商业 EDA、内部工具和开源组件组合起来。

两者不一定互相排斥。

事实上，大型芯片公司完全可能同时使用厂商提供的专用 Agent，并通过自己的工程平台管理更高层次的任务。

真正值得关注的问题，可能不是谁拥有最多 MCP Server，而是谁能够为一整条芯片开发流程提供可靠的状态管理、任务编排和可追溯证据。

4. 跨越前后端的信息壁垒，可能比自动化单个阶段更有价值

目前许多 EDA 优化方案仍然聚焦在特定阶段。

例如，综合优化器负责改善综合质量；布局布线工具负责物理实现；静态时序分析工具负责识别时序路径问题。

但这些阶段实际上紧密相关。

一项 RTL 层面的结构优化，在综合报告中看起来可能非常理想，却可能由于后端互连、拥塞或时钟树成本，失去预期收益。

反过来，后端工具发现的某些问题，也可能通过修改微架构、流水线或模块边界得到更有效的解决。

这说明，最有价值的 Agent 不一定是某个阶段最强的 Agent，而可能是能够有效传递跨阶段反馈的 Agent。

MCP4EDA 尝试利用后端报告指导综合优化，就是这一思路的早期体现。

如果未来商业 EDA 平台也能够在严格约束下打通 RTL、验证、综合和物理设计数据，就有机会让优化策略更早理解最终实现成本。

但这也会引入新的风险。

如果 Agent 为了改善时序而擅自调整时钟约束，可能获得漂亮的报告，却没有真正改善设计。

如果它为了提高覆盖率而修改测试条件，可能让验证结果变好看，却降低验证有效性。

因此，跨阶段自动化必须有一个底线：

Agent 可以探索设计空间，但不能通过偷偷改变问题定义来宣布成功。

5. Agent 的评估指标，会从执行速度转向有效工程收益

今天很多产品喜欢使用诸如“生产力提升数倍”“验证速度提升几十倍”这样的指标。

这些数字可能来自真实测试，但如果缺少上下文，就很难进行横向比较。

对于芯片开发而言，更合理的指标应当考虑：

完成一次有效验证或实现收敛所需的时间；
实际消耗的计算资源和 EDA License Hours；
最终结果满足约束的比例；
人工复核与返工成本；
是否引入新的验证遗漏；
结果能否在相同设计和工具环境中复现。

也就是说，真正应当衡量的是：

单位工程成本内，Agent 能交付多少经过验证且可复现的有效改进。

2026 年的一项预印本研究 FluxBench，已经开始从 Agent 架构、端到端 EDA 任务及 Token ROI 等角度比较不同方案。

其结果显示，即使基础模型相同，不同 Agent 系统在特定 EDA 任务上的表现也可能出现很大差异。

这些实验结果仍需要结合具体基准和研究条件理解，但其研究方向值得重视。

对于芯片开发而言，模型能力只是整个系统的一部分。

工具接口、执行环境、工作流设计、验证器和计算资源管理，同样影响实际结果。

6. 真正可靠的 EDA Agent，必须具有明确的权限边界

芯片工程中的风险，不只是 AI 可能生成错误代码。

它还可能操作错误的设计版本、覆盖重要文件、使用不正确的工艺库，或者在未经批准的情况下修改约束和签核配置。

在先进制程项目中，还必须考虑 PDK（Process Design Kit，工艺设计套件）、第三方 IP、工具许可证以及设计数据的保密要求。

这也是为什么 Siemens 等厂商特别强调私有化部署、受控计算环境、访问管理与审计能力。

我认为，一个面向真实芯片开发的 Agent 系统至少需要区分三类权限。

第一类是只读分析：阅读 RTL、报告、波形和工具状态。

第二类是受控执行：在指定工程副本上运行仿真、综合、形式验证和物理设计任务。

第三类是高风险修改：改变约束、修改签核配置、批准 Waiver、覆盖基准结果，以及触发最终交付。

前两类可以逐步提高自主化程度。

第三类则应受到更加严格的人工审批和版本管理约束。

原因非常简单：

芯片设计允许工具自动寻找答案，但不能允许工具自行降低答案必须满足的标准。

九、如果今天要设计一套数字芯片 MCP 工作流，我会怎么做？

在调查了这些产品之后，我反而不认为最合理的方案是立即为所有 EDA 软件编写一个 MCP Server。

更适合工程实践的路线，是先构建一个范围有限、可以独立验证的闭环。

例如，选择一个相对明确的 RTL 验证任务：

分析某个模块的回归失败，定位可能的设计问题，生成修改建议，并在独立工作区中完成重新验证。

在这个场景中，Agent 并不需要直接接管整个芯片项目。

它只需要获得一些明确的能力。

第一层：将工具能力拆成有语义的操作

相比于只提供一个可以执行任意 Shell 命令的接口，我更倾向于设计具有工程含义的工具。

例如：

建议的 MCP 工具	工程含义
`get_design_context`	读取指定设计版本、模块和约束
`submit_verification_run`	提交受控验证任务
`get_run_status`	查询仿真或验证进度
`inspect_failures`	返回结构化的错误、反例与相关日志
`propose_rtl_patch`	生成修改建议，不直接覆盖基准
`run_regression`	执行指定回归集合
`check_equivalence`	调用正式的等价性验证
`collect_evidence`	汇总工具版本、命令、输入和输出

这些是建议性的接口设计，不是某个 EDA 厂商已经公开提供的同名 MCP API。

它们的意义在于让 Agent 以工程任务为单位操作，而不是把所有复杂度都留给自由形式的 Tcl 或 Shell 命令。

第二层：每次执行都必须绑定设计状态

一个合理的验证任务，不应该只包含“运行测试”这句话。

它还应该明确设计版本、测试集合、随机种子和执行预算。

例如，概念性的工具请求可以表示为：

{
  "tool": "submit_verification_run",
  "arguments": {
    "design_revision": "abc1234",
    "test_suite": "reset_regression",
    "seed": 20261018,
    "flow_config": "baseline-v3",
    "max_walltime_seconds": 3600
  }
}

真实系统中的执行服务还应该记录工具版本、相关工艺库或模型版本、输入文件摘要、许可证消耗和最终产物位置。

这样的记录并不是为了方便 Agent 阅读，而是为了确保工程师能够追溯结果究竟如何产生。

第三层：用独立验证器判断结果，而不是相信 Agent 自己的总结

对于功能验证任务，最终结果应来自真实仿真器或形式验证引擎。

对于 RTL 改写任务，需要检查功能等价性、回归结果以及必要的综合约束。

对于 PPA 优化任务，需要使用固定的评估条件，并区分综合估算与物理实现结果。

对于签核相关任务，更需要核查实际使用的工艺角、库文件、约束、违规报告和 Waiver 状态。

一个完整的工程循环应该类似于：

图 5：受控验证闭环。Agent 只能提出候选方案，是否正确由真实工具与独立验证器判断。

注意，这里的 Agent 并不能直接宣布自己的修改成功。

它只能提出候选方案，随后由真实工具和既定验证条件判断结果。

在我看来，这是把 AI Agent 从一个方便的开发助手，提升为可信工程基础设施的必要条件。

第四层：有限预算比无限自主更重要

EDA 作业的实际成本不只是 Token。

一次完整的综合或布局布线，可能消耗大量计算资源，甚至占用稀缺的商业工具许可证。

因此，一个生产级 Agent 必须具有预算意识。

比如，规定最多执行多少次候选优化、最多使用多少核心小时、允许占用多少许可证，以及当结果没有改善时何时停止搜索。

在已经成熟的固定流程中，普通脚本可能仍然比 Agent 更合适。

只有当任务需要根据反馈动态选择下一步操作时，才值得引入额外的模型推理。

这也意味着，我们不应该追求“让所有 EDA 命令都变成 AI 工具”。

真正应该追求的是：

让需要工程判断的复杂工作流具备可靠的自动分析和执行能力。

十、未来一两年，数字芯片开发可能会发生什么变化？

基于截至目前的公开进展，我认为有三个方向值得持续观察。

首先，越来越多的 EDA 工具会提供 Agent 可以直接调用的结构化接口。

AMD Ross 和 OpenROAD-MCP 已经展示了这种路线的可行性。商业厂商可能继续通过自己的 Agent 平台开放工具能力，但开放范围、权限模型和商业模式不一定相同。

其次，Agent 将逐渐从单工具助手演变为跨工具工作流的执行者。

Siemens Fuse、Synopsys AgentEngineer 和 Cadence AgentStack 所指向的，都是让软件不再局限于回答“某条命令怎么使用”，而是理解一个更高层次的工程任务，并协调不同工具完成它。

但这种演变很可能是逐步发生的。

从自动分析一份验证失败报告，到能够在多种工具之间可靠完成设计收敛，是完全不同的工程难度。

最后，芯片开发中的 AI 竞争，会越来越强调可验证性和工程上下文，而不仅是模型的通用推理能力。

NVIDIA 与 Siemens 在标准单元特征化工作流上的研究已经说明，即使不更换基础模型，仅改善 Agent Skills、MCP 工具描述和验证机制，也有机会显著提高特定任务的可靠性。

对于 EDA，这种进步尤其重要。

因为芯片工程师需要的不是一个能够流畅解释错误的聊天机器人，而是一个能够准确识别失败、可靠执行实验、保留证据，并且知道什么时候不能擅自继续操作的工程助手。

结语：AI 不会绕过 EDA，而是会重新组织人与 EDA 的关系

回顾数字芯片开发的自动化历史，可以发现每一轮技术进步，都在尝试将某些原本需要工程师手工完成的工作变成可复用的计算过程。

EDA 工具把电路设计中的大量分析与实现任务自动化。

Tcl、Python 和内部流程平台，把工具之间的操作自动化。

机器学习优化器，让部分设计空间探索具备了数据驱动能力。

现在，AI Agent 与 MCP 开始尝试解决另一个问题：

能否让系统理解工程目标，并在多个专业工具之间自主组织工作？

截至 2026 年 10 月，这个问题已经不再只是概念验证。

Siemens Fuse 公开了跨 EDA 工具的 MCP 编排架构；Synopsys Verdi 已明确将专业调试能力作为 MCP 服务提供；AMD Ross 发布了能够连接 Vivado 的官方 MCP Server；OpenROAD-MCP 则让开放 ASIC 物理设计流程拥有了更加直接的 Agent 接口。

Cadence 等厂商也在快速扩展自主化设计与验证产品。

但如果把标准提高到“可以可靠、跨厂商、无人值守地完成复杂 ASIC 的整个前后端开发，并独立负责最终签核”，现有公开证据显然还不充分。

这并不令人意外。

因为芯片设计的难点从来不只是运行多少条命令，而是在庞大的设计空间、复杂的工具依赖和严格的物理约束下，持续获得可以信任的结果。

在我看来，MCP 的真正价值，不是让 AI 学会操作 EDA 软件。

而是让它有机会成为现有芯片研发体系中，一个标准化、可审计、可验证的参与者。

未来值得期待的数字芯片工作流，也许并不是工程师告诉 AI：

帮我把这颗芯片设计出来。

而是工程师定义目标、约束、验证方法和资源预算，Agent 负责组织大量受控实验，EDA 引擎负责给出真实结果，最终由人和工程门禁决定哪些结果可以进入下一阶段。

从会调用工具，到能够对工程结果负责。

我认为，这才是 Agentic EDA 真正需要跨越的距离。

参考资料与延伸阅读

以下资料优先选择厂商官方文档、公开技术文章和项目原始仓库。产品公告中的性能数字是相应厂商或研究团队披露的结果，不代表已经完成独立、跨平台复现。