【🟡AGI之路】从GUI到API—AI驱动软件自动化的演进之路

🟡 GUI迈向API（MCP协议诞生前）

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`）

🔘 自动驾驶

自动驾驶本质上是通过物理接口实现车辆的自动化操作，通过传感器（如摄像头、雷达）与控制系统（如转向、刹车）的交互，类似于电脑AI代理调用软件API，只不过它是调用"物理API"。自动驾驶的层次与电脑系统类似，但更复杂：

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

与电脑代理不同，自动驾驶需实时处理环境变化（如雨天、路况），这对AI决策提出了更高要求。例如，在恶劣天气下，传感器数据可能失真，AI需动态调整策略。自动驾驶目前多为L2/L3级别（部分自动化），如特斯拉的Autopilot。L4/L5（完全自动化）仍面临技术与法规挑战，需确保安全性和可靠性。

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

用户层：点击"导航"按钮（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总线协议）、电机控制指令	直接读写硬件寄存器（需嵌入式开发，如调整刹车力度）

🔘 Agent的能力

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

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

Plan模块：将任务分解为具体步骤：分析太阳辐射计算的步骤（如地形坡度、日照时间、大气衰减等）。
Tool模块：找到ArcGIS中能实现每一步的工具（如坡度计算、栅格叠加分析），匹配并调用可用工具（"用arcpy.Slope()算坡度，用arcpy.sa.RasterCalculator()叠加"）。

AI生成代码注入Arcgis中的Python控制台：

python 复制代码

# 步骤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的实现（如用RasterCalculator模拟日照）可能牺牲精度。真实太阳辐射需复杂模型（如辐射传输方程），而AI的简化假设（如常数日照）可能不够科学。这提示我们，Agent的组合能力虽强大，但需验证结果合理性。

AI的"接管"能力源于接口，而非AI自身具备控制软件的物理能力。因此，AI生成的是全新代码逻辑，但依赖软件提供的库（如arcpy、Shapes对象）。所以，AI需明确目标软件（如"在ArcGIS Pro中生成缓冲区"），否则可能生成错误代码（如在WPS中生成VBA，在QGIS中调用Arcpy的函数）。

大模型是一个通用文本生成引擎，能根据输入生成自然语言、代码或数据，但无法直接操作软件（如点击按钮、读写文件）。所以：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模拟点击，效率低且易失效。
逆向工程：破解内部函数，法律风险高。

🟡 RPA

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

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

RPA (Robotic Process Automation)，即机器人流程自动化的"企业级宏"，它能跨多个应用和系统执行操作，具有更复杂的条件分支和异常处理，还包含更丰富的集成能力（API、数据库、OCR等）。

在这一演进过程中，"宏"的核心思想一直存在：将人类重复性操作自动化。如果引入AI呢？

把 Function Calling 引入LLM提升决策能力，但仍是预定义工具集。如果使用MCP/Manus/Agent架构 ，则是借助了AI规划能力，实现真正的自主任务分解和执行。

当我们理解了这种演进关系，就能更好地把握新一代AI系统架构的本质：它们不是全新的发明，而是自动化技术沿着更智能、更自主的方向的自然延伸。特别是Manus这样的系统，本质上是"智能宏"，不同之处在于它不需要人工录制和定义流程，而是能够理解自然语言指令，自主规划和执行任务流程。

对Langchain组件与宏的类比也非常准确：

Runnable ：基础构建块，可组合成更复杂的流程，类似于宏中的模块化片段，可以重用和组合
Tool ：最基本的功能单元，单一函数调用（如搜索、计算、API访问），类似于宏中的单个命令
Chain ：多个Tool或其他组件的组合，可以包含条件分支和循环，类似于一个完整的宏
Agent ：决定使用哪个Tool或Chain的智能组件，相当于为宏添加了"大脑"，能够理解需求并选择合适的宏执行

现代AI系统架构实际上是将决策智能(LLM)与执行能力(宏/工具)分离然后重新组合

独立优化：可以分别改进决策智能和执行工具，LLM你就负责更好的规划复杂任务的编排，工具你就发挥本能
模块化：工具可以独立开发和重用，这也是MCP的理念，而不是像OpenAI的FunctionCalling一样只能遵循自家的
可扩展性：可以不断添加新工具而不改变核心架构，你只需要注册到MCPServer里，写上描述就行，MCPServer自然知道什么时候用你

🟡 DeepSeekRearsh

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

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

由单一LLM负责规划和反思，以文本报告为唯一输出形式，没有复杂的任务分解和协调机制，网络搜索API就是唯一的外部工具，比较适合单一主题的研究报告生成

Manus采用更复杂的网状架构，融合了MCP协议，支持多种任务类型和输出形式。

接收用户查询：用户提出可能涉及多领域、多步骤的复杂请求
计划阶段 (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 报告并邮件发送给 [email protected]。"让我们用 Function Calling 的流程完整走一遍。

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

🔘 Cursor与Manus

无论是Cursor还是Manus，其能力的边界都取决于目标软件是否提供了可编程接口。Cursor依赖VS Code的API接口，能够自动生成代码、安装依赖、优化项目结构。Manus通过浏览器、办公软件等的API接口，能够完成复杂的跨软件任务。如果软件未提供API接口，AI只能通过模拟用户操作间接实现任务，比如目标软件未提供API接口，Manus可能需要UI自动化，比如通过模拟鼠标键盘事件间接操作。API接口的存在性决定了AI能否直接调用软件功能，而学习如何调用API是AI实现自动化的核心能力.

🔘 MCP的背景

最本质的问题，我凝练出来就俩：基座大模型LLM自身的能力，直接决定了Agent是不是智能，能不能拆解任务，能不能知道调动什么工具以及怎么配合，我对结果不满意它怎么自动优化，这一点占百分之90%，搞定这个之后，第二点就是如何设计API，让大模型知道什么时调（描述），怎么调（请求与传参）。前者不是我们需要考虑的，大模型自然有厂商训练，所以基本上所有的AI从业者，AI模型设计师，都是在围绕第二步，OpenAI的FunctionCalling算是先行者，它根据自己的GPT模型设计了一套规则，现在的MCP协议则更宏观，是面对整个AI体系生态设计的规则。 MCP协议正是为解决AI生成代码与软件接口适配的核心矛盾而设计的标准化中间层

🔘 MCP与RPC

MCP 的架构基于客户端-服务器模型：

MCP Client：AI 模型或 Agent，发起请求。
MCP Server：工具或服务的适配层，响应请求并执行业务逻辑。

设计思想上，借鉴RPC（远程过程调用），增加了上下文管理和工具发现功能。它的消息格式可能包括：

请求：{"tool": "read_file", "params": {"path": "file.txt"}}
响应：{"result": "file content", "status": "success"}

与RPC进行类比：你想要设计一个智能助手让它帮你完成日常工作：写 Excel 文件、打开浏览器查资料、甚至在 ArcGIS Pro 中生成地图。你希望这个助手能轻松调用各种工具，而不用你每次都手把手教它怎么操作。你脑海中浮现一个疑问：这不就是 RPC（远程过程调用）吗？它们看起来好像是一个模子刻出来的，但仔细一看，又有些不一样。

先从 RPC 说起。你写了一个程序，想让远在另一台服务器上的函数帮你查天气。你定义了一个函数 get_weather("唐山")，通过 RPC 机制，这就像给远方的同事打了个电话："嘿，帮我查下唐山的天气！" RPC 把你的请求打包成数据（可能是 JSON 或二进制），通过网络（比如 TCP）送到服务器，服务器执行后返回结果："今天晴天！" 这个过程简单直接，像调用本地函数一样自然。RPC 的核心魅力在于，它把复杂的网络通信隐藏起来，让你感觉远程服务器就像你电脑里的一个模块。你不需要知道服务器是用 Python 还是 Java 写的，只需约定好函数名和参数就行。这正是 RPC 的"函数式调用"风格：明确、直白，像程序员之间的默契。

现在，切换到 MCP 的场景。你不再是单纯的程序员，而是 AI 的"指挥官"，LLM不会写代码，但它能听懂你的指令："帮我把'Hello'写到 Excel 文件里。" 你启动了 MCP，它帮LLM和工具搭起了桥梁。你对 AI 说："用 MCP 工具'excel_write'，参数是文件路径和数据。" AI 把这句话翻译成一个请求：{"tool": "excel_write", "params": {"file": "data.xlsx", "data": "Hello"}}，然后通过 MCP 发送出去。另一边，MCP Server 收到请求，默默调用 Excel 的 API，把数据写好，再返回："写好了！" 这个过程是不是有点眼熟？对，它和 RPC 的"请求-执行-返回"模式很像。MCP 的请求就像 RPC 的函数调用，tool 是函数名，params 是参数，服务器的执行逻辑也像 RPC 的远程方法实现。*

RPC 和 MCP 的相似只是表象，深入场景后，它们的区别开始显现。假设你的 AI 助手不仅要写 Excel，还要接连完成一系列任务：写完后打开浏览器查看结果，再用 ArcGIS Pro 画张地图。如果用 RPC，你得提前告诉 AI 所有函数名：write_excel()、open_browser()、create_map()，而且每次调用都是独立的，像打三次电话，每次重新说明需求。RPC 擅长这种单次、明确的调用，但它有个局限：它假设你已经知道有哪些函数可以用，而且它不关心上一次调用的结果对下一次有什么影响。换句话说，RPC 是"无记忆"的，就像一个只顾眼前的人，挂了电话就忘了你是谁。MCP 却不一个有记忆，你对 AI 说："先写 Excel，再打开浏览器。" MCP 用 context_id 把这些步骤串起来，第一次写 Excel 时，服务器可能返回：{"result": "写好了", "context_update": {"last_file": "data.xlsx"}}，下一次打开浏览器时，AI 可以直接说："用上次的文件路径打开相关网页。" 这个上下文管理功能是 MCP 比 RPC 更"聪明"的地方，它让 AI 能在多步骤任务中保持连贯主动帮你衔接任务。RPC 要实现这个，得额外写会话管理代码，而 MCP 内置了这种能力，天然适合 AI 的复杂需求。

再往前走一步，你的 AI 助手突然问："我还能干啥？" 在 RPC 世界里，它得靠你提前写死所有函数名，助手只能被动等待指令。但 MCP 提供了一个"菜单"功能。你让 AI 发送 {"tool": "list_tools"}，服务器返回一个工具列表：[{"name": "excel_write", "desc": "写 Excel"}, {"name": "browser_open", "desc": "开浏览器"}]. AI 就像翻开菜单，主动发现自己能做什么。这种动态工具发现机制是 MCP 的另一个亮点，而 RPC 通常是静态的，函数名得预先约定好。

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

最后，站在开发者的角度，RPC 的服务器端是一个"函数库"，你得提前写好所有方法，客户端直接调用。MCP 的服务器更像一个"工具箱"，可以独立运行，AI 通过协议访问。你可以用 Python 写一个 MCP Server，封装 Excel 的操作，AI 只需通过协议"点单"，不用管你是用 win32com 还是其他库。这种解耦让 MCP 更适合 AI 生态，开发者只需维护工具箱，AI 就能即插即用。而 RPC 的客户端和服务器通常更紧密绑定，改动一端可能影响另一端。

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

🔘 MCP的构成（系统架构层

Client（客户端） 负责向MCP Server发送请求，并接收最终结果。
- 不包含任务分解或具体执行逻辑，仅作为用户与MCP生态的交互入口。
- 示例：Claude桌面程序作为Host，通过Client与MCP Server通信。
Planner（规划器） 基于LLM（如Manus使用的Steiner模型）进行任务分解、动态编排、优化调整。
- 规划器是AI的核心能力体现，不属于MCP协议本身，但依赖协议格式进行工具调用。
- 示例：将"生成一个电商网站"分解为"创建数据库→编写前端代码→配置支付接口"。
MCP Server（服务器） 作为Agent的注册中心和调度中心，管理Agent的生命周期（启动、停止、更新等）。
- MCP Server是整个系统的核心枢纽，负责协调Client与Agent之间的交互。
- 示例：多个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：用于实时双向通信[[8]][[10]]。
Server端实现（工具逻辑） 封装具体功能实现，将专业工具能力暴露为MCP接口。

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

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

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

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

lua 复制代码

        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 实现流程

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: 客户端仅包含:
1. 核心应用逻辑
2. MCP Server API调用 Note over Planner: 可以是LLM, 或其他
更复杂的规划器 User->>Planner: "整理北京销售数据，计算增长率，
生成PDF并邮件发送" Note over Planner: 拆解为多个任务和子任务 Planner->>Planner: 创建任务计划:
1. 获取销售数据
2. 计算增长率
3. 生成报告
4. 发送邮件 Planner->>MCPServer: 提交任务1: 获取北京最近一周销售数据 + 可用Agent列表 MCPServer-->>DataAgent: { "action": "get_sales_data",
"parameters": { "city": "北京", "period": "最近一周" } } Note over DataAgent: Data Agent内部
调用销售数据API activate DataAgent DataAgent->>DataAgent: 执行数据获取逻辑 (可能使用Browser-use) deactivate DataAgent DataAgent-->>MCPServer: 返回销售数据 MCPServer-->>CalcAgent: { "action": "calculate_growth_rate",
"parameters": { "current": "...", "last_year": "..." } } Note over CalcAgent: Calc Agent内部
计算增长率 activate CalcAgent CalcAgent->>CalcAgent: 执行计算逻辑 (可能使用Linux Shell) deactivate CalcAgent CalcAgent-->>MCPServer: 返回增长率 MCPServer-->>`PDF Agent`: { "action": "generate_pdf",
"parameters": { "data": "..."} } Note over `PDF Agent`: `PDF Agent`内部
生成PDF报告 activate `PDF Agent` `PDF Agent`->>`PDF Agent`: 执行PDF生成 (可能使用Self-build Tool) deactivate `PDF Agent` `PDF Agent`-->>MCPServer: 返回PDF文件 MCPServer-->>EmailAgent: { "action": "send_email",
"parameters": { "to": "[email protected]", "file": "..."} } Note over EmailAgent: Email Agent内部
发送邮件 activate EmailAgent EmailAgent->>EmailAgent: 执行邮件发送 deactivate EmailAgent EmailAgent-->>MCPServer: 返回发送状态 MCPServer-->>Planner: 返回所有任务结果 Planner->>Client: 返回 Client->>User: "报告已发送"

想象小张同学需要评估某地区的洪水风险，分析历史降雨数据，生成预测模型，并创建可视化地图用于社区宣讲。他使用支持MCP协议的Claude来协助这一专业任务。

用户与MCP主机交互 ：小张同学向Claude（作为MCP host）提出请求："分析Metro河流流域的洪水风险，结合过去5年的降雨数据、地形高程和土地利用情况，生成预测模型和风险分区地图。"大语言模型Claude识别这是一个需要专业GIS工具和多种数据源的复杂分析任务
MCP客户端处理请求 ：MCP clients（client.py）接收并处理Claude的请求，然后客户端将任务分解为数据获取、空间分析、模型构建和地图可视化等子任务，并为每个子任务准备格式化的MCP请求
MCP核心处理与路由 ：中央的MCP核心（图中的USB集线器）作为通信协调中心，它将各子任务分发到适当的服务器，维护整个分析过程的上下文，确保子任务之间的数据流通顺畅
MCP服务器执行专业GIS任务 ： 空间数据MCP服务器 （右侧）连接到本地数据源 ，获取高分辨率DEM（数字高程模型）数据。气象MCP服务器 通过API获取历史降雨记录和气象站数据。GIS分析MCP服务器 执行流域划分、坡度计算和土地覆盖分类。 模型MCP服务器构建洪水预测统计模型
远程服务集成 ：空间数据服务器 连接到Google Earth Engine （替代图中的Google Calendar图标）获取卫星影像数据。 气象服务器 通过专业气象API（替代图中的Gmail图标）获取历史气象数据。 可视化服务器 使用ArcGIS Online 或QGIS Web（替代图中的Slack图标）创建交互式地图
结果整合与返回：各个MCP服务器将分析结果传回MCP核心，MCP核心整合所有数据和分析结果通过MCP客户端将完整信息返回给Claude，最终再由Claude向Carlos展示综合分析结果和可视化地图

收到的最终响应可能是："我已完成Metro河流流域的洪水风险分析。基于过去5年的降雨数据、DEM高程模型和最新的土地利用分类，我生成了一个洪水风险预测模型（R²=0.87）。分析显示北部山区有3处高风险区域，主要是由于近期森林砍伐导致的径流增加。我已创建一个分区风险地图，使用5级风险等级（从极低到极高）进行颜色编码。地图已导出为GeoJSON格式，可直接导入ArcGIS或QGIS进行进一步编辑。另外，我还生成了一份PDF报告，详细说明了分析方法和关键发现，适合向社区居民进行宣讲。"在这个GIS分析场景中，MCP架构使Claude能够无缝协调多个专业GIS工具和数据源，完成一个复杂的空间分析任务。虽然底层涉及多种地理空间分析技术、数据格式转换和专业模型构建，但Carlos只需提出一个自然语言请求，不必关心技术实现细节。可见：MCP的价值在于它为AI系统提供了一个统一的接口来访问专业工具生态系统，使得非GIS专家也能通过AI辅助完成复杂的地理空间分析任务，大大降低了专业技术的应用门槛。

但其实每个工具（如 excel_write、arcgis_map）的具体逻辑还是需要开发者手动编写，因为 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	MCP
核心思想	将工具/函数视为 LLM 的一种特殊"输出"，由 LLM 决定调用哪个工具/函数，以及传递什么参数。	将工具/函数抽象为独立的 Agent，由 MCP Server 负责 Agent 的管理和调度, 由Planner负责任务的分解和描述。
架构	客户端需要实现工具/函数的具体逻辑（当然有些属于OpenAI已经帮你内置了，但本质也是OpenAI的客户端实现的），并通过 API 调用 LLM 服务。	客户端只需包含核心应用逻辑和 MCP Server 的 API 调用，Agent 的具体实现与客户端解耦。
Agent 管理	Agent 的定义和实现通常与客户端代码耦合在一起。	Agent 是独立的实体，可以由不同的开发者或团队维护，并通过 MCP Server 进行注册和管理。
任务调度	由 LLM 决定调用哪个工具/函数。	由 MCP Server 根据任务描述和 Agent 的能力进行调度, Planner负责任务的分解。
灵活性与扩展性	相对较低。添加新的工具/函数需要修改客户端代码，并重新训练 LLM（如果需要）。	较高。可以方便地添加新的 Agent，无需修改客户端代码，也无需重新训练 LLM。
适用场景	适合工具/函数数量较少、逻辑相对简单的场景。	适合工具/函数数量较多、逻辑复杂、需要多个 Agent 协同工作的场景。
技术成熟度	相对成熟，有 OpenAI 等大型 LLM 服务提供商支持。	相对较新，仍在发展中，但 Anthropic 等公司正在积极推动。
灵活性与扩展性	相对较低。添加新工具/函数需修改客户端代码，可能需要重新训练 LLM	较高。可以方便地添加新 Agent，无需修改客户端代码，也无需重新训练 LLM
系统资源使用	受限于预定义的函数接口	可以使用Linux沙盒、浏览器控制等工具，直接访问计算资源
自定义工具	受限于预定义的工具列表	支持Self-build Tools，可以在运行时创建新工具（如生成PDF转换脚本）
状态管理	通常依赖客户端管理状态	使用文件系统保存中间状态，多个Agent之间可以共享数据
反思与迭代	通常更线性，反馈循环较简单	规划器可以根据中间结果调整后续任务
工具关系	工具是客户端的一部分	工具是独立实体，由MCP服务器管理
决策流程	LLM知道所有可用函数，直接决定使用哪个	LLM只需请求特定服务，MCP服务器决定使用哪个工具
扩展性	需更新客户端和可能重新训练LLM	只需在MCP服务器注册新工具
工具维护	客户端负责实现和维护所有工具	工具可由第三方提供和维护
接口标准化	每个客户端可能有不同实现	遵循统一的MCP标准协议