• 随着大语言模型和 AI Agent 的普及,一个新的概念越来越频繁地出现在开发者视野中:MCP 服务。

    MCP 的全称是 Model Context Protocol,中文可以理解为“模型上下文协议”。它的目标是为 AI 模型和外部工具、数据源、系统能力之间建立一种标准连接方式。简单说,MCP 服务就是让 AI 能够安全、稳定、结构化地访问外部世界的一类服务。

    为什么需要 MCP

    大语言模型本身很擅长理解和生成文本,但它天然有几个限制:

    • 不知道你本地文件系统里的最新内容
    • 不能直接访问你的数据库
    • 不能自动读取公司内部文档
    • 不能直接调用业务系统 API
    • 不能天然知道当前应用的真实状态

    如果想让 AI 真正完成任务,就需要让它连接外部工具。比如:

    • 查询订单状态
    • 创建日历事件
    • 读取 GitHub Issue
    • 搜索本地代码库
    • 操作数据库
    • 获取 Slack 或飞书消息
    • 调用内部系统接口

    过去,每个 AI 应用都可能为这些工具单独写一套接入逻辑。这样会带来很多重复工作,也不利于权限控制和生态复用。

    MCP 想解决的正是这个问题:用统一协议连接模型和工具。

    MCP 服务是什么

    可以把 MCP 服务理解为一个“工具适配层”。

    它站在 AI 应用和外部系统之间,把外部系统的能力包装成模型可以理解和调用的工具。AI 应用不需要知道数据库、文件系统、第三方 API 的所有细节,只需要按照 MCP 协议发现工具、读取上下文、发起调用即可。

    一个 MCP 服务通常会提供三类能力:

    • Resources:资源,例如文件、文档、数据记录、代码片段
    • Tools:工具,例如查询、创建、修改、搜索、执行某个动作
    • Prompts:提示词模板,例如预设的工作流、任务模板、领域提示

    这些能力被 MCP 服务暴露出来后,支持 MCP 的 AI 客户端就可以发现并使用它们。

    一个简单类比

    如果把大模型看作一个聪明但不能离开房间的人,那么 MCP 服务就像房间里的标准接口。

    模型可以通过这个接口说:

    • 帮我读取这个文件
    • 帮我查一下数据库
    • 帮我调用这个 API
    • 帮我搜索项目里的某个函数
    • 帮我把结果保存下来

    而 MCP 服务负责真正执行这些动作,并把结果返回给模型。

    这样一来,模型不用直接接触底层系统,开发者也可以更清楚地控制它能做什么、不能做什么。

    MCP 的基本架构

    一个典型的 MCP 架构包含三个角色:

    AI 客户端  <->  MCP 协议  <->  MCP 服务  <->  外部系统
    

    其中:

    • AI 客户端:例如支持 MCP 的 IDE、桌面助手、Agent 平台或聊天应用
    • MCP 协议:定义客户端和服务之间如何通信
    • MCP 服务:负责暴露工具、资源和提示词
    • 外部系统:真实的数据源或业务系统,例如文件系统、数据库、GitHub、Notion、Slack 等

    MCP 服务可以运行在本地,也可以运行在远端。对于本地开发场景,MCP 服务常常用于访问本地代码、文件和开发工具。对于企业场景,MCP 服务可能连接内部系统,并配合身份认证和权限管理。

    MCP 服务能做什么

    MCP 服务的能力取决于它连接了什么系统。

    连接本地文件

    文件类 MCP 服务可以让 AI 读取、搜索或修改本地项目文件。对于编程助手来说,这非常重要,因为模型需要看到真实代码才能做出可靠判断。

    例如:

    • 搜索函数定义
    • 阅读 README
    • 修改配置文件
    • 分析项目结构
    • 生成文档

    连接数据库

    数据库类 MCP 服务可以让 AI 查询数据、分析表结构,甚至辅助生成 SQL。

    例如:

    • 查看某张表的字段
    • 查询最近订单
    • 分析数据异常
    • 生成统计报表
    • 辅助排查线上问题

    当然,数据库场景对权限和安全要求更高,通常需要限制只读权限或设置明确的审批流程。

    连接第三方平台

    MCP 服务也可以连接各种外部平台,例如 GitHub、Slack、Notion、Google Drive、Jira 等。

    这样 AI 就可以参与更完整的工作流:

    • 总结某个 GitHub PR
    • 创建 Jira 任务
    • 查询会议纪要
    • 根据 Slack 讨论生成行动项
    • 在知识库中搜索相关文档

    连接业务系统

    企业内部也可以开发自己的 MCP 服务,把订单、客服、风控、库存、财务等系统能力暴露给 AI。

    这类 MCP 服务的价值很高,因为它能让 AI 从“问答工具”变成真正能参与业务流程的助手。

    MCP 和 API 有什么区别

    MCP 并不是用来取代 API 的。更准确地说,MCP 是面向 AI 应用的工具连接协议,而 API 是面向软件系统的通用接口。

    普通 API 通常假设调用方是程序员写好的代码,参数、流程和错误处理都由开发者控制。

    MCP 则更关注:

    • 如何让模型发现有哪些工具可用
    • 如何描述工具的输入和输出
    • 如何把资源上下文提供给模型
    • 如何控制模型调用工具的权限
    • 如何让不同 AI 客户端复用同一个工具服务

    换句话说,API 是系统之间的接口,MCP 是模型使用外部能力时的一套标准化接口。

    很多 MCP 服务底层仍然会调用普通 API。MCP 的作用,是把这些 API 包装成更适合 AI Agent 使用的形式。

    MCP 和 Function Calling 有什么关系

    Function Calling 是很多大模型平台提供的工具调用能力。开发者可以告诉模型有哪些函数可以调用,模型根据用户意图选择函数并生成参数。

    MCP 和 Function Calling 的目标相似,都是让模型使用工具。但它们的层次不同:

    • Function Calling 更像模型厂商或推理平台内部的工具调用机制
    • MCP 更像客户端和外部工具服务之间的开放协议

    可以理解为:Function Calling 解决“模型如何决定调用函数”,MCP 解决“工具如何被发现、描述、连接和复用”。

    在实际系统中,二者可以配合使用。AI 客户端通过 MCP 发现工具,再把工具能力交给模型进行选择和调用。

    MCP 服务的优势

    MCP 服务最大的价值在于标准化。

    一次开发,多处使用

    如果你为某个系统开发了 MCP 服务,多个支持 MCP 的客户端都可以使用它。比如同一个 GitHub MCP 服务,可以被 IDE、桌面助手和自动化 Agent 共同使用。

    更清晰的权限边界

    MCP 服务可以明确暴露哪些资源和工具。开发者可以把能力限制在安全范围内,例如只允许读取某个目录,只允许查询某些数据,只允许执行特定操作。

    更适合 Agent 工作流

    AI Agent 往往需要多步操作:先查资料,再分析,再调用工具,再根据结果继续执行。MCP 提供统一的工具和上下文接口,有利于构建这种连续工作流。

    降低集成成本

    没有 MCP 时,每个 AI 客户端都要为每个外部系统写适配。使用 MCP 后,服务端只需要按协议暴露能力,客户端按协议接入即可。

    MCP 服务的风险

    MCP 让 AI 更有行动能力,也意味着需要更认真地处理安全问题。

    常见风险包括:

    • 模型误调用高风险工具
    • 敏感数据被暴露给不该访问的上下文
    • 工具权限过大
    • 写操作缺少人工确认
    • 日志中泄露密钥或隐私信息
    • 远端 MCP 服务身份认证不完善

    因此,设计 MCP 服务时要遵循最小权限原则。能只读就不要写入,能限制目录就不要开放整个文件系统,重要操作最好加入确认或审批。

    一个 MCP 服务示例

    假设我们要为一个内部订单系统做 MCP 服务,它可以暴露三个工具:

    get_order(order_id)
    list_recent_orders(user_id)
    create_refund_request(order_id, reason)
    

    同时暴露一个资源:

    order_policy.md
    

    当客服人员问 AI:

    帮我查一下订单 12345 为什么没有发货,如果符合规则就发起退款申请。
    

    AI 客户端可以通过 MCP 服务完成以下流程:

    1. 调用 get_order 查询订单状态
    2. 读取 order_policy.md 判断是否符合退款规则
    3. 向用户说明判断结果
    4. 如果需要退款,调用 create_refund_request

    这就是 MCP 的典型价值:把模型的理解能力和系统的执行能力连接起来。

    什么场景适合使用 MCP

    如果你的 AI 应用只需要普通聊天,可能并不需要 MCP。

    但如果你希望 AI 访问真实数据或执行真实操作,MCP 就很有价值。

    适合使用 MCP 的场景包括:

    • AI 编程助手访问本地代码库
    • 企业知识库问答
    • 内部系统自动化
    • 数据分析助手
    • 客服辅助工具
    • DevOps 自动排障
    • 文档、任务、消息平台集成
    • 多工具 Agent 工作流

    尤其是当你希望同一套工具被多个 AI 客户端复用时,MCP 的优势会更明显。

    如何开始学习 MCP

    学习 MCP 可以按下面的顺序来:

    1. 先理解 Resources、Tools、Prompts 三个核心概念
    2. 使用现成 MCP 服务,例如文件系统、GitHub 或数据库连接器
    3. 在支持 MCP 的客户端中观察工具如何被发现和调用
    4. 编写一个最简单的本地 MCP 服务
    5. 再逐步加入权限、日志、错误处理和身份认证

    不要一开始就做复杂系统。一个能读取本地文件、提供搜索工具的小服务,就足够帮助你理解 MCP 的核心思想。

    总结

    MCP 服务是一种把 AI 模型连接到外部工具和数据源的标准化方式。它让模型不只是“会说”,还可以在受控范围内“会查、会用、会做”。

    它的核心价值不是让 AI 获得无限权限,而是用清晰的协议和边界,让 AI 更安全、更可靠地参与真实工作流。

    未来,随着 AI Agent 越来越多地进入开发、办公和企业系统,MCP 这类标准协议会变得越来越重要。理解 MCP,也就是在理解下一代 AI 应用如何连接真实世界。

    上一篇:
    使用 LM Studio 在 macOS 上本地部署 Gemma 4
    下一篇:
    Android 12 行为变更
    本文目录
    本文目录