由于最近AI Agent的爆发，相关的名词一个个接踵而来，什么Agent、Function calling、MCP，这一个个到底是什么，不免让人混乱，介于现在网上好像没有特别清晰的科普解释（至少我没找到），所以我在了解学习相关知识时，把我了解到的一些文档的内容结合我自己的理解记录在此。如有错误恳请各位大佬指正！
首先，从我们最常接触的智能体（Agent）开始吧。
Agent是什么？OpenAI是这么定义Agent的：智能体是能独立地、能代表你完成任务的系统。
摘自《A practical guide to building agents》
——OpenAI
更具体的说Agent具备了以下的特征：
Agent能利用LLM管理工作流的执行并且能做出决策。它能识别何时工作流完成，并在必要的时候主动纠正自身的操作；如果出现错误，能中止执行并将控制权转移给用户。
Agent能访问多种工具与外部系统进行交互，并在根据当前的工作流选择最合适的工具，来获取必要的信息或者执行操作。
所以一个基础的Agent的一般由模型（Model）、工具（Tool）、指令（Instructions）组成。
Model作为Agent的大脑，为Agent的推理和决策提供动力；
Tool作为Agent的四肢五官，为Agent获取信息，执行操作；
Instructions则像约束Agent的法律，为Agent提供明确的行为指南和安全范围；
根据上面的内容相信你大概知道Agent大概是个什么玩意了，其实说白了就是一个长了手的LLM系统，它不止局限于回答你的问题了，而是能切实的帮助的完成一些实际的操作，让咋们用户真正的能做成“甩手掌柜”。
好了，现在我们知道Agent是个什么东西，那又出现了一个问题：Agent是怎么调用这些Tool的呢？要是早能调用Tool，那不是我们早就能解放双手了么？
这就引出了第二个关键的专业名词Function Calling。
Function Calling
Function Calling翻译过来就是函数调用，是不是一下就有点拨开云雾的感觉了，其实就像是在软件开发中的API调用，接着往下看你就知道为什么这么说了。
Function Calling是什么？
简单来说就是，在开发者定义好想让LLM使用的工具后，LLM会根据系统prompt和用户的输入来判断是否调用这些函数，从用户输入中提取出函数需要的参数，传递给工具，工具执行并为模型提供结果，最后模型把结果合并到输出中发给用户。
下面是OpenAI官方平台中描述Function Calling的流程图。官方平台还有非常详细的具体代码实例，想深入了解一下可以去看看，网址我贴到这。Function calling - OpenAI API
其实在Function Calling出来之前，开发者都是手动将工具描述注入system prompt中并为工具调用编写单独的解析器，但是通过这种方式注册的Tool在调用时总会出现一些小毛病(比如LLM可能不会每次都遵循指令、占用大量提示词空间等)，所以最后官方下场了推出了Function Calling，通过明确函数定义、保证以预定义的JSON格式输出等手段有效解决了手动注入存在的问题。
OpenAI在官方文档中说“GPT-4.1 在有效利用在 OpenAI API 请求中作为参数传递的工具方面接受了更多的训练，使用 API 请求的 tools 字段来传递工具，以获得最佳理解和性能”。
但！
但是来了哈，由于各个AI厂商都有自己独特的Function Calling，你OpenAI的GPT有你自己Function Calling，他Google的Gemin有我自己的Function Caling，我开源模型LLaMA2也有...坏了我LLaMA2没有ㄒoㄒ，所以Function Calling的一些问题也暴露了出来：
1）由于各个厂商的实现方式都不同，导致应用只能在单一生态内运行；
2）并且开发者要为每种模型或工具编写特定的适配代码，随着集成数量增加，维护成本和出错风险成倍上涨；
3）函数调用往往只关注单次请求与响应，而缺乏对多轮对话或复杂任务执行中上下文状态的统一管理。
尽管 Function Calling 解决了工具调用问题，但其局限性催生了更通用的协议——MCP。
MCP（Model Context Protocol模型上下文协议）
MCP和Function Calling很像，本质上还是一个为LLM提供工具的一种机制，但是MCP解决了Function Calling的一些痛点，所以我更倾向把MCP理解为是Function Calling的Pro版。
MCP解决的Function Calling的主要痛点：
1）跨生态兼容：
Anthropic 于 2024 年底开源MCP，任何平台、模型或第三方服务都能遵循这一协议，无缝对接 Claude、GPT、Gemini 等多种模型，彻底摆脱单一生态的限制。
2）即插即用的工具：
每个 MCP 服务都会公开一个 JSON 格式的 manifest，详细列出工具的名称、输入输出等信息。AI 客户端只需读取 manifest，就能自动发现并调用所有可用工具，无需手动编写或维护繁琐的 SDK。
3）内置会话状态管理：
MCP 在协议层面支持“会话 ID”与可选的“上下文对象”机制，能够在多轮对话或复杂任务（如审批流程、数据分析、报告生成）中，持续共享和更新工具状态，开发者无需反复手动拼装和解析历史内容。
下图是Anthropic提供的一个MCP架构图：
MCP 主机（Host）
就是诸如 Claude Desktop、VS Code、Replit 这类终端应用或 AI 平台，它们负责发起对模型和工具的整体调用流程，并负责把结果展现在用户界面中。
MCP 客户端（Client）
它不是一个独立的进程，而是一段内嵌在主机中的 SDK 代码（Python、TypeScript 等），负责和 MCP Server 之间建立并维护通道。
MCP 服务器（Server）
通常我们把它看作“工具服务端”，它本身是一个运行着各种 Tool 的进程或服务。
每个 Tool（比如 file.read、math.sum、slack.send_message）都注册到这个 Server 上，对外以同一个 MCP Server 的身份提供能力。
Reference
https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
Function calling - OpenAI API
MCP 终极指南
(99+ 封私信 / 5 条消息) MCP、function calling 这两者有什么区别？与AI Agent 是什么关系？ - 知乎
Guide to Using the Responses API's MCP Tool | OpenAI Cookbook
Introduction - Model Context Protocol
Agent学习之：MCP和Function Call - 极客产品GeekPM
Model Context Protocol (MCP) in Pharma | IntuitionLabs
Model Context Protocol (MCP) - A Deep Dive - WWT
