MCP Extensions拆解：Tasks和MCP Apps如何重塑工具调用

MCP 诞生时定位很明确：一套标准化的工具调用协议。Server 暴露工具，Client 调用工具，返回结果，结束。这个模型简洁有效，但它有一个根本问题——所有新功能都只能往核心协议里塞。认证要塞，长任务要塞，UI 渲染也要塞。协议越来越臃肿，版本迭代越来越慢。

2026-07-28 发布的 Specification Release Candidate 改变了这个局面。RC 版最值得关注的架构变化不是某个具体功能，而是一个设计决策：引入 Extensions 框架。核心协议保持精简，所有扩展能力交给 Extensions 承载。MCP 从"能调用工具的协议"变成了"能扩展能力的平台"。

Extensions 框架：协议的"插槽"设计

Extensions 的设计哲学一句话概括：核心协议只管通信，扩展能力按需加载。

三种类型各有分工：

类型	定位	示例
modular	模块化功能，可独立启用	认证、权限管理
specialized	行业或场景特定逻辑	医疗数据处理、金融合规
experimental	孵化中的实验特性	可能进入核心，也可能废弃

能力协商发生在 initialize 握手阶段。Client 和 Server 通过 capabilities 字段声明各自支持的 extensions，只有双方都声明支持的 extension 才会生效。这解决了旧版的核心矛盾：一方想加新特性，另一方可能不支持，却没有协商机制。现在双方各说各的，取交集，干净利落。

旧版的问题不只是臃肿。更本质的是，所有特性挤在核心协议里，意味着每个特性都必须等整个协议升级才能迭代。Extensions 把这个耦合拆开了——认证模块可以独立发布 v2，不影响 Tasks 的版本节奏。

Tasks Extension：让工具调用"异步化"

这是 Extensions 框架下最实用的一个扩展，解决了工具调用的"时间维度"问题。

旧模型下，tools/call 是同步阻塞的：发请求，等结果。调用一个耗时操作（训练模型、大规模爬取、长编译任务），整个 Agent 会话就卡在那里。用户体验是：发了一条指令，然后看着转圈等几分钟。

Tasks Extension 改变了这个流程。Server 在 tools/call 响应中不再返回最终结果，而是返回一个异步 task handle：

1
2
3
4
5
{
  "task_id": "task_abc123",
  "status": "running",
  "progress": 0.35
}

Client 收到 handle 后，通过 tasks/get 轮询状态。状态机很简单：pending → running → completed / failed。同时支持 progress 通知和取消操作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 伪代码：Python SDK 中使用 Tasks
result = await client.call_tool("train_model", params)
if result.is_task:
    # 不阻塞，继续做其他事
    while True:
        status = await client.tasks_get(result.task_id)
        if status.is_completed:
            final = status.result
            break
        await asyncio.sleep(2)

实际意义是什么？Agent 可以同时发起多个长任务，轮流检查进度，而不是排队等待。这对需要调用多个外部服务的复杂工作流来说是重要的改进——从串行阻塞变成并行管理。

MCP Apps：从文本到"小程序"

如果说 Tasks 解决了时间维度的问题，MCP Apps 解决的是空间维度——工具调用能返回的不再只是文本和数据，还可以是交互式 UI。

旧 MCP 像一个只能发短信的客服：你问问题，它回文字。MCP Apps 让这个客服能发小程序给你——你在对话窗口里直接操作一个完整的界面，不用切到别的应用。

技术流程分四步：

Server 在 tools/list 中声明关联的 app 资源
工具调用后返回 app:// URI 而非纯文本
Host 在沙箱化的 iframe 中渲染 Server 提供的 HTML
通过 postMessage 实现 iframe 与 Host 的双向通信

整个过程是标准化的：UI 资源声明、工具关联、双向通信都有明确的协议规范。Server 开发者只需按照规范打包前端资源，Client 端（Claude、ChatGPT 等）负责渲染和沙箱隔离。

目前 Claude 和 ChatGPT 已原生支持 MCP Apps，OpenClaw.NET 也率先实现了原生支持。官方仓库在 github.com/modelcontextprotocol/ext-apps，由 Anthropic 于 2026-01-26 正式发布。

三者关系：Extensions 是容器，Tasks 和 Apps 是内容

把三者关系理清楚：

Extensions 框架提供"插槽"机制——协议如何声明、协商、加载扩展能力
Tasks 解决"时间维度"——工具调用可以不等结果
MCP Apps 解决"空间维度"——工具调用可以返回 UI

两者都是 Extensions 框架的具体实现，遵循相同的能力协商和生命周期管理。未来还会出现更多 extension，但机制已经确立。

对开发者的影响

如果你正在开发 MCP Server，需要关注三件事：

了解 Extensions 声明机制。RC 版的 initialize 握手新增了 capabilities 字段，你需要在 Server 实现中声明支持哪些 extensions。
长耗时工具必须实现 Tasks Extension。这是用户体验的基本要求——没有异步支持的长任务在新生态里没有竞争力。
有前端的工具考虑 MCP Apps。如果你的工具本来就有 Web 界面，通过 MCP Apps 嵌入对话窗口是自然的体验升级。

现有 Server 迁移方面，RC 版向后兼容，不支持 Extensions 的 Client 仍然可以正常调用。但建议尽早适配——Extensions 是协议的未来方向。

结论

MCP 从"能调用工具"到"能扩展能力平台"，Extensions 框架是这个变化的核心。Tasks 让时间维度不再是障碍，MCP Apps 让空间维度不再是限制。两者共同指向一个方向：MCP 不再只是一个通信协议，而是一个可以持续扩展的平台。

对开发者来说，现在是关注 Extensions 的好时机。框架已定，首批扩展已经发布，生态还在早期。早理解 Extensions 的设计语言，有助于在新生态中占得先机。

作者：varkm