企业官网建设流程全解析

如果说 2024 年大家还在讨论怎么让 AI 更好地聊天，那 2025 年几乎所有团队都在讨论怎么让 AI 真正干活。干活意味着模型不再只是生成文字，而是要主动去读文件、查数据库、操作浏览器、读取设计稿、调用内部系统。这时候就会出现一个非常实际的工程问题：每接一个新工具，都要重写一遍对接逻辑。我见过很多团队在同一个项目里给不同的工具写不同的 prompt、自定义接口、临时脚本，工具一旦换掉，整套 prompt 和代码全部作废。

MCP（Model Context Protocol，模型上下文协议）就是在这个背景下出现的。它的目标如果用一句话说，不是让模型变得更聪明，而是让模型连接工具的方式从“私有定制”变成“标准插座”。这篇文章想聊清楚一个看起来基础但很多人还没真正理解的问题：为什么我们需要 MCP，而不是继续靠 prompt 或者 function calling 一路写到底。

1. 先理解 MCP 解决的是哪一类混乱

1.1 在 MCP 之前，AI 应用是怎么接工具的

在 MCP 被广泛讨论之前，AI 应用接入外部能力通常有三条路。

第一种是自己写胶水代码。比如要接数据库，就写一个 Python 脚本，把 SQL 查询结果转成文本塞进 prompt。要接 Figma，就调 Figma API，把图层数据拉下来整理成 JSON。这种方式能跑通，但每接一个数据源就要写一套新的解析逻辑，而且这套逻辑往往只属于当前项目，换一个客户端、换一个模型就要重写。

第二种是依赖模型的函数调用能力。以 OpenAI 的 function calling 为例，开发者需要在请求里传入一个 tools 列表，定义每个函数的参数 schema，模型根据用户的输入决定调用哪个函数，然后你拿到函数名和参数再去执行。这个方案比起裸写 prompt 已经规范很多，但仍然有一个无法回避的问题：工具的发现和注册完全靠开发者在代码里手动维护。每新增一个工具，就要改代码、发版、更新 schema。工具数量一多，维护成本迅速上升。

第三种是干脆把工具的用法写进 prompt。让模型“知道”有某个工具，然后期望模型在合适的时候按照格式输出调用指令。这种方式对小规模实验很灵活，但它本质上是在用提示词工程对抗工具复杂度。当工具参数特别多、返回结果特别长、状态来回切换的时候，这种方案会变得不可控。

1.2 MCP 的真正切入点：不是能力，是标准化

MCP 要解决的问题，不是“模型能不能调用工具”，而是“工具应该如何被模型调用”。

你可以把 MCP 理解为 AI 应用和外部工具之间的一层统一协议。它规定了工具提供方要如何暴露能力、工具使用方要如何发现和调用这些能力、数据响应要用什么格式返回。这样一来，同一个 MCP server 可以被任何支持 MCP 的客户端使用，同一个客户端也可以接入任意符合协议的 server。

这才是 MCP 的关键价值。它没有发明“让 AI 调用工具”这件事，它发明的是“让所有工具用同一种方式被 AI 调用”的约定。就像 USB 之前，各种外设都有自己的接口，游戏手柄有游戏手柄的接口，鼠标有鼠标的接口，打印机有打印机的接口。MCP 的目标是：以后 AI 要接任何设备，只需要认准同一个协议。

所以，如果只看单一场景，你完全可以不用 MCP。你自己写一段脚本调一个 API，速度更快、依赖更少。但当你面对的是十几个工具、多个客户端、不断新增的业务系统时，没有标准就意味着每一次接入都是一次新的集成开发。

1.3 一个最小体系里的三个角色

理解 MCP 之前，先把三个角色弄清楚。

• Host：运行 AI 应用的宿主程序。常见的就是 Claude Desktop、Codex、Cline、各类 IDE 插件。它负责持用户会话、调用模型、展示结果。
• Client：在 Host 内部建立与 MCP server 连接的客户端。它负责维护连接、发送请求、接收响应。通常一个 Host 会内嵌一个或多个 Client。
• Server：真正的工具提供方。它把文件系统、数据库、设计稿、浏览器、任务追踪系统等能力封装成标准接口，向外暴露。

Server 和 Client 之间通过 MCP 协议通信。协议内容不是自然语言，而是结构化的 JSON-RPC 消息。Server 可以运行在本地，也可以部署在远程服务器上。本地运行最常见的启动方式是通过命令行拉起一个子进程，使用 stdio 通信；远程服务则通常使用 HTTP 或 SSE。

一个常见的误解是：MCP Server 必须很复杂，必须用某个特定框架。其实它只是一个轻量进程，负责把工具能力包一层标准接口。真正复杂的是 Server 背后的业务逻辑，比如怎么安全地操作文件、怎么查询数据库，这些才是工程重心。

2. MCP 的设计逻辑：它像 AI 世界的 USB-C

2.1 三种原语：Tools、Resources、Prompts

MCP 协议中心不是一堆复杂配置，而是三个核心原语。

Tools 是最直观的能力单位。它对应一个可执行的动作，比如“读取某个 Figma 文件”、“执行某条 SQL”、“点击浏览器里的某个按钮”、“发布一条 Jenkins 构建”。模型可以在对话过程中主动决定调用这些工具，调用时需要按照 server 定义的输入 schema 传入参数，执行完成后拿到结构化结果。

Resources 是数据源。它代表可读取的内容，比如一个文件、一张表、一个设计稿节点、一份日志。和 Tools 的区别在于，Resources 通常是“只读的数据”，不需要让模型执行副作用操作。客户端可以把 Resources 内容直接作为上下文传给模型，相当于把外部数据“粘”进对话。

Prompts 是可复用的提示模板。它用于把某个任务的执行方式固化成标准流程。比如服务器可以提供一个 “review 设计稿” 的 prompt 模板，客户端拿到后，会把这段指令和相关的 resource 一起组合成上下文。

这三个原语合起来，其实覆盖了 AI 应用最常见的三类需求：读数据、执行动作、按既定流程处理任务。这也是 MCP 和单纯的 function calling 体系之间一个很重要的差异。function calling 基本只解决“模型发起一个调用”的问题，而 MCP 把可发现能力、数据读取、模板治理一起做了。

2.2 两种传输方式：stdio 和 HTTP

MCP 在实际部署中主要有两种传输方式，选择方式会影响使用体验和运维复杂度。

stdio 方式最常见于本地开发场景。客户端启动一个子进程，比如npx某个 server 包，然后通过标准输入输出和这个进程通信。好处是配置简单，不需要开端口、不需要处理网络攻击面，tool server 和 AI 客户端在同一个机器上，权且只对本机操作可见。缺点是 server 必须能在这台机器上跑起来，而且无法直接服务多个远程用户。

HTTP/SSE 方式用于远程 server。比如团队里部署一个统一的 MCP server，供多人使用。这种方式把工具能力变成网络服务，可以集中管理权限、日志、更新策略。但同时要处理认证、限流、超时、TLS 等一系列网络问题，复杂度比本地 stdio 高不少。

从实际落地看，先跑本地 stdio server 是体验 MCP 最快速的方式。很多团队一开始也会把 shared server 先在本机验证，再部署到内网。不要一上来就架远程服务，否则排查问题时多了一层网络故障变量。

2.3 工具发现机制为什么是关键

一个经常被忽略但极其重要的设计是 “tools/list” 这类能力发现机制。

传统 function calling 方案里，工具列表是开发者硬编码在请求参数里的，模型只知道代码里给它的那些函数。MCP 则不同，server 可以动态地声明自己提供哪些工具、每个工具的参数 schema 是什么、需要什么权限。客户端启动时先向 server 发送工具列表请求，拿到全部可调用工具后再决定后续怎么路由。

这种动态发现机制带来的变化是：新增一个工具只需要改 server 而不需要改客户端。比如同一个 MCP server 今天提供了一个查询工具，明天又加了一个写入工具，AI 客户端启动后自动感知，不需要重新发布客户端版本。对于有大量工具、频繁上线的团队来说，这是非常重要的工程收益。

所以 MCP 的价值可以总结成一句话：它把 AI 应用和工具之间的耦合度，从“代码级绑定”降到了“协议级发现”。这也是为什么很多人形容它像一个标准插座，插上就能用，不用管内部是显示器还是硬盘。

3. MCP 和 Function Calling、Skill 不是一回事

3.1 MCP 与 Function Calling：一个关于插座，一个关于供电

很多人会把 MCP 和 function calling 混在一起，甚至以为两者是对立关系。理解它们最简单的方式是：function calling 是模型侧的能力，MCP 是工具侧的连接协议。

function calling 解决的是：模型如何在生成回复的过程中，决定调用一个函数，并输出结构化的参数。它是由模型提供商定义的 API 特性。比如 OpenAI、Anthropic、Google 各自的 function calling 格式就不完全一致。

MCP 解决的是：工具如何被 AI 客户端发现、连接和调用。它不关心模型具体怎么决策，它只保证工具在协议层面用统一的方式暴露。

所以你可以用 MCP 来替换掉项目里手工维护 function schema 的那部分工作。尤其是当你同时接 Anthropic、OpenAI、本地模型等多个模型时，MCP 能帮你把工具层抽象成一份，避免为每个模型各写一套 function 描述。

3.2 MCP 与 Skill：一个是能力接口，一个是使用说明书

最近很多平台都在提 Skill，比如 Claude 的 Agent Skill，或者各类 Agent 框架里的技能概念。于是出现了大量搜索“agent skill 和 mcp 有什么区别”的人。

Skill 的核心是“怎么做”，它把完成某个任务所需的指令、步骤、判断逻辑、可能用到的工具调用方法封装成一份可复用的知识包。比如一个 “代码 review skill”，会告诉模型应该先看 diff、再检查是否有安全风险、最后按什么格式输出意见。它更多是在 prompt 层操作。

MCP 的核心是“能做什么”，它提供一个工具能力的外部入口。它不承诺模型会怎么用这个工具，也不负责教你“什么时候该用这个工具、用完后怎么整理结果”，它只负责让这个工具能被标准调用。

所以两者完全不是替代关系。MCP 把工具变成可以插拔的电源插座，Skill 更像一本设备使用手册。真正完整的 Agent 工作流通常是：Skill 指导模型接下来该怎么处理任务，MCP 在执行过程中提供能力调用。

我见过很多团队一开始只做 MCP，给模型塞了一堆工具，结果模型经常在错误的时机调用。后来又补了 Skill 来框定流程，效果才稳定下来。原因就是：光有工具没有流程，Agent 很容易像第一次进厨房的人，什么厨具都有，但不知道先开火还是先切菜。

3.3 一个组合使用框架

如果你正在设计一个接入 AI 的完整工具方案，可以按这个顺序判断：

• 如果你的需求是 “模型要能执行某个动作”，优先考虑 MCP Server 提供 Tools。
• 如果你的需求是 “模型要把某些外部数据读进上下文”，优先考虑 MCP Server 提供 Resources。
• 如果你的需求是 “按固定流程处理一类任务，不希望每次重新写指令”，优先考虑 Skill 或 MCP Prompts。
• 如果你的需求是一次性实验、只调一个私有 API，直接写几行代码可能比引 MCP 更快。

这个框架不算发明，但它能避免一个常见误区：遇到 Agent 工具化，什么都往里塞 MCP。适不适合用 MCP，关键看“这个工具是否会被多个客户端复用”、“是否存在长期维护成本”、“是否需要统一的能力发现和变更机制”。如果三个问题都是否，那 MCP 就有点杀鸡用牛刀了。

4. 从 Figma MCP、Playwright MCP 看真实落地价值

4.1 为什么设计稿、浏览器、数据库是最先爆发的场景

如果你去看当前热门的 MCP server 清单，会发现几个反复出现的品类：Figma MCP、Playwright MCP、数据库类的 MCP（比如 Chat2DB 这类把数据库能力暴露给 AI 的服务）、文件系统 MCP、DevOps 类 MCP。

这些场景有一个共同点：它们的操作对象是结构化的、机器可读的。

拿 Figma 举例。前端工程师拿到设计稿后，要反复查看颜色、间距、组件命名、切图资源。过去让 AI 帮忙理解设计稿，你需要手动把截图发给它，或者写脚本去调 Figma 的 REST API。而 Figma MCP server 把“读取设计稿节点”、“获取样式信息”、“查找图层”等能力封装成 Tools，AI 客户端可以直接调用。整个链路变成：AI 通过 MCP server 读取设计稿数据，再结合前端代码生成需求，输出可落地的修改建议。

Playwright MCP 的思路也类似。它把浏览器自动化能力暴露给模型，模型可以自己打开页面、点击按钮、读取控制台日志、截图。这对自动化测试、页面回归、Bug 复现场景很有价值，因为原本需要人逐步操作浏览器验证的事情，现在可以由模型按步骤执行。

数据库类的 MCP 则更直接，它把 SQL 查询能力封装成工具，AI 可以根据用户的自然语言描述生成并执行查询。不需要再把查询结果复制粘贴进对话。

4.2 常见落地形态：读取数据 vs 执行操作

使用 MCP 时，要区分两类工具：

一类是只读型工具。比如读取设计稿、查询数据库、获取文件内容。这类工具相对安全，模型调用后只产生读取行为，风险主要是数据暴露范围。

另一类是写操作型工具。比如发送消息、发布部署、写入文件、修改配置。这类工具会改变外部系统状态，风险明显更高。模型一旦误调用，可能造成不可逆影响。

所以在接入真实业务时，我建议先对照明这两类。对于写操作型工具，初期至少要加一层确认机制。很多 MCP 客户端已经有“工具调用前等待用户确认”的设置，不要为了追求全自动就关掉它。等模型在特定场景下的调用准确率足够高，再考虑逐步放开。

4.3 工具注册不上怎么办：一条排查链路

最近常见的一个问题是 “Figma MCP 在 Codex 中总是工具注册不上”，很多人在网上问。这类问题本质上不是某一个 bug，而是一条链路上的多个环节需要逐一检查。

建议排查顺序：

1. 先确认 MCP server 本身能在命令行单独启动。直接运行配置里的启动命令，看是否报错。
2. 再确认客户端配置文件的路径、命令、参数是否准确。不同操作系统对 npx、node、python 的引用路径不一样，尤其是 Windows 系统，配置里经常需要指定具体的可执行文件路径。
3. 然后看客户端有没有成功发起 tools/list 请求。如果请求没有返回，问题多半在连接建立阶段。
4. 如果 tools/list 返回成功，但模型仍然说找不到工具，可能是客户端缓存或模型上下文没有刷新。重启客户端再试一次。
5. 如果 server 返回了工具但调用报错，要检查输入参数 schema 是否与实际情况匹配，以及 server 依赖的外部服务是否可用。比如 Figma MCP 通常需要配置 Figma access token，token 没有权限，工具能发现但不能成功读数据。

这里面最容易蒙蔽人的是第二步。很多人改了命令，发现还是没有效果，就开始怀疑协议有问题。其实首先要确认配置里的命令在 shell 里能否直接跑通，然后再去排查客户端。

4.4 那些容易忽略的 Schema 细节

还有一个从热词里能看到的经典问题：MCP Tools 的 InputSchema 是否支持类型嵌套？

答案在协议层面是支持的。MCP 工具的参数使用 JSON Schema 描述，自然支持嵌套对象、数组、枚举等结构。比如一个工具需要传入 { filters: [{ field, operator, value }] }，这种复杂结构可以被完整描述。

但要注意，不同客户端的兼容性并不同。有些客户端在处理嵌套 schema 时，可能无法正确解析复杂的组合关键字，或者生成 UI 表单时表现不佳。在工具设计上，尽量保持输入参数平坦化，如果必须嵌套，请先用支持 MCP 的客户端做实测，不要想当然觉得协议支持就一定没问题。

5. 自己跑通一个最小 MCP 流程

5.1 环境准备

体验 MCP 不需要太复杂的工程环境。常见准备是：

• Node.js 或 Python 3.10+ 环境，取决于你想用哪种 SDK。
• 一个支持 MCP 的客户端。常见的有 Claude Desktop，VSCode 里的 Cline、Continue 等插件，或者 Codex。
• 一个简单的 MCP server 示例。

如果你选择 Python 方式，需要先安装 MCP SDK。具体安装命令以对应 SDK 的官方文档为准，这里不做版本绑定的假设。

5.2 写一个最小 MCP Server

下面是一个极简 MCP server 的示例结构，用 Python 风格展示，目的是理解“把函数暴露成工具”这一过程。

from mcp.server import Server from mcp.server.stdio import run_server from mcp.types import Tool, TextContent server = Server("demo-server") @server.list_tools() async def list_tools(): return [ Tool( name="get_current_time", description="返回当前时间，用于演示 MCP 工具调用", inputSchema={ "type": "object", "properties": {} } ) ] @server.call_tool() async def call_tool(name: str, arguments: dict): if name == "get_current_time": from datetime import datetime now = datetime.now().isoformat() return [TextContent(type="text", text=f"当前时间是 {now}")] raise ValueError(f"未知工具: {name}") if __name__ == "__main__": run_server(server)

这段代码只做三件事：声明工具列表、定义工具行为、在 stdio 上启动服务。真实的 server 会复杂很多，但这个骨架足够让你看到 MCP 的核心结构。

5.3 配置客户端并验证

要让客户端发现这个 server，需要在客户端配置里添加一条记录。不同客户端格式不一样，常见思路是配置命令和参数。比如：

{ "mcpServers": { "demo": { "command": "python", "args": ["path/to/server.py"] } } }

配置完成后，重启客户端。正常情况下，客户端会启动这个进程并通过 stdio 获取工具列表。你可以在对话里问 “当前时间是多少”，如果配置正确，模型会调用你刚写的 get_current_time 工具，而不是凭空回答一个时间。

5.4 从最小流程到真实业务：先跑通，再工程化

最小流程跑通后，不要急着写几十个工具。更稳妥的节奏是：

1. 先在一个 server 里只暴露 1 到 2 个核心工具。
2. 用真实数据和真实客户端跑完整个调用链路。
3. 确认输出、日志、错误处理都符合预期。
4. 再逐渐增加工具数量。

你之后会发现，MCP 的接入难点从来不是写一个简单工具，而是：工具变多之后，schema 冲突怎么处理；调用失败时，客户端怎么回退；长耗时工具怎么处理超时；写操作怎么加确认。这些才是工程化要解决的事。

注意：不要一上来就写 50 个工具。工具数量越多，模型的选择难度越大，误调用概率也会明显上升。先让模型在少量工具上形成稳定表现，再加量。

6. 生产环境使用 MCP，真正要关心的五件事

6.1 权限与信任边界

MCP server 拥有的能力，可能比普通 API 大得多。它可以读本地文件、执行命令、连接内网服务。模型一旦被注入恶意指令，或者获得了过大的工具权限，风险是实际的。

所以在生产环境里，要严格管控 MCP server 的权限边界。比如使用独立的低权限账号运行 server；限制它只能读取必要的目录；禁止它访问非相关端口；对每一个新接入 server 做代码和依赖审计。

6.2 资源暴露范围

当你给模型提供一个读文件工具时，你实际上把什么范围的文件暴露给了模型？如果 model 可以任意读取整个磁盘的路径，那么对话历史里的“灵感”和“提示注入”都可能成为数据泄露入口。

建议做法是给文件类工具设置明确的根目录白名单，数据库类工具限制只能执行 SELECT，设计稿类工具限制只读当前项目的文件。不把整个系统的可见面一次性交给模型。

6.3 日志与可观测性

AI 应用和传统服务的最大不同是：模型的行为难以完全预测。它可能在某个时刻调用了一个你没想到的工具，传入了你没预料到的参数。这种不确定性要求 MCP server 必须有完善的日志。

日志里至少要记录：谁发起了调用、调用的是哪个工具、传入什么参数、返回什么结果、调用耗时、是否失败、错误原因。如果没有日志，一旦模型误操作，你只能看到结果已经发生，却无法回溯过程。

6.4 并发、超时与错误重试

MCP server 在处理并发请求时，需要关注两件事：一是资源竞争，二是超时控制。

如果一个 server 同时被多个 AI 客户端使用，而它本身是无状态设计，问题不大。但如果它内部依赖数据库连接池、临时文件、限流器等有状态资源，就需要认真处理并发冲突。另外，模型调用工具的时长不确定，工具内部一旦卡死，客户端可能一直等待。服务端应设置合理的超时时间，并对失败任务提供可理解的错误信息。

6.5 版本锁定与依赖管理

MCP 作为一个新协议，演进速度非常快。今天能用的配置，明天客户端升级后可能就变了。为了避免线上服务突然不可用，需要在项目里固定 server 的版本、客户端版本和对应配置。

给团队的内部 MCP server 建立 CI/CD 流程，每次改动都跑一遍工具发现和最小调用测试。不要只依赖外部 server 的最新版，必要时要 fork 或者锁定版本，保持环境可复现。

7. 回到最初的问题：我们到底为什么需要 MCP？

7.1 AI 从对话走向做事，连接层必须标准化

把视野拉长一点看， MCP 之所以在 2025 年成为高频词，是因为 AI 产品的形态正在从“chatbot”走向“agent”。Chatbot 只要处理文字，不需要碰外部世界；Agent 要真正完成任务，就必须操作外部系统。一旦涉及外部系统，就会出现无数种接口、权限、数据格式的组合。

如果我们回到一年前，一个团队要接 Figma、Postgres、Jira、GitHub Actions、浏览器自动化，大概需要写 5 套独立的集成代码。每套代码都要单独维护、单独更新、单独测试。而当它们都变成 MCP server 后，AI 客户端只需要学会一种协议，新增工具只是增加一条 server 配置。

这才是 MCP 的根本价值。它把“连接工具”这件事从项目级定制变成了基础设施级标准。理解了这一点，你就不需要问“MCP 能做什么”，而要问“当所有工具都标准化之后，AI 应用的上限在哪里”。

7.2 什么样的人现在不需要 MCP

虽然 MCP 热度很高，但它不是所有场景的银弹。

如果你只是在做一次性脚本，让 AI 调一个私有 API，不需要多个客户端复用，那直接写代码或者写一段 function calling 完全足够。它更快、更可控。如果你只需要简单的 webhook 触发，也没有必要为了所谓标准去套 MCP。

另外，如果你的团队还没有跑通单个 Agent 任务，先不要急着接一堆 MCP server。一个常见的失败模式是：工具接了很多，模型反而不知道该用什么，任务准确率下降。先把单个核心场景跑通，再逐步增加工具，是更稳妥的顺序。

7.3 下一步怎么开始

如果你看完这篇文章，认同 MCP 的核心价值，那下一步最该做的是找一个小场景做一次端到端验证。

我建议从这三个选项里选一个：文件系统读取、数据库查询、设计稿或浏览器工具。这三个方向最容易看到效果，也最容易暴露配置、权限、schema、日志问题。选一个你日常工作里高频但是重复性强的工具，用 MCP server 包起来，然后让 AI 客户端调用它，跑真实任务。

跑通之后你会有两个感受：一是原来几天的集成工作被压缩成了几十分钟的配置；二是真正的问题不在能不能调用，而在怎么让调用边界清晰、安全、可追踪。而这两点，恰好就是 MCP 在接下来一年里会不断变厚的地方。