假设你要做一个“投放预算调整”工具。
过去的做法，是产品经理画页面，实施人员在低代码平台拖入账户选择器、计划表格、预算输入框和审批流，测试通过后再发布。现在有了 A2UI，用户只要说一句“把本周消耗偏低的计划筛出来，给我一个调整入口”，Agent 就能根据上下文临时组装一张工作台。
两边用的都是组件、数据绑定、事件和流程。于是一个很自然的问题出现了：既然 Agent 能现场组页面，低代码平台还有必要存在吗？
我的判断是：A2UI 会吃掉一部分人工页面编排，但不会吃掉低代码平台。更可能的变化是，低代码从“让人拖组件”转向“管理 Agent 能调用的组件、数据、流程和权限”。
看起来很像，是因为用了同一批积木
低代码和 A2UI 的重合不是错觉。
低代码平台用 Schema 描述页面，用组件库提供输入框、表格和图表，用数据绑定连接业务数据，再通过事件触发查询、提交和审批。A2UI 也有相似结构：Catalog 规定 Agent 能使用哪些组件和函数，Data Model 保存界面数据，Action 回传用户操作，Renderer 负责把这些描述渲染成真实界面。
如果只看一份 JSON，二者甚至可能很难区分。
但判断两种产品是不是替代关系，不能只看“都能组页面”。更应该问五件事：谁生产、谁编排、谁治理，产品服务谁，最后交付什么。
五个维度，拆开 A2UI 和低代码
先看组件资产。
低代码平台的工作是生产和管理积木：组件怎么开发、参数怎么配置、数据源怎么接、哪些场景可用、升级后如何兼容。A2UI 的 Catalog 更像一份能力清单，Agent 根据清单选择和组合可信组件。换句话说，低代码擅长供给资产，A2UI 擅长在运行时消费资产。
再看编排主体。
低代码主要由人在设计时搭应用。产品经理、开发者或业务配置者提前决定页面结构和流程，再经过测试、发布，供大量用户反复使用。A2UI 主要由 Agent 或确定性逻辑在运行时组装 Surface，也就是某次任务需要的一块表单、卡片或工作台。它可以随着上下文变化，也可能任务结束后就不再出现。
第三是治理方式。
A2UI 用 Catalog 白名单、Schema 校验和可信 Renderer 限制“能显示什么、能调用什么客户端函数”。这能缩小任意代码执行的风险，却不等于已经解决数据权限、业务审批、版本发布和审计。账户选择器能被渲染，不代表当前用户有权看到所有账户；预算提交按钮能被点击，也不代表业务系统应该接受这次调整。
第四是目标用户。
低代码首先服务搭建者和管理员，让他们更快建设与维护应用。A2UI 的直接协作主体是 Agent 与 Renderer，最终服务的是正在完成任务的业务用户。用户不需要先理解页面结构，只需要表达目标，再对系统提供的控件进行选择、修改和确认。
最后是交付链路。
低代码交付的是一套可持续运行的应用或流程，要经历设计、配置、测试、发布和长期运营。A2UI 交付的是某个 Surface 的描述和更新，链路更接近“理解意图—选择能力—创建界面—完成交互—更新或销毁”。一个面向长期运营，一个面向当下任务。二者生命周期不同，不能用同一把尺子比较。
低代码负责沉淀组件、数据、流程和治理；Agent 通过 A2UI 在运行时组合任务界面。
真正会被替代的，是一部分人工拖拽
A2UI 对低代码的替代会先发生在页面编排环节。
过去，只要业务想多一个筛选条件、换一种字段组合，往往就要重新提需求、改页面、测试和发布。引入 A2UI 后，Agent 可以从已有 Catalog 中挑选账户选择器、计划表格和审批组件，根据当前任务临时拼出界面。对于一次性、上下文相关、低风险、可恢复的任务，这比长期维护大量固定页面更合理。
而且，运行时组装不一定每次都要大模型自由发挥。A2UI 官方允许确定性 Agent 返回预制界面。企业可以让模型只负责理解“用户要做什么”，再由规则选择经过测试的组件组合。这样既减少人工搭建，也不把稳定性押在临场生成上。
因此，被压缩的不是所有低代码能力，而是“每个小变化都要人重新拖一遍页面”的工作。
反过来，高频、长期、高风险的流程仍需要稳定结构。预算、删除、外发、跨账户操作的确认位置、权限检查和审计字段，不适合随着每次生成任意变化。A2UI 可以负责调出合适的操作面，但不能把业务红线也变成动态内容。
更大的变化，是低代码变成 Agent 的资产工厂
A2UI 要进入企业业务，不能只有 Text、Button、Table 这些通用组件。
Agent 需要知道“账户选择器能选择哪些账户”“预算调整器有哪些前置条件”“审批组件适用于哪类风险”“这个版本能否打开历史 Surface”。这些信息不只是前端属性，而是组件的业务语义、权限条件、风险等级和版本规则。
这恰好是低代码平台可以升级的方向：
- 把业务组件注册为 Agent 可理解的 Catalog；
- 把 API 和数据源包装为可调用能力；
- 把审批、校验和回滚规则变成机器可读约束；
- 给组件增加版本、权限、风险和适用场景说明；
- 记录 Agent 选择了什么组件、是否成功完成任务；
- 用协议测试和 UI Eval 检查组合结果。
源材料中的 Google Opal 和 A2UI Composer 已经说明，设计时配置工具与 A2UI 运行时并不冲突。但现有材料还不足以证明一套成熟的企业低代码治理链路已经形成。更稳妥的说法是：机制上的融合已经成立，规模化落地仍待更多案例验证。
生成得快，不等于治理得住
反方观点很直接：如果自然语言已经能生成完整应用，为什么还要低代码拖拽和配置？
这个观点说对了一半。Agent 确实会让“创建一个界面”的成本快速下降，纯页面拖拽的价值也会被压缩。但企业应用的主要成本从来不只在第一次创建。
一套生产系统还要回答：
- 数据模型由谁维护，字段变化如何兼容；
- 不同角色能看到什么、能执行什么；
- 修改后如何测试，失败后如何回退；
- 谁可以发布，版本如何灰度；
- 多人协作时谁对结果负责；
- 历史操作怎样审计，旧界面怎样恢复。
A2UI 是 Agent 与 Renderer 之间的 UI 表达契约，不是应用全生命周期平台。Catalog 白名单可以阻止 Agent 调用未知组件，却不能替企业决定谁有权调整预算。Schema 校验可以保证结构合法，却不能证明业务结果正确。
所以，自然语言降低的是创建成本，低代码需要守住的是持续治理。只提供拖拽能力、没有业务资产和治理深度的平台会被削弱；能管理高质量组件、数据、流程和权限的平台，反而可能成为 Agent 时代的重要基础设施。
放到智投，重点不是再做一套拖拽器
智投内部材料已经描述了 Skill 流程、九类 UI 指令、通用渲染组件、标准操作回传、HITL、会话状态和记忆设计。它们可以被理解为一套内部 Agent UI 资产的雏形：
- Skill 和业务规则定义任务如何推进；
- 九类 UI 指令与设计系统提供可信交互组件；
- 标准回传定义用户操作如何回到流程；
- HITL、状态与记忆控制风险和连续性。
下一步真正值得建设的，不一定是给人再做一套更复杂的拖拽画布，而是让这些资产同时满足三个条件：Agent 能理解，系统能约束，结果能评估。
例如，每个组件除了字段定义，还需要有任务语义、调用条件、权限范围、风险等级和版本兼容信息；每次 Agent 组合后，还要能验证字段是否完整、动作是否越权、历史 Surface 是否能安全恢复。
这里必须保留证据边界：现有材料能证明智投有这套内部方案，不能证明九类组件和相关状态能力已经全部上线，也没有可用于评价收益的真实指标。因此它更适合作为演进方向，而不是成功案例。
产品经理该如何判断
面对“A2UI 会不会替代低代码”这类问题，我会先做三个判断。
第一，分清被替代的是搭建动作，还是平台责任。Agent 可以代替人选择和组合组件，但数据、权限、测试、发布和审计仍需要明确责任方。
第二，不只看组件数量，要看资产能否被 Agent 正确调用。没有业务语义、权限条件和风险说明的组件库，对 Agent 只是另一套难以理解的 API。
第三，按风险分配运行时自由度。低风险临时工作台可以更动态；高频、高风险、长期协作流程应保留稳定结构和确定规则。
最终，A2UI 与低代码更可能形成一条新的分工链路：
人定义组件、数据、流程和治理边界
→ 低代码平台管理并发布这些能力资产
→ Agent 根据用户目标选择和组合
→ A2UI 把结果交给 Renderer
→ 业务系统返回权威结果并留下审计记录
低代码不会消失，但它的竞争重点会变化。过去比的是谁让人拖得更快；接下来比的是，谁能把企业能力整理成Agent 看得懂、用得对、出了问题能追责的资产。