MCP 工作原理全解

本文基于一次实际排查整理：在 WorkBuddy 中接入通达信（tdx-connector）、tushare、知识星球（zsxq）三个 MCP 连接器，并核对本机配置文件，还原 MCP 从接入、授权到调用的完整链路。

1. MCP 是什么，解决什么问题

MCP（Model Context Protocol）是 Anthropic 于 2024 年底开源的标准化协议，目标是解决「AI 应用 × 外部工具/数据源」的 N×M 适配问题：没有 MCP 时，每个 AI 应用要为每个数据源写一套私有胶水代码；有了 MCP，双方只需各自实现一次协议，即可任意组合——类比 USB-C 之于外设。

MCP 基于 JSON-RPC 2.0 消息格式，定义了三种核心角色：

Host：AI 应用本体（如 WorkBuddy、Claude Desktop），持有大模型与用户界面；
MCP Client：Host 内部的连接管理器，与 Server 一一对应，负责收发 JSON-RPC 消息；
MCP Server：由第三方提供的独立服务，把自家数据与能力包装成协议标准的三类原语：
- Tools：可被模型调用的函数（本文重点）；
- Resources：可被读取的数据资源（文件、记录等）；
- Prompts：预置的提示模板。

2. 整体架构与「适配层」的本质

┌─────────────────────────────────────────────┐
│                AI 应用（Host）                │
│  ┌──────────┐   ┌──────────┐  ┌──────────┐  │
│  │  LLM     │──▶│MCP Client│──▶│MCP Client│  │
│  └──────────┘   └────┬─────┘  └────┬─────┘  │
└──────────────────────┼─────────────┼────────┘
                       │ JSON-RPC    │
              stdio 子进程 │      streamable-http
                       ▼             ▼
              ┌──────────────┐  ┌──────────────┐
              │ 本地 MCP      │  │ 远程 MCP      │
              │ Server       │  │ Server       │
              └──────┬───────┘  └──────┬───────┘
                     ▼                 ▼
              本地系统/文件/DB      提供方云端 API

所谓「适配层」，就是 MCP Server 本身：它包裹在提供方既有系统（私有 API、本地终端、数据库）外面，做三件事——

能力翻译：把内部接口重新提炼为语义清晰、粒度合适的工具；
协议转换：对上只说 JSON-RPC，对下调用任意私有实现；
文档承载：每个工具的 description 与参数 Schema，就是写给模型看的接口文档。

提供方通常不需要从零实现协议，官方 SDK（Python FastMCP、TypeScript SDK 等）几行装饰器即可完成包装：

from fastmcp import FastMCP

mcp = FastMCP("tdx-finance")

@mcp.tool()
def get_realtime_quote(stock_code: str) -> dict:
    """获取A股实时行情快照：最新价、涨跌幅、成交量。stock_code 为6位代码。"""
    return tdx_client.query_quote(stock_code)   # 复用内部已有行情接口

mcp.run(transport="http")

3. 接入流程：Host 如何「看见」一个 Server

以在 WorkBuddy 中接入第三方 MCP 为例，全过程是一条固定的握手流水线：

登记配置：手动添加的 Server 写入 ~/.workbuddy/mcp.json（command/args/env 或 url）；连接器市场安装的则随插件包携带自己的 mcp.json，由 Host 合并进连接器体系。
建立连接：本地型 Server 被拉起为子进程（stdio 管道）；远程型则向 URL 发起 HTTP 连接。
initialize 握手：双方互报协议版本与能力清单（是否支持 tools / resources / prompts），完成版本协商。
tools/list 拉取工具清单：Host 询问「你有哪些工具」，Server 返回每个工具的名称、描述与参数 Schema。
工具注入模型上下文：工具的元数据（非实现代码）被转换后随每轮对话发给模型。

一个工具清单条目的实际结构：

{
  "name": "get_realtime_quote",
  "description": "获取A股实时行情快照，包括最新价、涨跌幅、成交量。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "stock_code": {"type": "string", "description": "6位证券代码，如 000001"}
    },
    "required": ["stock_code"]
  }
}

4. 模型如何「理解」API 的功能

关键认知：模型不是学出来的，而是每次会话都被直接喂了一份结构化说明书。 信息交换分两层：

协议层：tools/list 返回的工具元数据（名称 + description + JSON Schema）。
模型层：Host 将元数据转成模型 API 的 tools 参数注入上下文。模型靠 description 判断何时调用、靠 JSON Schema 约束参数类型与必填项；模型输出的只是「调用意图」，Host 会按 Schema 做参数校验，不合法则打回。

因此，写好工具的 description 与参数描述，本质是给模型写文档，直接决定模型选工具的准确率。值得注意的是：进上下文的只有工具说明书，Server 实现代码、用户的 API key 都不会进入模型上下文。

5. 运行时：一次工具调用的完整时序

sequenceDiagram participant U as 用户 participant L as LLM participant C as MCP Client participant S as MCP Server U->>L: ① 提问：查平安银行的最新价 L->>C: ② 决定调用 get_realtime_quote(000001) C->>S: ③ JSON-RPC: tools/call S->>C: ④ 返回数据 JSON C->>L: ⑤ 工具结果回传 L->>U: ⑥ 综合成自然语言回答

要点：

模型不执行任何东西。它只输出结构化的调用意图；发请求、拿数据的是 Client，真正连数据源的是 Server。
权限控制在 Host 层。敏感工具（如交易类）调用前通常需用户确认，连接器也要区分 enabled / disabled——未启用的 Server 根本不会被启动，模型自然「看不见」其工具。

6. 两级授权与鉴权：谁授权给谁，谁验证谁

MCP 链路上有两段独立的信任关系，容易混淆：

6.1 用户 → MCP Server（授权使用数据）

用户向数据提供方证明「我有权使用这项服务」，典型方式：

Token / API Key：用户在连接器界面填入自己的 token，Host 在每次请求中携带；
OAuth：远程 MCP 可走标准 OAuth 流程，弹窗登录后由 Server 颁发访问凭证。

6.2 Host → MCP Server（信任并执行代码/指令）

本地型 Server 等同于在用户机器上运行一个第三方程序，因此 Host 会引入信任机制：例如 WorkBuddy 中手动添加的自定义 MCP Server，需要用户在连接器管理页点击「信任」后才会被激活。

6.3 MCP Server → 上游 API（鉴权）

Server 拿着用户授权的凭证去调用上游私有 API。凭证的传递位置由 Server 设计决定——tushare 的做法是直接编码进 URL 模板。

7. 本地模式 vs 远程模式

维度	本地模式（stdio）	远程模式（streamable-http）
Server 位置	用户机器上的子进程	提供方云端服务
配置形态	`command` + `args` + `env`	`url`（可含 token 模板）
通信方式	标准输入输出管道	HTTP 长连接（Streamable HTTP）
数据边界	数据不出本机	查询参数与返回数据经过对方服务器
可用性	依赖本地环境与依赖安装	断网或对方故障即不可用（需设超时）
鉴权	无网络鉴权，凭本机权限	Token / API Key / OAuth
典型场景	数据库、文件系统、浏览器自动化	SaaS 数据服务、官方托管能力

8. 实例剖析：同一台机器上的三个 MCP

实际核对 ~/.workbuddy/ 下的配置，结论是：零个本地 Server，三个远程 Server。

连接器	Server 地址	类型	配置来源	鉴权方式
通达信	`https://txmcp.tdx.com.cn:3001/txmcp`	streamable-http	插件包自带 `mcp.json`	官方托管（连接器授权）
tushare	`https://api.tushare.pro/mcp/?token=${TUSHARE_TOKEN}`	streamable-http	插件清单 `urlTemplate` + `token-schema.json`	用户 token 填入 URL 模板
知识星球	`https://mcp.zsxq.com/topic/mcp?api_key=...`	URL 直连	用户手动写入 `mcp.json`	API Key 拼接在 URL

三个值得注意的工程细节：

配置分流：mcp.json 只存手动添加的 Server；连接器市场的 MCP 配置随插件包分发（位于 plugins/cache/<marketplace>/<name>/<version>/），两套机制最终汇合成同一批 Server。判断某个 MCP 装没装，要看对位置。
模板化凭证：tushare 的 URL 是 ?token=${TUSHARE_TOKEN} 模板，配套 token-schema.json 定义凭证格式——这就是连接器「授权」动作的技术实质：收集凭证并注入模板。
MCP + Skill 组合拳：tushare 插件包里除 MCP 配置外还携带了 skills/ 目录。MCP 负责「能力接入」，Skill 负责「使用方法论」（何时查什么、怎么解读），两者互补。

9. 总结

一句话串联全文：

接入 = 登记/安装配置 → 建立连接（本地子进程或远程 HTTP）→ initialize 握手 → tools/list 拉清单；使用 = 模型读工具说明书选工具 → Client 转发 JSON-RPC → Server 鉴权后调用上游 API → 结果回传模型润色成回答。

MCP 的核心贡献在于把这条链路上的消息格式、能力协商、元数据描述全部标准化，使「AI 应用 × 数据源」的适配成本从 N×M 降为 N+M——服务提供方只需写一层适配器向模型「自我介绍」，应用方只需实现一次协议即可接入整个生态。

posted @ 2026-10-26 16:32 Momoko-X 阅读(33) 评论(0) 收藏举报

刷新页面返回顶部