MCP三层架构：Server、Host与Client协作设计

可视化演示

角色总览：三个岗位，一条动线

假设你开了一家“MCP 餐厅”。大厅里，经理负责接待你、记录需求、安排上菜顺序；后厨里，厨师掌握着真正的烹调手艺；而传菜员，则在大厅与后厨之间来回奔波。你不会直接冲进厨房喊“要加辣”，厨师也不会跑到桌前推销招牌菜。三个岗位各管一摊，餐厅才能既高效又安全地运转。理解 MCP 架构的第一步，就是把这三个岗位认清楚。

在 AI 应用里，MCP 正是这样一套“餐厅分工制度”。它把工具调用拆成三个角色：Server 像后厨，负责把数据库、文件系统、第三方 API 包装成标准能力；Host 像经理，是用户和 Agent 所在的应用程序，负责理解用户意图、安排调用；Client 像传菜员，负责把 Host 的请求翻译成标准小票（JSON-RPC 消息）送到 Server，再把结果端回来。三者缺一不可，少一个环节，整个调用链条就断了。

三层之间通过 JSON-RPC 2.0 格式通信，整条链路可以写成一条流水线：

所以当你听到“MCP 架构”时，脑海里应该是这家餐厅的画面：经理不下厨、厨师不待客、传菜员不做菜。三者职责越清晰，系统就越容易扩展——想加一道新菜，只需在后厨新增一个 Server；想开分店，只需让经理多带几个传菜员。

Host 职责：运筹帷幄的餐厅经理

餐厅经理每天的工作是什么？记住熟客口味、安排座位、决定先上哪道菜、征询顾客对菜品的意见。经理从不亲自掌勺，但所有与“人”有关的决策都归他管——这正是 Host 的定位。它是三层架构里离用户最近、也最“重”的角色。

Host 在 MCP 中就是“Agent 的家”。它承载着大模型、会话上下文和用户界面；用户输入、模型推理、工具返回结果都在这里汇聚。Claude Desktop、支持 MCP 的 IDE、自研 Agent 平台，本质上都是 Host。它们决定 Agent 何时调用哪个工具、调用的结果如何呈现给用户——决策权牢牢握在 Host 手里。

Host 的关键职责可归纳为三点：一是管理 Agent 会话——像经理记住你的口味一样维护多轮上下文；二是用户交互——把模型输出呈现给用户，把用户指令送给模型；三是权限拦截——在调用任何工具前先征求用户同意，相当于经理上菜前问一句“您确定要这道菜吗？”此外，Host 还要协调多个 Client：一个 Host 可以同时连接多个 Server，就像一位经理管着多名传菜员，各跑各的路线。

回到餐厅，如果把“经理”这个角色抽掉，顾客就只能自己跑进厨房点菜，AI 应用也会失去决策与安全审查的关卡。Host 存在的意义，就是让“人”始终留在决策回路里——任何工具调用，都应该先过经理这一关。

Server 职责：深藏功名的后厨

后厨的价值在于“会做菜”。鱼香肉丝、宫保鸡丁、红烧狮子头——每道菜就是一项能力。MCP Server 就是这些能力的提供方，它不关心坐在大厅里的顾客是谁，只负责按标准流程把一道道菜做出来。真正动手干活的永远是后厨，这是 Server 最朴素也最重要的定位。

一个 Server 可以暴露三类能力：Tools（工具）是可执行动作，比如查询订单、写文件、调用支付 API；Resources（资源）是只读数据，比如数据库表格、配置文件内容；Prompts（提示词模板）相当于后厨的“预制菜单”，比如一个格式化周报的标准模板。三类能力统一通过 JSON-RPC 暴露，Host 不需要知道后厨内部怎么烧菜，只需知道“能点什么菜”。

Server 的核心行为是“能力广播”：连接建立后，通过 tools/list 把自己能提供的工具清单上报给 Host，Host 据此规划调用策略。同时 Server 必须守好自身边界——它在自己的进程内执行，独立于 Host，权限受限；每次调用都要校验参数格式与调用方身份，就像后厨有食品卫生规范，不接触顾客隐私。

设计 Server 时，思路应该像开菜谱：一道菜一个规矩，食材清单写清楚，做法别越界。Server 暴露能力的同时必须自带边界——菜可以辣，但锅不能把火苗带进餐厅。能力越聚焦，权限面越小，系统就越安全。

Client 职责：勤勉的传菜员

传菜员是餐厅里最不起眼却最关键的岗位。菜做得再好、经理安排得再周密，如果没人把订单送进厨房、把菜端出来，一切都是空谈。MCP 里的 Client 就是这条“生命线”——它不决策、不做菜，只保证消息准确送达。

Client 是 Host 内部与某个 Server 之间的一对一连接通道。Host 可能同时挂着多个 Client：一个连文件系统 Server，一个连数据库 Server，一个连 GitHub Server。每个 Client 只服务一个 Server，就像每位传菜员只负责一条固定送餐路线。这个“一对一”约束是理解 Client 的关键：它不是一个抽象层，而是一条具体的、有状态的连接。

Client 的职责有三：一是建立与维持连接，选择传输层（本地用 stdio 管道，远程用 HTTP/SSE）并管理会话生命周期；二是消息封装，把请求、响应包装成 JSON-RPC 2.0 格式，包含 jsonrpc 版本、method、params、id 等字段；三是协议协商，在初始化阶段与 Server 对齐协议版本与能力。它像传菜员一样，只保证小票格式正确、路线无误，从不擅自改菜。

传菜员不需要懂菜谱，但必须跑得快、传得准。当你的 Agent 平台出现“连不上工具”的故障时，八成问题出在 Client 这层：传输断了、协议版本没对齐、消息格式错误。排查时盯着传菜员手里的“小票”看，往往很快就能定位。

通信流程：一张订单的旅程

一次完整的点餐体验是什么样？你告诉经理想吃什么，经理确认菜单上有这道菜，传菜员把订单送进后厨，厨师做完让传菜员端回，经理检查后上桌。MCP 的工具调用生命周期，就是这张订单的旅程，四步走完，一次会话才算圆满。

整个过程分四个阶段。首先是初始化握手（initialize）：Client 向 Server 声明协议版本与能力，Server 回应自己的版本与能力，双方“对上方言”；接着是能力发现（tools/list）：Client 拉取 Server 的工具清单，相当于看菜单；然后是工具调用（tools/call）：Client 携带参数发起调用，Server 执行后返回结果；最后是会话收尾：发送关闭通知，释放连接资源，相当于结账离店。

所有消息都用 JSON-RPC 2.0 封装：请求带 method 和 params，响应带 result 或 error，id 用来配对请求与响应。一个典型的调用消息形如 {"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"query_order","arguments":{"order_id":42}}}——这串标准格式，就是传菜员手里那张所有人都能读懂的订单小票。

这张“订单旅程”提醒我们：任何 MCP 调试都可以按阶段切分——握手失败先查协议版本，清单为空查 Server 注册，调用失败查参数与权限。把旅程拆开看，问题就各归各家，不会再混成一锅粥。

安全边界：传菜窗口的规矩

餐厅为什么要设传菜窗口？因为顾客与后厨必须隔离：顾客不能进厨房碰刀具，厨师也不该知道顾客的银行卡密码。MCP 的安全边界设计，就是这扇“传菜窗口”——每一层都管好自己的权限，谁也不越界。

MCP 安全不是某一层的单点防护，而是层层设防：第一道防线在 Host——所有工具调用必须先经用户授权，经理替你确认；第二道防线在 Server——Server 只暴露最小必要能力，并在自己的沙箱里执行，权限受限；第三道防线在传输层——本地用 stdio 隔离进程，远程用 HTTPS/SSE 加密，敏感数据尽量留在本地，不经过不必要的网络传输。

实践要点包括：能力最小化（比如数据库 Server 只暴露只读查询，不暴露删表接口）、参数校验（Server 对每个参数做类型与范围检查，拒绝畸形输入）、审计日志（Host 记录每次调用的时间、工具、参数摘要，像餐厅留下订单存根以备查账）。权限判定遵循“取交集”原则：一次调用能拿到的权限，必须同时落在用户、Host、Server 三方允许的范围内。

安全的本质是“默认不信，逐级求证”。传菜窗口既挡了顾客进厨房，也挡了厨师打探顾客隐私——两边各守其位，餐厅才能放心营业。设计 MCP 系统时，宁可多问一次用户，也不要默认放行。

部署拓扑：小店与中央厨房

一家餐厅可以是一间街边小店，也可以是一套连锁中央厨房体系。MCP 的部署方式同样取决于你是“小店”还是“连锁”：本地单进程就像小店——后厨就在店里，传菜员走几步就到；远程多服务就像中央厨房——后厨集中建在别处，各门店通过网络从同一厨房调菜。

本地单进程部署：Host 与 Server 跑在同一台机器，通过 stdio（标准输入输出管道）通信，Client 拉起一个子进程并与它直接对话。优点是低延迟、高隐私——数据不出本机，适合桌面应用（Claude Desktop、IDE 插件）和本地文件、命令行工具。缺点是无法共享：每个用户都要各自拉起一份服务。

远程多服务部署：Server 独立部署在远端，通过 HTTP/SSE 通信，多个 Host（不同用户、不同团队）共享一套工具服务。优点是松耦合、可复用、便于集中运维，适合企业级的数据库查询、工单系统、内部 API 网关。缺点是网络延迟更高，且数据要过网络，安全要求更严。实践中也有混合部署：本地 Server 处理敏感文件，远程 Server 处理需要共享的数据。选型权衡看三件事：数据敏感性、延迟要求、运维成本。

选部署方案就像选餐厅经营模式：街边小店适合私密小范围，中央厨房适合规模化共享。架构师先问自己三个问题——数据能不能出本地、延迟有多敏感、谁负责运维——答案自然浮现，不必盲目追捧某一种形态。

AI 应用场景

Python 演示

import json  class MCPServer:    """MCP Server：模拟后厨，提供真实的工具能力"""     def __init__(self, name, tools):        self.name = name        self.tools = tools     def handle(self, req):        method = req["method"]        if method == "initialize":            return {"jsonrpc": "2.0", "id": req["id"],                    "result": {"serverName": self.name,                               "protocolVersion": "2024-11-05",                               "tools": list(self.tools)}}        if method == "tools/call":            name = req["params"]["name"]            args = req["params"].get("args", {})            if name in self.tools:                return {"jsonrpc": "2.0", "id": req["id"],                        "result": {"output": self.tools[name](args)}}        return {"jsonrpc": "2.0", "id": req["id"],                "error": {"code": -32601, "message": "方法不存在"}}  class MCPClient:    """MCP Client：模拟传菜员，负责消息在 Host 与 Server 间往返"""     def __init__(self, server):        self.server = server        self.req_id = 0        self.connected = False     def send(self, method, params=None):        self.req_id += 1        req = {"jsonrpc": "2.0", "id": self.req_id,               "method": method, "params": params or {}}        print(f"  [Client -> {self.server.name}] {method}")        return self.server.handle(req)  class MCPHost:    """MCP Host：模拟餐厅经理，管理会话、授权并调度工具"""     def __init__(self):        self.clients = {}        self.logs = []     def attach(self, name, client):        self.clients[name] = client     def approve(self, tool, args):        print(f"[Host] 请求用户授权调用 {tool}，参数 {args}")        return True     def call_tool(self, name, tool, args):        if not self.approve(tool, args):            return None        reply = self.clients[name].send("tools/call",                                        {"name": tool, "args": args})        result = reply["result"]["output"]        self.logs.append((name, tool, result))        return result  def main():    calc = MCPServer(        "计算器",        {"add": lambda a: a["x"] + a["y"],         "mul": lambda a: a["x"] * a["y"]})    client = MCPClient(calc)    host = MCPHost()    host.attach("计算器", client)    client.send("initialize")    print("[Host] 计算 3 × 4：", host.call_tool("计算器", "mul",                                                {"x": 3, "y": 4}))    print("[Host] 审计日志：", host.logs)  if __name__ == "__main__":    main()

1. class MCPServer后厨：持有真实工具函数，按 JSON-RPC 协议处理初始化与调用请求。
2. class MCPClient传菜员：维护请求 id，把方法名和参数封装成标准消息发给 Server。
3. class MCPHost经理：管理多个 Client，调用前先征求用户授权，并把调用记录写入审计日志。
4. def handle(self, req)Server 根据 method 字段分发请求，相当于后厨按小票类别接单。
5. client.send("initialize")建立会话时先握手，双方对齐协议版本，对上“暗号”。
6. host.attach("计算器", client)Host 把传菜员挂到自己的管理名单里，一条路线一个 Client。
7. def approve(self, tool, args)安全边界的核心：任何工具调用都要先过用户授权这一关。
8. self.logs.append(...)每次调用留痕，方便事后审计，像餐厅保留订单存根。

常见误区

面试题