在大模型开发中，MCP（Model Context Protocol，模型上下文协议）是一种开放协议，由 Anthropic 公司于 2024 年 11 月推出并开源。它旨在实现大型语言模型（LLM）应用与外部数据源、工具和服务之间的无缝集成。MCP 协议的核心在于模型上下文，也就是 LLM 在运行过程中所需的所有外部信息和工具，包括数据库、API、文档库等外部数据源，以及计算工具、搜索引擎、第三方服务等。通过 MCP 协议，LLM 应用能够动态访问和集成这些外部资源，从而增强模型的功能性和灵活性。
MCP 协议的工作原理是，当 LLM 应用需要外部数据或服务时，它会向外部资源发送上下文请求，这个请求包含了所需的数据或服务类型。外部资源接收到请求后，会返回相应的上下文数据，LLM 应用再将这些数据集成到模型中，用于生成响应或执行任务。此外，MCP 协议还支持动态管理 LLM 的对话上下文，确保在多轮对话中保持连贯性。
MCP 协议的优势在于它能够减少开发时间，因为开发人员可以利用预构建的 MCP 服务器完成常见任务，而不是为每个数据源或工具构建自定义集成。同时，它增强了互操作性，使用 MCP 构建的应用程序可以与任何兼容的工具和数据源无缝协作，从而创建一个真正可组合的生态系统。此外，MCP 协议的模块化设计使得调试、授权、审计和链接等关注点可以标准化并实现一次，然后在整个生态系统中重复使用。总之，MCP 协议通过标准化模型与外部资源的交互方式，提升了 LLM 应用的功能性、灵活性和可扩展性。
MCP （Model Context Protocol，模型上下文协议）定义了应用程序和 AI 模型之间交换上下文信息的方式。这使得开发者能够以一致的方式将各种数据源、工具和功能连接到 AI 模型（一个中间协议层），就像 USB-C 让不同设备能够通过相同的接口连接一样。MCP 的目标是创建一个通用标准，使 AI 应用程序的开发和集成变得更加简单和统一。
官方给了一张图可以参考：
结合这个图更加容易理解。MCP就是大模型和待访问的外部资源或工具之间的一个中间层，这个中间层类似Hub集线器，起到了统一标准，统一接口和适配的作用。这样大模型就可以更加方便地调用和使用外部资源或工具。
当看到这里后，大家会有一个疑问。
就是这个MCP感觉和大模型原来能力扩展用到的Function Call的概念相对类似。那么为何还要搞一个MCP协议？
这里面的关键就是原来采用Function Call模式的适合，大模型为了访问外部的资源或工具，都需要定制开发一个Function Call，哪怕是同一个资源，往往由于使用场景，操作系统，语言等不同，都还需要开发不同的适配接口。也这是这个原因极大限制了大模型的能力扩展。
而现在有了MCP协议后，等于统一构建了一个标准统一的API能力层，更加方便大模型按某种标准统一的接口方式来访问外部资源和工具。任何资源的访问都涉及到客户段和服务器端，大家都按统一的标准进行开发，无须再进行额外的开发适配工作。对于可以复用的API能力，只要开发好相应的MCP Server接入即可，后续只要写MCP Client端直接调用即可。
也就是说再MCP出来之前，大模型要调用外部工具（/API）最简单的是利用大模型本身的Function Calling功能，比如查询天气，但问题在于没法复用，我写好一个查询天气的tools，你要用可能还要写一遍或者很麻烦，这时候MCP就提出来了，大家都遵循统一的协议，一个人写好了一个工具，发布出来作为MCP服务端，其他人只需要按协议写个客户端调用就可以复用了。
因此MCP极大地方便了传统AI智能体的开发效率或者大模型能力扩展。
所以从上面图也可以看到，大模型对搜索引擎的访问，对Github的访问，对本地数据库，文件系统的访问等都可以通过基于MCP协议扩展MCP Server来完成。而且做到足够的标准化和统一。
MCP协议本身是做Claude大模型的Anthropic厂家提出的，其他大模型厂家是否会快速跟进，包括能够快速形成MCP生态暂时不谈。至少我们从上图可以看到通过MCP协议，真正实现了大模型对外部资源访问的标准化和适配。这个本身是大模型能力扩展的关键，也是为何在原来已有Function Call情况下还需要MCP的原因。这将极大减少大模型访问外部资源的开发和适配工作量。当然随着MCP生态的不断完善，可复用的MCP Server和API能力也会越来越丰富，这将更加方便AI Agent厂商进行AI应用的开发。
那么再回来看通用大模型为何要进行能力扩展？
简单来就是大模型本身的知识库能力欠缺两个关键的东西。一个就是企业或个人私有知识库的内容，一个就是实时发生的信息内容。这两个点大模型已经在解决，类似当前大模型都增加了添加附件或结合RAG做增强检索，也增加了联网搜索的能力来解决这两个问题。
但是这往往并没有完全解决问题。类似当前有一个企业第三方信用查询库，这个本身是不开放的，类似查询明天的天气，这个虽然可以通过网页搜索和爬取到，但是我们更加希望是调用类似Web API方式精确获取。
这些内容实际都需要大模型扩展外部工具和资源的能力。特别是大模型走向企业内部应用场景的适合，企业已有的知识库，已有的IT系统，已有的数据湖和数据中台，往往都是提供核心私有领域资源和数据的关键。
但是各个企业这种私有知识大模型该如何获取？
显然，大模型本身是不可能对于不同的企业都去单独定制和开发不同的Function Call来获取资源的，企业内部也不可能基于不同的AI应用不断的开发和企业内部资源工具对接的各种Function Call接口。
因此这就需要制定统一的标准规范体系，接口协议等。就是上面说到的MCP协议，只要企业按照MCP协议将企业资源开发为了MCP Server提供，那么这些资源都可以很方便的接入到大模型里面来。大模型也可以很方便的访问到这些资源，不同的AI智能体也可以充分共享和复用这些MCP Server提供的能力。
传统情况下，为了弥补大模型能力的不足，最简单的方式就是我们自己开发AI Agent应用，在AI应用的开发中我们可以自己写代码来获取外部资源，来实时调用外部接口，然后将获取到的信息再通过大模型提供的API接口输入给大模型并获取反馈。
也就是通过AI Agent应用扩展代码来解决了获取外部资源或工具的问题，但是这种情况下大模型本身更像是要给能力提供单位，等着被上层的AI Agent调用。实际对于复杂问题的规划，分解，行动，思考是在AI Agent这个地方完成的。这样大模型本身的深度思考和深度推理价值并没有真正发挥出来。
在这里就不得不谈到英伟达最近谈到的代理式AI的概念，我先摘录官网里面的对这个概念的一个简单解释如下：
人工智能的下一个前沿是代理式 AI，它使用复杂的推理和迭代规划来自主解决复杂的多步骤问题，将提升各行业的生产力和运营效率。代理式 AI 系统从多个来源获取大量数据，独立分析挑战、制定战略，并执行供应链优化、网络安全漏洞分析以及帮助医生完成耗时工作等任务。
代理式 AI 使用四步流程来解决问题：
感知：AI 智能体收集并处理来自传感器、数据库和数字接口等各种来源的数据。这包括提取有意义的特征、识别对象或确定环境中的相关实体。
推理：大语言模型充当编排器或推理引擎，它会理解任务、生成解决方案并协调用于内容创建、视觉处理或推荐系统等特定功能的专门模型。此步骤使用检索增强生成 (RAG) 等技术来访问专有数据源并提供准确、相关的输出。
行动：通过应用程序编程接口与外部工具和软件集成，代理式 AI 可以根据其制定的计划快速执行任务。可以在 AI 智能体中建立护栏，以帮助确保正确执行任务。例如，一个客户服务 AI 智能体可以处理一定金额内的索赔，而超过这个金额的索赔必须由人类审批。
学习：代理式 AI 通过反馈循环或“数据飞轮”持续改进，将交互中生成的数据反馈入系统以增强模型。这种随着时间的推移而逐渐适应并变得更加有效的能力为企业提供了一种强大的工具，能够提升决策制定和运营效率。
当我们看到这个内容的时候，大家是否会感觉我前面Manus搞的通用AI智能体概念很类似。即面对企业真实业务场景，我们往往需要的是具备深度思考和推理能力，具备任务分解规划能力，具备基于不同问题需求灵活调用外部资源和工具能力的一个端到端AI应用。而不是说出现任何一个新的业务场景，我们都需要去新开发一个AI Agent才能够解决。
所以我提到，在大模型具备深度推理能力后，企业级AI应用目标是构建一个通用性AI智能体，提供面向业务场景和问题的端到端输出，在这个过程中需要进行问题规划理解，拆分，行动，归纳总结，复盘，记忆能力。企业级AI应用不应该是再开发一个个独立的AI Agent信息孤岛。
MCP Sever能力接入可以穷举，但是AI Agent定制化开发难以穷尽，一个个去开发Agent思路将被淘汰，这个本质仍然是开发了大量上层的AI应用信息孤岛。
因此在类似MCP协议的东西出来后，其实是给大模型和企业之间搭建了一个资源和能力访问的中间层。这个中间层让大模型访问企业内部资源，数据库，文件，工具更加方便和容易。而企业要做的事情也很简单，就是遵循MCP协议标准开发不同类型的MCP Server将能力暴露出来即可。也就是我前面谈到的有了MCP，包括基于MCP形成了完整的生态体系后，大模型不再是被动的等待AI Agent调用，而是可以主动出击去访问需要的工具或资源。
大家可以在参考下面这张图：
也就是说MCP Client这个能力即可以是在单独开发的AI Agent智能体里面，也可以本身就内嵌在大模型里面。大模型的发展演进本身就包括了自己逐步发展为一个通用性质的AI智能体的能力。
原来为什么不行？原因仍然是大模型对外部资源访问能力受限导致。如果MCP生态足够强大，那么这个问题就可以很好的解决。
再次强调下我的观点，随着MCP生态的完善，和MCP Server能力提供的不断丰富。原来针对不同场景都要做独立的AI Agent，后续这个动作不需要，大模型具备深度思考能力，应该逐步演变适合企业场景的通用性AI Agent，而这个能力逐步下沉到了大模型内部。当前短期可能还是人工个性化定制AI Agent，远期一定是大模型内置通用性AI Agent能力。我们需要做的就是不断丰富接入资源，将其转变为MCP Server能力提供出去。
