1. 工具调用（Function Calling）
1.1 开发者编写工具函数 (The Definition)
这是第一步，你得给模型"装备"技能。你不仅需要写好代码，还得写好一份说明书。
- 代码实现：实际运行的 Python/JS 函数。
- JSON Schema 描述：模型看不见你的源代码，它只能看到一份关于函数的描述（名称、功能、参数类型）。
例子：如果你想让模型能查天气，你需要定义：
- 名称：
get_weather - 描述："获取指定城市的实时天气"
- 参数：
city(string)
1.2 编写系统提示词 (The Protocol)
你需要告诉模型，它现在拥有了这些"超能力"，以及调用的暗号。
虽然现在的 GPT-4 或 Gemini 都有内置的 tools 接口，但在底层或早期，这都是通过提示词完成的。
提示词示例："如果你发现用户的问题需要查询实时信息，请不要直接回答。请输出以下格式：Action: [函数名], Args: [参数]。"
1.3 模型输出特定格式 (The Thought)
当用户问："上海现在几度？"时，模型会意识到自己不知道实时天气，但它发现手里有一个 get_weather 的工具。
- 模型不会编造答案（理想情况下）。
- 它会进入"中继状态"：输出一段非人类阅读的结构化文本，例如：
JSON{ "call": "get_weather", "parameters": {"city": "Shanghai"} }1.4 开发者编写解析代码 (The Executor)
这是最关键的桥接步骤。模型本身并没有运行代码的权限，运行权限在你的服务器上手里。
- 拦截输出：你的程序监听到模型的返回结果。
- 解析：识别出这是一个工具请求，提取出函数名和参数。
- 执行：你的程序在本地或通过 API 真正去运行
get_weather("Shanghai")。 - 获取结果：比如得到结果
{"temp": "18°C", "condition": "Sunny"}。
1.5 结果回传与最终生成 (The Final Answer)
现在你有了结果，但用户还没看到。你需要把这个结果再次喂给模型，就像在对话记录里追加一条记录：
- 用户：上海现在几度？
- 模型（请求）：调用
get_weather(city="Shanghai") - 系统（反馈）：工具返回结果是 18°C，晴
- 模型（最终）："上海现在的气温是 18°C，天气晴朗。"
2. MCP（Model Context Protocol）
MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 提出的一个标准，旨在为大型语言模型（LLM）提供一种标准化的方式来访问外部工具和数据源。
目的：解决开发者在构建智能体式应用时，需要为每个应用重复编写代码来集成不同工具（如 Slack, GitHub, Google Drive 等）的痛点。
2.1 MCP 的核心组件
2.2 客户端 (Clients)
- 角色：希望访问外部工具或数据的应用程序。
- 示例：Cursor, Claude Desktop, Windsurf。
- 功能：向 MCP 服务器发送请求，获取数据或执行操作。
2.3 服务器 (Servers)
- 角色：提供工具和数据源的软件服务。
- 示例：Slack, Google Drive, GitHub, PostgreSQL。
- 功能：接收来自客户端的请求，并将其转换为对原始工具 API 的调用，然后将结果返回给客户端。
- 来源：部分服务器由服务提供商开发，但也有大量第三方开发者贡献。
3. Skills
- 工具 (Tool)：侧重于单一、原子的功能。例如：
read_file()。 - 技能 (Skill)：侧重于解决具体问题的能力。例如：
code_reviewer()。这个技能内部可能调用了读文件、语法分析、逻辑比较、生成报告等多个原子工具。
一个完整的技能通常由以下四个部分组成：
- 能力描述：告诉模型这个技能"是什么"以及"什么时候用"。这是模型决策的关键，描述越精准，模型误调用的概率就越低。
- 参数规范：严格定义输入格式。例如，"分析财务报表"技能需要：
year(integer),company_name(string),report_type(enum)。 - 执行逻辑：工具背后的代码实现。它可以是简单的 API 调用，也可以是一个复杂的 Python 脚本或多步流转的 MCP 请求。
- 结果解析器：将工具返回的原始数据（往往是杂乱的 JSON 或报文）转化为模型易于理解的摘要或结构化上下文。