content/01-mcp/05-interview/common-misconceptions.md

学 MCP 时我理解错的 10 件事

学 MCP 的过程中，有些误解很隐蔽——每个词都认识，但组合起来的逻辑却是错的。这篇文章记录我亲历的真实误解，以及纠正后的正确理解。

误解 1：N+M 是说"连接数从 200 减少到 30"

我以为： 10 个 App 对接 20 个系统，有了 MCP 后连接数从 200 减少到 30。

正确理解： 物理连接数没有减少，减少的是开发工作量。

10 个 App 还是会连接 20 个 Server（物理上还是 200 条连接）。但开发工作量从 200 次降到 30 次，因为每个 Server 只需要写一次，所有 App 直接复用，无需重复开发。

关键是"边际成本归零"：第 11 个 App 接入现有 20 个 Server，开发工作量 = 0。

误解 2：AI 调用了 Tool

我以为： AI 输出了 Tool 调用的 JSON，然后 AI 自己去执行这个 Tool。

正确理解： AI 只是"表达意图"，真正执行 Tool 的是你的代码。

AI 输出: { "tool": "get_weather", "input": { "city": "上海" } }
         ↓ AI 在此停止，等待结果
你的代码拦截 JSON，执行真实 HTTP 请求
         ↓
你的代码把结果传回 AI
         ↓
AI 生成自然语言回答

如果 AI 能直接执行，它就能任意访问网络、文件、数据库——是安全灾难。代码作为中间层，让 AI 的能力始终在开发者掌控之内。

误解 3：AI 停止后会主动通知我的代码去执行

我以为： AI 输出 JSON 后，会发某种信号通知我的代码"该你执行了"。

正确理解： AI 就是一个普通的 HTTP 接口，没有任何主动推送。

是你的代码一直在主控整个循环：调用 AI API（同步等待）→ 检查返回值类型 → 判断是否需要执行 Tool → 执行 → 再次调用 AI。AI 停止后什么都不做，就等着你的代码下一次调用它。

误解 4：Gateway 是零代码的，自动把所有服务包装成 MCP

我以为： 有了 MCP Gateway，配置一下就能把内部所有服务自动暴露给 AI 用。

正确理解： Gateway 必须写代码，没有魔法。它本质是一个普通 MCP Server，Tool 的实现内部调其他服务。业务逻辑的翻译工作永远需要人来做。

另外，Gateway 也不应该把所有服务全部暴露——AI 看到几百个 Tool 会选择混乱。好的 Gateway 是选择性暴露 AI 真正需要的能力子集。

误解 5："对 AI 语义透明"是指 AI 能理解

我的理解方向对，但词本身有歧义。

"透明"在工程领域有两种截然相反的含义：

  • 含义 A：可见、可理解（你的理解，在 MCP 语境是对的）
  • 含义 B：不可见、无感知（如"负载均衡对用户透明"= 用户感知不到）

更精确的词是：

中文英文含义
自描述的self-describing接口本身携带足够语义，不需要查外部文档
AI 可理解的AI-interpretable信息被组织成 AI 可推理的形式
语义不透明的semantically opaque接口本身没有语义线索（如 POST /v1/txn/proc）

误解 6：改造 API 文档成 AI 友好格式就够了

我以为： 只要把 API 文档写成 AI 能理解的自然语言，AI 就能调用这些接口了。

正确理解： 文档改造解决了"语义理解"这半步，但缺"执行桥梁"那半步。

AI 看懂了"要调 POST /v1/pay"——谁来发这个 HTTP 请求？AI 不能自己发。必须有代码层的桥梁把 AI 的意图转化成真实的 HTTP 调用。这正是 Function Calling / MCP 存在的理由。

改造文档 ≈ 写好 MCP Tool description，本质相同，但都还需要配套执行代码。

误解 7：MCP 的 N+M 思想只适用于 AI 工具集成

我以为： N×M → N+M 是一个 MCP 特有的技术技巧。

正确理解： 这是人类解决规模化问题的普世思想——引入标准中间层，将乘法复杂度降为加法复杂度。

货币、国际通用语、集装箱标准、USB、HTTP、SQL，解决的都是同一个数学问题。理解了这个结构，你就能在任何新场景中识别"是否需要引入标准中间层"。

误解 8：Tools、Resources、Prompts 都是 AI 主动调用的

我以为： MCP 的三类能力都是 AI 在需要时主动调用的。

正确理解：

  • Tools：AI 自主决定调用（对）
  • Resources：AI 按需读取（对）
  • Prompts：用户主动触发，不是 AI 触发

Prompts 是用户在 Host 界面输入 / 选择斜杠命令触发的，AI 是被动的。这是三类能力里最容易被忽视的，但对产品化最有价值——把专家的"最佳用法"封进模板，普通用户填参数就能得到专家级结果。

误解 9：动态 Tool 注册只有好处没有坏处

我以为： 动态注册明显优于静态注册，应该总是用动态注册。

正确理解： 动态注册解决了"Tool 太多"的问题，但引入了新的问题：

  • 意图分类出错会导致正确 Tool 根本没有暴露（比静态注册更糟）
  • 跨场景任务（需要多个业务域的 Tool）难以处理
  • 引入额外的延迟和 LLM 调用成本
  • 分组逻辑需要随业务变化持续维护

Tool 数量少于 15 个时，直接用静态注册就好。

误解 10：Schema 是数据本身

我以为： Schema 就是某种格式的数据。

正确理解： Schema 是数据结构的描述规范，不是数据本身。

类比：Schema 是表格的表头设计图（定义有哪些列、每列什么类型、哪些必填），不是表格里的数据。

在 MCP 里，JSON Schema 专门用来描述 Tool 的参数结构，让 AI 知道调用这个 Tool 时参数应该怎么填、有哪些约束。

总结：三类误解模式

模式特征本文例子
词义混淆类似词汇导致混淆"连接数" vs "开发工作量"
局部对整体错每个词都对，逻辑组合有问题"AI 调用 Tool"（意图表达 vs 真实执行）
日常语义推断专业含义用生活常识理解技术术语"透明"的两种相反含义

发现自己的误解，比只记住正确答案更有价值。误解意识是专家和初学者的重要区别之一。

评论