引言

  随着大语言模型（LLM）从"聊天玩具"走向真正的应用基础设施，一套全新的技术术语体系正在形成。无论你是开发者、产品经理还是技术决策者，理解这些概念及其相互关系，已经成为必修课。
  本文将系统梳理AI应用开发中的核心术语：Token、API请求次数、MCP、Skills、Function Calling、Tool、Agent、供应商、SDK、提示词库，并剖析它们之间的交互关系。

核心术语速览

术语	一句话定义	类比（传统软件开发）
Token	LLM计费和上下文的最小原子单位	字符/单词的"代币"
API请求次数	调用LLM接口的次数	HTTP请求次数
提示词库	可复用、可管理的Prompt模板集合	代码片段库 / 配置模板
Function Calling	LLM主动调用外部函数的能力	RPC调用 / API网关
Tool	可被LLM调用的具体功能实现	函数 / 微服务
Skills	面向任务的高层能力封装（含Tools+Prompt）	技能树 / 插件系统
MCP	模型与外部工具/数据的标准化通信协议	HTTP + RESTful规范
Agent	具备自主规划、调用Tools、记忆的智能体	脚本机器人 → 自主决策机器人
供应商	提供LLM API服务的企业	云厂商（AWS/Azure）
SDK	快速接入供应商能力的开发工具包	各云厂商的SDK

Token —— LLM世界的"原子货币"

定义：Token是大语言模型处理文本时的最小基本单位。它不等同于字符或单词，而是模型词汇表中的整数索引对应的片段。

核心特点：

• 计费单位：OpenAI等供应商按Token计费（输入+输出）
• 上下文限制：模型有最大Token数限制（如GPT-4-Turbo为128K）
• 切分规则：1个中文字符 ≈ 1-2 Token，英文单词平均1-1.5 Token

示例：

文本："Hello, 世界"
Token序列：["Hello", ",", " 世", "界"]  // 约4-5个Token

在架构中的角色：Token是LLM交互的基本"通货"，所有的Prompt、输出、Function Calling的入参/出参都消耗Token。

API请求次数 —— 计费与限频的"交互计数器"

定义：调用LLM供应商API接口的单次交互次数。每次向LLM发送消息并收到响应，计为1次API请求。

核心特点：

• 计费维度：多数供应商按 Token 计费，但也有按请求次数计费的套餐
• 限频控制：供应商通常有 RPM（每分钟请求数）和 TPM（每分钟Token数）双重限制
• 与Token的关系：一次请求可能消耗很少Token（如"是/否"问答），也可能消耗很多Token（如总结整本书）

API请求次数与Token的关系：

总成本 = Σ(每次请求的输入Token × 输入单价 + 输出Token × 输出单价)
而请求次数 = 调用次数

一个Agent场景示例：
- 用户一次对话可能触发 5 次API请求（思考→调用Tool→再思考→再调用Tool→最终回答）
- 每次请求消耗 500-2000 Token
- 总Token消耗 = 5次请求 × 平均1200 Token = 6000 Token

关键区别：

维度	API请求次数	Token消耗
计费方式	部分供应商按次计费	主流计费方式
限频维度	RPM（Request Per Minute）	TPM（Token Per Minute）
优化目标	减少往返次数	精简Prompt和输出
Agent场景	Tool调用链越长，请求越多	单次请求内容越长，Token越多

两者通常是 相互制约 的关系：

• 合并多次请求为一次（减少请求次数）→ 单次Token可能暴增
• 拆分请求（增加请求次数）→ 单次Token减少，但总Token可能因重复上下文而增加

提示词库 —— Prompt工程的可复用资产

定义：对提示词进行版本化、分类、参数化管理的系统，用于提高LLM调用的质量和一致性。

核心功能：

• 模板变量：请总结以下内容：{{content}}，字数限制：{{word_limit}}
• 版本管理：同一场景的不同Prompt版本（v1/v2）
• A/B测试：对比不同Prompt的效果
• 按场景分类：摘要/翻译/分类/代码生成等

典型实现：

• 简单的：JSON/YAML配置文件目录
• 复杂的：LangChain PromptHub、DSPy、自研提示词管理平台

与Agent的关系：Agent根据当前任务类型，从提示词库中选择合适的Prompt模板来调用LLM。
Prompt 是你向 AI 模型（如 ChatGPT、DeepSeek）输入的指令、问题或信息，用来引导它生成你想要的回复。

可以把 prompt 简单理解为“你给 AI 的提问或任务描述”。

举个例子：

• 普通提问：“什么是黑洞？” → 这是一个 prompt。
• 复杂任务：“用通俗的语言向小学生解释黑洞，并给出一个比喻。” → 这也是一个 prompt，更具体、效果更好。

一个好的 prompt 通常包括：

1. 清晰的指令：明确告诉 AI 要做什么（翻译、总结、写代码、解释概念等）。
2. 背景信息：提供必要的上下文，让 AI 理解场景。
3. 输出格式：指定回复的风格（正式、幽默）、长度（几句话、几段话）或结构（列表、表格、代码块）。
4. 示例（可选）：给一个输入→输出的例子，教 AI 按你想要的模式回答。

为什么 prompt 很重要？

同样的模型，不同 prompt 得到的结果质量可能相差很大。精准、详细的 prompt 能显著减少 AI 的“胡编乱造”或答非所问，让你更快得到满意的答案。

简单对比：

不好的 prompt	更好的 prompt
“写一首诗”	“写一首关于秋天、押韵、带点忧伤的短诗”
“怎么学编程？”	“我零基础想学 Python 做数据分析，请推荐学习路线和免费资源”

所以，学会写好的 prompt = 学会更好地使用 AI。这在 AI 领域甚至有专门的说法叫 提示工程。

Function Calling —— LLM调用外部世界的"手"

定义：LLM在生成回复时，决定调用一个外部函数的能力。它不是LLM直接执行代码，而是输出一个结构化的函数调用请求。

工作流程：

1. 用户："北京今天天气怎么样？"
2. 开发者将天气API描述为Function传给LLM
3. LLM分析后输出：{ "function": "get_weather", "arguments": { "city": "北京" } }
4. 开发者代码执行该函数，获取天气数据
5. 开发者将结果再传给LLM（第二次API请求）
6. LLM生成最终回复："北京今天晴天，25°C"

关键点：

• LLM 不执行 函数，只决定调用哪个函数及参数
• 函数的实际执行由开发者代码完成
• 需要将函数的描述（JSON Schema）传给LLM

API请求次数视角：一次带Function Calling的交互通常需要 2次API请求（第1次得到调用指令，第2次发送Tool结果并获取最终回复）。

Tool —— Function Calling的具体"抓手"

定义：Tool是Function Calling的具体实现载体，是对一个可调用功能的完整描述（含函数签名、描述、参数Schema、实际执行逻辑）。

Tool vs Function Calling的关系：

概念	层面	职责
Function Calling	能力/协议	LLM输出函数调用请求的能力
Tool	具体实现	某个具体功能的JSON Schema + 执行代码

Tool示例：

weather_tool = {
    "name": "get_weather",
    "description": "获取指定城市的天气",
    "parameters": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "城市名"}
        },
        "required": ["city"]
    },
    "func": lambda city: requests.get(f"weather.com/{city}")
}

Skills —— 任务导向的高级能力封装

定义：Skills是对某一类任务的完整能力封装，通常包含：目标描述 + 相关Tools + 示例Prompt + 成功标准。

Skills vs Tools 对比：

维度	Tool	Skill
粒度	单一功能（如"查天气"）	完整任务（如"行程规划"）
内容	函数签名 + 实现	Tools组合 + Prompt策略 + 流程
是否可组合	被Skill组合	可以组合多个Tools
API请求次数	不直接产生API请求	一个Skill可能包含多次API请求

MCP —— 模型与工具的标准化"普通话"

定义：MCP（Model Context Protocol）是由Anthropic提出并开源的协议，用于标准化LLM与外部数据源、Tools之间的通信方式。

MCP架构图：

MCP核心概念：

• Resources：暴露数据（文件、数据库记录）
• Tools：暴露可执行函数
• Prompts：暴露可复用的Prompt模板

对比：

• 没有MCP时：每个Tool写一套HTTP接口 + 文档 + 认证
• 有MCP后：实现一套MCP Server，任何支持MCP的Client都可直接调用

Agent —— 自主规划与执行的智能体

定义：Agent是能够自主理解目标、拆解步骤、调用Tools、观察结果、规划下一步的闭环智能体。

核心循环（ReAct模式）：

Thought → Action → Observation → Thought → Action → ... → Final Answer
思考      执行      观察结果      再思考      再执行        最终回复

Agent架构图：

Agent vs 普通LLM调用：

维度	普通调用	Agent
任务类型	单轮、明确	多步、需分解
API请求次数	1次	N次（取决于步骤数）
Token消耗	较少	较高（含多轮上下文）
Tool使用	预先指定	自主决策是否/何时/用哪个
出错处理	直接报错	可重试、换Tool、调整参数

供应商 —— LLM能力的提供方

定义：提供大语言模型API访问服务的企业。

供应商	代表模型	特点
OpenAI	GPT-4o, GPT-4-Turbo	综合能力强，生态完善
Anthropic	Claude 3.5 Sonnet	安全性，长上下文，MCP主导
Google	Gemini 1.5 Pro	超长上下文（2M），多模态
微软	Azure OpenAI	企业级合规，与Azure集成
国内	通义千问、文心一言、DeepSeek	合规、中文优化、价格低
开源部署	Llama 3, Qwen	数据私有，成本可控

SDK —— 快速接入供应商的开发工具包

定义：供应商提供的编程语言库，封装API调用、认证、重试、流式响应等底层细节。

示例（OpenAI SDK）：

from openai import OpenAI
client = OpenAI(api_key="your-key")

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

API请求次数与Token的深度关系

内在关系图

典型场景的消耗对比

场景	API请求次数	总Token消耗	典型应用
单轮问答	1	200-1000	简单咨询
带Tool的问答	2	500-2000	查天气、计算
简单Agent（3步）	4-6	2000-5000	单Tool多轮
复杂Agent（多Tool）	8-15	5000-20000	旅行规划、数据分析
多Agent协作	20-50+	20000-100000+	复杂任务分解

为什么不能只看其中一个

完整技术架构交互图

整体关系图

一次Agent调用的完整时序图（含API请求次数标注）

多供应商SDK统一调用架构

常见组合场景与资源消耗

场景	推荐组合	API请求次数	Token消耗
简单文本处理	提示词库 + 任意供应商	1次	200-1000
带Tool的单次调用	Tool + Function Calling	2次	500-2000
复杂多步任务	Agent + Skills + Tools	5-15次	3000-15000
企业多Tool系统	MCP + Agent	取决于任务复杂度	取决于任务复杂度
多供应商切换	统一SDK抽象层	取决于路由策略	取决于路由策略
成本敏感场景	开源模型 + 本地部署	无限制（自建）	无API费用

未来趋势

• MCP将成为Tool互操作的标准：类似HTTP在Web中的地位，减少重复造轮子。
• Agent从实验走向生产：2025-2026年是Agent落地的关键窗口期。
• Skills会被产品化：各厂商会推出"财务分析Skill"、"客服Skill"等开箱能力。
• 提示词库走向平台化：团队内共享、A/B测试、版本管理成为标配。
• 成本优化将更精细化：同时关注API请求次数和Token消耗，寻找最优平衡点。

总结

理解这一套术语体系的关键在于区分层级和职责：

• Token是最底层计量单位，决定直接成本
• API请求次数是交互次数，影响延迟和限频
• 提示词库是Prompts的管理基建
• Function Calling是LLM与外部交互的能力
• Tool是能力的具象实现
• Skills是对Tools+Prompts的场景化封装
• MCP是标准化的Tool通信协议
• Agent是整合上述所有能力的自主决策实体
• 供应商和SDK是能力来源与接入方式