前端 Skill 架构：面向行为抽象的原子能力设计与运行时契约

1. 为什么前端工程师突然开始聊“Agent Skill”？这不是后端或AI工程师的专属话题

最近在几个前端技术群和面试复盘帖里，频繁看到“Agent Skill”这个词被拎出来讨论——不是作为某个新框架的插件，也不是某家大厂的内部黑话，而是实实在在出现在候选人简历技能栏、面试官追问清单，甚至团队技术选型会议纪要里。我最初也以为是概念炒作，直到上个月帮一个电商中台项目做性能诊断时，发现他们用 Vue3 + Pinia 实现的“智能表单助手”，底层逻辑完全依赖一套自研的 Skill 注册与调度机制：用户输入收货地址，系统自动触发 address-validation Skill；切换支付方式，立刻调用 payment-method-check Skill；连“点击‘查看历史订单’按钮”这个动作，背后都绑定了一个 order-history-fetch Skill。它不叫 Agent，没用 LangChain，没有 LLM 接口，但整个交互流的可维护性、可测试性、可灰度能力，远超我们惯用的 Vuex 模块拆分方案。

这让我意识到，“Agent Skill”在前端语境下，根本不是对 AI Agent 的简单移植，而是一次面向行为抽象的架构升级。它把过去散落在组件 methods、useXXX Hook、甚至全局事件总线里的业务逻辑，重新组织成一个个有明确定义边界、输入输出契约、独立生命周期的“能力单元”。就像当年 jQuery 时代大家写 $(selector).doSomething()，后来 React 提出“组件即函数”，现在前端正在走向“能力即模块”。关键词里反复出现的Cursor（不是那个 AI 编程工具，而是指代“执行上下文中的能力调用点”），Reference（不是文档引用，而是 Skill 实例在运行时的可寻址标识），Script（不是 HTML 中的