【字节一面】MCP 里 Host 和 Client 是同一个东西吗？Tools 和 Resources 为什么要分开？

考察点

这道题出自字节跳动大模型岗一面（腾讯、百度一面也考同题），属于 MCP 的协议设计理解题。面试官不满足于你背出「MCP 是连接模型和工具的协议」，想看你是否理解架构角色拆分背后的设计动机：为什么不是 Host 直连 server，为什么能力要分三类而不是一个大杂烩。能讲出「控制权归属」这条主线，答案就立住了。追问常往 capability 协商、sampling、roots 走。

参考答案

Host 和 Client：不是同一个东西

Host 是用户直接面对的 Agent 应用——Claude Desktop、Cursor、你自己写的 Agent 后端。它持有模型会话、UI、用户授权，决定整体编排。Client 是 Host 内部为每个 MCP server 建立的协议连接实体，和 server 一对一：连了文件系统、数据库、GitLab 三个 server，Host 里就有三个 client，各自维护独立的连接和协议状态。

为什么要拆成两个角色而不是 Host 直接管所有连接？三个设计收益：

• 关注点分离。Host 管的是「Agent 的事」：跟模型对话、让用户确认敏感操作、决定调用哪个工具；client 管的是「协议的事」：initialize 握手、capability 协商、消息收发、错误处理。两层各自演化，互不绑架。
• 故障与能力隔离。每个 server 能力不同、稳定性不同。某个 server 挂了或握手失败，只影响它自己的 client 连接，Host 和其他 server 照常工作。如果揉在一起，一个劣质 server 能拖垮整个应用。
• server 无需感知应用全貌。server 只面对一个标准 client 接口，不用知道自己跑在什么 Agent 里、旁边还有哪些 server。这是生态能起来的前提——工具方写一次，所有 Host 都能用。

可以类比理解：Host 是操作系统，client 是每个外设的驱动，server 是外设。你不会让操作系统直接跟每个 USB 设备裸聊协议。

Tools、Resources、Prompts：按控制权分三类

MCP server 暴露的能力分三类，关键差异在由谁触发：

Tools 和 Resources 为什么不能合并成一个「能力」？ 核心原因是安全边界。Tool 有副作用——写库、发请求、执行命令，触发的后果不可逆，所以协议要明确「这是模型可以自主决定调用的东西」，Host 围绕它做确认、审计、限流。Resource 只是数据，应用把它读出来放进上下文，不存在「执行」一说。如果合并成一个概念，「这段数据」和「这个会删表的操作」在协议层面就无法区分，Host 没法对副作用做针对性管控，客户端 UI 也没法呈现「模型即将执行一个操作，请确认」和「应用读取了一份文件」这两种性质完全不同的事件。

再深一层，控制权归属还决定了 UX 形态：Prompts 由用户显式选择（斜杠命令），Resources 由应用按需加载，Tools 由模型在推理中发起——三类能力对应三种交互范式，合并等于逼所有客户端用同一种方式处理所有能力，生态的标准化价值就没了。

协议里值得一提的反向能力

理解角色拆分后，两个进阶点能加分：一是 sampling，server 可以反过来请 client 让模型生成内容（比如 SQL server 请模型帮忙优化语句），这解释了为什么 client 不能只是个哑管道；二是 roots，client 告诉 server「你能访问的边界在哪」（比如允许读哪些目录），把权限边界也协议化了。

可能的追问

• capability 协商具体协商什么？ 答：initialize 握手时双方声明支持的能力集——server 声明有没有 tools/resources/prompts、是否支持变更通知，client 声明是否支持 sampling、roots；后续交互只用双方都支持的能力。
• 一个 Host 连几十上百个 server 会有什么问题？ 答：工具 schema 全量注入会爆上下文，需要工具检索/分层加载；连接管理成本高，业界做法是引入 MCP gateway 聚合，Host 只连 gateway。
• sampling 有什么风险？ 答：server 借 client 的模型生成内容，等于把 token 成本和生成内容的安全暴露给 server 行为，Host 必须对 sampling 请求做用户可见和频率限制。