先说几个核心判断：2025年以来，AI Agent的迭代速度远远超出行业预期。它已不再停留在“理解用户语义”的阶段，而是真正开始执行任务——主动调用工具、操控界面、完成端到端的工作流程。这听起来令人振奋，但如果你的前端组件仍然只为“人类操作”而设计，就会陷入一个尴尬的境地：
一、时代的提问：AI 来了，你的组件它“看得懂”吗？
人类看到界面，点击按钮，触发事件，更新数据——这是一个极其自然的交互流程。但换成AI呢？它看到了什么？它如何调用？它无从知晓。
一个Vue组件究竟具备哪些“能力”？它能执行什么操作？需要哪些输入？会产生怎样的输出？对人类而言，扫一眼UI就能理解。但对AI来说，这些信息根本不存在于任何机器可读的结构之中。这正是问题的根源，也是“前端能力可调用化”所要解决的核心命题。
二、从“组件”到“技能”：认知范式的升级
2.1 什么是 Skill（技能）？
在AI领域，Skill的定义已经相当成熟。OpenAI称之为Function/Tool，Microsoft Copilot称之为Skill，Semantic Kernel称之为Plugin，LangChain称之为Tool，MCP同样称之为Tool。尽管名称各异，但其共同本质是一致的：一个可被发现的名称，加上告知AI应传递什么的输入描述，再告知AI会获得什么的输出描述，最后配备真正执行任务的逻辑。
| AI 框架 | 术语 | 核心要素 |
|---|---|---|
| OpenAI Function Calling | Function / Tool | 函数名、参数 Schema（JSON Schema）、描述 |
| Microsoft Copilot | Skill | 函数签名、触发意图、输入输出类型 |
| Semantic Kernel | Plugin / Skill | 函数集合、KernelFunction 装饰器 |
| LangChain | Tool | name、description、args_schema |
| MCP (Model Context Protocol) | Tool | name、description、inputSchema |
2.2 .vue 组件距离 Skill 有多远？
以一个典型的.vue组件为例：它拥有名称（比如type="spark-ej2-grid"），这没有问题；它通过props接收输入，但类型信息深藏在TypeScript中，运行时根本无法查询；它通过provide传递数据，但这个能力是隐式的，AI无法感知；它通过emit事件产生输出，但缺乏任何结构化描述。
差距的本质在于：组件的“接口”散落在TypeScript类型、Props定义、事件文档中——人类可读，机器不可查，AI不可调用。
2.3 Skill 化的三个核心动作
将.vue组件转化为Skill，本质上需要完成三件事：第一，命名化，采用kebab-case并通过Registry注册；第二，接口化，定义ComponentConfig类型并声明能力键；第三，可发现，添加meta元数据和AI可读的描述。三步完成后，一个前端Skill便诞生了。
三、SPARK 能力系统：Skill 的运行时基础设施
SPARK框架的能力系统绝非偶然为之，它在架构层面就为Skill化奠定了坚实基础。
3.1 能力键 = Skill 接口的类型标签
每一个能力键，对应一种可调用的前端能力。例如PAGE_DATASET对应“提供页面级数据空间”，DATA_SOURCE对应“提供数据视图”，APP_SERVICES对应“提供路由/日志/租户服务”，等等。这种设计让组件的能力变得可声明、可查询。
| 能力键 | 对应的 Skill 语义 | 典型 Provider |
|---|---|---|
PAGE_DATASET | “提供页面级数据空间” | PageRenderer |
DATA_SOURCE | “提供数据视图（可读写行数据）” | r-table / r-form |
APP_SERVICES | “提供路由/日志/租户服务” | SparkPlugin |
PAGE_SERVICE | “提供 UI 消息/确认框/导航” | RendererContainer |
FIELD_CONTEXT | “声明当前渲染上下文” | 各容器组件 |
LOGGER | “提供自定义日志实现” | 任意组件 |
3.2 provide / consume = Skill 的发布与调用
组件通过provide发布自身能力，子组件通过consume调用祖先的能力。这与OpenAI Function Calling的调用模型高度同构——function_name对应能力键，parameters对应consume的参数，return对应返回的数据视图。
3.3 parent 链查找 = Skill 的作用域感知
SPARK的lookup()沿着父级链向上遍历，就近匹配能力。这意味着当多个r-table嵌套时，每个子组件只能访问它自己的数据视图，不会跨树污染。这与Copilot Skill的“上下文隔离”、MCP的“会话隔离”设计思想如出一辙。
四、组件注册表：Skill 的发现协议
4.1 Registry = Skill Catalog（技能目录）
SPARK的ComponentRegistry就是前端Skill目录。你可以注册一个组件，并附带元数据——包括描述信息、提供了哪些能力、消费了哪些能力。Registry本质上就是一个Skill Catalog，AI可以查询这个目录，发现有哪些可用的前端技能。
4.2 isComponentRegistered = Skill 的存在性检测
AI在执行任务之前，可以先检测所需技能是否可用。如果组件已注册，就安全使用；如果不存在，就走降级路径。这种机制让AI的调用更加稳健可靠。
4.3 编译时注册 vs 运行时注册：Skill 的加载策略
编译时注册通过Vite插件生成虚拟模块，适合生产环境，首屏性能优先；运行时懒加载通过动态import实现，适合开发环境或大型项目；热插拔注册则像npm包一样动态扩展，适合微前端场景。
五、ComponentConfig：Skill 的调用契约
5.1 从 Props 到 Config：统一调用接口
所有SPARK组件都通过ComponentConfig接收配置，这是Skill调用的统一入口。它与AI工具协议的映射非常自然：type对应function，props对应arguments，dataKey对应数据绑定，children对应嵌套调用。
5.2 扩展 ComponentConfig：声明 Skill 的专属参数
你可以为每个Skill定义专属的配置接口，例如表格Skill需要dataKey、allowPaging、pageSize等参数。AI生成的rule.json就是对这套契约的“调用”。
六、AI 调用 Skill 的完整链路
6.1 rule.json：AI 生成的 Skill 调用脚本
在SPARK框架中，rule.json就是AI对前端Skill的调用序列。整个流程是这样的：AI理解需求，查询Registry（Skill目录），选择合适的Skill组合，生成rule.json（Skill调用参数），SPARK解析执行，最终完成UI渲染。
6.2 能力链的建立过程（Skill 的运行时组装）
这是SPARK最核心的运行时流程：AI生成的rule.json被解析为ComponentConfig树，渲染器取出组件实例，组件内部通过provide/consume建立上下文和能力链。整个过程由AI写配置，框架拼接能力链——无需人工干预。
6.3 AI 发现前端 Skill 的三种方式
第一种是通过虚拟模块virtual:spark-skill-catalog，这是当前已实现且推荐的方式。第二种是运行时通过API查询Registry。第三种是将Skill目录以提示词形式静态内嵌给AI。
