ARTICLE · 1103958
AI Agent时代的显性软件卡点:EDA、CAD、PLM与工程仿真
AI Agent时代的显性软件卡点:EDA、CAD、PLM与工程仿真上一篇文章里，我把 AI Agent 对软件行业的影响理解为一次价值迁移：当人越来越少直接操作软件以后，界面和大量功能的价值可能下降，而工作流、企业上下文、权限和控制层的重要性可能上升。 但这套框架里，还有一类软件值得单独拿出来讨论。 它们的特殊之处不是“比其他软件更有护城河”，也不是“AI 一定最先给它们带来业务增量”，而是它们的卡点更加显性。 所谓显性，是指我们今天已经比较容易回答这样一个问题： AI 完成工作以后，最终还要不要经过这个软件？ 在芯片设计、机械设计、建筑工程、产品生命周期管理和工程仿真里，这个答案往往比较明确。 一颗芯片不能因为大模型认为设计“差不多正确”，就直接 tape-out；一栋建筑也不能因为 Agent 生成了一套看起来合理的方案，就跳过结构计算、工程模型、法规检查和正式施工文件；一台机器更不是生成一张效果图以后就完成了，它还要进入正式的 CAD、BOM、PLM、仿真、制造和版本管理体系。 所以这一类软件的核心问题不是“AI 会不会使用它”，而是： AI 做完前面的工作以后，最后是不是仍然要回到这里。 这就是我所说的“显性软件卡点”。 
但显性并不意味着更早兑现。 恰恰相反，办公室里的 Agent 很可能比工业世界里的 Agent 更早普及。让 AI 帮员工整理邮件、更新 CRM、做会议纪要，远比让 AI 真正参与芯片、汽车、飞机、建筑和工厂设计容易。 工业世界还牵涉物理约束、安全责任、认证标准、制造流程，以及大量已经运行多年的旧系统。 因此，显性软件卡点有一个很有意思的特征： 它更容易被理解，但真正大规模进入 Agent 工作流，可能需要更长时间。 这和下一篇准备讨论的“隐藏软件卡点”恰好相反。后者看起来没有 EDA、CAD 那么“硬”，却可能随着办公室 Agent 普及更早进入真实应用。
如果今天问： Salesforce 到底是不是 Agent 时代不可绕过的软件？ 这个问题其实并不好回答。 CRM 里的客户记录当然重要，但未来 Agent 是否一定要通过 Salesforce 的交互层？数据和工作流会不会被新的 Agent 平台重新组织？过去按照用户数量设计的软件模式又会发生什么变化？ 这些问题仍然存在很大不确定性。 但如果换一个问题： 一颗先进芯片最终是否还需要 Timing、Verification、Physical Design 和 Signoff？ 答案就清楚得多。 或者问： 一台真正要生产的机械设备，最终是否仍然需要正式的 Geometry、BOM、Revision、Simulation 和 Manufacturing Data？ 同样比较容易回答。 所以这里所说的显性软件卡点，本质上是一类因现实世界交付要求而形成的软件节点。 它们往往处在这样一条链条的后半段： AI 生成方案 → 工程化 → 验证 → 正式版本 → 制造 / 施工 / 交付。 越接近真实交付，软件为什么存在就越容易理解。 当然，这不意味着某一家软件公司永远不会被替代。 未来完全可能出现新的 CAD、新的 Solver、新的 PLM，也可能出现从一开始就为 Agent 设计的新一代工程软件。 真正难消失的，是这一层需求本身： 现实世界仍然需要正式工程对象、确定性验证和责任追踪。
因为工业世界对“正确”的要求，与办公软件完全不同。 办公室 Agent 写一封邮件，哪怕措辞不够准确，用户可以修改；整理一次会议纪要，即使遗漏了一句话，多数情况下也不会带来不可逆的结果。 工业世界则不同。 芯片设计出现关键错误，可能意味着昂贵的重新 tape-out；机械结构错误可能影响产品可靠性甚至安全；建筑工程错误可能直接传导到施工；汽车、医疗设备和航空航天还涉及大量法规、认证和责任问题。 所以 AI 从数字内容进入工业世界以后，会遇到一个根本问题： 概率上“看起来合理”，并不自动等于工程上“可以交付”。 从语言模型的生成结果到真正的现实产品，中间必须加入大量确定性的东西，包括设计规则、工程约束、数学求解器、仿真、验证、正式数据结构和审计记录。 因此工业软件和普通生产力软件不能简单类比。 AI 很可能首先改变工程师“怎么完成工作”，然后才慢慢改变“用什么系统完成工作”。
如果要找一个最容易理解的例子，我认为还是 EDA，也就是 Cadence 和 Synopsys 所在的领域。 现在 AI 已经不只是给 EDA 软件加一个聊天窗口。 Agent 已经开始参与 RTL 生成、Verification、Debug、Physical Design、PPA Optimization 等工作。 表面上看，这似乎会产生一个疑问： 既然 Agent 自己能够做越来越多芯片设计工作，那么 EDA 软件的重要性是不是会下降？ 但今天看到的路径恰恰更接近相反方向。 Agent 越能自主设计，就越需要不断调用底层的 Verification、Simulation 和 Signoff 工具，判断自己生成的结果到底对不对。 过去的关系更接近： 工程师 → EDA 未来则可能逐渐变成： 工程师 → Agent → EDA 真正发生变化的是软件的操作者。 底层承担工程验证的系统并没有因此消失。 甚至可能出现一个很反直觉的结果。 过去一个工程师受限于时间，只能探索几十种设计方案；未来 Agent 可以在后台尝试成千上万种设计组合。那么 Simulation、Verification 和 Optimization 的总调用量，反而可能增加。 因此 EDA 的 AI 逻辑并不仅仅是： “它不会被替代。” 更值得关注的是： 设计成本下降之后，设计探索量是否会上升，并进一步增加验证工作。 
这也是为什么观察 Cadence，不能只看它有没有推出 AI 功能。 真正重要的是 AI 正在进入 EDA 工作流的什么位置。 如果 AI 只是帮助工程师查文档、生成代码，那仍然只是传统软件上的一个辅助层。 但如果 Agent 开始参与 RTL 生成、验证、物理设计和优化，就意味着 AI 正在真正进入工程生产流程。 这里出现了一个很重要的变化： 过去 EDA 的主要用户是工程师。 未来，Agent 本身也可能成为软件的重要使用者。 这会改变软件使用量和工程效率之间的关系。 以前增加一个用户，意味着增加一个 Seat。 以后可能不再这么简单。 一个工程师背后可以运行多个 Agent，而这些 Agent 会持续调用底层工具。 因此以后判断 EDA 公司 AI 进展时，我觉得不能只看： “推出了多少 AI 功能。” 更应该看： Agent 到底承担了多少真实工程任务，以及这些任务有没有增加底层 EDA 引擎的使用强度。
Synopsys 的变化又稍微不同。 在引入 Ansys 之后，它已经不再只是传统意义上的 EDA 公司。 Ansys 带来的结构、流体、电磁、热力学和多物理场仿真能力，让 Synopsys 的覆盖范围开始从芯片逐渐延伸到完整系统。 这件事放到 Agent 的长期发展里看，会非常有意思。 因为 AI 最终设计的不会只是一颗孤立芯片。 机器人、汽车、服务器、航空航天设备，本质上都是芯片、机械、热管理、电磁、软件和材料共同组成的复杂系统。 未来 Agent 可以帮助优化芯片，但一个真实产品还需要回答更多问题： 散热是否足够、结构能否承受、不同组件是否相互干扰、系统在不同环境下是否稳定。 所以未来工业 Agent 面临的“正确性”，不会只是逻辑正确。 而是整个系统在物理世界里能否工作。 从这个角度看，Synopsys 正在尝试把自己的位置从： Chip Completion 延伸到： System Completion。 这条路线值得持续观察，因为如果 AI 真正进入复杂产品研发，芯片设计和系统仿真之间的边界可能会越来越模糊。
EDA 的卡点比较容易理解。 而 Autodesk、PTC、Bentley Systems、Dassault Systèmes 这批软件面临的问题要复杂得多。 因为这里同时存在两个方向相反的变化。 一方面，AI 的确可能减少很多传统设计工作。 如果过去十名工程师才能完成的任务，未来三名工程师加 Agent 就可以完成，那么传统按照人类用户设计的软件模式必然需要调整。 而且 AI 会明显降低 CAD 的操作门槛。 大量菜单、快捷键和复杂命令，本质上都是把人的意图翻译成软件操作。 未来用户完全可能直接说： “把重量降低15%，但保持原来的强度约束。” 然后让 Agent 完成大量底层操作。 所以 UI 的价值下降是真实的。 但与此同时，AI 也可能大幅增加设计活动本身。 过去一个项目因为人力和时间有限，也许只能探索十种方案；未来 Agent 可以自动探索一千种。 过去一个零件可能只做几十次 iteration，未来可以在后台尝试数千次。 所以 CAD 和 PLM 真正的矛盾并不是： AI 会不会减少工程师。 而是： 工程师减少以后，机器产生的工程活动究竟会增加多少？ 如果人类操作减少，但设计、修改、验证和协作的总量大幅增加，那么工程软件承担的角色可能发生变化，而不是简单缩小。 
Autodesk 是这个变化里很典型的案例。 如果未来 Agent 可以生成 CAD、自动修改建筑设计，并帮助工程师完成大量重复操作，那么过去依赖人类直接操作界面形成的一部分价值必然会下降。 但 Autodesk 控制的并不只是界面。 它还涉及正式的 Geometry、BIM 模型、项目数据、协作关系，以及设计向施工和制造环节的衔接。 所以 Autodesk 长期真正需要回答的问题，不是： “AI 会不会画图？” 这个问题未来可能越来越不重要。 真正重要的是： AI 画完以后，正式设计最终保存在哪里？ 如果 Agent 生成一百个建筑方案，真正重要的不是一百张效果图，而是哪一套方案最终进入 BIM 模型、经过工程协调，并进入施工体系。 机械设计也是一样。 Agent 可以生成很多可能的零件，但最终仍然要形成正式 Geometry、工程参数、制造数据和版本记录。 因此 Autodesk 未来需要完成的转变可能是： 从帮助“人操作软件”，逐渐转向帮助“人和 Agent 共同完成工程工作”。 这会对它的产品结构、平台位置和收费方式提出新的要求。
PTC 如果只看 Creo，也可以放在 CAD 的逻辑里讨论。 但我认为它真正值得关注的部分，其实是 PLM。 Windchill 所管理的已经不是单纯： “这个零件怎么画。” 而更接近： 这个产品到底是什么。 一台工业设备从设计到运行，可能经历设计修改、BOM 更新、供应链替换、制造、安装、维修、零部件更换和软件升级。 二十年以后，这台现实设备的真实状态可能已经和最初图纸差别很大。 未来如果 Agent 真正进入工业环境，帮助企业维修设备、优化工厂、自动采购零件甚至修改设计，它必须知道： 设计系统记录了什么、生产系统实际制造了什么、维修过程中又改了什么，以及今天现实世界里的这台设备到底是什么状态。 这其实是一种非常特殊的企业记忆： Product Memory。 上一篇文章讨论过 Enterprise Memory。 在工业世界里，PLM 记录的则更像是一个产品贯穿整个生命周期的“记忆”。 所以 PTC 的长期卡点未必只是 Creo 这个 CAD 软件本身。 更重要的可能是： 谁能够持续维护产品的 Digital Thread。 如果工业 Agent 真正进入制造业，这层信息可能会成为 Agent 理解现实设备的重要上下文。
Bentley Systems 又是另外一种形态。 它面对的是道路、铁路、桥梁、水务、能源和大型基础设施项目。 这些领域有一个很突出的特点： 生命周期特别长。 一座桥梁、一条铁路、一座水厂可能运行几十年。 在这样的行业里，正式工程模型、历史修改记录、资产状态和 Digital Twin 的价值会持续很久。 Agent 当然可以进入这些 Workflow。 以后工程人员可能不再亲自完成大量重复性的 MicroStation 操作，而是让 Agent 执行。 但只要现实基础设施最终还需要正式模型、工程验证和责任追踪，这些系统仍然需要存在。 所以 Bentley 的卡点很容易理解。 真正需要注意的是： 基础设施行业的数字化和 Agent 化速度可能不会特别快。 办公软件可以每个月更新。 桥梁、铁路、水务和能源系统不可能按照互联网产品的速度更换底层工程流程。 这意味着 Bentley 代表的是一种很典型的长期逻辑： 产业位置比较清晰，但技术变化真正传导到业务流程可能需要很长时间。
Dassault Systèmes 的产品版图可能是这一组公司里最完整的之一。 CATIA 覆盖 CAD，ENOVIA 覆盖 PLM，SIMULIA 负责 Simulation，DELMIA 延伸到制造，再加上 3DEXPERIENCE 和 Virtual Twin，它几乎贯穿完整工业数字线程。 从 Agent 的长期形态来看，这套组合非常有意思。 未来一个工业 Agent 如果真正帮助企业设计产品，它不只是生成一个三维模型。 它可能需要同时理解设计、仿真、制造、供应链和现实运行状态。 这时候单独拥有一个 CAD 工具，与拥有一个能够描述整个工业系统的数字环境，是完全不同的能力。 Dassault 现在越来越强调 Virtual Twin 和 Industrial AI，本质上也是在回答这个问题： 如果 AI 要理解工业世界，它需要在哪一个数字世界里工作？ 不过，拥有完整的产品版图，并不意味着所有能力能够自动形成一个统一的 Agent 平台。 复杂产品线之间能否真正打通、用户体验能否改善、不同模块能否形成一个一致的数据环境，这些仍然是需要长期观察的问题。 
这一点非常重要。 因为“卡点比较清楚”和“业务最快发生变化”不是一回事。 办公 Agent 的渗透速度很可能更快。 原因很简单： 邮件、会议、文件、CRM 本来就是数字化的。 AI 今天就能读邮件、总结会议、搜索文件、更新客户信息。 即使它偶尔犯错，很多任务也可以由人检查。 工业世界则需要经历更长的过程。 大致可能从： AI 辅助工程师 逐渐进入： Agent 完成局部设计任务 再到： Agent 自动探索大量设计方案 最后才可能进入： Agent 跨 CAD、PLM、Simulation 和制造系统协同工作。 其中还需要解决精度、责任、安全、旧系统、数据格式和认证问题。 所以我不认为“工业软件是显性卡点”就等于： 它们会最早受益于 Agent。 反而很可能出现一个顺序： 办公 Agent 先大规模普及，工业 Agent 后大规模普及。 这也是为什么下一篇的“隐藏软件卡点”可能在时间上反而更靠前。
这是整个工程软件变化里，我觉得最值得长期追踪的问题。 过去软件的使用量往往与工程师数量高度相关。 一家企业有一千名工程师，大致对应一定数量的软件用户。 未来，企业可能只需要更少的人类工程师。 如果故事到这里结束，那么当然意味着传统的软件使用方式会受到影响。 但还有另一种可能。 更少的人类工程师背后，运行着大量 Agent。 这些 Agent 持续调用 CAD、PLM、Simulation、EDA 和 Digital Twin，自动探索设计空间、修改方案、验证结果和更新正式记录。 这时候软件服务的对象就开始变化。 过去软件主要服务： Human Productivity。 未来则可能逐渐服务： Engineering Capacity。 前者与人头数量高度相关。 后者则与一个组织能够产生多少工程工作相关。 这会是两种完全不同的软件世界。 但现在还不能假设所有工程软件公司都能够自动完成这个转型。 谁能够让 Agent 真正进入自己的数据模型、验证引擎和工程流程，谁才能真正参与下一阶段的变化。
如果以后继续研究这类公司，我会越来越关注三个问题。 第一，这个卡点是否客观存在。 也就是说，AI 生成的结果最终是不是仍然需要进入这个系统，才能形成正式工程成果。 第二，Agent什么时候会真正进入这套工作流。 一个产业方向长期成立，不代表短期就会形成实际业务变化。 尤其工业软件的采用周期，通常明显长于办公软件。 第三，软件公司的产品形态是否真正适合机器使用。 过去软件是给人设计的。 未来如果 Agent 变成重要使用者，那么 API、数据结构、权限模型、自动化接口和底层计算能力的重要性都会提升。 所以这一轮 AI 对工业软件最大的考验，未必只是： “有没有 AI 功能。” 而是： 能不能从 Human Tool，真正变成 Human + Agent 的工程基础设施。
第一篇文章讨论的是： AI Agent 时代的软件价值会从哪里流向哪里。 这一篇讨论的，则是其中最容易看见的一部分。 EDA、CAD、PLM、Simulation 和 Digital Twin 的特殊性，在于我们已经比较容易理解为什么 AI 最后仍然需要它们。 它们保存正式工程对象、连接现实世界约束、承担验证任务，并最终连接制造、施工和真实交付。 所以它们的“卡点”相对显性。 但这并不意味着它们会最先进入 AI 爆发期。 办公室里的 Agent 很可能更早普及。 企业 Context、权限、Identity 和 Workflow 的重要性，也可能更早暴露出来。 工程软件则正好相反： 卡点已经比较清楚，但真正大规模进入 Agent 工作流可能需要更长时间。 所以后面更值得追踪的，不只是： AI 能不能生成设计。 而是： AI 什么时候开始真正使用这些工程系统； 它会把多少工作从人类操作变成机器调用； 以及原本为人设计的软件，能否变成同时服务人和 Agent 的工程基础设施。 下一篇，我准备继续讨论另一类更不容易被看见的软件卡点： 当 AI Agent 真正进入办公室以后，还有哪些软件看起来没有 EDA、CAD 那么“硬”，却掌握着企业记忆、权限、身份和工作流，因此可能成为更早出现的“隐藏软件卡点”？
一、“显性”不是“更强”，而是更容易证明
二、为什么工业 Agent 的卡点特别容易看见？
三、EDA 是最典型的显性软件卡点
四、Cadence最值得观察的，不再只是“有没有AI”
五、Synopsys正在尝试把卡点从“芯片”扩展到“系统”
六、真正有争议的，是CAD和PLM
七、Autodesk真正面临的问题，是从“人使用的软件”变成什么
八、PTC的卡点不只在CAD，而在产品生命周期
九、Bentley的卡点来自基础设施本身
十、Dassault拥有一套非常完整的工业数字世界