Synopsys 这次没有再给行业看一条只能站在展台边围观的 demo。

7 月 27 日，Synopsys 在 DAC 2026 期间公布两条 autonomous EDA workflow：一条处理 debug closure，另一条处理 implementation and closure。客户可以通过 Synopsys 申请在 Microsoft Discovery 上评估，AMD 正在评估这些工作流能否用于下一代产品开发。

公告里最扎眼的是 25% – 40%。Synopsys 称，debug closure 的早期评估把 cycle time 缩短了 25% – 40%，可省下数周工程时间。

这个数字很诱人。更值得盯住的其实是评估入口（evaluation access）。过去半年，agentic EDA 已经不缺 " 会写 RTL、会读 report、会调工具 " 的演示。行业现在缺的是另一种东西：把 agent 放进真实研发环境，让客户用自己的数据、流程、工具版本和验收标准来测。

这次合作把 EDA 厂商、头部芯片客户和云端 R&D 平台放进了同一个评估入口。生产部署还远，证据链已经开始搭了。

两条工作流，切进最消耗工程时间的环节

第一条是 debug closure。

芯片验证里的 debug 很少有 " 报错指向某一行，改完就结束 " 这种好事。工程师往往要把 specification、RTL、testbench、日志、断言、coverage 和波形摊在一起，沿着信号传播、时序关系和模块层级找根因。问题可能出在设计，也可能藏在验证环境、配置或规格理解里。修完以后还要跑 regression，确认旧用例没有被破坏。

Synopsys 的方案让 Microsoft Discovery 负责编排，把领域 agent 和任务 agent 组织起来，识别设计失败、执行 debug，并推进根因分析与问题关闭。

25% – 40% 就来自这条工作流的早期评估。公开新闻稿没有给出样本数、设计规模、bug 类型、基线定义、工具配置或计算方法。它只能代表 Synopsys 目前披露的厂商结果，不能外推成所有团队都能拿到的固定收益。

第二条是 implementation and closure。

这条工作流在 Azure 上调用 Synopsys implementation agents 和 Fusion Compiler，持续做实现阶段的 QoR 调优与收敛。QoR 很难用一个数字讲清。时序、功耗、面积、拥塞、运行时间和可制造性彼此牵制。一个动作把 timing 拉回来，可能同时增加功耗或布线压力；早期看起来漂亮的结果，到了 signoff 也可能要还账。

Synopsys 对这条线只说初步结果显示 QoR 改善，没有披露指标和幅度。这里不能替厂商补数字。implementation closure 高度依赖 PDK、IP、约束、工具版本、数据库状态和企业脚本，换一个 design，适配工作可能重新来一遍。

两条工作流的共同点很清楚：任务周期长，上下文很重，每一步都要读回 EDA 工具的反馈。它们比单次生成代码更接近工程现场，也更容易暴露 agent 的短板。

Agent 的任务边界，已经压到 closure

今年 3 月，Synopsys 展示过一条 L4 多 agent 设计与验证工作流。从自然语言或形式化规格出发，系统生成 RTL，运行 Lint，生成单元级 testbench，再调用 EDA 工具做迭代验证。那条线主要覆盖从规格到 RTL（specification-to-RTL）。

7 月的两条新工作流继续往后走。

一条进入验证失败后的根因分析和问题关闭；另一条进入物理实现的 QoR 调优与收敛。前者要在日志、波形、设计状态和历史尝试之间保持连续上下文。后者要跨过多轮工具运行，在互相冲突的目标之间做取舍。

Synopsys 用 "fully autonomous" 描述它们。放到工程语境里，这个词应当加上边界：系统在给定目标、输入、工具和权限范围内持续执行多步任务。

Synopsys 自己对 AgentEngineer 的说明也留了人工控制线。其官方博客明确写道，人类工程师必须始终在闭环中（human engineers must always be in the loop）。工程师需要在预设 checkpoint 查看进度、验证行动理由，并在必要时改方向。

因此，" 全自主 " 不等于无人负责。关键约束、低功耗、安全、可靠性、物理验证和 signoff 仍要由有权限的人确认。agent 可以推进流程、整理证据、生成候选动作，工程责任没有随之转移。

Microsoft Discovery 想拿下工程编排层

Microsoft 在这次合作里没有去做 EDA 求解器。Discovery 占据的是另一层：agent 编排、推理、图知识基础、HPC、企业数据连接，以及安全、合规、审计与人工监督。

一条长周期 EDA 工作流要记住目标和历史动作，知道当前设计数据库处于哪个状态，调用正确版本的工具，读回报告，再决定下一步。它还要守住数据权限，知道哪些动作可以自动执行，哪些动作必须等人批准，失败后又该回到哪个 checkpoint。

这正是云平台看中的位置。模型、领域 agent、知识、EDA 工具和算力，被放进一个可持续运行的 R&D 循环。Synopsys 提供 AgentEngineer、EDA 领域知识、Fusion Compiler 以及验证和实现工具；AMD 把系统放到更接近真实芯片研发的评估压力下。

控制面也随之分成三层。EDA 厂商掌握工具、方法学和签核入口，云平台掌握编排、算力、治理和企业数据连接，芯片公司决定任务、权限、基线与验收标准。

这会改变 AI+EDA 的采购方式。客户买的可能不再是工具栏里一个 AI 按钮，而是一套跨模型、跨工具、跨权限域的工程运行环境。谁能记录每一步发生了什么、为什么这么做、结果由哪个工具确认，谁才有机会拿到更长的任务权限。

AMD 带来的，是一套更难的考卷

AMD 在公告里的状态是 " 正在积极评估 "（actively evaluating）。没有具体产品名，没有工艺节点，也没有团队、项目阶段和部署范围。

"AMD 已经用自主 EDA 设计下一代芯片 " 目前没有公开依据。更准确的说法是，AMD 正把这套工作流放到下一代产品开发的评估语境里。

这一步仍然重要。标准样例很少包含真实项目的全部摩擦：企业脚本和工具版本不统一，历史 IP 文档并不干净，设计数据高度敏感，回归队列和许可证有限，不同团队对 closure 的定义也会变化。agent 在干净 demo 里能跑通，进了这类环境才知道能不能活下来。

AMD 的角色因此比一句客户背书更重。它提供的是一张更难的考卷。行业接下来需要看到跨 design、跨阶段的稳定性：换一个 block、换一类 bug、换一个工具版本以后，收益还剩多少？人工接管频率多高？错误动作多久能被发现？方法能否复制到下一支团队？

这些问题比 " 最高提速多少 " 更接近生产判断。

Debug 先报数字，实现收敛先讲方向

两条工作流的披露并不对称。debug closure 给出了 25% – 40%，implementation and closure 只有 "QoR 改善 "。这很可能与任务的可测量性有关。

一次验证失败有相对清楚的起点。系统能否定位根因、提出有效修复、通过原测试和完整 regression，可以交给工具反复检查。统计口径仍需公开，debug 周期、工程师介入时间和问题关闭率至少容易形成基线。

实现收敛复杂得多。QoR 是一组互相牵制的指标。时序改善多少才算有效，要看功耗、面积和拥塞是否同时满足约束。同一套动作放到不同 PDK、设计规模、目标频率和 signoff 条件下，结果也可能反转。一次最优结果很难证明方法稳定。

implementation workflow 没有公开幅度，不代表收益一定较小。当前公开证据只够确认方向。进入生产试点前，厂商还需要给出固定约束下的 PPA 变化、运行次数、成功率、计算成本和人工接管率。

这组披露差异勾出了 agentic EDA 的近期落点。反馈越明确、失败越容易识别、结果越容易回滚，评估越快形成可信数字。任务变长以后，多目标冲突、工具状态和历史动作会一起增加证据建设的难度。

云端评估多了弹性，也多了一张账单

Microsoft Discovery 和 Azure 能为长周期 workflow 提供可扩展算力、agent 编排、企业数据连接与治理能力。需要并行跑 regression、尝试多组实现参数或保存大量中间状态时，这种弹性有现实价值。

云端也会增加新的评估项目。设计数据放在哪里，日志和波形怎么传，哪些 IP 可以离开本地环境，EDA license 怎么调度，失败重跑消耗多少算力，都会进入采购清单。高保密项目还可能要求隔离环境或混合部署。

Microsoft 官方强调 Discovery 的安全、合规、透明度、审计和人工监督。这些条件很重要，客户仍要结合自己的数据分级、权限体系和供应商合同逐项验证。平台声明替代不了项目级安全评审。

ROI 也不能只减掉工程师工时。Azure compute、EDA license、模型调用、数据传输、集成维护和人工审核都要计入。agent 夜里多跑十轮实验，第二天留下几份可用证据，工程师又花多久排除无效结果，这才是完整成本。

25% – 40% 之后，采购团队还要补六张表

评估 autonomous EDA workflow，可以把宣传页拆成六张表。

第一张是任务表。具体覆盖哪些 bug、哪些实现阶段、哪些工具和多大的 design。

第二张是基线表。25% – 40% 相对于哪套人工流程，统计 wall-clock time、工程师工时，还是两者的组合。

第三张是质量表。debug 修复有没有通过完整 regression；QoR 改善是否同时满足 timing、power、area、拥塞和 signoff 约束。

第四张是成本表。Azure compute、EDA license、token、数据传输、集成和人工审核一共花了多少。

第五张是风险表。错误动作率、回滚时间、人工接管点、权限边界和审计记录是否完整。

第六张是迁移表。换 design、IP、PDK、工具版本和脚本规范后，需要重做多少适配。

对芯片企业来说，单独测一个模型或一段 demo 不够。专业模型、企业知识库、EDA flow 编排、权限和过程留痕要放进同一条研发链路。中科麒芯用智语芯、IC 智能知识库和 Flow Builder 承接这层连接，关注点同样落在可控执行与工程证据。

六张表能连续跑出可比结果，评估才有机会进入生产试点（production pilot）。随后还要继续看正式项目、重复部署、tapeout 和硅后结果。每往前一级，证据要求都会更高。

可评估，意味着厂商开始接受客户量化

" 可评估 " 没有 " 全自主 " 那么响，却可能是这次发布最有分量的部分。

它把话题从功能演示带到采购与工程验收。客户可以建立自己的基线，限定 agent 权限，记录每次动作和工具反馈，再比较人工时间、总成本与结果质量。厂商也要面对真实数据的混乱、历史流程的包袱和跨团队协作，而不能只展示最顺的一条路径。

这一步也让三方利益更清楚。

Synopsys 希望证明 EDA agent 能从单点任务走向长周期 workflow；Microsoft 希望 Discovery 成为工程 agent 的企业编排底座；AMD 要判断这些能力能否缩短下一代产品开发，同时守住质量、数据和责任边界。

目前的状态仍很早。Microsoft Discovery 处于预览阶段（preview）。两条 EDA workflow 开放的是评估入口。AMD 正在评估。把三项状态叠在一起，agentic EDA 已经走到生产前验证的门口，还没有拿到生产通行证。

Synopsys、AMD 和 Microsoft 这次共同推出了两条可以申请评估的长周期工程工作流。debug closure 与 implementation closure 都很耗时间，也都依赖大量上下文、工具反馈和人工判断。

25% – 40% 是值得跟踪的起点。它还缺公开方法、独立复现与跨项目数据。implementation workflow 的 QoR 改善披露得更少，目前只能确认方向。

下一条真正重要的新闻，应当来自 production pilot：指标能不能复现，错误能不能及时回滚，成本能不能算过来，工具和数据权限能不能守住，关键 checkpoint 与 signoff 是否仍由工程师掌控。

证据积累到那一步，agentic EDA 才会从 " 能跑 " 走向 " 敢用 "。眼下这张评估入场券，已经比又一场全自主 demo 更接近答案。

作者：麒芯

声明：本文基于公开资料整理分析，25% – 40% 为 Synopsys 早期评估口径，客户评估不等同于生产部署、tapeout、硅后验证或独立 benchmark，不构成投资建议。

参考资料：

1. Synopsys：《Synopsys Advances Agentic AI Chip Design with AMD and Microsoft》

2. Microsoft Azure：《Microsoft Discovery》

3. Microsoft Azure Blog：《Microsoft Discovery: Advancing agentic R&D at scale》

4. Synopsys：《Synopsys Outlines Vision for Engineering the Future》

5. Synopsys：《AgentEngineer Technology: Transforming Engineering Workflows》

6. Synopsys：《Fusion Compiler: RTL-to-GDSII Design Solution》