用预签名上传与异步任务处理 MCP 大文件

让 Cursor 处理一段 50MB 音频，难点不只是模型能不能理解音频，还在于文件怎么传、GPU 在哪里跑、结果怎么回到项目目录。把文件编码后塞进提示词，很快就会撞上上下文和请求体限制。

作者给出的方案是：用 Remote MCP Server 编排上传、处理和下载，让文件走云存储，让模型只负责调用工具。他把这套架构用在了 Sonicaura MCP 音频处理引擎中。对需要接入远程媒体处理能力的程序员，这篇最有用的是任务链路的拆法。

大文件为什么不该经过模型上下文

作者先排除了两条直接路径。

第一条是把本地 .mp3 转成 base64，再发送给模型。编码后的文件仍然很大，还会增加传输体积；把它放进文本上下文，并不能绕开 token 和 payload 限制。原文用 50MB 音轨举例，但没有提供具体模型的限制值或测试结果。

第二条是让本地 MCP Server 直接读取文件。这能解决文件访问问题，却未必解决算力问题：如果任务需要较重的 GPU 计算，笔记本仍可能承担不了。

文件传输、模型推理和 GPU 处理，应该各走适合自己的通道。

模型只需要知道「文件已经上传」「任务是否结束」「结果在哪里」，不必接触文件的全部内容。这个分工，也是后面异步流程成立的基础。

五个步骤，把一句指令变成远程处理任务

作者采用的是异步上传模式（Async Upload Pattern），核心工具链如下：

1. Agent 调用 get_upload_url，服务器返回预签名 URL，例如 S3/R2 的上传地址。
2. Agent 或它触发的本地脚本，把文件直接上传到云存储。文件数据不进入 LLM 上下文。
3. Agent 调用 submit_task，通知服务器处理已上传的文件。
4. Agent 调用 check_task_status 查询进度。原文也提到可以使用 webhooks，但没有展开回调如何接入客户端。
5. 处理完成后，Agent 调用 get_download_url，获取结果下载地址，再把分离音轨、MIDI 或降噪音频下载到本地工作区。

预签名 URL 可以理解为一个带临时授权的存储访问地址。模型负责申请地址和安排后续动作，真正的文件上传由执行工具或脚本完成。

作者在 Cursor 中举出的指令是：「从 ./demo.mp3 提取人声，并把结果保存到本地。」

这句话看起来简单，背后却需要本地文件访问、上传执行、远程任务和结果下载共同配合。Remote MCP Server 提供远程工具，并不自动获得用户电脑上的文件访问能力。 原文没有给出这部分客户端配置和脚本实现，不能仅凭这套工具名就认定所有客户端都能全程自动完成。

能跑通之后，还要处理等待、失败和鉴权

作者提出了三个落地要求。

远程连接使用 Streamable HTTP。stdio 适合本地进程通信；要让远程客户端访问服务，需要部署服务器并暴露 HTTP 接口。原文提到了 Cursor 和 Claude Desktop，但没有列出兼容版本或连接配置。

任务状态必须清楚。check_task_status 如果始终只返回 pending，Agent 可能持续轮询，尤其在任务已经失败时。作者要求明确返回错误状态，但没有给出状态结构、轮询间隔和超时策略。

GPU 接口需要鉴权。作者建议使用 OAuth，避免公开接口被滥用并产生高额账单。不过，鉴权只能回答「谁可以调用」，费用额度和任务并发如何控制，原文没有说明。

作者称这套架构已经用于 Sonicaura MCP，代码仓库为 warmcoding/sonicaura-mcp，并已发布到 Official MCP Registry。原文没有附实现片段，也没有提供吞吐量、处理时延或失败率数据。

我的判断

我认同把大文件移出模型上下文的方向。对于远程 GPU 任务，直接上传对象存储，再提交异步任务，职责划分清楚，也方便把耗时处理与客户端请求分开。

但这篇更接近架构经验分享，还不足以作为完整实施教程。上传中断怎么办、重复提交是否重复计费、任务卡住如何结束，都没有展开。它也没有给出与其他方案的对照数据，不能据此判断性能或成本更优。

如果任务规模小、本地算力够用，本地 MCP Server 直接读取文件仍然合理；如果只是固定的上传和处理流程，普通 HTTP API 加脚本也能承担。MCP 的价值主要在于让 Agent 发现并调用这些能力，异步任务和对象存储本身并不依赖 MCP。

能拿来做什么

• 给现有音视频处理服务增加 MCP 接口时，可以先按 get_upload_url、submit_task、check_task_status、get_download_url 拆分职责，让工具参数传递文件标识和任务信息。
• 在 Cursor 中实现「处理本地音频」之前，先确认 Agent 能通过什么本地工具读取、上传和下载文件，再串联远程服务。
• 用 Node 编写状态查询接口时，应明确区分等待、完成和失败，并让调用方能够停止轮询，避免失败任务一直显示 pending。
• 将 GPU 服务开放给 Agent 前，先落实作者建议的 OAuth 鉴权，再检查任务提交是否还需要额度和并发限制，补齐原文没有覆盖的费用控制。