MCP实现了我在1年+前的想法

在前不久Claude发布了“Computer Use”狂吹了一波进入，我是万万没想到Claude猝不及防发布了一个MCP，当然这个应该快20天之前的事情了，这段时间因为入手了华为Mate70还有Mac mini M4，再加上我的CLaude账号被封，所以没有第一时间体验MCP，当然这段时间我也重新换了个号，折腾了下...

MCP是什么?

没了解的大家可以直接去MCP官网看看

https://modelcontextprotocol.io/introduction

第一次看官方介绍估计你可能也有点莫名其妙的搞了个啥子“协议”，所以我让ChatGPT给我介绍了下：

这个基本就是翻译了下官方的那个介绍，于是我让它通俗点：

其实我看到这个还是有点“莫名其妙”，实际体验一把后，其实就是Claude就是实现了一个ChatGPT的GPTs，也就是一套Agent开发调用的框架，当然MCP这个是开源的，在这之前Claude一直是没有推出官方类似于GPTs这种agent的平台服务的，跟大家之前熟悉的langchain、dify等，从最终的实现的效果来看其实是一样的，当然你在开发角度去理解肯定存在一些理念或者说侧重点不一样...

MCP实现了我在1年+前的想法

Agent这个方向我觉得是大模型生态中最开始卷的一个方向，而且也是最被看好的一个方向，这个是大模型能大规模实际应用的必然。在1年+前我看到了第一个安全领域里的应用，之前我在朋友圈及ppt里有提到过 “AI安全助手” ：

https://github.com/opensec-cn/opensec-cn.github.io/issues/2

 在当时还是非常不错的尝试的，非常有开创性的，我记得当时还没有GPTs

我当时看到这个项目就联系了作者wolf，他当时实现的是B/S模式，这个其实跟GPTs的方式一样他把对应的插件（Call Function/Tool）放在他的服务器上跑，这种模式有着天然的缺陷，而且存在各种安全隐患，我当时还测试发现了好几个安全问题，比如浏览器调用的插件可以直接访问服务器本地文件这种，其实这也是Agent应用场景下很常见的漏洞模型，当然还有一些就是隐私的顾虑，还有就是扩展性问题，于是我建议他应该出一个客户端版本，插件可以放在本地使用的文件操作、命令操作、网络操作都是在用户本地环境中，这种可以扩展的场景会非常多～ 

大概1-2个月后wolf就上线了客户端版本，可惜他使用了Docker，也就是把一个一个插件放在容器中跑，其实这个还是局限安全场景下，另外插件也没有实现进一步的类似于“工作流/链”的调用，当时我比较期待的还有一个就是客户端与服务端分离的设计，也就是我可以把这种agent框架跑在任意的环境下（包括服务器、移动设备等），然后通过插件平台分发对应的插件，这样可以扩展的场景就不仅仅局限在“纯安全”应用场景下了 ...

MCP这个设计很接近当时我跟wolf提到的那些设计了，不过在客户端与服务端分离的这个问题上可能还没有很好的实现实际例子，看官方的介绍有Server-Sent Events (SSE) 

https://modelcontextprotocol.io/docs/concepts/transports#transports

 这种方式是不是可以实现，就看后面的各种应用场景优化了，当然你也可以直接通过本机写个MCP server去操作（比如ssh）服务器的曲线路子实现这个目的，也是可以的。

MCP的核心

我们要解决大模型应用的问题，核心就在于处理数据与大模型“沟通”的问题，在这个角度上去理解MCP官方的定义介绍可能就非常好理解了，所以在本地运行环境可能更接近用户数据源，所以GPTs这种在局限在官方的运行的环境下，接近用户数据的也就是通过API的方式调用了，当然Agent的还有一个就是数据源处理后的动作执行判断，这个执行动作也是在GPTs或者Docker这种环境里很多场景下还是非常受限制的。

所以Claude把MCP定义为一种协议，是非常能体现出他们的核心理解。

MCP的应用

在MCP发布的时候，发布了多个官方的开发的Model Context Protocol servers 

https://github.com/modelcontextprotocol/servers

 当然也吸引了不少开发者的响应，在上面github页面里可以看到很多社区的MCP server的Third-Party项目，设置已经出现了“应用市场”：

https://mcp.so/ 

到目前为止已经看到了343个MCP Servers了，里面还是有很多很有意思的项目

当然这个MCP也不局限在官方的那几个Claude客户端的调用，也可以通过开发第三方客户端调用，比如：

https://github.com/chrishayuk/mcp-cli

 这个项目，就实现了：

还有Gui的项目，比如：

https://github.com/daodao97/chatmcp

 目前实现了“OpenAI LLM Model”调用

不过在我的实际测试mcp-cli项目时发现，我使用本地Ollama的的调用效果跟Claude客户端是没有办法比的，核心可能在于大模型本身的能力，还有第三方开发调用及对应MCP Server涉及到的“提示词”工程还是有很大的关系，所以如果想要进行私有化的落地还是得针对性根据模型进行优化～

MCP Server开发

在这段时间里其实我也折腾了下MCP Server的开发，官方提供了Python SDK 、TypeScript SDK 相比之我比较熟悉Python点，当然其实我Python也是非常有限的，不过在大模型时代，已经实现了开发自由了很多时候交给大模型开发就行了！是的，这个时候就轮到之前给大家吹嘘安利过无数次的Cursor上场了，因为MCP这个是个全新的玩意，在使用Cursor的时候，还是非常被动的，如果你不说明清楚，很可能就串台到啥“工控”啥的上面去了，所以对于这些比较新的概念，你得先让大模型学习下对应的知识，还好Cursor等都已经考虑到这种文档类的东西了，所以直接在Cursor 对话框里 @https://modelcontextprotocol.io/introduction 让他学习下是MCP当然，这个官方的文档其实写的比较简陋的，测试几次感觉直接写效果不太行，于是我想着能不能让他先学习下官方给出的来源代码：

https://github.com/modelcontextprotocol/servers

直接git clone下来后，用Cursor打开src这个目录项目，然后让他学习下time这个MCP server的代码，然后他就会写了，直接在Composer生成你想要的项目就行了，比如直接生成一个计算md5hash的 MCP server直接一次性生成好好了，可惜当时的Cursor Chat记录被我删除了，没办法给你们代码生成的图，直接看下Claude客户端调用的效果图吧

在这里我想要吐槽下的就是MacOS下的Python开发环境的配置环境变量的配置真是一言难尽，尤其是对我这种开发萌新选手来说，简直是噩梦！而且我还结合了大模型给的建议，好几次大模型都懵逼了！比如我当时在测试claude客户端配置调用具体的MCP server时，用uv可以，但是用python -m 调用是否不行，折腾了好久才发现Claude.app可能是硬编码python了

sudo ln -s $(pyenv which python) /usr/local/bin/python

尝试这个ln才搞定，当然其实在配置文件里写python的完整路径也是可以的。所以在这里建议如果你是跟我一样是开发小白，在可以选开发语言或者环境的时候，尽量别选python，那都是坑！

其实你调试通了后，开发就很简单了Cursor就直接帮你搞定了，比如我开发个ZoomEye-MCP-Server、还有我们创宇智脑GAC的Gac--MCP-Server，你就只需要告诉Cursor对应的api调用文档或者Curl包给他就行了，效果大体如下：

这里有个细节点，我提示词是ZoomEye搜索，然后Claude客户端自动关联了到了ZoomEye MCP Server的search_host 及 Gac MCP Server的ip_analysls的两个工具的Calling

需要注意的是在API调用的时候如果数据量大，建议在API输出后在MCP-Server进行处理后提交给LLM，要不然可能会处理不过来！

我也在使用上面提到的mcp-cli测试了下Ollama的效果使用的模型为llama3.1 测试的效果肯定是不如Claude客户端的：

这个是Tool Call search_host 触发ZoomEye API请求后的数据，提交给大模型进行推理，大体的整体效果也需要再通过提示词工程优化。

后面我追踪调试了下可能需要做进一步提示词的优化去理解返回及Call Tool的调用，因为我开发环境还是i9的iMac，所以我想着是不是可以调用我在最新的Mac mini M4上的大模型api，测试了Ollama及LM Studio 代码我就让cursor帮我改，不过最后测试发现在Call Tool环节一种都不能成功，目前估计还是跟提示词的理解有关系～

Agent 1.0/2.0

在开头我提到的那篇文章里关于“AI Agent 进入2.0时代”的文章里，实际上在后续的一些测试中发现还有一些问题，顺带在这里一起交代一下：

关于智谱的AutoGLM

智谱的AutoGLM 实际上还是在Agent 1.0的传统模式，基于事先“剧本”定义的模式，跟Claude computer-use这种“所见所得（推理）”的模式还是有本质上的差别的，在11月29日看到智谱发布会上介绍更加肯定了，而且当时他们介绍他们的所谓的“Agent 有 Emergent Ability” 也就是“涌现能力”，结果一看例子，还是提示词已经把操作流程“剧本”写进去了...

非常有天朝特色的“小聪明”！当然目前这个也是主流方法，尤其是在手机端的AI布局竞争中，大家基本都是基于这种方式的调用，我其实一直都比较关注手机上的融合，因为国内iphone16限制使用的问题，所以入手了华为Mate70 Pro我核心也是为了手机端的大模型体验，整体感觉还是不错的，尤其是在调用大模型的方式上，鸿蒙next的方式非常多，可扩展的场景也非常多，可以看看我视频号上发的那些测试视频，不过这几天OpenAI挤牙膏发布会宣布iphone Siri深度融合了ChatGPT看一些测试视频效果来看确实要比之前很简单粗暴的融合要好很多，相比之下国内的手机上的调用最终还是大模型的推理能力上，目前这块还是OpenAI最强，尤其是这2天又发布了告你高级视频对话功能，还是非常惊艳的！（测试效果视频都可以看看我的视频号），其实这个视频功能跟Claude Computer Use是类似的“所见所得（推理）”的，之前就有人利用Claude Computer Use的做了个一个工地摄像头获取工地画面进行工地安全隐患的应用。

关于Agent 2.0安全问题

在前面我做了一个关于“”，但是没有聊怎么防御的问题，实际上我感觉是确实是不太好防的，而且我觉得可能是影响广泛应用的"拦路虎"，因为改变了“输入”场景，攻击者可以通过“篡改”、“植入”的方式把“提示词”注入到具体的场景里，从而改变影响大模型的最终决策。在做“Claude Computer Use 提示词注入攻击演示”时候我一直在思考一个问题怎么识别出是不是大模型访问的问题，随后就看到了在Claude的黑客马拉松的比赛中，有人做了一个怎么防御“避免被 Claude Computer Use 破解验证码”的问题，因为在Claude Computer Use发布的时候已经有很多人就尝试过用来自动化破解验证码了（我在之前讲大模型安全应用的时候就提到了大模型来识别验证码的问题），还是非常有创意的，如果没有看过大家可以去看看：

https://weibo.com/5648162302/5098006686208067?comefrom=longpicweibo&pic_share_from=long_top

至于防御问题直接引用我朋友圈里发的内容：

Agent下一步进化的形态

我觉得在Agent这个问题上，最终落地的方案可能是经典的Agent 1.0的套路+Agent 2.0的套路结合，因为Agent 1.0的剧本套路，很显然是高效、安全的方案，但是缺点是场景（剧本）事先定义了，非常局限，不太符合AGI的追求，所以Agent2.0的所见及所得才是真正的“Emergent Ability”，用于还没有剧本覆盖的场景通用方案，缺点是速度比较慢、推理成本高、还有就是可能引入新的安全风险等

最后提一下 Google的 notebooklm 还是预测的那样，可以说毫无进展，看起来Google是真心看不起这种“小而美”的应用了，怀念Gmail/Gtalk/Goolge代码托管那个时代的Google，不过在今天早上看到有人发推特说终于有更新了：

当然对于我来说这个更新等于没更新！我期待的其他语言的支持，始终没有看到！

从MCP发布来看，OpenAI 与 Claude仍然还在继续着他们“向左向右”的故事～～个人感觉在应用方向上Claude比OpenAI更加坚定，而OpenAI传递的是我全都要！