面向程序员 · AI 工程连接协议课

MCP：AI 的标准连接协议

MCP 全称 Model Context Protocol。它不是一个模型，也不是一个数据库，而是一套让 AI 应用连接外部数据、工具和工作流的开放协议。可以把它理解成 AI 应用的“标准连接层”：Host 负责使用，Client 负责连接，Server 负责提供能力。

它标准化连接 AI 应用不用为每个工具单独写一套接入方式。

它标准化发现 Client 可以通过协议知道 Server 暴露了哪些 tools、resources 和 prompts。

它标准化调用 工具调用、资源读取、提示模板获取都有统一方法和消息格式。

它不替代风控 协议提供连接方式，权限、审批、数据保护仍要由实现方认真设计。

Model Context Protocol JSON-RPC

AI Host Chat、IDE、Agent 平台

→

MCP Client 一条连接，一个 Server

MCP Server 暴露数据、工具、模板

→

企业系统 知识库、数据库、API、工作流

Tools
执行动作

Resources
读取上下文

Prompts
复用流程

01 · 先给定义

MCP 是 AI 应用连接外部世界的标准协议

大模型本身只会处理输入和输出。企业应用需要文件、数据库、接口、搜索、工单、权限和审批。MCP 解决的就是“AI 应用怎么用统一方式接这些外部能力”。

Context

提供上下文

把文档、数据库记录、代码文件、配置说明等资料，以可发现、可读取的方式提供给 AI 应用。

Tools

提供工具

把查询订单、搜索代码、创建工单、调用 API 这类能力暴露成模型可调用的工具。

Workflow

提供流程模板

把常见任务封装成 prompt 模板，例如“生成周报”“排查线上错误”“写需求 PRD”。

Standard

统一接入方式

同一个 MCP Server 可以被多个支持 MCP 的客户端复用，降低重复集成成本。

一句话面试版 可直接背

MCP 是一套开放连接协议，让 AI 应用用统一方式连接外部数据源、工具和工作流。它用 Host、Client、Server 的架构组织连接，用 JSON-RPC 传消息，并通过 Tools、Resources、Prompts 等能力把外部系统提供给 AI 使用。

02 · 解决的问题

没有标准协议，AI 接系统会变成一堆定制胶水代码

企业里不止一个 AI 应用，也不止一个业务系统。如果每个客户端都单独接每个系统，后续维护、权限治理和复用都会很麻烦。

没有 MCP

每个应用各接各的

聊天机器人接知识库一套逻辑，IDE 接代码库一套逻辑，Agent 平台接工单系统又写一套。工具描述、参数 schema、鉴权、日志都散落在不同项目里。

有 MCP

Server 统一暴露能力

知识库、代码库、工单系统分别做成 MCP Server。不同 AI Host 通过标准协议发现和使用能力，治理策略也更容易集中。

程序员视角的价值 落地

1复用：一个 Server 可以服务多个支持 MCP 的客户端。
2解耦：AI 应用不用关心每个后端系统的私有接入细节。
3治理：工具、资源、权限、日志可以按统一边界管理。
4生态：外部系统只要实现协议，就更容易被不同 AI 应用使用。

03 · 三类角色

Host 管全局，Client 管连接，Server 提供能力

理解 MCP 架构时，先记住这句话。Server 不是一定指云服务器，它可以是本机进程，也可以是远程服务。

Host

用户正在使用的 AI 应用

例如聊天客户端、IDE、Agent 平台。它负责管理用户会话、模型上下文、多个 MCP 连接和最终交互体验。

Client

Host 内的一条连接

通常一个 MCP Server 对应一个 MCP Client。Client 负责初始化、能力协商、收发 JSON-RPC 消息。

Server

提供上下文和能力的一方

Server 暴露 tools、resources、prompts。它背后可以连接文件系统、数据库、业务 API 或工作流平台。

一个 Host 例如企业 AI 助手，负责用户界面、模型调用和上下文编排。

→

多个 Client 分别连接知识库 Server、订单 Server、代码库 Server。

多个 Server 每个 Server 只负责自己领域内的能力，不把所有业务塞到一个入口里。

→

多个外部系统 数据库、API、文档、搜索引擎、消息系统、工单系统。

04 · 两层结构

MCP 可以拆成数据层和传输层

这样讲比较清楚：数据层规定“说什么话”，传输层规定“用什么通道说”。同一套 JSON-RPC 消息，可以跑在不同传输方式上。

Data Layer

协议语义层

定义 JSON-RPC 消息、生命周期管理、能力协商、tools、resources、prompts、notifications、progress、logging 等语义。

Transport Layer

通信通道层

定义 Client 和 Server 之间怎么传消息。常见方式是本地 stdio 和远程 Streamable HTTP，也可以扩展自定义传输。

为什么这点重要 理解协议

如果你做本地文件系统 MCP Server，可能用 stdio；如果你做企业云端知识库 MCP Server，可能用 Streamable HTTP 和 OAuth。传输方式不同，但上层依然是 MCP 的方法、能力和消息结构。

05 · 核心能力

Server 最常暴露三类能力：Tools、Resources、Prompts

这三类能力很容易混。Tools 是动作，Resources 是资料，Prompts 是模板。面试时把控制权讲清楚，会显得很专业。

Tools

模型可调用的动作

例如查询订单、搜索代码、创建工单、调用数据库查询。通常由模型根据用户意图决定是否调用，但执行前仍要经过 Host 的控制。

Resources

应用可读取的上下文

例如文件内容、数据库 schema、API 文档、知识库片段。它更像资料入口，应用可以选择是否放进模型上下文。

Prompts

用户可选择的流程模板

例如“生成 PRD”“总结会议”“排查故障”。它把一组提示词、参数和工作流入口标准化。

控制权速记 别混

能力	更像什么	常见控制方	典型方法
`Tools`	可执行函数	模型请求，Host 审批	`tools/list`、`tools/call`
`Resources`	可读取资料	应用选择和展示	`resources/list`、`resources/read`
`Prompts`	可复用任务模板	用户主动选择	`prompts/list`、`prompts/get`

06 · 生命周期

连接不是一上来就调用工具，先要握手和协商

MCP 是有状态协议。Client 和 Server 建立连接后，需要初始化、协商协议版本和能力，然后才能发现和使用能力。

1 启动连接 Client 启动本地 Server，或连接远程 MCP endpoint。

2 Initialize 双方交换协议版本、clientInfo、serverInfo 和能力声明。

3 发现能力 Client 调用 tools/list、resources/list、prompts/list。

4 使用能力 读取资源、获取 prompt、调用工具，并处理返回结果。

5 通知和关闭 处理能力变更、进度、取消、日志，以及连接终止。

initialize message JSON-RPC

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "enterprise-ai-assistant",
      "version": "1.0.0"
    }
  }
}

07 · 传输方式

本地常用 stdio，远程常用 Streamable HTTP

传输方式决定消息怎么走。做面试回答时，能讲出两者适用场景和安全注意点就够用了。

stdio

适合本地进程

Client 启动 MCP Server 子进程，通过 stdin 和 stdout 传 JSON-RPC。适合本地文件、命令行工具、开发机环境。关键点是 stdout 只能输出合法 MCP 消息，普通日志应写到 stderr。

Streamable HTTP

适合远程服务

Server 作为独立 HTTP 服务运行，Client 通过统一 MCP endpoint 发送 POST，也可以用 SSE 接收流式消息、通知和长任务进度。远程场景要重点处理认证、会话和来源校验。

选择建议 工程判断

1本地工具、文件系统、开发机自动化，优先考虑 stdio，简单、快、无网络开销。
2企业共享服务、云端知识库、跨团队复用，优先考虑 Streamable HTTP。
3远程 HTTP Server 要做认证、Origin 校验、会话管理、限流和审计。

08 · 消息示例

MCP 消息本质上是结构化的 JSON-RPC 请求和响应

不需要死背所有方法。先看懂 tools/list、tools/call、resources/read 这几个常用动作，协议就不神秘了。

discover tools tools/list

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "kb_search",
        "title": "搜索企业知识库",
        "description": "按关键词检索制度、接口文档和产品需求",
        "inputSchema": {
          "type": "object",
          "required": ["query"],
          "properties": {
            "query": { "type": "string" }
          }
        }
      }
    ]
  }
}

call tool tools/call

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "kb_search",
    "arguments": {
      "query": "商品导入失败原因"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "找到 3 篇相关文档：导入任务、错误码、字段校验规则"
      }
    ]
  }
}

读消息时抓三件事 方法

1method 表示要做什么，例如 tools/list 或 tools/call。
2params 是调用参数，必须按 schema 校验。
3result 是返回结果，最终回答要基于这个结果，不能凭空补充。

09 · 概念区分

MCP 不是 API、不是 RAG、也不是 Agent 本身

这几个词经常被混用。面试时把边界讲清楚，比背定义更重要。

MCP vs API

API 是服务接口，MCP 是 AI 连接协议

API 面向业务系统调用方；MCP 面向 AI 应用，标准化能力发现、资源读取、工具调用和提示模板。

MCP vs RAG

RAG 是知识问答方案

RAG 重点是检索资料再回答；MCP 可以给 RAG 暴露知识库资源，也可以暴露工具和工作流。

MCP vs Tool Calling

Tool Calling 是模型调用动作

MCP 可以把工具以标准方式暴露给 AI 应用；Tool Calling 更偏模型如何选择和调用某个工具。

MCP vs Agent

Agent 是任务执行者

Agent 负责规划、执行和反思；MCP 是 Agent 可用的连接层，让它能接外部数据和工具。

一句话总结边界 清晰

API 是路，RAG 是查资料的办法，Tool Calling 是模型请求动作的机制，Agent 是执行任务的主体，MCP 是把外部能力标准化接进 AI 应用的协议。

10 · 设计方法

设计 MCP Server，要先划清领域边界

不要一上来就写代码。先决定 Server 服务谁、连接什么系统、暴露哪些能力、哪些动作需要确认、哪些数据不能出边界。

1 确定场景 例如“企业知识库问答”“订单售后助手”“研发代码检索”。

2 划分能力 哪些是 tools，哪些是 resources，哪些可以做成 prompts。

3 设计 schema 工具参数、资源 URI、prompt 参数都要可校验、可描述。

4 设计权限 按用户、租户、角色、数据域控制访问和动作。

5 接入观测 记录连接、调用、错误、耗时、结果摘要和 traceId。

企业知识库 MCP Server 草图 示例

能力	设计
Tools	`kb_search`、`doc_summarize`、`find_owner`
Resources	`kb://doc/{docId}`、`kb://space/{spaceId}/index`
Prompts	`write_prd_from_docs`、`compare_policy_versions`
Policy	按租户、部门、文档密级、用户角色过滤

resource template 示例

{
  "uriTemplate": "kb://doc/{docId}",
  "name": "knowledge-document",
  "title": "企业知识库文档",
  "description": "按文档 ID 读取当前用户有权限查看的文档内容",
  "mimeType": "text/markdown"
}

11 · 安全和授权

MCP 能接数据和执行工具，所以安全必须前置

MCP 只是协议，不能自动替你解决权限、隐私和审批。真正上线时，Host、Client、Server 都要承担安全责任。

用户同意

数据和动作要可确认

用户应该知道 AI 将访问哪些资料、调用哪些工具、执行什么动作。

数据隐私

最小化共享

不要把完整数据库或敏感文档直接丢给模型。按权限、范围和必要性提供上下文。

工具安全

高风险动作要审批

写数据、发消息、删除文件、提交审批这些工具，必须有确认、幂等和审计。

远程授权

HTTP 场景要认真做认证

远程 MCP Server 要考虑 OAuth、Token 作用域、Origin 校验、会话管理和限流。

推荐做法

1工具分级：只读工具、低风险写工具、高风险写工具分别治理。
2按当前用户身份执行，不允许模型绕过企业权限系统。
3远程服务校验 Origin，避免本地或内网 MCP 被恶意网页探测。
4所有工具调用记录 traceId、用户、参数摘要、结果和耗时。

危险做法

1把 MCP Server 当成万能后门，绕过原有业务权限。
2让模型自由决定退款、删除、发外部邮件等高风险动作。
3把工具描述、返回内容完全当真，不做服务端校验。
4HTTP Server 直接监听所有网卡，不做认证和来源校验。

12 · 调试和观测

MCP 出问题，要沿着连接链路排查

常见故障不是“模型不聪明”，而是 Server 没启动、能力没注册、schema 写错、权限失败、返回格式不稳定或 stdout 混入了普通日志。

01 连接成功率

Server 是否启动，初始化是否完成，协议版本是否协商成功。

02 能力发现率

tools/list、resources/list、prompts/list 是否返回预期能力。

03 调用成功率

tools/call 是否通过校验、权限、下游 API 和超时控制。

04 回答忠实度

模型最终回答是否基于 MCP 返回结果，而不是自己补内容。

排查顺序 Debug

1先看 Host 配置：Server 命令、URL、环境变量、权限凭证是否正确。
2再看初始化日志：initialize 是否成功，capabilities 是否符合预期。
3接着看能力列表：工具名、描述、inputSchema 是否准确。
4最后看调用链路：参数、权限、下游响应、返回格式、模型最终回答。

13 · 企业案例

用 MCP 做“产品需求资料助手”

这个案例和需求 PRD、RAG、Tool Calling 都能串起来，适合面试讲企业落地。

业务场景 产品经理输入“商品批量导入失败后如何给用户展示明细，并生成一版 PRD”。

MCP Resources 读取现有产品文档、接口文档、错误码说明、权限规范和历史 PRD。

MCP Tools 调用 kb_search 检索资料，调用 api_schema_lookup 查接口字段，调用 owner_lookup 查负责人。

MCP Prompts 使用 write_prd_from_docs 模板，把资料整理成背景、目标、流程、字段、异常和验收标准。

server capability sketch MCP 设计草图

Server: product-docs-mcp

Resources:
  kb://product/import/current-prd
  kb://api/product-import/schema
  kb://policy/permission/product-admin

Tools:
  kb_search(query, spaceId)
  api_schema_lookup(apiName)
  owner_lookup(domain)

Prompts:
  write_prd_from_docs(topic, audience, outputLevel)
  compare_old_new_requirement(oldDocId, newTopic)

这个案例的关键点 面试友好

MCP 不是直接“生成 PRD”的魔法。它先把企业资料、接口、负责人、模板用标准协议暴露出来，再让 AI 应用在权限范围内读取和调用，最终基于真实资料生成 PRD。

14 · 面试问答

回答时先讲价值，再讲架构，最后讲安全

面试官问 MCP，通常不是想听你背文档，而是看你能不能把 AI 连接企业系统这件事讲清楚。

Q1：MCP 是什么？

A：MCP 是 Model Context Protocol，是一套让 AI 应用连接外部数据、工具和工作流的开放协议。它用 Host、Client、Server 的架构组织连接，用 JSON-RPC 传消息，让 AI 可以标准化发现和使用 Tools、Resources、Prompts。

Q2：为什么需要 MCP？

A：因为企业里 AI 应用很多，业务系统也很多。如果每个应用都单独接每个系统，会产生大量重复集成。MCP 把连接方式标准化，让外部能力可以被多个 AI 客户端复用，也更容易做权限、日志和治理。

Q3：MCP 的 Host、Client、Server 怎么理解？

A：Host 是用户使用的 AI 应用，比如聊天客户端或 IDE；Client 是 Host 里负责连接某个 Server 的组件；Server 是提供上下文和能力的一方，可以暴露工具、资源和提示模板。通常一个 Server 对应 Host 里的一个 Client 连接。

Q4：MCP 和普通 API 有什么区别？

A：API 是某个业务系统自己的接口；MCP 是面向 AI 应用的标准连接协议。它不只是调用接口，还包括能力发现、工具 schema、资源读取、prompt 模板、生命周期和通知等协议能力。

Q5：MCP 落地时最需要注意什么？

A：最需要注意安全和治理。MCP 能让 AI 接触数据和工具，所以必须做用户同意、权限控制、参数校验、敏感数据保护、写操作确认、审计日志和远程服务认证。

15 · 练习和速查

把 MCP 讲成一个能落地的连接方案

学完这一课，至少要能为一个企业系统设计 MCP Server 的能力清单。

练习 1

设计订单 MCP Server

列出 2 个 tools、2 个 resources、1 个 prompt，并说明哪些能力需要用户确认。

练习 2

区分 Tools 和 Resources

把“查订单”“读取接口文档”“创建售后单”“读取错误码表”分别归类，并解释原因。

练习 3

写一份安全清单

从用户同意、权限、参数校验、数据脱敏、幂等、审计六个维度写检查项。

一页速查卡 复习

1MCP 是 AI 应用连接外部数据、工具和工作流的开放协议。
2三类角色：Host 管全局，Client 管连接，Server 提供能力。
3两层结构：数据层定义 JSON-RPC 语义，传输层负责消息通道。
4三类核心能力：Tools 是动作，Resources 是资料，Prompts 是模板。
5两种常见传输：stdio 适合本地，Streamable HTTP 适合远程。
6安全底线：用户同意、权限控制、参数校验、写操作确认、审计日志。