企业官网建设流程全解析

MCP（Model Context Protocol）这个词火了快一年，但我发现大多数人的理解还停留在“AI 调用工具的统一格式”这个层面。这个理解不算错，但很可惜，它把 MCP 想小了。今天我想用第一性原理，把 MCP 从工具调用重新拆一遍：它真正改变的不是“函数怎么调”，而是“能力怎么被声明、被发现、被组合”。这篇文章适合正在接 MCP 但总觉得哪里没想透的开发者，也适合在 Cursor、Codex、Cline 里配了一堆 MCP Server 却搞不清它们之间关系的同学。看完你会明白，为什么我把 MCP 称作能力协议，而不是工具调用协议。

1. 先别急着调工具：MCP 解决的根本矛盾

1.1 Function Calling 的“三堵墙”

要理解 MCP 为什么会出现，得先回到没有 MCP 的时候。大模型应用接入外部能力，最原始的做法是 Function Calling，也就是我们在系统提示词里塞一堆 JSON Schema，告诉模型“你有个函数叫 search_docs，参数是 keyword，类型是 string”。模型根据这坨 schema 输出一个结构化的调用意图，代码再去执行对应函数。

这套机制今天依然大量存在，OpenAI、Anthropic、Google 都有各自的 function calling 实现。但只要你做过三个以上的 AI 应用，就会撞上三堵墙。

第一堵墙是schema 与实现的双份维护。你写了一个 Python 函数get_user_orders(user_id)，为了让它能被模型调用，还得在另一个文件里手写一份对应的 JSON Schema，描述参数、类型、必填项。函数改了，schema 经常忘了同步。第二堵墙是静态上下文的容量瓶颈。所有工具描述都必须塞进 prompt，工具一多，几千 token 就没了。我见过有人往 system prompt 里塞 20 个工具的 schema，结果模型开始“幻觉式调用”根本不存在的参数。第三堵墙最致命：工具是宿主私有的，换一个应用全部重来。你在 Web 应用里写好的工具函数，换个 Chat 客户端、换个 IDE 插件，一行都带不过去，每个宿主都得自定义一套工具注册和调用协议。

这三堵墙的本质是什么？是"工具调用"这件事被绑定在了具体应用的实现里。模型和外部世界之间的接口，本该是公共的、动态的、可以由多方共同维护的，现实中却成了每个应用自己后院里的私房菜。

1.2 MCP 出场：把“我要调用”变成“你能提供什么”

MCP 的切入点，正好打在这三堵墙上。它的思路不是继续优化“function calling 的格式”，而是引入了一个全新的中间层：MCP Server 作为独立的能力提供者，模型所在的 Host 作为能力消费者，二者通过标准协议对话。

这个变化看着只是加了个中间人，但性质完全不同。在 function calling 的世界里，模型应用是主体，工具是被动等待调用的客体，一切行为都围绕“我这个应用有什么函数”展开。在 MCP 的世界里，模型应用不再需要提前知道一个函数的存在，它只需要问一句：“你（MCP Server）能提供什么？”服务器回答：“我提供这些 tools，这些 resources，这些 prompts。”然后模型再决定用哪个。

这就是工具调用和能力协议的临界点。工具调用描述的是“我怎么执行一个既定动作”，能力协议描述的是“我如何发现并协商一个能力”。前者是编死的，后者是运行时动态发生的。MCP 的核心原语里专门设计了tools/list，这看起来只是个枚举接口，但它背后代表的是能力的自描述：一个 MCP Server 可以在运行时告诉客户端它有什么能力，客户端不需要事先硬编码，更不需要把能力清单打包进提示词。这种“动态发现”机制，才是“协议”和“格式”之间真正的分水岭。

2. 第一性原理拆解：MCP 是能力协议，不是工具标准

2.1 能力声明的本质：从“写死函数”到“运行时协商”

我们可以把 MCP 的第一性原理压缩成三句话：

1. 外部世界的每一种可交互能力，都可以抽象为统一的接口；
2. 这种接口应该由能力的提供方自主声明，而不是由消费方预先定义；
3. 消费者通过标准协议在运行时发现、选择、调用能力。

围绕这三句话，MCP 设计了极简的三角色模型：Host（宿主，也就是 Claude Desktop、Cursor、Codex 这类 AI 应用），Client（宿主内部与 server 建立连接、维护会话的组件），Server（能力提供方，暴露工具、资源、提示词）。Host 与 Server 之间走 JSON-RPC 2.0，传输层默认支持 stdio 和 HTTP+SSE，新版本还加了 Streamable HTTP。这个架构你越看越像什么？像 HTTP 协议本身：浏览器（Host）不知道服务器（Server）上有什么资源，但知道该用 GET、POST 去试探；服务器用 200、404 这些状态码告诉浏览器结果。MCP 把同样的哲学搬到了 AI 与外部世界的交界处。

这就是为什么我坚持认为 MCP 的核心贡献不在工具调用本身，而在“能力协商”。所谓能力协商，是一套完整的生命周期：

• initialize建立会话，协商协议版本和 capabilities；
• tools/list发现可调用的工具集合；
• resources/list发现可读取的数据资源；
• prompts/list发现可复用的提示模板；
• tools/call、resources/read、prompts/get执行具体操作。

大家可以对比一下 Computer Use 这类方案，它走的是“像素级操作界面”的路线，让 AI 直接看屏幕、点鼠标、敲键盘。MCP 走的是“语义级操作界面”，让 AI 直接面对能力本身，不需要理解 GUI。两者的哲学差异很明显：Computer Use 是让 AI 适应人类的操作方式，MCP 是让外部世界以 AI 最容易理解的方式暴露自己。哪个更适合自动化？毫无疑问是后者，因为语义接口减少了感知和动作之间的误差，代价是需要有人先为系统写一层适配。

2.2 三种原语：资源、提示、工具，一个都不能少

很多人以为 MCP Server 就是“把函数暴露给 AI”，只用了 Tool 这一种原语。但 MCP 的真正设计野心，藏在它定义的三类原语里。

工具（Tools）是最容易理解的，对应可执行的函数，通常有副作用，比如“发送邮件”“创建订单”“读取数据库”，由模型自主决定何时调用。

资源（Resources）则是可读取的数据载体，可以是文件内容、数据库查询结果、API 响应，甚至是file://协议下的本地路径。资源的意义在于：它让模型在调用工具之前，可以先“读取上下文”。比如一个代码仓库的 MCP Server，可以暴露repo://src/main.py这样的资源 URI，模型先读代码再决定怎么改。

提示词（Prompts）在中文社区里讨论得最少，但它其实最妙。Prompt 在 MCP 里是“可复用的模板”，由服务端维护。比如一个数据库 MCP Server 可以提供一个prompts/sql_review模板，客户端请求这个 prompt，得到的不是文本，而是需要填入参数的消息结构。这相当于把提示工程从客户端挪到了服务端，由最懂某个垂直领域的人去维护提示内容。

为什么要有三种而不是一种？回到第一性原理：真实世界的“能力”不是只有动作，还有数据输入和任务模板。如果只有工具，模型每次操作前还得有人在提示词里手动注入背景资料，那上下文窗口依然会被撑爆。有了资源和提示词，数据加载和任务编排也被纳入了协议范围。你连接一个 Figma MCP，它不仅给你get_file这种工具，还能让你直接读取设计稿的节点树资源；连接一个蓝湖 MCP，它不只会“切图”，还能把设计规范作为资源暴露给模型。三者合在一起，才构成一个完整的“能力面”。

2.3 为什么“能力协议”比“工具调用协议”更准确

我给 MCP 的定义是：它是一套让 AI 应用在运行时发现、协商并调用外部能力的开放协议，能力可以是动作（Tool），可以是数据（Resource），也可以是任务模板（Prompt）。工具调用只是这套协议下的一种消息模式。

这个区分不是文字游戏，它决定了我们怎么设计 MCP Server。如果你把 MCP 理解成“工具调用格式”，你就会照着 function calling 的思路把每个函数都塞成 tool，然后发现很多场景特别别扭——比如你想给模型提供一份很大的配置文档，它会变成get_config()工具；你想让模型读取项目状态，又得写另一个工具。但如果你把 MCP 理解成能力协议，你会自然地想：这个能力域里有哪些数据（resource）、有哪些动作（tool）、有哪些标准作业模板（prompt），然后按领域建模。两者的设计产出是完全不同的。

还有一个更实际的原因：工具调用是“宿主单方面定义的”，能力协议是“双方协商的”。在多智能体场景里，这一点越来越关键。一个 Agent 作为 Host 去连另一个 Agent 暴露的 MCP Server，两者之间不是主从关系，而是能力供需双方的关系。宿主可以决定“要不要用”，服务器可以决定“给不给这个客户端用”。这种松耦合才是多智能体协作的基础。所以说 MCP 是多智能体世界里“通信与协作的基础设施”，一点都不夸张。

3. MCP 和那些容易混淆的概念：Skill、Computer Use，到底差了些什么

3.1 MCP 是管道，Skill 是内容

我在社区里经常被问到一个问题：Agent Skill 和 MCP 有什么区别？这俩概念确实容易混，因为很多 MCP Server 装完之后，效果看起来就是一个“让 AI 获得某项技能”。

我的区分方式很简单：Skill 是模型侧的“怎么想”，MCP 是外部侧的“怎么连”。Skill 通常是一段提示词、一份 Few-Shot 示例、一套推理路径组成的“软技能包”，它改变的是模型的行为方式，不涉及外部系统交互。比如你给 Agent 装一个“代码审查 Skill”，它学到的是审查的顺序、关注点、输出格式，整个过程可以完全不碰任何外部 API。MCP 则解决的是“外部系统怎么把能力暴露给模型”的问题，它需要实实在在的进程、服务、鉴权、数据传输。

更直接地说，Skill 是给 Agent 的大脑装软件，MCP 是给 Agent 接五官和手脚。一个 Agent 可以只靠 Skill 完成纯推理任务，但只要涉及读数据库、操作 Figma、调浏览器，就必然要 MCP 这类通道。这里不存在谁取代谁的问题，最佳实践恰恰是组合：用 Skill 定义领域内的作业方法论，用 MCP 打通所需的外部工具，两者一个向内、一个向外。

3.2 MCP 与 Function Calling / Tool Use 的继承关系

那 MCP 跟 Function Calling 的关系呢？我倾向于描述成“继承并超越”。MCP 的工具调用动作，本质上是 function calling 的标准化网络版。function calling 解决的是“模型怎么表达调用意图”，把 JSON Schema 塞给模型，让它输出一段结构化调用。MCP 保留了这套交互模式，但把工具的声明、注册、发现、执行、错误处理全部协议化，并且从单机进程扩展到跨应用的网络边界。

具体到工程上，最直观的区别是：function calling 的工具列表跟着应用走，应用启动时注册，应用死了就没了；MCP 的工具列表跟着 Server 走，Server 是独立进程，开发完可以给任何支持 MCP 的客户端复用。换句话说，function calling 是“一个应用私有的工具系统”，MCP 是“一套跨应用公共的能力市场”。你在 Cursor 里配好了一个 MySQL MCP，换到 Codex、Cline、Cherry Studio，只要配置文件拷过去、依赖装好，同样的工具马上能用，不需要为每个客户端重新实现一遍工具注册逻辑。

当然，MCP 目前没有完全干掉 function calling。很多 Host 内部依然保留了自己的 function calling 层，MCP 客户端拿到工具列表之后，会把它们翻译成宿主内部能理解的 schema 再交给模型。但这层翻译是内部的，对用户透明。对开发者来说，你只需要写一次 MCP Server，就能辐射到所有主流客户端——这是 function calling 时代无法想象的复用效率。

3.3 MCP 与 Computer Use：语义操作与界面操作的路线之争

Computer Use 是最近很火的方向，OpenAI 的 Computer Use、Anthropic 的 Computer Use 都是让模型像人一样操作屏幕。很多人对比 Computer Use 和 MCP，结论是“Computer Use 让 AI 看屏幕点鼠标，MCP 让 AI 直接调 API”，这个总结大方向没问题，但值得再往深挖一层。

Computer Use 实际上是在模拟人的感知-决策-行动回路，适用于没有 API、没有代码接入权限的遗留系统，比如老旧的 ERP、桌面客户端。它的优势是普适，什么系统都能操作；劣势是慢、贵、误操作率高，每次点击都需要视觉截图、坐标推算，一次误点可能带来灾难性后果。MCP 走的是相反的路：要求系统主动暴露自身能力，以结构化接口呈现给 AI。它不是让 AI 适应一个“人看的界面”，而是让人以外的世界适应 AI 的处理方式。

这两种路线不是替代关系，而是互补关系。接口完善的新系统，优先上 MCP，因为效率高、可靠；实在没有接口的老系统，再考虑 Computer Use 兜底。我见过一个比较成熟的架构是“MCP 为主，Computer Use 兜底”：优先让 AI 尝试通过 MCP Server 完成操作，如果某个环节没有现成接口，再动态唤起一个 Computer Use 的 Agent 去处理这块界面操作。这个思路我觉得在未来很长一段时间都是主流。

4. 自己动手：从零搭一个能“发现能力”的 MCP Server

4.1 从零到一：先选 SDK，再谈设计

理论讲再多，不如亲手搭一个。做 MCP Server 有两种方式：直接用官方 SDK，或者裸写 JSON-RPC 协议。除非你想深入协议细节，否则我都建议用 SDK。官方提供了 Python SDK 和 TypeScript SDK，Python 的FastMCP封装得非常舒服，代码量少，适合快速验证；TypeScript SDK 在前端团队里更顺。我个人日常验证想法用 Python，因为代码最短。

先说一个反面经验：不要一开始就陷入“我要不要自己实现 MCP Server”的纠结。现在主流能力的 MCP Server 基本都有现成的，蓝湖、Figma、MySQL、Playwright 全都有官方或社区版本。你需要自己实现 MCP Server 的场景只有三类：内部系统没有现成接入、需要把多个内部 API 聚合成一个统一能力面、或者要对敏感数据做访问控制。其余时候，优先复用成熟的 Server，把精力花在能力编排上，这才是杠杆率最高的做法。

装好依赖后，MCP Server 的最小骨架长这样：

pip install "mcp[cli]"

用 FastMCP 实现一个最简单的工具：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo-server") @mcp.tool() def add(a: int, b: int) -> int: """计算两个整数之和""" return a + b if __name__ == "__main__": mcp.run()

运行之后，这个 Server 就监听在 stdio 上，任何 MCP 客户端都可以通过标准输入输出和它通信。这段代码少得让人怀疑，但它已经完成了 MCP 协议中最关键的几个动作：定义了能力（add 工具）、暴露了描述（docstring 会被自动转成工具描述）、等待宿主发现（通过 stdio 通信）。

4.2 再加点能力：用 Resource 和 Prompt 构建“能力面”

只写一个 Tool 不足以展示 MCP 的完整设计，我通常会在 Demo 里把三类原语都放进去。下面这个示例模拟一个“项目知识库 MCP”，既有查询工具，也有可供读取的文档资源，还有内置的分析提示模板。

from mcp.server.fastmcp import FastMCP mcp = FastMCP("project-knowledge") DOCS = { "架构文档": "本项目采用前后端分离架构，前端 React，后端 Python FastAPI...", "接口文档": "POST /api/v1/orders 用于创建订单，请求体包含 user_id...", } @mcp.tool() def search_docs(keyword: str) -> list[str]: """根据关键词检索项目文档标题，返回匹配的文档名列表""" return [title for title, content in DOCS.items() if keyword in content] @mcp.resource("docs://{doc_name}") def get_doc(doc_name: str) -> str: """读取指定文档的完整内容""" return DOCS.get(doc_name, "未找到该文档") @mcp.prompt() def doc_analysis(doc_name: str) -> str: """要求模型对某份文档做结构化摘要""" return f"请阅读文档《{doc_name}》，从架构合理性、潜在风险、改进建议三个维度给出分析"

这个 Server 的形态，大家体会一下：Toolsearch_docs让模型可以搜索，Resourcedocs://{doc_name}让模型可以直接获取文档原文，Promptdoc_analysis让模型知道“拿到文档之后该怎么分析”。能力在这里不再是孤立的函数，而是一个有上下文、有方法论的完整体系。

如果只在 Tools 层面做文章，模型往往不知道该读哪份文档，也不知道读完之后该做什么。有了 Resource 和 Prompt，宿主可以先把检索到的文档作为上下文读进窗口，再套上分析模板，最终产出结构化分析。整个过程没有人为写死任何一步，全靠模型在运行时根据能力声明做决策。这就是“能力协议”在实操中的意义：你给的不是一个函数，而是一整套可以被自主调用的能力。

4.3 把 Server 接进 Codex、Cursor、Cline：配置一次，到处复用

Server 写完，接进客户端才是最爽的时刻。拿本地 stdio Server 来讲，主流客户端都会提供 MCP 配置文件入口，形式大同小异。

以 Claude Desktop 和 Cursor 的通用配置为例，你需要在一个 JSON 文件里声明 server 名、启动命令和参数：

{ "mcpServers": { "project-knowledge": { "command": "python", "args": ["/path/to/project_knowledge_server.py"], "env": {} } } }

Cursor 里是在Settings -> MCP里添加，底层会生成同样的配置。Codex CLI 则支持通过命令直接添加：

codex mcp add project-knowledge -- python /path/to/project_knowledge_server.py

Cline（VS Code 插件）则在插件设置里有 MCP 配置面板，填写 server 名、命令、参数即可。配置完重载之后，你会在客户端的工具列表里看到project-knowledge前缀的工具。此时你就可以在对话里直接说“帮我搜一下接口文档里关于订单的内容，然后用文档分析模板做一份评估”，模型会自己决定先调search_docs还是直接读资源。

这里有个需要提醒的点：MCP Server 配置必须保证客户端进程能访问到命令和环境。比如 Codex 跑在 WSL2 里，你装了某个数据库 MCP，客户端在 Windows 侧而 Server 在 Linux 侧，stdio 进程起不来，工具自然注册不上。遇到这种情况，先确认客户端本身就跑在 WSL2 里，再检查 Python/Node 路径，多数问题都出在执行环境不一致，而不是 MCP 协议本身。

4.4 垂直场景举例：不止是代码和数据库

MCP 的应用范围早就超出了代码领域。热词里最常出现的几类，我说一下自己的实际观察：

• 设计协作：Figma MCP、蓝湖 MCP 在国内外设计团队里铺得很快，典型用法是自然语言生成 JS/TS 代码时，模型先从设计稿读取样式和结构，再生成对应前端代码；
• 游戏引擎：Unity MCP、CocosCreator MCP 把场景树、资源列表、组件属性暴露给 AI，模型可以直接说“在场景里创建一个带刚体的立方体，并挂上材质”，引擎侧自动执行；
• 安全分析：BurpSuite MCP、x64dbg MCP、wazuh MCP 这类工具，把原本需要鼠标点击的安全检测和调试动作协议化，AI 可以自动完成请求分析、寄存器查看、告警聚合，这类应用对稳定性和权限控制要求更高；
• 数据与科学计算：MySQL MCP、MATLAB MCP 是老牌工具接入 AI 的样板，数据库 Schema 作为 Resource、增删改查作为 Tool，分析师可以用自然语言完成取数、建模、可视化。

每个垂直领域接入 MCP 时都会面临领域特有的问题，比如 Unity MCP 要处理引擎主线程的调度，MATLAB MCP 要处理计算任务的同步阻塞，安全类 MCP 要严格限制 AI 的自动化权限边界。但共性是一致的：先把领域能力建模成 Tool、Resource、Prompt 三类原语，再接进宿主，让 AI 在协议框架内自主完成任务。

5. 我在实战中踩过的坑和排查方法

5.1 工具注册不上的常见原因

很多人在 Codex 里配 Figma MCP，工具总是注册不上。我排查过不少类似问题，几乎都逃不出三个原因：

第一，Server 进程根本没起来。stdio 类型的 Server 是由客户端负责拉起的，如果你的 Python 或 Node 环境路径不对，或者依赖没装，子进程会静默失败。先手动在终端跑一遍启动命令，确认没有报错。第二，网络型 MCP 的鉴权失败。Figma 的社区 MCP 需要 Personal Access Token 或者 OAuth，token 没有正确配置，Server 即使起来了也无法通过 Figma API 的验证，工具列表就拉不回来。解决方法是先确认 token 权限范围包含File content的读取权限，再检查 Server 日志。第三，Client 和 Server 协议版本不兼容。MCP 还处于快速迭代期，SDK 版本和客户端支持的版本偶有不匹配，表现为握手失败，通常升级双方版本就能解决。

这里给一个排查口诀：先是环境（命令能不能跑），再是鉴权（token 有没有权限），最后才是协议（SDK 版本对不对）。按这个顺序查，90% 的问题能自己解决。

5.2 工具调用超时和上下文溢出

工具挂上了，实际调用时也会出问题，我自己遇到最多的是两类：

一类是长耗时工具的调用超时。比如让 MCP 去跑一个复杂的 MATLAB 计算，或者等一个数据库大查询，模型这一侧的 HTTP 请求可能已经超时了。解决办法是把长任务改造成异步模式：Tool 先返回“任务已提交，任务 ID 为 xxx”，再暴露一个query_task_status(task_id)的工具让模型轮询。这本质上是把同步阻塞调用变成异步任务队列，在 MCP 场景里尤其重要，因为模型对超时非常敏感，等太久它会“自说自话”地编一个结果。

另一类是大资源内容把上下文撑爆。resources/read返回一个几十 MB 的日志文件，Token 会瞬间爆炸。这里需要在 Server 侧做内容裁剪或分页，让资源按块返回，或者先提供摘要工具。我自己的习惯是：凡是要往上下文里塞的内容，Server 一律先做截断或摘要，只返回最关键的部分，模型需要更多细节时再通过工具按需获取。

5.3 Server 不是越多越好

这是我最想提醒新手的一点。很多人看到 MCP 生态丰富，就一口气装了十几个 Server，结果对话时工具列表几十上百个，模型每次决策都要在这堆工具里做选择，既费 Token 又容易选错。而且不同 Server 之间工具同名冲突、权限边界模糊这些问题都会被放大。

我的经验是：单个对话会话内，保持 3-5 个 MCP Server 是体验较好的区间。Cursor、Codex 这类开发场景，通常一个代码库 MCP、一个数据库 MCP、一个设计稿 MCP 就足够了。需要更多 Server 的时候，可以按项目拆分配置文件，不同项目各自只挂相关的 Server。MCP 的配置文件写清楚之后，这些都是低成本操作，没必要让所有 Server 常驻。

还有一个容易忽略的点：MCP Server 的权限问题。MCP 是一个强大的通道，但通道本身没有内置完整的权限审计。一个能操作数据库的 MCP，宿主的提示词注入攻击一旦得手，可能导致数据被删改。所以在设计内部 MCP Server 时，一定要做好三个动作：最小权限原则（Tool 只暴露必需操作）、操作审计（记录每次工具调用）、敏感操作二次确认（比如删除类操作要求模型先调用一个“确认”工具）。这些细节文档里不会写，但生产环境里都是保命用的。

6. 关于 MCP 未来的几点个人判断

回到文章开头的问题：MCP 到底是什么？我再重复一遍我的结论：它是一套能力协议，不是工具调用格式。工具调用只回答“怎么执行”，能力协议回答的是“能力如何被声明、发现、组合、复用”。理解了这一点，你再看 MCP 生态里的各种进展，就会有一个清晰的判断框架。

在协议层面，MCP 未来一定会补上两件事：一是能力编排与会话状态的标准，现在一个 Agent 跨多个 MCP Server 协调任务时，会话状态分散在各 Server 里，缺少统一的上下文协议；二是安全与治理机制，当前的服务发现、鉴权、审计都还比较原始，企业落地时基本都要自己再做一层。这两块补上之前，MCP 更适合“单 Agent + 多工具”的架构，大规模多智能体写作还早了点。

在生态层面，我比较看好两类 MCP Server 的沉淀：一类是垂直领域的高质量能力面，比如把 Figma、蓝湖的设计能力完整建模的 Server，这类需要领域知识深度，构建门槛高，价值也高；另一类是企业内部的“系统连接器”，把内部 OA、CRM、数据库统一暴露成 MCP，让员工通过 AI 助理安全地操作，这类更考验权限设计和合规治理。

最后再分享一个实操层面建议：不要急着把现有 AI 应用的 function calling 全部改造成 MCP。把“必须跨应用复用”的能力抽取成 MCP Server，把“只有一个应用内部使用”的工具继续保留在 function calling，两条腿走路。我见过不少团队雄心勃勃地搞“全量 MCP 化”，结果光迁移成本就吃掉了收益。MCP 的价值在于让能力流动起来，如果能力本身不需要流动，别为了架构的纯洁性引入不必要的复杂度。这一个取舍原则，比 MCP 本身的任何技术细节都更重要。