用 NeMo Gym 验证 EDA Agent：从 Liberty 文件到工具接口改进
摘要
通过 NVIDIA 与 Siemens 的标准单元表征案例，解释如何用最终 Liberty 文件验证定位 Agent 错误，再改进技能和 MCP 工具描述。区分复合评分、开发任务规模与生产泛化边界。
用 NeMo Gym 验证 EDA Agent：从 Liberty 文件到工具接口改进
全文概览
芯片设计中的 Agent 会调用仿真和文件处理工具，最终交付供后续设计使用的模型文件。上游配置出错后，流程仍可能生成格式合理的结果。判断一次长任务是否完成，需要检查最终产物与预期任务之间的关系。
NVIDIA 与 Siemens 的工程案例把验证器接入标准单元表征流程，再根据失败轨迹修改技能和工具描述。它提供了一条明确的优化路径：固定任务与模型，检查交付物，定位错误传播，再修改 Agent 与工具之间的接口。文中的定量结果属于作者开发评测，不能直接当作所有芯片设计任务的完成率。
这篇文章的原始发布时间为 2026 年 10 月 14 日 16:10 UTC，即北京时间 10 月 15 日。下图给出输入、表征、扩展执行与输出之间的关系。
图中先对代表性单元做试运行与验证，再扩展执行，随后生成并比较 Liberty 文件。底部反馈路径把输出中发现的问题送回配置阶段。图中的 229 个单元表示完整数据集规模，后文调优结果来自其中两个单元的任务。
打开图1高清原图。横向流程图在手机上建议放大查看。后文按输入约束、验证机制、评测条件和可复用做法展开。
背景与约束
电子设计自动化（Electronic Design Automation，EDA）需要在不同工艺、电压和温度条件下描述逻辑单元的行为。这些条件通常合称 PVT，即 Process、Voltage、Temperature。标准单元表征把电路仿真结果整理成时序、功耗等模型，Liberty 的 .lib 文件是该流程的重要输出。
这类任务有多阶段依赖。一次配置会影响后续仿真及数据汇总，遗漏某个单元或工作条件也可能到交付时才暴露。本文分析认为，任务契约至少应说明预期对象、条件组合、输出格式和数值容差，才能区分完整交付与部分成功。
Siemens 产品说明将 Agent Skills 定义为承载领域流程的可执行操作规程，并通过领域工具和解析器连接设计系统。这解释了案例中的两类可修改对象：技能约束执行顺序，工具接口约束每一步能接收和返回什么。
整体方案与关键变化
NeMo Gym把环境组织成任务数据、Agent 执行框架、验证器与任务状态。对这篇案例来说，仿真器完成物理计算，Agent 组织工具调用，验证器判断结果是否满足交付要求。三者承担不同职责。
一次优化迭代先从干净状态运行任务，保留模型消息和工具轨迹，再把最终文件交给验证器。开发者沿着失败结果追查错误发生在哪个阶段，修改技能和工具描述后重跑相同任务。原文明确这是有人参与的工程优化流程，不能据此推断模型已自主完成递归自我改进。
改动还包括简化重叠的文件与 shell 接口，以及用明确的 JSON Schema 描述工具输入。本文分析认为，当多个工具看起来都能完成同一操作时，清楚划定输入、输出和副作用，能让失败更容易定位，也更便于比较修改前后的行为。
关键机制与实现
验证器把完整性门槛和数值质量分开。原文使用四个门控条件，再乘以落在容差内的预期数值占比：
这是原文奖励定义的文字化表达。任一门控失败，奖励归零。各项检查的含义如下。
检查项 | 要确认的问题 |
|---|---|
Coverage | 预期单元和 PVT 条件是否齐全 |
Validity | 文件能否被验证工具正确解析和使用 |
Relative validation | 相比参考产物是否新增失败 |
Accuracy | 预期时序、功耗数值中有多少落在容差内 |
Integrity | 是否真正生成完整结果，避免复用、截断或改写已有数值 |
例如，若只检查已写出的行有多少正确，遗漏输出可能让分数虚高。本文分析建议把预期集合放在任务契约中，由验证器独立读取，再检查结果的覆盖范围。这样，Agent 不能通过少交一部分内容缩小评分分母。
下图把验证器与修改接口的路径放在一起。
上方路径负责生成并验证文件，下方路径利用轨迹分析更新技能和 MCP 定义。模型上下文协议（Model Context Protocol，MCP）在这里提供工具连接方式，任务是否完成仍由领域验证器判断。
打开图2高清原图。关键关系是最终文件进入验证器，诊断结果再影响下一轮工具调用方式。
证据与工程代价
作者使用 GF180MCU 工艺设计套件（Process Design Kit，PDK）建立任务，以 Claude Opus 4.8 和 Claude Code 固定模型及执行框架。完整数据集包含 229 个标准单元、36 个 PVT 条件，实际调优每次限制为两个单元与 36 个条件，约做了 25 次 rollout，每次约 1.5–2 小时。
开发评测中的平均复合验证分数约从 55% 提至 95%，Agent 轮次从 155 降至 53，输出 token 约从 81K 降至 29K。这里的 95% 是复合评分，不能解释为 95% 的生产任务已经正确交付。原文也没有在这篇文章中给出独立复现实验或所有条件下的置信区间。
官方 Quickstart展示了任务 rollout、聚合指标与运行输入分别保存的方式。工程复用时，应同时保留输入版本、任务状态和评分依据，才能判断分数变化来自接口改进、任务变化还是验证器变化。
局限与适用边界
这个案例支持最终产物验证驱动的流程调优，但结果范围仍是小规模开发任务。文章没有逐项拆分每个技能或接口修改的独立收益，也没有证明相同改动在全部单元、不同工艺或其他模型上保持效果。读者可以复用评测结构，跨任务收益仍需重新测量。
成本也来自完整流程：仿真、参考产物准备、工具执行和人工诊断都要计入。NeMo Gym 提供环境组织与评测基础设施，复现该案例还需要相应的 EDA 工具、PDK 和可信参考结果。
验证器本身同样需要审查。覆盖集合写错、容差过宽或参考产物包含缺陷，都可能影响分数。对风险较高的交付，应让评分依据与产物一起保留，便于独立复核。
可验证的启发
以下是本文分析提出的两种尝试，尚未在本文中执行。
第一，给已有 Agent 加一个独立交付检查器。选择一个经常出现部分完成的任务，明确预期文件或对象集合，并保留缺项、重复和数值偏差的负例。先验证检查器能识别这些已知错误，再观察它是否暴露过去被工具成功状态掩盖的问题。
第二，把工具接口修改当作受控实验。固定模型、任务、验证器与预算，每轮只改一处容易混淆的接口描述，比较最终产物分数和每次成功交付的资源消耗，再用未参与调优的任务检查迁移。如果开发分数上升而留出任务下降，应暂停继续推广这项修改。
参考资料
NVIDIA：Optimizing Agent Reliability and Tool Calling Efficiency for Chip Design Using NVIDIA NeMo Gym，原始工程案例、Figure 1–2 与开发评测。
NVIDIA NeMo Gym，环境定义与评测框架，查阅于 2026-10-15。
NeMo Gym Quickstart，Main 文档，查阅于 2026-10-15。
Siemens Fuse EDA AI Agent，领域技能、工具连接与部署范围说明。