即刻App年轻人的同好社区
下载
置顶
7 02
实现一个 mcp client 要解决的几个关键问题
1. 给出一个可视化页面，把所有可用的 mcp servers 列出来，可以查看用途，可以搜索
2. 用户安装某个 mcp server，先在用户机器帮他运行这个 mcp server，运行成功再把这个 mcp server 写入到 mcp client 的配置文件
3. 用户提问，从 mcp client config 读取所有已安装的 mcp servers，并行请求进程通信，拿到所有支持的 resources / prompts / tools
4. 带上所有资源的描述信息 + 用户 query，大模型返回需要调用的 mcp server 和对应的参数
5. 并行与本地的 mcp servers 进程通信，拿到响应结果
6. 拿 mcp servers 结果 + 用户 query 做最终的摘要回答
安装 mcp server 需要用户机器有 node 或 python 环境，需要在安装 mcp client 的时候帮用户把环境依赖装好。
感觉这套方案很适合拿来做一个 spotlight 应用，作为个人 PC 的一个超级入口。
1. 给出一个可视化页面，把所有可用的 mcp servers 列出来，可以查看用途，可以搜索
2. 用户安装某个 mcp server，先在用户机器帮他运行这个 mcp server，运行成功再把这个 mcp server 写入到 mcp client 的配置文件
3. 用户提问，从 mcp client config 读取所有已安装的 mcp servers，并行请求进程通信，拿到所有支持的 resources / prompts / tools
4. 带上所有资源的描述信息 + 用户 query，大模型返回需要调用的 mcp server 和对应的参数
5. 并行与本地的 mcp servers 进程通信，拿到响应结果
6. 拿 mcp servers 结果 + 用户 query 做最终的摘要回答
安装 mcp server 需要用户机器有 node 或 python 环境，需要在安装 mcp client 的时候帮用户把环境依赖装好。
感觉这套方案很适合拿来做一个 spotlight 应用，作为个人 PC 的一个超级入口。
17 37
MCP Server 的实现流程，官方文档已经写的很详细了：
1. 先通过 prompts / resources / tools 的描述信息，定义服务的能力；
2. 再通过 server.setRequestHandler 定义接到客户端请求后，执行怎样的逻辑，响应怎样的数据；
3. 最后把 server 连接到 transport，启动服务在本地监听客户端的 RPC 请求；
MCP 客户端接入流程：
0. 客户端提供一个配置页面，让用户提前把需要用到的 MCP Servers 填到配置里面；
1. 客户端在启动的时候，连接到 transport，通过 client.getServerCapabilities() 获取所有已配置的 MCP Servers 提供的能力，包括 prompts / resources / tools 等；
2. 用户在客户端输入问题，客户端把用户提问 + MCP Servers 的能力描述发送给大模型，做意图识别，大模型返回应该调用哪些服务，应该传哪些参数；
3. 客户端带上 MCP Server 名称和对应的参数，发起一次 RPC 请求，获得 MCP Server 响应的数据；
4. 客户端带上用户提问 + MCP Server 响应的数据，请求大模型回答，可以理解为一次 RAG（Rpc-call-Augmented Generation ）；
从整个流程看来，MCP 跟 Function Calling 的逻辑基本一致，差异点在于 Function Calling 是 API 调用，MCP 是 JSON-RPC 请求。
MCP 的能力描述和功能逻辑统一封装在 Server 端，而 FC 的能力描述配置在客户端，功能逻辑在 API，相对比较割裂，不容易管理。
MCP Server 更容易做一些通用型操作，比如读取本地文件，读取业务数据库，而 FC API 一般要跟具体的业务绑定，不够灵活。
MCP Server 官方仓库有十几个例子，很值得参考，开发者可以提交自己的 server，先实现一下业务无关的通用 server，比如连接 notion 做个人笔记分析。影响力起来了可以做很多事，参考 WebPilot 插件在 ChatGPT Plugin 的地位。
MCP Client 目前只有 Claude 自己的桌面客户端有比较好的支持，对于第三方 ChatBot 应用是个机会，可以选择早点接入，积累先发优势，MCP Servers 应该很快会起量。
1. 先通过 prompts / resources / tools 的描述信息，定义服务的能力；
2. 再通过 server.setRequestHandler 定义接到客户端请求后，执行怎样的逻辑，响应怎样的数据；
3. 最后把 server 连接到 transport，启动服务在本地监听客户端的 RPC 请求；
MCP 客户端接入流程：
0. 客户端提供一个配置页面，让用户提前把需要用到的 MCP Servers 填到配置里面；
1. 客户端在启动的时候，连接到 transport，通过 client.getServerCapabilities() 获取所有已配置的 MCP Servers 提供的能力，包括 prompts / resources / tools 等；
2. 用户在客户端输入问题，客户端把用户提问 + MCP Servers 的能力描述发送给大模型，做意图识别，大模型返回应该调用哪些服务，应该传哪些参数；
3. 客户端带上 MCP Server 名称和对应的参数，发起一次 RPC 请求，获得 MCP Server 响应的数据；
4. 客户端带上用户提问 + MCP Server 响应的数据，请求大模型回答，可以理解为一次 RAG（Rpc-call-Augmented Generation ）；
从整个流程看来，MCP 跟 Function Calling 的逻辑基本一致，差异点在于 Function Calling 是 API 调用，MCP 是 JSON-RPC 请求。
MCP 的能力描述和功能逻辑统一封装在 Server 端，而 FC 的能力描述配置在客户端，功能逻辑在 API，相对比较割裂，不容易管理。
MCP Server 更容易做一些通用型操作，比如读取本地文件，读取业务数据库，而 FC API 一般要跟具体的业务绑定，不够灵活。
MCP Server 官方仓库有十几个例子，很值得参考，开发者可以提交自己的 server，先实现一下业务无关的通用 server，比如连接 notion 做个人笔记分析。影响力起来了可以做很多事，参考 WebPilot 插件在 ChatGPT Plugin 的地位。
MCP Client 目前只有 Claude 自己的桌面客户端有比较好的支持，对于第三方 ChatBot 应用是个机会，可以选择早点接入，积累先发优势，MCP Servers 应该很快会起量。
29 79
聊几点我对 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 服务的路由寻址问题（没有固定的后缀，只能靠意图识别或者人工配置）。
7. OpenAI 最初开放的 API 协议已经成了一个约定俗成的标准，后来的大模型在开放自家 API 时都会选择兼容 OpenAI 的 API，主要原因有两个：一是 OpenAI 的 API 开放的早，很多应用接入了，兼容它对第三方接入友好；二是 OpenAI 的 API 实现的确实很规范，照着模范生抄作业何乐不为。MCP 会不会也跟 OpenAI 的 API 协议一样，成为行业内的新标准，这个问题取决于先有鸡还是先有蛋：如果有足够多的第三方服务基于这套协议开放了自己的服务，其他大模型/应用客户端应该会跟进；如果主流的大模型/应用客户端都支持了这套协议，那么作为一个第三方，也肯定愿意按这套协议开放自己的服务（比起为 GPTs / Coze / Dify 分别写一个 API 给智能体调用，MCP 服务只需要写一次，可以在任意支持 MCP 的客户端调用）。
8. MCP 目前不支持 Remote Server，不能在网页版调用，只能在 Claude 桌面版使用。我写了一个用 Claude 客户端分析群聊记录的程序，结合实例来看 MCP 的应用，很好理解。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 服务的路由寻址问题（没有固定的后缀，只能靠意图识别或者人工配置）。
7. OpenAI 最初开放的 API 协议已经成了一个约定俗成的标准，后来的大模型在开放自家 API 时都会选择兼容 OpenAI 的 API，主要原因有两个：一是 OpenAI 的 API 开放的早，很多应用接入了，兼容它对第三方接入友好；二是 OpenAI 的 API 实现的确实很规范，照着模范生抄作业何乐不为。MCP 会不会也跟 OpenAI 的 API 协议一样，成为行业内的新标准，这个问题取决于先有鸡还是先有蛋：如果有足够多的第三方服务基于这套协议开放了自己的服务，其他大模型/应用客户端应该会跟进；如果主流的大模型/应用客户端都支持了这套协议，那么作为一个第三方，也肯定愿意按这套协议开放自己的服务（比起为 GPTs / Coze / Dify 分别写一个 API 给智能体调用，MCP 服务只需要写一次，可以在任意支持 MCP 的客户端调用）。
8. MCP 目前不支持 Remote Server，不能在网页版调用，只能在 Claude 桌面版使用。我写了一个用 Claude 客户端分析群聊记录的程序，结合实例来看 MCP 的应用，很好理解。MCP 的想象空间还是很大的，未来可期。
个人经验之谈，有表达不当之处，欢迎补充讨论。🌚
128 1733
肝了一篇文章 聊透 AI 辅助编程。🙂
我用 AI 辅助编程，效率提升 x 倍
54 43
知了阅读群文章摘要功能恢复了，踩了不少坑，值得记录一下。
1. 微信机器人用的是 wechaty 框架，之前用的是 padlocal 协议，200 元/月，现在换成了 wechat4u 协议，免费使用。
padlocal 协议有一个好处是，重新登录后能返回稳定的用户 ID，wechat4u 协议重新登录后用户 ID 会变。之前需要记录是哪个用户发了哪篇文章，只能选择 padlocal 协议，现在改成了免费摘要，不绑定文章和用户，则可以选择 wechat4u 协议。
2. 更换微信机器人协议之后，用户在群里转发公众号文章，拿不到文章内容了。排查发现是因为新的协议下，拿到的公众号文章链接是临时的，直接去获取文章内容，会被浏览器拦截，需要人工验证。无论使用 jina reader / firecrawl 还是无头浏览器，都拿不到文章内容。
为了解决这个问题，要么换成原来的 padlocal 协议（拿到的文章链接是稳定的，不是临时的），要么使用无头浏览器模拟点击验证，到达稳定的页面后再获取文章内容。我使用 go-rod 实现了这个模拟点击验证的方案。
3. 拿到文章内容之后，请求大模型摘要，之前用的 DeepSeek 直连 API，请求会比较慢，改成硅基流动的聚合 API 之后，速度有所提升。现在大模型 token 费用非常便宜了，文章自动摘要功能可以免费提供给用户使用，toC 收钱是非常难的。
4. 大模型生成摘要之后，最后一步是生成图文回复到群里。服务端直接画图的方案效率会比较低，我现在的方案是先用前端渲染一个图文摘要页面，再用无头浏览器（go-rod）去截图这个页面，再把图片上传到 cos 拿到图片链接，然后通过微信机器人返回到群里。
后面有时间，再整理一篇文章详细介绍微信机器人 + AI 摘要的方案。“知了阅读”在的群里，任何人转发文章，都会自动输出一个图文摘要，帮助群友做读前筛选。
欢迎体验知了阅读，感谢关注与支持。
1. 微信机器人用的是 wechaty 框架，之前用的是 padlocal 协议，200 元/月，现在换成了 wechat4u 协议，免费使用。
padlocal 协议有一个好处是，重新登录后能返回稳定的用户 ID，wechat4u 协议重新登录后用户 ID 会变。之前需要记录是哪个用户发了哪篇文章，只能选择 padlocal 协议，现在改成了免费摘要，不绑定文章和用户，则可以选择 wechat4u 协议。
2. 更换微信机器人协议之后，用户在群里转发公众号文章，拿不到文章内容了。排查发现是因为新的协议下，拿到的公众号文章链接是临时的，直接去获取文章内容，会被浏览器拦截，需要人工验证。无论使用 jina reader / firecrawl 还是无头浏览器，都拿不到文章内容。
为了解决这个问题，要么换成原来的 padlocal 协议（拿到的文章链接是稳定的，不是临时的），要么使用无头浏览器模拟点击验证，到达稳定的页面后再获取文章内容。我使用 go-rod 实现了这个模拟点击验证的方案。
3. 拿到文章内容之后，请求大模型摘要，之前用的 DeepSeek 直连 API，请求会比较慢，改成硅基流动的聚合 API 之后，速度有所提升。现在大模型 token 费用非常便宜了，文章自动摘要功能可以免费提供给用户使用，toC 收钱是非常难的。
4. 大模型生成摘要之后，最后一步是生成图文回复到群里。服务端直接画图的方案效率会比较低，我现在的方案是先用前端渲染一个图文摘要页面，再用无头浏览器（go-rod）去截图这个页面，再把图片上传到 cos 拿到图片链接，然后通过微信机器人返回到群里。
后面有时间，再整理一篇文章详细介绍微信机器人 + AI 摘要的方案。“知了阅读”在的群里，任何人转发文章，都会自动输出一个图文摘要，帮助群友做读前筛选。
欢迎体验知了阅读，感谢关注与支持。
42 1119