003 · AI Agent 真能走完 RTL-to-GDS 吗？

核心问题：一个 Agent 能否完成 RTL-to-GDS，究竟主要取决于模型知道多少，还是取决于整个系统如何限制、保存和验证它的行动？

论文卡片

• 原题： Can AI Agents Really Complete RTL-to-GDS? Lessons from Benchmarking Tool-Interactive EDA Workflows
• 作者： Jinyuan Deng、Zhengrui Chen、Xufeng Wei、Tianyu Xing、Chenyi Wen、Qi Sun、Cheng Zhuo。
• 机构： 浙江大学、ChipFlux。
• 版本： 2026-07-23，arXiv v3；分类为 cs.AI、cs.AR、cs.LG。
• 定位： Agentic EDA 的实证案例研究，评测长流程、工具交互式芯片设计。
• 阅读入口： alphaXiv · arXiv · 免费全文 · PDF

论文讲了什么

论文固定 PicoRV32 RTL，在商业 55 nm 工艺环境中设置 350 MHz 和 700 MHz 两个目标，让 Agent 依次完成综合、布局规划与电源规划、布局、时钟树综合、布线、物理 ECO 和最终报告。作者比较三种架构：通用命令行 Agent、加入 EDA Skills 的同类 Agent，以及通过结构化接口保存工具会话和设计状态的 FluxEDA；每种架构分别配合四个基础模型。

评测不只看最终结果，还看阶段是否完成、面积、功耗、setup／hold 时序、运行时间、模型成本和 Token ROI。阶段之间采用门控：前一阶段没有完整通过，后续结果不能被当成有效最终设计。

主要结果

三种架构的所有运行都完成了综合，但后续差异明显。在每种架构的 8 个“模型 × 时钟目标”组合中：

• 通用命令行 Agent 完成物理实现 7/8 次，完成 ECO 3/8 次；
• 加入 EDA Skills 后，分别只有 3/8 和 2/8 次；
• FluxEDA 两个阶段都是 8/8 次。

错误分析中，工具版本、运行模式和设计状态相关的 Tcl 兼容问题，占观测到的物理实现错误事件的 31.7%。作者据此认为，领域知识可以告诉 Agent 大致该做什么，却不能保证某条命令在当前工具状态下合法。

证据边界

这项研究只使用一个设计、一种工艺设置、选定的商业工具版本，而且每个配置只运行一次。因此，它能展示具体工作流中的失败模式，却不足以给模型或架构作普遍排名。FluxEDA 与命令行架构提供的行动空间也不同：结构化接口既可能提升系统可靠性，也可能使任务本身更容易。论文结果支持“接口与状态管理很重要”，但尚未分离其中每项机制各自贡献多少。

重点读哪里

先读 §2.2，理解“语法正确但操作非法”的区别；再读 §3.2–3.3，确认三种架构获得了什么能力、分数如何门控；最后读 §4.3–5.3，看阶段失败如何导向作者关于系统级能力的结论。

思考启发

以下是导读者由论文引出的理解角度，不是论文新增结论。

这篇论文改变了“Agent 能力”的归属方式。若同一个模型更换执行架构后，分数相差数十分，那么能力就很难被视为模型的固定属性。它更像一个关系属性：模型只有在特定接口、状态表示、反馈和约束之中，才表现出某种能力。

但这也带来新的测量难题：当一个接口提前排除了大量错误行动时，系统是真的更聪明了，还是评测者重新定义了它可以做什么？可靠性提升与问题简化之间并没有天然清晰的边界。

三个思考问题

1. Agent 的“能力”应该归属于模型，还是模型与环境组成的系统？

如果同一个模型在开放 Shell 和结构化接口上表现悬殊，哪一种结果更能代表它的真实能力？

2. 排除非法操作是在增强 Agent，还是在降低任务难度？

如果接口让版本不兼容的 Tcl 命令根本无法被调用，这证明了更好的推理，还是更好的问题定义？

3. 一次成功可以支撑“可靠完成”的结论吗？

每个配置只有一次运行时，如何区分架构带来的稳定性与一次采样的偶然结果？