引言：一只龙虾引发的思考

"帮我创建一个五一签到活动，每天登录游戏，在活动页签到送宝箱+挑战卡，累计签到 5 天额外送一个王者之殿，仅限游戏vip等级 ≥ 5 的用户参与。"

这段话发给 WorkBuddy 后，10分钟左右——活动创建、页面搭建、签到组件配置、条件规则编排、分享参数设置、保存发布——全部自动完成。不需要拖拽，不需要填表单，不需要在多个配置面板间来回跳转。

这是我们尝试在企业级营销活动自助化平台中跑通的完整链路。龙虾之所以能精准高效地操作活动状态扭转、画布精准编辑、逻辑高效编排，不是因为我们用了更强的模型，而是因为我们重新设计了系统本身。

01.jpg

当 AI Agent 能自主规划、编排工具、生成完整营销活动时，我们需要的不再是给低代码平台加个 AI 聊天框作为副驾驶，而是一场从系统底层开始的设计范式转移——不是让 AI 去猜测学会操作系统，而是让系统主动暴露能力给 AI，让系统为 AI 而生。

02.jpg

关键词

  • AI Native：不是给系统加 AI 聊天框，而是让系统从底层为 AI 自主操作而设计

  • WebMCP：基于 W3C navigator.modelContext 提案，让前端以标准化工具协议暴露能力给 AI

  • 主动暴露：系统不再让 AI 被动适配 UI，而是将能力以接口形式主动注册

  • 源码底座：底层基于 JSX/AST 等标准语言协议，摒弃私有 DSL，AI 可直接理解

  • Service 层：业务逻辑从 UI 组件剥离为独立 Service，人机共享同一代码路径

  • 双层 MCP：前端 WebMCP 负责画布操作，后端 MCP 负责平台操作，Skill 层统一调度

  • Schema 即协议：Formily Schema 同时驱动可视化表单渲染和 AI 参数理解，一份定义服务人机两个入口

  • 三层操作抽象：L1 原子指令 → L2 语义化工具 → L3 业务 Service，AI 调用 L2 但产生 L1 记录

  • CRDT 协同：AI 操作产生与人工完全等价的协同记录，可追溯、可撤销、可审计

  • 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 面板仍然是人类用户的入口，但它不再是系统的唯一入口——它只是底层能力模块的一个"视图层"，用于方便人的可视化管控。

03.jpg

1.3 从"被动适配"到"主动暴露"

上面的对比揭示了一个更深层的认知转变。传统系统设计中，能力的组织方式是"人找功能"——功能被包裹在 UI 页面和交互流程中，外部（无论是 AI 还是其他系统）想要调用这些能力，只能"被动适配"：模拟人类操作、解析 UI 结构、猜测交互路径。

这种模式在 AI 时代暴露出根本性的局限：UI 是给人看的，不是给 AI 用的。 再聪明的 AI，面对一个只能通过截屏猜测操作的黑箱系统，理解能力也无从施展。

AI 原生的思路是反过来——让系统主动暴露能力，而不是让 AI 被动去适配系统。具体来说：

  • UI 从"唯一入口"退位为"视图层之一"：人可以通过 UI 操作，AI 可以通过工具接口操作，两者地位平等

  • 能力从"藏在页面里"变为"以接口形式注册"：每个能力有清晰的名称、参数定义和返回结果，不需要猜测

  • 操作路径从"隐式导航"变为"语义路由"：AI 只需描述意图，协议层自动匹配到对应的能力接口

这不是一个技术优化，而是一个设计哲学的转变——系统不再假设自己的使用者只有人类，而是从一开始就为"人 + Agent"两种角色设计能力入口。 后续的 WebMCP、Service 层、Schema 协议，都是这个哲学的具体落地。

04.jpg

二、第一性原理：为什么 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 了。

有人形象地比喻：低代码系统就像"被锁在玻璃盒子里的应用"——能运行，却无法进化。私有 DSL 是 AI 时代的围墙，AI 可以解析 Java/Python/TypeScript 等标准语言，但无法进入每家低代码平台的内部规则体系。

所以，AI 原生项目的底层产物应该优先使用 AI 能理解的标准协议（如源码/AST），而非私有 DSL。

05.jpg

2.2 但纯代码模式有企业级瓶颈

完全基于源码就万事大吉了吗？并非如此。在企业级场景中，纯代码模式面临一系列现实问题：

  • 边界过于宽泛：开发者可以写出任意代码，难以规范化行为；

  • 无法可视化：非技术人员看不懂，无法参与审核和确认；

  • 人工检查困难：业务逻辑散落在代码各处，人工 Review 效率低下；

  • 难以复用：相似的业务功能反复造轮子；

  • 安全合规风险：无法在结构层面限制高风险操作；

2.3 解法：三层结构（源码/模块/可视化）

我们的方案是在源码底座上做出关键的架构约束：

06.jpg

底层是真实的 JSX 源码，通过 AST（抽象语法树）来操作——插入组件是往 AST 中添加节点，修改属性是修改 AST 节点的 props，删除组件是从 AST 中移除子树。AST 如何同时服务于可视化编辑器和 AI Agent，我们会在下一节展开。

在此之上，我们将通用的、安全的、经过验证的功能封装为业务模块（Service 层）：礼包配置、条件规则、签到逻辑、分享策略……它们对外暴露的是语义化的函数接口，如 configurePackage(conditionGroupId, rewardType, ...)，而非私有 DSL 或可视化表单。

之所以这样做，是因为在自助化营销场景中，系统的使用者是不熟悉开发技术的产品运营人员，而每项业务功能背后往往牵涉多个内部系统——礼包单系统、积分系统、数据存储、条件引擎、分享中台……如果让运营人员直接操作这些系统，极易出错且难以排查。因此，我们将复杂的跨系统逻辑收敛到业务模块内部，对外只暴露简洁的语义化接口，模块内部可能是基于低代码的逻辑编排，也可能是基于源码的逻辑实现，调用方无需关心底层实现。

AI 调用的是业务接口，模块负责操作源码。 AI 不需要理解 AST 结构就能完成业务配置，同时模块边界提供了安全约束——AI 只能通过预定义的接口操作，无法产生任意代码。

源码让 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 提供的可视化管控界面是他们理解和操作后端配置的唯一窗口。

判断标准其实很简单：人是否需要直接操作这个产物？如果需要（如后端配置），用结构化的配置协议并提供可视化管理界面；如果不需要（如前端画布由编辑器和 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 在配置参与条件时，不需要"发明"条件逻辑，而是：

代码语言：TXT

自动换行

AI代码解释

① 理解用户意图  → "当天登录游戏" 且 "VIP 等级 ≥ 5"，识别为 AND 关系
② 查询条件库  → 分别找到"当天登录游戏"和"VIP 等级"两个条件（若未命中则提醒用户接入新条件）
③ 读取 Schema  → 从 Formily Schema 提取参数模板（configExample）
④ 填入参数  → "当天登录游戏"无需参数，VIP 等级填入 { "level": 5, "operator": ">=" }
⑤ 编排组合  → 将两个条件组合为 AND 关系写入配置

如果用户的需求中涉及条件库中不存在的条件，AI 不会"编造"一个新条件，而是主动提醒用户接入新条件——"当前条件库中没有'游戏时长'相关的条件，请联系平台管理员接入后重试"。这保证了 AI 不会产生无效配置，也帮助平台持续丰富条件库。

条件库的本质是 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 全流程实战：一句话到上线活动

让我们回到开头的场景，完整展开"一只龙虾上线一场营销活动"的全链路：

用户输入：

"帮我创建一个五一签到活动，每天登录游戏，在活动页签到送宝箱+挑战卡，累计签到 5 天额外送一个王者之殿，仅限游戏vip等级 ≥ 5 的用户参与。"

AI Agent 自主执行：

展开 

代码语言：TXT

自动换行

AI代码解释

Step 1: 理解意图 ──────────── Agent 解析需求，规划执行步骤
Step 2: 创建活动 ──────────── 后端 MCP → create_app
Step 3: 搭建页面结构 ────────── WebMCP → insertComponent (批量)
Step 4: 配置签到规则 ────────── WebMCP → configureCumulativeSignin
          ├── 累计签到天数：5 天
          ├── 每日奖励：宝箱 + 挑战卡
          └── 累计额外奖励：王者之殿
Step 5: 配置参与条件 ────────── WebMCP → getConditionDetail → configureConditionPanel
          ├── 查询条件库获取"当天登录游戏"和"VIP 等级"两个条件
          ├── 读取 Formily Schema
          ├── 填入 "VIP ≥ 5" 参数
          └── 组合为 AND 条件组写入
Step 6: 设置分享策略 ────────── WebMCP → configureShare
Step 7: 保存并发布 ──────────── WebMCP → save → 后端 MCP → 状态扭转

全程 AI 自主规划、自主编排、自主执行。用户只需在关键节点确认，效率大幅度提升。这不是因为我们做了一个更聪明的 Prompt，而是因为系统从底层就为 AI 的自主操作而设计——清晰的工具语义、标准的 Schema 协议、确定性的执行路径。

四、WebMCP+Formily：告别截屏，让前端成为 AI 的一等公民

前面讨论了"从被动适配到主动暴露"的设计哲学，那么具体怎么落地？第一个要解决的问题是：AI 如何操作前端？

今天的 LLM 已经足够聪明，能够理解复杂的多步骤意图、拆解任务、规划执行路径——这不是瓶颈。真正的瓶颈在于系统是否给到了 AI 足够清晰的能力入口。

4.1 从"截屏猜测"到"能力暴露"

当前 AI Agent 对前端项目的操作能力，坦白说，还很原始。以主流的 Computer Use 方案为例：

代码语言：TXT

自动换行

AI代码解释

传统 Agent 操作前端的方式：
截屏 → OCR 识别 → 猜测元素位置 → 模拟点击 → 再截屏验证 → 发现不对 → 重试...

这种"截屏 + OCR + 猜测"的大量消耗Token且效率极低的模式，对简单的网页交互勉强可用，但面对一个有着复杂组件树、嵌套 props 绑定、联动条件逻辑的生产级应用，完全力不从心——它无法精准操作组件树，无法修改 props，无法读取绑定关系，更无法理解业务语义。

WebMCP 是让前端成为 AI 生态一等公民的入口。

WebMCP（基于 W3C navigator.modelContext 提案）让前端应用能够将自己的能力以标准化工具协议的形式暴露给 AI Agent：

代码语言：TXT

自动换行

AI代码解释

AI Agent 通过 WebMCP 操作前端的方式：
语义化意图 → 调用精确的工具接口 → 直接操作组件树/修改 props/读写配置 → 确定性结果

不再猜测，不再重试。AI 知道自己能做什么、参数是什么、结果会是什么。

4.2 前端架构的范式升级：从表单收集到服务暴露

传统的前端不仅是"表单数据收集器"，更承载了用户与系统之间的连接器角色——用户的所有操作都必须通过前端 UI 这个唯一入口才能触达系统。在这种架构中，业务逻辑散落在 React 组件的 onChange 回调里，与 UI 渲染深度耦合，外部无法调用。

AI 原生时代，前端架构需要从"表单收集"升级为"服务暴露"：

07.jpg

关键变化：业务逻辑从 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代码解释

// ❌ 传统命名：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 是自然的解决方案：

展开 

代码语言：TXT

自动换行

AI代码解释

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

自动换行

AI代码解释

// 文件操作
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. 可审计：所有操作记录可用于复盘和合规检查

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 失败时不会"失控"。

# 人工智能 # 微信
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

Kubernetes CoreDNS 解析超时排查（ndots 与 NodeLocal DNSCache）

CoreDNS 超时先用 ClusterIP 直连排除数据面，再读 Pod的ndots 与 search。默认 ndots:5 让短名查询放大数倍，AAAA 再乘一倍。指标上区分 NXDOMAIN 瀑布和真正的 SERVFAIL/p99。NodeLocal DNSCache 降 RTT、不消灭放大；根上仍是 FQDN 或谨慎的 dnsConfig。改 DNS 全局配置必须可回滚，禁止先停 Core

avatar 2048 AI社区
cover

AIGC课程为什么从99元到数万元都有：先把“买工具”与“买结果”分开

avatar 2048 AI社区

AI视频总结工具有哪些？2026年5款热门工具横向评测

本文从客观角度介绍5款常见的AI视频总结工具：Ai好记、NoteAi、BibiGPT、通义听悟、NotebookLM。每款工具按同一套维度说明：支持的内容来源、转写与总结能力、操作方式、页面呈现，以及适用场景。文末附功能对比表和常见问题，供读者按需选择。

avatar 2048 AI社区