当AI开始进入芯片设计流程，评价一个EDA智能体的能力，已经不能只看它能否生成几段RTL代码，更重要的是，它能否理解设计需求、规划执行路径、调用EDA工具，并在仿真发现问题后自主调试，最终完成验证与性能评估。

合见工软UDA 3.0亮相EDA智能体沙龙：多智能体协同推进芯片设计验证全流程自动化图1

在2026湾芯展同期电子创新网举办的EDA生产力智能体沙龙上，合见工软EDA软件产品AE刘万江现场演示了数字设计AI智能平台UniVista Design Agent（UDA）3.0的工作过程。该演示没有停留在产品介绍和功能展示，而是直接进入芯片设计任务：通过自然语言输入设计需求，由智能体自主规划工作流程、生成多个子智能体，调用EDA工具完成RTL设计、代码检查、仿真验证、调试修复、覆盖率分析及PPA评估等任务。

在演示中，刘万江解释说UDA 3.0围绕一个可综合的、包含8个通用寄存器的16位单周期CPU核展开设计与验证工作。整个过程涉及多智能体任务分解、并行设计、仿真调试和多种EDA工具协同，展示了合见工软将Agentic AI引入芯片数字设计与验证流程的最新进展。

从生成代码到执行完整工程任务，EDA智能体正在尝试跨越芯片设计自动化的新门槛。

从自然语言到EDA工具链：让AI真正参与芯片设计

传统数字芯片设计流程涉及需求分析、RTL编码、逻辑检查、仿真验证、问题调试、回归测试以及性能和面积评估等多个环节。不同阶段往往需要工程师切换工具、分析日志、定位问题，再将结果反馈给设计或验证环境。

AI代码生成工具可以帮助工程师编写RTL代码，但代码生成只是芯片设计任务的一部分。要将AI能力真正融入工程流程，还需要解决任务如何拆解、工具如何调用、执行状态如何管理，以及发现错误后如何继续迭代等问题。

刘万江表示这正是合见工软UDA 3.0试图解决的核心问题。

合见工软UDA 3.0亮相EDA智能体沙龙：多智能体协同推进芯片设计验证全流程自动化图2

根据合见工软官网的产品介绍，UDA 3.0是一款基于Agentic AI技术、针对芯片设计场景优化的数字设计AI智能平台。它支持任务规划、流程编排和调度，可以通过自然语言指令或设计规格（Spec）生成、修改Verilog RTL代码，并进一步调用EDA工具完成设计检查、验证、纠错和PPA评估。

在刘万江的演示中，工程师首先将设计相关文件加入工作空间，再通过VS Code风格的交互界面向UDA 3.0描述任务要求。系统可以结合输入文件、预设工作流以及相关知识和Skills，分析任务并生成执行计划。

这一交互方式的变化看似简单，背后却涉及EDA应用模式的转变。

过去，工程师需要明确知道应该使用什么工具、执行什么命令，以及下一步应该如何处理工具返回的结果。引入智能体之后，工程师可以更多地从设计目标出发，由AI负责将目标拆解成可执行的工程步骤，再根据任务进展调用相应工具。

当然，这并不意味着工程师不再需要理解设计流程。对于复杂芯片项目，设计规格是否完整、约束是否合理、验证目标是否充分，依然直接影响最终结果。UDA 3.0的价值在于，将部分流程组织、工具操作和重复性分析工作交由AI执行，让工程师能够把更多精力放在架构、算法和关键设计决策上。

多智能体协同：将复杂设计任务拆解为可执行流程

在本次演示中，多智能体协同是一个值得关注的技术环节。刘万江展示了UDA 3.0根据工作流生成多个子Agent的过程。演示中，系统生成了11个Agent，并通过任务规划和流程编排，将整体设计任务拆解为不同阶段的工作。

与单一AI模型直接生成代码不同，多智能体架构强调任务分工和协同执行。不同子Agent可以承担需求分析、设计规格细化、模块生成、验证、调试或结果分析等工作，并根据任务需要调用不同的大模型。

据他介绍，UDA 3.0通过增强Harness Engineering能力，改善对复杂任务和长程任务的支持。这里的关键不仅是让模型具备推理能力，还需要为其建立相应的执行框架，使任务能够按照一定的流程推进，并在不同阶段管理输入、输出和执行状态。

对于芯片设计而言，这种能力尤其重要。因为一个看似简单的RTL设计任务，也可能包含多个相互依赖的步骤。例如，设计代码生成后，需要经过语法和Lint检查；完成检查后，需要建立验证环境并开展仿真；仿真若发现错误，则需要结合日志、关键信号或波形进行分析，修改代码后重新验证；只有当相关检查通过后，才能进一步开展面积、时序等指标的评估。

如果AI只能独立完成其中某一个环节，工程师仍然需要手动串联整个流程。只有当智能体能够理解步骤之间的依赖关系，并根据执行结果决定后续动作时，AI才有机会承担更完整的工程任务。

UDA 3.0演示的多智能体架构，正是围绕这一方向展开。在执行模式上，刘万江还展示了多个Agent并行处理不同子模块的过程。对于适合并行开展的设计任务，系统可以组织多个Agent分别执行；对于存在先后依赖关系的任务，则需要按照流程顺序推进。

这种设计兼顾了任务分解与执行效率。不过，在实际项目中，并行程度仍然需要根据模块依赖、资源条件和设计约束确定，并非所有芯片设计任务都适合并行处理。

另一个值得关注的细节是，不同子Agent可以配置不同的大模型。由于不同模型在长程任务、代码生成、推理分析等方面可能具有不同的能力特点，针对任务进行模型配置，有助于提高复杂工作流的适配能力。

这意味着，EDA智能体的竞争不只是模型能力的竞争，也涉及任务调度、工程流程设计、工具接口和执行管理等系统能力。

不止于生成RTL：从检查、仿真到调试和PPA评估

本次演示的另一个重点，是UDA 3.0对设计与验证流程的贯通。围绕16位CPU核的设计任务，系统不仅生成设计代码，还进一步执行了多项检查和验证工作。

在设计阶段，智能体根据输入需求和工作流开展任务规划、模块规格细化及RTL生成，并执行相应的代码检查。在验证阶段，系统生成验证相关内容，调用仿真工具开展测试，并对执行结果进行分析。

演示中，仿真曾出现错误。系统随后对问题进行分析，并通过跟踪关键信号等方式开展调试，在修正问题后重新执行仿真，最终完成相关测试和覆盖率收集。这一过程体现了EDA智能体区别于普通代码助手的一个重要特征：它不仅需要生成代码，还需要根据工具反馈采取后续行动。

芯片设计中的错误往往不会在代码生成时全部暴露。即使RTL代码符合语法要求，也可能存在功能逻辑错误，或者在特定测试条件下出现与预期不符的行为。因此，设计、验证、调试之间必须形成持续迭代的闭环。

在传统流程中，工程师需要根据仿真日志和波形分析问题，再决定是否修改代码、调整测试环境或重新运行验证。智能体如果能够参与这一过程，就有机会减少人工在工具切换、日志分析和重复执行上的投入。

在完成相关设计与验证工作后，UDA 3.0还调用了相应工具开展Lint、PPA评估以及等价性检查等工作。

根据现场演示结果，相关设计检查和PPA评估均显示通过，形式验证相关检查也完成了相应流程。系统还对回归测试结果及覆盖率进行了总结。演示任务将覆盖率目标设定为高于95%，最终展示的结果未达到100%，符合该任务预设的覆盖率要求。

刘万江指出覆盖率达到预设阈值，并不等同于芯片设计已经获得完整的功能正确性证明。覆盖率指标反映测试对相关代码或功能目标的覆盖情况，其意义仍取决于覆盖率类型、验证计划、测试质量和具体设计要求。同样，演示中单个CPU核任务的检查通过，也不能直接推导出UDA 3.0已经能够无条件完成任意规模、任意复杂度的芯片设计。

但从工程流程角度看，这次演示至少呈现了一条相对完整的技术路径：由自然语言提出设计目标，通过多智能体组织任务，调用EDA工具完成设计与验证，再根据工具反馈进行调试和迭代，最后汇总执行结果。

对于EDA智能体而言，这比单纯展示代码生成更有参考价值。

Agentic AI与EDA工具链结合：合见工软的差异化路径

如果说大模型为EDA智能体提供了理解需求、生成代码和分析问题的能力，那么专业EDA工具链则是其开展工程工作的基础。

芯片设计并非纯粹的软件编程。RTL代码需要满足硬件描述语言规范，设计需要经过逻辑检查与验证，面积和时序需要通过相应工具进行评估，最终结果还需要满足项目既定的设计约束。因此，AI生成的代码是否正确，不能只依靠模型自身判断，而需要借助专业工具进行检查和验证。

刘万江表示合见工软的产品思路是将UDA 3.0作为AI任务规划与执行平台，与自身的EDA工具链结合，形成AI平台与专业EDA工具协同的解决方案。他表示UDA 3.0可以调用其数字设计和验证工具，包括UVS+仿真引擎、UVD+调试引擎、VPS回归测试管理工具，以及Lint、Formal和逻辑综合等相关工具。

其中，UVS+承担仿真相关工作，UVD+支持设计调试，VPS用于回归测试管理。通过将这些工具纳入智能体工作流，UDA 3.0能够在不同设计阶段调用相应的专业能力，而不必将所有功能都交给大模型本身完成。

这也是EDA智能体与通用AI编程助手之间的重要区别。

通用AI编程助手主要围绕软件代码生成和开发流程展开，而芯片设计需要更严格的硬件语义、设计规则和验证机制。AI要进入这一领域，必须与专业EDA工具建立紧密联系，并通过工具执行结果验证设计行为。

合见工软还将UDA 3.0与UniVista Verification GOAT验证AI智能体EDA工具集相结合。通过调用仿真、调试和回归测试管理等工具，并提供开箱即用的Skills，平台可以支持从验证计划到验证执行的相关工作。

对于UVM验证场景，UDA 3.0支持AI辅助生成验证计划、搭建验证环境，并配合GOAT完成UVM流程中的相关任务。平台还支持TestBench和SVA断言生成，并能够结合仿真工具开展验证与纠错。

这表明，合见工软的布局并不局限于RTL代码生成，而是希望将AI能力扩展到芯片设计与验证的多个环节。

除了与自身工具链集成，UDA 3.0也提供开放接口，支持通过Skills、MCP等方式接入其他工具。这为后续扩展工作流和适配不同工程环境提供了空间。

当然，开放接口只是生态扩展的基础。要真正形成可复用的工程能力，还需要解决工具适配、设计数据一致性、执行权限、错误恢复以及跨工具结果验证等问题。

从Demo走向工程应用，EDA智能体还要跨过哪些门槛？

目前，EDA智能体正在从辅助编程向复杂工程任务执行发展，但从演示验证到规模化应用，仍然存在一系列需要解决的问题。

首先是复杂任务的可靠性。单个CPU核的设计和验证可以展示智能体的基本能力，但真实芯片项目往往包含更大规模的RTL代码、复杂的模块依赖、严格的时序约束，以及多层次的验证目标。智能体能否在长时间执行过程中保持任务状态一致，能否准确处理工具异常和设计变更，仍需要通过更多实际项目检验。

其次是结果的可验证性。EDA工具能够检查特定规则、验证设计行为或评估PPA指标，但不同工具的通过结果并不能简单等同于整个芯片项目已经完成验证。智能体需要准确理解每个工具的能力边界，并将结果与原始设计需求、验证计划和工程约束对应起来。

第三是企业级部署能力。芯片企业通常拥有自己的设计规范、代码库、验证环境和知识资产。如何将这些内部资源安全、有效地接入智能体工作流，同时控制不同用户的访问权限，并管理模型调用和任务执行，是EDA智能体能否进入日常研发体系的重要条件。

针对这些需求，刘万江指出UDA 3.0提供了企业级后台管理功能，包括用户权限和会话管理、知识库与代码库创建、企业知识库和代码库对接、组织级Skills资产管理，以及Token使用统计和功能使用分析等。

这些功能的意义在于，让智能体不只是一个供个人使用的交互工具，而是具备融入企业研发环境的基础条件。

此外，他也表示EDA智能体的价值最终仍需要通过实际工程数据来衡量，包括设计任务完成率、验证效率、问题定位时间、工具调用成功率，以及工程师介入程度等。只有这些指标得到持续验证，才能更准确地判断智能体为芯片研发带来的实际收益。

结语：EDA智能体的竞争，正在从代码生成走向工程闭环

从本次EDA智能体沙龙的演示来看，合见工软UDA 3.0展示了多智能体任务编排、专业EDA工具调用、设计验证迭代和结果汇总等能力，并将这些能力组织到同一套数字设计AI平台中。演示中，每一项 AI 产出都经过 EDA工具验证、附带完整证据链，让 AI 结果更可靠、更可信。

这反映出EDA与AI融合的一条重要发展方向：AI的作用不再局限于帮助工程师完成某项孤立操作，而是逐步参与由多个工具、多个任务和多轮反馈组成的工程流程。

对于EDA厂商而言，未来的竞争也将不只是比较谁能生成更好的RTL代码，还要看谁能将AI模型、专业工具、设计数据和验证流程真正整合起来，让智能体在明确约束下完成可检查、可追踪的工程任务。

合见工软UDA 3.0的此次演示，为这一方向提供了一个具体案例。其后续价值，还需要在更复杂的设计项目、更多样的验证场景和实际客户工作流中持续检验。但有一点已经越来越明确：当AI开始承担任务规划、工具调度、设计迭代和验证分析，EDA智能化的竞争焦点，正在从单点辅助能力转向完整的工程执行能力。

合见工软UDA 3.0亮相EDA智能体沙龙：多智能体协同推进芯片设计验证全流程自动化图3