综述 | 智能体电子设计自动化：从“交接有效性”重新理解 Agentic EDA

论文题目：Agentic Electronic Design Automation: A Handoff Perspective 论文链接：https://arxiv.org/abs/2606.19795 论文作者：Jiawei Liu、Peiyi Han、Yuntao Lu、Su Zheng、Fengyu Yan、Bei Yu 论文机构：香港中文大学、Primarius Technologies 论文方向：Agentic EDA、LLM for EDA、电子设计自动化、工作流交接、可信智能体

导读

EDA 本质上不是一个单点任务，而是一条跨工具、跨阶段、跨团队的长链条：RTL、约束文件、综合脚本、仿真日志、QoR 报告、checkpoint、版图、签核结果和工程决策，会在不同工具、会话和组织之间不断传递。过去的 LLM for EDA 综述多按应用场景、设计阶段或模型方法组织文献；这篇综述则换了一个更工程化的视角：一个智能体生成的东西，交给下游工具、下游智能体或工程师之后，到底还能不能被正确、可追溯、可审计地使用？ 论文提出 handoff validity（交接有效性） 作为 agentic EDA 的核心组织原则。所谓有效交接，不只是“当前 checker 通过了”，而是被交接对象必须满足接收方的接受条件，并携带足够的上下文、证据和来源信息，使下游不需要猜测隐藏假设。基于这一原则，作者综述了 82 个 agentic EDA 系统，将其划分为 Stage-Bound、Flow-Bound、Organization-Bound 三类，并进一步提出五层 EDA Agent Communication Protocol（EACP） 研究议程，覆盖智能体发现、消息结构、工具调用、工作流编排以及安全与 IP 保护。 这篇综述的价值在于，它把“LLM 是否会写代码/调用工具”推进到“LLM 产物如何跨边界被工程系统接纳”的层面。

1 Introduction | 引言

EDA 工作流天然是 handoff-heavy 的。数字设计从 RTL 到综合、布局布线、时序收敛和签核；模拟设计从原理图到后仿、DRC/LVS；验证流程则持续产生测试、覆盖率、错误日志和修复补丁。每一阶段的输出往往会成为下一阶段的输入，但输出本身并不总是携带完整语义。例如，一个综合后的 gate-level netlist 反映了某组 SDC 约束下的优化结果，却不等于完整保存了约束语义；如果下游拿到过期 SDC、不兼容库版本或不完整 checkpoint，就可能出现执行失败、时序违规或不可复现实验。 传统 ML4EDA 主要提升单个任务的效率和质量，如布局、时序预测、HLS 指令搜索等。这类方法往往有固定接口、数据 schema 和实验假设，但输出何时可在 PDK、工具版本或设计规格改变后继续复用，通常没有被显式建模。 LLM-based agent 带来了新复杂度。它们不仅回答问题，还会调用 EDA 工具、生成可执行脚本、根据工具反馈迭代修复、在多智能体间传递状态，甚至把检索到的文档知识转成工程命令。一旦这些输出影响下游工程决策，输出就必须满足某种“交接合同”：谁接收、接收方期待什么、证据在哪里、适用范围是什么、来源是否可查、是否有权限执行。

论文因此提出 handoff validity：当一个被转移的对象满足消费者的接受条件，并携带足够上下文、证据和 provenance 以供下游使用时，交接才是有效的。

这也解释了为什么仅按“任务类别”或“模型类型”组织 agentic EDA 不够。RTLFixer 这类系统可能只需要在单一修复循环中满足编译器反馈；ChatEDA 这类系统要跨多阶段传递脚本、工具输出和状态；Ask-EDA 或 RTLExplain 这类系统则需要保证知识来源、适用范围和组织可接受性。它们都属于 LLM for EDA，但交接边界完全不同。 论文围绕四个问题组织后文：什么条件和证据能建立 handoff validity、被交接的是什么、交接过程如何管理、边界上还有哪些开放问题。它们分别对应 handoff contracts、handoff objects、coordination mechanisms 和 open questions。 语料方面，作者检索了截至 2026 年 5 月 1 日公开、已发表或已接收的相关工作，覆盖核心 EDA 会议与期刊以及 AI/ML 会议中的 EDA 论文，最终纳入 82 篇描述 82 个 agentic EDA 系统的论文。

2 A Boundary-Centered Taxonomy | 以边界为中心的分类法

论文首先定义四个核心概念。 交接有效性 指交接对象在接收方语境下可被接受、可解释、可继续使用。它超越局部正确性：RTL patch 编译通过不等于满足综合、时序或集成要求；TCL 脚本在当前 session 可执行，也可能在路径、工具版本或 library 改变后失效。 交接合同 指接收方对交接对象提出的接受条件及证据要求，可以是功能验证、规格一致性、性能阈值、物理验证、脚本可执行性或来源可追溯性。 交接对象 可以是设计 artifact、验证 artifact、工作流状态、知识条目、命令、脚本或工程决策，例如 netlist、SDC、synthesis TCL、QoR report、检索规则或审批记录。 协调机制 是生产、传递、验证和维护 handoff object 的交互模式。例如 generate-repair、search-optimize、orchestrate-transform、recover-resume、retrieve-answer、retrieve-execute 等。 基于交接有效性必须维持的边界范围，论文提出三类系统。

Stage-Bound 系统在单个 EDA 阶段或 bounded verification task 内建立有效性。典型例子包括 RTL 修复、Verilog 生成、模拟电路 sizing、版图生成、断言生成等。它们通常依赖局部 checker、仿真器、覆盖率或性能指标来关闭当前任务边界。 Flow-Bound 系统要跨工具、会话或相邻 pipeline 阶段保持状态一致。典型例子包括 ChatEDA、ASIC-Agent、ORFS-Agent 等。它们传递的不只是某个 artifact，还包括脚本、约束、checkpoint、QoR 记录、执行轨迹和工作流状态。 Organization-Bound 系统跨越项目、团队、知识库或权威边界。典型例子包括 Ask-EDA、RTLExplain、ChatLS 等。其关键不只是答案是否看起来合理，而是检索来源是否可检查、适用范围是否匹配当前 PDK/工具/项目、命令是否被授权、证据能否进入工程审查和签核流程。 这三类不是互斥能力，而是按“最宽交接边界”归类。若系统同时有局部修复和跨流程编排能力，应按 Flow-Bound 理解；若系统将组织知识转成可执行脚本并影响工程决策，则需要按 Organization-Bound 标准处理。

3 Stage-Bound Systems | 阶段边界系统

Stage-Bound 系统的交接范围最窄，但也是 agentic EDA 最常见的落点。它们通常在一个局部任务中生成 artifact，然后依赖 checker、simulator、formal tool、coverage monitor 或 learned evaluator 反馈修复，直到局部接受条件满足。 论文将 Stage-Bound 的 handoff contracts 概括为四类：功能验证、规格符合、性能评估和物理验证。RTL 生成与修复系统往往使用编译、仿真、测试或覆盖率作为证据；模拟电路系统使用 SPICE 仿真、性能指标、拓扑约束；版图系统使用 DRC/LVS 或几何规则；断言/测试生成系统则依赖语法、语义、覆盖率或 formal verdict。 Stage-Bound 的 handoff objects 主要包括三类：设计 artifact、验证 artifact 和 hybrid object。设计 artifact 可以是 RTL、Verilog、Chisel、网表、电路拓扑、layout program 或参数配置；验证 artifact 可以是 testbench、assertion、coverage plan、diagnostic trace；hybrid object 同时承担设计和验证角色，例如带有修复证据的 RTL patch，或附带性能评估的模拟电路候选。 其协调机制主要包括：

• 生成-修复：模型生成 artifact，checker 返回错误，系统迭代修复。
• 搜索-优化：模型或智能体在候选空间中搜索，使用仿真、综合或性能指标筛选。
• 支撑型机制：系统不一定闭环修复，而是生成诊断、定位、约束、测试或验证辅助信息。

Stage-Bound 的开放问题很直接：不同局部反馈如何统一表示并转化为可操作信号？局部 checker 通过是否足以支持下游使用？它解决的是“局部可接受”，但还没有完全解决“下游可交接”。

4 Flow-Bound Systems | 流程边界系统

Flow-Bound 系统面对的是更接近真实 EDA 的问题：多个工具、多次调用、多轮 session 和多个阶段之间的状态要保持一致。这里的交接对象不再只是单个代码片段，而是包含 artifact、脚本、约束、配置、日志、报告、checkpoint 和执行记录的一组状态包。 Flow-Bound 的 handoff contracts 包括两类核心要求。第一是脚本和命令在当前工具环境中可执行，且输入输出 schema 与后续节点匹配。第二是下游验证条件满足，例如 synthesis 之后的 netlist、SDC、library、QoR report 与 timing analysis 所需上下文一致。 Flow-Bound handoff objects 通常包括 stage output、QoR record 和 flow state。stage output 是当前阶段产物，如综合脚本、网表、版图中间件；QoR record 包含 timing、area、power、congestion 等度量；flow state 则包含 session、tool version、路径、环境变量、checkpoint、执行历史和恢复点。 其协调机制包括：

• 编排-转换：将一个阶段的输出转成下一个阶段可消费的输入，并保持接口、约束和状态一致。
• 恢复-继续：在工具失败、session 中断或回归失败后，从 checkpoint 或 repository state 恢复。
• 标注-优化：把下游 QoR 或验证结果标注回上游决策，指导后续搜索与迭代。

Flow-Bound 的难点在于，流程有效性不是一次 checker 通过就能保证的。脚本可能因工具版本或路径变化失效，QoR 改善可能依赖未记录约束，checkpoint 可恢复也不代表上下游 artifact 仍兼容。因此它需要明确的 context fingerprint、dependency record、checkpoint policy 和 transition evidence。

5 Organization-Bound Systems | 组织边界系统

Organization-Bound 系统处理的是最宽的交接边界：知识、权限、来源、团队和工程责任之间的传递。它们常见于 RAG 问答、设计文档检索、脚本生成、问题诊断、知识图谱和多模态工程助手。 在这类系统中，handoff contract 的核心是 source grounding：输出必须能追溯到可检查的来源，并且来源范围要匹配当前项目、PDK、工具版本和组织上下文。一个命令即使来自官方文档，也可能对当前设计不适用；一个经验规则即使在某个项目有效，也可能没有权限跨项目复用；一个 retrieved answer 即使引用了文档，也可能缺少文档版本、适用工艺和审批路径。 Organization-Bound handoff objects 包括 knowledge artifact、command artifact 和 hybrid object。knowledge artifact 是文档片段、设计规则、FAQ、历史 issue、图表或专家知识；command artifact 是 SQL 查询、EDA 工具命令、TCL 脚本或诊断步骤；hybrid object 则同时包含解释、证据和可执行动作。 其协调机制主要有：

• 检索-回答：从文档、知识库或项目记忆中检索证据并生成可追溯回答。
• 检索-执行：将检索知识转化为可执行命令、脚本或查询。
• 混合机制：既生成解释，又生成可执行动作，并维护来源、查询、结果和审批之间的链路。

该类系统的开放问题最敏感：如何编码 source scope？chunk-level citation 是否足够？grounded command 执行前如何同时验证来源有效性、执行正确性、设计约束、访问权限和变更审批？这些问题决定 agentic EDA 能否进入真实组织工作流。

6 Toward a Unified EDA Agent Communication Protocol | 走向统一 EDA 智能体通信协议

在分析三类边界之后，论文指出结构性互操作缺口：现有通用协议可以支持消息传递、工具访问或工作流执行，但缺少面向 EDA 的共享语义，无法同时标准化智能体发现、handoff message、异构工具调用、多阶段编排、安全/IP 边界和可审计证据。 因此作者提出五层 EDA Agent Communication Protocol（EACP）研究议程。

EACP 的五层分别对应五个问题：

• Agent discovery protocol：多厂商 EDA 环境中的智能体如何发现并验证兼容 peer？
• Agent message protocol：handoff message 必须携带什么结构，接收方才能正确行动？
• Tool invocation protocol：智能体如何通过共享 typed interface 调用异构 EDA 工具，并由 backend adapter 映射到具体工具？
• Workflow orchestration protocol：多个智能体如何组合成可靠、可恢复的多阶段 pipeline？
• Security & IP protocol：敏感工艺 IP 如何保护，每个 agent action 如何可归责？

论文还提出六类共享 reference type，避免每层重复定义上下文、artifact、证据和策略：

• ContextRef：标识 PDK、工艺节点、corner、library、工具环境、约束集和设计版本。
• ArtifactRef：标识设计、验证、工作流、命令或知识对象的类型、版本、位置、hash 和所有权。
• EvidenceRef：标识 checker 结果、诊断记录、QoR 测量、验证者身份和合同 verdict。
• PrincipalRef：标识 agent、用户、服务、orchestrator 或 tool adapter 的认证身份。
• PolicyRef：标识授权、保密、披露、执行和保留策略。
• TraceRef：把消息、工具调用、工作流事件、审批和来源记录连成 provenance chain。

这个协议设想非常工程化。它不规定所有 EDA 命令目录，而是定义跨 agent、tool 和 workflow 的共享语义：谁能做什么、在什么上下文下做、产生什么 artifact、用什么证据证明、出错如何恢复、哪些信息能披露、最终如何审计。

7 Conclusion | 结论

这篇综述的核心观点是：agentic EDA 的长期目标不只是让 LLM 在某个局部任务上更强，而是让设计 artifact、工作流记录和工程决策在跨阶段、跨流程、跨组织边界时仍然 portable、auditable、admissible。 作者用 handoff validity 重新组织 82 个 agentic EDA 系统，提出 Stage-Bound、Flow-Bound、Organization-Bound 三类边界，并以 handoff contracts、handoff objects、coordination mechanisms 和 open questions 四个维度进行比较。这个框架把许多看似分散的 LLM for EDA 工作连接起来：RTL 修复、工具调用、自动化 flow、RAG 问答、知识图谱、脚本生成和多智能体编排，本质上都在处理“交接对象如何被下游接收”的问题。 更重要的是，论文提出的五层 EACP 给出了下一阶段研究方向：智能体发现要表达 EDA 兼容性，消息协议要携带上下文和证据，工具调用要有 typed semantics，工作流编排要支持 checkpoint、恢复和验证，安全/IP 层要保证授权、披露、保护、保留和审计。 对真实芯片设计而言，agent 能生成 RTL 或脚本只是第一步。更难的是：它生成的东西是否带着完整约束、版本、证据、来源、权限和责任链，能否被下游工具、工程师和组织流程接纳。这正是本文用“handoff perspective”强调的方向。