低代码平台曾是科技圈最标准的“千亿赛道”叙事开发人才缺口、企业数字化转型、业务人员自助开发三条逻辑放在一起市场规模顺理成章地被推算到千亿美元量级。研究机构慷慨地给出增长曲线厂商热衷于讲“人人都是开发者”的故事资本也愿意为这个听起来足够性感的平台买单。然而最近两年风向明显变了曾经高调的低代码厂商要么转型要么收缩要么被客户吐槽“定制化比原生开发还贵”。更刺眼的对比来自 AI 编程助手。一个面向专业开发者的工具靠订阅和按量计费估值却能轻松超过绝大多数低代码厂商。资本市场在用脚投票真正能写软件的人以及真正帮这些人写软件的 AI比“让人人都能拖拽出软件”的宏大叙事值钱得多。这篇文章想聊清楚三件事。第一低代码为什么曾经被资本相信又为什么在叙事层面“社死”第二从工程架构看低代码平台到底重在哪里AI Agent 又是如何从交互层改写这门生意的第三企业现在还要不要上低代码如果要用怎么用才不会翻车。全文不是给低代码唱挽歌而是帮你在技术选型时看懂牌面。1. 千亿叙事是怎么起来的以及它为什么会“社死”1.1 资本为什么曾经相信低代码低代码的故事并不是从近两年才开始的。早在 2017 年前后OutSystems、Mendix 等厂商就凭借“低代码”概念拿到大额融资微软 Power Platform、国内明道云、简道云、宜搭等产品也快速铺开。当时的行业背景非常清晰企业数字化需求爆发但专业开发人员数量远远跟不上。业务部门对 IT 的需求排期太长想要“自己的事情自己干”。软件交付成本居高不下企业希望缩短从需求到上线的周期。云计算和 SaaS 模式成熟平台化交付成为可能。这些因素叠加让“低代码/零代码”成为资本愿意下注的赛道。从公开资料看多家机构当时的市场规模预测普遍落在千亿美元量级年复合增长率动辄 30% 以上。资本市场本质上买的不是当前营收而是“未来每个企业都会为这个平台付费”的确定性。1.2 叙事为什么崩了问题出在故事讲得太顺但实际落地时遇到了几个结构性矛盾。第一个矛盾是真正买单的人和使用的人不是同一批。采购低代码平台的往往是企业高管或业务部门他们听到的是“不用写代码也能开发系统”但真正每天在用平台的是业务侧的 ITBP 或系统管理员他们很快会发现简单的审批流、表单、报表确实能做但一旦遇到复杂业务逻辑、跨系统数据同步、精细权限控制低代码平台的学习成本并不比传统开发低。最后项目还是回到了“IT 部门主导低代码平台只是换了个 IDE”。第二个矛盾是低代码项目的后期维护成本被严重低估。传统代码项目有 Git、代码评审、自动化测试、代码规范出了问题可以开 debugger 逐行排查。低代码项目则是一个中心化的可视化设计器加运行时引擎配置往往存在云端私有数据模型里变更没有 diff上线没有自动回滚调试只能靠平台提供的有限日志。很多团队在 POC 阶段惊艳进入生产环境后才发现“配置即代码”听起来很美好实际上连“配置入 Git 做版本管理”这个最基本的工程能力都难以实现。第三个矛盾是定制化反而更贵。低代码平台的价值在于用平台能力覆盖通用场景但企业真正需要的永远是差异化功能。当业务方要求“在列表页加一个特殊排序”“在审批节点做条件分支”“对接内部统一的 SSO 和审计系统”时低代码平台反而成了新的瓶颈。厂商也不傻最终会引导你购买私有化部署、专业服务、定制组件、专属 SLA整体成本迅速逼近甚至超过传统开发。1.3 “社死”的不是低代码而是“独立千亿赛道”这个故事必须说明一个判断低代码技术本身没有死。现状是它越来越像一个大厂内部工具、一个解决特定场景的平台组件而不再是一个能够独立撑起千亿美元估值、独立上市、独立成为生态的“赛道”。所谓“社死时刻”指的是资本叙事被现实打脸。低代码不再是聚光灯下的明星媒体不再写“低代码颠覆开发”厂商不再提“人人都是开发者”取而代之的是更克制、更落地的说法低代码是 IT 工具链的一部分是企业软件交付的一种补充方式。这并不意味着技术层面的失败而是商业模式层面的失败。它证明了软件开发的本质不是“拖拽组件”而是“理解问题、拆分边界、处理异常、持续演进”。低代码平台想要的是一步到位但软件工程恰恰是一个不断纠偏、不断重构、需要严格版本管理的长期过程。2. 低代码平台的技术架构它到底重在哪里如果你想评估“企业要不要上低代码”必须先理解低代码平台的工程实现。2.1 模型驱动的运行时传统开发的路径是写代码 → 编译 → 部署 → 运行。低代码平台的路径是模型描述 → 平台解释 → 运行时渲染 → 提供服务。这里的“模型”是一个广义概念包括数据模型、流程模型、权限模型、页面模型。“模型驱动”意味着业务逻辑被表达为结构化的元数据和应用声明而不是一行行命令式代码。平台内置一个运行时引擎负责读取这些元数据并实时解释执行。可以类比成 Word 文档和打印纸的关系。你维护的是 Word 文档模型平台负责渲染和打印运行时。只要模型不变平台升级后应用的表现可能完全不同反过来平台一旦锁定你的“文档”就离不开那台“打印机”。这种架构的优点很明显业务人员可以在设计器里改改字段、拖拖流程就能完成一次迭代不需要重新编译和发布。缺点也很明显所有业务都过一层抽象运行时性能和排查链路都会打折扣平台本身的升级、定制和兼容会把“维护成本”转嫁到应用层。2.2 五大核心引擎一个标准的企业级低代码平台至少包含下面五个核心模块表单引擎负责渲染数据录入页面支持字段类型、校验规则、联动显隐。流程引擎负责人工审批、任务流转、条件分支、超时处理。权限引擎负责角色、数据范围、按钮级权限、字段级脱敏。报表引擎负责数据聚合、图表展示、导出。集成引擎负责与外部系统通过 REST、Webhook、消息队列等进行对接。每个引擎都是一个庞大的抽象层。以流程引擎为例它要考虑会签、或签、加签、驳回、撤回、跳转、超时、自动任务、条件网关还要与权限引擎、表单引擎联动。平台为了“通用”必须把这些场景全部建模出来但企业实际使用时大概率只用到其中 20% 的能力剩下 80% 的复杂度全部转化成了学习成本和性能开销。2.3 一段低代码元数据示例下面用一个请假审批的元数据模型展示低代码运行时到底在解释什么。以下配置是通用思路不是某个具体产品的专有格式。{ modelName: leave_request, displayName: 请假申请, fields: [ { name: applicant, type: string, label: 申请人, required: true }, { name: leaveType, type: enum, options: [年假, 事假, 病假], label: 请假类型 }, { name: startTime, type: datetime, label: 开始时间 }, { name: endTime, type: datetime, label: 结束时间 }, { name: reason, type: textarea, label: 请假事由 } ], validations: [ endTime startTime ], permissionRef: leave_request.permission, processRef: leave_request.process }这段 JSON 描述了一个最基础的数据模型。运行时引擎读取它后会自动生成增删改查接口、表单页面和基础校验。但你注意这里没有任何复杂业务逻辑。如果业务要求“请假天数超过 3 天需要部门总监审批否则只需要主管审批”这段元数据就需要额外配合流程模型和规则表达式配置复杂度会指数级上升。2.4 低代码与传统开发的核心矛盾从工程视角看低代码平台真正的问题不是“能不能做”而是“做完了怎么演进”。传统代码项目有完整的工程化体系Git、Code Review、CI/CD、单元测试、自动化测试、监控告警、性能分析。低代码平台在可视化设计层面做得越强大对底层实现的封装就越彻底开发者反而越难介入。在传统开发中出现性能瓶颈可以优化 SQL、加缓存、改索引在低代码平台里你能做的只有改配置、给平台提工单、等厂商升级。这种“可控性缺失”是很多技术团队在 POC 之后拒绝低代码的根本原因。下面用表格对比三类方案的差异对比维度传统代码开发低代码平台AI Agent 辅助开发核心产物源代码模型配置自然语言代码工具变更跟踪Git/Diff/Review平台内配置版本会话记录代码提交调试能力Debugger/日志/链路追踪平台日志工具调用链追踪性能优化可深入优化代码和数据库依赖平台运行时可生成代码后优化长期维护工程化成熟平台锁定风险高依赖模型能力演进学习门槛高中但复杂逻辑门槛陡增低但验证成本高典型场景核心业务系统内部工具/审批流原型、脚本、报表生成这组对比想说明的是低代码并不是没有价值它的价值集中在“快速搭建内部工具和标准化流程”这个区间。一旦越出这个区间它的弱点就会集中暴露。3. AI Agent 如何改写低代码的底层逻辑3.1 交互范式的变化从拖拽到自然语言低代码最引以为傲的是“可视化拖拽”。它把复杂的技术细节藏到了设计器后面让非程序员也能搭建简单系统。但拖拽的本质是把“开发”换成“图形化编排”并没有改变“人必须理解业务结构并手动建模”这件事。AI Agent 给出的交互方案是自然语言。你直接告诉 Agent“我要一个请假审批应用请假三天以上需要总监审批数据只允许部门和人事看到”Agent 就能自动生成数据模型、流程定义、权限策略甚至能生成可直接部署的代码。这里的关键变化不是“不用写代码了”而是“人不再需要手动把业务意图翻译成模型或组件”。低代码还停留在“人操作设计器”Agent 则直接进入“人表达意图模型理解和执行”。3.2 Agent 的组成结构一个具备构建业务应用能力的 Agent通常由这几个部分组成主模型负责理解用户意图、拆解任务、生成中间计划。工具集提供可用能力比如数据库操作、API 调用、代码执行、文件操作。上下文保存对话历史、业务约束、架构偏好。记忆沉淀用户偏好、历史决策、领域规则。沙箱限制 Agent 在执行操作时的影响范围。在这个框架下低代码平台本身可以被重新定位成一个“工具集”。Agent 不再直接操作页面的拖拽栏而是调用低代码平台暴露出来的建模 API创建数据模型、创建流程定义、调整权限策略。换句话说低代码平台可能成为 Agent 的运行时底座而不是用户的 IDE。3.3 一个最小示例用 Agent 思路生成审批应用下面用一段 Python 伪代码演示 Agent 的编排思路。它不依赖任何具体 SDK只是为了说明“意图 → 计划 → 工具调用 → 验证”这个链路。# 文件路径demo/agent_build_app.py # 演示一个轻量 Agent 如何把自然语言需求转成低代码模型 def build_leave_request_application(user_intent: str): # 1. 解析意图 plan llm_parse(user_intent) # plan 示例 # [ # {step: create_model, name: leave_request, fields: [...]}, # {step: create_flow, name: approve_flow, nodes: [...]}, # {step: create_permission, name: dept_hr_only, rules: [...]} # ] # 2. 按计划调用工具 for step in plan: if step[step] create_model: model_api.create(step) elif step[step] create_flow: flow_api.create(step) elif step[step] create_permission: permission_api.create(step) # 3. 验证结果 generated_app app_api.export(leave_request) report validate_against_schema(generated_app) return report # 调用示例 report build_leave_request_application( 帮我创建一个请假审批应用超过3天需要总监审批数据和页面只允许HR和部门主管查看 ) print(report)这段代码的核心逻辑是Agent 负责把用户意图拆成步骤然后调用平台 API 完成建模最后用校验器确认产物符合预期。对比低代码平台“人手工拖拽”Agent 省掉的是“人理解工具”的成本但引入了“模型是否理解正确”的新问题。3.4 低代码与 Agent 不在同一个层面一个容易混淆的地方在于Agent 不是低代码的下一代而是低代码设计器的替代者。Agent 负责的是“理解需求、生成编排方案”低代码平台负责的是“运行时解释和执行”。两者可以独立存在也可以组合使用。对现有低代码平台而言正确的进化方向不是继续强化拖拽设计器而是开放标准化的建模 API让 Agent 能够直接操作模型定义。这样既能保留运行时稳定性又能接入新的交互范式。所以低代码的“社死”不是全面死亡而是“可视化设计器作为核心交互方式”的时代正在被 Agent 终结。用户不再需要学会拖拽只要会说清楚需求。4. 企业现在要不要上低代码一个决策框架这里给出清晰判断低代码仍然有使用场景但它更适合做“边缘系统”不适合做“核心枢纽”。4.1 适合上低代码的场景内部工具类例如运营后台、客服工单、审批流、简易报表。业务部门自助产品、运营、市场部门搭建临时管理工具。标准化流程请假、报销、采购申请、合同审批。原型验证快速验证一个业务流程是否跑得通。与核心系统隔离不涉及核心交易、不依赖强一致性、不承载高并发。在这些场景里低代码的核心优势是“快速建模、低门槛交付、减少重复 CRUD”确实能节省时间。4.2 不适合上低代码的场景支付、订单、库存等核心交易链路。强状态机、强一致性、高并发分布式事务。强合规审计环境如需完整代码审计、精确变更追踪。长期演进超过两年的复杂系统。需要深度定制 UI、算法、性能优化的大型应用。这些场景需要的是传统工程能力代码审查、自动化测试、性能调优、细致监控。低代码平台的抽象层会把这些问题全部模糊化出事时排查成本极高。4.3 团队评估清单在决策前建议用下面这些问题做一次严格评估这个应用的生命周期预计多长超过两年慎重。核心逻辑是否会被多个系统依赖会慎重。业务规则是否经常变化变化频繁低代码有一定优势。团队是否有能力维护平台本身的升级没有慎重。平台是否支持把模型导出为标准代码不支持慎重。权限体系是否满足企业审计要求不满足直接淘汰。平台是否有清晰的 API方便与现有系统集成没有慎选。4.4 特别警惕 POC 陷阱POC 阶段低代码几乎总是表现良好。因为 POC 用的是干净数据、简单流程、少量用户不会暴露权限漏洞、性能瓶颈、并发问题和版本管理问题。进入生产环境后真实用户、真实数据量、真实异常流量会迅速放大平台短板。所以建议不要只做功能 POC要做“压力 POC”和“故障 POC”。测试一下 100 个用户同时提交审批时平台的响应时间测试一下权限配置漏配时是否默认放行测试一下平台宕机后数据是否完整。这些问题不在 POC 阶段暴露就会在生产阶段爆炸。5. 如果一定要用低代码怎么做才不翻车低代码在企业内落地并非绝对不可行前提是把它当工程系统来管而不是当“傻瓜工具”来用。以下五条工程化建议值得直接抄走。5.1 配置即代码必须入 Git很多低代码平台的配置存放在云端数据库中没有 Diff、没有 Review、没有回滚。这就等于把生产环境的所有变更都交给“直接在页面上改”。解决方案是凡是平台支持导出的模型、流程、权限配置全部导出为结构化文件纳入 Git 管理走提交、评审、发布流程。平台不支持导出的要在选型阶段直接淘汰。5.2 增加 CI 校验环节模型和配置同样需要自动化校验。下面是一个简单的 CI 校验思路# 文件路径scripts/validate_lowcode_config.sh # 思路对导出的模型文件做 schema 校验、权限校验和流程完整性校验 #!/bin/bash set -e MODEL_DIR./lowcode_configs # 1. 校验 JSON 格式 find $MODEL_DIR -name *.json -exec python -m json.tool {} \; /dev/null # 2. 校验模型是否满足最小规范 python scripts/validate_model_schema.py $MODEL_DIR/leave_request.model.json # 3. 校验权限策略是否允许匿名访问不允许 python scripts/check_anonymous_permission.py $MODEL_DIR/permission.rule.yaml # 4. 校验流程节点引用是否存在 python scripts/check_flow_reference.py $MODEL_DIR/leave_request.process.json echo lowcode config validation passed.这个脚本的本质是把低代码配置当成“源代码”来对待。只要 CI 能跑起来就能在发布前拦截大部分低级错误。5.3 权限策略默认拒绝低代码平台的权限模型常常默认开放原因是为了降低使用门槛。但在企业环境里应该改成“默认拒绝、按需开放”。下图是一个最小权限策略示例# 文件路径lowcode_configs/permission.rule.yaml # 角色部门主管 role: dept_manager permissions: - resource: leave_request actions: [view, approve, reject] scope: department_only - resource: leave_request actions: [edit, delete] scope: created_by_self - resource: employee_salary actions: [] scope: none注意最后一条普通员工和部门主管对薪资字段没有任何操作权限。这种策略需要显式写出来而不是依赖平台默认值。每一次权限迭代都要走评审不能直接在页面上勾勾选选。5.4 双轨策略低代码做前端和流程核心逻辑走代码一条实际可用的架构经验是把低代码平台当成“表皮”把核心业务逻辑放在平台之外的微服务中。表单、审批流、页面展示可以交给低代码平台但价格计算、库存扣减、订单状态机、对账逻辑等核心能力必须写成独立服务通过 API 暴露给低代码应用。低代码应用只负责编排展示和人工审批不承载核心数据一致性。这样做的价值是平台被替换、升级、淘汰时核心逻辑还在重建一套前端和流程的成本相对可控。5.5 提前规划退出通道任何低代码选型都必须回答一个问题如果平台明天停止服务我的系统怎么办应该要求供应商提供完整的数据导出能力、模型导出能力、API 文档以及至少一份“迁移到传统代码架构”的预案。如果不能导出平台就是一个黑盒你的所有资产都等于永久租借。6. 常见问题与排查思路低代码项目和 Agent 辅助开发在实践中会遇到不少相似问题这里整理一张排查表问题现象可能原因排查方式解决方案应用在低代码平台运行很慢运行时引擎抽象层过厚或查询缺少索引查看平台慢日志、数据库慢 SQL将高频查询改到独立 API/数据库视图同一套配置在不同环境表现不一致配置漂移未按环境同步对比各环境导出配置版本配置纳入 Git CI统一发布权限规则经常漏配平台默认开放角色模板不清晰审查权限变更记录和越权报表默认拒绝、最小权限、定期复核Agent 生成的应用逻辑错误提示词缺乏领域约束或模型理解偏差查看会话上下文和工具调用链补充 Schema 提示、工具级白名单、人工确认关键操作低代码平台升级后原有应用崩溃平台运行时不兼容旧模型查看升级日志和兼容性说明升级前先在测试环境验证保留旧版本流程审批节点超时不生效流程引擎配置错误或定时任务未开启检查流程定义和平台定时任务日志核对节点配置确认调度服务正常导出代码后无法运行生成代码依赖平台私有 SDK检查导出产物和平台依赖优先选择兼容标准技术栈的平台每个问题背后都有一个共性原因把低代码当成“黑盒”使用缺少工程化视角。只要把模型、配置、权限、流程都当作可审计的资产来管理很多问题都能提前暴露。7. 最佳实践与工程建议7.1 对技术负责人的建议在引入低代码或 Agent 辅助开发前先定义清楚一个原则任何系统都必须能回答“它是怎么运行的、它是怎么变更的、它挂了怎么恢复”这三个问题。低代码平台如果做不到就只配做边缘工具不配做核心系统。实际项目中更推荐“先试点、再推广”的节奏。选一个非核心、跨部门协作多的内部工具做试点周期控制在两个月以内产出一次完整的复盘性能、权限、维护成本、团队接受度。不要把低代码直接铺到核心业务线上。7.2 对实施团队的建议把低代码项目当软件开发项目来管理而不是当作“配置活”。具体包括每个模型和流程都要有负责人和评审记录。配置变更要留下审计日志。应用的发布要有固定的窗口期。设置最低限度的自动化测试至少覆盖关键流程和权限策略。不要放任业务人员直接改生产配置后台要有审批流。7.3 对正在建设 Agent 能力的团队的建议如果你所在团队正准备用 Agent 重构内部工具建议先把现有低代码平台的模型层抽出来做成标准 API。让 Agent 能读取和创建数据模型、流程定义、权限规则。这样既保留低代码运行时稳定性的优势又获得了新的交互入口。关键点在于Agent 生成的配置必须能进入现有的代码审查和 CI 流程不能让它直接改生产环境。建议给 Agent 的权限设置为“只能生成配置草稿”由工程师在执行前审批和合并。这里的安全原则和低代码权限策略完全一致默认拒绝按需开放全程可审计。8. 总结与值得继续跟踪的方向回到标题一个千亿赛道的“社死”时刻。这里的“社死”不是功能消失而是价值重估。低代码在资本叙事层面遭遇了尴尬但它留下的工程资产——模型驱动、元数据抽象、流程引擎、权限建模——正在成为 AI Agent 落地的重要底座。真正值得继续跟踪的方向有三个第一个是 Agent 与低代码运行时的融合低代码平台从“用户操作界面”变成“Agent 的工具集”交互入口彻底改变。第二个是模型驱动开发的新形态企业不再手动建模而是通过自然语言让 Agent 生成模型由人来审查和修正。第三个是工程化能力的下沉无论是低代码还是 Agent 生成代码Git、CI、权限审计、回滚机制都会成为标配任何绕开工程化能力的“效率工具”都很难在核心系统里长期存在。如果你正在做技术选型建议下一次讨论低代码或 AI 编程工具时带着本文中的评估清单和工程化原则去对照。判断标准从来不是“工具是否流行”而是“这套方案能否在两年后依然解释得了自己的变更历史、权限边界和故障恢复路径”。低代码的故事翻篇了但软件生产方式的改造刚刚开始。