LLM大语言模型Agent系统核心技术演变流程

从Function Calling到MCP协议再到Skill的演进之路

摘要

本文系统梳理了LLM Agent系统核心技术的演变历程，从2023年OpenAI发布的Function Calling，到2024年Anthropic开源的MCP协议，再到2025年Skill概念的提出，详细剖析了每一代技术的核心机制、解决的问题以及存在的局限性。通过具体的交互流程和代码实现示例，帮助读者深入理解这一领域的技术演进脉络。

1. 引言：从静态问答到动态智能体

2022年11月30日，ChatGPT的发布正式敲响了大语言模型（LLM）时代的大门。最初的LLM主要作为"文本生成器"存在，用户输入问题，模型输出答案，交互模式相对单一。然而，随着应用场景的拓展，开发者逐渐意识到：要让LLM真正赋能实际业务，必须赋予其与外部世界交互的能力。

1.1 LLM发展的三个阶段

回顾LLM Agent技术的发展历程，可以清晰地划分为三个主要阶段：

1. 纯生成阶段：早期LLM仅具备文本生成能力，所有知识来源于训练数据，无法获取实时信息，也无法执行外部操作。

2. 工具调用阶段：2023年OpenAI推出Function Calling，使LLM能够根据用户需求主动调用外部函数/API，获取实时数据或执行具体操作。

3. 自主智能体阶段：随着MCP协议和Skill概念的出现，LLM Agent具备了动态发现工具、按需加载能力、自主规划执行的完整智能体能力。

1.2 技术演进的核心驱动力

这一系列技术演进的背后，是三个核心痛点的推动：

• 上下文限制：LLM的上下文窗口有限，无法一次性加载过多工具描述。
• 扩展性需求：固定Tool List难以适应快速变化的三方服务生态。
• 标准化诉求：不同厂商的函数调用格式不统一，导致重复开发。

2. 第一阶段：Function Calling的诞生（2023年）

2.1 OpenAI Function Calling的发布背景

2023年6月13日，OpenAI在gpt-4-turbo模型中首次引入函数调用（Function Calling）能力，这一机制的发布标志着LLM从"文本生成器"向"逻辑控制器"的本质跃迁。根据OpenAI的定义，这一机制并非让模型直接执行函数，而是让模型能够识别需要调用函数的场景，并生成符合指定JSON Schema的参数。

2.2 Function Calling的核心机制

2.2.1 工具描述Schema定义

Function Calling要求开发者为每个可调用工具定义一个JSON Schema，包含工具名称、功能描述和参数结构：

{
  "name": "get_current_weather",
  "description": "获取指定城市的当前天气",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "城市名称，如北京、上海"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"]
      }
    },
    "required": ["location"]
  }
}

2.2.2 模型决策调用流程

当用户提问"北京今天天气怎么样？"时，完整的Function Calling交互流程如下：

1. 请求构建：应用将用户问题连同所有可用工具的Schema一起发送给LLM。
2. 意图识别：LLM分析用户意图，判断需要调用get_current_weather函数。
3. 参数生成：LLM生成JSON格式的函数调用请求：{"location": "北京", "unit": "celsius"}。
4. 本地执行：应用在本地执行实际的天气查询API调用。
5. 结果回传：将API返回结果再次发送给LLM，生成最终的自然语言回复。

2.2.3 tool_choice参数策略

Function Calling API提供了tool_choice参数来控制模型的工具选择行为：

2.3 Function Calling的局限性

2.3.1 Tool List固定化问题

在Function Calling模式下，所有可用工具必须在请求时完整提供。这意味着每增加一个新工具，都需要修改应用代码并重新部署。对于需要频繁接入三方服务的场景，这种"硬编码"方式显然不够灵活。

2.3.2 多系统集成复杂性（M×N问题）

随着AI生态的发展，市场上出现了大量模型（OpenAI GPT、Anthropic Claude、Google Gemini等）和大量工具服务。不同厂商的函数调用格式存在差异：OpenAI使用特定JSON格式，Anthropic格式类似但细节不同，其他厂商可能采用完全不同的方案。这就形成了典型的M×N集成问题——M个模型需要分别适配N个工具，开发成本呈指数级增长。

3. 第二阶段：MCP协议的标准化革命（2024年）

3.1 MCP的诞生背景

2024年11月25日，Anthropic开源发布了Model Context Protocol（模型上下文协议，简称MCP），旨在解决AI系统与外部工具集成的碎片化问题。2025年3月27日，OpenAI宣布其Agents SDK正式支持MCP，标志着该协议成为行业事实标准。

3.2 MCP的核心设计理念

3.2.1 “AI时代的USB-C接口”

MCP的设计灵感部分来源于USB-C接口。如同USB-C通过统一接口连接多种设备，MCP旨在为AI应用提供一个"即插即用"的上下文管理框架。任何符合MCP规范的工具服务，都可以被任何支持MCP的AI应用直接调用，无需重复开发适配代码。

3.2.2 客户端-服务器架构

MCP采用经典的三层客户端-服务器架构：

• MCP Host：运行LLM的宿主应用（如Claude Desktop、Cursor、IDE插件等），负责协调多个MCP Client。
• MCP Client：嵌入在Host中的连接器，与特定MCP Server建立一对一连接，负责协议协商和消息路由。
• MCP Server：轻量级服务程序，对接具体数据源或工具，按MCP规范暴露标准化功能接口。

3.2.3 JSON-RPC 2.0通信协议

MCP基于JSON-RPC 2.0协议进行通信，定义了三种核心消息类型：

• Requests：双向消息，带有方法和参数，期望有响应。
• Responses：匹配特定请求ID的成功结果或错误。
• Notifications：无需回复的单向消息。

3.3 MCP的核心原语

MCP定义了三类核心原语（Primitives），用于标准化LLM与外部系统的交互：

3.3.1 Tools（可执行函数）

Tools是LLM可以调用的可执行函数，用于检索信息或执行操作。每个Tool通过装饰器注册，包含名称、描述和参数Schema：

@mcp.tool()
def query_database(sql: str):
    """执行SQL查询并返回结果"""
    return db.execute(sql)

3.3.2 Resources（只读资源）

Resources是结构化数据，可以包含在LLM提示上下文中。例如本地文件、数据库记录、API响应等：

@mcp.resource("file://config.json")
def read_config():
    return open("config.json").read()

3.3.3 Prompts（预定义模板）

Prompts是预定义的任务模板，用于引导LLM完成特定任务，如生成SQL语句、代码审查等。

3.4 MCP如何解决Function Calling的痛点

3.4.1 动态工具发现机制

与Function Calling的固定Tool List不同，MCP支持运行时动态发现和加载工具。Host应用可以在不重启的情况下，通过MCP Client连接到新的MCP Server，自动获取该Server提供的所有Tools、Resources和Prompts。

3.4.2 标准化接口降低集成成本

MCP通过标准化协议，将M×N的集成问题简化为M+N。工具开发者只需实现一次MCP Server，即可被所有支持MCP的AI应用使用；AI应用开发者只需集成MCP Client，即可调用所有符合MCP规范的工具服务。据实测，MCP可将工具集成代码量减少约80%。

3.4.3 一次编码到处执行

MCP的设计理念是"一次编码，到处执行"。开发者只需按照MCP规范开发Server，无需关心底层模型是GPT、Claude还是其他。这种跨模型兼容性极大降低了开发和维护成本。

4. 第三阶段：Skill的渐进式能力封装（2025年）

4.1 Skill出现的背景

随着MCP生态的发展，一个AI应用可能连接数十甚至上百个MCP Server，每个Server又提供多个Tools。这就带来了新的问题：Tool List过于庞大，超出了LLM的上下文窗口限制；大量工具描述会稀释模型对关键信息的注意力。Skill概念正是在这一背景下提出的解决方案。

4.2 Skill的核心概念

4.2.1 Skill作为"工作交接SOP大礼包"

Anthropic将Skill定义为：模块化的能力，扩展了Agent的功能。每个Skill打包了LLM指令、元数据、可选资源（脚本、模板等），Agent会在需要时自动使用它们。

更直观的理解是：Skill就像给Agent准备的工作交接SOP大礼包。想象你要把一项工作交给新同事，不靠口口相传，只靠文档交接，你会准备什么？

• 任务执行SOP：这件事大致怎么做，分哪些步骤。
• 工具使用说明：用什么软件、怎么操作。
• 模板素材：历史案例、格式规范。
• 问题解决方案：可能遇到的问题、规范、解决方案。

4.2.2 SKILL.md文件结构规范

一个标准的Skill是一个目录，必须包含SKILL.md文件，其结构分为两部分：

YAML Frontmatter（头部元数据）：

---
name: code-review
description: 基于OWASP Top 10标准进行代码安全审查
version: 1.0.0
allowed-tools: [Read, Bash, Edit]
---

Markdown Body（正文指令）：

# 代码审查指南

## 审查流程
1. 读取目标文件内容
2. 检查SQL注入风险
3. 检查XSS漏洞
4. 输出审查报告

## 输出格式
- 问题等级：高危/中危/低危
- 问题描述
- 修复建议

4.3 渐进式披露架构

Skill最核心的技术创新是渐进式披露（Progressive Disclosure）架构，它通过分级治理机制实现了对LLM上下文窗口的革命性优化。

实测数据显示，在处理长链条业务流程时，该架构能将上下文Token消耗降低60%-80%，同时显著提升长文本任务中的指令遵循准确率。

4.4 Skill与MCP、Function Calling的关系

Skill与MCP不是替代关系，而是协作关系，可以用"硬件vs软件"来类比：

• MCP（连接层）：它是"管道"，让Claude能"连上"PostgreSQL数据库，解决"能不能访问"的问题。
• Skill（能力层）：它是"逻辑"，教Claude"查询数据库时必须先检查权限，且不能用SELECT *"，解决"做得对不对"的问题。

最佳实践是：用MCP建立连接，用Skill定义流程。两者结合，才能构建出既灵活又可靠的AI Agent系统。

5. 技术实现详解

5.1 Function Calling实现示例

5.1.1 完整调用流程

import openai

# 定义工具
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "获取天气",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {"type": "string"}
            },
            "required": ["location"]
        }
    }
}]

# 调用API
response = openai.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "北京天气"}],
    tools=tools,
    tool_choice="auto"
)

5.2 MCP协议实现详解

5.2.1 初始化与能力协商

MCP会话开始时，Client和Server需要进行能力协商，确定双方支持的功能：

// Client发送初始化请求
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "sampling": {},
      "roots": {"listChanged": true}
    },
    "clientInfo": {
      "name": "claude-desktop",
      "version": "1.0.0"
    }
  }
}

5.2.2 tools/list请求

// Client请求工具列表
{"jsonrpc": "2.0", "id": 2, "method": "tools/list"}

// Server返回
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "query_sql",
        "description": "执行SQL查询",
        "inputSchema": {...}
      }
    ]
  }
}

5.2.3 tools/call调用流程

// Client调用工具
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "query_sql",
    "arguments": {
      "sql": "SELECT * FROM users LIMIT 10"
    }
  }
}

5.3 Skill实现详解

5.3.1 目录结构组织

my-skill/
├── SKILL.md          # 核心指令文档
├── scripts/          # 可执行脚本
│   └── analyze.py
├── references/       # 参考资料
│   └── guidelines.md
└── assets/           # 素材资源
    └── template.json

5.3.2 动态加载机制

Skill的加载遵循渐进式原则：

1. 会话启动：Agent加载所有Skill的元数据（name + description），约100 Token/个。
2. 需求匹配：LLM将用户需求与Skill元数据语义匹配，决定使用哪个Skill。
3. 按需加载：加载选中Skill的SKILL.md正文（<5k Token）。
4. 条件触发：执行过程中如需参考文档，再加载references中的内容。

6. 完整交互流程对比

6.1 Function Calling交互流程

6.2 MCP交互流程

6.3 Skill增强的MCP交互流程

7. 总结与展望

7.1 三代技术的演进脉络

从Function Calling到MCP再到Skill，LLM Agent技术经历了从"能用"到"好用"再到"高效"的演进：

7.2 未来发展趋势

• 协议进一步标准化：MCP有望成为AI领域的HTTP，成为所有LLM与外部系统交互的统一标准。
• Skill生态繁荣：类似App Store的Skill市场将出现，开发者可以发布、交易各类专业Skill。
• 多Agent协作：A2A（Agent-to-Agent）协议的发展将使多个专业Agent能够协同完成复杂任务。
• 安全与治理：随着Agent能力的增强，安全隔离、权限控制、审计追溯将成为关键议题。

7.3 对开发者的建议

1. 拥抱MCP：新项目建议直接基于MCP协议设计，避免重复造轮子。
2. 沉淀Skill：将重复性工作抽象为可复用的Skill，提升团队效率。
3. 关注生态：积极参与MCP和Skill社区，跟进协议演进和最佳实践。
4. 平衡灵活与规范：在标准化和定制化之间找到适合业务场景的平衡点。

LLM Agent技术仍在快速发展中，Function Calling、MCP、Skill三代技术并非简单的替代关系，而是在不同场景下各有优势。理解它们的设计哲学和适用边界，才能在实际项目中做出正确的技术选型，构建出真正有价值的AI应用。

参考资料

1. OpenAI Function Calling官方文档（2023年6月）
2. Anthropic MCP协议规范（2024年11月）
3. Anthropic Agent Skills规范（2025年）
4. LangChain Agent框架文档
5. 腾讯云、CSDN等技术社区深度解析文章