人工智能已经能理解任务、编写程序、调用工具，甚至独立推进复杂工程工作。我们却还在让它沿着预先画好的流程图走。这场架构之争，绕不开既有利益、路径依赖，以及企业敢不敢动自己的老本。
一、一场令人似曾相识的技术革命
工业软件领域正上演一幕有点魔幻的戏。大语言模型、工具调用、代码生成和自主任务执行快速发展，软件开始能听懂自然语言、制定计划、操作工具，必要时还会调整自己的做法。与此同时，不少传统企业软件平台忙着把这些能力装进原有的低代码框架：加几个智能组件、几个模型连接器，再配一套可视化编排工具，便宣布完成了向智能体平台的转型。
发布会上的演示通常很好看。业务人员输入一段话，屏幕上跳出几个智能体节点，数据依次流经知识库、模型和流程引擎，最后生成分析报告。仔细看就会发现，多数行动路径早已由开发人员画好。模型理解语言，流程图决定行动；一旦碰上没设计过的情况，系统照旧报错、退出，或者等人重新配置。
荒诞之处就在这里：我们用一套为减少人工编程而发明的体系，去约束已经能够自主编程的技术。模型能理解需求、生成代码、调用工具、修复错误，甚至分析陌生项目并提出修改方案，我们却要求它先适应封闭的低代码环境，遵从特定的数据模型、组件接口和流程节点。开发平台本该帮智能体做事，结果又成了一层必须绕过的门槛。这层门槛还常被包装成企业级能力、工业级可靠性和可治理性，仿佛流程图画得越密，智能体就越聪明。
低代码当年解决过实在的问题。企业信息化中有大量表单、审批、数据管理、业务流转和系统集成需求，开发人员反复写着相似的页面、接口和逻辑。模型驱动、可视化配置、组件复用，确实降低了标准化应用的交付门槛。流程稳定、规则明确的管理场景，今天也仍然用得上它。
但问题变了。过去，开发工作主要是把确定的业务规则高效翻译成程序；现在，越来越多的任务要求软件边运行边理解目标、处理意外、选择工具，再根据结果改变下一步行动。低代码在前一种任务里积累的优势，不能直接拿来当后一种任务的架构答案。硬要让它坐在工业智能体开发的中心，冲突迟早会冒出来。
二、用流程图驯服智能体，本身就是一种范式错位
传统工作流有一个前提：业务流程事先能够描述，系统沿设计好的路径执行。条件判断、循环、异常分支和动态参数可以让路径更复杂，但行动空间主要还是开发阶段由人划定。智能体面对的是另一类问题。用户给它目标、可用工具、约束和上下文，它要在运行中形成计划，做一步，看结果，再决定下一步。智能体当然需要确定性规则，尤其是权限、安全和业务边界；这些规则不必替它预写每一种可能的调查路径。
工业场景能把差别看得很清楚。假设一条精密加工产线连续出现尺寸偏差，工程师请系统找原因、提出调整建议。用传统低代码平台，开发人员可以事先搭好质量数据查询、设备参数获取、历史批次比较、工艺分析、异常模型调用和报告生成流程，再给各种结果配置分支。问题若恰好落在这些分支里，系统跑得很顺。
现场的问题却未必这么听话。智能体可能需要临时比对不同批次的刀具磨损记录，接着检查温度补偿算法；发现疑点，又调用统计程序、读取数控设备日志，用仿真模型验证热变形假设。第一轮找不到可靠结论，就换方向查，甚至自己写一段临时分析程序。那些开发人员没法提前列全的动作，恰恰是智能体最该发挥作用的地方。
如果每多一种分析路径，都要打开设计器、加节点、配接口、改数据结构、发布版本，这套方法只是换了个界面继续让人手工定义逻辑。拖拽组件不等于复杂性消失；几十个节点相互依赖的流程，有时比结构清楚的程序更难读、更难调试。低代码原本想降低开发复杂度，碰上高度动态的任务，却可能把复杂性埋进越来越厚的配置里。
于是问题来了：一个工业智能体若只能走开发人员排好的路线，与过去的工作流自动化、规则引擎和 RPA 有多大区别？它可以把对话变得自然，把报告写得漂亮，在部分节点接入大模型，也完全可能创造业务价值。但面对未知任务时，它的自主规划能力并没有随之长出来。企业采用 AI 增强的流程自动化没有错；把这种交付方式当成工业智能体的最终形态，才可惜。
三、工业智能体需要一个开放的工程执行环境
工业任务有自己的难处：工程对象复杂，专业算法、物理约束、历史数据和异构软件挤在一起。参与机械设计的智能体，可能要先读产品需求，再查 PLM 里的零部件资料，调用 CAD 生成或修改几何模型，借助 CAE 做结构分析，根据仿真结果调整参数，最后交工程师审核，进入正式的设计变更流程。设备维护也一样，设备台账、传感器时序数据、维修工单、故障知识库和预测模型常常都得一起用。只把几个接口接通，离完成任务还远。
平台该下功夫的地方，是工业工具与专业知识的组织，以及复杂任务如何持续执行。某一种专有的可视化开发语言，不该成为它最重要的资产。MCP、CLI、API 和工程软件专用连接器都可以用来封装能力。智能体应能在授权范围内发现工具、理解能做什么、按任务动态组合调用，同时保留完整的执行上下文。工具失败时，要能分析错误、决定重试还是另找办法；任务持续数小时甚至更久时，要能保存状态、管理中间文件、从中断处接着做，并让工程师随时接管关键步骤。演示之后能不能进生产，往往就卡在这些细节上。
低代码在这套体系里依然有位置：业务界面、驾驶舱、人员审批、任务管理、与现有系统的集成应用，都可以由它快速交付。稳定、重复、确定性的流程也没必要抛弃传统编排引擎。需要挪动的是平台的重心。以往低代码试图成为企业应用开发的中心，功能要围着自己的数据模型和运行环境转；智能体时代，它更适合作为应用入口和交付渠道。任务执行能力应当能独立存在，工业工具不能锁死在私有组件里，工程任务的上限也不能由可视化流程能画多少节点来决定。低代码可以做工业智能体的外壳，别抢着替它做大脑。
开放不等于放任。工业系统有严肃的安全要求，生产设备控制、工艺参数修改、质量放行、工程设计变更都有责任边界。智能体可以自主分析、组织仿真、提出建议；高风险操作必须经过权限校验、规则约束和必要的人工确认。规划可以灵活，执行必须可控。安全治理要落在工具调用权限、操作范围、执行记录、版本管理和审批机制上。用巨大的预定义流程堵住所有行动，并非唯一的安全办法；反过来，任凭智能体自由调用工具，也谈不上成熟。
四、难以割舍的，往往是旧有的商业利益
既然方向已经看得见，传统平台为什么还执着于把智能体塞回旧架构？答案恐怕更多藏在产品历史、商业模式和组织利益里。成熟平台多年投下的专有框架、组件库、业务模板、认证体系、实施伙伴、培训课程，以及客户已经运行的应用，既是竞争壁垒，也是收入来源。新技术改变开发方式，管理者很容易先问：怎样让它继续服务于这些资产？于是智能体变成新组件，大模型变成新流程节点，工具调用进入原有组件市场，所谓智能体开发又被解释成可视化应用开发的升级版。
短期看，这样做有商业道理。客户不用马上换平台，销售沿用熟悉的关系，实施伙伴继续提供服务，厂商也能避开剧烈调整。麻烦在于，这种稳妥会慢慢反过来定义产品：新需求来了，先加组件，再封装接口，再添一种配置。功能不断增加，底层想法却没变；旧框架更重，兼容要求更繁，团队越忙，越难腾出手来改根基。所有人都在推进创新，却没人愿意碰创新脚下那套旧结构。
低代码与工业智能体相遇的魔幻现实，正在这里。企业大谈技术革命，研发却把保护现有架构当默认前提；口头讲自主，交付依旧靠人工编排；营销材料说软件会理解人的意图，开发体系仍让人逐项定义软件该怎么走。本该被新技术减少的工作，重新变成平台开发的必经环节。效率收益被配置、适配和维护成本吃回去一截，客户买到的系统看着先进，用着沉重。
生成式 AI 还在改变软件开发的成本结构。过去，低代码的重要卖点是少写代码。现在，模型可以按需求生成程序、编写接口和测试，分析错误并修改。架构设计、验证、安全审查、持续维护仍少不了，但代码本身已经不必然是最贵、最难取得的生产资料。如果低代码继续主要靠“少写代码”证明价值，它的竞争逻辑就得重新审视。企业治理、稳定交付、系统集成和业务运行保障，才更值得它投入。死守可视化界面的中心地位，守住的可能只是一套正在失去说服力的旧说法。
五、背着包袱走，不如拿出置之死地而后生的勇气
成熟软件平台都有技术债，没人能假装历史不存在。渐进升级通常风险较小，也容易获得内部支持；但技术范式若已经转向，渐进有时只是昂贵的拖延。新能力必须迁就旧架构，架构调整得照顾原有产品线，每次升级还要维护更多兼容关系。开发团队看得到方向，却只能在旧系统上继续补丁。路线图排得越满，改变底层结构的机会越少。
置之死地而后生，并非鼓励企业一夜之间扔掉存量产品，更不能把新技术当万能药。它意味着组织愿意给新产品一套不同的架构，容许新商业模式冲击既有收入，让开发体系绕开原有专有工具，也容许新团队证明：过去视作核心竞争力的某些资产，战略价值已经变了。自我革命必然触碰利益。大型企业软件厂商难的未必是造出智能体引擎，而是接受未来的平台可能用不上自己最引以为豪的组件。
如果从零设计工业智能体平台，我更愿意看到轻量、开放、模型原生的体系。底层用标准化接口连接工业数据、知识、专业软件和计算资源；中间有独立的运行环境处理任务规划、工具发现、执行状态、上下文记忆、多智能体协作与错误恢复；上层再通过业务应用服务工程师。权限、安全、审计和可观测性要贯穿其中。模型可以直接调用接口明确的工业工具，开发者也能为关键业务编写确定性程序。传统软件工程的方法，该可靠时继续可靠；智能体需要自主处理的问题，给它留下空间。最后界面用低代码、传统前端还是 AI 动态生成，看业务需求，别让平台的旧技术选型替客户作主。
商业模式也得跟着动。传统企业软件卖平台授权、开发席位、组件数量和项目实施；工业智能体的价值，更可能落在任务完成质量、执行效率、集成成本和持续运行能力上。能辅助分析设备故障、生成工艺方案、组织复杂工程仿真的系统，价值来自解决了什么问题，背后堆了多少可视化节点并不重要。厂商要从销售开发工具逐渐走向提供可复用的工业能力、可靠的执行基础设施和持续运营服务。客户采购时，也别再用平台体量、功能清单和界面数量来代替技术判断。
说到底，还得让真实任务来验货。比起预先排练好的完美流程，我更想看一个事先没配好路径的工业问题：系统能否听懂任务，能否组织多个工具完成分析；失败后能不能找到原因、接着工作；能否分清事实、假设和推断，留下工程师可复核的证据链；涉及生产安全和业务责任时，能否守住授权边界。这比展示漂亮的搭建界面难得多，也更接近企业愿意长期付费的东西。
六、结语：最大的危险，是用昨天的成功定义明天
很多企业后来被超越，未必是因为看不到新技术。恰恰因为太清楚旧技术给自己带来过什么，才难以放手。成熟平台、稳定客户、庞大生态、经过验证的商业模式，都是优势，也都可能成为不改变的理由。每一次局部决策都显得合情合理，走远了才发现方向已经偏了。
智能体不会让低代码立刻消失。稳定业务系统仍要确定性流程，企业仍需开发应用、集成系统、治理运行。但低代码得重新找准位置：它可以是好用的企业应用开发工具，可以衔接智能体与既有业务系统，也能在流程治理上继续发挥作用。该放下的是那种执念：新一代智能体必须服从旧开发范式。工业智能体能做多远，应看模型、工业知识、工具生态、执行架构与安全治理，而非某个平台的组件库有多大。
一个时代的技术优势，不该成为下一个时代的架构枷锁。 如果企业相信智能体会改变软件开发和工业工程，就得重新审视产品、技术体系和商业模式，必要时亲手结束某些曾经成功的技术路径。未来的软件未必照我们熟悉的方式开发，工业应用也未必沿我们画好的路线运行。承认这一点，比一遍遍为旧架构寻找新理由更痛，也更有用。
舍不得革自己的命，最终就只能等着别人来革。
工业智能体平台要长出来，需要有人敢拆旧架构、重建技术基础。单靠一个又一个新增的低代码组件，恐怕撑不起它。