## 引言：一只龙虾引发的思考
\"帮我创建一个五一签到活动，每天登录游戏，在活动页签到送宝箱+挑战卡，累计签到 5 天额外送一个王者之殿，仅限游戏vip等级 ≥ 5 的用户参与。\"
这段话发给 WorkBuddy 后，10分钟左右——活动创建、页面搭建、签到组件配置、条件规则编排、分享参数设置、保存发布——全部自动完成。不需要拖拽，不需要填表单，不需要在多个配置面板间来回跳转。
这是我们尝试在企业级营销活动自助化平台中跑通的完整链路。龙虾之所以能精准高效地操作活动状态扭转、画布精准编辑、逻辑高效编排，**不是因为我们用了更强的模型，而是因为我们重新设计了系统本身**。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当 AI Agent 能自主规划、编排工具、生成完整营销活动时，我们需要的不再是给低代码平台加个 AI 聊天框作为副驾驶，而是一场从系统底层开始的设计范式转移——不是让 AI 去猜测学会操作系统，而是让系统主动暴露能力给 AI，让系统为 AI 而生。
\u003e **关键词**\u003e \u003e - **AI Native**：不是给系统加 AI 聊天框，而是让系统从底层为 AI 自主操作而设计\u003e - **WebMCP**：基于 W3C navigator.modelContext 提案，让前端以标准化工具协议暴露能力给 AI\u003e - **主动暴露**：系统不再让 AI 被动适配 UI，而是将能力以接口形式主动注册\u003e - **源码底座**：底层基于 JSX/AST 等标准语言协议，摒弃私有 DSL，AI 可直接理解\u003e - **Service 层**：业务逻辑从 UI 组件剥离为独立 Service，人机共享同一代码路径\u003e - **双层 MCP**：前端 WebMCP 负责画布操作，后端 MCP 负责平台操作，Skill 层统一调度\u003e - **Schema 即协议**：Formily Schema 同时驱动可视化表单渲染和 AI 参数理解，一份定义服务人机两个入口\u003e - **三层操作抽象**：L1 原子指令 → L2 语义化工具 → L3 业务 Service，AI 调用 L2 但产生 L1 记录\u003e - **CRDT 协同**：AI 操作产生与人工完全等价的协同记录，可追溯、可撤销、可审计\u003e - **Skill 设计**：分阶段暴露减少信息过载，版本号自动更新保持同步，防御性机制确保生产可靠
---
## 一、从\"拖拉拽\"到 AI 主导的Harness演进
在展开技术方案之前，有必要先厘清一个根本性的问题：**我们到底在谈论哪种\"AI + 低代码\"？**
### 1.1 三代范式对比
行业中存在三代截然不同的范式，但它们经常被混为一谈：
| | 1.0 传统低代码 | 2.0 AI Copilot | 3.0 AI Native ||:---|:---|:---|:---|| **人机关系** | 人主导，手动操作 | 人主导，AI 建议 | AI 主导，人指导 || **交互方式** | 拖拉拽 + 表单配置 | 对话生成 + 人工调整 | 自然语言 → AI 自主完成 || **AI 角色** | 无 | 副驾驶（Copilot） | 执行者（Agent） || **操作路径** | 仅人工 | AI 建议，人工执行 | AI 规划 + 编排 + 执行 || **底层依赖** | 私有 DSL / 可视化引擎 | 私有 DSL + AI 适配层 | 源码 + 语义化工具接口 |
1.0 是\"人找工具\"——用户在平台提供的组件库和配置面板中手动拼装。2.0 是\"AI 帮找\"——AI 能生成表单、写脚本，但输出仍然是平台的私有结构，用户仍需手动确认和调整。
**3.0 是范式跃迁**：AI 不再是\"能听懂会协助\"的副驾驶，而是\"自主规划、编排、按需调用工具并完成目标任务\"的执行者。平台的核心价值从\"提供可视化操作界面\"转变为\"提供底层成熟的可复用工具模块\"。
这不是渐进式升级，而是设计出发点的根本转变。
### 1.2 从\"意大利面条\"到\"扁平能力网\"
这里藏着一个更深层的认知转变：**AI 原生时代的软件到底是面向谁的？**
答案不再是\"人\"，而是\"人 + Agent\"。但可视化 UI 界面对 Agent 并不是最高效的交互方式——Agent 不需要看到一个精心设计的仪表盘，它需要的是一组清晰定义的、可直接调用的能力接口。
传统软件设计的思路是\"意大利面条\"式的：把功能做成一个个臃肿的页面、面板、弹窗、表单，层层嵌套，功能之间隐式耦合。用户（无论是人还是 Agent）必须理解整个 UI 的导航逻辑，才能找到自己想要的功能。
AI 原生的思路恰恰相反：**不再将功能做成意大利面条，而是将模块打平做细，以能力接口的形式暴露给 Agent，由 Agent 根据用户意图自主规划和调用。** 平台的核心资产从\"UI 页面\"变成了\"能力模块库\"。UI 面板仍然是人类用户的入口，但它不再是系统的唯一入口——它只是底层能力模块的一个\"视图层\"，用于方便人的可视化管控。
### 1.3 从\"被动适配\"到\"主动暴露\"
上面的对比揭示了一个更深层的认知转变。传统系统设计中，能力的组织方式是**\"人找功能\"**——功能被包裹在 UI 页面和交互流程中，外部（无论是 AI 还是其他系统）想要调用这些能力，只能\"被动适配\"：模拟人类操作、解析 UI 结构、猜测交互路径。
这种模式在 AI 时代暴露出根本性的局限：**UI 是给人看的，不是给 AI 用的。** 再聪明的 AI，面对一个只能通过截屏猜测操作的黑箱系统，理解能力也无从施展。
AI 原生的思路是反过来——**让系统主动暴露能力，而不是让 AI 被动去适配系统**。具体来说：
- **UI 从\"唯一入口\"退位为\"视图层之一\"**：人可以通过 UI 操作，AI 可以通过工具接口操作，两者地位平等- **能力从\"藏在页面里\"变为\"以接口形式注册\"**：每个能力有清晰的名称、参数定义和返回结果，不需要猜测- **操作路径从\"隐式导航\"变为\"语义路由\"**：AI 只需描述意图，协议层自动匹配到对应的能力接口
这不是一个技术优化，而是一个设计哲学的转变——**系统不再假设自己的使用者只有人类，而是从一开始就为\"人 + Agent\"两种角色设计能力入口。** 后续的 WebMCP、Service 层、Schema 协议，都是这个哲学的具体落地。
---
## 二、第一性原理：为什么 AI 原生必须基于源码？
这是整个方案最反直觉但最重要的设计决策。
### 2.1 AI 更擅长生成代码，而非 DSL
来看一个事实：Cursor、Copilot、Claude Code 等主流 AI 编程工具，在生成 JavaScript、Python、TypeScript 等流行语言的代码时非常精准。但让它们去生成某个低代码平台的私有 DSL？效果往往令人失望。
**为什么会这样？根本原因在于\"学习素材\"的差异。**
AI 生成代码之所以精准，是因为它学习了海量的代码素材——GitHub 上数十亿行的开源代码、Stack Overflow 上的问答、技术博客中的示例。LLM 对这些流行语言的语法、语义、惯用法、边界情况都有极其透彻的理解。它不仅\"知道\"语法规则，更\"理解\"语言背后的设计模式和最佳实践。
而私有 DSL 呢？它本质上只是一个**割裂的协议**，有以下几个问题：
- **JSON 格式本身没有语义化表达**。JSON 是一种通用的数据存储格式，它不表达\"如果-那么\"、\"遍历-过滤\"这样的业务语义，也不具备编程语言的组合与抽象能力。JSON Schema 的 `type: \"string\"` 只能告诉 AI \"这是一个字符串\"，但无法告诉 AI \"这个字符串是用户等级的判断条件\"。- **字段命名缺乏强制规范**。不同的开发者可能用 `cfg_01`、`tp`、`v` 这样的缩写，也可能用 `rewardType`、`threshold` 这样的语义化命名。在私有 DSL 中，字段命名往往没有强制规范约束，AI 很难推断缩写的含义。- **没有\"语法\"可言**。流行编程语言有编译器、有类型系统、有 lint 工具来保证一致性。私有 DSL 通常只是一份 JSON Schema + 若干约定俗成的规则，缺乏形式化的语法约束，连人类开发者都需要翻文档才能理解，更别说 AI 了。
\u003e 有人形象地比喻：低代码系统就像\"被锁在玻璃盒子里的应用\"——能运行，却无法进化。私有 DSL 是 AI 时代的围墙，AI 可以解析 Java/Python/TypeScript 等标准语言，但无法进入每家低代码平台的内部规则体系。
所以，**AI 原生项目的底层产物应该优先使用 AI 能理解的标准协议（如源码/AST），而非私有 DSL**。
### 2.2 但纯代码模式有企业级瓶颈
完全基于源码就万事大吉了吗？并非如此。在企业级场景中，纯代码模式面临一系列现实问题：
- **边界过于宽泛**：开发者可以写出任意代码，难以规范化行为；- **无法可视化**：非技术人员看不懂，无法参与审核和确认；- **人工检查困难**：业务逻辑散落在代码各处，人工 Review 效率低下；- **难以复用**：相似的业务功能反复造轮子；- **安全合规风险**：无法在结构层面限制高风险操作；
### 2.3 解法：三层结构（源码/模块/可视化）
我们的方案是在源码底座上做出关键的架构约束：
**底层是真实的 JSX 源码**，通过 AST（抽象语法树）来操作——插入组件是往 AST 中添加节点，修改属性是修改 AST 节点的 props，删除组件是从 AST 中移除子树。AST 如何同时服务于可视化编辑器和 AI Agent，我们会在下一节展开。
在此之上，我们将通用的、安全的、经过验证的功能封装为**业务模块**（Service 层）：礼包配置、条件规则、签到逻辑、分享策略……它们对外暴露的是语义化的函数接口，如 `configurePackage(conditionGroupId, rewardType, ...)`，而非私有 DSL 或可视化表单。
之所以这样做，是因为在自助化营销场景中，系统的使用者是不熟悉开发技术的产品运营人员，而每项业务功能背后往往牵涉多个内部系统——礼包单系统、积分系统、数据存储、条件引擎、分享中台……如果让运营人员直接操作这些系统，极易出错且难以排查。因此，我们将复杂的跨系统逻辑收敛到业务模块内部，对外只暴露简洁的语义化接口，模块内部可能是基于低代码的逻辑编排，也可能是基于源码的逻辑实现，调用方无需关心底层实现。
**AI 调用的是业务接口，模块负责操作源码。** AI 不需要理解 AST 结构就能完成业务配置，同时模块边界提供了安全约束——AI 只能通过预定义的接口操作，无法产生任意代码。
\u003e **源码让 AI 能理解，模块让 AI 能安全地操作，可视化让人能监督。三者缺一不可。**
### 2.4 基于 AST 而非私有 DSL，但不意味着让 AI 直接改代码
走到这一步，一个自然的问题是：既然 AI 更擅长生成代码，那 DSL 是否应该被彻底抛弃？
答案是：**不，在特定场景下 DSL 仍有不可替代的价值。** 关键在于区分\"私有 DSL\"和\"结构化配置协议\"。
以我们的自助化项目为例，前后端的策略截然不同：
#### 前端：基于 AST，但不让 AI 直接改代码
前端已经彻底摒弃私有 DSL，转向 JavaScript 语言的公有协议 **ESTree**（ECMAScript 标准抽象语法树）作为中间层，所有操作通过 AST 来修改前端产物。AST 作为标准化的中间协议，同时服务于两个消费方：
- **可视化编辑器**：组件树展示、节点拖拽、属性面板编辑，本质上都是对 AST 的读写- **AI Agent**：通过 WebMCP 工具接口操作 AST，完成业务配置
两者共享同一套底层协议，保证了人机操作的一致性。
但 AI 并不直接编写或修改源码，而是通过 WebMCP 暴露的语义化工具（如 `insertComponent`、`updateNodeAttributes`）来操作。原因在于，许多业务操作涉及多处代码的联动修改——比如插入一个组件可能需要同时创建文件、更新父节点引用、注册路由。让 AI 直接改源码，很容易遗漏关联步骤导致状态不一致。通过封装好的工具接口，这些复杂的联动逻辑被收敛在模块内部，AI 只需调用一个接口就能完成完整的操作链路，显著提升了稳定性。
#### 后端：保留 DSL，填补可视化缺口
后端仍然保留了 DSL 驱动的配置方式。原因在于后端没有前端的天然可视化能力——运营人员无法通过\"拖拽组件\"来配置后端逻辑，DSL 提供的可视化管控界面是他们理解和操作后端配置的唯一窗口。
\u003e 判断标准其实很简单：人是否需要直接操作这个产物？如果需要（如后端配置），用结构化的配置协议并提供可视化管理界面；如果不需要（如前端画布由编辑器和 AI 操控），则优先使用 AI 能理解的标准协议（源码/AST）。
---
## 三、零代码自助化：AI 原生的天然土壤
前面讨论的是通用性的设计原则。但有一个特定场景，天然就是 AI 原生建设的最佳落脚点——**完全零代码的自助化营销活动搭建**。
### 3.1 为什么\"零代码自助化\"比\"低代码\"更适合 AI 原生？
低代码平台面向的是有一定技术能力的开发者，需要理解组件、属性、事件绑定等概念。而自助化营销活动平台面向的是产品经理和运营人员——他们大多不熟悉开发技术，也不应该需要理解技术细节。
这意味着两个关键差异：
1. **流程高度固定化**。自助营销活动的流程是标准化的：活动创建 → 前端页面搭建 → 后端业务逻辑配置 → 测试 → 发布。每一步都有明确的输入和产出，AI Agent 可以精确地规划执行路径。2. **业务知识需要被封装**。运营人员不懂代码，但他们懂业务。平台需要将业务领域知识（如条件规则、奖品逻辑、分享策略）封装为\"条件库\"等高层抽象，让 AI 在执行意图理解和拆解时，有足够的业务上下文。
### 3.2 条件库：AI 的业务知识引擎
在我们的自助化平台上，\"条件库\"是连接业务意图和技术实现的桥梁。它封装了大量业务领域知识——用户等级判断、消费门槛、时间窗口、地区限制……每一个条件都基于 **Formily JSON Schema** 描述，包含整个条件的说明、语义化的参数定义、类型约束和校验规则。
我们设计了一套 Schema 引擎来管理条件库的注册与渲染：业务方只需按标准格式注册一个 Formily Schema，平台即可自动渲染出完整的配置表单——下拉框、输入框、日期选择器，无需额外编写 UI 代码。更重要的是，**同一份 Formily Schema 同时服务于两个消费方**：
- **人类运营**：Schema 被渲染为可视化配置表单，运营人员在界面上点选、填值- **AI Agent**：Schema 作为明确的参数协议，告诉 AI 每个字段的名称、类型、枚举值和校验规则——AI 无需猜测参数结构，按协议填值即可
Formily Schema 不只是一个 UI 渲染描述——**同一份定义同时驱动了人机两个入口，零冗余。**
以五一签到活动为例，AI Agent 在配置参与条件时，不需要\"发明\"条件逻辑，而是：
```① 理解用户意图 → \"当天登录游戏\" 且 \"VIP 等级 ≥ 5\"，识别为 AND 关系② 查询条件库 → 分别找到\"当天登录游戏\"和\"VIP 等级\"两个条件（若未命中则提醒用户接入新条件）③ 读取 Schema → 从 Formily Schema 提取参数模板（configExample）④ 填入参数 → \"当天登录游戏\"无需参数，VIP 等级填入 { \"level\": 5, \"operator\": \"\u003e=\" }⑤ 编排组合 → 将两个条件组合为 AND 关系写入配置```
如果用户的需求中涉及条件库中不存在的条件，AI 不会\"编造\"一个新条件，而是**主动提醒用户接入新条件**——\"当前条件库中没有'游戏时长'相关的条件，请联系平台管理员接入后重试\"。这保证了 AI 不会产生无效配置，也帮助平台持续丰富条件库。
\u003e **条件库的本质是 AI 的业务知识引擎——它让 AI 不需要\"理解业务\"，只需要\"查表和填表\"。**
### 3.3 流程越标准，AI 越可靠
以配置一个完整的营销活动为例，AI Agent 的执行路径是高度确定性的：
| 阶段 | Agent 行为 | 调用工具 ||:--:|:---|:---|| 活动创建 | 创建活动实例，设置基本信息 | 后端 MCP: `createApp` || 页面搭建 | 根据活动类型选择模板，插入组件 | WebMCP: `insertComponent` × N || 签到配置 | 配置累计签到天数、每日奖励、累计奖励 | WebMCP: `configureCumulativeSignin` || 业务配置 | 查询条件库，编排条件规则 | WebMCP: `getConditionDetail` → `configureConditionPanel` || 奖品配置 | 配置礼包类型、奖品池、发放规则 | WebMCP: `configurePackage` || 分享设置 | 配置分享渠道、文案、图片 | WebMCP: `configureShare` || 画布保存 | 执行客户端提交git | WebMCP: `save` || 测试发布 | 预览、保存、发布测试环境、发布正事环境 | 后端 MCP: `publish` ...... |
**流程越固定，AI 的执行越可靠。** 这是零代码自助化场景天然适合 AI 原生建设的根本原因。
### 3.4 全流程实战：一句话到上线活动
让我们回到开头的场景，完整展开\"一只龙虾上线一场营销活动\"的全链路：
**用户输入**：\u003e \"帮我创建一个五一签到活动，每天登录游戏，在活动页签到送宝箱+挑战卡，累计签到 5 天额外送一个王者之殿，仅限游戏vip等级 ≥ 5 的用户参与。\"
**AI Agent 自主执行**：
```Step 1: 理解意图 ──────────── Agent 解析需求，规划执行步骤Step 2: 创建活动 ──────────── 后端 MCP → create_appStep 3: 搭建页面结构 ────────── WebMCP → insertComponent (批量)Step 4: 配置签到规则 ────────── WebMCP → configureCumulativeSignin ├── 累计签到天数：5 天 ├── 每日奖励：宝箱 + 挑战卡 └── 累计额外奖励：王者之殿Step 5: 配置参与条件 ────────── WebMCP → getConditionDetail → configureConditionPanel ├── 查询条件库获取\"当天登录游戏\"和\"VIP 等级\"两个条件 ├── 读取 Formily Schema ├── 填入 \"VIP ≥ 5\" 参数 └── 组合为 AND 条件组写入Step 6: 设置分享策略 ────────── WebMCP → configureShareStep 7: 保存并发布 ──────────── WebMCP → save → 后端 MCP → 状态扭转```
全程 AI 自主规划、自主编排、自主执行。用户只需在关键节点确认，效率大幅度提升。这不是因为我们做了一个更聪明的 Prompt，而是因为系统从底层就为 AI 的自主操作而设计——清晰的工具语义、标准的 Schema 协议、确定性的执行路径。
---
## 四、WebMCP+Formily：告别截屏，让前端成为 AI 的一等公民
前面讨论了\"从被动适配到主动暴露\"的设计哲学，那么具体怎么落地？第一个要解决的问题是：**AI 如何操作前端？**
今天的 LLM 已经足够聪明，能够理解复杂的多步骤意图、拆解任务、规划执行路径——这不是瓶颈。**真正的瓶颈在于系统是否给到了 AI 足够清晰的能力入口。**
### 4.1 从\"截屏猜测\"到\"能力暴露\"
当前 AI Agent 对前端项目的操作能力，坦白说，还很原始。以主流的 Computer Use 方案为例：
```传统 Agent 操作前端的方式：截屏 → OCR 识别 → 猜测元素位置 → 模拟点击 → 再截屏验证 → 发现不对 → 重试...```
这种\"截屏 + OCR + 猜测\"的大量消耗Token且效率极低的模式，对简单的网页交互勉强可用，但面对一个有着复杂组件树、嵌套 props 绑定、联动条件逻辑的生产级应用，完全力不从心——它无法精准操作组件树，无法修改 props，无法读取绑定关系，更无法理解业务语义。
**WebMCP 是让前端成为 AI 生态一等公民的入口。**
WebMCP（基于 W3C `navigator.modelContext` 提案）让前端应用能够将自己的能力以标准化工具协议的形式暴露给 AI Agent：
```AI Agent 通过 WebMCP 操作前端的方式：语义化意图 → 调用精确的工具接口 → 直接操作组件树/修改 props/读写配置 → 确定性结果```
不再猜测，不再重试。**AI 知道自己能做什么、参数是什么、结果会是什么。**
### 4.2 前端架构的范式升级：从表单收集到服务暴露
传统的前端不仅是\"表单数据收集器\"，更承载了**用户与系统之间的连接器**角色——用户的所有操作都必须通过前端 UI 这个唯一入口才能触达系统。在这种架构中，业务逻辑散落在 React 组件的 onChange 回调里，与 UI 渲染深度耦合，外部无法调用。
AI 原生时代，前端架构需要从\"表单收集\"升级为\"**服务暴露**\"：
关键变化：**业务逻辑从 UI 组件中剥离，下沉为独立的 Service 层**。10 个 Service 同时服务于 Setter UI 和 WebMCP Agent，零重复代码，人机行为路径完全一致。当 AI 调用 `configurePackage` 和人类在面板中点击保存，走的是同一段代码、产生的是同样的操作记录。
### 4.3 Formily Schema：不只是表单，更是 AI 的参数协议
Formily JSON Schema 在前端领域是成熟的表单渲染协议——定义字段类型、布局结构、联动规则，驱动 UI 表单的自动渲染。但它的价值远不止于此：**Formily Schema 天然具备描述\"参数结构\"的能力**，这恰好是 AI 理解和操作一个系统所需要的信息。
传统上，表单 Schema 是\"写给 UI 的\"——AI 不需要知道\"用哪个下拉框组件渲染\"，它需要知道的是：**这个参数叫什么、是什么类型、有哪些可选值、约束条件是什么。** 而一份标准的 Formily Schema 恰好包含了这些信息：`type` 定义类型、`enum` 限定可选值、`pattern` 约束格式、`title` 和 `description` 提供语义描述。
因此，我们选择 **Formily Schema 作为前端能力暴露的统一协议**——不仅是表单渲染协议，更是 AI 与系统之间的通信协议。`type` 定义类型、`enum` 限定可选值、`pattern` 约束格式、`title` 和 `description` 提供语义描述，AI 基于这些信息就能准确拼出严格符合要求的参数 JSON，无需猜测，也无需额外适配。
### 4.4 语义化命名：名称即协议
还有一个容易被忽视但至关重要的设计：**字段名的语义化**。
```typescript// ❌ 传统命名：AI 需要猜测含义{ \"cfg_01\": 1, \"tp\": 3, \"v\": \"abc\" }
// ✅ 语义化命名：名称即协议{ \"packageType\": \"signin_reward\", \"rewardCount\": 10, \"conditionGroupId\": \"user_level_check\" }```
当字段名本身就能传达含义时，AI 不需要查文档就能理解参数结构。**这不是代码风格问题，而是 AI 原生时代的设计范式问题。** 语义化的字段名、清晰的工具描述、标准化的 Schema 格式——这些构成了 AI 与系统之间的通信协议。
### 4.5 Skill 统一调度：前后端 MCP 各司其职
平台能力暴露不只在前端。在营销活动搭建场景中，操作天然分为两层：
- **平台级操作**（后端）：创建活动、查询配置、发布上线、状态扭转- **画布级操作**（前端）：插入组件、修改属性、配置业务规则、管理页面
这两层操作的运行时不同（后端 vs 浏览器）、权限模型不同、状态管理不同。如果强行统一到一层，必然带来复杂的代理和同步问题。
**双层 MCP 是自然的解决方案**：
```AI Agent │ ├─► 后端 MCP Server (Go, Streamable HTTP) │ ├── create_app 创建活动 │ ├── get_page_config 查询页面配置 │ └── publish / offline 发布 / 下线 │ └─► 前端 WebMCP (浏览器内, W3C navigator.modelContext) ├── 画布操作 insertComponent / moveNode / updateNodeAttributes ├── 逻辑配置 configurePackage / configureConditionPanel ├── 组件配置 configureSingleSignin / configureCumulativeSignin └── 项目管理 save / undo / listPages```
对 AI Agent 来说，它不需要知道哪个操作走后端、哪个走前端。在 Skill 层，我们按业务场景（如\"配置签到活动\"）将前后端 MCP 工具组织在一起，Agent 只需关注当前步骤的语义意图，由 Skill 自动路由到对应层的工具接口。**前后端 MCP 各司其职，Skill 层统一调度。**
### 4.6 WebMCP 工具全景
前端 WebMCP 面临一个独特的挑战：LLM 运行在 Agent 进程中，但画布运行在浏览器中，两者隔着进程边界。
我们在画布页面中注入了一个 `__webMcpBridge__` 桥接对象，实现了完整的 MCP 工具注册和调用协议。当浏览器支持 W3C 的 `navigator.modelContext` API 时使用标准接口，否则自动降级到 `window.__CTOOL_WEBMCP_TOOLS__` 全局对象。
76 个工具覆盖了画布操作的完整语义空间：
| 类别 | 数量 | 代表性工具 ||:---|:---|:---|| 节点/树查询 | 8 | `ctool_getNodeTree`, `ctool_getSelectedNode` || 组件 CRUD | 8 | `ctool_insertComponent`, `ctool_moveNode` || 页面/弹窗管理 | 6 | `ctool_addPage`, `ctool_switchPage` || 配置读写 | 4 | `ctool_updateNodeAttributes` || 礼包/分享/按钮 | 6 | `ctool_configurePackage`, `ctool_configureShare` || 条件面板/变量 | 5 | `ctool_configureConditionPanel` || 签到/预约 | 5 | `ctool_configureSingleSignin` || 项目资产查询 | 10 | `ctool_listPages`, `ctool_listComponents` || 撤销/重做/保存 | 4 | `ctool_undo`, `ctool_save` || 图片资源/系统 | 5 | `ctool_uploadImageByUrl` |
---
## 五、操作粒度的分层设计：AI 操作可CRDT协同追溯，底层细节不暴露
如何定义 AI 的\"操作粒度\"？这是 AI 原生系统设计中最微妙的平衡。
太细（直接操作 AST 节点），AI 需要理解内部数据结构，容易出错、幻觉频发；太粗（只提供\"创建活动\"这样的大粒度操作），AI 失去灵活性，无法处理细节调整。
我们的答案是**三层抽象**：底层是原子操作指令，中间是语义化的业务工具，上层是面向人类的 Service。三层各自职责清晰，但有一个共同的设计目标——**AI 的每一步操作都像人类操作一样，可追溯、可撤销、可协同。**
### 5.1 【L1】原子操作层
50+ 种枚举类型，每种操作产生一条 CRDT 协同记录。这是系统的\"指令集\"：
```typescript// 文件操作AddFile | RemoveFile | RenameFile | UpdateCode// 视图操作AddPage | UpdatePage | RemovePage | AddFragment | RemoveFragment// 配置操作UpdateCtoolConfigJsonFiled | UpdateCtoolNocodeConfigJsonFiled// 状态操作AddStoreState | UpdateStoreVariable | RemoveStoreState```
每一条记录都携带 `clientId`、`userId`、时间戳、操作类型。无论操作来自人工还是 AI，记录格式完全相同——天然支持多人协同、操作回放和撤销。
### 5.2 【L2】业务操作层（WebMCP 工具）
76 个语义化工具，是原子操作的**编排组合**。例如：
- `ctool_insertComponent` = `AddFile` + `UpdateCode`（创建组件文件 + 更新父节点引用）- `ctool_moveNode` = `removeNode` + `insertComponent`（先删后插，保证树结构一致性）- `ctool_updateNodeAttributes` = 自动路由到 AST 或 `nocode.json`（根据属性前缀判断写入目标）
AI 调用的是 L2 工具，但产生的是 L1 记录。**AI 不需要理解底层数据结构，但它的每一步操作都被完整记录、可撤销、可协同。**
### 5.3 【L3】Service 层
这一层在上文\"服务暴露\"中已经展开。它的核心价值是：**人机行为路径完全一致，零重复代码，零行为差异。**
### 5.4 CRDT：让可追溯成为现实
三层抽象为\"可追溯\"提供了结构基础，而真正让它落地的技术手段是 CRDT。我们使用 Yjs 作为 CRDT 引擎，当 AI 调用 `ctool_insertComponent` 时，底层产生的操作记录与人类拖拽组件时完全相同——只是 `clientId` 标识为 AI。这意味着：
1. **实时可见**：其他协作者能实时看到 AI 在添加组件2. **可撤销**：AI 的操作可以逐步回滚3. **无冲突**：CRDT 保证 AI 操作与人工操作不会冲突4. **可审计**：所有操作记录可用于复盘和合规检查
\u003e **AI 不是系统的\"外挂\"，而是系统的\"协作者\"。** 它产生的每一条操作记录，与人类用户在协同语义上完全等价。
---
## 六、Skill 设计：分阶段暴露与防御兜底
前面介绍了 WebMCP 的能力暴露和双层 MCP 的调度架构，但有了 76 个前端工具 + 后端 MCP 工具，直接丢给 AI 并不能保证好的效果。Skill 的设计质量直接决定了 Agent 的执行准确性和效率。
### 6.1 分阶段暴露：从核心入口到按需扩展
76 个 WebMCP 工具如果全部注册到 Skill 中一次性暴露给 Agent，不仅消耗 Token，更严重的是**信息过载导致 AI 选择困难**。
我们的解法分两层：
**第一层，核心入口暴露**：Skill 只注册少量核心查询入口（如节点树查询、组件列表、页面列表），引导 Agent 在执行过程中通过这些入口**按需获取**当前场景所需的工具定义，动态扩展可调用的能力集合。这种策略与**渐进式披露**理念不谋而合——先给最关键的入口，按需展开更多能力。这样做的好处是：**Skill 定义无需随工具增减频繁更新，Agent 始终能获取到最新的可用工具，两者的维护完全解耦。**
**第二层，版本号感知与自动更新**：核心入口虽少，但入口本身的参数格式或语义也可能随平台迭代而变化。我们在每个核心入口中引入了版本号机制——Skill 中记录的入口版本与平台当前版本不一致时，Agent 会自动拉取最新版本的入口定义并更新 Skill，确保入口描述和参数始终与平台实际能力保持同步。
**第三层，场景化聚焦**：在 4.5 中提到，Skill 按业务场景将前后端 MCP 工具组织在一起。更进一步，针对每个场景步骤，Skill 只暴露与当前步骤直接相关的 3-5 个工具，而非整个场景的全部工具。例如\"配置签到活动\"场景下，Agent 在配置参与条件这一步，只需要看到 `ctool_getConditionDetail` 和 `ctool_configureConditionPanel`——签到配置、分享设置等工具在此时反而是噪音。
**核心思路：Agent 先通过少量入口定位到当前场景，再在场景内聚焦到当前步骤的 3-5 个工具。版本号机制保证入口始终是最新的，按需查询保证场景工具始终是完整的。每一步都只有最相关的选项，决策更精准，执行更高效。**
### 6.2 防御性设计：让 Agent 失败可控、数据可信
Skill 的精心组织能大幅提升成功率，但生产环境中仍需要兜底机制。我们设计了两个关键的防御性策略：
**失败限速**：Agent 执行过程中难免出错，但错误修复不能无限重试——这不仅浪费 Token，更可能导致系统状态不可控。我们设计的限速机制是：最多两轮自动修正，超出立即转人工。这个规则确保了 Agent 不会陷入\"试错循环\"，也保证了用户体验——用户不会等了半天发现 Agent 在反复撞墙。特别地，如果失败原因是接口报错（而非参数错误），Agent 会在转交人工时附上完整的错误信息和调用链路，帮助人类快速定位问题。
**数据时效管理**：条件库中的条件不是永久有效的——某些条件依赖的后端服务可能会下线或调整。如果 AI 在不知情的情况下使用了已失效的条件，生成的活动配置在生产环境会直接报错。我们在条件库中引入了有效期机制：每个条件都有 `validTime` 字段，AI 查询条件列表时优先展示当前有效的条件；如果用户的需求必须使用某个已过期的条件，AI 会主动提示用户联系管理员续期。这从机制上杜绝了 AI 使用失效条件的可能性。
**核心思路：Skill 让 Agent 做对，防御性设计确保 Agent 失败时不会\"失控\"。**
---
## 写在最后：让系统为\"人 + Agent\"而生
回顾全文，从范式认知到底层架构，从前端能力暴露到操作粒度分层，再到 Skill 调度策略，我们提炼出 6 条核心设计准则：
1. **源码底座，减少私有 DSL** — 底层尽可能基于 AI 能理解的标准语言（JSX/AST），将通用功能封装为安全可复用的业务模块，既保持 AI 的理解能力，又提供企业级的约束和可视化。
2. **模块打平，能力暴露** — 不再将功能藏在层层嵌套的 UI 页面里，而是将模块打平做细，以标准化接口暴露。UI 面板退位为底层能力的\"视图层之一\"，Agent 通过接口自主规划和调用。
3. **主动暴露，而非被动适配** — UI 是给人看的，不是给 AI 用的。通过 WebMCP 将前端能力以标准化工具协议暴露，通过 Service 层将业务逻辑从 UI 中剥离，让系统主动告诉 AI：我能做什么、需要什么参数。
4. **Schema 即协议，名称即语义** — Formily Schema 不只是表单渲染描述，更是 AI 与系统之间的通信协议。配合语义化的字段命名，AI 无需猜测参数结构，按协议填值即可。
5. **人机路径一致，CRDT 协同** — AI 调用的工具和人类操作走同一条代码路径，产生完全等价的 CRDT 协同记录。AI 不是系统的外挂，而是与人类平等的协作者。
6. **精心组织，防御兜底** — Skill 层通过分阶段暴露减少信息过载、通过场景化聚焦提升精准度，再辅以失败限速和数据时效管理等防御性机制，确保 Agent 在生产环境中可靠运行。
这 6 条准则源于零代码自助化营销活动场景的实践，但它们的适用范围远不止于此。**任何强交互式的 Web 应用**——设计工具、数据编排平台、CMS、IDE 插件——都面临同样的问题：系统的能力藏在 UI 里，AI 只能靠截屏猜测。
AI 原生不是给系统加一个 AI 聊天框，而是一种系统设计哲学——**从\"为人设计界面\"到\"为人 + Agent 暴露能力\"**。这不意味着抛弃可视化，而是意味着系统的架构必须同时回答两个问题：人类用户如何精准操作？AI Agent 如何理解和调用？
\u003e 不再将功能做成意大利面条，而是将能力打平暴露给 Agent。\u003e \u003e 不再让 AI 猜测系统，而是让系统主动告诉 AI 能做什么。\u003e \u003e 不再为 AI 适配系统，而是让系统成为 AI 的一等公民。
**AI 原生不是一个功能，而是一种系统设计哲学。**
