VSCode扩展工具Copilot MCP使用教程【MCP】

优质文章学习记录

— 3 min read
VSCode扩展工具Copilot MCP使用教程【MCP】
在这里插入图片描述


MCP（Model Context Protocol，模型上下文协议） ，2024年11月底，由 Anthropic 推出的一种开放标准，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。本文章教你使用VSCode扩展工具Copilot MCP快速上手MCP应用！

1. VSCode中安装Copilot MCP

在这里插入图片描述


Copilot MCP是一个适用于 VSCode 的 MCP Client。

2. Copilot MCP使用

安装之后会出现Coplilot授权，并在左侧菜单中出现MCP Server按钮

在这里插入图片描述

3. Add Server

点击Add Server，MCP Server分为两种建立方式，Process和SSE

在这里插入图片描述


以Process为例，输入必要信息：

在这里插入图片描述


其中Server Name是你给Server起的任意名字，需要注意的是Start Command。
这里我的输入为：

npx -y @modelcontextprotocol/server-filesystem /path

注意path修改为自己的文件路径，并确保你已安装node.js从而可以使用npx命令
这个Command怎么来的呢？
可从来自MCP Server官方社区获得自己想要的Server：

https://github.com/modelcontextprotocol/servers?tab=readme-ov-file
在这里插入图片描述


以Filesystem为例，点进去可查看其调用方式，以NPX为例：

在这里插入图片描述


其要求我们输入npx命令，并附加上文件路径，可以为多个文件路径，显然，Command格式举例如下：

npx -y @modelcontextprotocol/server-filesystem /path

注意path修改为自己的文件路径，并确保你已安装node.js从而可以使用npx命令。
在Start Command中输入以上命令即可。
输入完成后点击 Add Server
成功后列表显示刚刚添加Server，不显示意味着添加失败。

在这里插入图片描述


点开后可查看该Server提供的Tools列表：

在这里插入图片描述

4. 调用Server

准备一个测试文件，我在/path下创建了个mcp_test.txt文件,里面包含一句话：

在这里插入图片描述


之后，在VSCode 右侧Copilot对话框中出入：

@mcp <内容>
在这里插入图片描述

例如：

@mcp 请读取"/root/xxx"下的“mcp_test.txt”中的内容
在这里插入图片描述

发送后得到回应：

在这里插入图片描述

成功！！！

Read more

本地化部署方案：GraphRAG+LangChain+Ollama 驱动 LLaMa 3.1 集成 Neo4j 实战

本地化部署方案：GraphRAG+LangChain+Ollama 驱动 LLaMa 3.1 集成 Neo4j 实战

本文将带您从零开始，用不到50行核心代码实现基于本地大模型 LLaMa 3.1 的 GraphRAG 应用开发。我们将整合 LangChain 工作流、Ollama 模型管理工具与 Neo4j 图数据库，构建一套支持实体关系挖掘与混合检索的增强生成系统，全程无需依赖云端 API，兼顾数据安全与开发效率。 一、先搞懂核心概念：什么是 GraphRAG？ 传统 RAG（检索增强生成）依赖向量数据库的语义相似度匹配，容易丢失实体间的关联信息。而 GraphRAG（图检索增强生成） 则通过"节点-关系"的图结构建模数据，将分散的文本块转化为结构化知识网络，让 LLM 能基于实体关联进行推理，输出更具逻辑性的答案。 其核心价值在于： * 结构化上下文：将"蒂姆·库克""苹果公司&

Llama Factory微调显存参考表：从7B到72B模型的实战验证

Llama Factory微调显存参考表：从7B到72B模型的实战验证 大语言模型微调是当前AI领域的热门技术，但显存需求往往成为实践中的拦路虎。LLaMA-Factory作为流行的微调框架，官方提供了一份显存参考表，但实际部署时我们常会遇到"理论值"与"实测值"不符的情况。本文将带你通过云实例批量验证7B到72B模型的显存占用规律，为你的微调实践提供可靠依据。 为什么需要验证显存参考表 微调大模型时，显存不足是最常见的报错原因。LLaMA-Factory官方参考表虽然给出了不同模型规模下的显存预估，但实际运行时会受到以下因素影响： * 微调方法差异：全参数微调、LoRA、QLoRA等方法对显存的需求可能相差数倍 * 精度选择：float32、bfloat16、float16等不同精度直接影响显存占用 * 批次大小和序列长度：较长的文本序列会指数级增加显存消耗 * 框架版本差异：如某些commit可能意外修改默认数据类型 这类任务通常需要GPU环境，目前ZEEKLOG算力平台提供了包含LLaMA-Factory的预置环境，可快速部署验证。 测试环境搭建与配置

AIGC爆发时代：用TensorRT镜像抢占推理市场先机

AIGC爆发时代：用TensorRT镜像抢占推理市场先机 在生成式AI席卷全球的今天，用户对“秒级响应”的期待早已不再是奢望。从文生图、语音合成到实时翻译和个性化推荐，AIGC应用正以前所未有的速度进入千行百业。但随之而来的挑战也愈发尖锐——如何让动辄数十亿参数的大模型，在有限的硬件资源下依然保持低延迟、高吞吐？ 答案不在更大的GPU集群，而在更聪明的推理优化。 NVIDIA推出的TensorRT及其配套的官方Docker镜像，正是破解这一难题的关键钥匙。它不是简单的加速库，而是一整套面向生产的推理编译与部署体系。许多企业在将Stable Diffusion或LLM迁移到生产环境时，第一道关卡就是性能瓶颈；而那些率先采用TensorRT方案的团队，往往能在上线初期就实现3倍以上的吞吐提升，直接拉开竞争差距。 这背后的技术逻辑并不复杂：与其“硬跑”原始模型，不如先将其“编译”成针对特定GPU架构高度定制的执行引擎。就像为一辆赛车量身打造发动机调校，而不是开着家用车去参加F1比赛。 为什么原生框架跑不动大模型？ 我们先直面一个现实问题：为什么PyTorch训练完的模型，放到服务

ClawdBot实际作品展示：Whisper+PaddleOCR双模态翻译对比图集

ClawdBot实际作品展示：Whisper+PaddleOCR双模态翻译对比图集 1. ClawdBot是什么：你的本地AI翻译工作台 ClawdBot不是云端服务，也不是需要注册账号的SaaS工具——它是一个能完整运行在你个人设备上的AI助手框架。你可以把它理解成一个“可插拔”的AI控制中心：后端用vLLM调度大模型，前端提供Web界面管理，中间通过标准化协议连接各类AI能力模块。它不依赖厂商API调用配额，不上传隐私数据，所有推理都在本地完成。 关键在于它的定位：不是替代某个具体功能的工具，而是让你自由组装翻译流水线的底盘。比如你想让一张日文菜单图片自动转成中文并朗读出来，ClawdBot本身不直接做OCR或语音合成，但它能协调Whisper、PaddleOCR、TTS模型按顺序执行，并把结果整合成一次连贯响应。 这种设计带来两个明显优势：一是隐私可控——整张图片从上传到识别再到翻译，全程不离开你的机器；二是能力可替换——今天用PaddleOCR识别，明天换成PP-OCRv4，只需改几行配置，无需重写业务逻辑。 它不像传统AI应用那样“开箱即用”，但比纯命令行工具更友