26年3月来自浙大的论文“FluxEDA: A Unified Execution Infrastructure for Stateful Agentic EDA”。

大语言模型和自主智体正被越来越多地应用于EDA自动化，但许多现有的集成方案仍然依赖于脚本级或请求级交互，这使得在实际的生产环境中难以保持工具状态并支持迭代优化。本文提出FluxEDA，一个统一的、状态智体EDA基础设施。FluxEDA引入一个基于托管网关的执行接口，并实现结构化的请求和响应处理。它还维护持久化的后端实例。这些特性使得上层智体和可编程客户端能够通过保留的运行时状态与异构EDA工具进行交互，而不是通过孤立的shell调用。其用两个具有代表性的商业后端案例研究对该框架进行评估：自动化路由后计时ECO和标准单元子库优化。结果表明，FluxEDA能够支持在实际工具环境中进行多步骤分析和优化，包括状态重用、回展（rollback）和协同迭代执行。

FluxEDA 是一个统一的基础架构，用于构建可靠且有状态的代理式 EDA。与通过碎片化的脚本或临时 shell 接口直接暴露异构 EDA 工具不同，FluxEDA 在上层客户端和底层工具环境之间插入一个稳定的能力层，如图 1 所示。FluxEDA 网关的核心是通过结构化的 Socket-RPC 接口封装工具原生功能，并为工具交互提供受管理的执行基础。网关主要通过 MCP 服务器进行访问，以实现标准化的面向智体集成，同时还支持 Python 和 C++ SDK 以进行编程使用。通过这种设计，涵盖逻辑综合、物理设计和验证的异构引擎被整合到数字实现流程中的统一 API 空间中。这使得智体能够在持久的工具会话中运行，而不是在离散的脚本边界上运行，同时也使传统的软件客户端能够与同一个受管理的运行时环境进行交互。此外，FluxEDA 集成强大的平台级运行时管理功能，包括实例路由、基于心跳的会话维护、超时控制和异步长任务执行，从而能够在面向生产的 EDA 环境中实现稳定的长周期交互。

虽然 MCP 服务器和网关建立了一个持久的工具访问界面，但仅靠原始 API 暴露不足以实现复杂的数字化应用。为了弥合底层工具调用和高层设计意图之间的差距，FluxEDA 引入域特定的技能 [18] 来编码显式的工作流知识。技能并非完全依赖智体的隐式推理来处理复杂的 EDA 流程，而是提供结构化的程序指导。这包括任务分解、输入验证、执行顺序、会话上下文保存和可重用的操作模板。因此，这种架构强制执行严格的关注点分离：MCP 层控制如何安全地公开和管理工具功能，而技能层则规定何时以及以何种顺序组合这些功能以完成具体的流程任务。

概述

图 2 展示 FluxEDA 的整体架构。该系统分为五层：访问层、通信层、网关层、EDA 工具适配层和运行时管理层。FluxEDA 并没有直接向用户或代理暴露特定工具的 shell，而是在前端客户端和后端 EDA 环境之间插入了一个通用的执行栈。这种架构在不同的接口之间提供了一致的调用路径，同时将特定工具的执行和会话管理保留在基础架构层内。

从 EDA 的角度来看，该架构的主要目的是在持久执行模型下支持多步骤和跨工具的交互。许多实际任务并非单个命令，而是一系列相互依赖的分析、报告和优化步骤，这些步骤必须在相同的已加载设计和运行时状态下运行。因此，FluxEDA 将统一访问、受控方法分发和受管理的工具会话整合到一个软件底层，用于实现可编程和智体辅助的 EDA 自动化。

执行信号流

图 3 以编号信号流的形式展示 FluxEDA 中的端到端请求路径，涵盖了网关前、网关控制和网关后三个阶段。在步骤 (1) 中，传入的请求被打包成一个结构化基于socket 的 RPC 消息，其中包含目标方法、参数和执行元数据，然后被转发到公共通信和网关路径。

跨越 RPC 边界后，请求进入网关控制阶段。在步骤 (2) 中，FluxEDA 会应用执行前所需的控制检查，包括协议验证、注册表查找、参数检查和能力级授权。网关不会直接暴露任意 shell 过程，而是仅针对显式注册的 api_* 方法解析请求，从而为后端访问定义清晰的执行边界。网关还在步骤 (3) 中支持能力发现，客户端可以通过通用的自省 API 查询连接性、可用方法和相关的接口元数据。

在步骤 (4) 中，经过验证的可执行请求被分发到相应的通用 API 或工具特定的 API。在步骤 (5) 中，目标后端实例执行请求的操作，结果在网关后路径中进行规范化。最后，在步骤 (6) 中，FluxEDA 向调用者返回结构化响应，其中包括状态信息，以及根据所选返回模式返回类型化数据、类似文本的输出或原始工件。通过使用统一的通信契约进行调用、自省和结果交付，FluxEDA 使上层自动化与可执行接口保持一致，并减少了对工具特定 shell 约定的依赖。

渐进式功能暴露和技能

面向智体的 EDA 基础设施面临的一个实际挑战是如何在不使上层客户端过载的情况下暴露工具功能。实际上，预先发布所有可调用方法及其描述的扁平化 MCP 接口不仅会随着后端功能的增长而变得越来越臃肿，还会消耗基于 LLM 智体的宝贵上下文预算 [19]。为了解决这个问题，FluxEDA 采用一种渐进式的功能暴露机制：网关首先仅提供一个简洁的功能发现界面，例如通过诸如 api_ping 和 api_list_method 之类的自省 API，而详细的调用要求仅在需要时才进行查询。这种设计使得协议界面保持简洁，并能随着后端工具的演进而扩展。同时，工作流知识通过特定领域的技能进行单独处理，这些技能指导在已发现的方法空间中进行功能选择和调用顺序，而不会使协议层本身过载。

工具适配和生命周期管理

在网关之下，FluxEDA 使用工具适配器通过一致的可调用接口暴露原生工具的功能。这一层的目的并非消除特定工具的行为，因为时序分析、综合、仿真和实现工具在命令语义、状态模型和报告格式方面自然存在差异。相反，这些差异被限制在已注册的 api_* 方法之后，从而允许上层调用后端操作，而无需直接依赖特定工具的 shell 约定。

这种接口抽象与生命周期管理的后端实例相结合。FluxEDA 并非将每个请求视为独立的 shell 调用，而是重用受管理的实例，从而在多次调用中保留已加载的设计、执行上下文和中间状态。这种执行模型对于实际的 EDA 自动化至关重要，因为一项任务通常包含多个依赖步骤，例如设计加载、报告检查、时序分析、优化以及在更新状态下的重新分析。

图 4 展示了这种机制：首先，后端工具进程会被纳入运行时管理，并绑定到一个实例 ID (instance_id)，该 ID 作为后续调用的路由句柄；一旦建立，同一实例即可被一系列请求重用，同时在交互过程中保持已加载的设计和内部工具上下文不变；相比之下，每个 RPC 都携带一个唯一的请求 ID (request_id)，用于每次调用的跟踪、响应匹配和错误报告；这种分离使得 FluxEDA 能够在单一调用框架内同时维护实例的连续性和请求级别的可观测性。

运行时管理层通过进程启动、实例绑定和路由、端口分配、就绪检查、存活监控、对长时间运行操作的支持以及在显式释放、超时或故障时进行清理来维持这一生命周期。因此，更高级别的自动化可以在稳定的后端实例上运行，而无需重复重建工具环境。这种持久实例执行模型使 FluxEDA 与简单的 RPC 包装器区别开来：FluxEDA 不仅规范了后端工具的调用方式，还规范了其运行时状态的创建、保存、重用和回收，以用于迭代和跨工具的 EDA 任务。