聊几点我对 Anthropic MCP 的看法：

1. 并没有像自媒体鼓吹的那样夸张，还不至于让 AI 行业变天，依然有很长的路要走；

2. 可以简单理解跟大模型已经支持的 Function Calling 是同一个东西，本质是为了让大模型可以调用外挂的服务，对接更多的数据和能力，再作为补充上下文回答用户的问题；

3. 区别点在于：Function Calling 由大模型通过 HTTP 请求第三方的外挂 API，而 MCP 是由大模型通过 RPC 请求第三方的外挂服务；

4. 从接入方式上看，Function Calling 更简单，第三方只需要写一个 API，再在大模型配置对 API 的请求参数即可。MCP 接入起来要复杂一些，第三方需要写个服务，实现协议里定义的 RPC 方法，再在大模型里面配置服务地址和参数，大模型客户端在启动的时候需要做一次服务发现，再连接到配置的 RPC 服务，才能在后续对话过程调用；

5. Function Calling 和 MCP 的核心和难点都在于大模型侧的意图识别，用户随机提问，如何找到匹配的外挂服务，实现 RAG，这是所有大模型面临的通用难题（比如 ChatGPT 有几百万的 GPTs 应用，如何根据用户提问路由到最匹配的那个 GPTs 来回答问题），MCP 协议并不能解决这个问题。Claude 客户端目前的实现方式，是让用户自己写个配置文件，告诉大模型有哪些可以调用的服务，再由 Claude 在对话时自动识别，跟 ChatGPT 之前让用户选择使用哪些 Plugins 的逻辑一致；

6. MCP 的亮点是定义了一套标准且相对完善的协议，对于大模型和应用的生态协同有很大的指导意义。类似由微软提出并在 VS Code 实现的 LSP 协议一样（定义了编辑器如何与第三方语言服务交互，实现代码补全/类型约束/错误提示等功能）。MCP 协议的适用对象主要是大模型/应用客户端和第三方服务，跟 LSP 不同的是，编程语言的数量相对有限，最多几百个语言服务，社区协同下很快就能全部支持，编辑器可以根据文件的后缀快速定位到要调用的语言服务。MCP 适用的第三方服务是海量的，MCP 的发展取决于有多少第三方服务愿意基于这套协议去实现 RPC 服务，最关键的还是大模型/应用客户端对海量 MCP 服务的路由寻址问题（没有固定的后缀，只能靠意图识别或者人工配置）。

Qwen2vl-Flux 这个模型用 Qwen2VL 替换了 FLUX 中的 T5 模型。

让 FLUX 的多模态图像理解和提示词理解变得很强。

- 无文本图像直接基于图像生成图像
- 类似 IPA 将图片和文字结合生成对应风格的图片
- GridDot控制面板，细致的风格提取
- ControlNet 集成，支持 Depth 和 canny

模型下载：https://huggingface.co/Djrango/Qwen2vl-Flux

除了有点斗鸡眼，还是很像我的！

分享一个快速下载 huggingface 巨大模型文件的方法：当下载开始后，在 Chrome 里复制下载链接，然后粘到任意一个你有会员的下载器里（迅雷/夸克/百度云都可以试试）

速度会瞬间感人……