MCP Extensions改进AI与工具的交互方式(上)

从工具调用到原生应用，一场关于 AI Agent、人机协作与软件生态的深层变化正在发生。

近期，OpenAI 开源项目 MCP Extensions 的 GitHub Stars 突破了 1,000。开发者 Max Stoiber 随即宣布了 v0.2 版本的更新，带来了可编辑对话草稿、多轮交互表单、新版 MCP SDK 支持，以及一系列针对应用交互体验的改进。

从表面看，这似乎只是一次常规的软件版本迭代。但如果结合近年来 MCP 协议、MCP Apps 和 AI Agent 的发展，就会发现，这些变化指向了一个值得关注的方向：AI 与外部工具的关系，正在从简单的调用与响应，走向深度融合的原生应用体验。

过去，我们不断尝试让 AI 调用更多工具、连接更多数据源，甚至自主执行复杂任务。而 MCP Extensions 所探索的另一条路径是：能否让工具本身成为 AI 工作环境中的一部分，让用户不必在聊天窗口与外部软件之间反复切换，就能直接查看数据、修改参数、审查结果，并与 Agent 持续协作？

这可能是理解 MCP Extensions 最重要的切入点。

为什么已经有了 MCP，还需要 MCP Extensions？

要理解这次变化，首先需要回顾 MCP 的发展。

Model Context Protocol（MCP）是一套连接 AI 应用与外部工具、数据和资源的开放协议。它通过标准化的通信机制，让不同的 AI 客户端能够发现和调用外部系统提供的能力。

对于开发者而言，MCP 的重要性在于降低了重复集成的成本。工具开发者不必针对每一种 AI 模型或 Agent 框架分别设计接口，而可以通过 MCP Server 向兼容的客户端提供统一的工具与资源访问能力。

但这一模式存在一个逐渐显现的问题：工具能够被 Agent 调用，并不意味着工具能够被用户自然地使用。

假设我们开发了一个用于单细胞转录组分析的 MCP Server。它可以接收参数、执行 Scanpy 工作流、计算差异表达基因，再将结果返回给模型。

从工具调用角度看，整个过程已经十分完整。

但研究者真正需要的往往不止于此。

他们可能希望直接打开 UMAP 图，点击需要的细胞群，查看对应的 marker genes；也可能希望在运行批次整合之前调整参数，对比不同策略，再决定是否继续执行分析。

如果这些操作完全依赖聊天窗口中的自然语言描述，交互效率就会受到限制。

后来出现的 MCP Apps，为 MCP 引入了可以嵌入宿主应用的交互式用户界面，让开发者不仅能返回文本和结构化数据，还能展示图表、表单和可操作的应用视图。

OpenAI MCP Extensions 则沿着这一方向更进一步。

它既不替代 MCP，也不另起炉灶建立一套新的 Agent 协议，而是在 MCP 与 MCP Apps 的基础上增加面向 ChatGPT 的扩展能力，让第三方应用能够更加深入地融入 ChatGPT 的界面、文件系统交互和对话流程。

三者可以这样理解：

MCP 负责连接能力，MCP Apps 负责呈现交互，MCP Extensions 负责更深入的宿主集成。

因此，MCP Extensions 的意义，并不是让 AI 首次拥有图形界面，而是让外部应用更接近 ChatGPT 的原生功能。

从被动调用到主动使用：插件开始拥有自己的应用入口

MCP Extensions 最直观的变化之一，是引入了更加完整的应用入口机制。

以往，许多 MCP 工具主要依靠模型决定何时调用。用户通常需要先发送一条消息，Agent 再判断是否使用相应的工具。

而现在，开发者可以通过 Extensions 定义三类入口。

第一类是 Global Entrypoint，即全局入口。

应用能够出现在 ChatGPT 的侧边栏中，用户可以直接打开，而不必每次都通过自然语言要求模型启动。

例如，一个文献管理插件可以提供独立的文献库界面；一个生物信息学应用可以提供数据集浏览器。用户进入 ChatGPT 后，便可以直接访问这些功能。

第二类是 Thread Entrypoint，即对话入口。

应用可以作为特定对话中的内容标签页存在，让某个分析界面与对应的研究任务建立联系。

例如，当 Agent 正在执行一项空间转录组分析时，研究者可以在同一对话内查看质控结果、空间聚类图以及分析进度，而不是不断要求模型重新输出结果。

第三类是 File Entrypoint，即文件入口。

开发者可以为特定文件格式提供专用查看器。当用户打开支持的文件时，ChatGPT 可以使用插件定义的界面替代默认文件查看器。

这为专业软件的轻量化集成提供了想象空间。

当然，这些能力不会由协议自动生成。具体的数据解析、可视化与交互逻辑仍需要开发者实现，而且文件入口目前主要面向受支持的桌面客户端。

但从产品设计角度看，这种变化相当重要。

工具不再只能等待 Agent 调用，而开始拥有能够被用户主动访问和持续使用的空间。

它使 MCP 插件逐渐从后台能力扩展，发展为兼具专业功能与交互体验的轻量应用。

让 Agent 理解用户正在操作什么，而不仅仅理解用户说了什么

MCP Extensions 的另一个重要方向，是改善用户界面与模型上下文之间的信息同步。

在传统的 Agent 工作流中，模型通常根据用户输入和工具返回的结果进行推理。

然而，在许多专业应用里，用户的重要操作并不一定通过文字表达。

例如，一位研究者正在浏览空间转录组图像。他放大了某个组织区域，筛选了特定细胞类型，调整了表达阈值，最后选中一个需要进一步研究的空间域。

对于用户而言，这一系列操作已经明确表达了当前的研究目标。

但如果模型无法感知这些界面状态，那么当用户说出“分析一下这个区域”时，Agent 仍然可能缺乏足够的上下文。

MCP Extensions 扩展了 ui/update-model-context，允许应用将相关信息提供给模型。

开发者可以通过内容块传递用户明确选择的资源，也可以使用结构化上下文描述当前界面状态，例如正在查看的数据集、选中的对象、筛选条件和视角。

模型随后可以按需调用 MCP 工具，获取更详细的数据。

这种设计背后有一个值得注意的原则：

用户需要看到完整的数据，但模型不一定需要接收完整的数据。

对于单细胞和空间多组学分析，这一点尤其重要。

一份表达矩阵可能包含数万个细胞和数万个基因。如果插件每次交互都把全部信息发送给模型，不仅会增加上下文消耗，还可能导致信息截断和处理效率下降。

更合理的方式是让界面负责数据展示，模型上下文负责传递当前关注的对象，而服务端工具负责按需获取详细信息。

例如，研究者在 UMAP 上选择某个细胞群时，插件只需要告诉模型该细胞群的标识、对应的数据集及必要的摘要信息。模型随后再调用工具获取 marker genes、表达特征或细胞注释证据。

这样既保留了研究者对数据的直接控制，也降低了 Agent 理解当前任务的成本。

更重要的是，它使图形操作与自然语言推理能够真正衔接起来。

未来，人们或许不再需要反复告诉 Agent“我现在看到什么”，因为应用能够在授权范围内，把必要的工作状态提供给模型。

不过，这种上下文同步不等于永久记忆。实验记录、分析版本和科学证据仍然需要可靠的后端机制保存。

v0.2 的两项关键变化：可编辑草稿与多轮交互表单

如果说此前的 Extensions 主要解决应用如何融入 ChatGPT，那么 v0.2 则进一步关注：当任务需要用户参与时，Agent 应当如何与人协作？

2026 年 10 月 10 日发布的 v0.2.0 中，两项最值得关注的能力是 Editable Drafts 和 Multi-Round-Trip Forms。

1. Editable Drafts：把决定权交还给用户

过去，当插件希望在 ChatGPT 中发起一项新的对话任务时，通常需要通过消息接口向模型发送内容。

现在，v0.2 为 ui/message 增加了更灵活的控制方式。

开发者可以通过 send: false，让插件把内容放进一个可编辑的消息草稿，而不是立即发送。

同时，target 参数可以控制内容进入当前对话，还是打开一个新的对话。

这个看似很小的变化，实际上改变了插件与用户之间的关系。

假设研究者在空间分析界面中选择了一个组织区域，希望 Agent 对其进行差异表达分析。

插件可以自动整理当前选择、分析目的和必要参数，生成一份请求草稿。

研究者可以先检查内容，补充限制条件，确认方法选择，再主动发送给 Agent。

在这个过程中，插件帮助用户准备行动，却没有替用户完成最终决定。

对于科研、代码开发和其他需要审查的重要工作，这一点十分有价值。

因为用户往往希望 AI 减少重复操作，却不希望自己失去对关键决策的控制。

可编辑草稿正好提供了一种相对轻量的协作方式：让工具降低操作成本，同时保留人的主动权。

需要注意，目前这种不立即发送的草稿行为主要支持 ChatGPT 桌面端与 Work 浏览器，移动端仍存在限制。

2. Multi-Round-Trip Forms：让复杂任务能够在执行过程中征询用户

另一项更具结构性意义的变化，是对多轮往返表单的支持。

真实的专业任务通常无法一次性确定全部参数。

例如，一个生物信息学工作流可能先完成数据质量检查，随后发现需要根据批次效应决定是否整合样本；某项分析也可能需要用户选择参考数据集，或决定是否排除特定细胞群。

传统工具调用模式下，开发者往往需要提前收集全部参数，或者通过额外的对话重新组织执行流程。

随着新版 MCP 引入 Multi Round-Trip Requests（MRTR），工具可以在需要用户输入时返回 input_required，由客户端呈现相应的交互请求。用户完成操作后，工具可以在新的调用中接收回答并继续处理。

OpenAI Extensions 在此基础上扩展了表单能力。

除了基本的文字、单选和多选，开发者还可以使用带缩略图的选项、建议值、资源选择和文件选择等交互方式。

试想这样一个场景：

Agent 完成组织切片的初步处理后，发现有多个候选区域需要进一步分析。

它不必要求研究者记住复杂的样本编号，而可以通过表单展示对应的图像缩略图，让研究者直接选择目标区域。

随后，分析工具根据用户的选择继续执行。

这种模式的意义，不是让 Agent 更加自主，而是让人类参与能够自然地嵌入自动化流程。

它将传统的“用户提出需求，Agent 连续执行”转化为一种更灵活的协作模式：

Agent 执行可以确定的步骤，在关键不确定处请求判断，然后继续完成任务。

对于科学研究、工程设计和高风险业务流程，这种交互能力尤其重要。

从更广泛的角度看，多轮表单也意味着复杂任务不必完全依赖自然语言进行控制。结构化输入能够减少歧义，并为参数验证和操作审查提供更清晰的边界。