我是怎么用 WorkBuddy 和 Agent 把一个文件或静态网站发布出去的

在很多 Agent、脚本工具和自动化工作流里，把文件安全上传并生成可直接使用的公开链接，一直是一个高频但容易被低估的需求。很多团队一开始只想着“先把文件传上去”，真正落地时才发现，后面还会接出一长串问题：要不要登录才能上传，上传完成后返回什么链接，图片和视频能不能直接预览，大文件失败后能不能只补传缺失部分，目录站点能不能直接发布，后续更新时能不能保证新旧版本切换稳定。

OkFile 就是围绕这条链路做的一套面向 Agent 的文件上传与发布服务。它的目标不是简单再做一个上传接口，而是把“上传、发布、预览、站点化、更新回滚”这条交付链路尽量封装完整，让 Agent、脚本和轻量工具可以直接接入使用。

从能力上看，OkFile 先解决的是单文件上传场景。图片、视频、PDF 以及常见文件上传后，可以直接返回公开链接，也可以根据类型返回适合预览或播放的页面链接。对调用方来说，这一点非常实用，因为很多自动化流程真正需要的不是底层对象地址，而是一个可以马上给用户访问、分享或嵌入的结果。

第二个重要能力，是同时支持匿名上传和 API Key 上传。匿名模式适合快速试用、低门槛接入和临时发布；登录后生成 API Key 的模式，则更适合正式集成、额度控制和归属管理。这样做的好处是，产品既能覆盖轻量场景，也能覆盖更稳定的长期调用场景。

第三个能力，是对大文件的 multipart 分片上传支持。现实环境里，大文件一次性上传失败并不罕见，尤其是在脚本环境、Windows 本地环境和网络波动条件下。OkFile 在文件较大时会自动进入分片模式，上传失败后只需要补传缺失片段，不需要整文件重来。这种体验对于自动化任务非常关键，因为它能显著降低重试成本。

除了单文件，OkFile 还支持整站目录上传。也就是说，调用方不只是上传一个文件，还可以上传一整个静态站点目录。上传完成后，系统会保留子目录结构，并直接返回站点访问地址和入口页地址。这样一个前端目录就可以直接变成一个独立子域名站点。

这个站点能力里有两个设计点很有代表性。第一，如果上传目录里所有文件都位于一个公共顶层目录下，系统会自动裁剪这个公共目录，把里面的内容视为站点根目录。第二，如果站点根目录没有 index.html，系统不会报错，也不会强迫调用方额外生成一个用于列目录的伪首页，而是自动渲染目录列表。对于文档目录、图片集合、输出结果集这类并不标准的站点来说，这种行为会更加自然。

在很多面向 Agent 的场景里，真正困难的并不是第一次发布，而是后续持续更新。传统的原地覆盖方式很容易出现混合状态，比如 HTML 已经变成新版，但 CSS、JS 或图片资源仍然还是旧版，导致用户访问时出现错乱。为了解决这个问题，OkFile 现在引入了版本化更新模型。每次更新已有网站时，系统会先准备一个新版本，待所有文件上传完成后再原子切换到新版本。如果新版本有问题，还可以从后台一键回滚到旧版本。

这种设计对 Agent 场景尤其重要。因为一旦系统开始承担“自动生成内容并持续发布”的任务，稳定性就会变得比第一次上传更重要。日报、周报、分析报告、知识库快照、模型输出结果页面，这些都很适合用目录站点发布的方式来承载，而版本切换和回滚可以让这种模式更接近真实生产环境。

从技术架构上看，OkFile 建立在 Cloudflare Pages Functions、Workers、R2 和 D1 之上。页面与 API 负责接收请求和输出结果，R2 负责文件存储，D1 负责用户、会话、API Key、站点和版本等元数据管理，Worker 则负责站点子域名路由与发布解析。这样的架构让它既能保持边缘侧访问优势，也适合做轻量而稳定的发布链路。

我觉得 OkFile 这个方向的价值，不在于“它又是一个文件上传工具”，而在于它把 Agent 真正常用的最后一段交付链路产品化了。很多 AI 工具今天已经能生成图片、视频、文档和网页内容，但距离“稳定交付给用户”往往还差一个上传、分享、预览和发布层。OkFile 正是在补这层能力。

如果你正在做 Agent 工具链、自动化内容发布、轻量站点生成、报告导出或者面向外部用户的临时文件分享，那么 OkFile 这种“上传加发布加预览加站点化加更新回滚”的一体化方案，值得关注。

官网地址是 https://www.okfile.com/ ，GitHub 仓库是 https://github.com/okfilecom/okfile 。从当前演进方向来看，未来如果继续补强站点更新差异摘要、更细粒度的权限控制和更适合 Agent 的标准化 Skill 接入，这条路线会更完整。对于一个面向 Agent 的文件与站点发布服务来说，这只是刚刚开始。