AI 相关概念解释

LLM

大语言模型（Large Language Model）是基于海量文本数据训练的深度学习模型（通常基于 Transformer 架构，如 GPT-4、Claude 3 等）。

• 核心能力：理解自然语言并生成人类可读的回复，具备强大的通用知识推理、文本总结、翻译、代码编写等能力。
• 在 AI 架构中的角色：通常被视为整个 AI 系统的“大脑”，负责接收指令并进行逻辑推理与决策。

Agent

智能体（Agent）是指能够感知环境并自主采取行动以实现特定目标的系统。在当前的语境中，通常是指基于 LLM 构建的 AI Agent。

• 核心特征：它不仅能“说话”（生成文本），还能“行动”。通过赋予大模型规划记忆（Memory）、工具调用（Tool Use）和执行反思（Reflection）的能力，Agent 能够自主地完成复杂的多步任务。
• 类比：如果说 LLM 是一个聪明但没有手脚的大脑，那么 Agent 就是包含了大脑、四肢以及工具箱的“数字虚拟员工”。

MCP

模型上下文协议（Model Context Protocol）是一种标准化的协议架构（由 Anthropic 提出并开源），旨在打破数据孤岛，安全地将 AI 模型与外部数据源和工具连接起来。

• 核心作用：它提供了一个统一的标准，让开发者可以在不同的 AI 智能体和数据源（如本地文件系统、数据库、第三方 API 等）之间建立双向连接。
• 架构：包含 MCP Hosts（如 IDE 或聊天客户端）、MCP Clients（在 Host 内请求数据的组件）和 MCP Servers（暴露具体数据或功能的后端服务）。
• 如何通俗地理解 MCP Server：你可以非常形象地把它理解为一个**“特定能力与工具的合集/路由节点”**。就像传统的 Web 后端微服务，它对外暴露了一组标准的 API（即 Tool），专门负责某一块领域的功能。
  • 典型例子（GitHub MCP Server）：假设你运行了一个 GitHub 的 MCP Server，这相当于启动了一个本地的微服务。这个 Server 像菜单一样向 AI 声明了自己有 create_issue、search_repo、read_file_from_github 这几个具体的 Tool。当 AI 判断需要查阅你远程仓库的代码时，就会发送符合 MCP 协议的请求给这个 Server，Server 再去真正调用真实的 GitHub API 执行动作，并把结果按标准格式返还给 AI。
• 多 MCP Server 协同（AI 如何知道该调哪个？）：如果在本地同时连接了 GitHub 服务器、本地文件系统服务器、SQL 数据库服务器等多个 MCP Server，客户端（Host）会向所有的 Server 拉取它们提供的“工具清单”。然后，Host 会把这一大堆 Tool 整合在一个全局的说明书里，连同用户的提问一起发送给提供 Function Call 能力的大模型（LLM）。
  • 实际上大模型（LLM）并不知道，也不需要知道这些工具来源于哪个具体的后端服务。它只阅读这些被整合提交给它的工具的自然语言描述（比如 read_local_file 和 search_github_repo），根据用户的提问自己推断出应该呼叫哪个工具名字。当 LLM 说出要用 search_github_repo 之后，客户端（Host）自己就清楚这个工具归 GitHub 的节点管，于是把指令直接路由给那个相应的 Server 进程去跑。
• 通用基座的职责极度简化（通信解耦）：由于 MCP 的存在，通用基座（如 Claude 客户端或 Cursor）根本不需要关心具体的业务逻辑是如何用代码实现的。这就好比电脑主板（基座）与 USB 接口（MCP 协议）：主板厂商不需要自己去造具体的鼠标、键盘或打印机。只要外部设备厂商（社区的 MCP Server）按 USB 标准把设备插上，电脑就能识别出它是个“打印机”。不管打印机内部是怎样进纸、喷墨的，主板只负责无脑地把你想打印的内容通过标准化接口传过去就行了。这样就真正实现了“基座出脑子，社区生态出各行各业的手脚”的万物互联愿景。

Function Call

函数调用（Function Calling）是现代大语言模型（如 GPT-4 等）具备的一种核心能力机制。

• 核心特征：它允许开发者在与 LLM 交互时，向模型描述一组预先定义好的函数（即 Tools 的签名和参数表）。模型如果判断需要外部信息来回答问题，会自动输出一段结构化数据（通常是 JSON），指明“请帮我调用 A 函数，并传入 B 和 C 这两个参数”。
• 与 Tool 的区别：Function Call 是模型的能力与机制（模型决定“调什么函数并给出参数”），而 Tool 是实际被执行的具体接口（外部系统拿到参数后去执行具体代码，再把结果还给模型）。

Tool

工具（Tool）是 AI 智能体用来与外部世界交互的具体函数或 API 接口。

• 核心作用：由于原生的大模型本身是静态的且不具备实时获取外部信息或执行操作的能力（比如无法联网、无法直接读写本地文件），“工具”为模型提供了这些能力。
• 使用方式：人类开发者定义工具的用途和参数格式（通常通过 JSON Schema），LLM 会在需要时决定调用哪个工具并生成对应的参数，随后外部环境执行该工具并将结果返回给 LLM，LLM 基于结果继续推理。例如：网络搜索（Web Search）、文件读取（Read File）、执行终端指令等都是典型的 Tool。
• 工具过多的挑战与解决（Context 占用问题）：如果系统中接入了上百个工具，每次提问都把所有工具的详细说明（JSON Schema）全量发送给大模型，会极大地消耗和占用 Context（上下文窗口和 Token），还会导致大模型“挑花眼”反而降低命中准确率。因此在实际的工程落地中：
  • 动态检索（RAG for Tools）：Host 会先将所有工具的功能描述进行向量化存储，当用户提问时，先在本地做一个语义匹配搜索，只挑出与当前问题最相关的 3~5 个工具发给大模型做 Function Call 推理。
  • 多级路由（Multi-Agent Router）：先用一个轻量级大模型判断用户的意图分类（比如“这是一个关于 GitHub 的问题”），然后仅把该意图类别下的工具加载进来交给大模型执行。
  • 状态保持与提示词缓存（Prompt Caching）：由于大模型接口（API）本质上是无状态的，这就意味着在多轮对话中，Agent 确实需要每次都把这些工具说明（Schema）重新打包发给 LLM。为了解决重复传输带来的高昂成本和高延迟，现代前沿模型（如 Claude 3.5、GPT-4o）推出了 Prompt Caching 技术。Host 可以将庞大且不变的“工具集说明和系统配置”固定缓存在大模型服务端，后续每轮对话只需要发送新增的用户提问（Query）即可，极大地提升了响应速度并降低了 API 费用。

综合示例：串联 MCP、Function Call 与 Tool

假设你正在使用一个支持 AI 代码助手的 IDE（比如拥有 MCP 插件的 VS Code），并且你问 AI：“请帮我看看项目根目录下的 package.json 里面写了什么？”

整个过程是如何流转的？

1. MCP 的连接与发现：AI 助手（作为 MCP Host/Client）启动时，通过 MCP (模型上下文协议) 连接到了一个本地文件系统的 MCP Server。这个 Server 将自己拥有的各种能力以标准化的格式声明给 AI 助手，其中就包含了一个名为 read_file 的 Tool (工具)。
2. LLM 与 Function Call：AI 助手把你提的问题连同 read_file 的工具说明（基于 JSON Schema 格式）一起发送给云端的 LLM（大模型）。在大模型内部推理后，发现自己没法直接读你电脑里的文件，但通过提供的工具列表发现 read_file 可以做到。于是 LLM 触发了 Function Call (函数调用) 机制，它没有直接回答文字，而是输出了一段带有指令的结构化数据（如 JSON），意思是：“请帮我调用 read_file 函数，参数是 path='package.json'”。
3. Tool 的实际执行：AI 助手（在宿主机本地环境）拦截到了这个 Function Call 请求，它并没有让大模型去读文件，而是通过 MCP 协议向本地文件系统 MCP Server 发出调用指令。此时，真正的 Tool（一段真实的读取硬盘文件的 Node.js/Python 代码）被执行，读取了 package.json 的文本内容。
4. 大模型收到结果并回答反馈：AI 助手把 Tool 拿到的文件内容作为“观察结果 (Observation)”拼接在上下文中重新发回给 LLM。大模型基于文件内容总结后，最终把可读的纯文本回答输出给你。

Skills

技能（Skills）通常指赋予 AI 完成特定领域任务的、预先定义好的一组指令（Instructions）、知识和能力的集合。

• 核心作用：与基础的 Tool（通常仅仅是一个执行函数）不同，Skill 更偏向于“行为范式”或“领域知识库”。当给 Agent 装备某个特定领域的 Skill 时，Agent 就掌握了完成该领域任务的最佳实践或专业工作流。
• 在系统中的体现：通常体现为高度定制化的提示词系统（Prompt）、特定的文件操作规范或者组合了多个 Tool 形成的高级功能模块。