给 AI Agent 一份原理图，提出需求，它就可以完成从代码编写、Vivado编译、仿真、实现到 Debug，最终生成 bit 文件的全流程。借助Agent的能力，其他嵌入式开发也能达到类似的效果。

但，如果有一天 Vivado 或Cadence等EDA工具的版本更新了，桥接EDA和AI的底层 TCL 脚本的使用规则发生变化，那么再聪明的 通用AI Agent，可能也无法正常调用这些设计工具完成最终的任务了。

提这个假设我是想引出的是，“垂直 Agent”的产品。

毕竟，当前Codex、Claude Code，以及国内的 WorkBuddy、Kimi Work 等这类通用AI Agent开发起嵌入式工程都已经很顺手了。而且通用 Agent 的妙处就在于通用，前端后端、办公杂务，样样来得，像村口的王师傅，剃头修脚配钥匙，一铺全包。所以好像没必要为所谓的垂直领域做出单独的Agent吧。

问题就在于垂直领域的工程交互命脉掌握在传统 EDA 工具上。

当前通用 Agent 之所以能够获得特定领域EDA的工作能力，很大程度上建立在专业 EDA 工具开放了足够成熟、稳定的接口之上。例如，vivado和Cadence的A是因为有TCL脚本，这种脚本的交互形式AI工具最喜欢了。但这纯属巧合，因为这些TCL脚本其实并不是为AI Agent原生打造的。借用这些接口进行AI化工作，能跑，但低效且低能。因此，通用 AI Agent 虽然具有很强的通用能力，但在进入特定专业领域后，依然会受到专业 EDA 工具接口的约束。这其实就是通用 Agent 的一个软肋。

但反过来看，EDA 厂商的软肋可能更明显。

EDA 厂商本质上仍然是传统的软件工具厂商。他们压根不具备AI这个聪明的大脑。想把自己的护城扩宽难不成EDA 厂商要训练属于自己的垂直大模型？

好像也有厂家真的在做。但我的看法是，至少从目前来看，EDA 厂商完全没有必要重新训练一个通用意义上的大模型。

首先，是钱的问题。训练一个通用大模型需要巨大的算力、数据和资金投入，这并不是EDA 厂商最擅长的事情。EDA 厂商真正的核心竞争力，是几十年积累下来的 EDA 工程经验。

其次，是胜算的问题。很多事实也表明，垂直大模型的能力并不一定会长期领先于通用大模型。通用大模型的迭代速度非常快。即使现在训练出一个针对细分领域的模型，它在某些任务上具有优势，但下一代通用模型也可能凭借更强的训练数据、更强的推理能力、更大的上下文窗口以及更完善的工具调用能力，很快超过它。以 Verilog 代码生成领域为例，VerilogEval 等团队的对比研究已经表明，通用大模型本身已经具备相当不错的 Specification-to-RTL 能力。

欧阳修笔下的卖油翁说得好：无他，唯手熟尔。让一家传统 EDA 厂商杀入基础大模型领域，好比让巷口卖了三十年烧饼的老师傅改行去炼钢——烧饼是真的香，高炉也是真的烧钱，炼出来的钢还未必比得过专业钢厂的下水料。

因此，我更倾向于认为：EDA 厂商没有必要重新“制造一个大脑”。

那么问题的症结就在于：

通用 AI Agent 缺少传统 EDA 工具所积累的专业工程能力；而 EDA 厂商又缺少大模型本身的智能能力。

两者到底应该如何结合？

以非专业人士的视角来看，我对 Agent 的理解很简化：

Agent = 大模型 + 工具 + 编排。

其中，大模型负责理解和推理；工具负责执行；编排则负责决定先做什么、后做什么，以及出现错误之后如何处理。

大模型决定了 Agent “聪不聪明”，但它能不能在某个特定领域表现得更好，很大程度上取决于它能调用什么样的专业工具，以及它在使用这些工具出现错误之后，能不能正确迭代，套用成熟明确的工程经验。

还是以 FPGA 开发为例。如果出现时序违例，普通通用大模型当然知道存在 Timing Violation，也知道应该查看时序报告、然后修改 RTL 或相关约束。但它通常只能是基于既有的语料和经验给出一个相对通用的解决方案。而且往往需要消耗大量的Token和试错成本，整体效率偏低。就像个江湖郎中，医德是有的，把脉也把得认真，就是一副药开八十味，吃不死人，见效慢，药钱还贵。

如果 Agent 与 EDA 工具进行了更深度的结合，那么当发现时序违例之后，它就可以从工具底层快速知道，时序报告路径、对应错误路径官方的解决方案、获知调用EDA工具哪些能力可以优化时序，约束文件该用什么格式。高效，准确，省token，省时间。同样是看病，这回直接进了手术室，主刀的还是本院院长。

因此，如果能够把 EDA 工具底层已经积累几十年的工程能力，以 API、MCP、Skill 等形式开放出来，让通用大模型可以直接调用。即，通用Agent 提供 AI 能力，而 EDA 厂商提供专业领域的工程能力。

我认为这是一种更加理想、高效工作形态。

事实上，现在主流 EDA 厂商都开始向这个方向探索。例如 ，群里多个同行就透露，AMD 已经在vivado 2025.2中加入 AI 辅助能力，探索基于 MCP 的知识库接入方式。当然，Lattice 也有类似产品在推出。

我查阅了官方资料，AMD确实采用了 MCP +SKILL+ Knowledge Grounding 的方式把 Vivado 的专业知识和 AI Agent 结合起来。流露出的6月30日的技术文档显示，他们实现的形式是VS Code + Vivado AI Assistant的架构。这种轻量又实在的方式实在令人期待。

AMD/Xilinx 自己的 GitHub 上已经有 AI-assisted Vitis 示例。

通用 Agent 端也不甘示弱啊。风头正热的Deepseek Harness其实就有意打造一个开源的通用Agent架构，任何垂直场景的应用都可以用它的agent架构+插件实现垂直化的Agent能力。虽然这些能力目前还处于比较早期的阶段，但方向已经非常明确。

当然，现实情况也没有这么简单。从商业角度来看，EDA 厂商并不一定愿意把所有专业能力都开放给外部 Agent。工具、数据、算法以及长期积累的工程经验，是人家的传家宝，是后续软件和服务收费的命根子。一些 EDA 厂商就更倾向于自己构建封闭的垂直 Agent，甚至进一步训练自己的垂直模型。例如 Cadence 已经推出了 ChipStack AI Super Agent，这代表了一种更加垂直、一体化的路线。肥水不流外人田，连田埂都砌高了三尺。

所以，现在其实存在两种不同的思路：

一种是 EDA 厂商自己重新造轮子，想把自研模型，工具和工程能力全部整合在自己的体系里。另一种则是打不过就加入，EDA 厂商自己提供 Skill、MCP、API 等接口，将自身积累的专业工程能力开放给通用 Agent，让通用大模型负责理解和推理，EDA 工具负责提供专业执行能力。

这两种方式目前都不能简单地说谁对谁错。但有一点是可以确定的：硬件开发，以及更广泛的传统工程开发，其开发范式都正在被AI Agent变化。老师傅们手里那把用了半辈子的刀，不管愿不愿意，迟早都要换个握法。刀还是那把刀，只是握刀的手，往后未必还是人的手了。