ZhuLong：面向EDA脚本的执行落地LLM代理，具备离线API自我探索能力

# ZhuLong：面向EDA脚本编写的执行落地LLM智能体与离线API自我探索
来源：https://arxiv.org/html/2608.07925
Yang Liu Shiwei Hou Xiyuan Chen Yu Wang Sen Yuan\{paul\.liu, shiwei\.hou\}@cxmt\.com chenxiyuan@mail\.ustc\.edu\.cnQirui Gan Shao You Feifan Chen Wencheng Li Shuyang HuYongzhou Liu Emma Xia Xiaojing Lu Hao Wang Fan Xu Yanfeng Li

###### 摘要。

使用工具特定、往往缺少文档的API进行EDA脚本编写，仍然是一个长尾瓶颈，现有LLM无法解决。本文提出ZhuLong，一个基于执行落地的LLM编码智能体，用于PyAether和SKILL。它通过统一的MCP工具将API检索、文档检查和沙箱执行结合起来，并辅以离线API自我探索机制，通过反事实实验推断未文档化的API行为。

我们在EDA-Eval-PyAether上评估ZhuLong，这是一个包含158个真实世界任务、基于断言执行的基准测试。完整系统在商用华大九天Aether环境中达到78.5%的Pass@1，显著优于纯LLM基线（23.6%）。消融研究确定沙箱执行是主导性能驱动因素（移除后下降41.2个百分点），自我探索机制额外贡献3.2个百分点的准确率提升，并将每个任务的平均工具调用减少22.1%。在涉及未保存版图和原理图的20个交互式任务上，ZhuLong在PyAether上达到60.0%的Pass@1，在SKILL上达到50.0%。

用于EDA的LLM智能体、EDA脚本编写、代码生成、沙箱执行、API自我探索

††会议：第32届亚太设计自动化会议；2027年1月25-28日；日本东京††ccs：硬件 软件 用于EDA的工具

## 1. 引言

大语言模型（LLMs）在通用代码生成方面已展现出强大能力[Vaswani et al.,2017](https://arxiv.org/html/2608.07925#bib.bib22)；[OpenAI,2023](https://arxiv.org/html/2608.07925#bib.bib17)；[Yang et al.,2025](https://arxiv.org/html/2608.07925#bib.bib24)。然而，将LLM应用于EDA脚本编写——工程师通常需要操作内存中的设计数据库、创建版图实例、连接原理图以及查询网表——仍然具有挑战性。首先，EDA API是长尾且工具特定的；许多API很少出现在公开训练语料中。其次，正确性无法通过静态方式验证：它取决于真实EDA环境中可观测的副作用，例如修改后的版图或更新后的原理图。第三，没有执行反馈，静态生成既无法诊断错误，也无法迭代修正不正确的代码[Chen et al.,2024](https://arxiv.org/html/2608.07925#bib.bib6)；[Blocklove et al.,2024](https://arxiv.org/html/2608.07925#bib.bib4)。现有基于LLM的EDA工作主要集中在HDL生成上[Thakur et al.,2023](https://arxiv.org/html/2608.07925#bib.bib21)；[Liu et al.,2024](https://arxiv.org/html/2608.07925#bib.bib15)，而使用真实工具API进行脚本编写——尤其是文档不完整和沙箱执行——仍未得到充分探索。

本文提出ZhuLong，一个基于执行落地的LLM编码智能体，用于PyAether和SKILL。ZhuLong以传说中的神兽“烛龙”命名，它睁开眼睛带来光明，旨在照亮不透明的EDA API，并自动化工具特定的脚本工作流。ZhuLong构建于Cline-CLI[Contributors,2024](https://arxiv.org/html/2608.07925#bib.bib8)之上，扩展了三个MCP工具[Lu et al.,2025](https://arxiv.org/html/2608.07925#bib.bib16)——search_apis、get_api_details和run_code——它们形成一个闭环：检索候选API、检查其文档、在EDA环境中执行代码并获得执行反馈，然后根据观察到的错误或输出进行迭代修正。所有工具都接受统一的lang参数，同时支持PyAether和SKILL，并使用完全相同的智能体逻辑。为了进一步解决文档不完整或过时的问题，ZhuLong引入了离线API自我探索机制，通过反事实实验主动探索沙箱中未文档化的API行为——有意测试替代参数值、观察执行结果、推断约束和使用模式，并将发现的信息作为增强的API文档存储起来，供未来查询使用。

主要贡献如下：

- •首个用于商用EDA脚本编写的执行落地智能体。我们提出了首个通过沙箱执行在PyAether和SKILL中验证执行反馈的系统，相比静态RAG带来了+43个百分点的准确率提升。
- •面向EDA的离线API自我探索。一种补充机制，通过对未文档化API进行反事实实验，贡献了+3.2个百分点的准确率提升，并将每条轨迹的平均工具调用数减少了22.1%。据我们所知，这是首个在EDA领域主动发现并编码未文档化API行为的机制。
- •EDA-Eval-PyAether：首个面向PyAether脚本编写的公开基准测试。一个包含158个真实世界任务、基于断言执行的基准测试，能够对LLM生成的EDA脚本进行严格评估。完整的ZhuLong系统在该基准测试上达到78.5%的Pass@1。

## 2. 背景与动机

我们针对两种广泛使用的EDA脚本接口：用于华大九天Aether的PyAether[Empyrean Technology, [n. d.]](https://arxiv.org/html/2608.07925#bib.bib10)和用于Cadence Virtuoso的SKILL[Systems,2024](https://arxiv.org/html/2608.07925#bib.bib20)。尽管这两种环境很普遍，但它们各自的脚本编写却带来了超越通用LLM代码生成器能力的挑战，而且社区也缺乏衡量进展的基础设施。

EDA脚本编写从根本上不同。以往关于LLM代码生成的工作在那些通过单元测试验证正确性的领域取得了成功[Chen et al.,2021](https://arxiv.org/html/2608.07925#bib.bib7)；[Austin et al.,2021](https://arxiv.org/html/2608.07925#bib.bib3)。EDA脚本编写则面临三个截然不同的挑战：(i) API是长尾、工具特定且文档匮乏的；(ii) 正确性取决于实时有状态数据库中的副作用，而不是返回值；(iii) 没有现成的基准测试来评估生成的脚本是否真正有效。

以往的工作止步于执行之前。最近的举措如LayoutCopilot[Liu et al.,2025](https://arxiv.org/html/2608.07925#bib.bib14)、ChaTCL[Rui et al.,2025](https://arxiv.org/html/2608.07925#bib.bib19)和RAG-EDA[Pu et al.,2024](https://arxiv.org/html/2608.07925#bib.bib18)将LLM与静态知识库相结合。然而，它们都有一个关键局限：它们不执行生成的代码。正确性是通过人工判断[Liu et al.,2025](https://arxiv.org/html/2608.07925#bib.bib14)；[Rui et al.,2025](https://arxiv.org/html/2608.07925#bib.bib19)或检索质量[Pu et al.,2024](https://arxiv.org/html/2608.07925#bib.bib18)来评估的，而不是根据脚本是否真正修改了版图。因此，错误得不到诊断，“看起来合理”与“实际能用”之间的鸿沟始终无法弥合。

根本问题：没有基准测试，就没有进展。如果没有标准化的基准测试，社区就无法系统性地比较方法或衡量进展——每项先前工作都使用不同的协议和临时任务。最近针对Tcl/Innovus流程的并行基准测试[Xu et al.,2026](https://arxiv.org/html/2608.07925#bib.bib23)；[Li et al.,2026](https://arxiv.org/html/2608.07925#bib.bib13)证实了人们日益认识到这一空白，但它们面向的是不同的工具链。一个专门的PyAether/SKILL基准测试仍然缺失。

我们的方法。ZhuLong通过沙箱执行反馈解决技术挑战——闭环从生成到执行再到修正——并辅以离线API自我探索机制。至关重要的是，我们引入了EDA-Eval-PyAether，这是首个面向PyAether脚本编写的标准化基准测试。这些贡献共同建立了推进基于LLM的EDA脚本编写的方法论和测量基础设施。

## 3. 系统设计

### 3.1. 总体架构

ZhuLong构建于Cline-CLI[Contributors,2024](https://arxiv.org/html/2608.07925#bib.bib8)之上，这是一个开源自主编码智能体框架，并扩展了面向EDA的检索、文档和执行能力。我们选择Cline-CLI是因为其成熟的权限控制、人在回路支持和企业级就绪性。如图1 (https://arxiv.org/html/2608.07925#S3.F1)所示，该系统由三个组件组成：基于LLM的智能体运行时、API知识库和EDA执行环境。智能体通过三个MCP工具与这些组件交互，而离线API自我探索机制在运行时之前预先增强API知识库。

图1. ZhuLong系统架构。智能体通过三个统一的MCP工具与API检索、增强文档和EDA执行交互。离线自我探索在运行时之前增强知识库，执行反馈支持迭代修正。

### 3.2. 三个MCP工具

ZhuLong扩展了三个MCP工具[Anthropic,2024](https://arxiv.org/html/2608.07925#bib.bib2)，每个工具都接受统一的lang参数（pyaether或skill），以相同的智能体逻辑支持两个平台：

- •search_apis(query, lang)：通过语义和关键词搜索检索相关API。我们使用BGE-M3嵌入[Chen et al.,2025](https://arxiv.org/html/2608.07925#bib.bib5)对API的名称和描述建立索引，并使用FAISS[Douze et al.,2024](https://arxiv.org/html/2608.07925#bib.bib9)进行高效的相似性搜索，返回前K个结果（默认K=5），并附带置信度分数和描述。
- •get_api_details(api_name, lang)：获取指定API的完整文档，包括参数类型、返回值和示例。返回的文档在可用时由离线API自我探索机制（第4节 (https://arxiv.org/html/2608.07925#S4)）进行增强，用通过沙箱探索发现的约束和使用模式来丰富不完整的规范。
- •run_code(code, mode, lang)：在EDA环境中执行生成的代码。它支持两种模式：(1) 轻量模式——在无GUI会话的沙箱环境中运行（PyAether使用独立PythonE，Virtuoso使用批处理模式下的SKILL），捕获输出、错误和状态变化以进行迭代修正；(2) 交互模式——通过智能体-EDA桥接（socket通信）在打开的EDA会话内运行，支持对未保存的版图和原理图进行操作。

### 3.3. 智能体工作流

智能体通过执行反馈迭代修正其输出[Contributors,2024](https://arxiv.org/html/2608.07925#bib.bib8)。一条典型轨迹首先对用户指令进行推理，然后在需要时通过search_apis进行API检索。随后通过get_api_details检查候选API，并据此生成代码。智能体通过run_code执行代码，观察结果，然后重新规划——修改代码、检索替代API或终止。这个循环持续到成功，或直到智能体判断进一步尝试不太可能成功。智能体并不受固定顺序的约束；当它已经知道所需的API时，可以跳过检索，或者当初始结果缺乏置信度时，可以执行多轮检索。

## 4. 离线API自我探索机制

EDA工具中的API文档往往不完整，遗漏了参数约束、返回结构和错误条件。先前的工作通过基于检索的增强[Pu et al.,2024](https://arxiv.org/html/2608.07925#bib.bib18)或静态知识图谱[Liu et al.,2025](https://arxiv.org/html/2608.07925#bib.bib14)来解决文档缺口——这两种方法都依赖于已经文档化的内容。当文档缺失时，这些方法无法提供补救。

ZhuLong采用了不同的方法：它不是等待文档存在，而是通过沙箱中的离线反事实实验主动发现API行为。对于每个目标API，自我探索智能体读取任何可用的文档，识别缺口——例如，未指定的参数范围、未文档化的返回字段或模糊的错误语义——并生成有针对性的测试脚本进行探测。它通过run_code执行这些脚本，观察结果，并迭代修正关于该API接受什么、返回什么的假设。探索智能体根据其当前置信度自主决定接下来测试什么以及何时停止。

具体来说，探索智能体构建反事实假设——例如，某个参数是否接受空列表、数值参数是否允许负值、或者返回值是否包含某个特定字段——并设计最小测试用例来验证每一个假设。执行结果（成功、错误、异常或意外的返回结构）揭示了实际约束。经过多轮迭代，智能体为每个API构建行为模型，捕获参数约束、返回结构、错误条件和副作用。

这个离线过程对每个API运行一次；增强后的文档存储在API知识库中，并在运行时通过get_api_details提供，不产生运行时开销。最终得到的文档比官方来源中的内容更完整，并且直接反映API的实际行为，而不是其预期或假定的行为。

## 5. 基准测试构建

### 5.1. 数据集：EDA-Eval-PyAether

为了评估基于LLM的PyAether代码生成，我们构建了EDA-Eval-PyAether，一个包含158个任务的基准测试。任务来自四个来源：API参考（61.4%）、文档示例（27.2%）、内部培训材料（7.6%）和脱敏的CAD实际案例（3.8%）。每个任务都经过EDA领域专家的人工审核。

表1 (https://arxiv.org/html/2608.07925#S5.T1)显示了不同EDA场景下的任务分布。版图和原理图操作占大多数（70.2%），反映了PyAether在物理设计工作流中的核心用途。

表1. 按场景的任务分布

### 5.2. 评估协议

每个任务由一个自然语言提示、一个函数签名和基于断言的测试代码组成。如果生成的代码在PyAether沙箱中无错误执行且所有断言通过，则该任务视为通过。主要指标是Pass@1[Chen et al.,2021](https://arxiv.org/html/2608.07925#bib.bib7)：

\text{Pass@1}=\frac{\text{所有断言通过的任务数}}{\text{总任务数}}\times 100\%

## 6. 实验

### 6.1. 实验设置

#### 6.1.1. 研究问题

本评估旨在回答四个研究问题：(RQ1) 沙箱执行相比静态生成是否能提高代码生成的准确率；(RQ2) 自我探索机制除了沙箱执行之外，是否在准确率和效率方面都带来可衡量的收益；(RQ3) 对于API发现，基于向量的检索是否优于基于grep的关键词搜索；(RQ4) 不同的索引构建策略如何影响检索效果。

#### 6.1.2. 基准测试与评估协议

我们在EDA-Eval-PyAether上评估ZhuLong，这是一个包含158个真实世界PyAether脚本编写任务的基准测试。按照第5节 (https://arxiv.org/html/2608.07925#S5)定义的评估协议，我们采用Pass@1（执行成功率）作为主要指标。在评估过程中，智能体在每个任务上被允许最多2轮重新规划（即最多三次完整运行），遵循第3.3节 (https://arxiv.org/html/2608.07925#S3.SS3)所述的自我修正循环；超时为s。