MCP会成为下一代操作系统吗？
当模型上下文协议（MCP）推出时，其价值主张十分明确：为大语言模型提供调用外部功能的标准方式。
但如果查看2026路线图及此后推出的稳定工作成果，你会发现其目标更为宏大。MCP正从工具调用API向更广泛的原语演进，用于智能体工作流、长期运行任务、交互体验及企业级部署。
证据在于那些已不再是实验性的内容：
- 委托：任务现已成为官方扩展，支持长期运行任务，无需保持原始请求处于打开状态。服务器可从工具调用返回任务句柄，客户端可使用该句柄检查、更新或取消任务。
- 交互：MCP应用允许服务器提供交互式HTML界面，宿主可在工具交互的同时渲染这些界面，包括带有按钮、表单及其他UI元素的界面。
- 企业级管理授权：组织可设定：“该智能体可在这些条件下、使用此身份访问这些系统”，而非采用按用户、按服务器的授权方式。
MCP技能工作组正在开发一项实验性扩展，用于通过MCP发现和分发可复用的智能体技能。该提案仍在演进中，尚未成为MCP官方规范的一部分。已落实到位。
技能比工具更优吗？
这正是故事变得有趣的地方。
在旧模型中：
- 客户端：“以下是你可调用的工具。”
- 智能体：调用工具、解析结果、对结果进行推理。
在MCP技能工作组提出的新模型中：
- 服务器：“以下是一个流程，包含前置条件、副作用、预期结果、重试逻辑及升级路径。”
- 智能体：理解完整的操作上下文，可在知晓约束条件的情况下执行任务。
该工作组目前正在探索其技术实现方式——利用MCP中的资源机制，为技能元数据定义模式，并研究发现与组合的相关问题。
但概念上的转变十分明确：MCP正从“以下是你可调用的函数”转向“以下是安全、高效的智能体在该领域的运作方式”。
这一变化对使用MCP的组织有何作用？
试想将这些部分结合后会发生什么：
- 可审计性 + 企业级管理授权 = 将智能体访问与企业身份及授权控制关联起来的更坚实基础。
- 任务 + MRTR = 长期运行任务可暂停以等待审批、澄清或其他输入，无需保持持续打开的连接。
- MCP应用 + 服务器渲染的UI = 智能体不仅能获取数据，还可与设计好的界面交互，减少解析错误并提升可用性。
- 技能 + 标准化流程 = 智能体依据已记录的剧本运作，而非临时拼凑的工具链。
- 事件驱动型MCP（即将推出） = 智能体可由底层系统的变更触发，而非仅由客户端请求触发。
将这些结合起来，MCP看起来不再仅仅是一个工具调用API。它正成为一个更广泛的协议层，用于协调智能体交互、长期运行任务、用户界面、身份及企业基础设施。
MCP路线图的下一步是什么？
2026路线图明确指出了任务中未解决的问题：重试行为、结果过期、长期状态。这些即将到来的变化是构建系统的基础，在该系统中任务将成为智能体工作的标准单元。
路线图提到了“可移植服务器配置”，这意味着智能体应能在不同部署间迁移而不丢失上下文。还提到了“可组合工具执行”，这暗示需以标准化方式将工具串联起来。
该路线图上的每一项都是这一更大图景的一部分：MCP正从用于调用函数的协议演变为智能体作为组织成员运作的协议。
更新： 于22年8月，MCP维护者发布了新路线图，该路线图强化了这一方向，优先事项包括智能体消息原语、原生HTTP传输、智能体身份及企业级安全、改进的原语及SDK开发者体验。
本系列的后续内容
我们现已涵盖了两点：
- 向无状态、原生Web的MCP的架构转变（第1部分）。
- 向完整智能体能力的概念转变（本文）。
接下来的三篇文章将深入探讨其影响：
完整愿景如何将这些线索结合起来。
MCP的架构如何向原生Web及运维友好型演进。
企业安全与治理如何被构建到基础之中。
了解更多
- MCP 2026路线图（https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/）
- MCP技能工作组（https://github.com/modelcontextprotocol/spec/discussions）（SEP-2640）
- 任务扩展规范（https://modelcontextprotocol.io/specification/2026-07-28/extensions/tasks）