【📛MCP】从GUI到API，AI驱动软件自动化的演进之路之“MCP协议”🟡 GUI迈向API（MCP协议诞生前）

🟡 GUI迈向API

GUI：直观界面，面向人类，封装好每次交互背后的路径。
API：抽象代码，面向机器，提供API接口，供程序调用。

你平时使用的软件（如Excel、ArcGIS Pro）和Windows系统，都是通过图形用户界面与你互动。点击按钮、选择菜单、拖拽元素，这些操作简单直观，GUI其实是对底层功能的“封装”，屏蔽了代码和API的复杂性，让普通用户无需编程也能完成任务而已。明白了这一点，我们就能理解AI如何“接管”软件，可以说：Agent的能力由其可调用的API层级决定。

🔘 API层级

计算机系统的运作本质是一套分层抽象模型，每一层通过API向上层提供服务，同时对下层隐藏复杂性。

层级	核心功能	典型API/接口	Agent可操作权限
硬件层	CPU、内存、磁盘、网络卡等	机器指令（x86汇编）、设备驱动	直接操作硬件需内核权限，通常Agent无法触及
操作系统层	资源管理（进程、文件、调度）	系统调用（如Linux的syscall、Windows API）	高权限Agent可调用（如Python的`os`模块调用文件操作）
运行时环境层	编程语言支持（如JVM、Python解释器）	标准库（如Python的`sys`、`io`模块）	受限于语言运行时权限
应用软件层	具体功能实现（如Excel、ArcGIS、浏览器）	应用API（如Excel VBA、Arcpy）	Agent通过应用API操作软件功能
用户界面层	图形界面（GUI）或命令行界面（CLI）	GUI事件（如点击按钮）、CLI命令	通过模拟用户输入间接操作（如`pyautogui`）

🔘 Agent的能力

显然，Agent只能调用已有的API，无法凭空创造软件本身不存在的功能。

比如Excel没有空间分析功能，当任务超出API组合的能力（如Excel直接生成克里金插值图）将无能为力。但是只是说Agent的功能上限由软件的API定义，记住我这里说的是“上限”，对于绝大多数人而言，咱对一个软件的利用远远达不到上限，此时Agent的能力就体现了出来，它可以最大程度的利用现有的API进行规划组合，充分挖掘该软件的潜力。假设ArcGIS Pro的arcpy没有直接提供“太阳辐射计算”函数Fun_Solaranalysis()，AI可以利用软件提供的多个接口，进行已有API组合，设计任务流，倘若软件支持插件，插件本身也提供API嘛，自然AI可调用插件API。咱们模拟一下就懂了：咱们现在的任务对于AI看来，宏观来说就是两步：

Plan模块：将任务分解为具体步骤：分析太阳辐射计算的步骤（如地形坡度、日照时间、大气衰减等）。
Tool模块：找到ArcGIS中能实现每一步的工具，匹配编排，以达到目的（当然前提是这些工具的组合能解决）

AI生成代码注入Arcgis中的Python控制台：通过组合现有工具（坡度计算、山体阴影、栅格计算器）实现了目标功能。但是需要注意：组合API的实现（如用RasterCalculator模拟日照）可能牺牲精度。真实太阳辐射需复杂模型（如辐射传输方程），而AI的简化假设（如常数日照）可能不够科学。Agent的组合能力虽强大，但需验证结果合理性。

# 步骤1：计算地形坡度
arcpy.Slope_3d("DEM.tif", "slope.tif")
# 步骤2：模拟日照时间
arcpy.Hillshade_3d("DEM.tif", "hillshade.tif", azimuth=180)
# 步骤3：叠加分析（伪代码）
arcpy.RasterCalculator("sun_radiation = hillshade * 0.5 + slope * 0.3")

既然AI需要通过软件提供的可编程接口（如API、脚本语言）间接调用功能。那么接口有哪些类型？

脚本语言：如VBA（Excel）、arcpy库（ArcGIS Pro）、PyQGIS库（QGIS）。
REST API：如Slack、Notion的HTTP接口。
插件系统：如WPS的JavaScript API。

对于无接口软件，如微信、某些游戏，未提供API，AI无法直接集成。或者若接口仅支持基础操作（如WPS的有限JavaScript API），AI无法实现复杂任务。替代方案有两种：

UI自动化：用pyautogui模拟点击，效率低且易失效。
逆向工程：破解内部函数，法律风险高。

目前Agent开始向“具身智能”发展，其实汽车的自动驾驶就是典型代表，本质就是“多模态加持下的Agent”

自动驾驶为例，它本质上是通过物理接口实现车辆的自动化操作，通过传感器（如摄像头、雷达）与控制系统（如转向、刹车）的交互，类似于电脑AI代理调用软件API，只不过它是调用“物理API”。自动驾驶的层次与电脑系统类似，但是自动驾驶需实时处理环境变化（如雨天、路况），这对AI决策提出了更高要求。例如在恶劣天气下，传感器数据可能失真，AI需动态调整策略。自动驾驶目前多为L2/L3级别（部分自动化），如特斯拉的Autopilot。L4/L5（完全自动化）仍面临技术与法规挑战，需确保安全性和可靠性。但更复杂：

感知层：传感器收集数据（如摄像头捕捉图像），类似应用层API。
决策层：AI算法（如深度学习）分析数据，决定动作，类似系统级Agent。
执行层：控制系统执行（如转向、刹车），类似硬件级操作，但涉及物理世界。

假设任务是“导航路径后开启自动驾驶”：

用户层：点击“导航”按钮（GUI事件）。
应用层：调用路径规划SDK生成路线。
中间件：通过Apollo框架协调传感器与规划。
系统层：分配CPU处理实时数据。
硬件层：读取雷达数据，调整方向盘。

层级	核心功能	API/接口示例	Agent操作方式
用户界面层	车载显示屏、语音交互，提供驾驶模式选择	GUI事件（如触摸指令）、语音识别API（如Google Speech）	通过模拟用户输入（如点击“自动驾驶”按钮）控制车辆模式
应用软件层	高精地图、路径规划算法，生成行驶路径	地图API（如Apollo HD Map）、路径规划SDK（如Autoware）	调用算法库生成优化路径（如A*算法）
中间件层	自动驾驶框架，协调感知、规划、控制模块	模块间通信接口（如Apollo Cyber RT的Topic/Service）	通过消息传递（如ROS Topic）协调功能模块
操作系统层	实时操作系统，管理传感器数据处理任务	进程调度、内存管理API（如ROS 2 DDS、QNX POSIX）	调用系统API分配资源（如多线程处理数据）
硬件层	车辆传感器（激光雷达、摄像头）、执行器（电机、刹车）	传感器驱动（如CAN总线协议）、电机控制指令	直接读写硬件寄存器（需嵌入式开发，如调整刹车力度）

🟡 RPA 与宏

宏(Macro) 是预先录制编写的一系列操作，可自动重复执行。简单宏如鼠标宏、键盘宏，通常记录单一应用内的操作序列，简单记录宏没逻辑分支能力。最初的Excel宏是简单的操作记录(XLM宏)，后来引入了VBA作为宏编程语言，"录制宏"功能实际上就是生成一套VBA代码，只不过VBA作为一个完整的编程语言，支持变量、条件、循环、函数等，它写出来的宏自然允许更精细的应用程序控制和更复杂的逻辑，可以说VBA代表了单一应用内宏自动化的高级形态，具有完整的编程能力，但主要局限于Office应用程序环境。

基础宏(记录操作) → VBA(编程宏) → RPA(跨应用宏) → LLM+工具(智能宏)

RPA (Robotic Process Automation)机器人流程自动化，它能跨多个应用和系统执行操作，具有更复杂的条件分支和异常处理，还包含更丰富的集成能力（API、数据库、OCR等）。可以说在这一演进过程中，"宏"的核心思想一直存在：将人类重复性操作自动化。

当我们理解了这种演进关系，就能更好地把握新一代AI系统架构的本质：它们不是全新的发明，而是自动化技术沿着更智能、更自主的方向的自然延伸，可以借助LLM作为大脑，思考什么时候调用什么工具，当然每一个具体的工具都是一套或简单或复杂的workflow，那就是宏。现代AI系统架构实际上是将决策智能(LLM)与执行能力(宏/工具)分离然后重新组合。

🟡 RAG

🔘 RAG的核心

RAG 是一种结合检索和生成的模型架构。核心思想是：在生成回答时，不仅仅依赖语言模型的内部知识或当前上下文，而是通过从外部知识库中动态检索相关信息来增强回答的质量。就是将这些找到的信息（无论是语义相似度匹配的文本，还是结构化查询到的数据）补充进提示词补充送入LLM，让LLM基于这些额外信息生成更准确的回答。所以这个外部知识库可以是任何形式的数据，包括结构化数据和非结构化数据。区别在于处理不同数据时，RAG 采用的检索策略会有所不同。

LLM在整个过程中只负责最后的"合成"工作，再次强调，只负责最后的生成，我为啥这样强调它的重要性，因为太多人对RAG一知半解的反而最容易陷入一个误区，就是随着RAG召回率低，效果不好，会觉得是自己选择的LLM模型不行，觉得换个模型就好了，但其实这不是关键！此前我特意写过一篇文章《【🔴Langchian】——爆肝半个月的Langchian框架开发全景手册》，讲到了召回率低关键几个点并进行了排序：

Embedding Model 词嵌入模型：向量质量决定语义匹配的基石。
Retriever 检索召回器：检索策略和参数直接影响召回结果。
Text Splitter 文本分割器：分割方式影响上下文和向量生成质量。
Vector Store 向量数据库：存储和索引效率影响检索性能。影响效率而不是召回率
Document Loader 文档加载器：如果数据输入有问题，会间接影响性能。

检索到的信息通常会被赋予更高的"隐式权重"，主要因为检索内容通常放在提示词的前部或靠前位置，LLM更容易关注，而且在设计提示词中常包含"根据提供的信息回答"等指令，也会暗示检索信息比模型原有知识更新或更可靠。当然，还要考虑模型有没有自查能力，关于模型的自查能力，这取决于具体的LLM：高级模型会在一定程度上进行事实自查，当发现提供的信息与其固有知识冲突时，可能会指出这种冲突，中小型模型通常缺乏这种自查能力，更倾向于直接采纳提供的上下文信息。But‼️ 模型的规模并不是最关键因素，甚至都算不上啥重要因素，即使是小型模型也能很好地执行"读取上下文并基于此回答"的任务。因为真正影响RAG系统质量的是检索系统的准确性和提示词的设计方式。再次强调本质，LLM 不参与检索，仅负责生成，所以模型能力不影响召回率，而影响生成质量通顺性啦这些东西。 所以对于企业级部署，小型但针对指令优化的模型，配合高质量的检索系统，往往比单纯追求大模型更具成本效益，然而大多数我看到的公司，基本上所谓的本地化部署，就是为了构建一个RAG系统，然后就需要花费几十上百个W部署所谓某模型的满血版...有钱挺好的。

🔘 什么才算RAG？

上传附件到云仓库是否属于 RAG取决于系统在生成回答时是否动态检索外部知识库中的相关信息，也就是说，有没有检索器retriever（因为这个就涉及到词嵌入模型，向量数据库等等，各种策略等，没有这个很显然就只是上下文附加而已）

PaaS与本地化框架：Coze、Dify、CherryStudio、Langchian等等。

用户上传附件（如文档、表格）后，系统对其进行预处理（例如文本提取、向量化）。
预处理后的内容存储到外部知识库（如向量数据库）。
用户提问时，系统通过检索器（Retriever）从知识库中提取与查询最相关的内容。
检索到的内容结合语言模型的生成能力，输出最终回答。

两者均依赖向量数据库（如Milvus、Chroma）和语义检索，差异仅在于抽象层级。

维度	低代码平台（如Coze）	LangChain框架
部署复杂度	即开即用，无需代码	需手动配置6大模块（加载器、检索器等）
扩展性	依赖平台插件生态	支持自定义检索策略（如混合BM25+DPR）
成本	通常按数据量收费	开源免费，但需自建向量数据库

MaaS：如 ChatGPT、Claude 的官网
1. 用户上传附件后，系统直接将其解析为文本。
2. 解析后的文本作为模型的上下文（Prompt）输入。
3. 模型基于此上下文生成回答，无需额外的检索过程。

特殊情况：ChatGPT 的因为有FunctionCalling，好像是有自定义的RAG工具， GPT 是否属于 RAG 需具体分析。如果自定义 GPT 配置了外部知识库并通过检索机制生成回答，则属于 RAG。如果仅将上传内容作为上下文输入，则不属于 RAG。

🔘 Retriever

LLM的是开源的，而且其生成质量依赖检索内容，而非模型规模。组件是开源的：Embedding模型、文本分割器等多为固定模块，优化空间有限。所以Retriever的优化是RAG工程师的核心战场，Retriever虽然称为检索器，但它不是一个实体的嵌入模型，它是一种算法策略组合。检索召回器决定了哪些信息会被送入LLM作为上下文，直接影响回答的准确性和完整性：召回过少缺失关键信息，回答不完整。召回过多噪音太大，分散LLM注意力。召回不相关引入错误信息，导致错误回答。所以当我们说"优化检索召回器"时，实际上是在调整这整套系统中的多个环节，而不仅仅是更换某个单一组件。

图中的第11步就是是检索召回器整体策略执行后得到的最终结果。这一步骤代表的是：经过向量相似度计算，然后应用了选定的检索策略(如TopK等)，考虑了各种参数设置还包含重排序（Reranker）修正后的排序结果，得到系统认为与用户查询最相关的文本块集合，把这些文本块随后会被组织成提示模板，与原始查询一起提供给LLM生成最终答案。图中虽然简单标记为"Related Text Chunks"，但这背后是整个检索召回过程的成果。LangChain 提供 RetrievalQA 这种RAG系统的预置链，内部集成检索器比如（VectorStoreRetriever）和 LLM类和默认流程，简化开发。

🔘 非结构化数据——单一向量

对于非结构化数据（如文档、网页、文章等），RAG 通常使用向量匹配来进行语义检索。适合开放性或模糊的问题

存储：文本数据被向量化（通过嵌入模型，如 BERT），存储在向量数据库中。
检索：根据用户查询的向量表示，计算与知识库中文本片段的相似度，提取最相关的段落。
生成：语言模型基于检索到的文本生成回答。

如果只考虑非结构化策略会有什么致命缺点？那么假设我们有一个 Excel 文件，包含以下结构化数据：

                        地区    天气    企业名称    年份    排放量
                        北京    晴天    企业A      2022    100
                        北京    晴天    企业A      2023    120
                        上海    雨天    企业B      2022    150
                        武汉    雨天    企业B      2023    180

比如“帮我查一下北京晴天下排名前2企业的排放量同比增长了多少”，直接就是将整个用户提问嵌入为一个多维度的单一向量，单一向量，单一向量（比如用 BERT 模型生成一个 768 维向量）。然后用这个向量去检索 Excel 数据中与它语义最相似的行。可能返回“北京晴天企业A 2023年排放量120”之类的数据片段，完全不符合用户的提问，因为难以理解排序企业、计算同比增长，它只能理解这个句子的语义大概和某个嵌入的东西在语义上近似，比如模型可能混淆“利润”与“利润率”，造成向量化失真。这就是向量匹配的内生局限性，因为无论你的提问有多么细节，你选择的嵌入模型多牛逼维度有多高，他就是处于几万维空间，它也只是单一向量，单一向量就只能找到与语义相近的文本块，无法理解需要逻辑和计算的概念。更甭说结构化的数据还涉及字段关联（地区字段与北京的关系、天气字段与晴天的关系）和跨行计算（2023排放量 - 2022排放量），语义向量面对这些涉及到筛选和数学运算无能为力。

🔘 非结构化数据——单一向量过渡到混合检索策略

已知，向量匹配（或称为语义搜索）的根本局限在于它的单一向量的"一元性"，无论查询要求提的多么仔细，最终都被映射到单一向量空间中的一个点，必定丢失结构化数据最大的特点，就是结构化的逻辑关系。 当然硬着头皮RAG结构化数据，那么为了解决单一向量的局限，可以引入混合检索策略，思想是将查询拆分为多个子条件（如“北京”、“晴天”、“排名前2”、“排放量同比增长”），再分别嵌入向量，再结合关键词检索。

多路召回：同时使用稠密向量（语义）、稀疏向量（关键词权重）和传统关键词搜索
查询分解：将复杂查询拆分为多个子查询
多级排序：综合多个检索结果，调整权重

可以先用用语义向量匹配“北京”和“晴天”，找到相关行。然后用关键词检索“排放量”，定位对应列。再尝试组合这些条件。混合检索可以显著提高检索精度，比如找到“北京晴天”相关的所有行，但“排名前2”和“同比增长”需要排序和跨年计算，检索本身无法完成这些操作。可能返回北京晴天的数据子集（如企业A的2022和2023年数据），但仍需额外逻辑处理排序和计算。所以说混合检索适合稍微复杂的语义匹配，但对结构化数据的数学运算和逻辑处理仍无能为力。

🔘 结构化数据下的 RAG

对于结构化数据（如数据库表、CSV 文件等）检索方式一定要基于结构化查询，而不是语义向量匹配。

存储：数据以表格形式存储在关系型数据库或其他结构化系统中。
检索：通过结构化查询语言（如 SQL）或规则过滤，从数据库中提取与用户问题相关的数据。
生成：语言模型将检索到的数据转化为自然语言回答。

目前的 PaaS 在处理 Excel 数据时效果普遍不如 MaaS，无论是Langchian的RAG检索链，还是低代码平台如Coze，百宝箱等，走的都是非结构化RAG流程，将结构化数据作为向量进行嵌入。不管你的检索策略再牛逼，你也是非结构化的RAG。而 MaaS 平台内部通常直接集成 Pandas 等库，直接解析 Excel 文件，比如在 ChatGPT 或 Qwen 中直接上传 Excel 文件，结果更准确，因为它们走的是 LLM + Pandas 的路线。比如“帮我查一下北京晴天下排名前2企业的排放量同比增长了多少”，背后的机制可以分为两个部分：

首先，LLM分析自然语言拆解任务: 因为LLM 通过海量训练数据学会了识别查询中的意图和关键信息，LLM 的作用是将你的自然语言“翻译”成一系列逻辑清晰的数据操作步骤，但这些步骤当然不是代码，而是抽象的指令。
- 筛选条件：从“北京晴天”中提取出“地区 = 北京”和“天气 = 晴天”。
- 排序需求：从“排名前2”中理解需要按某个字段排序并取前两名。
- 计算需求：从“排放量同比增长”中推导出需要计算两年的排放量差异并转换为百分比。

然后，Pandas 执行具体操作: MaaS 平台集成了 Python 环境和 Pandas 库。Pandas 是一个强大的数据处理工具，能直接读取 Excel 文件并将其转化为 DataFrame，保留行列关系、列名和数据类型。LLM 生成的抽象指令会被映射到 Pandas 的具体操作。最终，Pandas 执行这些操作并返回结果，LLM 再将结果组织成自然语言回答你。例如：
- 数据读取：pandas.read_excel('file.xlsx')
- 筛选数据：df[(df['地区'] == '北京') & (df['天气'] == '晴天')]
- 排序和排名：df.sort_values('排放量', ascending=False).head(2)
- 计算同比增长：(df['2023排放量'] - df['2022排放量']) / df['2022排放量'] * 100

Pandas 和 Text2SQL 的相似之处在于两者都用于处理结构化数据（表格形式的数据），并依赖 LLM 将自然语言查询转化为可执行的代码。也都是靠LLM 先理解用户意图，然后生成对应的操作指令（Pandas 代码或 SQL 查询）。从技术上看，Text2SQL 和 Pandas 是并行的两种工具，而不是直接的扩展关系。它们都属于“自然语言到代码”的应用，但目标不同：Pandas 面向本地表格数据，依赖 Python 生态，而且能处理各种数据处理任务（清洗、计算、绘图等），比如GPT能根据你的数据画出图，这就是结合了Pandas和绘图库。Text2SQL 面向数据库，依赖 SQL 语言。但是从概念上看，Text2SQL 可以看作是类似思想的延伸：都是通过 LLM 将自然语言转化为结构化数据的操作指令，只不过 Text2SQL 的“执行者”从 Pandas 变成了数据库引擎。未来肯定是RAG与Text2SQL的协同，比如百度智能云已推出Text2SQL+RAG联合方案。

🔘 RAG评估

维度	核心指标	环保局场景案例	优化技术
检索质量	召回率Recall@k 噪声敏感度实体召回率	查询“企业VOCs排放标准”需覆盖90%合规文件，关键条款（如“活性炭吸附技术”）覆盖率85%	混合检索（关键词+向量）动态调整top_k(k=???) 重排序Rerank
生成质量	忠实度幻觉检测完整性	生成回答需100%基于检索内容，完整覆盖“处罚条款+检测方法+执法流程”	RAG-Fusion 后处理过滤（拦截矛盾内容）结构化输出模板
系统性能	延迟（<500ms） Token消耗吞吐量	污染事件溯源需3秒内返回结果，单次查询成本<$0.01 ]	模型量化高频查询缓存分布式向量数据库（如Milvus）
业务适配	领域鲁棒性多模态支持证据链溯源	支持PDF/图片解析（如环保政策表格），答案追溯至原始文件编号和日期	多模态解析（OCR+表格提取）领域术语库动态更新机制

混合检索：结合关键词（BM25）和向量（BERT）检索，解决环保政策中“技术名称”与“技术描述”的语义鸿沟。
RAG-Fusion：通过多文档交叉验证生成回答，确保“处罚条款”与“检测方法”的逻辑一致性。
多模态解析：对PDF中的表格（如排放限值）和现场照片（如污染源）进行联合分析。
动态更新机制：实时同步最新政策（如2024年上海分布式光伏网络规范）。

🟡 DeepSearcher

以后的 RAG 发展方向很可能是 DeepSearcher（Agentic RAG） 与 结构化查询 的结合。这种结合将使 RAG 系统更加智能和灵活，能够根据查询的性质自动选择最合适的检索方式（SQL 查询、向量匹配或混合）

传统RAG的LLM仅作为“生成工具”，被动接收检索结果，缺乏对检索策略的控制，其流程为：

检索阶段：依赖外部算法（如BM25、向量检索）从知识库中提取信息，LLM不参与此过程
生成阶段（LLM参与）：将检索到的信息与用户查询结合，通过LLM生成最终回答。

传统RAG默认从固定知识库检索，若问题超出预构建索引范围（如实时市场动态），则生成内容与现实脱节，且对非知识库问题（如口语化表达）处理能力很差。DeepResearch将LLM的参与扩展到全流程，所以这是Agent，包括问题解析、检索策略制定和动态推理：

问题解析阶段：利用LLM对用户查询进行分解，生成子问题并规划检索路径。
检索阶段：LLM动态调整检索策略（如决定是否需要二次检索或切换数据源）等。
生成阶段：整合多源信息并生成结构化报告保留推理过程。

传统RAG本质上是AI生成流程中的一个关键环节而已，作用是通过外部知识库增强生成内容的准确性和时效性以减少幻觉，所以一般作为独立组件嵌入问答系统、知识库增强等场景当中。它本身不是一个智能体，只是一个组件。而Deep Research则通过LLM的自主推理能力，将检索增强从“信息补充”升级为“认知增强”。例如在金融分析场景中，Deep Research可自动发现数据缺口并触发二次检索，而传统RAG仅能输出基于初始查询的结果。

下图中的反思模块很重要，每次用户提问后，LLM自己反思，是不是还需要外界知识？然后再去走一遍搜索流程，这种不断“追问”“反思”的能力，才是Agentic RAG类（DeepSearcher）相比传统RAG的最大改进。

Deep Research 是一个专注于文本报告生成的架构，其实也是采用较为简单的线性处理流程。

接收用户查询 用户提出查询需求（例如研究主题或问题）
计划阶段 (Planning) 规划器由LLM负责，分析用户查询，然后按模板输出报告结构，
研究阶段 (Researching)：搜索查询、反思、网络搜索API、收集和整理搜索结果：
合成阶段：为每个报告部分（引言、章节1、章节2、结论）生成内容最终按照预定结构呈现完整内容

传统RAG已死：传统RAG的优势在于一次检索的低成本。但其对需求的响应还停留在非常基础语义理解-检索的阶段；但现实中，我们大部分的需求表达背后，都是有隐含逻辑的，并不能被一步检索到位（比如，如何在一年赚一个亿），必须通过推理-反思-迭代-优化来对其进行拆解与反馈，而以Deep Searcher为代表的Agentic RAG 技术方向，将是无可置疑的大势所趋

可以说，Deep Research代表了"专家级报告生成的上限"，而Manus通过多智能体架构实现了"通用任务执行"的突破。二者的差异本质上是线性流程与网状协作的代际差异，是AI从"信息整合者"向"自主行动者"的范式转变。

接收用户查询：用户提出可能涉及多领域、多步骤的复杂请求
计划阶段 (Planning) 高级规划器如Steiner、任务分解后继续子任务分解、再检查任务分配的合理性
执行阶段 (Execution) MCP服务器负责各种Agent调度，比如搜索Agent使用Compute use功能，编码Agent生成代码，部署Agent将生成的内容部署到云服务或本地环境，还有其它各个Agent。
工具使用阶段：编排工具组合，Compute use控制浏览器进行网络交互，Linux Shell Executo执行Linux命令行操作，Document process tools处理各种文档格式，Self-build Tools动态创建完成特定任务的工具
文件系统交互 用于Agent间数据交换和存储。Todo列表跟踪待完成任务，中间文件存储处理过程中的临时数据
结果合并阶段 整合各Agent执行结果生成多样化的输出形式，包括但不限于网页文档代码图像各种

🟡 Function Calling

🔘 桥梁

Function Calling 是大型语言模型（LLM）与外部工具交互的一种机制。允许 LLM 在处理用户请求时，识别出需要调用什么外部工具，并生成一个结构化的指令（通常是JSON）。告诉客户端1、应该调用哪个工具 以及 2、需要传入什么对应参数。最终，客户端（通常是应用程序）负责执行这些工具并整合结果，提供给用户。当然客户端得预先提供可用工具的描述（如 JSON Schema），LLM 再根据描述判断是否调用。

LLM 不直接执行工具，而是“指挥”客户端。
工具可以是本地的（如 Python 函数）或云端的（如 REST API）。
它是开发者通过 API 使用的功能， ChatGPT 网页端是没有的。

所以，Function Calling 的本质是一座桥梁，就是“人脑”与“躯干”的神经链接，它连接了 LLM 的语言理解能力与外部工具的执行能力。为什么需要这座桥梁？因为LLM的本质是统计语言模型，其能力局限于符号操作（如文本生成、逻辑推理），你说能算个数学题，能写个代码，那是因为数学题和代码这种也是语言。但无法直接操作本地资源，不能真正的“行动”。LLM可以生成“调用ArcGIS接口生成北京市人口热力图”的指令，但无法直接操作ArcGIS真的做出来。但是它只要能知道怎么做，就足够了，就像大脑一样，虽然它啥也不能干只能想，但是它知道身体哪个部位干（工具），怎么干（参数）。

🔘 流程

用户端发起请求 ：通过客户端（官方Web端、本地应用程序等）输入自然语言请求。

客户端会将输入连同预定义的工具列表一并发送给 LLM 服务。LangChain封装了底层细节，包括工具定义的传递和执行。需要定义工具，框架会处理与LLM之间的交互逻辑。
LLM 服务处理请求 判断是否需要调用工具。不需要就直接返回文本回答。需要就生成结构化的工具调用指令
客户端执行工具 客户端接收指令，负责调用对应的工具（本地函数或云端 API），然后获取工具执行结果。
结果整合与反馈 客户端将工具结果发回 LLM，生成自然语言回答，或直接将结果展示给用户。

LLM只负责生成"做什么"和"用什么参数"的结构化指令，而客户端完全自由决定"如何实际执行"这个指令：

Web API → 使用HTTP请求库（如requests、axios、fetch）发送GET/POST请求
数据库操作 → 使用数据库连接和查询（如SQL查询、MongoDB操作）
本地函数 → 直接调用应用内的函数或方法
系统命令 → 执行操作系统命令或脚本
硬件控制 → 发送信号给物联网设备或硬件接口

这种设计使得Function Calling极其通用，能够适应几乎任何应用场景，因为它不对"如何执行"做任何限制或假设。开发者可以根据自己的应用需求和技术栈，选择最合适的执行方式。

智能办公助手场景是一个复杂的多步骤任务：“帮我整理最近一周北京地区的销售数据，对比去年同期增长率，生成 PDF 报告并邮件发送给 sales@company.com。”让我们用 Function Calling 的流程完整走一遍。

sequenceDiagram
    participant User as 用户
    participant Client as 客户端<br>(包含工具实现)
    participant OpenAI as LLM服务(OpenAI)
    
    Note over Client: 客户端内包含:<br>1. 核心应用逻辑<br>2. 工具函数实现<br>3. OpenAI API调用
    
    User->>Client: "整理北京销售数据，计算增长率，<br>生成PDF并邮件发送"
    Client->>OpenAI: 发送请求+工具列表定义
    OpenAI-->>Client: { "tool": "get_sales_data",<br>"parameters": { "city": "北京", "period": "最近一周" } }
    
    Note over Client: 内部调用销售数据API
    activate Client
    Client->>Client: 执行get_sales_data工具函数
    deactivate Client
    
    Client->>OpenAI: 发送数据+请求下一步
    OpenAI-->>Client: { "tool": "calculate_growth_rate",<br>"parameters": { "current": "...", "last_year": "..." } }
    
    Note over Client: 内部计算增长率
    activate Client
    Client->>Client: 执行calculate_growth_rate工具函数
    deactivate Client
    
    Client->>OpenAI: 发送结果+请求下一步
    OpenAI-->>Client: { "tool": "generate_pdf",<br>"parameters": { "data": "..." } }
    
    Note over Client: 内部生成PDF
    activate Client
    Client->>Client: 执行generate_pdf工具函数
    deactivate Client
    
    Client->>OpenAI: 发送文件+请求下一步
    OpenAI-->>Client: { "tool": "send_email",<br>"parameters": { "to": "sales@company.com", "file": "..." } }
    
    Note over Client: 内部发送邮件
    activate Client
    Client->>Client: 执行send_email工具函数
    deactivate Client
    
    Client->>User: "报告已发送"

在OpenAI的生态系统中，工具调用机制通过Function Calling实现了LLM与外部功能的无缝连接。无论是内置工具（如网页搜索、DALL-E图像生成）、第三方插件，还是用户自定义的GPTs，底层均依赖统一的JSON Schema定义和指令生成逻辑。然而，用户体验被高度抽象化：网页端用户无需关心工具定义或调用细节，系统自动处理这些过程；而开发者则可通过插件市场或API实现自定义工具，但需自行托管工具逻辑并遵循OpenAI的规范。

🔘 对比 LangChain Agent

Function Calling、LangChain Agent 和 MCP 协议都是 LLM 与外部工具交互的机制，但它们的设计目标、实现方式和适用场景不同。Function Calling 依赖 OpenAI API，格式固定。LangChain Agent 支持多种 LLM 和自定义逻辑。使用 BaseTool 定义工具，灵活性高。支持链式调用（LCEL）、记忆（Memory）等功能。不限于 OpenAI，可适配开源模型。而 MCP（Model-Controlled Protocol）是一个通用协议框架，强调服务发现、权限控制和复杂工作流管理，Function Calling 可视为其一种具体实现。

维度	Function Calling	LangChain Agent	MCP 协议
设计目标	简单工具调用	灵活的代理式工具调用	复杂工作流管理
实现方式	LLM 生成 JSON，客户端执行	Agent 自主规划，框架支持	分布式服务编排
工具定义	JSON Schema	`BaseTool` 类	服务注册（抽象接口）
复杂度	线性，需多次 LLM 调用	单次规划，多步执行	自动编排，无需 LLM 干预
安全性	客户端管理密钥	依赖开发者实现	mTLS、OAuth 等内置支持
异常处理	客户端手动处理	有限支持（需自定义）	内置断路器、事务补偿
适用场景	快速原型、简单任务	中等复杂任务、开源模型	企业级系统、敏感数据

🟡 MCP

MCP本身就是一个中间件，就是解耦，所以“智能”本质上由LLM本身的解析与规划能力+ 工具本身的能力决定

🔘 MCP的背景

作为标准化的 AI 工具调用协议，它解决了各家 AI 模型 function calling 实现不一致的问题（因为FunctionCalling的本质是对现有的模型进行加训SFT）。

🔘 MCP与RPC

MCP 可以看作“AI 版的 RPC”，它继承了 RPC 的函数调用风格，但加上了LLM作为大脑，动态发现机制、上下文管理和灵活传输，专为 AI 的量身定制。

先从 RPC 说起。你写了一个程序，想让远在另一台服务器上的函数帮你查天气。你定义了一个函数 get_weather("唐山")，通过 RPC 机制，这就像给远方的同事打了个电话：“嘿，帮我查下唐山的天气！” RPC 把你的请求打包成数据（可能是 JSON 或二进制），通过网络（比如 TCP）送到服务器，服务器执行后返回结果：“今天晴天！” 这个过程简单直接，像调用本地函数一样自然。RPC 的核心魅力在于，它把复杂的网络通信隐藏起来，让你感觉远程服务器就像你电脑里的一个模块，你也别管这个工具咋实现的，啥语言，啥逻辑，你只需约定好函数名和参数发送请求就行。这正是 RPC 的“函数式调用”风格：明确、直白。再切换到 MCP 的场景。假设你的 AI 助手不仅要写 Excel，还要接连完成一系列任务：写完后打开浏览器查看结果，再用 ArcGIS Pro 画张地图。如果用 RPC，你得提前告诉 AI 所有函数名：write_excel()、open_browser()、create_map()，而且每次调用都是独立的，像打三次电话，每次重新说明需求。RPC 擅长这种单次、明确的调用，但它有个局限：它假设你已经知道有哪些函数可以用，而且它不关心上一次调用的结果对下一次有什么影响。RPC 是“无记忆”的，就像一个只顾眼前的人，挂了电话就忘了你是谁。MCP 因为有LLM作为从大脑，你对 AI 说：“先写 Excel，再打开浏览器。” MCP 用 context_id 把这些步骤串起来，第一次写 Excel 时，服务器可能返回：{"result": "写好了", "context_update": {"last_file": "data.xlsx"}}，下一次打开浏览器时，AI 可以直接说：“用上次的文件路径打开相关网页。” 这个上下文管理功能是 MCP 比 RPC 更“聪明”的地方，它让 AI 能在多步骤任务中保持连贯主动帮你衔接任务。RPC 要实现这个，得额外写会话管理代码，而 MCP 内置了这种能力，天然适合 AI 的复杂需求。而且更何况LLM还能根据工具提供的自我描述，进行编排。

说到通信方式，RPC 和 MCP 也有自己的“邮路”。RPC 喜欢用 TCP 或 HTTP/2，像快递公司用高速公路，确保数据高效送达。而 MCP 更灵活，它可以用 STDIO（标准输入输出）在本地跑，就像你直接喊隔壁房间的同事干活，也可以用 HTTP SSE（服务器推送事件）走网络，支持实时更新。这让 MCP 既适合本地工具（如 Claude Desktop 调用本地 Excel），也为未来远程调用留了余地。RPC 更偏向网络化场景，MCP 则像个“本地+网络”的双栖选手。

🔘 MCP的构成（系统架构层

Client（客户端） 负责向MCP Server发送请求，并接收最终结果。
- 不包含任务分解或具体执行逻辑，仅作为用户与MCP生态的交互入口。
- 示例：Claude桌面程序作为Host，通过Client与MCP Server通信。
Planner（规划器） 基于LLM（如Manus使用的Steiner模型）进行任务分解、动态编排、优化调整。
- 规划器是AI的核心能力体现，不属于MCP协议本身，但依赖协议格式进行工具调用。
- 示例：将“生成一个电商网站”分解为“创建数据库→编写前端代码→配置支付接口”。
MCP Server（服务器） 是整个系统的核心枢纽，负责协调Client与Agent之间的交互。管理Agent的生命周期（启动、停止、更新等）。自己创建一个 MCP 服务器超级无敌简单。大家参考这篇文章即可动手写一个MCPsever用于提供天气查询服务。在这里补充一些重要的地方
- 首先确保已安装Node.js v16.0.0+，这样咱可以在服务器端运行Js的代码。MCP的SDK和其他依赖库（如 node-fetch）都依赖于Node.js。需要安装 npm install @modelcontextprotocol/sdk node-fetch zod ，其中@modelcontextprotocol/sdk提供了MCP协议的核心功能，node-fetch 和 zod 分别负责HTTP请求和参数校验，是实现天气查询工具的关键。而，
- McpServer 实例的核心功能是通过 tool() 方法注册工具函数，比如咱有一个普通函数query_weather，使用 server.tool() 方法就能注册成一个名为 query_weather 的MCP工具。同理，扩展其他工具只需在 server.tool() 中注册新的工具即可。。connect() 是启动服务器，绑定传输协议（如 stdio 或 SSE）。
- 使用 StdioServerTransport 创建一个标准输入输出传输协议实例,适合本地调试。如果需要远程访问，可以切换为其他传输协议（如 SSE），然后调用 server.connect() 方法，将服务器与传输协议绑定。
- 在测试之前，你需要确保客户端（如 Cline 或 Claude Desktop）已经正确连接到本地运行的 MCP Server。只有在客户端与服务器成功建立连接后，才能发送请求并测试功能。因为咱刚才属于是自己写了个服务端，开启了监听。客户端需要通过配置文件或命令行参数指定服务器的位置，并与服务器建立连接。如何连接到本地服务器？首先当前是咱的服务器在运行，也就是上面的第一步，然后我们可以使用 Cline，打开 Cline 的配置文件添加或修改以下内容，确保指向你的 MCP Server
- 记住路径要改成自己的：package.json里的main文件，这个是启动文件，改成自己的主文件名
- 记住路径要改成自己的：Cline MCP配置里，把咱写的服务器的地址，改成自己的。

Agent（工具/服务） 独立执行具体任务，由不同开发者维护，通过MCP Server注册并声明自己的能力。
- 内部可能使用的技术包括：
  - Browser-use：模拟用户操作浏览器，获取网页数据。
  - Linux Shell：执行系统命令，进行数据分析或文件操作。
  - Self-build Tool：动态创建工具（如PDF转换脚本）。
  - 特定领域API：调用专业库（如GIS分析中的Arcpy）。
File System（文件系统） 提供Agent之间的数据共享机制，存储中间结果和最终产物。
- 文件系统是系统资源的一部分，通过协议访问，比如存储GIS分析的中间数据，供后续任务使用。

🔘 MCP协议的组成（通信规则层）

MCP协议 是“规则书”，规定了AI与工具如何通过标准化格式（如JSON）进行通信MCP系统架构 是“施工图”，明确了各组件（Client、Server、Agent等）如何分工协作，实现协议规则[[9]]。

请求/响应格式（消息结构） 定义标准化的数据交换格式，确保AI与工具之间的通信一致性。
工具注册与发现（服务描述） 让AI知道有哪些工具可用及其使用方法，支持动态发现。
上下文管理（状态保持） 支持多轮交互和长任务执行，维护会话状态。
传输层支持（通信通道） 定义底层数据传输方式，支持不同环境下的通信需求。
- STDIO：用于本地命令行工具调用。
- HTTP/SSE：用于网络服务通信。
- WebSocket：用于实时双向通信。
Server端实现（工具逻辑） 封装具体功能实现，将专业工具能力暴露为MCP接口。

🔘 MCP协议通信方式（传输层支持）

MCP 属于高层协议，它的设计目标和功能集中在应用层，就拿网络通信场景来说， MCP 关注 AI 如何与工具通信（请求格式、工具发现、上下文），并不涉及数据包的分片、重传等传输细节，这些交给 TCP 或 STDIO。其次，它没有重复造轮子，比如HTTP SSE 是基于 HTTP协议的扩展。既然 MCP 不直接处理数据包的传输，而是依赖底层的传输机制，那么来看看它支持的两种方式：

HTTP SSE（服务器推送事件）：基于 HTTP 的实时通信，HTTP 本身是应用层协议，跑在 TCP（传输层）之上。
STDIO（标准输入输出）：本地程序间的管道通信，替代网络传输，功能上类似传输层，但不属于 TCP/IP 栈。

当你本机运行 MCP，通信完全绕过了 TCP/IP 协议栈。这时不涉及网络层级，因为数据不通过网卡或网络设备。STDIO 是操作系统提供的一个本地通信机制，程序间通过标准输入输出流传递数据。

        STDIO本地通信                HTTP SSE网络通信
    ---------------------       ---------------------
    | 应用层: MCP       |       | 应用层: MCP  HTTP SSE |
    ---------------------       ---------------------
    | 本地传输: STDIO   |       | 传输层: TCP       |
    ---------------------       ---------------------
    | 操作系统          |       | 网络层: IP        |
    ---------------------      ---------------------
                               | 数据链路层         |
                               | 物理层            |
                                ---------------------

当 MCP 需要跨机器通信（比如 AI 调用远程工具），它会使用 HTTP SSE（服务器推送事件）。这时，完整的 TCP/IP 协议栈就派上用场：

HTTP：总是依赖 TCP/IP，纯网络协议，即使本地测试也走回环地址（127.0.0.1），离不开传输层。
gRPC：RPC 的现代版本，默认用 HTTP/2 和 TCP，网络导向，本地通信也模拟网络栈。
MCP：支持 STDIO，纯本地时不走网络，网络时用 HTTP SSE，兼顾两种模式。

MCP 协议的通信机制主要基于 SSE (Server-Sent Events) 而不是 WebSocket。SSE 是一种服务器推送技术，允许服务器通过 HTTP 连接向客户端推送数据。这种机制适合 MCP 的使用场景，因为：SSE 提供了单向的服务器推送能力，非常适合工具执行状态的实时更新，所以MCP 架构中，客户端通过常规 HTTP 请求发送命令和查询，而服务器则可以通过 SSE 连接实时推送工具执行状态、进度更新和结果。这种组合使 MCP 能够提供及时的反馈，同时保持相对简单的实现。（WebSocket 虽然提供全双工通信，但对于大多数 MCP 用例来说可能是过度设计，SSE 的单向推送模型更符合 AI 工具交互的实际需求。）

🔘 MCP 实现流程

sequenceDiagram
    participant User as 用户
    participant Planner as 规划器(Steiner)
    participant MCPServer as MCP Server
    participant DataAgent as 数据Agent
    participant CalcAgent as 计算Agent
    participant PDF Agent as PDF Agent
    participant EmailAgent as 邮件Agent

    Note over Client: 客户端仅包含:<br>1. 核心应用逻辑<br>2. MCP Server API调用
     Note over Planner: 可以是LLM, 或其他<br>更复杂的规划器

    User->>Planner: "整理北京销售数据，计算增长率，<br>生成PDF并邮件发送"

    Note over Planner: 拆解为多个任务和子任务
    Planner->>Planner: 创建任务计划:<br>1. 获取销售数据<br>2. 计算增长率<br>3. 生成报告<br>4. 发送邮件
    
    Planner->>MCPServer: 提交任务1: 获取北京最近一周销售数据 + 可用Agent列表
    MCPServer-->>DataAgent: { "action": "get_sales_data",<br>"parameters": { "city": "北京", "period": "最近一周" } }

    Note over DataAgent: Data Agent内部<br>调用销售数据API
    activate DataAgent
    DataAgent->>DataAgent: 执行数据获取逻辑 (可能使用Browser-use)
    deactivate DataAgent
    DataAgent-->>MCPServer: 返回销售数据

    MCPServer-->>CalcAgent: { "action": "calculate_growth_rate",<br>"parameters": { "current": "...", "last_year": "..." } }

     Note over CalcAgent: Calc Agent内部<br>计算增长率
    activate CalcAgent
    CalcAgent->>CalcAgent: 执行计算逻辑 (可能使用Linux Shell)
    deactivate CalcAgent
    CalcAgent-->>MCPServer: 返回增长率

    MCPServer-->>`PDF Agent`: { "action": "generate_pdf",<br>"parameters": { "data": "..."} }
    Note over `PDF Agent`: `PDF Agent`内部<br>生成PDF报告

    activate `PDF Agent`
    `PDF Agent`->>`PDF Agent`: 执行PDF生成 (可能使用Self-build Tool)
    deactivate `PDF Agent`
    `PDF Agent`-->>MCPServer: 返回PDF文件

    MCPServer-->>EmailAgent: { "action": "send_email",<br>"parameters": { "to": "sales@company.com", "file": "..."} }
    Note over EmailAgent: Email Agent内部<br>发送邮件

    activate EmailAgent
    EmailAgent->>EmailAgent: 执行邮件发送
    deactivate EmailAgent
    EmailAgent-->>MCPServer: 返回发送状态

    MCPServer-->>Planner: 返回所有任务结果
    Planner->>Client: 返回
    Client->>User: "报告已发送"

MCP服务端并非简单将协议附加到用户提问，而是通过以下步骤实现结构化交互：

动态注入结构化上下文：传统方法可能将工具信息以自然语言拼接到prompt，而MCP使用机器可读的JSON Schema，确保LLM结构化解析，将工具列表、参数格式、资源状态等信息通过专用协议字段（如system消息或MCP协议头）注入LLM输入，与用户提问分离
协议驱动的工具调用： LLM生成符合MCP协议的调用指令（如{"tool_call": "weather_api", "parameters": {"city": "北京"}}），服务端解析后转发至对应工具，关键是还支持实时数据更新（如通过SSE推送数据库状态变化）和多轮交互，扩展LLM的上下文感知能力。

当然每个工具的具体逻辑还是需要开发者手动编写，因为 MCP 只定义了通信协议（请求格式、响应结构）。无论是用传统 LangChain 还是 MCP，底层调用（如 win32com 操作 Excel）都离不开人工实现。关键在于在于：MCP 把工具实现从客户端移到 Server 端后，开发者不需要自己重复写所有工具。别人可以按照 MCP 协议开发并部署 Server，把工具逻辑封装好，普通用户直接通过协议调用这些现成的功能。比如：一个开发者写了个 MCP Server，支持 excel_write，开源到社区。你作为普通用户，只需连接到这个 Server，发送 {"tool": "excel_write", "params": {"file": "data.xlsx", "data": "Hello"}}，就能用它写 Excel。同样，别人可能已经写好了 browser_open 或 arcgis_map，你直接用就行。

🔘 MCP与FunctionCalling

内生性的工具调用：Function Calling：模型内生性能力（SFT路径）

Function Calling的实现依赖于对模型的监督微调（SFT），本质上是让模型学习如何将自然语言意图映射到结构化的工具调用参数（如JSON Schema）。这种能力需要模型：

理解工具语义：识别用户意图是否需要调用工具（例如“订机票”触发航班查询API）。
生成结构化输出：严格遵循预定义的参数格式（如日期字段必须符合YYYY-MM-DD）。
参数逻辑校验：隐含学习参数间的逻辑关系（如“出发日期早于返回日期”）。

通过微调，模型权重被修改，工具调用能力成为其“本能”。这类似于医疗领域SFT让模型掌握专业术语推理能力，即使脱离RAG也能处理简单问题。因此，一个支持Function Calling的模型（如GPT-4）与其原始版本在参数分布上存在显著差异，因为这玩意儿属于内生性的改变，自然模型对工具的理解深度更高，参数生成更精准，但是很显然泛化性受限，工具更新需重新微调，跨模型兼容性差（不同厂商的Function Calling实现可能不互通）。

外援性的工具调用：MCP：外部驱动型工具调用（类比RAG路径）

MCP协议不依赖模型微调，而是通过动态上下文注入实现工具调用：

工具描述标准化：将工具的名称、参数格式、示例用法等以文本形式写入Prompt。
模型即时学习：模型在推理时根据上下文临时“学习”如何生成符合要求的参数（类似于Few-shot Learning）。
客户端执行：由外部系统（如MCP中间件）解析模型的文本输出并实际调用API。

MCP将工具调用视为一种“上下文任务”，模型仅需具备基础的语言理解和格式生成能力。工具知识不内化到模型权重中，而是通过Prompt动态管理，类似RAG对外部知识的依赖。支持任意模型（只需满足基础文本生成能力），工具更新无需重新训练。不过性能依赖Prompt设计，工具描述的清晰度和示例质量直接影响效果，复杂工具调用可能出错率较高。

🔘 从模型层面对比FC

FC完全是基于模型层面的拓展，就是通过SFT加训，将工具调用逻辑植入模型参数的过程。

例如 OpenAI 的 GPT-4 需要重新训练才能支持 DALL·E 图像生成，这种训练会改变模型权重而非简单添加规则。比如 GPT4 可以调动我内部服务器上的工具，但同样的问题，Gemini、Qwen 等模型就无法识别，因为每个模型的都需要单独训练才能根据某个问题，输出工具和特定格式的参数。哪怕大语言模型的能力都很接近，甚至咱说Gemini2.0反而更先进，但是这不是先进不先进的事情，哪怕有一点点格式问题，这次请求也发不出去，所以它就是单一的，虽说penAI 采用的是增量训练，仅更新与工具调用相关的参数，而非完全重训，但新增工具仍需重新验证模型稳定性，导致开发周期长。所以，Function Calling 是模型能力的延伸，相当于给 GPT-4 增加了"工具使用说明书"，但不同厂商的说明书互不兼容。

而MCP下的工具调用，完全不需要对大模型做任何微调啊，因为大模型只需要知道有哪些工具，怎么编排这些工具的组合就行，这些能力大模型还是要有的，之前微调调的是让大模型同时输出工具名，还得知道参数格式才能知道怎么用，太麻烦了，现在只让大模型负责分析个大概怎么回事儿，有哪些工具，咱大体编排下处理顺序就行，工具的调用，残水的格式啥的，你都别管了，MCPCLient就是干这个的，它干完会把工具参数都发给你（这很关键啊，这就是之前没有MCP时，完完全全靠大模型本身的能力推理完的！所以工具一多你想想多麻烦吧），好了，截止到这一步，下面的过程MCP和FunctionCalling就基本一样了，FunctionCalling下，这个消息发到服务器处理，MCP下也是发到MCPServer处理，就一样啦。所以可见，客户端就是中间件，就是翻译本，只要有个客户端，能提供可用服务列表，并遵循协议接口，还通过动态工具发现机制配新工具，不存在像Function Calling那样因参数格式差异导致请求失败。当然，能否想到用哪些工具取决于基座模型智商——————————MCP本身没有智能，自然也不提升模型本身的意图理解React能力，它仅解决现成工具调用的标准化问题。也就是说同样一个任务，不同的人智商不同，面对同样的工具场景，想的办法不一样，而工欲善其事必先利其器，工具质量也决定了任务的效果，MCP只是说，不同的人都能直接使用这些工具，仅此而已。

还需要补充一点

MCPClient 不参与逻辑编排，其功能仅限于，无法理解工具调用顺序或组合。

指令转发：将 LLM 生成的工具调用请求传递给对应工具
结果回传：将工具执行结果（如浏览器返回的商品信息）反馈给 LLM
动态注册：支持新工具接入，但工具的使用仍需 LLM 主动调用

当任务涉及多工具协作（如“搜索商品→下单→支付”），LLM 是唯一决策者，流程如下：

任务分解：LLM 将用户需求拆解为子任务（如先搜索后支付）
逐级调用：LLM 生成第一个工具调用指令，MCPClient 执行后返回结果。
动态调整：LLM 根据结果生成下一步指令
异常处理：若某一步骤失败（如支付超时），LLM 需重新规划（如更换支付工具）

比如在MCP中，工具调用顺序通常由业务规则预定义（如必须先登录再支付），这就是我说的工具本身的能力。模型只需输出工具列表（如["login", "payment"]），Client根据规则确定顺序，任务效果取决于模型编排能力和工具质量，大模型只有知道你的工具设定，才能知道咋利用具体的单一工具啊，才能知道工具间咋协作从而React啊。

因为真实场景中，工具组合可能动态变化（如用户临时修改地址），预设流程无法覆盖所有情况，而且若 MCPClient 自主编排工具（如自动调用支付接口），可能引发不可控风险（如误扣款），当然这里不是说MCP就是个傻子，它只是不理解工具与工具之间的关系，但是对于一个工具，这个工具也不一定是很简单的逻辑，它自己就是一个很系统的工作流，比如访问数据库，先鉴权，生成SQL，然后获得数据后处理等等，这一套逻辑你必须要写的很清楚后才能注册成MCPServer,具体到每个工具，MCPClient 仅机械执行。

LLM作为大脑进行调度，我们能控制每一步咱们做不做，我说了那么多可能很抽象，你自己打开Cursor试一把就明白了，你只要不点完全接管，每一步调动的MCP Server，都是需要你的验证的。而你若是给了MCPCLient本身LLM的能力，还是挺可怕的， MCPClient 的无推理能力设计恰好符合这一原则——工具调用的权力始终由人类或 LLM 主导。MCPClient 的无推理能力设计恰好符合这一原则——工具调用的权力始终由人类或 LLM 主导。每一步的决策（调用哪个工具、参数、顺序）均由 LLM 主导，MCPClient 仅机械执行，协作的智能性完全依赖 LLM 的 React 式分步决策，而 MCP 协议的价值在于标准化工具调用接口，但这已经足够用了。

维度	LLM	MCPClient	协同关系
意图理解	多轮推理与动态决策	无	模型生成指令：LLM 通过多轮对话理解用户需求，生成明确的工具调用指令
工具调用	无	安全传递指令与结果	客户端执行指令：MCPClient 将 LLM 生成的指令传递至工具，并返回结果，确保接口标准化
容错处理	生成应急预案	无	模型触发重试/切换：LLM 根据错误反馈生成新指令（如“切换支付通道”），MCPClient 仅执行
安全控制	无	认证/鉴权/审计	协议层强制约束：MCP 协议内置安全机制（如 TLS 加密），LLM 通过 prompt 约束敏感操作[[6]]。

🔘 从通信方式对比FC

Function Calling 本质上就是传统的 API 调用，没有什么特别之处。它基本上遵循了几十年来软件开发中使用的同样模式：1. 发送请求、2. 等待处理、3. 接收响应。唯一的"创新"是 AI 模型能够理解什么时候需要调用这些函数，并能够正确地构造参数而已，但这一切都是发生在API调用之前，单从通信和技术实现角度看，它确实就是普通的 API 调用，API 调用部分仍然使用的是几十年来软件开发中一直在用的传统请求-响应模式。所以在通信机制上，MCP 和 Function Calling 是截然不同的技术。

Function Calling：

采用简单的 HTTP 请求-响应模式
完全同步操作 — 模型发出请求，暂停生成，等待完整结果返回后继续
每次交互都是独立的，不保持状态连接
通信严格单向：客户端等待模型请求，执行操作，返回结果

MCP (Model Control Protocol) ：

使用 SSE (Server-Sent Events) 创建持久连接
支持异步操作模式 — 工具可以在执行过程中持续发送数据
维护持久会话，允许状态追踪和上下文保留
双向通信流：客户端发送请求，服务器可主动推送更新而不需等待请求

MCP 的技术优势

实时反馈机制：工具可以在完成之前发送部分结果和进度更新，使模型能够更早开始处理信息
长时间运行的操作支持：适合需要较长时间处理的任务，如大型文件分析、复杂计算或数据爬取
动态交互能力：工具可以请求额外信息或提供选项，模型可以响应这些中间交互，而不必等待操作完全完成
标准化协议：提供统一的接口规范，使工具开发者只需开发一次，即可在所有支持 MCP 的平台上运行
资源效率：对于需要多次交互的复杂任务，避免了重复建立连接的开销

🔘 协议的无关性

协议无关性

MCP协议基于JSON-RPC 2.0构建，其核心交互逻辑通过标准化消息格式实现，与应用程序类型无关。无论是桌面应用、网页工具还是嵌入式系统，只要客户端能够发送HTTP请求或者本地的studio请求，并且能够处理JSON数据，就可以作为MCP客户端连接到MCP服务器。咱们以QGIS这个软件为例，选择QGIS作为Host开发Client，本质是增强既有专业工具；构建GIS Server则是创建通用能力供给节点

QGIS作为Host的本质 ：QGIS在此场景下是业务逻辑承载主体，需承担GIS数据解析、空间分析、地图渲染等核心能力。其MCP Client的功能是扩展工具调用边界（如连接AI模型或外部API），而非替代QGIS的GIS处理能力。

GIS Server作为服务端的本质 ：GIS Server其通过MCP协议将传统GIS服务转化为LLM可理解的工具集合，例如将"地图切片生成"封装为generate_map_tiles工具。因此GIS Server与具体Host无关，可被QGIS、浏览器、智能助手等多种Host调用。这种设计使GIS能力成为可插拔模块，例如同一地图服务可同时支持Claude分析需求和浏览器可视化需求。

维度	QGIS作为客户端（Client）	QGIS作为服务器（Server）
功能发起方	主动调用MCP协议，请求外部服务（如AI模型）	被动响应客户端请求，提供QGIS原生功能（如地图渲染）
数据流向	从MCP Server获取数据或指令，结合QGIS处理	将QGIS内部数据或功能封装后输出给其他客户端
典型应用场景	- 空间数据分析与AI模型集成（如洪水预测） - 本地GIS工具链扩展	- Web GIS服务（如地图切片分发） - 多用户协同编辑

【📛MCP】从GUI到API，AI驱动软件自动化的演进之路之“MCP协议”