AI黑话：Agent、MCP、Function Calling…是什么意思？

最近这一段时间，各种跟 AI 相关的词儿就像洪水一样涌进我的屏幕。Agent、MCP、Function Calling……这些到底是什么鬼？

有人说 Agent 是一个智能实体。得，那智能实体又是什么？
有人说 MCP 是 AI 时代的 USB 协议。噢？那它是不是也能接个 U 盘啥的？
这些概念听起来既熟悉又陌生，让人一头雾水，它们到底有什么真实的意义？

今天这篇文章，我就打算用最简单的大白话，把 Agent、MCP、Prompt、Function Calling 这些核心概念连接起来，带你一起理清它们之间的关系。

话不多说，我们现在就开始。

还记得 2023 年，当 OpenAI 刚放出 GPT 的时候，AI 在大家眼里好像就只是一个聊天框。我们通过这个聊天框给 AI 模型发送一条消息，AI 模型就生成一个回复。

我们发出去的这条消息，就是我们常说的 User Prompt，用户提示词。它通常就是我们想问的问题或者想说的话。

但你仔细想想，在现实生活中，我们和不同的人聊天时，即使说的是一模一样的话，对方也会基于自己的经验给出不同的回答。

比如说，我说“我肚子疼”，我妈可能会问我是不是需要去医院；我爸可能让我赶紧去趟厕所；而我女朋友嘛，可能就直接蹦出来一句：“滚！我也肚子疼！”

但 AI 原本没有这样的人物性格（persona），所以它只能给出一种泛泛的、安全的、标准的回答，听起来就特别没劲。

于是，我们就想给 AI 也赋予一个“人设”。最直接的办法，就是把“人设”信息和用户的消息一起，打包成一个完整的 User Prompt 发送过去。

比如说，我们可以这样写：“请扮演我的女朋友，我现在对你说：‘我肚子疼’。”

这时候 AI 可能就会回复：“滚！我也肚子疼！” 嗯，好像是那个味儿了。

但问题是，“扮演我温柔的女朋友”这句话，并不是我们真正想说的内容。总感觉怪怪的，不够自然。

所以，后来人们决定把“人设”信息从用户真正要说的消息中分离开来，放到另一个独立的提示词里。这个，就是 System Prompt，系统提示词。

System Prompt 主要负责描述 AI 的角色、性格、背景信息、说话语气等等。基本上，所有不是由用户直接说出来的，但又希望能影响 AI 回复的内容，都可以放进 System Prompt 里。每当用户发送 User Prompt 时，系统会自动把对应的 System Prompt 也一起发送给 AI 模型。这会让整个对话流程感觉更加自然。

在网页版的聊天机器人里，System Prompt 通常是由系统预设的，用户没那么容易直接改动。不过，网站通常会提供一些设置项。例如，ChatGPT 有一个叫做“定制 ChatGPT”的功能，用户可以在里面写下自己的偏好，这些偏好就会自动成为 System Prompt 的一部分。

然而，即便有了完美的人设，AI 归根结底还是个聊天框。你问它一个问题，最多给你一个答案，或者告诉你怎么做某件事。但具体去执行任务，还是得你自己来。

那能不能让 AI 自己去完成任务呢？

最早期的尝试，是一个叫做 AutoGPT 的开源项目。它是一个跑在本地的小程序。如果你想让 AutoGPT 帮你管理电脑里的文件，首先需要写一些文件管理的功能，比如 list_files 用于列出目录、read_file 用于读取文件等等。

然后把这些功能，包括它们的用途说明、使用方法，注册进 AutoGPT。

AutoGPT 会根据这些信息，生成一段 System Prompt，告诉 AI 模型用户提供了哪些工具（tools）、它们有什么用，以及如果 AI 想使用它们，应该返回什么格式的内容。

最后，它把这个 System Prompt，连同用户的请求（比如“帮我找到《原神》的安装目录”），一起发给 AI 模型。

如果 AI 模型足够聪明，它就会按照 System Prompt 要求返回一个特定格式的消息，表明它希望调用哪个功能。

AutoGPT 在收到 AI 返回的消息后，解析出来，就知道应该调用哪个对应的函数了。然后，它把这个函数的执行结果再发回给 AI。AI 根据这个结果，再决定下一步应该做什么。这个过程不断重复，直到任务完成。

像 AutoGPT 这种负责在 AI 模型、工具和最终用户之间进行信息传递的程序，我们就称它为 AI Agent，AI 代理。而那些提供给 AI 调用、可以执行特定功能的函数或服务，就叫做 Agent Tools，AI 工具。

不过，这种架构有个小问题。尽管我们在 System Prompt 里明确规定了 AI 应该返回的格式，但 AI 模型说到底是一个概率模型，它还是有可能返回不符合格式的内容。为了处理这些“不听话”的情况，很多 AI Agent 会在检测到 AI 返回格式错误时，自动进行重试。第一次失败了，再试第二次。

现在市场上不少知名的 Agent，比如 llm-compiler (之前叫 Cline)，其实还在用这种方式。但这来回的重试，总让人觉得有点不靠谱。

于是，主流的模型服务提供商们出手了。ChatGPT、Claude、Gemini 等等，相继推出了一个新的功能，叫做 Function Calling，函数调用。

这个功能的核心思想是：统一格式、规范描述。

回到找《原神》目录的例子，之前我们用 System Prompt 来告诉 AI 有什么工具、返回什么格式。但这些描述是用自然语言随便写的，只要 AI 能理解就行。

Function Calling 把这些描述标准化了。比如，每个 Tool 都用一个 JSON 对象来定义，说明工具的名称（name 字段）、功能的描述（description 字段）、需要的参数（parameters 字段）等等。

然后，这些描述工具的 JSON 对象，也被从 System Prompt 中分离开来，放到了一个独立的字段里。

最后，Function Calling 还强制规定了 AI 在需要使用工具时应该返回的固定格式。所以，System Prompt 里关于返回格式的定义也可以去掉了。

这样一来：

• 所有工具的描述都集中在一个地方；

• 所有工具的描述都遵循同样的格式；

• AI 在使用工具时，返回的响应也遵循同样的格式。

这样，开发者就可以更有针对性地训练 AI 模型去理解这种调用场景。在这种情况下，即使 AI 还是生成了不正确的响应，因为响应格式是固定的，AI 服务端自己就能检测到，并执行重试。这个过程用户甚至完全感觉不到。

得益于这些优点，现在越来越多的 AI Agent 开始从完全依赖 System Prompt 转为使用 Function Calling。

但 Function Calling 也有它自己的问题：目前还没有一个统一的标准。各家大公司的 API 定义都不一样，而且很多开源模型还没支持 Function Calling。所以，想要写一个真正跨模型兼容的 AI Agent，其实挺麻烦的。

因此，System Prompt 和 Function Calling 这两种方法，目前在市场上是并行存在的。

我们刚才讨论的所有内容，都是关于 AI Agent 和 AI 模型之间的通信。接下来，我们把目光转向另一边：AI Agent 怎么和 Agent Tool 通信呢？

最简单的方式，就是把 AI Agent 和 Agent Tool 写在同一个程序里。Agent 需要用哪个 Tool，直接函数调用就行了，一步到位。现在市面上大部分的 Agent 都是这样工作的。

但后来大家慢慢意识到，有些 Tool 功能其实很常见。比如，一个网页浏览 Tool，可能会被很多不同的 Agent 都需要。总不能在每个 Agent 里都复制一遍同样的代码吧？这太麻烦，也不优雅。

于是，大家就想了个办法：把 Tools 变成服务，集中部署，让所有的 Agent 去调用它们。

这个，就是 MCP。

MCP 是一套专门设计的通信协议，它用于规范 Agent 和 Tool 服务之间的交互方式。运行着 Tool 服务的实体叫做 MCP Server，调用这些服务的 Agent 叫做 MCP Client。

MCP 定义了 MCP Server 和 MCP Client 之间如何交流，以及 MCP Server 必须提供哪些接口。比如，查询 MCP Server 里有哪些 Tool、Tool 的功能是什么、描述、需要哪些参数、什么格式等等。

除了我们理解中需要函数调用的那种普通 Tool，MCP Server 还可以直接提供数据，类似于文件读写服务，这在 MCP 里叫做 Resource（资源）；或者给 Agent 提供预设的提示词模板，这叫做 Prompt（提示词）。

MCP Server 可以运行在和 Agent 同一台机器上，通过标准输入/输出（stdin/stdout）进行通信；也可以部署在网络上，通过 HTTP 等协议进行通信。

这里要特别强调一下，尽管 MCP 是为了 AI 的场景而定制的标准，但 MCP 本身跟 AI 模型其实没有关系。它并不关心 Agent 使用的是哪个模型。MCP 只负责帮 Agent 管理 Tool、Resource 和 Prompt 这些东西。

最后，我们来把整个流程梳理一遍。

假设我听说我女朋友肚子疼了。于是，我问我的 AI Agent（或者说是 MCP Client）：“我女朋友肚子疼怎么办？”

Agent 把我的问题包装成一个 User Prompt。

接着，Agent 利用 MCP 协议，从 MCP Server 里查询到所有可用的 Tool 的信息。

AI Agent 会把这些 Tool 信息转换成 System Prompt 或者 Function Calling 的格式。然后，将这些内容和用户的请求（User Prompt）打包，一起发送给 AI 模型。

AI 模型注意到有一个叫做 web_browse 的网页浏览 Tool。于是，通过普通回复或 Function Calling 的格式，它生成了一个调用这个 Tool 的请求，希望能去网上搜索一下解决方案。

Agent 收到这个请求后，利用 MCP 协议，去调用 MCP Server 里的 web_browse Tool。

web_browse Tool 在访问指定网页后，把内容返回给 Agent。

Agent 再把这个结果转交给 AI 模型。

AI 模型根据网页内容和自己的“思考”，生成最终的答案：“多喝热水”。

最后，Agent 把这个结果显示给用户。至于后来我女朋友有没有夸我体贴……这部分咱们就按下不表了。

总之，System Prompt、User Prompt、AI Agent、Agent Tool、Function Calling、MCP 以及最底层的 AI 模型，它们就是这样互相连接又各司其职的。它们不是互相取代的关系，而是像齿轮一样，共同构成了 AI 自动化协作的完整体系。

很多人说 AI 的进步让人焦虑，人类最终会不会被 AI 取代？未来的情况到底会怎么样？我不知道。但经常在我心里涌起的，与其说是恐惧，不如说是一种微妙的兴奋。因为我们每个人都那么渺小，活在时代的缝隙里，大多数时候，只能无力地看着洪流奔涌而过。在我们过去经历的每一次重大的技术变革中，普通人往往都只是被推着往前走。也许改变了工作生活的方式，但他们始终是变革的参与者。