技术

MCP

模型上下文协议

一种开放协议，让 AI 模型可以安全地连接外部工具与数据源，而无需为每个模型单独写定制集成。

最近审阅: 审阅人Kevin Riedl wiki ↗

Model Context Protocol（MCP）之于 AI Agent，相当于 HTTP 之于 Web：一份共享、开放的标准，规定模型如何与外界其余部分对话。它由 Anthropic 在 2024 年末推出，并在 2025 与 2026 年被广泛采用。

技术形态：一个 MCP 服务器通过一份定义好的 schema 暴露资源、工具与 Prompt。任何 MCP 兼容客户端（Claude Desktop、Claude Code、API、一个 IDE 插件）都能发现并调用这些工具，而不需要按厂商写胶水代码。集成做一次，每个 MCP 客户端都受益。

这种杠杆，举个实际例子：一家公司把它的内部 CRM、分析数仓和文档库封装成三个 MCP 服务器。这个季度团队在用 Claude；下个季度出于成本原因他们试用另一个模型。如果函数调用绑死在一个厂商上，那次切换意味着重写每一个集成。有了 MCP，他们把新客户端指向同样这三个服务器就行了。集成成本只付了一次，不是每个模型一次。把这些服务器与对文档库的 RAG 配对，你就能从内部数据得到有接地的答案，无需定制管道。

诚实的取舍与创始人的错误：只有当你预期会更换模型、或想要可移植性时，MCP 才是正确的选择；如果你永久绑定在一个供应商上，朴素的函数调用更简单也没问题。更大的风险是安全。MCP 是一个传输协议，不是一个权限模型。一个草率的 MCP 服务器，把一个有写能力的工具配上薄弱的鉴权暴露出来，就是一个等着发生的「Confused Deputy」，模型会被骗去调用它不该调用的东西。我们经常构建 MCP 服务器并已经把它们部署到生产；我们也为每一个都写一份安全评估，因为标准还在变，而失败模式是你的内部系统，不是一个聊天机器人说了句蠢话。只有当一个工具在模型循环里确实有用、且安全模型允许模型去调用它时，我们才把它封装进 MCP，对任何破坏性的动作都加上 Human-in-the-Loop。

// FAQ

常见问题

Function-Calling 是按厂商的。MCP 是可移植的。如果你永远不打算更换模型厂商，Function-Calling 就够用。如果你想能切换厂商（多数企业都想），MCP 是 lock-in 更低的选择。
MCP 本身是传输协议，安全性取决于服务器暴露了什么、如何鉴权。一个写得差的 MCP 服务器就是等着出错的「Confused Deputy」。一个写得好的不会比普通内部 API 更危险。
两个标准：底层工具放进 LLM 循环里是真的有用，并且安全模型允许模型来调用（涉及破坏性操作的，最好保留 Human-in-the-Loop）。其余的就保持为普通 API。