从菜单到技能，从页面到 A2UI：AI 原生开发平台的分层架构与双智能体工程

分层架构 · A2UI · 双智能体工程 ｜ 基于真实平台重构实践 ｜ 2026-10-26

一、引言：AI 原生 ≠ 给 IDE 加一个助手二、企业级架构纲领：A / B / C 三层三、统一界面协议：从 Generative UI 到 A2UI四、B 层：注解即模型，声明即配置五、C 层与沙箱：独立编译，独立发布六、双智能体：开发管理智能体与编码智能体七、技能中心与流程编排：菜单是技能的投影八、案例一：一个智能体（技能）的诞生九、案例二：一次 Web 软件工程的端到端交付十、反思与展望：三个回潮信号参考资料

# 从菜单到技能，从页面到 A2UI：AI 原生开发平台的分层架构与双智能体工程

本文基于一个企业级低代码 + 智能体平台的真实重构实践写成。为降低阅读门槛，产品内部称谓已统一替换为通用术语（如「视图描述文件」「统一对话工作台」「开发管理智能体」等），技术标识（loader.path、SC_SKILL 等）作为工程证据保留。全部界面截图来自平台真实运行环境。

一、引言：AI 原生 ≠ 给 IDE 加一个助手

过去两年，「AI 原生开发」在很大程度上被做成了一场 IDE 插件竞赛：代码补全、侧边栏 Chat、内联修复。这些能力确实提升了工程师写代码的速度，但对于企业级平台而言，它们没有触及真正的问题——从需求到交付的整条链路里，写代码只占一小部分，剩下的是界面搭建、配置声明、权限挂接、菜单发布这些「工程税」。

我们对自己平台的交付记录做过复盘：一个中等复杂度的业务模块，从需求确认到可上线，纯粹的编码工作往往不到三成；其余时间花在了「让页面能点、让数据能存、让菜单能见」上。如果 AI 只加速那三成，整个交付周期几乎不会变化。

所以，「AI 原生」必须是一个架构命题，而不是一个工具命题。我们的答案是三个根本性转变：

这三个转变不是并列的功能点，而是同一场重构的三个切面：技能改变了「交付什么」，A2UI 改变了「交付物的形态」，双智能体改变了「谁来交付」。而把三者粘在一起的，是一套 A/B/C 三层架构纲领。下文将按这个逻辑逐层展开。

二、企业级架构纲领：A / B / C 三层

所有企业级平台最终都会撞上同一堵墙：变化频率的冲突。平台底座要稳定（否则无法承载多租户），客户需求要快速响应（否则丢单），业务逻辑要频繁迭代（否则失去生命力）。把这三种节奏塞进同一组模块里，结果一定是「改一处、动全身」——这正是传统「菜单 + 模块」架构在 AI 时代显式失灵的第一原因。

我们的解法是按变化频率切出三层：

A/B/C 三层架构：按变化频率切分，右侧为分层判据与依赖红线

• A 层 · 平台基线（月级节奏）：模板与编译、注册机制、视图描述文件（UI Schema）的序列化、端口与契约（SPI）、领域语义模型、服务注册总线。它由平台团队统一升级，全租户一致，是所有上层赖以运转的「物理定律」。
• B 层 · 领域宿主（客户周期节奏）：这一层最容易被误解，它不是「业务代码」，而是模型层——以 Java 注解承载实体与视图契约，以 YAML 承载运维面配置。它随领域包按客户实施节奏安装。
• C 层 · 业务实现（天级节奏）：场景服务、编排逻辑、以及实现 B 层契约的 APIImpl 类。它是唯一允许（也应当）频繁变化的一层。

分层最有价值的是一个可以口口相传的判据，我们把它压缩成一句话：

能被平台反射读取的元数据，必须写在注解里；与类无关、客户可改的运维配置，必须放在 YAML 里；任何「拼装产物」的代码，都不许留在 C 层。

三条依赖红线与之配套：B 不得依赖 A 的生成器；C 不得反向依赖 A 的内部实现（只能走端口与契约）；装载顺序固定为 A → B → C，由 -Dloader.path=lib,lib/domain,lib/biz 在运行期强制固化，并有构建门禁脚本持续校验。

这套分层的直接收益是发布节奏的解耦：A 层月级升级不阻塞 C 层当天交付；反过来，C 层的天级迭代也永远不会把风险传染给平台基线。后文的双智能体分工、沙箱验证、独立发布，全部建立在这个结构性前提之上。

三、统一界面协议：从 Generative UI 到 A2UI

界面的「AI 原生化」有一条清晰的术语谱系，厘清它，才能避免概念的真空转：

Generative UI 术语谱系：伞形范式 → Agentic UI → A2UI 协议，附四原则与时间线

• Generative UI（生成式界面）是伞形范式，覆盖一切「由模型参与产出界面」的形态，从早期语音助手的动态卡片到今天的大模型动态表单；
• Agentic UI（智能体驱动界面）是其中以智能体为中心的交互形态：对话即操作，界面在多轮交互中动态生成；
• A2UI（Agent-to-UI）则是 2026 年崛起的开放协议——由 Google 主导，2026 年 4 月发布 v0.9，已有 v1.0 规范。它把「智能体画界面」从各家私有的玩法，变成了可互操作的标准。

A2UI 协议有四条原则，恰好与我们平台的既有设计一一对应：智能体产出 JSON 结构化界面描述而非可执行代码；客户端用自有组件目录渲染；UI 结构与应用数据分离；不经信任边界执行任意代码。这说明协议化的界面描述是行业收敛方向，而不是我们的标新立异。

平台内部对应物是「视图描述文件」：一份 JSON 形态的 UI Schema，由 children 结构树、components 组件池、header 列表列与 APICaller 数据调用四部分组成。它与 A2UI 的精神完全同构——界面是数据，不是程序。语义组件（列表、表单、树表、分页栏、数据调用器）就是「客户端组件目录」在平台侧的实现。

统一对话工作台：左栏自然语言对话，右栏工作区承接技能产出的界面与文档

在交互入口上，平台提供统一对话工作台：左栏是与智能体的连续对话，右栏是工作区。值得强调的是右栏内容的来源——它不由前端硬编码，而由技能的 ui.panel 声明驱动。这正是 Generative UI 谱系里「渲染端只认协议、不认业务」的落地形态：智能体（或技能）声明它需要什么样的面板，工作台负责装配。

四、B 层：注解即模型，声明即配置

如果说 A/C 分层解决的是「节奏冲突」，那 B 层的设计解决的是「模型放在哪」的问题。传统平台把模型散落在数据库表结构、前端页面配置和后端代码三处，三处漂移是低代码平台一切诡异 Bug 的总根源。我们的答案是两句话：注解即模型，声明即配置。

Code-to-UI 全链路：从 Java 注解到 UI Schema 的四步流水线，右侧为编译双路径与运行期五步法

注解即模型。B 层以三类 Java 注解承载全部可被反射读取的元数据：

• 实体注解：@DBTable、@DBField、@Uid——只服务持久化，不参与前端；
• 视图注解：@Aggregation、@ModuleAnnotation、@TreeGridRowCmd 等——视图构建器直接读取它们装配界面；
• 动作注解：@APIEventAnnotation——动作入口由它驱动，是「按钮为什么出现」的唯一答案。

为什么必须用注解而不是另立模型文件？因为反射装配的口径是「注解成员名 == 实体字段名」，注解与类同生共死，天然杜绝漂移。一旦模型另存他处，就会出现「列不显示查 DBField 却一无所获」这类事故——列表列实际来自视图注解的装配链。

声明即配置。与类无关、客户必然要改的东西——模块清单与菜单树（modules.yaml）、字典项（dicts/*.yaml）、角色权限矩阵（authz/roles.yaml）、发布清单（release/bundles.yaml）——全部放在 YAML。它们不参与编译，改完即生效，客户实施团队可以自助维护。

两条路线相乘，得到平台最核心的资产：Code-to-UI 链路。注解经反射装配成领域语义模型（类级契约、方法配置、字段聚合三件套），语义模型映射到语义组件，视图构建器再把语义组件序列化为 UI Schema。整条链路有一个强验收口径：产物在 workspace、versionspace、export 三个地址的 MD5 必须一致——任何一处不一致，都意味着有人绕过链路直改了产物。

工程上有两处细节值得记录，它们决定了这条链路在实战中是否可靠：

1. 编译双路径，互不替代：模型产物走常规编译器；注解页源码必须用内存 javac 直接编译到 target/classes。判定「编译真的发生了」的口径不是看日志，而是看 .class 文件是否新增。
2. 运行期激活五步法：内存编译 → 动态加载 → 字节码挂入 ClassPool → 注册契约接口类 → 重建动态类注册表。顺序敏感，缺任何一步的典型症状都是同一句报错：MethodConfig not found。

B 层设计器完成态：语义组件已装配成页，布局与绑定全部落在注解与声明上

表单对齐校验：标签格与输入格的网格契约由链路自动保证，而非人工微调

Code-to-UI 产物闭环：设计器产出的页面在运行态可点、可存、可查，三地址产物一致

这套链路的意义在于：界面不再是被「画」出来的，而是被「推导」出来的。注解是公理，语义组件是定理，UI Schema 是证明——谁改了公理，重新推导一遍即可，永远不存在「页面与代码对不上」的问题。这也为第三章的 A2UI 愿景补上了地基：当智能体要「写」一个界面时，它写的不是像素，而是这条链路最上游的注解与声明。

五、C 层与沙箱：独立编译，独立发布

C 层的纪律只有一条：只写实现，不碰产物。场景服务、编排逻辑、APIImpl 实现类——能删掉生成器残留拼装代码（例如历史遗留的「页面拼装类」），是这次重构中最艰难也最值得的手术：拼装产物属于 A 层的视图构建器，C 层一旦沾手，「天级节奏」就会把半成品污染到所有上层。

与 C 层配套的是沙箱——平台唯一的执行主体。它是一个独立进程（独立端口），承担编译、注册、运行验证的全部职责：

C 层独立编译与发布：开发态不落平台进程，沙箱承担执行，三层发布节奏互不阻塞

沙箱有四个关键机制，都是实战教训换来的：

• 动态类恢复：动态类只活在运行期注册表里，进程重启即失。恢复服务在启动时扫描各工程的编译产物目录并重新注册，页面才能恢复数据能力。配套纪律：重启前必须把编译产物复制进沙箱实例目录，否则「页面壳在、数据接口全 404」。
• 模板与静态资源的磁盘口径：页面壳模板与静态资源走磁盘覆盖，改动即时生效，无需重打包——这让「改一个标签」从十分钟级降到秒级。
• 会话预热：启动参数注入管理员会话，避免数据接口在未登录态下集体报错。这是不改鉴权代码前提下的保守方案。
• 元数据缓存对齐：VFS 缓存如果残留旧包名，会静默「复活」旧页面——空壳视图文件的排查顺序应当是先查缓存、再查代码。

沙箱运行态实测：独立进程中完成编译注册后，页面真实出数、动作可用

CRUD 闭环实测：列表出数、弹窗录入、保存回显——C 层交付的验收口径就是这条闭环

运行态动作按钮：每个动作必须同时有 UI 入口与数据调用，缺一即为不可达

发布节奏上，三层彻底解耦：A 层月级统一打包升级；B 层领域包按客户实施节奏安装；C 层业务实现当日修改、当日验证、当日发布。验收口径还有一条容易被忽略的细节：模块首次访问会触发建表与初始化（约 20 秒），之后稳定在毫秒级——「静置十秒仍是空表」不能判为故障，必须计入预热再复测。这些纪律琐碎，但正是它们把「沙箱」从一个测试环境变成了工程管道上可信的一环。

六、双智能体：开发管理智能体与编码智能体

引入智能体时，我们最初把「会写代码的 AI」当成了全部。很快发现不对：能写代码的智能体到处都是，能把工程管起来的智能体几乎没有。业界对 Agentic SDLC（智能体主导的软件工程）的讨论也收敛到同一结论：需要 Orchestrator（编排者）与 Coding Agent（编码者）的角色分工，前者负责规划、派发、质量门禁与进度，后者按计划实现，测试阶段再由测试智能体与隔离执行环境兜底。

我们把这套分工落成了三个实体：

双智能体与沙箱的协作全景：开发管理智能体规划防护、编码智能体生成实现、沙箱执行验证

开发管理智能体（Orchestrator）——偏向工程管理。它的职责清单读起来更像一个技术项目经理：

• 三问对齐：开工前强制回答「做什么、改哪里、怎么验收」，把自然语言需求收敛为可执行规格；
• 规划与派发：任务拆解后指派编码智能体，并以页面注册表（page_registry）追踪每个页面的归属、入口与状态；
• 写侧防护：所有写操作四闸把关——dry-run 预演、.oodbak 备份、一键回滚、越权路径直接拒绝；
• 环境巡检：启动预检与健康探针持续盯沙箱状态（端口、会话、编译产物）。

编码智能体（Coding Agent）——偏向纯实现。它是一个独立节点（经 A2A 协议接入），不问需求、只接规格：接收任务后调用模板化生成服务（FTL 模板渲染代码与声明骨架），按编译构建配方（recipe）一条龙完成编译与构建，产物写回虚拟文件系统。它不承载任何「工程决策」——这是刻意的：决策权集中在开发管理智能体，实现权下放编码智能体，二者通过规格与产物解耦。

沙箱——唯一执行主体。这里必须澄清一个容易混淆的关系：开发管理智能体不直接执行任何编译或运行动作。它通过探针观测沙箱，通过运行证据（页面可点、数据可存）确认结果，通过注册表追踪进度。执行权与规划权的分离，让「智能体失控」的风险被压缩到沙箱边界内——就算某个任务跑飞了，炸的也只是那个独立进程。

编码智能体工作台：按规格生成代码骨架与声明文件，编译构建一次跑完

生成产物示例：模板渲染出的实现类与契约一一对应，不做任何「自由发挥」

这套分工的直接收益是人的注意力重新变得昂贵而稀缺：人只出现在「提需求」和「验收」两个节点上，规划、实现、验证、防护全部由双智能体与沙箱接力。下一章的技能中心，则解决「接力成果如何变成可分发的产品」。

七、技能中心与流程编排：菜单是技能的投影

传统平台的功能分发靠「菜单管理」：管理员建菜单、绑权限、配角色，三张表互相牵制，客户每上一个新功能都要走一遍人工配置流程。AI 原生平台的分发单元变了——一切可安装、可授权、可调用的东西都是技能。

技能中心全景：四类技能、南北向状态机、授权单一真源与菜单投影机制

技能分四类：CAPABILITY（能力，如文档、问答、数据、浏览器）、TOOL（可调用的原子工具）、SCENE（面向任务的组合场景）、APP（低代码作品——页面、表单、流程、报表）。注意最后一类：前文所有章节的产出物，最终都以 APP 技能的形态进入分发。三层架构生产「物」，双智能体生产「活」，技能中心把两者变成「商品」。

生命周期是一条南北向状态机：注册（上架目录）→ 安装（租户级实例化）→ 授权（激活）→ 可见（菜单出现）。配两句口号式的口径：安装即上架，授权即可见。

这里最重要的设计决策是：菜单不是一张表里的一行记录，而是技能声明的实时投影。菜单树由「已安装 ∩ 已授权」技能的 menus 声明即时装配，管理端只能做排序与改名覆盖，不能凭空造菜单。删掉声明，菜单同步消失——权限、可见性、分发从此只有一个真源（Grant 授权模型：主体 × skill 域 × 操作集），不再存在「角色菜单表」与「技能授权表」打架的问题。存储侧由节点表、技能表、声明表、安装实例表四张表支撑，全部带租户列实现多租户隔离。

技能市场：目录即货架，安装动作产生租户级实例

应用中心：菜单树由已安装且已授权的技能实时投影而来

流程编排（BPM）在这个体系里不是独立王国，而是技能的一种实现形态：审批流的节点、路由、监听器在画布上编排，画布产物同样遵循「声明即配置」的口径，最终随技能包发布。从用户视角看，一个「报销审批」技能 = 页面 + 流程 + 权限的打包体；从平台视角看，它只是 SC_SKILL 表里的一行声明加一组制品。

八、案例一：一个智能体（技能）的诞生

把前面的构件串起来，看第一个端到端案例：用一句话交付一个「读书笔记」技能。

案例一泳道图：从一句话到菜单可见的七步接力，人工只出现在首尾

完整链路七步：用户在工作台说「做一个读书笔记技能，能记、能查、能分享」；开发管理智能体三问对齐后拆解任务并注册页面清单；编码智能体按规格生成代码骨架与声明文件并写回虚拟文件系统；沙箱完成编译、注册、构建视图与运行验证（页面可点、数据可存）；开发管理智能体汇总运行证据，产出技能声明（能力清单、菜单声明、面板声明）；技能中心把成品注册上架；最后租户管理员安装、授权，菜单自动出现，用户在右栏打开即可使用。

对话工作台发起：需求以自然语言进入，全程不需要打开 IDE

安装授权后的最终态：工作区菜单即时新增两项——投影实时生效

这个案例刻意选了「技能开发」而非「业务开发」，因为它是对平台自举能力（bootstrapping）的检验：平台自身的新功能，也走同一条对话 → 生成 → 验证 → 分发的管道。当工具、场景、应用三类技能都能被这条管道生产时，「平台进化」与「用平台交付业务」就合并成了同一件事。

九、案例二：一次 Web 软件工程的端到端交付

第二个案例回到经典场景：给教学域新增一个「作业管理」模块——真实的 Web 软件工程，涉及数据建模、界面、权限、流程四条线。

案例二泳道图：注解 + 声明 + 实现三线并进，沙箱验证闭环，流程编排收尾

与前一个案例的本质区别在于：这里产出的是带数据模型的完整模块，因此三层架构的强制性开始显形——

• 需求方一句话进入后，开发管理智能体先做领域建模规划：识别聚合（作业、学生、班级）、定视图形态（列表 + 表单）、定权限矩阵与字典；
• B/C 层产出分三线：B 层的实体与视图注解载体、模块/字典/权限三份 YAML 声明，以及 C 层的 APIImpl 业务实现；
• 沙箱执行 Code-to-UI：构建视图产出 UI Schema，三地址 MD5 一致校验通过后，动态类注册进运行时；
• 随后是 CRUD 闭环验证——列表出数、表单可存、字典码值显示文本、权限矩阵生效，四项全绿才算过关；
• 若涉及审批（如「批改」需要流转），流程编排画布接管：节点、路由条件、扩展监听器全部画布化，产物随模块一起走门禁发布。

运行态实测：作业列表真实出数，行命令与工具栏动作全部可达

流程定义工作台：节点与路由在画布上编排，声明随模块发布

值得对照的是时间结构：过去这类模块以「周」为单位（建模一天、搭页面两天、调权限一天、联调两天）；在双智能体管道下，结构化工作量被压缩到小时级，而人的时间几乎全部花在两处——开工前的三问对齐，与收尾时的闭环验收。效率的提升不是来自打字变快，而是来自「工程税」的消失。

十、反思与展望：三个回潮信号

重构一年后，有三个曾被我们判为「旧时代残留」的东西，以新形态回潮了。它们不是倒退，而是提醒。

菜单的回潮。我们曾以为对话入口终将取代菜单，但用户行为数据说：绝大多数人打开平台后的第一个动作仍是「看菜单」。这不矛盾——对话是创建的入口，菜单是存量的地图。菜单以技能投影的形态回潮，恰恰说明「可发现的、稳定的、不需要思考的导航」是永恒需求。教训是：投影必须实时准确，一条「安装了却看不见」的技能，对用户信任的损伤远大于少一个功能。

代码的回潮。声明式与生成式覆盖不了最后 20% 的需求——特殊的校验、古怪的集成、性能敏感的路径。我们一度想用更多 DSL 把这 20% 也收编，结果 DSL 本身成了新的技术债。C 层「永远为手写保留」是这次重构里最反直觉、也最正确的决定：AI 原生不是消灭代码，而是消灭代码的搬运。当编码智能体能把样板代码全部接走，剩下的手写代码反而回归了它本来的价值密度。

人的回潮。写侧防护做得再完善（预演、备份、回滚、越权拒绝），我们仍然把「授权」与「验收」钉死在人手上——授权决定别人能用什么，验收决定什么算做完。这两个动作不可代理，因为它们本质上是责任的签署，而责任无法委托给一个没有主体资格的智能体。

展望下一程：A2UI v1.0 规范的生态成熟后，平台可以引入第三方组件目录，让「智能体产出 + 多端渲染」真正跨出单体平台；技能市场需要补上治理三件套（审计、限额、停用），让分发规模化的同时可控；双智能体体系则会迎来第三个角色——测试智能体，把「闭环验证」从人工口径升级为可持续回归的自动化证据链。

回到标题：从菜单到技能，是交付单元的进化；从页面到 A2UI，是交付物形态的进化；从人工到双智能体，是生产关系的进化。三者叠加，才是「AI 原生」相对于「IDE 加助手」的完整含义——不是让开发者更快地敲键盘，而是让工程本身长出新的骨架。