文章目录一、以前写工具代码到底有多折磨人老工具模式三大致命bug二、MCP到底是怎么根治这些糟心事的三、两套核心文件分清客户端和服务端3.1 my-mcp-server.mjs干活的服务端子进程步骤1初始化服务实例步骤2注册可调用工具步骤3注册静态资源步骤4启动标准输入输出通道3.2 langchain-mcp-test.mjs发起请求的客户端父进程第一步配置并连接MCP服务第二步批量拉取工具与资源列表第三步循环读取所有资源内容第四步资源注入系统提示词开启ReAct循环收尾关闭连接释放进程四、捋顺整套调用完整链路4.1 用户提问到工具执行全流程4.2 资源读取完整链路五、MCP对比原生内置工具差距一目了然六、实操自查清单写完直接对照检查P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01一、以前写工具代码到底有多折磨人咱先聊实话最开始写Agent工具的时候我真的天天想摔键盘。举个最真实的场景你在A项目写了个读取本地文件的工具逻辑写得漂漂亮亮下周开新项目好家伙全部代码复制粘贴重来一遍。这跟你在家洗了碗去朋友家吃饭还要自带全套洗碗布有啥区别一点复用性都没有。老工具模式三大致命bug项目隔离完全没法复用工具代码和Agent代码焊死在同一个文件换个工程只能CtrlC/V改参数改路径半小时起步。我上次一个文件读取工具三个月复制了五次每次复制必改三处变量改完还出bug纯纯重复劳动。语言壁垒直接焊死用Python写的数据查询工具Node项目根本调用不了两边语言环境完全不通等于两套工具两套维护。就像你安卓充电线插苹果手机插半天没反应两边各搞一套标准谁也不迁就谁。代码耦合严重两头都要懂写工具的人得吃透Agent底层逻辑写智能体的人还要看懂工具内部实现分工直接作废谁都没法单独干活。后端开发写了个数据库工具前端Agent调试的时候看不懂底层逻辑两个人对着代码扯皮一下午效率直接归零。二、MCP到底是怎么根治这些糟心事的MCP全称模型上下文协议核心操作只有一件事把工具从Agent里拆出来单独做成独立进程用统一标准通信。相当于以前你人跟工具绑在一起现在直接给工具单独开一间办公室你只用走标准化通道传话不用管办公室里面怎么装修。整体架构对比一眼看懂旧模式Agent LLM 工具全部挤在同一个进程代码缠成毛线球。MCP新模式Agent客户端进程 ↔ MCP服务端进程工具全部放在服务端内部完全解耦。这不就是前后端分离吗前端只管展示对话后端只管干活两边互不打扰想换语言换语言想单独更新单独更新。三、两套核心文件分清客户端和服务端整套本地MCP案例只有两个核心文件分工清清楚楚一点不混乱。3.1 my-mcp-server.mjs干活的服务端子进程这个文件就是所有工具、资源的存放地所有查询、读取操作全写在这里对外只暴露标准接口。步骤1初始化服务实例const server new McpServer({ name: my-mcp-server, version: 1.0.0 });这行是固定模板name自定义服务名称version随便填版本用来区分不同服务。步骤2注册可调用工具注册工具一共三个参数各司其职缺一不可① 工具名称LLM识别调用的标识② 描述参数校验规则大模型靠这个判断什么时候调用、传什么参数③ 异步执行函数真正处理业务逻辑接收模型提取的参数。相当于你给外卖平台上架菜品菜名是工具名菜品介绍规格是描述和参数后厨炒菜逻辑就是执行函数平台只负责下单不用管怎么做菜。工具返回格式统一规范content数组承载返回文本预留拓展图文返回的能力绝大多数场景只用填一段文字就行。步骤3注册静态资源资源就是给大模型看的说明书通过自定义URI访问文本、配置都能存进去。注册资源四个核心参数展示名称、访问URI、资源格式说明、读取内容函数。资源就是工具的使用手册大模型启动前先读一遍立马知道当前服务有哪些工具、怎么传参不用人反复写提示词科普。步骤4启动标准输入输出通道const transport new StdioServerTransport(); await server.connect(transport);本地开发专用传输方式父子进程通过stdin/stdout管道通信不用配端口、IP开箱即用。远程部署只需要替换传输类业务代码不用改。3.2 langchain-mcp-test.mjs发起请求的客户端父进程客户端就是咱们的AI智能体负责拉起服务端进程、拉取工具、读取资源、跟大模型对话。第一步配置并连接MCP服务配置格式固定command填运行环境args填脚本路径底层自动调用spawn拉起子进程。不管是Node、Python、npx包配置写法一模一样换语言只改command参数不用重写连接逻辑省心到离谱。第二步批量拉取工具与资源列表两行固定方法getTools()一次性拉取所有服务的工具listResources()拿到全部资源地址不用手动维护工具数组。以前新增工具要手动push进数组现在写完服务端直接刷新拉取新增工具自动识别再也不会漏写、错写。第三步循环读取所有资源内容两层循环遍历所有服务、每个服务下的资源调用readResource读取文本拼接成完整说明文本。两层循环看着麻烦实际作用就是把所有说明书拼成长文一次性喂给大模型不用分段发送减少对话轮次消耗。第四步资源注入系统提示词开启ReAct循环把拼接好的资源文本封装成SystemMessage大模型启动就能看懂全部工具能力。ReAct循环核心逻辑携带提示词和用户问题调用大模型判断是否生成工具调用指令无指令直接输出答案存在工具调用匹配对应工具执行携带唯一tool_call_id把结果塞回对话重复请求大模型直到模型给出最终回答。tool_call_id这个参数千万不能丢模型一次调用多个工具时靠ID区分每条结果对应哪次请求丢了ID模型直接分不清数据回答全乱套。收尾关闭连接释放进程脚本运行结束必须调用close()不然子进程会后台常驻占用内存堆一堆僵尸进程。忘了关连接的后果就是每次运行多开一个后台进程半天下来十几个进程挂着电脑越跑越卡跟后台偷偷开一堆浏览器标签一个德行。四、捋顺整套调用完整链路4.1 用户提问到工具执行全流程用户输入查询需求 → 客户端组装系统提示词用户消息 → 大模型推理判断需要调用指定工具 → 返回带ID的工具调用参数 → 客户端匹配工具执行服务端逻辑 → 工具结果封装带ID消息放回对话 → 再次请求大模型整合结果输出回答。整个流程分工特别清晰大模型只负责思考要不要调用工具代码只负责执行工具、传递数据互不抢活不会出现逻辑混在一起分不清的情况。4.2 资源读取完整链路服务端注册资源定义URI与内容 → 客户端拉取资源列表 → 根据服务名URI读取资源文本 → 拼接为系统提示词传入大模型。五、MCP对比原生内置工具差距一目了然对比维度原生内置ToolMCP服务端模式工具存放位置和Agent代码同文件独立进程、独立脚本复用能力无法跨项目复制粘贴复用任意项目配置即可接入跨语言支持完全不支持Python/Node/Rust全部兼容代码耦合度高度耦合修改一处全联动完全解耦两端独立迭代多工具管理手动维护数组容易遗漏自动合并全部服务工具简单总结原生工具是把工具焊死在智能体身上MCP是给智能体配通用外接工具箱想用哪个插哪个不用随身焊死。六、实操自查清单写完直接对照检查能独立写出MCP服务端完整四步初始化代码熟练掌握客户端连接服务的commandargs标准配置分清getTools/listResources/readResource三个方法的作用与返回结构理解双层循环遍历读取全部资源的底层逻辑明白tool_call_id在多工具并发调用里的必要性完整梳理ReAct循环每一轮执行逻辑清晰说出MCP对比传统内置工具四大核心优势。照着这份清单过一遍本地MCP开发基本不会踩大坑面试问MCP相关问题也能完整讲清整套流程。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01