AI Agent技能Skills设计

Agent Skill 详解：前端开发者视角的一次认知升级

随着 AI Agent 的兴起，一个高频出现的概念是：Skill（技能）。

如果你是前端开发者，可以把它理解为------

👉 "AI 世界里的组件 / API / Hook 的结合体"。

这篇文章会用你熟悉的前端思维，帮你彻底理解 Agent Skill。

一、从前端视角理解：什么是 Agent？

在讲 Skill 之前，先快速建立上下文。

你可以把 Agent 理解为：

一个"有大脑（LLM）+ 能调用工具 + 能做决策"的程序

类比前端：

概念	类比
LLM	类似"核心逻辑引擎"（但更智能）
Agent	类似"应用层 Controller"
Tool / Skill	类似"服务 / API / 组件能力"

二、什么是 Skill？

✅ 一句话定义

Skill = Agent 可调用的一个结构化能力单元

🧠 用前端类比理解

Skill ≈

一个函数（Function）
一个 API（fetch 调用）
一个组件能力（Component Capability）
或者一个 Hook（useXXX）

但它比这些更"AI原生"。

✅ Skill 的核心结构

一个 Skill 通常包含：

ts 复制代码

type Skill = {
  name: string
  description: string
  inputSchema: object
  handler: (input) => output
}

📦 拆解一下

部分	含义	前端类比
name	技能名	函数名
description	描述	JSDoc
inputSchema	输入定义	TypeScript 类型
handler	执行逻辑	函数体 / API

三、Skill 是怎么被调用的？

这是关键点👇

🧠 核心机制

不是你调用 Skill，而是 LLM 决定调用哪个 Skill

🔁 调用流程

用户输入问题
Agent 把问题交给 LLM
LLM 判断：
👉 "这个问题我需要用 Skill 解决"
选择一个 Skill
构造参数
调用 Skill
返回结果
LLM 整理输出

📊 类比前端流程

就像：

ts 复制代码

if (needFetch) {
  const data = await fetchAPI(params)
  return render(data)
}

但区别是：

👉 if 判断是 AI 自动做的

四、Skill vs 前端常见概念

1️⃣ Skill vs Function

Skill	Function
给 AI 用	给人写代码用
有语义描述	通常只有代码
可被 LLM 选择	必须手动调用

2️⃣ Skill vs API

Skill	API
AI 自动调用	手动 fetch
有自然语言描述	文档驱动
更偏"能力"	更偏"接口"

3️⃣ Skill vs React 组件

Skill	React Component
提供"能力"	提供"UI"
无界面	有界面
被 Agent 调用	被 JSX 调用

五、Skill 的运行本质

Skill 本质上解决一个问题：

👉 如何让 LLM 不只是"会说"，还能"会做"

没有 Skill 的世界

LLM：

"我建议你去查天气网站"

有 Skill 的世界

LLM：

（调用 weatherSkill）

"今天东京 18°C，多云"

👉 这就是从"建议"到"执行"的跃迁。

六、典型 Skill 示例

🌦 天气查询 Skill

ts 复制代码

const weatherSkill = {
  name: "getWeather",
  description: "获取指定城市的天气",
  inputSchema: {
    city: "string"
  },
  handler: async ({ city }) => {
    return await fetch(`/api/weather?city=${city}`)
  }
}

🧠 LLM 看到的是：

"这是一个可以获取天气的能力"

而不是代码本身。

七、Skill 的设计原则（工程重点）

1️⃣ 描述比实现更重要

❌ 错误：

txt 复制代码

getData

✅ 正确：

txt 复制代码

获取用户最近7天订单数据

2️⃣ 输入必须清晰

像写 TypeScript 一样：

ts 复制代码

{
  userId: string
  days: number
}

3️⃣ 一个 Skill 只做一件事

👉 类似 React 单一职责原则

4️⃣ 可组合性

多个 Skill 可以组合：

txt 复制代码

搜索 → 过滤 → 总结

类似：

ts 复制代码

pipe(search, filter, summarize)

八、前端开发者可以怎么用？

🔧 1. 做 AI Copilot

自动生成 UI
自动改代码
自动调试

🤖 2. 做智能工具

表单自动填写
数据分析
BI 助手

🧩 3. 构建 AI 应用

你可以把 Skill 当成：

👉 "AI 的后端能力层"

前端负责：

UI
交互

Skill 负责：

执行
数据
自动化

九、总结

我们用一句话收尾：

Skill = 给 AI 用的函数 + API + 能力描述 + 自动调用机制

🧠 对前端开发者的认知升级

从：

👉 "我调用 API"

变成：

👉 "AI 帮我决定调用哪个 API"

这就是 Agent 时代最重要的变化之一。

十、延伸思考

Skill 会不会成为新的"后端接口标准"？
前端是否会直接"编排 Skill"？
React 未来会不会出现 "AI Hooks"？

如果你理解了 Skill，本质上你已经迈入：

👉 AI 应用工程（AI Engineering）的大门

从 0 到 1：如何设计一个 Agent Skill，并接入 Agent 框架（附 MCP 区别详解）

如果说上一篇我们解决的是：

👉 "Skill 是什么？"

那这一篇我们解决三个更关键的问题：

我怎么自己设计一个 Skill？
Skill 怎么接入 Agent 框架？
Skill 和 MCP（Model Context Protocol）到底有什么区别？

这三件事，本质上对应 AI 工程的三个层次：

能力设计（Skill Design）
系统接入（Integration）
协议标准（Protocol）

一、如何设计一个"好用"的 Skill？

很多人一上来就写 handler，其实方向是反的。

👉 Skill 的核心不是代码，而是"让 LLM 能理解并正确调用"

1. Skill 设计的本质

一句话总结：

Skill = 可被 LLM 正确选择 + 正确使用的能力描述

2. 设计步骤（工程化流程）

我们用一个真实例子：👉「查询用户订单」

✅ Step 1：定义能力边界（最重要）

❌ 错误设计：

txt 复制代码

订单相关操作

👉 太模糊，LLM 不知道什么时候用

✅ 正确设计：

txt 复制代码

获取用户最近N天的订单列表

👉 明确：

输入：用户 + 时间范围
输出：订单数据

✅ Step 2：写"给 AI 看"的描述（不是给人）

ts 复制代码

const skill = {
  name: "getRecentOrders",
  description: "获取指定用户最近N天的订单列表，用于查询订单历史",
}

👉 关键点：

不要写技术细节
要写"使用场景"

✅ Step 3：设计输入 Schema（像写 TypeScript）

ts 复制代码

inputSchema = {
  type: "object",
  properties: {
    userId: { type: "string" },
    days: { type: "number" }
  },
  required: ["userId"]
}

👉 本质：

你是在给 LLM 一份"函数签名"

✅ Step 4：实现 handler（反而最简单）

ts 复制代码

async function handler({ userId, days = 7 }) {
  return fetch(`/api/orders?userId=${userId}&days=${days}`)
}

👉 注意：

handler 是给系统执行的
description 是给 AI 理解的

3. 一个完整 Skill 长这样

ts 复制代码

export const getRecentOrdersSkill = {
  name: "getRecentOrders",
  description: "获取用户最近几天的订单数据，用于订单查询和分析",
  inputSchema: {
    type: "object",
    properties: {
      userId: { type: "string" },
      days: { type: "number" }
    }
  },
  handler: async ({ userId, days = 7 }) => {
    return await fetchOrders(userId, days)
  }
}

4. 前端类比（非常关键）

Skill 设计	前端类比
description	props 语义
inputSchema	TypeScript 类型
handler	业务逻辑
Skill	一个"可调用服务组件"

二、Skill 如何接入 Agent 框架？

这是从"写能力"到"让 AI 用能力"的关键一步。

1. 核心架构

一个典型 Agent：

txt 复制代码

用户输入 → LLM → 选择 Skill → 执行 → 返回 → LLM总结

👉 Skill 要做的：

注册到 Agent，让 LLM 知道"有这个能力"

2. 最简单接入方式（函数调用模式）

以常见 Agent 框架为例（如函数调用式 Agent）：

Step 1：注册 Skill

ts 复制代码

const agent = new Agent({
  skills: [getRecentOrdersSkill]
})

Step 2：把 Skill 转成 LLM 可理解格式

ts 复制代码

const tools = skills.map(skill => ({
  name: skill.name,
  description: skill.description,
  parameters: skill.inputSchema
}))

👉 这一步本质：

把 Skill 转成"函数调用描述"（Function Calling）

Step 3：LLM 自动调用

ts 复制代码

const response = await llm.chat({
  messages,
  tools
})

如果 LLM 返回：

json 复制代码

{
  "tool_call": {
    "name": "getRecentOrders",
    "arguments": { "userId": "123" }
  }
}

Step 4：执行 Skill

ts 复制代码

const result = await skill.handler(args)

Step 5：把结果喂回 LLM

ts 复制代码

messages.push({
  role: "tool",
  content: result
})

👉 完整闭环完成

3. 一句话总结接入流程

注册 Skill → 转成工具描述 → LLM 选择 → 执行 → 回传

4. 前端类比

像这样：

ts 复制代码

registerComponent(Button)
render(<Button />)

但区别是：

👉 是 AI 在"render Skill"

三、Skill vs MCP：到底有什么区别？

这是很多人最容易混淆的点。

1. 一句话结论

Skill 是"能力定义"，MCP 是"能力传输协议"

2. 什么是 MCP？

MCP（Model Context Protocol）可以理解为：

👉 让 Agent 能连接外部工具 / 数据源的标准协议

你可以把它类比为：

HTTP（接口通信）
或 WebSocket（实时通信）

3. 核心区别

维度	Skill	MCP
本质	能力定义	通信协议
作用	告诉 AI "能做什么"	告诉系统 "怎么连工具"
层级	应用层	基础设施层
是否必须	是	不一定
类比	函数 / 组件	HTTP / RPC

4. 更直观理解

🧠 Skill 世界

txt 复制代码

getWeather()
getOrders()
sendEmail()

👉 定义能力

🌐 MCP 世界

txt 复制代码

连接 Notion
连接 Slack
连接数据库

👉 提供数据和工具来源

5. 它们如何协作？

👉 真正的架构是：

txt 复制代码

MCP → 提供工具能力
Skill → 封装成 AI 可用能力
Agent → 决策调用

📦 举个例子

MCP 提供：

Notion API
数据库访问

Skill 封装：

ts 复制代码

getUserNotes()
summarizeDocs()

👉 LLM 只看 Skill，不关心 MCP

6. 前端类比（重点）

概念	类比
MCP	浏览器 / 网络层
Skill	API 封装
Agent	前端应用
LLM	智能调度器

👉 或更直白：

MCP = fetch / axios 背后的网络
Skill = 你封装的 API 方法

四、总结（工程视角）

✅ Skill 的本质

给 AI 用的"函数 + 语义描述"

✅ 接入 Agent 的本质

让 LLM 能"看到并选择"你的能力

✅ MCP 的本质

让系统能"接入世界"