本文由 NotebookLM 基于我的演讲材料《Agentic 时代的前端：当 UI 成为数字员工的执行界面》生成初稿，我在此基础上补充细节，最后由 GPT 5.2 进行润色。

在 Agent 正在从“辅助者”变成“执行者”的时代，前端架构必须被重新定义。

随着 AI 编程工具从“代码补全”迈入“代码代写”的 Agentic 时代，软件系统中的执行主体正在发生根本性变化——从人操作，转向人监督 AI 操作。这一转变要求前端的角色必须进化：从传统的“展示界面”（GUI），演变为一个可执行、可治理、可审计的“工作界面”。它的本质更接近一个刚性的、契约驱动的 API，而非仅供展示的 GUI。

1. WHY｜为什么前端必须被重新定义？

传统软件系统的核心假设是“人是执行主体”。UI 的传统职责正是基于这一假设，将复杂的系统能力拆解为一个个独立的按钮、表单和菜单，供人点击操作。

然而，随着大语言模型和 Agentic Workflow 的日益成熟，这个核心假设正在失效：系统的执行主体正从“人”转变为“AI”，人类的角色则变成了监督者。当执行主体发生根本变化，那些仍为“给人点”而设计的 UI，便不可避免地成为整个系统的瓶颈。

1.1 AI Coding 2.0：执行权正在从人转移到 Agent

AI 在编码领域的角色正在经历一场深刻变革，执行权正逐步从开发者转移到 Agent 手中。这种转变主要体现在：

• 从代码建议者，转变为任务执行者
• 从被动响应，转变为主动规划与行动
• 从单次生成，转变为自我校验与修复

如今的 Agent 已具备完整的“感知 → 决策 → 行动 → 反馈”的能力闭环。

它不再只提供代码建议，而是能够执行具体的、高价值的任务，例如自动化 Lint 检查与修复、自动化生成并执行测试，乃至自动化验证环境。

当 AI 拥有了如此强大的执行能力时，核心问题也随之浮现：系统是否允许它安全地执行。

1.2 断层出现了：Agent 的进化速度已经超过 UI 架构

从快速自我迭代、“不需要看代码”的 Claude Code，到 Agent 模式的 AI IDE（如 Google Antigravity），Agent 的进化速度已经远超传统 UI 架构的迭代。

当前，AI 与现有系统的集成方式普遍是“寄生式”的——AI Agent 通常以“插件”或“覆盖层”的形式运行在既有 UI 架构之上。

AI 不应只是 UI 表层的“补丁”，而应成为架构底层的“内核”。

这种寄生方式非常脆弱，因为它缺乏与应用程序之间的 “正式契约”（Formal Contract）。AI 无法可靠地理解系统状态，也没有明确的操作边界，导致 Agent 的行为更像在“猜测系统如何工作”，而不是真正“操作系统”。

这个断层清晰地指出：传统 UI 架构已成为释放 Agent 执行能力的最大障碍。

1.3 传统 UI 的极限：导航税与认知负担

此外，传统 UI 正在向用户征收高昂的“导航税”（Navigation Tax）。我们迫使用户把复杂意图拆解为一系列精确点击，在迷宫般的菜单里寻找所需功能。这种“功能蔓延”的设计不仅隐藏了价值，还会导致状态分散、反馈滞后，以及执行过程难以追溯等问题。

当执行者从理解力强但操作速度慢的人类，变成操作速度极快但需要精确指令的 Agent 时，这套为人类设计的交互机制会彻底失效。

2. WHAT｜在 Agentic 时代，UI 应该成为什么？

2.1 范式转移：AI 不是“使用 UI”，而是“操作系统”

在 Agentic 时代，我们必须完成一次范式转移：AI 不再是 UI 的“用户”，而是系统的“操作者”。UI 也不能再仅仅充当被动显示屏。

这种定位的转变意味着 UI 的核心价值发生根本变化：

• 从展示界面，转向执行界面
• 从视觉对齐，转向意图与执行对齐
• 从交互美学问题，转向系统治理问题

2.2 重新定义 UI：数字员工的执行工作台

如果我们把 AI 视作一名“数字员工”，那么未来的 UI 就应该是它的“工作台”（Workbench）。智能体前端（Agentic Frontend）不仅是界面，更是 AI 的任务控制中心。

与传统 UI 试图把复杂操作隐藏在漂亮按钮背后不同，一个面向 Agent 的执行界面必须把执行过程显式化、结构化地暴露出来。

2.3 执行界面的四个核心要素

一个可执行、可治理的 UI，必须具备四个核心能力，才能成为合格的“数字员工工作台”：

1. Task（任务）：清晰展示“我们希望达到什么目标”，以及“现在走到了哪一步”。它把宏大目标结构化拆解为透明的执行路径与进度。
2. Context（上下文）：提供完成任务所需的所有资料，成为可信、无歧义的单一事实来源（Source of Truth），确保 AI 的每一个决策都有据可依。
3. Action（动作）：这是 AI 真正“干活”的地方。它提供被明确授权、边界清晰的原子操作接口，把计划转化为现实世界的结果；并且动作必须可审计。
4. Observation（观察）：提供完整、可追溯的执行日志与状态反馈。它记录每一个动作带来的结果，帮助 AI 与监督者判断“接下来该做什么”。

UI 的新价值主张不再是“好不好看”，而是：能否让执行过程透明、可控、可接管。

2.4 从“体验 UI”到“可执行体验”

在 Agentic 系统中，“用户体验”的定义也随之改变。真正的体验不再是美化按钮，而是最大限度降低用户的认知负担。实现这种“可执行体验”的关键在于：

• 清晰解释：向用户明确展示系统正在做什么、打算做什么。
• 过程暴露：暴露关键决策点与执行步骤，建立信任。
• 随时接管：允许人类在任何环节介入、修正或完全接管执行过程。

3. HOW｜如何构建 Agentic Frontend？

3.1 为什么 Prompt 不够：自然语言无法承担执行责任

Prompt（自然语言）是表达意图的绝佳工具，擅长处理基于上下文的推理与模糊的“感性决策”。但系统执行需要的是刚性执行：自然语言难以直接映射为精确指令，存在安全与确定性风险。

在复杂业务系统中，仅依靠自然语言难以解决以下关键问题：

• 如何验证一次执行是否符合权限与规则？
• 如何约束 Agent 的操作边界，防止越权？
• 如何对所有操作进行审计与回滚？

3.2 DSL：Agent、UI 与系统之间的刚性契约

领域特定语言（DSL）正是为弥合“感性理解”与“刚性执行”之间的鸿沟而生。它扮演着 Agent、UI 与系统之间一种可验证、可审计的执行协议。

DSL 的核心价值在于：

• 将模糊的自然语言意图，转化为结构化、无歧义的执行指令。
• 以代码形式显式定义系统的状态、能力与约束。
• 在 Agent 与系统之间建立清晰、可信的信任边界。

DSL 并不是要取代自然语言，而是为其提供一个可以安全、可靠执行的刚性框架。

3.3 从契约到渲染：A2UI 与 GenUI

在许多 Agent 架构中，执行任务的 Agent 往往是远程的，无法直接操作客户端 UI 组件。为了解决这个问题，A2UI（Agent-to-UI）或 GenUI（Generative UI）的概念应运而生。

其核心思想是将 UI 结构与 UI 实现分离，工作原理如下：

1. 声明式描述：Agent 的输出不再是具体 UI 代码，而是一种声明式 UI 描述（例如 Declarative JSON）。它只描述“需要什么”，而不关心“如何实现”。
2. 客户端渲染：客户端（前端）接收这份描述，并负责将其安全地渲染为原生 UI 组件，从而保持对安全性与性能的完全控制。

通过这种方式，UI 才真正成为数字意图的可视化表达。

3.4 迁移不是重写：现实世界的 Agentic 演进路径

在现实世界的项目中，向 Agentic 架构的迁移往往是渐进式演进，而不是一次性彻底重写。通过具体迁移案例，我们可以看到这条路径如何落地：

• 前端遗留系统升级：诸如从 Vue 2 升级到 Vue 3 的案例，展示了一种分层演进策略：为不同代码分层（如构建配置、框架代码、业务组件）匹配最优的 Agent 能力，从而逐步、安全地完成现代化改造。
• 桌面应用框架迁移：桌面应用的 UI 框架从 Swing 迁移到 Compose 的案例则说明，Agent 驱动的重构可以克服旧式非声明式 UI 框架的局限性；因为声明式 UI 的结构天然更适合 AI 的理解与操作。

其关键策略包括：为不同代码分层匹配最优的 Agent 工具集；利用规则与工具链缩小 AI 的修改范围；并构建“感知—诊断—修复”的自动化闭环，让 Agent 能够自动访问页面、分析错误、定位代码并尝试修复。

4. 试验｜我们正在试验中的 Agentic Frontend

4.1 NanoDSL：执行界面的最小表达

NanoDSL 的定位不是“又一种 UI DSL”，而是 IDE 内 AI Agent 的执行界面最小表达：用尽可能少的语法，把 UI 结构、状态与交互压缩成一份正式合约，满足 可解析（parseable）→ 可编译（DSL→AST→IR）→ 可预览（IR→HTML）。

它的“最小”体现在三点（均来自当前实现）：

• 结构最小：用缩进表达层级，组件树天然可解析（默认 IndentParser）。
• 数据流最小：用 state: 声明状态，用 <<（订阅）与 :=（双向）表达绑定（Binding）。
• 行为最小：交互不允许随意写代码，而是协议化动作（NanoAction：StateMutation / Navigate / Fetch / ShowToast / Sequence），便于 IDE/运行时安全接管。

示例（短版）：

component ContactForm:
    state:
        email: str = ""
        loading: bool = False

    Card:
        content:
            VStack:
                Input(value := state.email)
                Button("Send"):
                    on_click:
                        state.loading = True
                        Fetch(url="/api/contact", method="POST")

4.2 DSL + 校验：Agent DSL 自我进化的基础设施

要让 Agent 构建“可交付”的 AI 生成 UI，核心过程可以压缩为六步：

1. 问题定义：AI 生成的 UI 往往“可读但不可用”，常见失败集中在结构不稳、属性幻觉、交互不可执行，以及无法做回归评估。
2. 约束表达：引入 AI 优先的 NanoDSL，用缩进结构、显式状态绑定（<< / :=）和协议化动作（NanoAction ），限制模型自由度，提升生成稳定性与安全性。
3. 编译流水线：通过 NanoDSL → AST（NanoNode）→ IR（NanoIR）→ Render（如 HtmlRenderer），将文本生成转化为可编译、可预览、可运行的结构化产物。
4. 自我验证：在生成后立即执行解析与编译校验（例如批量 validateDsl 会强制走通 parse + IR 转换），确保每一次输出至少“能编译、可预览”。
5. 持续评估：基于固定需求基准（suite + expect ground truth）和多维指标（EvaluatorRegistry ：语法/结构/组件/属性/绑定/动作/格式/冗余），对不同模型与提示词做质量回归与对比（runDslEval 会记录分数、耗时与 token）。
6. 可演进边界：以 IR 作为稳定契约，将变化限制在 DSL/Spec 与 Parser 层（例如 NanoSpecV1 + NanoParser 可替换），支撑组件、模型与 IDE 渲染端的持续演进。

结论：AI 原生架构的关键不在于“让模型更会写 UI”，而在于通过 DSL、编译与评估机制，把 UI 生成变成一条可验证、可度量、可回归的工程闭环——这才是 IDE 场景真正可交付的 AI 产品能力。

5. 结语｜让系统为 AI 的理解、修改与验证而生

Agentic 时代真正的挑战，不在于模型本身是否足够聪明，而在于我们的系统是否为一个非人类的执行者做好了准备。如果一个系统无法被 AI 安全地修改，那它本质上还停留在过去。

一个真正 AI 友好的系统，其架构必须满足三个核心原则：

1. AI 能找得到上下文：架构必须优先服务于上下文的清晰度。文档（例如 AGENTS.md）应成为 AI 理解系统的“最短路径地图”。
2. AI 能改得对：通过接口与声明式结构约束 AI 的行为。一个接口就是一份契约，它明确告知 AI 修改的范围与边界，确保操作可控。
3. AI 能验证结果：所有修改都应能被 AI 自己验证。在这里，Terminal CLI 不只是 UI，更是 AI 的输入/输出接口，让每一次修改结果都清晰可辨，形成完整的自愈闭环。

归根结底，Agentic Frontend 不是一个新框架，而是一种全新的系统观——为机器执行者而设计，让人类成为最终的监督者与受益者。