AI应用名词解析（二）

接着上一段，这次进入发展阶段，主要讲 FunctionCalling、MCP、RAG 以及 Agent（先导形态）这些内容

如果把 LLM 当成一颗超级大脑，它最大的短板是：它本身没法真正执行任何动作。也就是说，你给它下指令，它就把内容“编排”着完成一遍，但它无法自主感知外部环境，更谈不上对环境产生影响。

举个最直观的例子：你直接问 LLM 今天的天气、日期或者新闻，它通常会胡说，也就是它根本不具备搜索能力。原因很简单：它只是做连续的词语衔接，并不会去查资料；

那如果确实需要搜索，我们能不能先帮它把信息检索出来，再把整段结果当作上下文发给 LLM，让它负责总结，这不就行了？

可问题是这样做太繁琐了。既然如此，能不能把固定的搜索逻辑写成程序，对话时自动触发执行？通过这种自动化流程，就等于让 LLM 获得“动手能力”，也就是对工具的调用与操作能力。

接下来就围绕这个思路的示例，把相关名词逐一说明。

1.1

FunctionCalling

在真实的 AI 应用落地时，必然会碰到一个关键问题：以刚才的“搜索”为例，这个程序怎么判断需要不要搜索？以及应该搜索什么内容？

因此需要再加一段 Prompt，用来规定 LLM 输出的格式，比如要求它用 Json，并约定哪些字段代表什么含义。这样程序才能准确理解模型想表达的意图。于是这个概念就被命名为 FunctionCalling，和开发里前后端约定接口的方式类似。

OpenAI 的开发文档里有一篇专门讲 FunctionCalling（https://developers.openai.com/api/docs/guides/function-calling)

最后把 FunctionCalling 总结一下：

它位于 AI 应用客户端与 LLM 之间。客户端把一组函数的定义提供给模型，模型会在合适的时机决定“要不要触发”。（这里模型输出的是意图，比如要调用哪个函数、传什么参数；真正执行仍是由 AI 应用程序完成，因为 LLM 自身没有实际执行动作的能力），从而避免模型胡编。

它通常属于单一平台内部的一套机制，因此每个 AI 应用都可能有自己不同的 FunctionCalling 定义。

一句话概括：这是一种客户端与模型之间约定的工具调用表达方式。

1.2

MCP

到了更贴近业务的场景，你会发现很多工具其实是通用的。比如 A、B 两个项目都要查数据库，就没必要在每个项目里重复实现一套 FunctionCalling。把这些共用能力做成统一封装再开放出来，反而更高效，这就是 MCP（https://modelcontextprotocol.info/docs/introduction/），最初由 Anthropic 提出。

从直观角度看，MCP 可以理解为：把一些通用功能或特定功能抽象出来，形成一个 MCP 服务器，供 AI 应用程序（或任何“会调工具的模型客户端”）去调用。

MCP（Model Context Protocol）本质上是一个工具调用协议，规定通信与交互的方式。至于客户端与 MCP 之间怎么沟通，可以通过 HTTP、WebSocket、进程间消息，甚至本地脚本等多种形式实现。

MCP 处在 AI 应用客户端和外部工具之间：它把“工具/资源如何用标准化的方式暴露给客户端”这件事统一起来。例如，通过约定消息格式来获取 MCP 提供的可执行工具列表、执行方式，以及最终如何返回结果。

1.3

MCP 和 FunctionCalling 区别

从上面的描述就能看出：MCP 和 FunctionCalling 不在同一层级。

在 Function Calling 里，工具有可能指向 MCP 中的能力。于是整体流程会变成：LLM 先用 Function Calling 传递“需要客户端去调用 MCP 里的哪个工具以及参数”；客户端再依据 MCP 的定义去执行，最后把结果再交还给 LLM。

从 LLM 的视角来看，这件事可以等价为一次 Function Calling。对于 LLM 来说，MCP 往往是“不可见的”，它只会看到：有一组工具可用，而我现在要调用其中某个。

1.4

Agent 智能体

前面提到的那类 AI 应用，只要看起来就能主动执行/调用一些脚本工具，我们就把它归到智能体 Agent。

而“可联网搜索”的对话属于非常常见的需求，所以就再给它单独起了个名字，叫 Web Search（后面就简称 Search，不仅能搜网页，看起来也更“强”。）。

最初的 Agent 可能只是给你的输入消息再塞进一些 Prompt，多少有点噱头；但如今更成熟的 Agent，才是真正让人觉得“有点智能”。除了搜索之外，一些确定性更强的操作也特别适合融进智能体里，比如读取本地文件、查询数据库内容等。

OK，到现在为止，通过注入特定的 Prompt（FunctionCalling / MCP）解决了 LLM 与 Agent 之间沟通不规范的问题，并且还能让 LLM 间接具备调用工具的能力，比如读取文件、执行命令、搜索等。

1.5

RAG

说到搜索能力，如果展开讲：在把用户输入的提示词发送给 LLM 之前，先把文本切分，再去向向量数据库发起查询。这样就能找到语义相近的片段，也就是“能召回相关内容”的数据库。

随后把查询到的结果合并进上下文，用来增强生成内容的可靠性（降低幻觉）以及相关性。这种做法通常被称为：检索增强生成 Retrieval-Augmented-Generation（RAG）。当年这套方法还火过一阵子，有些中转节点甚至靠它来偷懒、减少 Token 消耗。

从原理上看它很简单：检索相关语料 → 把结果增强到上下文 → 再进行生成。但真正要把它用好就没那么容易了，因为每一步都会对应一系列难点，尤其是面对多模态数据的时候。