Agent领域又迎来新进展。
凌晨，OpenAI CEO Sam Altman突发公告，宣布将在旗下产品中支持竞争对手Anthropic提出的模型上下文协议（MCP）：“目前MCP已在OpenAI的Agents SDK中开放，ChatGPT桌面版和Responses API的支持也即将推出” 。
MCP被广泛认为是“AI工具集成的新标准”，两大巨头的合作意味着我们有望用统一的标准解决长期困扰AI应用的数据孤岛和工具集成难题。
可以预见，随着OpenAI比预期更快的支持MCP，MCP在模型调用工具资源方面已经成为行业事实标准。当Agent行业有了更统一的协议标准，行业还将迎来更快发展。
在这个时间点，锦秋基金参考了Anthropic的官方文档以及海外VC和媒体的研究与报道，尝试梳理出MCP的现状与未来展望，也试图梳理出Agent创业的可能机会与趋势。
如果你对这些话题感兴趣，也欢迎与我们沟通联系（gzh@jinqiucapital.com）
模型上下文协议（Model Context Protocol，MCP）是Anthropic于2024年11月率先提出并开源的开放标准 。通俗地说，MCP定义了一种让AI助手获取外部“背景信息”和执行工具操作的通用接口。
正如官方比喻所言，可以将MCP视作AI应用的“USB-C接口”——为各种工具和数据源提供统一的即插即用连接方式 。
过去，不同AI应用往往需要为每一个数据库、API或知识库开发各自的插件或集成代码；而MCP的愿景是“一劳永逸”，让任意LLM客户端和任意数据源服务器都遵循同一协议对话。
这将大大简化AI系统获取上下文信息和代替用户执行操作的机制。换句话说，MCP试图将过去AI集成领域繁杂的“M×N”对接问题，优雅地转化为“M+N”的标准化架构，使开发者不必管理每对组件的单独适配。
根据Anthropic的官方声明（“Introducing the Model Context Protocol,”anthropic.com, November 25, 2024），从技术架构看，MCP遵循轻量级的客户端-服务器模型。开发者可以将任何具有信息或功能的源头封装为“MCP服务器”，然后让AI助手作为“MCP客户端”来调用这些服务器 。
Anthropic的理念是：任何能为AI助手提供额外信息或功能的东西，都可以变成一个API工具，由LLM自主调用。
AI助手（也称AI Agent）通过调用这些标准化工具，就能统一实现各种扩展功能，而无需依赖繁琐的中间框架。MCP具体包括三类参与者 ：
MCP服务器（Server）：独立运行的微服务，每个MCP Serve负责一种特定能力或数据源，通过标准协议供AI访问。例如一个MCP服务器可以对应企业数据库、Slack消息库、Git代码库、文件系统甚至浏览器控制等 。服务器可在本地（访问计算机文件、数据库等）也可在远程（通过API访问在线服务）。
MCP客户端（Client）：嵌入在AI应用中的协议客户端，负责与上述服务器建立一对一连接并根据AI需求调用其提供的工具或数据 。每一个MCP客户端实例对应连接一个服务器，如同AI助手的“插件驱动”。
主控AI应用（Host）：运行AI助手或Agent的宿主程序，例如ChatGPT、Claude桌面应用、IDE插件或任何需要外接能力的AI应用 。主控应用可以启动多个MCP客户端去连不同服务器，实现同时接驳多个工具。
借助MCP，LLM与外部世界之间多了一层标准化“桥梁”，让AI拥有了标准化的“触手”，可以伸向各种数据库、应用和工具箱汲取养分，再为我们提供更聪明的服务。它所带来的是一场AI上下文交互的标准化革命，为下一代AI应用奠定了开放集成的基石。
MCP赋予了AI两大关键性的扩展能力：感知环境与影响环境。
一方面，通过标准化的协议，AI能够实时连接并安全地访问外部数据源，无论是企业内部的业务数据库（如库存、交易记录）、实时传感器读数，还是互联网上的公开API，从而摆脱训练数据的时效性限制，获取最新、最动态的信息。
另一方面，MCP使AI不再仅仅是信息的提供者，更成为了行动的执行者，能够调度和操控外部软件工具来完成具体任务，例如调用API发送消息、修改数据库条目、操作日程应用或执行自动化脚本。
此外，MCP还提供了便捷的用户上下文注入机制，允许AI在获得授权的前提下，访问用户的个人数据（如历史对话、偏好设置、本地文件）或企业内部的知识库、文档，从而提供高度个性化和情境感知的响应。
这三大基础能力共同构成了MCP的核心价值，让AI能够更紧密地融入实际工作流，提供更智能、更实用的服务。
在这些基础能力的支撑下，业界已经涌现出一系列具体的实践范式和创新的应用模式，在a16z 最新的文章《A Deep Dive Into MCP and the Future of AI Tooling》里，作者Yoko Li提出了一些他的看法。他认为：
赋能开发者中心化工作流：
对于开发者群体而言，频繁的上下文切换是降低效率的一大痛点。MCP为此提供了理想的解决方案，允许开发者在他们熟悉的集成开发环境（IDE）中无缝集成和调用外部工具与服务。
例如，开发者可以直接在IDE内，通过专门的MCP服务器执行数据库查询（如Postgres MCP服务器）、管理缓存（如Upstash MCP服务器），或利用浏览器工具（如Browsertools MCP）进行实时调试，访问控制台日志等信息，而无需离开当前编码环境。这种“本地优先”的工作流显著减少了中断，提升了开发效率。
更进一步地，MCP还催生了自动生成服务器的新范式：通过爬取文档或API规范，可以快速生成MCP服务器，使得编码代理能够即时获得高保真度的上下文信息或直接调用工具能力，极大减少了手动集成和编写样板代码的负担。
催生多功能应用与创新体验：
MCP的潜力远不止于连接现有工具，它正在推动客户端应用本身向“万能应用”演进，并创造全新的用户体验。
以代码编辑器Cursor为例，作为MCP客户端，用户可以通过加载不同的MCP服务器，将其转变为具备Slack消息收发、邮件发送（Resend MCP）、甚至图像生成（Replicate MCP）等多种能力的集成工作站。
更具想象力的是，在单一客户端中组合多个MCP服务器可以解锁复杂的新流程，例如，让AI代理一边生成前端界面代码，一边调用图像生成服务器为主页创作视觉元素。这种模式超越了传统应用的单一功能限制。
同时，MCP也在降低专业工具的使用门槛，普惠更广泛的用户群体。虽然初期用例多集中于开发者，但像Claude Desktop这样的客户端正成为非技术用户接触MCP强大能力的入口。
可以预见，未来将涌现更多面向特定业务场景（如客户支持、营销内容创作、设计辅助）的专用MCP客户端。
客户端本身的设计及其支持的交互方式，对最终的用户体验起着决定性作用。例如，Highlight通过创新的@命令允许用户在客户端内调用任意MCP服务器，并将生成内容无缝传递到下游应用（如Notion），形成新颖的UX模式。
另一个引人注目的例子是Blender MCP服务器，它使得几乎不具备3D建模知识的用户也能通过自然语言描述来创建模型。
随着社区为Unity、Unreal Engine等更多工具构建服务器，我们正实时见证着从文本到3D内容生成等创新工作流的诞生与普及，这预示着MCP将深刻重塑人与数字工具的交互方式。
桥接现有集成平台，激活海量应用生态：
MCP的标准化特性使其能够高效对接现有的成熟集成平台，Zapier 的实践即是典型代表。
根据Zapier官网（https://zapier.com/mcp）的解读，Zapier MCP 充当了一座桥梁，允许任何兼容 MCP 的 AI 助手（如 Cursor、Claude Desktop 等）连接到 Zapier 平台上超过 7,000 款应用和 30,000 多种预设动作的庞大生态系统。
这种方式巧妙地规避了为 AI 单独开发海量应用接口的巨大复杂性，直接复用了 Zapier 已有的集成能力。
用户在 Zapier 中预先配置并授权 AI 可执行的具体操作（例如，“向 Slack 特定频道发送消息”、“在 Jira 指定项目中创建任务”），包括选择账户、限定参数等，然后将生成的安全 MCP 服务器 URL 添加到 AI 客户端。
当用户向 AI 下达指令时，AI 通过 MCP 与 Zapier 通信，由 Zapier 安全地执行已授权的操作。
这使得 AI 不再局限于对话，而是能直接在用户的指令下，于各类业务软件中执行实际任务，如项目管理（Jira, Asana）、客户关系管理（Salesforce, HubSpot）、通信协作（Slack, Teams, Gmail）、数据处理（Google Sheets）乃至版本控制（GitHub）。
Zapier MCP 的实践极大地降低了将 AI 融入日常业务流程的技术门槛，将 AI 助手转变为能够跨应用执行任务的强大工作流引擎。
虽然MCP生态尚处早期，但其围绕协议构建的具体形态已开始显现，为前述各类参与者的商业机会提供了初步的落地场景和支撑体系。这个新兴的生态系统不仅包括协议的核心——客户端与服务器，更囊括了日益关键的基础设施层以及勇于探索的早期采用者。
a16z的《A Deep Dive Into MCP and the Future of AI Tooling》文章里，也进行了详细阐述。
客户端与服务器现状：目前，高质量的MCP客户端实现多集中在以编码为核心的场景（如前文提及的Cursor等IDE集成），这反映了开发者社区作为技术先行者的普遍规律。服务器端则呈现出“本地优先”和面向单用户的早期特点，这与协议早期基于SSE等技术的实现有关。但随着协议的成熟和未来可能采用如Streamable HTTP等更灵活机制，预计客户端将向更广泛的业务场景（如客服、营销）拓展，服务器的应用范围和部署模式也将极大丰富，吸引更多服务商将其能力封装为标准MCP接口。
加速构建的基础设施层：为了支撑MCP生态的繁荣，一系列关键基础设施正在快速成型：
发现与市场：类似npm之于JavaScript或RapidAPI之于API经济，MCP市场和目录服务正崭露头角，例如 Mintlify的mcpt、Smithery、OpenTools 等平台，它们旨在让开发者更容易发现、分享和复用MCP服务器（连接器），这对于标准化访问和实现AI代理按需调用工具至关重要。
开发与生成工具：为了降低构建门槛，Mintlify、Stainless、Speakeasy 等公司提供了服务器生成工具，帮助开发者快速将现有数据源或API封装成MCP兼容的服务。
托管与扩展：随着应用增多，服务器的部署、扩展和稳定性成为焦点。Cloudflare、Smithery 等提供的托管解决方案正着力应对这些挑战。
连接与管理：特别是在本地优先的场景下，连接和密钥管理的复杂性需要简化。Toolbase 等平台开始提供此类连接管理方案。 这些基础设施的完善，将极大提升MCP生态系统的可扩展性、可靠性和易用性。
早期采用者的实践探索：尽管MCP尚属新鲜事物，但已有不少前瞻性企业和开发者工具开始集成实践，验证其价值：
Block 公司正利用MCP构建自动化代理系统，旨在消除重复性的机械任务。
开发者工具领域的 Zed、Replit、Codeium、Sourcegraph 等正积极与MCP合作，通过让AI代理更精准地检索代码上下文，来增强其核心功能。
Confluent 则构建了直连其数据流平台的MCP服务器，使AI代理能用自然语言与实时数据交互。
此外，Apollo 等公司也在积极探索MCP的集成应用。 这些早期采用者（通常与Anthropic等协议主要贡献者合作）的实践不仅展示了MCP的实际优势和广泛适用性，其用例和经验也为后续更大范围的采纳提供了宝贵的参考和动力。
MCP激活了一个繁荣的生态系统：开发者、平台商、数据方、集成商各得其所，共同做大AI应用市场的蛋糕。这也印证了一个洞见：在AI时代，竞争优势将更多来自生态位置而非单点技术。
MCP面临的争议
尽管MCP凭借Anthropic的推动和OpenAI等巨头的迅速支持，正快速成为AI调用外部工具和数据的事实标准（国内如百度地图、高德地图也已跟进），展现出强大的发展势能，然而行业内对其的争议、质疑乃至审慎的目光也从未停止。
Andrej Karpathy面对相关提问时一句简洁的“please make it stop”，便颇具代表性地折射出部分业内人士对其前景所持有的复杂情绪或保留态度。
这些争议首先尖锐地指向了MCP的核心定位及其能力边界问题。虽然MCP在模型调用工具资源方面表现出色，被广泛认可为该领域的“事实标准”，但一个关键的质疑在于，其当前设计是否（以及如何能）有效支持日益重要且复杂的智能体间通信与协作场景。
批评声音认为，MCP的设计初衷和现有架构并非为此优化，可能存在先天不足，特别是在与那些专门针对智能体通信需求而设计的协议（如ANP、Agora等）进行比较时，其局限性更为凸显。
这直接关系到MCP未来是应坚守工具调用的核心定位，接受与其他协议共存协作的局面，还是需要进行重大的、可能充满兼容性挑战的演进以拓展其能力边界。
紧随其后的，是对MCP所占据的生态位及其对创新空间影响的深切担忧。MCP的迅猛发展和由巨头加持带来的近乎主导的地位，虽然极大地推动了工具调用层面的标准化进程，但“硬币的另一面”是可能形成技术路线的过早收敛甚至垄断。
业界担心，这种“赢者通吃”的局面会挤压其他具有不同设计哲学、或许在特定场景下更优的创新协议（例如，采用不同世界观和技术选型的ANP项目）的生存与发展空间，从而潜在地抑制了整个AI交互协议生态本应具有的多元化探索和长期活力。
部分大型平台在考虑开放核心能力接入MCP时的战略性犹豫，也与这些对标准主导权、生态控制力以及未来技术路径选择的深层顾虑不无关系。
当前面临的主要挑战
比如，在数字营销公司Digidop看来（引用来源：“Model Context Protocol (MCP): How This Revolutionary Technology Is Transforming Artificial Intelligence），MCP当前及未来发展还面临着一系列具体的技术与生态挑战：
标准统一与碎片化风险：作为开放标准，MCP需警惕因不同实现、私有扩展或竞争协议导致生态割裂的风险，在开放创新与保持核心互通性之间寻求平衡。
安全、认证与授权机制尚不成熟：当前协议在标准化的身份验证、精细化的权限控制等方面尚有不足，对确保AI安全、可控地执行任务构成挑战。
开发者体验与生态成熟度有待提升：MCP引入了新的开发范式，存在学习曲线，同时围绕开发、部署、管理、发现及调试MCP服务器的成熟工具链和基础设施尚待完善。
工具质量与标准化指引欠缺：早期涌现的MCP工具质量参差不齐，缺乏统一的质量评估标准和接口设计的最佳实践，影响了互操作性和开发者信心。
基于MCP目前的发展，很多人认为这可能是迈向通用AI交互与智能新范式。比如，在Yoko Li的《A Deep Dive Into MCP and the Future of AI Tooling》一文里，他就试图阐释这一观点。基于此，他也提出一些可能的创业机会。
MCP Infra的机会
托管与多租户
MCP 支持 AI 智能体与其工具之间的一对多关系，但多租户架构（例如 SaaS 产品）需要支持多个用户同时访问共享的 MCP 服务器。
默认采用远程服务器可能是一个近期解决方案，以使 MCP 服务器更易于访问，但许多企业也希望托管自己的 MCP 服务器并分离数据和控制平面。 一个用于支持规模化 MCP 服务器部署和维护的简化工具链，是解锁更广泛采用的下一个关键部分。
认证
MCP 目前没有为客户端如何向服务器进行认证定义标准的认证机制，也没有为 MCP 服务器在与第三方 API 交互时应如何安全地管理和委托认证提供框架。认证目前留给各个实现和部署场景自行决定。
在实践中，MCP 迄今为止的采用似乎集中在本地集成上，这些场景并不总是需要显式认证。 一个更优的认证范式可能是推动远程 MCP 采用的一大突破口。从开发者的角度来看，统一的方法应涵盖：
客户端认证：用于客户端-服务器交互的标准方法，如 OAuth 或 API 令牌
工具认证：用于向第三方 API 进行认证的辅助函数或包装器
多用户认证：面向企业部署的租户感知认证
授权
即使工具通过了认证，谁应该被允许使用它？他们的权限应该有多细粒度？MCP 缺乏内置的权限模型，因此访问控制是在会话级别进行的——这意味着一个工具要么可以访问，要么完全受限。
虽然未来的授权机制可能会塑造更细粒度的控制，但当前的方法依赖于基于OAuth 2.1 的授权流，一旦认证通过，即授予会话范围的访问权限。
随着引入更多的智能体和工具，这会增加额外的复杂性——每个智能体通常需要自己的会话和独特的授权凭证，导致一个不断增长的基于会话的访问管理网络。
网关
随着 MCP 采用规模的扩大，网关可以充当认证、授权、流量管理和工具选择的集中层。类似于 API 网关，它将强制执行访问控制，将请求路由到正确的 MCP 服务器，处理负载均衡，并缓存响应以提高效率。
这对于多租户环境尤其重要，因为不同的用户和智能体需要不同的权限。标准化的网关将简化客户端-服务器交互，提高安全性，并提供更好的可观测性，使 MCP 部署更具可扩展性和可管理性。
MCP 服务器的可发现性与可用性
目前，查找和设置 MCP 服务器是一个手动过程，需要开发人员定位端点或脚本，配置认证，并确保服务器和客户端之间的兼容性。
集成新的服务器非常耗时，并且 AI 智能体无法动态发现或适应可用的服务器。 不过，根据Anthropic 上个月在 AI 工程师大会上的演讲，似乎 MCP 服务器注册表和发现协议即将推出。这可能会为 MCP 服务器解锁下一阶段的采用。
执行环境
大多数 AI 工作流需要按顺序进行多次工具调用——但 MCP 缺乏内置的工作流概念来管理这些步骤。要求每个客户端都实现可恢复性和可重试性并不理想。
尽管如今我们看到开发者正在探索像Inngest这样的解决方案来实现这一点，但将有状态执行提升为一等公民概念将为大多数开发者理清执行模型。
标准的客户端体验
我们从开发者社区听到的一个常见问题是，在构建 MCP 客户端时如何考虑工具选择：是每个人都需要为工具实现自己的 RAG，还是有一个等待标准化的层？
除了工具选择之外，也没有统一的调用工具的 UI/UX 模式（我们已经看到了从斜杠命令到纯自然语言的各种方式）。一个标准的客户端层，用于工具发现、排序和执行，有助于创建更可预测的开发者和用户体验。
调试
MCP 服务器的开发者经常发现，让同一个 MCP 服务器在不同客户端之间轻松工作是很困难的。通常情况下，每个 MCP 客户端都有自己的怪癖，而客户端追踪要么缺失要么难以找到，这使得调试 MCP 服务器成为一项极其困难的任务。
随着世界开始构建更多远程优先的 MCP 服务器，需要一套新的工具来使本地和远程环境下的开发体验更加流畅。
如果MCP成为AI驱动工作流的事实标准
MCP 的开发体验让我们想起了 2010 年代的 API 开发。范式新颖且令人兴奋，但工具链尚处于早期阶段。如果我们快进到几年后，如果 MCP 成为 AI 驱动工作流的事实标准，会发生什么？一些预测：
以开发者为先的公司的竞争优势将演变，从交付最佳 API 设计演变为同时交付供智能体使用的最佳工具集合。如果 MCP 能够自主发现工具，API 和 SDK 的提供者将需要确保他们的工具易于从搜索中发现，并且具有足够的差异化，以便智能体为特定任务选择它们。这可能比人类开发者寻找的要精细和具体得多。
如果每个应用程序都成为 MCP 客户端，每个 API 都成为 MCP 服务器，可能会出现新的定价模型：智能体可能会根据速度、成本和相关性的组合更动态地选择工具。这可能导致一个更市场驱动的工具采用过程，选择性能最佳、最模块化的工具，而不是采用最广泛的工具。
文档将成为 MCP 基础设施的关键部分，因为公司将需要以清晰的、机器可读的格式（例如llms.txt）设计工具和 API，并使 MCP 服务器成为基于现有文档的事实上的产物。
仅有 API 已不再足够，但可以是很好的起点。开发者会发现从 API 到工具的映射很少是 1:1 的。工具是更高层次的抽象，在任务执行时对智能体最有意义——智能体可能不会简单地调用send_email()，而是选择包含多个 API 调用以最小化延迟的draft_email_and_send()函数。MCP 服务器的设计将以场景和用例为中心，而不是以 API 为中心。
如果每个软件默认都成为 MCP 客户端，将会出现一种新的托管模式，因为工作负载特性将不同于传统的网站托管。每个客户端本质上都是多步骤的，并需要执行保障，如可恢复性、重试和长时间运行任务管理。托管提供商还需要在不同的 MCP 服务器之间进行实时负载均衡，以优化成本、延迟和性能，允许 AI 智能体在任何给定时刻选择最高效的工具。
事实上，除此之外，我们可能还能有很多的畅想。比如，未来通过MCP可能能与特定行业数据、特定的SaaS平台结合，开放出来更多个性化的精准的产品与服务。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |