Skill 的起源与演进：从 Function Calling 到 Agent Skill

2023 年，OpenAI 用一个 functions 参数重新定义了大模型与外部世界的交互方式。两年后，“Skill” 成为 AI Agent 系统中最核心的抽象单元。本文梳理从 Function Calling → Plugin → Skill 的完整演进脉络，揭示每一次范式跃迁背后的技术动因与设计哲学。

---

一、前言：为什么需要理解 Skill 的历史？

当我们谈论 AI Agent 的 “Skill” 时，很容易将其简单理解为 “能调用的函数”。但这种理解会让我们在设计复杂 Agent 系统时陷入困境——函数是无状态的、无边界的、无身份的；而 Skill 是有上下文的、有约束的、有自我描述能力的。

要理解 Skill 为什么长成今天这个样子，我们必须回到它的起点：2023 年 6 月，OpenAI 发布 Function Calling 的那个夏天。

这条演进路线并非线性升级，而是一次次对 “大模型如何与外部世界交互” 这个根本问题的重新回答。每一次回答都比上一次更深刻，也更接近 Agent 系统的真实需求。

---

二、Function Calling 的诞生：让模型"动手"

2.1 问题背景

2023 年上半年，GPT-4 刚刚发布。尽管它的推理能力令人惊叹，但它有一个致命缺陷：无法与外部世界交互。它不知道今天的天气，无法查询数据库，不能发送邮件。所有能力都被锁在了模型参数和上下文窗口里。

开发者们尝试了各种 workaround：在 prompt 里嵌入 JSON Schema、用正则表达式解析模型输出中的函数调用意图、甚至训练专门的 “调用解析器”。这些方法脆弱、不可靠，且缺乏标准化。

2.2 Function Calling 的设计

2023 年 6 月 13 日，OpenAI 在 API 中引入了 functions 参数。其核心设计极其简洁：

{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "北京今天天气怎么样？"}],
  "functions": [
    {
      "name": "get_weather",
      "description": "获取指定城市的天气信息",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {"type": "string", "description": "城市名称"}
        },
        "required": ["city"]
      }
    }
  ]
}

模型的响应不再是自由文本，而是一个结构化的函数调用意图：

{
  "choices": [{
    "message": {
      "role": "assistant",
      "function_call": {
        "name": "get_weather",
        "arguments": "{\"city\": \"北京\"}"
      }
    }
  }]
}

2.3 历史意义

Function Calling 解决了三个关键问题：

1. 意图识别的标准化：模型不再需要通过自由文本来 “暗示” 它想调用什么函数，而是直接输出结构化的调用意图。
2. 参数提取的可靠化：JSON Schema 为参数定义了类型和约束，大幅降低了参数解析的错误率。
3. 人机协作的规范化：开发者定义函数，模型决定何时调用、如何传参，形成了一种清晰的分工模式。

但 Function Calling 的局限也很明显：它只是 “函数调用”，不包含执行逻辑、不包含错误处理、不包含使用约束。开发者需要自己实现调用链、结果回传、重试机制等所有编排逻辑。

---

三、Plugin 生态的兴衰：野心与现实

3.1 ChatGPT Plugins 的愿景

2023 年 3 月，OpenAI 发布 ChatGPT Plugins，比 Function Calling 还早三个月。Plugins 的野心远大于 Function Calling——它不仅要让模型 “调用函数”，还要构建一个开放的生态系统。

每个 Plugin 包含：

• 一个 ai-plugin.json 描述文件（包含名称、描述、认证方式等）
• 一个 OpenAPI 规范（定义可用的 API 端点）
• 一个人类可读的描述文档

# ai-plugin.json 示例
schema_version: "v1"
name_for_model: "weather"
name_for_human: "Weather Plugin"
description_for_model: "获取全球城市的天气预报数据"
description_for_human: "获取实时天气信息"
api:
  type: "openapi"
  url: "https://weather.example.com/openapi.yaml"
auth:
  type: "none"

3.2 Plugin 为什么失败了？

ChatGPT Plugins 在发布时引起了巨大轰动，但到 2024 年初，OpenAI 逐渐将其边缘化，最终在 GPTs 中用 Actions 替代了 Plugins。失败的原因是多方面的：

发现与安装的摩擦：用户需要手动启用 Plugin，且无法直观地知道哪个 Plugin 能解决当前问题。这违背了 “AI 应该自动选择工具” 的 Agent 理念。

质量参差不齐：开放生态带来了大量低质量 Plugin，许多只是简单包装了一个 REST API，缺乏真正有价值的领域逻辑。

缺乏执行上下文：Plugin 只定义了 “能做什么”（API 端点），但没有定义 “怎么做”（执行策略）、“什么时候做”（触发条件）、“做到什么程度”（成功标准）。这些缺失导致模型在使用 Plugin 时经常出现误用。

安全模型过于简单：Plugin 的认证机制（API Key、OAuth）无法满足复杂场景下的权限控制需求。

3.3 Plugin 留下的遗产

尽管 Plugin 生态失败了，但它提出了几个重要的设计问题，这些问题后来被 Skill 系统回答：

• 自描述性：工具应该如何描述自己的能力？
• 可发现性：Agent 如何在运行时发现合适的工具？
• 可组合性：多个工具如何协同工作？
• 安全性：如何在赋予能力的同时保持控制？

---

四、Skill 的语义升级：从 “能做什么” 到 “是什么”

4.1 范式转变

2024 年下半年到 2025 年，随着 Claude、GPT-4o、Gemini 等模型在 Agent 能力上的持续进化，一个新的抽象层开始在各个框架中浮现：Skill。

Skill 不是 Function Calling 的简单升级，也不是 Plugin 的改良版。它代表了一种根本性的范式转变：

维度	Function Calling	Plugin	Skill
核心抽象	函数签名	API 端点	能力单元
描述方式	JSON Schema	OpenAPI	自然语言 + 结构化元数据
包含内容	仅接口定义	接口 + 认证	接口 + 执行 + 知识 + 约束
调用方式	模型决定	模型决定	模型理解后自主决策
执行边界	无	API 调用	完整执行上下文
知识传递	无	无	内嵌领域知识
自我约束	无	无	明确的能力边界

4.2 Skill 的三个关键特征

语义丰富性（Semantic Richness）：Skill 不仅告诉模型 “这个函数接受什么参数”，而是通过自然语言描述告诉模型 “这个能力是什么、适用于什么场景、有什么限制”。这种语义密度让模型能够做出更准确的能力选择。

执行完整性（Execution Completeness）：一个 Skill 可以包含脚本、配置、依赖声明等完整的执行上下文。模型不需要关心 “如何安装依赖”、“如何处理错误”，这些都被封装在 Skill 内部。

认知对齐（Cognitive Alignment）：Skill 的描述方式与人类认知模型对齐。当我们说 “这是一个数据分析 Skill” 时，我们传递的不仅是功能信息，还有一整套隐含的预期：它应该能处理表格数据、生成图表、进行统计分析等。

4.3 代表框架

Skill 作为核心抽象的代表性框架包括：

• OpenAI Agents SDK（2025）：将 Tools 概念扩展为可组合的能力单元
• Claude Computer Use + MCP（2024-2025）：通过 Model Context Protocol 实现标准化的能力接入
• LangChain/LangGraph（2024-2025）：从 Chain 到 Tool 到 Agent 的逐步抽象升级
• OpenClaw Skills（2025）：以 SKILL.md 为核心的自描述式 Skill 系统

---

五、代码示例：三种形态的对比

5.1 Function Calling 形态

# Function Calling：纯粹的接口定义
import openai

# 定义函数（仅接口，无实现逻辑描述）
functions = [
    {
        "name": "analyze_csv",
        "description": "分析CSV文件并返回统计结果",
        "parameters": {
            "type": "object",
            "properties": {
                "file_path": {"type": "string"},
                "columns": {
                    "type": "array",
                    "items": {"type": "string"}
                },
                "operation": {
                    "type": "string",
                    "enum": ["mean", "median", "std", "describe"]
                }
            },
            "required": ["file_path", "operation"]
        }
    }
]

# 模型返回调用意图
response = openai.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "分析 sales.csv 的平均销售额"}],
    functions=functions,
    function_call="auto"
)

# 开发者需要手动处理：
# 1. 解析 arguments
# 2. 验证参数合法性
# 3. 执行实际逻辑
# 4. 处理异常
# 5. 格式化结果回传
# 6. 管理调用链（多轮对话）

5.2 Plugin 形态

# Plugin 形态：API 端点 + OpenAPI 规范
# openapi.yaml
openapi: 3.0.0
info:
  title: Data Analysis Plugin
  version: 1.0.0
paths:
  /analyze:
    post:
      summary: 分析数据文件
      operationId: analyzeData
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                file_url:
                  type: string
                  description: 数据文件的URL
                query:
                  type: string
                  description: 自然语言查询
      responses:
        '200':
          description: 分析结果
          content:
            application/json:
              schema:
                type: object
                properties:
                  result:
                    type: string
                  chart_url:
                    type: string

# Plugin 仍然缺乏：
# - 执行策略（失败后怎么办？）
# - 使用约束（什么场景下不该用？）
# - 领域知识（什么是"平均销售额"？）

5.3 Skill 形态

<!-- SKILL.md：自描述式 Skill -->
# 数据分析 Skill

## 能力描述
这是一个数据分析 Skill，能够对 CSV/Excel 文件进行探索性分析、
统计计算和可视化。适用于销售分析、用户行为分析、财务报表分析等场景。

## 适用场景
- 用户需要对表格数据进行统计分析
- 需要生成数据可视化图表
- 需要发现数据中的趋势和异常

## 不适用场景
- 实时数据流处理（请使用"流处理 Skill"）
- 非结构化数据分析（请使用"NLP 分析 Skill"）
- 数据量超过 1GB（请使用"大数据分析 Skill"）

## 使用方式
1. 将数据文件放到工作区
2. 用自然语言描述分析需求
3. Skill 会自动选择合适的分析方法

## 依赖
- Python 3.10+
- pandas, matplotlib, scipy

## 脚本
- `analyze.py` — 主分析脚本
- `visualize.py` — 可视化辅助

## 参考材料
- `examples/` — 常见分析场景示例
- `patterns/` — 数据分析模式库

这三种形态的对比清晰地展示了演进方向：从 “告诉模型能调用什么函数” 到 “告诉模型这是一个什么样的能力”。

---

六、演进逻辑总结

6.1 技术驱动

每次范式跃迁都由技术进步驱动：

• 2023 Function Calling：GPT-4 的指令遵循能力足够强，能够理解结构化的函数定义并输出结构化的调用意图。
• 2023-2024 Plugin：模型能力扩展到可以理解 OpenAPI 规范，但生态管理和质量控制的挑战暴露了 “开放平台” 模式的局限。
• 2025 Skill：模型的上下文理解能力和推理能力进一步提升，能够理解自然语言描述的能力边界和使用约束，使得 “自描述式 Skill” 成为可能。

6.2 需求拉动

Agent 系统的复杂度不断提升，也拉动了抽象层的升级：

• 单次调用 → 多步编排：从 “调一个函数” 到 “完成一个任务”，需要更丰富的执行上下文。
• 通用工具 → 领域能力：从 “获取天气” 到 “进行数据分析”，需要内嵌领域知识。
• 开发者控制 → Agent 自治：从 “开发者决定调用链” 到 “Agent 自主选择能力”，需要更语义化的描述。

6.3 设计哲学的演变

最深层的变化是设计哲学的演变：

Function Calling:  "模型，这里是你可以调用的函数列表。"
Plugin:            "模型，这里是一个开放的工具市场，你可以去发现和使用。"
Skill:             "模型，这里是你的能力集合。每个能力都有明确的边界，
                    当你理解用户需求后，自主决定使用哪个能力。"

从 “函数” 到 “能力”，从 “调用” 到 “理解”，从 “开发者编排” 到 “Agent 自治”——这就是 Skill 的演进逻辑。

---

七、展望：Skill 的未来

Skill 的演进仍在继续。几个值得关注的方向：

1. Skill 的自动生成：Agent 能否根据任务需求自动创建新的 Skill？
2. Skill 的动态组合：多个 Skill 能否在运行时自动编排成工作流？
3. Skill 的版本进化：Skill 能否从使用反馈中自动优化自身？
4. Skill 的安全治理：如何在保持灵活性的同时确保安全边界？

这些问题的答案，将定义下一代 AI Agent 系统的架构形态。

---

参考文献

1. OpenAI. “Function calling and other API updates.” OpenAI Blog, June 13, 2023. https://openai.com/index/function-calling-and-other-api-updates/
2. OpenAI. “ChatGPT plugins.” OpenAI Blog, March 23, 2023. https://openai.com/index/chatgpt-plugins/
3. Anthropic. “Model Context Protocol (MCP) Specification.” Anthropic Documentation, 2024. https://modelcontextprotocol.io/
4. Schick, T., et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023. arXiv:2302.04761.
5. Qin, Y., et al. “ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs.” ICLR 2024. arXiv:2307.16789.

---

本系列覆盖 AI 大模型基础、Agent 开发、MCP 协议、Skill 开发、RAG、模型微调、部署推理 七大方向，从入门到实战的全栈内容持续更新中。

所有文章的 Markdown 源文件、可运行代码、高清配图已整理成完整资料包。

👍 点赞 + ⭐ 关注，评论区扣「1」，挨个发你领取方式 👇