别把 EDA 工具重写一遍#

模拟 IC 工具链已经足够复杂。Virtuoso 里有原理图、版图、cellview、SKILL、ADE、Spectre、工艺环境和大量项目约定。想在外部重新做一套完整替代品，成本很高，也很容易偏离工程师实际使用路径。

virtuoso-cli 选择的方向更现实：保留 Virtuoso 作为权威执行环境，在外部提供一个 CLI 入口。

它的大致链路是：

1
terminal / agent -> vcli -> Rust daemon -> Virtuoso SKILL evalstring

外部命令不直接去碰数据库，而是通过 Virtuoso 里加载的 bridge 把 SKILL 代码送进去执行，再把结果整理成 CLI 能读的结构。

这层桥接的好处很直接：自动化可以沿用已有 Virtuoso 环境，不用另起一套假想流程。

Session 是第一等概念#

EDA 服务器上经常不止一个 Virtuoso 实例。一个人在跑调参，另一个人在开版图，后台还有仿真任务。如果外部 CLI 只认一个固定端口，很快就会遇到冲突。

virtuoso-cli 把 session 做成第一等概念：

• 每个 Virtuoso 实例有唯一 session ID。
• daemon 绑定动态端口，减少固定端口冲突。
• session 文件记录活跃实例。
• 单 session 时可以自动连接。
• 多 session 时必须显式选择，或通过环境变量指定。
• 死掉的 daemon 对应的 stale session 会被过滤。

这套设计看起来偏基础设施，但它是 agent 介入 EDA 的前提。没有明确 session，自动化命令就不知道自己会改哪个 Virtuoso 窗口。

CLI 要对人和 agent 同时友好#

传统 CLI 只要人能看懂就够了；面向 agent 的 CLI 还要能被程序稳定解析。

virtuoso-cli 公开文档里强调了几件事：

• noun-verb 命令结构。
• JSON 结构化输出。
• schema 自省。
• 语义化退出码。
• 命令历史和 SKILL 执行日志。

这些特性对人也有用，对 agent 更是基础。agent 不能靠猜终端里的自然语言来决定下一步，它需要明确知道命令是否成功、失败类型是什么、参数有哪些、结果怎么解析。

所以我更愿意把 EDA 自动化理解成接口整理，而不是简单录一遍 GUI 操作。

原理图编辑要可读也要可写#

很多工具会先做“生成原理图”，但我更在意它能不能读回现有设计。

工程里经常要先查实例、网络、引脚和参数，再决定怎么改。你要确认自动放置和连线有没有符合预期，也要在修改前知道当前 cellview 的状态。

virtuoso-cli 把 schematic 能力拆成创建、放置、连线、连接，也包括读取 instances、nets、pins、parameters。这种双向能力更适合工程自动化：

• 先读当前状态。
• 再做最小修改。
• 然后保存、检查或构建。
• 最后把结果和日志交给人确认。

这比“生成一整张新图覆盖旧内容”稳得多。

仿真任务必须能异步追踪#

Spectre 仿真不是一个普通的瞬时命令。它可能跑很久，可能失败，可能产生大量结果文件，也可能需要在远程服务器上执行。

如果 CLI 只能同步等待，体验会很差；如果异步启动后没有 job registry，系统又会丢失状态。

virtuoso-cli 的公开设计里有异步仿真、job 列表、job 状态、取消任务和结果解析。这些能力让自动化流程更像工程系统，而不是一次性脚本：

1
run async -> get job id -> poll status -> parse result -> export evidence

对 agent 来说，这一点尤其重要。长任务不能光返回“我开始跑了”，还要能在后续步骤里找回状态。

远程模式要进主流程#

很多 EDA 环境天然是远程的：License、PDK、仿真服务器和项目数据都可能在 Linux 机器上。开发者可能在本地终端、远程 shell、跳板机或 agent 工作区之间切换。

远程模式最好从架构阶段就考虑进去，别等到最后靠文档补一段临时用法。

virtuoso-cli 支持本地直连和 SSH tunnel，并提到 ControlMaster 连接复用、多 profile、远程 Spectre 命令配置。这些能力对应的是现实工作流：一个人可能同时连多个 Virtuoso 实例，也可能在不同项目环境之间切换。

做这种工具时，远程连接的可诊断性和可恢复性比“能连上一次”更重要。

日志要能回放现场#

EDA 自动化最怕不可追溯。尤其当工具能修改原理图、设置 ADE 变量、启动仿真时，每一步都应该能回看。

命令日志、session 历史、SKILL 执行记录和 job 状态，出问题时都派得上用场。它们能回答几个具体问题：

• 哪个 session 执行了命令。
• 执行的是哪段 SKILL。
• 命令什么时候失败。
• 仿真 job 是否还活着。
• 结果是从哪里导出的。

如果没有这些证据，自动化一旦出错，人只能回到 GUI 里猜。

agent 进入 EDA 的范围#

我不认为 agent 应该直接拥有无限制修改 EDA 项目的能力。更合理的方式是通过受控 CLI 进入：

• 命令有明确 noun 和 verb。
• 输出是结构化的。
• 失败码可解释。
• session 必须可选择。
• 写操作可以先 dry-run 或检查。
• 关键修改留下历史。

这样 agent 能做大量重复工作，例如读 schematic、批量设置变量、启动仿真、导出结果、整理日志；但它仍然被桥接层的范围约束住。

我最想记住的是这一点：它没有把 EDA 包装成聊天入口，而是把适合自动化的部分收束成可审计的 CLI。

更现实的自动化路线#

做 EDA 自动化时，我觉得更现实的路线是把老工具里已经可靠的能力接到现代工作流里：

• CLI 让人能批处理。
• JSON 让程序能解析。
• session 注册让多实例不混乱。
• tunnel 让远程环境可达。
• job registry 让长仿真可追踪。
• 日志让修改可回看。

这套设计承认 Virtuoso 本身很复杂，所以只在外面补一个稳定入口。

对我来说，virtuoso-cli 的启发很直接：工程自动化不一定需要另一个炫技平台，先把现有工具、脚本和 agent 接清楚，很多事就已经能推进了。