哈喽，我是老刘
老刘是个客户端开发者，目前主要是用Flutter进行开发，从Flutter 1.0开始到现在已经6年多了。
那为啥最近我对MCP和AI这么感兴趣的呢？
一方面是因为作为一个在客户端领域实战多年的程序员，我觉得客户端开发的终局一定和AI是强绑定的。
另一方面就个人而言，我对新技术一直有很大的好奇心。
本文就来聊聊目前比较火热的MCP到底是怎么来的，以及它和Agent等其它AI相关技术的关系。

一、LLM、Function call和MCP

LLM是啥： 大语言模型本质上是一个具有一定思考能力的对话机器。简单来说就是你提问他回答。
但是他的回答只能限制在训练LLM的语料库范围内，超出范围的内容答不出来或者瞎编。

那么如何让LLM回答实时性高的或者没有训练过的问题呢？

第一代方案：

人工搜索相关的文章后通过对话发给LLM，LLM整理后回答你的问题。
缺点是费时费力，所以有了第二代方案

第二代方案：

将第一代的人工搜索并喂给LLM通过浏览器插件或者其它软件工具自动化完成。
这套方案的缺点是不够智能，比如我问ai：“明天应该穿什么？”
这时插件会直接搜索明天穿什么而不是明天的天气怎么样。
其实我们真正的问题是：明天什么天气，并且根据天气判断穿什么衣服。
所以有了第三代方案Function call

第三代方案（Function call）：

要解决上面的问题，就需要让LLM去理解用户的问题，并做出判断：去搜索明天的天气。
如何让LLM能调用外部的工具搜索天气呢？
ChatGPT在2023年6月份的时候提出来了Function call协议。
它的工作方式如下：

1、​​请求阶段​​
用户提问 + 函数定义列表 → 发送至ChatGPT API。

{"functions": [{"name": "get_weather","description": "获取城市天气","parameters": {"type": "object","properties": {"location": {"type": "string"}}}}]
}

​​2、模型决策​​
模型判断需调用函数 → 返回函数名及参数字符串，如：

{"name": "get_weather","arguments": "{\"location\": \"Beijing\"}"
}

3、​​函数执行​​
AI客户端（例如CherryStudio、Cursor）解析JSON，调用本地或外部API（如天气接口），获取结果。
4、​​结果整合​​
将函数返回数据再次发送给模型 → 生成最终自然语言回复（如“今日晴，25°C”）。

Function call最重要的作用是让LLM能根据和用户的对话自主分析需要调用哪些接口和工具。
但是Function call的缺点也很明显：
从前面的工作方式中可以看出来，Function call并没有明确规定向LLM发送函数列表以及LLM调用某个方法时的具体字段及协议标准。
这就会造成不同LLM接受函数列表以及调用时的字段可能各不相同。
比如我要开发一个天气查询服务，就需要针对不同的LLM开发不同的通知和解析过程。
而作为一个AI客户端，比如Cursor或者CherryStudio，也需要针对不同的LLM以及不同的服务提供者做专门的适配。
为了解决上面这个问题，将Function call的通知和调用接口统一成标准协议自然而然的产生了，那就是MCP。

第四代方案（MCP）：

MCP通过定义一个统一的协议层解决了上述碎片化问题：
1、​​统一交互协议​​

• ​​标准化函数描述格式​​：所有服务提供者遵循同一套MCP Schema定义函数（名称、参数、权限）
• ​​调用指令规范化​​：LLM返回的请求强制符合MCP JSON Schema，消除解析歧义

示例：MCP函数调用指令格式

{"action": "execute","tool": "weather","params": {"location": "Beijing"}
}

2、双向解耦设计​​

角色	受益点
服务提供者	一次开发即支持所有MCP兼容LLM（无需适配各平台）
AI客户端	通用解析引擎处理任意MCP服务，新服务接入零成本

3、MCP的工作流程
下面来看MCP的完整工作流程：

其实本质是是对Function call的标准化
在启动客户端后，会进行初始化操作，将目前客户端已经配置好的MCP服务列表发送给LLM。
在具体的问答阶段，LLM会自主判断需要调用哪些外部工具，然后将调用的参数发送给Host（比如Cursor）。
Host收到调用的Json后会去调用MCP Server的对应接口，然后将返回的结果再发送给LLM。
这个过程可能会循环多次，直到LLM认为已经获取足够的信息，最终LLM将最后结果返回给用户。

二、 MCP、工作流和Agent

Agent
先来说Agent，如果LLM是一个具备语义理解与推理能力的对话机器，那么Agent就是基于LLM的能力能够独立完成任务拆解、自主决策并执行相关动作的一个智能体。
它不再是只能和你对话，而是能完成“感知-规划-执行”的闭环。
简单来说就是Agent先读懂你的要求，然后自己规划一个执行步骤，最后能调用相关的外部工具完成执行动作。

工作流
那么工作流在这中间起到什么作用呢？
首先我们要知道LLM的语义理解与推理能力和人类的逻辑推理是不一样的，LLM的推理是基于概率和模式匹配的。
直观的结果就是一方面它有时候会一本正经的胡说八道，另一方面它拆解的执行步骤可能和我们预期的不太一致。
比如有可能你把任务换个说法，Agent拆解出来的步骤就不一样了。
那么能否把一些明确的固定的工作流程或者好的实践变成一个模板告诉Agent，让Agent每次碰到同类的事务就按照这个固定步骤去执行呢？
比如“客户订单处理”的流程就固定为：接收→库存检查→发货→通知
工作流就是这种标准化的操作模板，通过这些预设逻辑可以降低Agent决策复杂度，提升执行可靠性。

MCP
有了强大的LLM，以及优秀的工作流，Agent就可以像一个真正的人类一样，把事情安排好，甚至做的比人类更好。
现在只剩下最后一件事，就是让Agent能操作外部工具。这就是MCP的作用了。
有了Function call，LLM就已经可以调用外部工具获取信息或者执行动作。
但是Function call本身没有统一的标准，不利于推广，因此MCP为各种不同的LLM和服务之间建立了统一的通信标准协议。
Agent或者工作流的任何一个步骤都可以通过MCP完成外部世界的信息获取或者对外部世界的操作。

LLM、Agent、工作流和MCP的对比

组件	角色类比	依赖关系	核心价值
LLM	大脑	Agent的推理基础	语义理解与决策生成
Agent	指挥官	驱动工作流，调度MCP	任务拆解与动态决策
工作流	战术手册	固化Agent的最佳实践	提升执行效率与可复现性
MCP	万能工具包	为Agent和工作流提供武器库	打破数据孤岛，实现工具即插即用

Coze

看到很多人问Coze和MCP以及和工作流的关系，这里简单说一下我的理解。
Coze是一个帮助开发者搭建Agent的平台。
你可以在里面创建自己的智能体Agent，为这个智能体指定特定的工作流。
给这个智能体配置一些基于MCP的外部工具。
最终将这个智能体打包成App、网站、小程序对话机器人等队外的样式并发布出去。

总结

以上是老刘对“MCP是什么？”、“MCP怎么来的？”、“MCP是如何工作的？”这些问题的理解。
作为一个客户端、Flutter开发者，我觉得在这个AI蓬勃发展的时代，客户端的未来一定是和AI强绑定的。
而MCP作为AI时代的API标准，也是每个客户端程序员都应该掌握的技能。
好了，如果看到这里的同学对客户端、Flutter开发或者MCP感兴趣，欢迎联系老刘，我们互相学习。
点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》