快速理解 MCP（模型上下文协议）核心价值

作者：柯杰

前言

最近 MCP 突然火了（其实很早就出来了，只是因为被几个热门应用集成后才迎来爆发），大量人员参与进来后信息就杂乱了。有很多错误的认知和判断在自媒体渠道传播，把 MCP 简单理解成大模型的 Tool，跟 Function call 放到一个层面对比，这种认知有很大的错误。我自己主导开发过亿级设备同时在线 &千万 QPS 的高可用网络服务（https://archsummit.infoq.cn/2019/shenzhen/presentation/1769 ，也主导过 Agent 构建平台开发（https://aicon.infoq.cn/202412/beijing/presentation/6195 ）。本文从协议和 Agent 视角帮助大家快速理解 MCP（模型上下文协议），尝试纠正一些错误认识。如果有不对的地方，也欢迎指正。

MCP 分析

MCP 全称是 Model Context Protocol，核心是 Context，而不能简单理解成 Tool。以下从 Agent 框架层面的能力类别来理解 MCP 对于 Agent 的价值：Agent 框架核心能力 MCP 关键特性工具（技能）调用 ToolLUI 交互 Prompt 感知（Perception） Resource（Changed Notification）深度思考/DeepResearch Resource（Listing/Reading Resources）

Tool 和工具调用的关系好理解，就不展开，以下分别介绍 Resource 和 Prompt 在深度思考、感知、LUI 交互层面可以发挥的作用。

2.1 LUI

交互在 Agent 产品走深向实的必经之路中，很对 LUI 的交互里，缺乏传统 GUI 的导航栏，导致用户不知道怎么使用。一个典型案例是：Siri 集成应用能力之后，支持大量的指令，但是你知道有哪些吗？真的会用大量 Siri 指令吗？通过 MCP 的 Prompt 特性，可以在 UI 层做指令提示，帮助用户理解 Agent 功能，并学会如何使用对应的 Agent。MCP 的 User Guide 中也给出了 UI 集成的建议，帮助大家理解 Prompt 的作用。Agent 架构中交互部分实践参考

2.2 感知（Perception）

Agent 框架的感知能力

2.3 深度思考

在 Agent 框架需要解决的问题中，既有有简单的工具调用，比如查看天气；也有复杂的推理任务，比如“分析餐饮行业现状、机会与趋势”这类复杂任务。对于复杂任务来说，推理框架如果具备访问原始数据的能力（Resource），而不是简单的工具调用（Tool），可以在 query-read-reasoning-query-read... 的多轮迭代中产生更好的效果。做过深度思考或者 DeepResearch 的人应该能理解 MCP 的 Resource 定义中，可以感知 resource meta，并且可以 listing resource、reading resource，还可以有泛化的 pagination 能力，在复杂推理任务中相比 Tool 可以带来的巨大价值。

3. MCP 的未来

随着 AI 领域从业者的重心逐渐从模型转向应用时候，Agent 访问外部数据、用户交互能力的缺失问题逐渐被更多人看到，也因此催生了 MCP 这种标准协议的诞生。但是 MCP 的成功还有很长一段路要走，不是「有真实痛点的方案」就一定能成功。熟悉 IoT 领域的人也知道，过去很多大企业构建了 IoT 联盟，但是因为各种原因还是分裂成各厂商独立的技术体系。因此，我们还是要理性的看待这种技术变革。短期内快速适配 MCP 应对 Context 数据交互问题是可以的，长期来看还有非常大不确定性。毕竟标准协议和通用框架设计过早，无法满足未来更复杂场景从而淹没在历史的长河中，这样的案例太多了。