前言 近年围绕大型语言模型(LLM)与"工具调用"模式出现了大量讨论,其中模型上下文协议(Model Context Protocol,简称MCP)成为争论焦点。有人认为MCP是重复发明轮子,是一个短期存在的权宜之计;也有人认为它是解决多客户端环境下实时能力协调、身份授权与状态同步等核心问题的必要协议。本文试图澄清MCP的核心价值、面对的挑战以及可行的改进路径,帮助工程与产品团队判断何时应采用MCP、如何将其纳入技术栈,并为社区在协议层面的演进提供可行建议。 MCP 是什么,它为谁而生 MCP不是简单的工具描述语言,也不仅仅是API规范的替代品。它的设计目标在于让AI客户端与后端能力之间形成一种以"对话"为核心的运行时协议:客户端不仅能在会话中发现并调用工具,还能接收运行时变更通知、处理权限授权和审批流、以及处理长时任务的进度与中断。换言之,MCP关注的是运行时的动态行为与分布式协调,而不是仅仅描述静态接口。
对于单一闭环系统或完全受控的堆栈,团队可通过自定义封装实现类似功能。问题在于现实世界往往不是单一客户端或单一厂商环境:企业会同时在ChatGPT、Claude、Cursor等多个AI客户端中接入能力,产品线往往需要"一次构建,到处可用"的工具集,同时不同角色、不同会话状态会影响可见能力与可执行动作。MCP应运而生,目标正是解决这种多客户端、多身份、多状态下的运行时协调问题。 为什么静态API(如OpenAPI/gRPC)无法替代MCP OpenAPI和gRPC在静态接口描述方面近乎完美。它们适合描述端点、参数和返回类型,便于生成代码、测试与文档。然而,它们天生是静态的声明式规范,不包含运行时权限委派、能力动态变化通知、以及会话级别的能力过滤机制。
几种典型场景可以说明差异: 当用户完成OAuth认证后,后端可能根据其角色只暴露部分工具。若将所有可能的工具都堆到OpenAPI里,客户端无法区分哪个在当前会话中可用。无限的上下文窗口也不能解决这个问题:即便将整个API文档塞进LLM的上下文,LLM依旧不知道哪个操作在"刚刚"变为可用、哪个操作需要审批或只能在特定部署失败后出现。动态性、身份感知与触发时机是静态文档无法描述的。 当某些操作是有副作用或危险操作时,服务器可能需要在运行时请求确认或执行审批流程。OpenAPI未定义这样的交互模式,工程团队最终会在每个客户端上各自实现一套行为,导致 fragmented(碎片化)的体验和维护成本。
MCP正是为这些运行时行为建立统一约定,使得不同客户端在访问同一后端时能共享相同的交互模式。 MCP解决的核心问题:身份、状态与协同 身份感知是MCP的首要亮点之一。不同用户、不同工作空间和不同权限集会看到不同的工具集。MCP协议允许服务端基于OAuth scope、组织策略或会话上下文向客户端报告"你目前能看到的工具集合",并在能力发生变更时通过通知机制告知客户端。这种能力在多租户平台上尤为重要:运营团队、开发团队与支援团队需要在同一平台上获得差异化权限,而这些差异必须体现在AI代理能够调用的能力上。 运行时状态也是关键。
很多能力并非一直可用,而是依赖于系统状态或某些事件触发后才出现。举例来说,只有当部署失败时才可用的"回滚"操作,或是在故障排查期间才开放的"导出日志"工具,都是运行时能力。MCP允许服务器在事件发生时通过通知将这些临时能力广播到客户端会话,从而避免将所有可能操作静态暴露出来,降低误操作风险。 最后是跨客户端协同。企业希望在不同AI客户端中获得一致体验:销售团队使用某个AI助手时看到的工具集合应与运维或客户支持使用的助手按照同样的权限策略被过滤。若没有统一协议,每个客户端的集成都会演化出自己的行为,导致策略分散且难以治理。
MCP提供了一套在不同客户端之间保持一致性的约定,减少重复实现与策略偏差。 MCP 的交互模式与典型功能 MCP并不是单一功能的实现,而是一组模式的结合:能力发现、能力变更通知、审批/确认流、长任务的进度流以及错误和回退策略。能力发现让客户端能在对话中知晓当前环境可调用的工具;变更通知让客户端在运行时更新可见工具集;审批流在危险操作前触发用户确认或更高权限审批;进度流允许客户端向用户展示后台任务的实时进展。 这些模式在实践中如何体现并非完全固定:MCP的规范设计比较宽松,允许不同实现之间存在变体。这既是灵活性的来源,也带来了一个现实问题:过于宽松的规范会导致客户端与服务器社区难以实现高级功能,形成所谓的"启动陷阱"(bootstrap trap):只有实现了足够多特性的客户端,服务器才能放心使用高级模式;而只有服务器提供充分能力,客户端才愿意实现复杂逻辑。规范的不一致性因此成为MCP生态发展的主要障碍之一。
常见批评与反驳 批评一:MCP是多余的,OpenAPI/gRPC和更大的上下文窗口就足够了。 反驳:静态接口与大上下文能解决接口描述和信息拥塞,但无法解决基于身份与运行时事件的能力过滤、跨客户端一致性和审批/通知等动态行为。把所有可能性写入文档或上下文,会增加误用风险,且长期无法满足多租户治理需求。 批评二:MCP会成为碎片化的协议标准,各家都实现不同版本。 反驳:这是任何新协议都会面临的风险,解决路径不是放弃协议而是加强规范化治理。建立明确的传输层要求、能力协商流程和测试套件,并推动参考实现与合规检查,能够显著减少碎片化风险。
批评三:MCP的传输与状态管理太复杂,难以工程化。 反驳:复杂性来自真实问题的复杂性。动态权限、审批流和长任务提示的确需要更复杂的信令与长连接支持。更合理的做法是明确定义必需与可选功能,提供轻量级与全功能两套路径,使工程团队可以在不同成熟度阶段采用合适的实现。 MCP 当前痛点与改进建议 MCP在社区与实际部署中暴露了若干问题,下面列出主要痛点并给出改进建议。 传输层混乱:MCP现有生态中对传输的定义不够清晰,导致有的实现倾向于HTTP轮询、另一些使用WebSocket或SSE,互操作性受限。
建议明确定义必须支持的传输方式(例如WebSocket与Server-Sent Events用于双向通知与流),同时允许REST回退路径以照顾简单场景。 规范过于宽松:规范的灵活性使得实现碎片化。建议引入分级合规性标准,定义核心必需集、推荐集与高级集。核心必需集应覆盖能力发现、身份通知与基本审批操作;推荐集可包含进度流与分阶段审批;高级集则为流式响应与复杂跨会话协作。 缺乏参考实现与测试套件:没有标准化的参考实现和互操作性测试,难以保证客户端与服务器的兼容性。建议由社区或财团维护至少一个开源参考服务器与客户端,并建立跨实现的互操作性测试套件,提供自动化测试框架与合格认证标识。
权限与治理策略:MCP需要更明确的授权模式示例以及常见场景的最佳实践。建议规范引入与OAuth、OIDC的标准对接示例,定义如何在会话级别下传递作用域、如何进行临时权限提升与审计要求。 启动陷阱:规范的局部实现导致高级功能无法落地。建议在生态早期推动灰度部署模式:定义一个"基础MCP"以便快速采纳,同时鼓励实现方在可控范围内逐步启用高级功能,并通过互操作测试验证兼容性。 治理与演进路径:协议需要明确的治理机制,决定规范变更流程、版本控制与兼容策略。建议成立跨组织治理委员会,采用开放RFC流程来演进规范,并明确长期支持(LTS)版本与迁移路径。
落地案例与适用场景 MCP最适合的场景是企业级、多租户、跨客户端的部署场景。在以下典型场景中,MCP的价值尤为明显: 运维与SRE平台:当不同角色需要在对话中查询系统状态、触发回滚或排查问题时,MCP可以控制哪些操作在何时可用,并在执行前提供审批流与回退通知。 企业助手与知识工作平台:在多个AI助手(销售助手、HR助手、法律助手)共享后端能力时,MCP能确保每款助手看到的工具集与权限一致,避免安全与合规问题。 客服与自动化流程:在客户支持对话中,根据客户身份与会话上下文动态暴露诊断工具、账户管理接口等,MCP支持实时通知与权限审计,减少误操作风险。 改进实践的路线图 短期可行步骤包括:定义核心必需集、提供开源参考实现、明确传输(如WebSocket+SSE)与认证对接方法。中期目标应集中于建立互操作性测试套件、分级合规标准与社区治理结构。
长期愿景是实现跨厂商的无缝互操作,让企业可以在多款AI客户端之间统一策略、减少重复集成成本。 结语 MCP并非完美,也不是唯一的路径,但它响应了一个客观存在的需求:在多客户端、多身份与动态运行时状态的环境中,单靠静态API与超长上下文无法提供安全、一致且可治理的能力暴露与操作控制。通过明确协议约定、提供参考实现与测试套件、渐进式改进规范,MCP有望成为解决跨客户端AI能力编排问题的有效工具。面对现实中的复杂性,工程团队应理性评估:在需要跨客户端一致性、安全与运行时动态能力时,把MCP纳入架构考虑范畴,结合规范化实践与分级采纳策略,更可能带来长期的治理与效率收益。 。
