考察点
这道题出自字节跳动 AI 基础设施开发岗实习面试，考的是你对 Agent 工具生态演进的理解。面试官想确认三点：你知道 MCP 出现之前工具集成具体痛在哪（不是一句「没有标准」就完事）；你能讲清 MCP 的角色划分和一次工具调用的完整链路；你不会把 MCP 吹成银弹。追问常往「MCP 和 Function Calling 是什么关系」「MCP 的安全风险」方向走。
参考答案
MCP 出现之前：M×N 的硬编码地狱
没有 MCP 的时代，给 Agent 接工具的方式是每个应用各自硬编码：应用 A 想接 GitHub、数据库、内部工单系统，就得分别写三套适配代码——每个工具的鉴权方式、参数格式、错误处理、结果解析全都不一样，全塞进应用自己的代码库里。应用 B 想接同样三个工具，再来一遍。M 个 Agent 应用 × N 个工具，集成成本是 M×N，且每对组合都是一次性的：工具方 API 升级，所有接过它的应用各自跟着改。工具的能力描述（有哪些参数、干什么用）也没有统一格式，都是手写 prompt 片段塞进各自系统里，质量参差不齐，模型调用准确率全看各应用 prompt 工程师的手艺。
MCP 的核心解法：一次实现，处处可用
MCP（Model Context Protocol，Anthropic 2024 年底开源的开放协议）做的事类比 USB-C：定义一套标准接口，工具方实现一次 MCP Server，所有支持 MCP 的 Host 都能直接用，集成成本从 M×N 降到 M+N。具体标准化了三类能力的暴露方式：
- Tools：可被模型调用的函数，带 JSON Schema 的参数描述；
- Resources：可读取的数据（文件、数据库记录），由应用侧控制何时注入上下文；
- Prompts：预定义的提示模板。
工具的自我描述（名字、参数 schema、说明）由 Server 统一下发，模型看到的是规范格式的工具清单，不再依赖应用手写描述。
工作流程：三个角色，一条链路
MCP 是 client-server 架构，三个角色要分清：
- Host：面向用户的 Agent 应用（如 Claude Desktop、各类 IDE 里的 AI 助手），持有 LLM 和对话状态；
- Client：Host 内部的协议客户端，与每个 Server 保持一对一连接；
- Server：工具的提供方，可以是本地进程（stdio 通信）或远程服务（HTTP/SSE 通信）。
一次工具调用的完整链路：
- Host 启动时，Client 向各 Server 发起连接和初始化握手，协商协议版本、交换能力声明；
- Client 调用
tools/list拿到该 Server 暴露的工具清单和 schema，Host 把这些工具描述注入模型的上下文； - 模型推理时决定调用某个工具，输出工具名和参数；
- Host 把调用请求路由给对应 Client，Client 发
tools/call请求到 Server； - Server 执行真实逻辑（查库、调 API、读写文件），返回结构化结果；
- 结果回到模型上下文，模型继续推理或生成最终答复。
必须澄清的一个关系：MCP 不替代 Function Calling
面试里最容易露怯的点：MCP 和 Function Calling 不是一个层级的东西。Function Calling 是模型的能力——模型按 schema 输出结构化调用意图；MCP 是应用与工具之间的传输协议——管的是这个调用意图怎么送达工具、结果怎么回来。MCP 链路里模型的工具决策仍然靠 Function Calling（或等价的提示工程），MCP 只是把它背后的「接线」标准化了。
落地时的现实考量
工程上接 MCP 有几个坑值得提：Server 数量一多，工具描述全塞进上下文会吃掉大量 token，需要工具筛选/路由层；远程 Server 的鉴权与权限边界要自己把关，社区 Server 供应链安全（恶意 Server 通过工具描述做 prompt injection）是真实风险；另外生态虽增长很快，但企业内部系统大多还没有现成 Server，仍需自己包一层——好在这正是 MCP 的价值点，包一次全员复用。
可能的追问
- MCP 和 Function Calling 的关系？ 答：Function Calling 是模型输出调用意图的能力，MCP 是应用与工具间的通信协议，负责把意图送达工具并取回结果；MCP 链路的工具决策仍依赖模型的 Function Calling 能力，两者互补不替代。
- 本地 Server 和远程 Server 怎么选？ 答：本地 stdio 适合个人工具、访问本机资源，零网络开销但没法集中管理；远程 Server 适合团队共享服务，可统一鉴权和审计，代价是网络延迟和运维成本。
- MCP 有什么安全风险？ 答：工具描述可被用来做 prompt injection；Server 拿到的是真实系统权限，要做最小权限和调用审计；接入第三方 Server 前审其工具描述和实现，供应链风险和传统依赖包同理。
- 没有 MCP 时你会怎么做工具集成？ 答：应用内自建工具抽象层：统一定义 Tool 接口（名称、schema、执行函数），各工具实现适配器注册进来，工具描述由这层自动生成注入 prompt——本质是应用内自造一套私有「MCP」，缺点是无法跨应用复用。