1. 从一次真实集成说起Function Calling 到底哪里不够我最早接触 Function Calling是在给一个订单管理系统接 AI 助手的时候。客户需求很直接AI 要能查订单、查库存、改发货状态所以我把相关接口封装成函数然后在系统提示词里把函数定义全塞进去让模型自己决定“要不要调”。当时的感觉确实是“好用”模型能根据对话上下文自动选择函数参数类型也基本不会传错。但随后接入的服务越来越多从 3 个工具涨到 20 个工具问题就像滚雪球一样来了。很多团队和我当时的反应一样明明 Function Calling 做得挺好的为什么还要冒出 MCP 这个标准协议怎么会有人觉得 Function Calling 不够用后来我在多套 Agent 框架里反复接入、重写适配层、排查各种超时和鉴权问题之后才意识到一个关键点——Function Calling 解决的只是“模型怎么把一次函数调用说清楚”这一个环节。它没有回答工具怎么被发现、怎么被连接、怎么被鉴权、怎么在远程环境里稳定运行。而这些恰恰是生产环境绕不开的问题。这篇文章我不想纠结于纯理论而是从四个具体维度拆一下 Function Calling 的边界再把 MCP 的设计哲学逐条讲清楚。最后我会把我实际搭建 MCP Server、接客户端时踩过的坑一起列出来。无论你是在做 AI Agent、企业内部工具链还是想找一套通用的 AI 工具接入标准这篇都值得看完再动手。1.1 工具一多上下文先撑不住用过 Function Calling 的人都有一个体感函数定义不是白给的它要占 Token。OpenAI 的 Function Calling 会把每个函数的 JSON Schema 全部放在请求体里包括函数名、描述、每个参数的 type、description、是否必填。一个设计良好的函数几十到几百 Token 很正常。如果你把 50 个工具全部塞进去光工具定义就能吃掉 1 万到 2 万 Token。在 128K 上下文的模型上这个消耗还能忍但换到 32K 的小模型上问题就很明显了。首 Token 延迟变高单次请求成本变高而且模型真正能用来思考用户意图的上下文窗口也被压缩了。更麻烦的是不是所有工具在每个会话里都有用。订单系统里有 20 个工具但用户这一轮可能只关心物流另外 19 个工具的定义照样被迫进入上下文。Function Calling 没有“按需加载”的概念你提供什么模型就必须看什么。我后来做过一个粗略统计某些 Agent 应用里工具定义占了总输入 Token 的 30% 以上甚至有个项目达到 45%。这种浪费在生产环境是不可接受的。MCP 在设计时把“工具发现”和“工具调用”拆开客户端可以先调用tools/list知道服务器有哪些工具再决定要不要把某个工具的 schema 喂给模型。虽然在实际调用时模型往往还是需要看到工具定义但至少你可以按会话、按用户、按任务动态筛选而不是一次全塞进去。1.2 模型只看到函数签名看不到服务和状态Function Calling 的本质是给模型一份“静态的函数签名表”。模型知道这个函数叫什么、参数是什么但除此之外几乎什么都不知道。它不知道这个工具对应的服务是否在线、是否要求认证、返回值会是什么结构、调用失败后应该重试还是放弃。这些信息全部要靠客户端在函数调用完成后通过一次真实的 HTTP 请求去验证。为了补救这一点工程团队一般会做两件事第一在函数的 description 里写大量提示词告诉模型“这个接口可能返回 4xx需要根据 code 字段提示用户”第二在调用失败时手动把错误信息塞回对话里希望模型能根据错误信息自动修复参数。这两件事做起来非常痛苦因为每个工具的失败模式都不一样你需要在客户端代码里为每个工具单独写一套错误处理逻辑。更隐蔽的问题是后端 API 的演进。假设你运维的系统里有个updateOrder函数本来只允许修改订单地址后来业务方要求增加“修改订单金额”的能力。你更新了接口但客户端里的函数定义没同步模型就永远不知道可以用新参数甚至可能因为旧 schema 拒绝发起合法请求。这种“服务端能力变化无法同步到模型侧”的问题本质上是因为 Function Calling 缺少服务端主动描述和广播能力。MCP 的工具端点是服务端实现的工具列表跟着服务端走天然解决了“改了 API 忘了改客户端”的尴尬。1.3 没有标准传输层每个团队都在造轮子Function Calling 标准本身只解决一个问题模型输出一段符合 JSON Schema 的函数调用指令。至于这段指令怎么到后端、后端怎么执行、结果怎么传回来协议完全不关心。真实落地的团队只能自己设计传输方案有的走 HTTP POST有的走 SSE有的走 WebSocket。每条链路都要自己处理超时、重试、断线重连、并发控制、请求取消和流式返回。这些细节单独看都不难但组合在一起就变成一笔不小的技术债。尤其当你要同时接入多个外部工具时每个工具都可能是不同的传输方式A 服务是明文 HTTPB 服务要求 SSEC 服务走 WebSocket 还要带 token。你的 Agent 代码里塞满了 foreach 风格的分支判断时间一长自己都不想维护。这还只是传输层更别提鉴权、审计、日志、版本兼容。我当时在做一个多 Agent 协作系统时就深深体会到了这点模型层已经标准化了但工具层完全是“村办企业”水平。每个接入工具都有一套自己的调用约定和错误结构测试成本高交接文档也写不到底。这就是为什么 MCP 会刻意在协议层把 JSON-RPC 2.0 通信格式、消息类型、错误码、生命周期都定义清楚。传输可以换但消息结构不能换工具可以换但客户端适配逻辑不需要换。1.4 生态碎片化同一套工具换个框架就要重写还有一个常被忽视的痛点——生态碎片化。OpenAI 的 Function Calling、Anthropic 的 Tool Use、Google 的 Function Calling表面上都是“让模型调用工具”但实际协议细节差异很大。函数定义字段名不同消息格式不同调用结果的回传方式也不同。你给 OpenAI 写好的工具封装想原样搬到 Gemini 上用几乎不可能至少要把函数定义和调用结果解析逻辑全部重写一遍。用一张表可以看得很清楚对比维度OpenAI Function CallingAnthropic Tool UseMCP工具定义JSON Schema 嵌入请求tool 对象嵌入 messages协议化 tools/list 获取触发方式模型自动选择模型自动选择模型选择 服务端通知传输层无标准自己定无标准自己定stdio / HTTP / WebSocket服务端能力声明不支持不支持支持能力协商远程接入自己实现鉴权自己实现鉴权协议级鉴权方案在一个公司里可能 Claude 负责写代码、GPT 负责客服、Gemini 负责内容摘要每个场景都要接入内部工具。如果都用点对点的 Function Calling就意味着你要为三套协议各写一份工具适配层还要同步维护。MCP 想解决的问题就是这个工具服务端只需要实现一次 MCP Server任何支持 MCP 的客户端都能直接使用。它不是替代“模型决策是否调用工具”这一步而是把工具的接入方式从“点对点”变成“一对多”。2. MCP 的设计哲学把“点对点集成”升维成“协议化接入”聊完 Function Calling 的四个边界MCP 的价值就很好理解了。它不是一个“又一个函数调用格式”而是一整套应用层标准协议。如果你习惯把技术问题类比到生活场景可以这么理解Function Calling 是每个人各自用不同的充电线给手机充电MCP 想做的是那个统一接口让所有充电器都能插进同一个口。更进一步MCP 的设计其实借鉴了软件行业一个非常成熟的模式——LSPLanguage Server Protocol。2.1 设计源头从 LSP 继承的“协议化抽离”思想LSP 的历史很有意思。在它出现之前每种语言都要为每个编辑器提供配套插件。VS Code 要出 Python 插件Sublime 也要出 Python 插件Emacs 还要出 Python 插件。插件的维护成本极高而且能力还不一定对齐。LSP 的做法是把“语言分析能力”抽成独立的语言服务器编辑器只要实现 LSP 客户端协议就能对接任何语言。一次实现到处复用。MCP 的设计者显然是沿着这条思路思考的。AI Agent 此刻正面临和编辑器当年一样的困境每接一个外部服务就要在 Agent 代码里写一套工具集成每换一个 Agent 框架这套集成基本作废。MCP 想把“工具能力”抽成独立的工具服务器Agent 只实现 MCP 客户端协议就能对接任何服务。写代码的工具、操作浏览器的工具、读设计稿的工具、控制安全测试软件的工具全部接入同一套协议。这也是为什么很多人会问“MCP 是软件协议还是硬件协议”。答案是明确的MCP 是应用层软件协议和 HTTP、LSP、WebSocket 同一层级。它不涉及物理接口、电气特性那些硬件内容只规定“软件之间怎么描述能力、怎么交换请求、怎么传递结果”。你可以把它理解为“AI 时代的服务接口标准”。2.2 三种原语tools、resources、prompts 分别解决什么问题MCP 协议中最核心的设计是定义了三种原语Tools、Resources、Prompts。很多刚接触的人只盯着 Tools觉得这不就是函数调用换个名字吗但只要把三种原语放在一起看就能看出 MCP 的野心——它想覆盖 Agent 和外部世界交互的全部类型而不是只解决“调用一个函数”。Tools 是可执行操作这是和 Function Calling 对齐的部分。模型决定是否调用服务器执行并返回结果。区别在于工具列表由服务器动态提供并且可以中途变化。Resources 是可读上下文。Agent 做事之前需要“先了解”比如读一个数据库表结构、看一份产品文档、拉取某个页面的 HTML。Resource 可以是一个固定 URI也可以是一个带参数的资源模板比如orders://recent?statuspending。Prompts 是可复用提示模板。它把团队沉淀的提示词模板做成服务器端点用户或模型可以按名字获取。这一步把“提示词工程”从零散的文本文件变成了协议可发现、可复用、可管理的资源。我用一张简化表格对比一下原语解决什么问题类比传统概念Tools让 Agent 做一件事API 调用 / RPCResources让 Agent 知道一件事数据库查询 / 文件读取Prompts让 Agent 按模板执行一种模式模板函数 / 预设角色只把 Tools 接到 MCP 上的团队其实只发挥了协议一半的威力。Resources 的价值在真实场景里尤其明显。举个例子你让 Agent 分析某个订单的异常状态如果没有 Resources你需要把订单数据手动拼到提示词里有了 ResourcesAgent 可以直接通过orders://detail/12367读取数据源信息更新及时也不用担心上下文里塞了过期的快照。2.3 生命周期与消息格式JSON-RPC 2.0 上的“握手”MCP 的通信基础是 JSON-RPC 2.0。所有请求都有唯一的 id有标准的 error 对象也有服务端主动发起的 notification通知。这些机制本身不稀奇真正有意思的是协议的生命周期设计。客户端和服务器建立连接后第一步不是直接调工具而是要完成一次 initialize 握手。客户端发送自己支持的协议版本和 capabilities服务器回复自己支持的版本号和能力清单双方确认后再进入正常通信。这个设计是从分布式系统里学来的基本素养先协商再做事。避免版本不匹配、能力不对称导致的调用失败。Function Calling 没有这个过程客户端默认“我给的函数一定存在一定可调”所以一旦后端协议升级往往直接报错而且报错信息晦涩难懂。MCP 的流程大致是initialize 握手 →notifications/initialized通知 →tools/list拉工具列表 →tools/call调用工具 →resources/read读取资源。服务端还可以通过 notification 通知客户端“工具列表变了请重新拉取”。这套生命周期给了前后端非常清晰的契约也方便开发者做审计和回放因为这些消息都是结构化、可追踪的。2.4 传输层设计成“可插拔”到底在解什么题MCP 另一个核心设计是传输层抽象。早期规范的传输方式是 stdio标准输入输出主要面向本地场景客户端直接拉起服务器进程通过 stdin/stdout 通信。这种模式最简单也最安全因为不需要网络缺点是只能跑在同一台机器上。随后出现的是 HTTP SSE 传输服务器用 SSE 推送消息客户端用 HTTP POST 发送请求。再后来社区又演进出了 Streamable HTTP 和 WebSocket 传输。你会发现不少云服务直接以wss://开头的 WebSocket 地址作为 MCP 端点比如类似wss://api.example.com/mcp?token...的形式这就很适合浏览器里运行的客户端或者需要长连接的场景。把传输层抽象出来之后上层业务代码就不用关心“消息怎么到达对方”。你既可以让 MCP Server 跑在本地子进程里也可以部署在远程服务器上可以走加密的 WebSocket也可以走普通 HTTP。这个灵活度对生态发展极其重要——因为工具服务器不可能永远跟客户端在同一台机器上SaaS 化、云化是必然趋势。3. 实操10 分钟搭一个 MCP Server并让 Client 连上理论讲再多不如亲手跑一遍。这一节我不会讲很复杂的东西只带你走完一个最小闭环用 Python 写一个带 Tool 和 Resource 的 MCP Server然后在本地用一个支持 MCP 的客户端接入它。全部代码加起来不到 40 行但整个过程能帮你把协议的生命周期、消息格式、配置方式全部串起来。3.1 用 FastMCP 快速实现一个 ServerMCP 官方提供了 TypeScript SDK 和 Python SDK第三方库 FastMCP 使用起来更直观。如果你是 Python 用户强烈建议直接用 FastMCP。安装就一行pip install fastmcp。下面这个示例实现了一个“订单助手”服务器包含一个查询订单的工具和一个读取订单统计信息的资源。from fastmcp import FastMCP mcp FastMCP(order-helper) mcp.tool() def query_order(order_id: str) - dict: 根据订单号查询订单状态。 # 实际项目中这里会调用内部订单服务 return { order_id: order_id, status: 已发货, logistics: 顺丰速运, eta: 2025-06-14 18:00 } mcp.resource(orders://stats) def get_order_stats() - str: 返回今日订单统计。 return 今日订单总数: 1024异常订单: 5待发货: 230 if __name__ __main__: mcp.run(transportstdio)这段代码有两处值得注意。第一mcp.tool()装饰器会把函数自动转换成 MCP Tool函数名、参数类型、docstring 都会自动变成协议里的工具描述。第二mcp.resource(orders://stats)定义了一个资源端点客户端可以直接通过这个 URI 读取数据。运行python server.py后这个服务器会在 stdin/stdout 上等待 JSON-RPC 消息。如果是公网或者跨进程场景你还可以把传输方式改成 HTTP只需把最后一行改为mcp.run(transporthttp)FastMCP 会自动启动一个 HTTP 服务。对于从零上手的人来说先用 stdio 模式理解协议再切换到 HTTP 模式是最平滑的学习路径。3.2 配置客户端Claude Desktop、Cursor、Codex 都能接服务器跑起来之后剩下就是让客户端找到它。以 Cursor 为例在.cursor/mcp.json里加入下面这段配置{ mcpServers: { order-helper: { command: python, args: [/absolute/path/to/server.py], env: {} } } }Claude Desktop 的配置位置类似一般在claude_desktop_config.json里结构几乎一样。Codex 这类 CLI 工具也支持类似配置只是字段名可能略有差异。接好之后你只需要在对话里问一句“帮我查一下订单 ORD-2025-0613 的状态”模型会先通过tools/list发现工具再通过tools/call调用query_order最后把结果组织成自然语言回复你。这里我踩过一个坑路径问题。args里的路径必须写绝对路径否则客户端拉起子进程时会找不到文件。如果你用的是 Windows还要注意python可能在 PATH 里不存在保险做法是写 Python 解释器的完整路径比如C:\\Python312\\python.exe。3.3 接入远程 ServerHTTPS 与 WebSocket 两种方式本地接入只是第一步真正到生产你大概率需要接远程 MCP Server。远程接入的配置也很简单不再指定command而是指定url。来看一个标准配置{ mcpServers: { remote-order-api: { url: https://api.example.com/mcp, headers: { Authorization: Bearer YOUR_TOKEN } } } }如果服务器走 WebSocket 传输url会类似wss://api.example.com/mcp?tokenYOUR_TOKEN。当你在浏览器里写 Agent 应用或者需要服务端主动推送通知时WebSocket 传输会更合适。普通 HTTP 请求适合一次性调用WebSocket 适合长连接场景二者在 MCP 规范里都支持选择哪个取决于服务端的实现和你的网络环境。需要注意的是把 token 放在 URL query 里虽然方便但存在日志风险。很多网关、代理、访问日志会记录完整 URLtoken 一旦落日志就可能泄露。我自己更倾向于把 token 放在 Authorization header除非服务端明确只支持 query 方式。另外远程 MCP 接入后初始化握手变得更重要因为你要确认远程服务器返回的协议版本和你的客户端版本兼容否则调用会因为版本不匹配被直接拒绝。4. 从实际项目出发MCP 生态里那些让人“哇”的落地场景了解了协议原理再回头看整个 MCP 生态会发现它早已不是实验室产物。2025 年以来几乎每天都有新的 MCP Server 出现覆盖了浏览器自动化、安全测试、设计工具甚至工业软件。这些应用的共同点在于它们都给 AI 提供了一个“手和眼睛”让模型能直接操作真实世界的工具而不是只停留在纯文本对话。4.1 Playwright MCPAI 直接操作浏览器Playwright MCP 是我个人用得最多的工具之一。它把 Playwright 的浏览器自动化能力封装成 MCP ServerAgent 可以自己打开页面、点击按钮、填写表单、截图、读取网络请求。配置方式很简单{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] } } }接好之后我让 AI 帮我做过端到端回归测试给它一个线上环境的 URL它自己会打开页面、登录、点几个业务按钮然后把页面报错信息拿回来分析。过去写一套这样的 E2E 自动化脚本至少需要半天现在让 AI 跑一遍 UAT 流程可能只需要几分钟的调试时间。还有一个细节值得说Playwright MCP 默认接在 headless 浏览器上如果你需要看真实界面做演示记得加--headed参数否则你不会知道模型每一步到底操作了什么。4.2 Burp Suite MCP安全测试接入 AI 工作流安全界对 MCP 的关注度也在急剧上升。Burp Suite 是渗透测试里的老牌工具现在也有 MCP Server 实现让 AI 直接操控 Burp 的抓包、重放、扫描能力。配置接入思路和上面一样本质上就是把 Burp 的功能暴露成一个个 MCP Tool然后让 Agent 根据测试目标自动编排操作。这类场景的典型工作流是Agent 先访问目标站点观察 Burp 截获的请求列表然后根据漏洞特征生成测试请求主动重放和检查响应。AI 做初步漏洞扫描安全专家做最终人工复核效率确实比纯手工高很多。不过我必须提醒一句这类工具接上 AI 后影响面很大别在未经授权的目标上跑合规问题比效率更重要。MCP 本身的鉴权机制也必须在接入前配置好否则等于把你的抓包工具对外开放了。4.3 Figma、Blender、Chrome DevTools设计、三维与前端调试设计类工具同样被 MCP 改变了用法。Figma MCP 让 AI 可以读取设计稿的图层结构、导出色值、提取组件信息然后直接把设计参数传给前端代码生成。对于经常要“对着设计稿写样式”的开发者来说这个闭环非常爽。Blender MCP 则让 AI 能直接操作三维场景你可以用自然语言让 AI 建一个立方体、改材质、调灯光。Chrome DevTools MCP 更接近前端调试AI 可以读取控制台报错、检查 DOM 状态、分析网络请求。这些场景背后其实是同一个逻辑把专业软件的操作从“人用鼠标键盘操作”变成“模型用标准接口调用”。AI 不是在模仿人操作界面而是直接通过协议访问工具的能力层。这比屏幕识别、UI 自动化要稳定得多因为它绕过了渲染层的不确定性直接操作数据层。这也是为什么现在很多团队在设计自研工具时都在考虑顺便对外暴露一个 MCP Server而不是只提供传统 API 文档。4.4 一个容易被忽略的问题MCP 到底解决的是接口问题还是协议问题从这些落地场景可以看到MCP 的价值点不在于“让 AI 调一个工具”而在于“让所有 AI 客户端用同一种方式接入所有工具”。普通 API 提供的是“接口”使用方必须知道接口在哪里、怎么鉴权、怎么传参MCP 提供的是“协议”使用方只要实现协议客户端剩下的通过交互式发现解决。这就是它和 REST、gRPC 这类“服务间通信协议”的根本差异所在。我在内部技术分享时经常用一个说法REST 是给开发者的MCP 是给 AI 的。开发者接到一个 REST API会先翻文档然后用代码拼接请求。AI 接到一个 MCP Server会先调用tools/list自己“读文档”然后根据工具描述自己拼参数。这个过程不需要人肉维护接口文档也不需要为每个服务写专属 SDK。协议发现加上模型推理AI 自身的适应能力就发挥出来了。5. 实际排过的坑MCP 接入倒查清单作为一个把 MCP 接进过几个生产项目的工程师我深知理论再顺实践中的坑还是层出不穷。这一节我把遇到过的问题整理成清单每个问题都附上原因和解决方案。如果你在接入时遇到类似现象直接按这个倒查。5.1 超时30 秒后客户端直接放弃我遇到过三次类似的报错mcp client timed out after 30 seconds。这个 30 秒是很多客户端的默认超时上限。服务器冷启动比较慢时比如要加载大型模型或者初始化数据库连接握手阶段就容易超时还有一种情况是工具本身耗时长比如一个函数要跑数据批量处理同步等待 30 秒不够用。解决思路分三层第一给客户端调大超时时间不少客户端配置支持timeout字段第二把长耗时操作改为异步模式先用工具提交一个任务拿回 task_id再用另一个工具轮询结果第三检查服务器启动路径有些时候超时只是因为服务器进程根本没起来比如路径写错或者依赖没装全。先排除第三点再去想协议层面的优化否则容易绕远路。5.2 stdio 模式下 stdout 被污染这个坑非常隐蔽但危害极大。在 stdio 模式下stdout 是 MCP 协议消息的专用通道客户端和服务器通过它传输 JSON-RPC 消息。如果服务器代码里有任何print()输出哪怕是调试用的日志都会被当成协议消息喂给客户端导致整个会话解析失败。我第一次用 FastMCP 时为了看函数是否被调用在工具函数里顺手加了一个print结果客户端直接卡死。正确做法是日志输出到 stderr不要打到 stdout。如果你用 Python 的 logging 模块默认也是输出到 stderr所以一般没问题怕的是有人图方便用print。此外MCP 协议本身定义了logging/setLevel这一类通知服务器可以通过协议主动上报日志客户端可以设置日志级别。生产环境里建议把日志接到独立的日志文件或日志采集系统然后再让 MCP 服务器通过协议上报关键事件。5.3 鉴权与 token 管理别在 URL 里裸奔远程 MCP 服务的鉴权问题是 2025 年以来社区讨论最多的话题之一。早期很多远程 MCP 端点直接采用 token 放在 URL query 的方式比如wss://api.example.com/mcp?tokenxxxx。这种实现简单但风险显而易见URL 极易被网关、代理、CDN 日志记录token 一旦落日志等于凭据泄露。更危险的是有些团队会把日志同步到搜索引擎索引导致 token 被公开收集。我现在的做法是第一能用 header 尽量用 header比如Authorization: Bearer xxx第二如果服务端只支持 query 参数建议在网关层把日志脱敏或者定期轮换 token第三MCP 规范正在向 OAuth 2.1 方向演进新接入的服务优先选择支持 OAuth 授权的实现用标准授权码流程而不是长期静态 token。安全问题在 Agent 时代只会越来越重要别为了方便牺牲掉这一层。5.4 Windows 环境下 npx 与命令路径的兼容问题如果你在 Windows 上用 Playwright MCP 这类基于 Node 的服务器几乎一定会遇到命令启动失败的问题。{command: npx, args: [...]}在 Windows 上经常无法直接拉起子进程因为 npx 是一个 shell 脚本需要经过 cmd 执行。常见的规避方式有两种把 command 改成cmdargs 传/c npx ...或者给 npx 写一个 .cmd 包装路径。另外Windows 上如果同时装了多个 Python 版本python命令可能指向了某个虚拟环境导致 MCP Server 缺少依赖。我建议所有 command 都写成绝对路径宁可配置文件长一点也不要留这种“本地能跑、别人拉不起来”的隐患。很多团队觉得这类问题小但在多人协作时一个错误的配置可能浪费整个下午的排查时间。5.5 常见问题速查表现象常见原因解法握手 30 秒超时服务冷启动慢 / 超时配置过小调大 timeout预热服务异步任务化连接后无响应stdout 被 print 污染日志改到 stderr禁止 print401 / 403 拒绝token 过期或 header 位置不对检查 Authorization轮换 token工具列表为空工具未注册 / 注册装饰器写错检查 mcp.tool() 是否生效Windows 启动失败npx / python 路径问题使用 cmd 包装或绝对路径协议版本不兼容客户端与服务器 SDK 版本差异升级 SDK查看握手返回版本号写在最后的一点经验这套 MCP 接入流程我前后跑了不下十遍最大的感受是写一个 MCP Server 不难难的是把工具边界设计清楚。很多人一上来就把所有接口都塞进 Tools忽视了 Resources 和 Prompts 的存在结果就是 Agent 依旧要靠对话里的上下文猜来猜去最后还是退化成“伪 AI 客服”。按照我的习惯凡是“一次性数据查询”优先设计成 Resource凡是“可复用的任务模板”设计成 Prompt只有真正需要模型做决策并触发副作用的操作才设计成 Tool。这样设计出来的服务Agent 用起来明显更稳调试也更简单。MCP 还在快速演进但它的核心设计哲学其实一直没变——把工具接入从“和每家 API 谈恋爱”变成“遵循同一个协议交朋友”。先理解这一点剩下的事情都会变得顺理成章。
