MCP 的2026 年的变化：从一问一答走向长任务是什么？

MCP 最初的设计前提是「客户端问、服务端答」。但 Agent 的任务越跑越长，这个前提开始不够用，协议在 2026 年的调整基本都围绕这一点展开。长任务：MCP Tasks 扩展（SEP2663）让服务端可以先返回一个任务句柄，客户端稍后查询进度和结果，而不必一直挂着一个请求等待。传输：据 MCP 维护者介绍，2026 年 7 月 28 日版规范去掉了协议层会话，远程 MCP 服务器可以像普通 HTTP 服务一样部署和横向扩容。路线图：两位主维护者 David Soria Parra 和 Den Delimarsky 在 8 月 22 日发布新路线图，列出五个优先方向——服务端主动推送

MCP 的资料来源是什么？

MCP Official Documentation MCP 官方博客：MCP joins the Agentic AI Foundation（20251209） Linux Foundation: Formation of the Agentic AI Foundation MCP 官方博客：MCP Roadmap（20260822） CISA: Adds Seven Known Exploited Vulnerabilities to Catalog（20260902） OpenAI: Introducing the Agents API MCP Servers Repository 站内

MCP 是什么？模型上下文协议详解

Q: MCP 的先用一句话抓住它是什么？

MCP 是让 AI 应用以标准方式连接工具、数据和上下文的协议。 它本身不是模型，也不负责生成回答。它更像连接层，帮助模型所在的应用找到外部资源，并以约定好的方式使用这些资源。 用生活里的话说，MCP 像给 AI 准备的一排标准插座。文件系统、数据库、日历、代码仓库就像不同电器；如果每个电器都要单独改线，使用起来会很麻烦。MCP 的意义，是让 AI 应用用更统一的方式插上这些外部能力。

AI之上编辑部发布于 2025-03-30更新于 2026-09-3030 查看MCP模型上下文协议工具调用

MCP 是 Model Context Protocol 的缩写，中文常译作“模型上下文协议”。它是一套让 AI 应用连接外部工具和数据源的开放协议，2025 年底移交 Linux 基金会旗下的 Agentic AI Foundation 托管

MCP 是 Model Context Protocol 的缩写，中文常译作“模型上下文协议”。它是一套让 AI 应用连接外部工具和数据源的开放协议，最早由 Anthropic 在 2024 年底发布，2025 年 12 月移交给 Linux 基金会旗下新成立的 Agentic AI Foundation（AAIF）托管。

可以把 MCP 理解成 AI 应用的“通用插座”。过去每个 AI 应用都要分别对接数据库、文件系统、搜索、日历、代码仓库等服务；MCP 想做的是提供一套统一连接方式，让这些能力可以用更标准的方式暴露给 AI 应用。

先用一句话抓住它

MCP 是让 AI 应用以标准方式连接工具、数据和上下文的协议。

它本身不是模型，也不负责生成回答。它更像连接层，帮助模型所在的应用找到外部资源，并以约定好的方式使用这些资源。

用生活里的话说，MCP 像给 AI 准备的一排标准插座。文件系统、数据库、日历、代码仓库就像不同电器；如果每个电器都要单独改线，使用起来会很麻烦。MCP 的意义，是让 AI 应用用更统一的方式插上这些外部能力。

为什么需要 MCP

大语言模型本身主要负责理解和生成。真正完成任务时，它常常需要读文件、查数据库、访问代码仓库、调用搜索、写日历、运行工具。如果每个 AI 应用都单独集成每个工具，开发和维护成本会很高，也很难形成通用生态。

在 MCP 的语境里，Host 是用户正在使用的 AI 应用，比如桌面助手、编辑器或聊天应用；Client 是 Host 里负责通信的部分；Server 则负责暴露工具、资源或提示模板。模型不需要知道每个系统内部怎么实现，只要通过协议看到可用能力。

和 API、Agent 的关系

API 是软件之间通信的通用接口，MCP 更像是面向 AI 应用的连接标准。很多 MCP Server 背后仍然会调用 API、数据库或本地工具。可以说，API 是服务窗口，MCP 则把这些窗口整理成 AI 更容易发现、理解和调用的形式。

Agent 需要工具才能行动，MCP 可以为 Agent 提供工具和上下文。一个 Agent 通过 MCP 访问文件、项目管理系统、数据库或业务系统后，才有可能从“能回答”变成“能做事”。

到 2026 年，MCP 已经成了各家 Agent 平台默认支持的接入方式。例如 OpenAI 9 月 10 日开放公测的 Agents API，就把「MCP 服务器」和模型、指令、工具并列写进 Agent 的定义里；亚马逊 9 月 23 日开放给外部 Agent 的卖家后台插件，也是通过标准授权流程把卖家数据接给 Claude 这类助手。

常见使用场景

MCP 常见于 AI 编辑器、桌面助手和企业智能体场景。比如让 AI 读取代码仓库、运行开发工具、访问本地文件、查询内部知识库，或者连接工单、CRM、日历和文档系统。已有 API 也可以被包装成 MCP Server，提供给 AI 应用使用。

这种标准化连接的价值在于复用。一个工具只要以 MCP Server 的形式提供出来，不同支持 MCP 的 AI 应用就有机会接入它。

2026 年的变化：从一问一答走向长任务

MCP 最初的设计前提是「客户端问、服务端答」。但 Agent 的任务越跑越长，这个前提开始不够用，协议在 2026 年的调整基本都围绕这一点展开。

长任务：MCP Tasks 扩展（SEP-2663）让服务端可以先返回一个任务句柄，客户端稍后查询进度和结果，而不必一直挂着一个请求等待。
传输：据 MCP 维护者介绍，2026 年 7 月 28 日版规范去掉了协议层会话，远程 MCP 服务器可以像普通 HTTP 服务一样部署和横向扩容。
路线图：两位主维护者 David Soria Parra 和 Den Delimarsky 在 8 月 22 日发布新路线图，列出五个优先方向——服务端主动推送的事件、Webhook 与频道；统一到 HTTP 原生传输；面向 Agent 的工作负载身份与企业授权（DPoP、身份联邦）；统一工具结果契约与渐进式工具发现；以及 SDK 开发体验。路线图只给优先级，没有给交付时间表。

其中「渐进式工具发现」值得单独说一句。路线图原文指出，连上一个有一百个工具的服务器，意味着用户还没开口，模型就已经为整个工具清单付了上下文费用。工具越多，越需要按需露出，而不是开场全量塞进上下文窗口。

容易误解的地方

MCP 不是插件市场，也不是大语言模型。它是一套协议，具体能力来自不同 Server。接入 MCP 也不等于自动安全，因为协议只解决连接方式，不替你决定哪些数据能读、哪些工具能用、哪些操作需要确认。

2026 年的实际案例说明了这一点。9 月 2 日，美国 CISA 把 LiteLLM 的 CVE-2026-59822 列入已知被利用漏洞目录：它的 MCP Streamable HTTP 端点在 API key 校验失败后没有终止请求，随便编一个 Bearer token 就能调用背后的 MCP 工具，1.84.0 之前的版本都受影响。问题不在 MCP 协议本身，而在网关对它的实现，但后果一样落在工具和凭据上。

工具暴露越多不一定越好。能力越大，治理越重要。如果一个 Server 可以读写敏感文件、发送消息、修改配置，就必须配合权限、审计和用户确认。工具描述和工具返回的内容也会进入模型上下文，是提示词注入的常见入口。

怎么判断它该不该用

设计 MCP 连接时，要先想清楚边界：哪些资源可读，哪些工具可调用，哪些动作必须人工确认，日志如何记录，错误如何处理。

几条落地建议：只连真正需要的 Server，工具数量宁少勿多；远程 Server 走标准授权，不要把长期有效的密钥写死在配置里；经过网关或代理暴露 MCP 时，把网关版本纳入安全补丁的跟踪范围；会跑很久的操作优先用 Tasks 这类异步方式，不要靠超时重试硬撑。MCP 的价值在标准化连接，可靠的 AI 系统还需要安全策略和用户控制。