夜雨聆风请在微信客户端打开
引言
随着大语言模型（LLM）从"聊天玩具"走向真正的应用基础设施，一套全新的技术术语体系正在形成。无论你是开发者、产品经理还是技术决策者，理解这些概念及其相互关系，已经成为必修课。
本文将系统梳理AI应用开发中的核心术语：Token、API请求次数、MCP、Skills、Function Calling、Tool、Agent、供应商、SDK、提示词库，并剖析它们之间的交互关系。
核心术语速览
| Token | ||
| API请求次数 | ||
| 提示词库 | ||
| Function Calling | ||
| Tool | ||
| Skills | ||
| MCP | ||
| Agent | ||
| 供应商 | ||
| 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
关键区别：
两者通常是 相互制约 的关系：
合并多次请求为一次（减少请求次数）→ 单次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 通常包括：
清晰的指令：明确告诉 AI 要做什么（翻译、总结、写代码、解释概念等）。 背景信息：提供必要的上下文，让 AI 理解场景。 输出格式：指定回复的风格（正式、幽默）、长度（几句话、几段话）或结构（列表、表格、代码块）。 示例（可选）：给一个输入→输出的例子，教 AI 按你想要的模式回答。
为什么 prompt 很重要？
同样的模型，不同 prompt 得到的结果质量可能相差很大。精准、详细的 prompt 能显著减少 AI 的“胡编乱造”或答非所问，让你更快得到满意的答案。
简单对比：
所以，学会写好的 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的关系：
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 对比：
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调用：
供应商 —— LLM能力的提供方
定义：提供大语言模型API访问服务的企业。
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的深度关系
内在关系图
典型场景的消耗对比
为什么不能只看其中一个
完整技术架构交互图
整体关系图
一次Agent调用的完整时序图（含API请求次数标注）
多供应商SDK统一调用架构
常见组合场景与资源消耗
未来趋势
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是能力来源与接入方式
请在微信客户端打开
来日方长，未来可期。
