5 年前我发了 ZPan 首发！迟到一年的云存储网盘还有人需要么？
当时 ZPan 的想法很简单：既然某些网盘动不动限速、开会员也不一定省心，那为什么不直接基于对象存储搭一个自己的网盘？文件放在 OSS 、COS 、Kodo 、S3 、MinIO 这些对象存储里，ZPan 只负责用户、目录、分享、配额这些控制逻辑。上传下载尽量走预签名直链，不让服务器变成带宽瓶颈。
这个思路到今天我依然觉得是对的。
但几年后再回头看，V1 解决的是“能不能自己搭一个网盘”的问题，却没有解决“能不能长期稳定地用下去”的问题。更尴尬的是，作为 ZPan 的作者，我自己其实都没有一个长期稳定运行的 ZPan 。
这也是我重新做 ZPan V2 的起点。
连作者自己都懒得运维
以前要跑一个 ZPan ，大体上还是传统服务端应用那一套：找一台 VPS ，装环境，跑服务，配反代，配证书，配数据库，后面还要处理更新、备份、磁盘、内存、进程挂掉、系统升级这些事情。
每一件单独看都不难。
麻烦的是，它平时没事的时候你几乎感受不到成本，一旦出问题，你就必须立刻切换到运维模式。服务挂了要上去看日志，证书有问题要查配置，机器抽风要重启，磁盘满了要清理。可能一年只有几次，但每一次都很烦。
我后来发现，如果一个产品连作者自己都不愿意长期运维，那它对普通用户也很难真的友好。
所以 V2 最大的技术方向，不是简单换个前端框架，也不是把 Go 换成 TypeScript ，而是把 ZPan 往 Serverless 上迁。
现在 ZPan V2 优先支持 Cloudflare Workers ，同时也支持 Docker ，并扩展到 AWS Lambda 、Vercel 、Netlify 、Azure Functions 、Google Cloud Run 等运行环境。尤其是 Cloudflare Workers + D1 + R2 这一套，对个人用户非常合适：不需要维护 VPS ，不需要让家里的 NAS 长期开机，也不用每天担心哪天进程挂了。
这对我自己也很现实。因为我希望可以稳定地提供一个服务，而不是隔三差五被一台 VPS 叫回去救火。
ZPan 仍然是那个基于对象存储的网盘，但它不应该再要求你先成为一个合格的运维。
也正是因为 V2 走向 Serverless ，ZPan 官方现在已经上线并运营了官方网盘服务：zpan.space。
这件事在 V1 时代其实很难下决心。因为一旦官方提供服务，就意味着我要持续维护服务器、处理故障、升级系统、盯着各种基础设施问题。对个人项目来说，这个成本很高。
但 Serverless 之后，这件事变得现实了。官方服务可以跑在更免运维的基础设施上，我不用再被服务器拖住，也能给不想自托管的普通用户提供一个稳定入口。
所以现在 ZPan 有两种使用方式：懂技术、喜欢折腾的人可以继续自托管；普通用户、不想管部署的人，可以直接使用 zpan.space。
V2 不只是一个网盘
如果只看表面，ZPan V2 还是文件、文件夹、上传、下载、分享这些东西。
但现在我更愿意把它叫做一个 S3 原生的文件托管平台。
这个差别在哪里呢？
传统网盘通常把“文件系统”当成核心。文件在服务器磁盘上，或者在某个网盘提供商里，应用围绕这些文件做管理。ZPan V2 的核心不是本地文件系统，也不是各种网盘账号聚合，而是一套围绕 S3 兼容对象存储的控制平面。
文件存在哪里？在 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储里。
ZPan 负责什么？负责用户、组织、团队、目录、对象元数据、上传会话、分享链接、图床路径、WebDAV 映射、配额和权益、远程下载任务、后台任务、审计、公告、授权和商业化能力。
所以 ZPan 不是要替代对象存储，而是给对象存储补上一个适合人使用、适合团队使用、适合运营使用的入口。
这也是 V2 和 V1 最大的区别。V1 更像一个“对象存储版私人网盘”，重点是替代某些限速网盘。V2 则更像一个“S3 文件工作台”，重点是把对象存储变成一个可管理、可分享、可接入工具、可运营的产品。
文件管理重新做了一遍
V2 重新做了完整的文件管理体验：上传、下载、新建文件夹、重命名、移动、复制、批量操作、搜索、回收站、文件预览、上传进度、名称冲突处理等都重新梳理了一遍。
这里面有一些看起来不显眼但很关键的变化。
比如上传不只是返回一个上传地址那么简单。V2 里有对象上传会话，可以处理更大的文件上传和分片预签名，文件先进入 draft 状态，确认上传完成之后才真正变成 active 。这样前端、对象存储、数据库记录之间不会轻易出现“文件没传完但记录已经存在”的脏状态。
再比如删除不是直接删对象，而是先进入回收站；替换文件时，旧文件也可以按规则进入回收站；批量操作会有进度和失败反馈；重名冲突可以选择替换或保留两者。
这些都不是特别适合拿来做噱头的功能点，但它们决定一个工具能不能每天用。
图床是一等场景
我自己写博客、写文档、发截图时，经常需要一个稳定的图床。以前大家会用各种免费图床，后来一个个失效；也有人直接用对象存储，但每次上传、复制链接、管理路径都不够顺手。
V2 把图床作为核心场景来做。
你可以在 ZPan 里开启图床能力，配置路径规则、访问域名、Referer 白名单，然后用 API Key 接入 PicGo 、PicList 、uPic 、ShareX 、Flameshot 这些常见工具。截图之后直接上传到自己的 ZPan ，返回的就是自己的稳定链接。
这套东西底层仍然是对象存储，但体验上更像一个图床产品。对开发者、博主来说，这个场景可能比“网盘”本身还高频。
分享不只是发一个链接
网盘最常见的动作就是分享。V2 的分享不再只是把文件丢出去，而是支持访问页、直链、密码、过期时间、下载次数限制、访问统计、下载统计，以及保存到自己网盘。
文件夹分享也不是简单暴露一个目录，而是会在分享页里继续按 ZPan 的目录模型浏览。每个用户还可以有自己的公开主页，把公开分享过的资料整理出来。
这意味着 ZPan 不只是私人存储，也可以变成一个轻量的文件发布工具。项目 release 、设计稿、安装包、课件、素材包、公开资料页，都可以用同一套分享能力完成。
团队、配额和权益
V1 更偏个人使用，V2 从一开始就有组织和团队的模型。
每个用户有自己的个人空间，也可以加入团队空间。文件、成员、角色、活动记录、配额都围绕工作空间来组织。这样 ZPan 就不只是“我自己的网盘”，也可以承担小团队内部资料库、素材库、交付文件管理这些场景。
V2 的配额模型也不再只是一个简单的数字。它有基础配额、存储权益、流量权益、当前套餐、额外包、周期流量统计等概念。这样以后不管是免费自用、团队内部分配，还是商业化售卖存储套餐，都能在同一套模型上继续发展。
这也是为什么我说 V2 不是一个简单的网盘重写。它已经开始具备“运营一个文件服务”的底层结构。
WebDAV 、后台任务和远程下载
V2 也在补齐外部访问和文件工作流。
WebDAV 可以让你把 ZPan 挂到系统文件管理器、同步工具或其他支持 WebDAV 的客户端里。它不是把对象存储密钥暴露给客户端，而是通过专用 API Key 访问 ZPan ，再由 ZPan 映射到用户有权限访问的工作空间和文件树。
后台任务则承载压缩、解压等文件处理流程。小文件 zip 压缩和解压可以直接在当前运行环境里完成，并且有任务状态、进度、失败原因和结果记录。
远程下载也不是让主站自己去长期跑下载进程。V2 的设计是 ZPan 做控制中心，下载器作为独立节点注册进来，通过心跳上报状态、能力、速度和任务进度。ZPan 负责创建任务、分配任务、展示进度、最后把完成的文件导入对象存储。
这样主站仍然保持轻量，需要网络环境和临时磁盘的工作交给下载节点。
把 WebDAV 和远程下载放在一起，就会出现一些很实用的玩法。
比如你可以把下载器部署在网络条件更合适的地方，在 ZPan 里创建远程下载任务。下载器负责把媒体资源下载下来，再上传回 ZPan 。随后你用 Infuse 、VidHub 这类媒体客户端，通过 WebDAV 连接 ZPan ，就可以直接观看这些资源。
这样 ZPan 就可以变成一个轻量的媒体资源中转和管理中心：远程下载负责把资源带回来，WebDAV 负责让播放器和客户端读到它，对象存储负责保存文件。
我也在做另一个媒体资源聚合相关的开源项目，它同样会是一个可以自托管的项目。未来它会对接 ZPan ，让用户更方便地搜索资源、一键下载，再通过 WebDAV 观看。这个项目还在开发中，有兴趣的话可以关注我的 GitHub ，后面会开源出来。
版本分层：开源、支持与商业化
V2 现在也有更清晰的版本分层：Community 、Pro 、Business 。
这里我想说清楚一点：ZPan 并不是把个人使用需要的基础能力都放到付费版里。基础文件管理、分享、图床、社交登录/OIDC 、邀请码等能力属于 Community 的核心范围。对于个人、自托管用户、小团队来说，这些能力已经可以覆盖大多数日常场景。
Community 面向个人、家庭和小范围自用。它不是残缺版本，而是完整覆盖日常网盘、图床、分享、WebDAV 这些基础需求。只是为了保持社区版的边界清晰，会有一些高级能力和规模限制。
Pro 更像一个功能解锁授权。更坦诚一点说，它也是一种对 ZPan 开源项目的支持。一个开源项目如果完全没有收入，很难长期稳定地投入时间、精力和基础设施成本。Pro 会解锁一些更高级的能力，比如自定义品牌、调整站点名称、开放注册、更多团队空间、更多存储后端、站点公告、审计日志等。它更适合重度个人用户、家庭用户、小团队，或者希望把自己的 ZPan 实例做得更完整、更像自己产品的人。
Business 才是面向“运营一个 ZPan 实例”的版本。如果你想对外营业，把 ZPan 当成一个商业化服务来运营，给用户售卖存储套餐和流量权益，或者围绕下载器、存储出口流量做 Credits 计费，那应该使用 Business 。
这个分层的原则很简单：Community 覆盖个人和家庭的完整基础体验； Pro 解锁更高级的站点和团队能力，同时支持项目继续发展； Business 面向对外运营和商业化闭环。
适合谁用
如果你是开发者、博主，想要一个自己的图床，ZPan 很适合。
如果你有 R2 、S3 、B2 、OSS 、COS 、MinIO 、RustFS 、Tigris 这些对象存储，但缺一个好用的 Web 管理入口，ZPan 很适合。
如果你经常要分享文件、发布资料、给别人一个稳定下载链接，ZPan 很适合。
如果你是一个小团队，想把设计素材、项目文件、交付物、内部资料统一放到一个可控的地方，ZPan 也很适合。
但如果你想要的是多人在线文档协作、企业 IM 、日历、邮件、全套办公套件，那 ZPan 不是这个方向。它不会去做一个更小的 Nextcloud ，也不会去做一个更复杂的 AList 。ZPan 会继续专注在 S3 对象存储之上的文件托管和文件工作流。
顺便聊聊 Agent Kanban
最后再聊一下这次重做的开发方式。
ZPan V2 的开发过程，基本上是通过 Agent Kanban 完成的。
我没有像过去那样一行一行地写代码，而是把自己放在产品负责人和架构负责人的位置：定产品方向、定架构边界、定工程规则、拆任务、写验收标准、做 review ，然后让 Agent 去实现。
这件事不只是“用 AI 写代码”这么简单。
过去一两年很火的 vibe coding ，更多是让用户在网页里描述一个想法，然后生成一个能看的 demo 。这个方向很有价值，但它离真实产品开发还有距离。
真实项目需要的不只是“生成代码”，还需要任务拆解、上下文管理、架构约束、测试验证、代码审查、持续迭代、问题回滚，以及多人协作里的责任边界。换句话说，它需要一套 agent harness：围绕 Agent 的任务系统、工具、状态、权限、执行环境、观测和验收机制。
Agent Kanban 想验证的就是这个方向：能不能把 vibe coding 往 harness engineering 推进一步，从一个偏 demo 的流程，推进到可以稳定交付真实产品的工程流程。
ZPan V2 算是我的一个验证场。
整个 V2 的过程中，我更像是在管理一个 Agent 团队：我定义需求和边界，Agent 负责实现；我定义验收标准，Agent 根据标准补测试、修 bug 、完善交互；我不追求一次生成一个大而全的结果，而是让每个任务都进入一个可追踪、可 review 、可验收的流程。
最后 ZPan V2 能跑起来，功能也能一轮轮补齐，至少说明这套方法是有机会的。
所以这篇文章表面上是在介绍 ZPan V2 ，背后其实也记录了另一件事：我正在用一个真实产品，验证 agent harness 这一套工程化方法能不能从“写 demo”走到“做产品”。
最后
几年前我做 ZPan ，是因为有人跟我抱怨网盘不好用。
几年后我重做 ZPan ，是因为我发现“把文件放到对象存储里”这件事已经越来越普遍，但大家仍然缺一个轻量、现代、免运维、可自托管、可运营的入口。
ZPan V2 想做的就是这个入口。
如果你也受够了网盘限速，或者正在找一个自己的图床、文件分享站、团队资料库，欢迎试试 ZPan 。
- GitHub：https://github.com/saltbo/zpan
- ZPan 官方服务：https://zpan.space
- Agent Kanban：https://agent-kanban.dev
如果你已经用过 V1 ，也欢迎回来看看 V2 。它还是那个基于对象存储的 ZPan ，只是这次，我想把它做得更像一个真正可以长期稳定使用的产品。
Select Language