ARTICLE · 981126
MCP到底有什么用?换一个AI,工具为什么又要重新接?
MCP到底有什么用?换一个AI,工具为什么又要重新接?继续沿用我们的模拟客服AI。 上一期刚接好查询订单、查询物流和创建工单三个工具，新的需求又来了： 客服AI要用，IDE里的AI助手要用，运营部门正在试用的另一个AI也想用。 功能明明还是那三个，我却要换一种格式重新描述工具、处理调用结果，再单独适配认证方式。 同一个订单接口，像被要求配三种不同的插头。 做到这里，我才发现，麻烦已经不在订单接口了，而在AI和工具中间那层重复连接。 如果换一个AI，就要重新接一遍工具 Function Calling解决了一个重要问题： 模型能够根据用户的问题，判断要调用哪个函数，并生成函数需要的参数。 例如用户问： “订单20260828001到哪里了？” 模型可以提出调用queryOrder，并带上订单号。 Java程序执行查询，再把结果交给模型回答。 在一个客服系统里，这套流程已经能用。 可当另一个AI应用也想调用queryOrder时，它可能有自己的工具格式、连接方式和返回结果要求。 再换一个客户端，又要重新适配。 如果有十个工具、五个AI应用，连接关系很容易越写越乱。 这就像每家电器公司都设计自己的插座。 电视能插A口，冰箱只能插B口，换个房间还得重新买转换器。 大家缺少的不是更多插头，而是一套共同认可的连接方式。 MCP就是来处理这件事的 如果我们把查询订单、读取文件、创建工单这些能力，按照一种统一的格式对外提供，会怎样？ 支持这种格式的AI应用连接进来后，可以先询问： “你这里有哪些能力？” 服务端回答： “我能查询订单、查询物流，还能创建工单。这些工具分别需要这些参数。” AI应用理解以后，就可以选择合适的工具并发起调用。 这套连接规范，就是MCP。 MCP全称Model Context Protocol，中文通常叫模型上下文协议。 它是一套连接AI应用与外部数据、工具和服务的开放标准。 简单理解，MCP想做的事情，就是给AI工具准备一个相对统一的插口。 MCP里面到底装了什么？ 继续看查询订单的例子。 我们可以搭建一个订单MCP Server，对外提供三类东西： Resources，也就是可以读取的资料和数据。 Tools，也就是可以执行的能力，例如查询订单、创建工单。 Prompts，也就是预先准备好的提示模板或使用方式。 客服AI所在的应用负责连接这个MCP Server，获取它公开的能力。 当用户询问订单时，大致会经历： AI应用连接订单MCP Server。 MCP Server告诉它有哪些工具。 模型判断需要调用queryOrder。 客户端把订单号发送给MCP Server。 MCP Server再调用原来的订单API。 查询结果返回给模型，最后生成客服回复。 真正访问订单系统的，依然是我们原来的Java服务和业务API。 MCP没有把订单接口变没，也没有代替Function Calling。 它主要统一的是AI应用发现、理解和使用外部能力的方式。 API解决系统之间怎么通信。 Function Calling解决模型想调用哪个函数、需要什么参数。 MCP解决不同AI应用如何用更统一的方式连接、发现和调用这些外部能力。 为什么很多公司开始开放MCP？ 看到这里，外面越来越多公司提供MCP Server，就不难理解了。 第一，它们不想为每个AI应用单独写连接器。 做好一个MCP入口，理论上可以让多个支持MCP的客户端连接，减少重复适配。 第二，它们希望自己的产品进入用户正在使用的AI工作流。 以前我们要打开网站，找到页面，再点击功能。 接入MCP后，用户可能直接在AI助手里说： “帮我看看这个项目有哪些未关闭的问题。” “查询最近几笔支付记录。” AI就能通过官方提供的工具完成操作。 GitHub提供官方MCP Server，让AI工具能够在权限范围内访问代码仓库、Issue和Pull Request等能力。 Stripe也提供MCP Server，让AI Agent调用部分支付相关工具并查询知识资料。 公司开放MCP，等于为自己的产品增加了一个AI入口。 第三，官方自己提供，比用户到处找第三方插件更容易控制权限、版本和操作范围。 哪些功能能读取，哪些功能能修改，调用时需要什么身份，都可以由服务提供方明确规定。 开放MCP，不等于开放数据库 “MCP是开放协议”很容易让人产生另一个误会： 公司是不是把数据免费开放给所有AI了？ 当然不是。 有些公司会开源MCP Server代码，有些只提供远程MCP服务。连接以后，通常仍然需要登录、授权或者配置访问凭证。 你能看到哪些数据、能调用哪些工具，依旧受账号权限控制。 MCP更像给大楼修了一个统一规格的大门。 有门，不代表谁都能进；门禁、工牌和访问记录仍然存在。 安装陌生的MCP Server也不能只看功能多不多。 它可能接触文件、代码、订单甚至支付数据。优先选择官方来源，检查它公开了哪些工具，只授予必要权限，涉及修改、删除和付款的操作保留人工确认。 回到最开始的模拟项目。 查询订单、查询物流和创建工单这三个功能，不需要消失，也不用全部重写。 我们可以在原有API外面增加一个MCP Server，把这些能力按照统一协议提供出去。 以后支持MCP的客服AI、IDE助手或者其他应用，都有机会通过同一种方式连接它们。 Function Calling像教一个AI怎么使用工具。 MCP更像把工具箱做成大家都看得懂的规格。 这也是很多公司愿意开放MCP的原因：它们开放的不是全部数据，而是一个受权限控制、能进入更多AI应用的官方入口。