模型上下文协议是AI Agent缺失的一环吗？干货评测
更新于 2025年9月25日
9 分钟
模型上下文协议是 AI Agent 的关键缺失环节吗？一份不废话的评测
如果你在 2024-2025 年一直在使用 LLM 构建应用，你可能已经感受到了阻力：将模型连接到工具、数据库和实时系统感觉就像在重新发明轮子——每次都是如此。模型上下文协议（Model Context Protocol, MCP）应运而生，它是一个旨在使模型具有工具感知能力、上下文丰富性以及在应用程序和运行时之间具有互操作性的开放标准。但 MCP 实际上是否准备好标准化我们将 AI 连接到现实世界的方式——或者它只是更多的炒作？
在这篇分析性和战略性评论中，我们将分解 MCP 是什么，它的优点是什么，它的缺点是什么，以及它与 LangChain 工具抽象、OpenAI 函数调用和 agent 框架等替代方案相比如何。我们还将介绍采用信号、安全考虑因素以及您可以立即使用的实用用例。
到最后，您将知道 MCP 是否属于您的技术栈——以及在标准演进过程中需要关注什么。
什么是模型上下文协议（用通俗易懂的语言）？
模型上下文协议是一个开放标准，用于以一致的接口将 AI 模型连接到外部工具、数据和系统。MCP 提出了一种共享语言，而不是硬编码函数或为每个提供商编写一次性集成：服务器公开功能（工具、资源、提示）；客户端（IDE、应用程序、agent 运行时）请求它们；模型获得对上下文和操作的结构化访问。
- 核心思想：将模型交互与供应商锁定和定制 API 解耦。
- 实际承诺：统一的工具，因此 agent 可以使用跨环境的相同协议形状调用搜索 API、查询数据库、打开文件或运行作业。
Thoughtworks 的分析抓住了精神：MCP 旨在稳定开发人员将模型连接到世界的方式，通过形式化大多数团队重复重建的管道层，使其位于炒作之下。
一篇重要的独立评论更直率地指出：MCP 很有吸引力，但它的真正价值取决于清晰的采用途径、超越演示环境的互操作性以及对安全和生命周期管理的可信答案。
社区情绪反映了一种务实的中间立场：开发人员发现 MCP 在将 agent 连接到精选的工具服务器时“非常有用”，尤其是在可重复的集成方面——同时承认现在要获得普遍认可还为时过早。
为什么现在 MCP 很重要
这里有一个令人不舒服的现实：您今天对工具访问的选择是分散的。
- OpenAI 函数调用紧凑且方便——但它是特定于提供商的，不同供应商的模式和行为存在差异。
- LangChain 和类似的库为您提供工具抽象——但它们以框架为中心，而不是系统之间的线路协议。
- Agent 框架成倍增加——每个框架都有自己定义工具、提示、内存和上下文存储的方式。
MCP 尝试在协议层进行标准化，因此：
- 单个 MCP 客户端可以与多个 MCP 服务器（数据库、文件系统、API）通信。
- 工具可以在应用程序和模型之间移植。
- IDE、终端和聊天应用程序可以提供相同的功能，而无需定制适配器。
底层原理：MCP 提供了什么
将 MCP 视为想要使用工具的东西（客户端）和提供工具/数据的东西（服务器）之间结构良好的契约：
- 工具注册表：可发现的、类型化的工具，您可以使用结构化参数调用。
- 资源访问：加载文件、文档或数据库行的标准化方法。
- 提示和上下文配置：跨应用程序共享的一致提示/模板。
- 会话语义：握手、能力协商和持续的消息交换。
这使得：
- 一次构建，多次集成：编写一个“搜索服务器”或一个“CRM 服务器”，并在多个项目中重用它。
- 可重现性：工具不仅仅是代码——它们是具有元数据和权限的已声明功能。
- IDE/agent 收敛：同一服务器可以为 VS Code 扩展和面向客户的 copilot 提供支持。
Thoughtworks 强调，MCP 的价值在于使交互界面可预测，从而减少了早期 AI 项目中占据主导地位的胶水代码成本。
MCP 的优势（以及它的不足之处）
优势
- 互操作性：通用协议减少了一次性集成和供应商锁定。
- 工具生命周期：服务器可以版本化、测试并作为标准化功能分发。
- 多环境覆盖：同一服务器可以为 CLI agent、聊天 UI 和 IDE copilot 提供服务。
- 社区驱动的生态系统：精选的服务器列表和示例可帮助团队更快地启动。
局限性
- 早期成熟度：企业级安全性、治理和服务水平协议 (SLA) 仍在发展中。
- 运营复杂性：运行和保护 MCP 服务器会增加基础设施开销。
- 模型提供商差异仍然存在：MCP 标准化了工具端，但模型行为有所不同。
- 不是完整的 agent 框架：您仍然需要规划、内存和编排层。
MCP 与替代方案：何时使用
- MCP 与 OpenAI 函数调用：
- 对于单供应商、快速原型设计且可移植性不是优先事项的情况，请选择 OpenAI 函数。
- 对于具有可重用服务器和一致语义的多模型、多环境工具访问，请选择 MCP。
- MCP 与 LangChain 工具：
- LangChain 提供框架级抽象和编排。
- MCP 提供了一种可由 LangChain 使用或与其一起使用的协议；它关注的是共享线路，而不是替换规划逻辑。
- MCP 与 Agent 框架（AutoGen、CrewAI、Semantic Kernel 等）：
- Agent 框架处理规划、角色和协调逻辑。
- MCP 可以将标准化工具/资源提供给这些框架，以避免定制适配器。
- MCP 与实时 API（例如，流式语音、视觉、事件）：
- 实时 API 侧重于低延迟多模式交互。
- MCP 标准化了与外部工具和数据的桥梁；将两者都用于具有操作功能的语音 agent。
安全性、治理和合规性：需要关注什么
安全性是协议在企业中成败的关键。主要考虑因素：
- 身份验证/授权：客户端如何获得对服务器和工具的范围权限？基于令牌的身份验证、服务帐户和每个工具的策略至关重要。
- 数据边界：确保资源访问（文件、数据库）尊重最小权限和环境隔离。
- 可观察性：记录带有输入/输出的工具调用以进行审计，但编辑机密信息。
- 速率限制和配额：MCP 服务器应强制执行每个客户端的预算以防止滥用。
- 治理工作流程：对服务器进行版本控制、审核更改并发布到私有注册表。
重要的评论要求在此处提高成熟度——大多数团队将需要分层自己的安全态势，直到生态系统标准化最佳实践。
您可以立即使用的真实用例
- 具有实际文件和 repo 访问权限的 IDE copilot：将文件读/写、测试运行程序和包管理器公开为 MCP 工具，以便您的编码助手可以重构、运行测试并起草带有防护措施的提交。
- 具有数据合规性的企业 copilot：通过 MCP 服务器提供对 CRM/ERP/BI 的只读视图；嵌入行级权限和审计日志记录。
- 受监管内容的检索：使用 MCP 公开批准的知识库和策略片段；模型永远不会直接接触原始系统。
- 运维自动化：工单分类、事件操作手册和部署操作手册作为工具——可通过具有显式步骤的 agent 触发。
- 分析和 SQL 工作流程：提供参数化查询和安全结果抽样的数据库 MCP 服务器。
社区策划的 MCP 服务器列表可以帮助您快速启动经过实战测试的集成。
开发者体验：使用 MCP 构建是什么样的
- 编写服务器：使用名称、输入模式、输出形状、权限定义工具。实现处理程序；通过 MCP 传输公开。
- 在本地运行，集中部署：从用于开发的本地服务器开始，然后部署到用于团队的共享环境。
- 连接客户端：与您的聊天 UI、IDE 插件或支持 MCP 的 agent 运行时集成。
- 使用合约进行迭代：将您的工具列表和模式视为 API——对其进行版本控制、测试并发布发行说明。
对于任何交付过微服务的人来说，这种模式都感觉很熟悉，但好处是您的“工具服务”可以在许多模型体验中重复使用。
采用信号和生态系统健康
- 主要咨询公司的思想领导力持谨慎乐观态度，强调实际收益而非炒作。
- 独立分析师正在探索边缘——安全性、可靠性以及大规模运营服务器的成本。
- 从业者分享了早期的成功案例和服务器目录，表明了构建者之间的基层吸引力。
这不是一个必然的结论，但方向是有希望的：一个减少重复工作的标准主导层正是生态系统所需要的。
MCP 如何在 2025 年融入您的技术栈
- 如果您要交付一个绑定到一个 LLM 供应商的单个 copilot：从本机函数调用开始；在您预见到多环境重用时引入 MCP。
- 如果您正在构建平台功能（内部或面向客户）：尽早采用 MCP 以避免定制适配器；为核心系统发布内部服务器。
- 如果您正在运行 agent 框架：使用 MCP 作为工具平面；使用您首选的框架进行规划/内存。
- 如果您需要严格的治理：从一开始就使用企业身份验证、权限和审计层包装 MCP 服务器。
顺便说一句，如果您的团队在浏览器中进行原型设计并且需要将模型连接到 Web 内容、PDF 和编码工作流程，值得注意的是，Sider.AI 可以充当前端 copilot，同时将工具访问委托给像 MCP 服务器这样的标准化后端——帮助您将 UX 与集成层分离，同时在标准演进过程中保持灵活性。
一个实用的推广计划（90 天）
- 第 1-2 周：选择两个高价值工具（例如，搜索 + 数据库读取）并定义模式。构建具有身份验证的最小 MCP 服务器。
- 第 3-4 周：连接内部聊天 UI 或 IDE 插件；与 5-10 个用户一起测试。检测日志并添加防护措施。
- 第 5-6 周：添加两个更多工具（例如，带有审查关卡的票务 + 文件写入）。记录版本控制和服务水平协议 (SLA)。
- 第 7-10 周：使用真实工作流程进行试点（支持分类、销售问答或代码重构）。测量节省的时间和错误率。
- 第 11-12 周：生产化：可观察性、速率限制、机密管理、灾难恢复和私有服务器注册表。
结论：您应该押注 MCP 吗？
简短的回答：是的——如果您关心跨模型和应用程序的可移植性、治理和可重用性。MCP 不会取代您的 agent 逻辑或您的提供商 API，但它为您提供了一致的工具平面，从而减少了集成成本并加速了多界面 copilot。
需要谨慎的地方：安全性和运营成熟度。如果您处于受监管的环境中，请构建您的控制措施，并将 MCP 服务器视为一流服务——而不是 sidecar。
需要关注的事项：开源服务器的增长、IDE/客户端支持以及更清晰的授权和可观察性最佳实践。如果这些加速发展，MCP 将成为将 AI 连接到现实世界的默认方式。
主要收获
- 模型上下文协议标准化了模型访问工具和数据的方式，减少了胶水代码并提高了可移植性。
- 它作为跨 IDE、聊天应用程序和 agent 运行时的共享工具平面最强大；它不能替代规划框架。
- 早期的生态系统吸引力是真实的，但企业应该分层安全性、治理和可观察性。
- 如果您已经在使用 agent 框架或多模型堆栈，MCP 可以自然地适应并可以快速获得回报。
词汇表（快速入门）
- MCP 服务器：通过模型上下文协议公开工具/资源的服务。
- MCP 客户端：发现并调用服务器功能的应用程序（IDE、聊天 UI、agent 运行时）。
- 工具：模型可以通过客户端调用的结构化、类型化操作。
- 资源：通过标准化接口公开的外部数据（文件、数据库行、文档）。
常见问题解答
Q1：什么是 AI 中的模型上下文协议？
模型上下文协议是一个开放标准，它定义了 AI 模型如何通过一致的接口访问外部工具和数据。它将模型行为与定制集成分离，从而实现可重用的服务器和跨应用程序和模型的可移植工具访问。
Q2：MCP 与 OpenAI 函数调用相比如何？
OpenAI 函数调用是特定于供应商的，非常适合与单个提供商快速集成。MCP 是模型无关的，并且标准化了跨环境的工具访问，使其更适合多模型或多界面 copilot。
Q3：模型上下文协议是否已为企业做好生产准备？
它很有前景，但仍在成熟。企业可以通过分层安全性（身份验证、权限、可观察性和治理）来采用 MCP，同时监控生态系统最佳实践和服务器注册表。
Q4：MCP 可以取代 LangChain 或 agent 框架吗？
不能。MCP 标准化了工具和资源平面，而像 LangChain、AutoGen 或 Semantic Kernel 这样的框架处理规划和编排。它们是互补的：使用 MCP 将工具公开给您选择的框架。
Q5：模型上下文协议的实际用例是什么？
常见的用例包括具有安全文件访问权限的 IDE copilot、从 CRM 和知识库读取的企业 copilot、通过批准的内容进行检索以及诸如工单分类或操作手册执行之类的运维自动化。
