编程智能体并未淘汰低代码，反而让其更具价值

过去几个月，一种自信的新叙事悄然兴起：编程智能体如此强大，任何人都能写出代码，低代码智能体构建的时代基本结束。

如果一个非开发者用自然语言描述需求，就能看到可运行的 Python 代码，那他们何需低代码可视化画布？这个论点简洁有力，却忽略了一个关键问题。

转变确实存在，但随之而来的问题也不容忽视

我们先承认其合理性：编程智能体确实降低了门槛。曾经为语法和脚手架耗费数小时的开发者，如今能以完全不同的速度推进。那些从未自视为构建者的人——产品经理、运营负责人、财务分析师——也发现，当 AI 将他们的意图转译为代码时，他们也能构建出可运行的自动化。

UiPath 首席技术与产品官 Raghu Malpani 称此为软件构建方式的代际转变。过去需要数周甚至数月才能构建一个关键自动化的开发者，现在能在相同时间内交付数倍成果。“软件只是更快地吞噬世界，”他简练地说道。随着编程智能体从处理小型离散任务，演进到自主承担复杂功能，这种加速效应将呈复合增长。

这就是加速的故事。但加速本身也会制造问题——而这正是低代码叙事变得更有趣之处。

关键不在谁能构建，而在谁能治理

当更多人能更快地构建智能体，企业需要治理的智能体数量非但不会减少，反而会更多。而对这些智能体负责的大多数人——合规官、运营经理、流程所属部门负责人——并不会阅读 Python 代码。

这是讨论中常被忽略的部分。“低代码已死”的论点完全聚焦于构建阶段，却无视智能体发布后的一切：凌晨 2 点的事故、6 个月后的审计请求、智能体被授权做什么以及何时授权的问题。当跨多部门、多系统的流程出现故障时，必须有人能快速理解问题。可视化流程图是运营经理、合规官或业务负责人真正能看懂的东西，代码则不能。

低代码的价值从来不只是让构建更简单，而在于让流程对所有相关方都可读、可理解。随着编程变得更容易，这一价值不会减弱，反而会放大——因为智能体构建者的增速，超过了能审计其产出的人群。

我实际上认为，在不懂代码的人也能理解低代码体验的世界里，低代码的价值反而会增加；它能把自然语言意图以他们能理解的可视化业务逻辑呈现出来。
Raghu Malpani，UiPath 首席技术与产品官

可视化画布不是代码的辅助轮，而是一层“可读性层”——让自动化流程对负责它的人变得可理解。

复杂流程天生需要可见性

还有另一个在规模化时尤为关键的维度。对简单的单任务自动化，治理论点或许显得抽象；但大型企业实际运行的复杂流程编排——跨系统、跨部门、多人工决策点的工作流——则完全不同。

Malpani 直指核心：在复杂的多步骤流程中，即使是有经验的开发者，也更喜欢整体结构的可视化视图（即便各组件是用代码构建的）。流程做什么、如何分支、人在回环的位置——这些信息的可见性，并非对非技术人员的妥协，而是任何企业级系统的设计要求。

构建阶段还有一个维度值得一提：可视化工具能在设计时强制执行约束，而代码往往要到运行时才会暴露问题。设计时静态检查在部署前即可锁定问题；内置防护措施在智能体进入生产前划定行为边界，从源头控制风险。这些不仅对非开发者重要，对任何为智能体发布后负责的人同样重要。

辩论核心的伪二选一

之所以说这是伪二选一，是因为在现代业务编排与自动化平台上，低代码和代码优先并非通往不同目的地的竞争入口，而是通向同一栋建筑的两扇门。

团队可以从可视化低代码画布起步，再迁移到代码，而逻辑、结构与意图都不会丢失。偏好直接写代码的开发者，也能生成可视化流程图供审批。选择哪个入口，并不等于做出永久性架构决策，也无需从头再来。

这正是多数“低代码已死”讨论所忽视的前提。将两条路径对立起来，只是为了论点更干脆；但规模化构建智能体的企业，承受不起这种非黑即白的框架。

构建智能体的团队应考虑的正确问题