返回资讯中心
外部精选
云计算
#容器平台#AI#AI Agents#Model Context Protocol#Model Context Protocol (MCP)

MCP 文件上传难题困扰开发者两年,修复方案逐渐成形

来源标题:Developers have been hacking around MCP’s file-upload problem for two years. A fix is taking shape.

Anthropic 推出 MCP 近两年后,开发者仍缺乏将文件从 AI 应用传给 MCP 工具的标准方式,目前只能靠临时上传链接或跳转单独上传页面绕过。MCP 自去年 12 月起归属 Agentic AI Foundation,维护者正推动服务器免会话部署和复用企业现有身份系统管理访问。相关修复方案正在成形。

The New StackPaul Sawers2026/11/11 · 今天17 分钟阅读

以下正文由 AI 翻译自 The New Stack(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

自Anthropic大约两年前推出Model Context Protocol(MCP)以来,该协议在将AI助手连接到外部工具和数据方面发挥了关键作用。想让编码agent检查某个bug的状态?通过MCP server让它访问你的问题跟踪系统即可。或者想问助手公司上周发了多少订单?把它连接到一个能查询数据库的工具上就行。

自去年12月加入Agentic AI Foundation以来,MCP的路线图反映了在生产环境中运行该协议的需求。例如,维护者们一直在努力让server更容易部署,无需跟踪各个client会话,并让企业能通过现有的身份系统管理访问权限。

但开发者长期面临的一个问题是:如何将文件从AI应用传递给MCP工具。比如说,你在对话中附上一个PDF,让助手把它保存到云存储——助手可以调用工具来保存文件,但开发者仍需解决如何把PDF从聊天应用传到工具的问题。这可能意味着要签发一个临时上传链接,或者把用户引导到一个单独的上传页面。

为了填补这一空白,MCP项目团队勾勒出了一个草案扩展,为client和tool提供处理上传和下载的通用方式。

MCP终于着手解决文件上传问题

为什么MCP需要一种传输文件的方式

在周二发布的一篇博客文章中,MCP首席维护者、Anthropic技术团队成员Den Delimarsky和Google软件工程师Wil St. Charles阐述了新扩展的理由,指出随着开发者开始要求agent利用MCP连接的工具做更多事情,他们的需求已经发生了变化。

“这些MCP server项目中有许多现在需要处理文件——往往是由agent能力和自主性的不断提升所驱动的。”

“过去两年里,人们用这个协议构建的东西变得越来越有野心。野心大得多,”他们写道。“这些MCP server项目中有许多现在需要处理文件——往往是由agent能力和自主性的不断提升所驱动的。”

这种需求几乎从MCP诞生之初就在社区中显现出来。2024年12月,一位开发文件处理工具的开发者在GitHub上询问如何将文件从client传到server。Anthropic的一名团队成员承认了这一难点,并表示他们正在探索工具如何将文件发回给AI应用。随后其他社区成员纷纷献计献策,其中一位提到他们自己构建了一种从AI应用向MCP server发送文件的方式。他们的MCP client在调用工具之前直接将文件上传到server,上传本身发生在协议之外。

此后开发者一直在寻找绕过这一空白的方法。几个月前的一个Reddit帖子中,一位用户表示,在启用出站访问后,临时S3上传链接在Claude中可行,但在ChatGPT中无法采用同样的方法,于是他们构建了一个单独的Web应用和上传页面。另一位开发者说他们为MCP App构建了一个拖放界面,让用户自行提交文件,但agent仍然无法自己发起上传。

也有现成的方案。FastMCP为构建MCP App的开发者提供了一个拖放上传组件,而Box最近通过自己的MCP server推出了对PDF和Office文档的安全文件上传和下载支持。

MCP项目团队这边则一直在缓慢推进通用标准的制定。Delimarsky于2025年8月提出了一个探索性的上传提案,随后在4月成立了一个文件上传工作组,最初由Anthropic和OpenAI的成员组成。10月,该工作组将文件下载也纳入了职责范围。

如今,一份草案规范阐述了双向传输可以如何运作。

“虽然我们勾勒出了大致框架,但还不确定最初的设想是否就是最终的方案。”

“虽然我们勾勒出了大致框架,但还不确定最初的设想是否就是最终的方案,”作者们写道。“找出答案的最好方式就是——你猜对了——接触现实。”

MCP将如何传输文件

这一实验性文件传输扩展建立在MCP于7月推出的扩展框架之上,该框架让client和server能够选择启用新功能,而无需更改核心协议。实验阶段为开发者提供了一个场所,可以在正式的规范增强提案(SEP)之前或与之并行地对想法进行原型设计和完善。

无论哪种方式,文件本身都绕过模型。

根据该扩展,例如当你让助手把附带的PDF保存到云存储时,模型调用工具,由MCP client处理上传。client可以在工具请求中发送小文件;对于较大的文件,client单独上传,然后再次调用工具完成任务。无论哪种方式,文件本身都绕过模型。

对于下载,例如一个导出CSV的工具在生成文件后可以包含一个下载URL。client随后可以直接获取该CSV,模型会收到一条消息,告知它工具生成了什么。

一大安全影响在于host对文件去向应拥有多大控制权。就目前而言,拟议的扩展限制了client何时可以将其MCP凭证发送到上传目的地。host在MCP server提供目的地之前会请求用户批准上传,因此用户在批准时可能并不知道文件将被发往何处。

“这些保障措施控制的是client的MCP凭证被发送到哪里,但它们本身并不控制文件去哪里,”作者们写道。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →