作者 | Gil Feig
编辑 | 云昭
出品 | 51CTO技术栈（微信号：blog51cto）
AI 助手在产品体验中的重要性日益凸显，而一种新的标准也应运而生，它助力 AI 助手的构建：模型上下文协议 (MCP)。随着 Anthropic、OpenAI 和 Gemini 等主流大型语言模型 (LLM) 提供商的采用，该协议迅速在更广泛的软件生态系统中获得了广泛关注，各大公司纷纷构建自己的 MCP 服务器。
作为参与构建 MCP 服务器和 API 集成的人员，我亲眼目睹了这种快速采用导致的混乱。一些开发人员和产品经理将 MCP 视为 API 的替代品，而另一些人则认为 MCP 不如 API。
实际情况则更加微妙：MCP 和 API 是互补的。许多设计良好的 AI 系统都需要两者，而一些 AI 工程师构建的系统可能并不足以支持使用 MCP。
为了帮助您了解哪种解决方案适合您的特定场景，我将解释每种解决方案的工作原理、局限性以及它们如何协同工作。
1.MCP 和 API 如何协同工作
MCP 的核心是为大型语言模型与外部数据源交互提供一种标准化的方式，但这些交互通常通过现有的 API 进行。当 LLM 从 MCP 服务器调用某个工具（例如在 Jira 中创建工单）时，仍然会向相关的 Jira 端点发出 API 调用。
Hasura 通过即时编写由数据库和服务支持的 GraphQL API，简化数据访问，从而使开发团队（或 API 使用者）能够立即投入工作。GraphQL 本身的特性以及 Hasura 的动态方法使集成和迭代变得简单。
MCP 的价值在于它能够管理 LLM 与数据源之间的上下文。它提供了一个标准化的框架，用于：
- 工具选择和调用： MCP 允许 LLM 根据用户提示动态选择使用哪些工具，而不需要硬编码的 API 调用。
- 上下文保留：该协议帮助 LLM 保留、更新和获取上下文，这对于管理多步骤工作流程至关重要。
- 简化交互： MCP 通过提供标准协议使 LLM 和应用程序更容易集成。
同时，API 仍然处理核心数据传输、身份验证流程和与不同应用程序的连接。
2.MCP 的安全挑战需要 API 级解决方案
MCP 灵活开放的架构带来了独特的安全挑战。开发人员希望使用尽可能多的工具（API 端点）。这导致密钥通常可以访问电子邮件、机密规划工具和销售数据等敏感服务。再比如，LLM 可能会误认为字段标签（将“SN”误认为是社保号码而不是姓氏），从而无意中泄露敏感数据。
为了防止此类情况发生，工程师需要集成访问控制级别、模式执行和数据丢失防护。最有效的方法是将 MCP 的上下文管理功能与强大的 API 基础架构相结合。
例如，API 提供商的身份验证方法（例如 OAuth 2.0）使 LLM 能够确认用户是否具有访问底层 API 端点所需的权限。API 提供商的响应代码可以帮助您的 LLM 诊断和解决问题（例如，在请求失败时向用户发出警报并提供解决方案）。
3.大多数 AI 用例仅需要 API
我看到一些 AI 团队采用 MCP 来掩盖更深层次的问题，例如混乱的检索系统、失控的提示链以及团队间缺乏清晰的约定。他们没有修复架构，反而增加了另一层，导致抽象程度更高，清晰度更低。
这些 AI 团队目前还不需要 MCP；他们只需要（通过构建强大的 API 集成）清理他们的提示和数据管道。如果一个团队仅仅使用 MCP 来组织基础设施层，那么现在可能还为时过早。
当您能够应对复杂性时，MCP 会非常强大：需要处理多个模型、数据源和下游消费者，并且需要结构化的合约。但在此之前，请先考虑在整个基础架构中构建一致性，然后实施自动化的归档、重复数据删除和权限管理策略，以减少手动开销并保持秩序。
4.API必不可少，MCP是暂选项
随着我们构建日益复杂的人工智能助手，理解 MCP 和 API 在集成生态系统中是互补的层至关重要。
MCP 提供上下文管理层，帮助 LLM 更有效地与外部系统交互，而API 则提供与这些系统安全可靠的连接。
认识到两者的关系对于成功构建AI产品至关重要。盲目追求 MCP 的做法并不可取，我们需要在构建有效的 MCP 实现之前，还得投入精力构建够硬的 API 基础设施、有组织的检索系统和标准化约定。
参考链接：
https://thenewstack.io/author/gilfeig/
