排程发布、啃长文档、剪视频,三个仓库在给 Agent 补手

你大概都遇到过这种场面。想让 Agent（能自己调用工具、连续干完一件活的模型程序）把本周稿子排到各个平台，它会把文案写漂亮，一到发布就停住。登录、授权、排期都不在它手里。

换成读一份一百多页的扫描件，前几页还能对上，翻到后面开始串行、漏段。再换成剪短视频，它能写出 ffmpeg 命令，跑完却说不清成片对不对。

三件事看着分散，卡点接近。模型会写，不等于接得上外部系统，也检查不了自己交出去的东西。今天这三个仓库各补一段。

gitroomhq/postiz-app 管发布和排期，baidu/Unlimited-OCR 管超长文档解析，kajisho5/ffmpeg-skill 管在本机剪片并自查结果。

图 仓库首页截图，页面标题和简介来自 gitroomhq/postiz-app 仓库本身，说明本文讨论的是自托管版本。

稿子写完到发出去，中间隔着各平台的授权页、字段限制和时间窗。人做这件事靠记性。Agent 缺的是那个能替它保管令牌、按平台改格式、到点再发的中间层。

gitroomhq/postiz-app 就是这层。README 把它定位成社交媒体管理平台，负责排程、自动化与效果分析，给出云版和自建开源版两条路。

仓库用 AGPL-3.0，默认分支 main，2023 年 7 月建仓。累计 39,950 stars、7,571 forks，开放 issue 218 个，当天热榜新增 1,007 stars，最新发行版 v2.25.3 发布于 2026 年 10 月 24 日。

技术栈写在 README 里。前端是 NextJS，后端是 NestJS，Prisma 配 PostgreSQL，Temporal 负责定时与长任务，整个仓库用 pnpm workspaces 管。

排期不靠一张 cron 表，靠的是能重试、能追状态的工作流引擎。

接入面铺得很宽。README 列出 Instagram、YouTube、LinkedIn、TikTok、X 等渠道，也给面向 Agent 的入口，Claude Code、Codex、Cursor、OpenClaw 各有连接方式。

它还提供 MCP server（让模型用统一协议调用外部工具的服务端）、CLI（命令行界面）、公开 API（程序调用的接口）和 webhook（事件发生时推给你的回调地址）。n8n、Make.com 这类工具可以直接接。

需要提前想清楚的地方在自托管。README 的对照表写得诚实。云版用平台预审过的应用，开箱即连。

自建版要自己去每个平台注册开发者应用再走审核。Meta、YouTube、TikTok 可能要几周。数据不出自己的服务器，代价是把这段等待挪到前面。

运行依赖也不轻。官方文档要求自备 PostgreSQL、Redis、对象存储和一组环境变量。更新时自己拉镜像、跑迁移、盯备份，这些活云版由官方承担。

现版本的坑有公开记录。开放 issue #918 从 2025 年 8 月挂到现在，仍有人在自托管实例上添加渠道时收到 Could not add provider，重定向发生在授权开始之前。

issue 正文的 docker-compose 注释要求 MAIN_URL 和 FRONTEND_URL 与实际域名一致，但没解决问题。2026 年 4 月回帖把根因落在代码层，LinkedIn provider 带着要 Community Management API 的 organization 权限，授权地址还传了 prompt=none，回帖附有补丁分支。

我的判断是，想快速验证 Agent 能否接管发布就用云版。想把内容数据和令牌留在自己机器上就上自建版，但要先把域名、HTTPS、平台审核排进工期。两条路的差别落在交付时间。

一页扫描件还能当图片看，一百页就要考虑上下文怎么放。

常规做法是逐页塞进窗口。页数一多，显存和时延跟着涨，后面几页还会因为前面太长而丢细节。

baidu/Unlimited-OCR 换了思路。README 在 2026 年 10 月 27 日的更新里放出 Unlimited OCR 2，主力是稀疏参考滑动窗口注意力，简称 SR-SWA。

它把文本和图像之间的注意力交互压到一组固定大小的工作参考上，README 举的量级是 512 个 token。这样一来，每一步解码的时延和显存基本不随文档长度增长。

直接结果是整份文档可以一次送进去解析，多页之间能互相参照。README 的接口也按这个用法写，多页推理按页序传图片列表，输出按同样页序返回。

仓库同一天放出 MarathonDocBench，一个测超长文档的新基准。权重在 Hugging Face 和 ModelScope 都能拿到。

指标方面，当天热榜新增 504 stars，累计 29,507 stars、3,138 forks、94 个开放 issue，MIT 许可，2026 年 6 月建仓。

仓库没打 GitHub release，版本只能看 main 的提交和更新日志，最近一次提交在 2026 年 10 月 28 日。

工程侧分两条。快测走 Transformers，README 记录的测试环境是 Python 3.10 加 torch 2.13.0、transformers 4.52.1，单张 A800 80GB。

正式服务走 SGLang，README 给了启动参数和显存说明。比如 mem-fraction-static 要从 0.75 降到 0.7，才能在 32 路以上并发时留出余量。

下面的评估命令来自 README，属于文档示例，本文没有实际执行。

边界也要说清。开放 issue #66 是一份独立使用者的复现报告。他在 OmniDocBench v1.6 的 1,651 页上跑官方评测脚本，得到 Overall 92.45，与项目自报的约 93.92 存在差距。

公式和表格两项与公布值基本一致，差距集中在文本编辑距离。实测 0.0870，按公开数字反推约为 0.042。

报告作者说明自己用的是 README 推荐配置，也排除了退化循环。这条对我们有用。长文档解析的文本质量要和公式、表格分开看，评估口径不一致时先核脚本再谈差距。

我更倾向于这样安排。整本书、整卷合同、上百页档案一次性入库时，把复杂度压成常数的做法值得优先试。单页票据识别用常规流程更成熟。

上线前拿自己的文档跑一遍，把输出按页序送进下游，别只看排名图。

图 README 中的 Unlimited OCR 2 概览图，画的是从长文档到无长度上限解析的定位，属于项目自述示意图，不是本文的测试结果。

让 Agent 剪视频，麻烦不在生成命令，而在交片之后的判断。帧率猜错、容器装不下某个编码、本来只需复制流却重编一遍，这些问题命令都能跑完，日志还显示成功。

kajisho5/ffmpeg-skill 把这件事拆成一套固定流程。README 的说法是先探测、尽量无损地改、再检查、最后验证。

整包提供 42 个工具，覆盖剪切、拼接、去静音、按比例裁切、字幕与卡拉 OK 高亮、贴图与动效、HDR 转 SDR、响度归一、多机位对齐、交付检查、整片渲染和批量目录。

每个工具也能作为 MCP 工具调用。默认只暴露 12 个核心工具，设一个环境变量可以列全 42 个。

最值得看的是那份机器可读的契约。每个工具的输入结构在运行时从同一个 argparse 解析器推导，CI 会在结构和参数不一致时让构建失败。Agent 拿到的参数表跟着代码走，不会出现文档和实现脱节。

工作方式朴素。只要有 ffmpeg 和 python3，整包就能离线跑，不上传素材，不需要 API key，也没有 Python 第三方依赖。可选本地转写只在装了语音引擎时启用，没装就按已有字幕处理。

当前版本 v2.17.3，发布于 2026 年 10 月 28 日。当天热榜新增 35 stars，累计 3,490 stars、279 forks，开放 issue 只有 4 个，MIT 许可，2026 年 9 月建仓。

最短路径来自 README，属于文档示例，本文没有实际执行。

第一条把技能装进 Claude Code、Cursor 或 Codex 的目录，第二条体检，第三条打印契约。

README 提醒 doctor 总状态 ok 不等于每个工具都能用。macOS 上用 Homebrew 装的 ffmpeg 可能整体 ok，字幕工具却因缺 subtitles 滤镜而不可用，要看逐工具结果。

局限同样有据可查。开放 issue #367 记录了验证层自己漏判的一次。某些 MPEG-TS 输入在剪切时整条视频流被丢掉，输出成了纯音频 MP4，工具仍报告完成并把 verified 标成 true。

报告写明根因是事后校验只复核时长和音画起点偏移，没比对输入与输出的流构成。校验规则写漏一项，通过就等于没说。

我更倾向于把它当成本地流水线的执行端。README 自己也这么分工，这个仓库只负责切、量、导出，在结构化 JSON 里报告结果。判断哪一段是亮点、成片能不能发，属于前面那层的事。

图 从 README 演示 GIF 中提取的一帧，左边是输入、右边是命令产出，展示字幕与卡拉 OK 高亮；原素材由项目脚本合成，不是本文的成片。

拼起来看，分工很清楚。想让 Agent 接管发布，先解决授权与排期的托管，postiz 交给工作流引擎和平台审核。

想让 Agent 读超长材料，先解决上下文膨胀，Unlimited OCR 用固定大小的参考窗口把成本压平。想让 Agent 交付出可核验的成片，先解决自查，ffmpeg-skill 把参数契约和验证步骤一起打包。

取舍上，我先看失败代价落在哪。发布错了要撤回，代价是公开的，postiz 值得先花时间把域名和平台审核跑通。文档解析错了，代价是下游数据脏，换引擎前用自己的文档做抽检。视频剪错了，代价是返工。

成熟度也不一样。postiz 三年多、几千 fork、两百多个开放 issue，活跃度和维护负担都在明面上。Unlimited OCR 四个月冲到近三万 stars，热度高，评测口径还要自己核。ffmpeg-skill 一个多月、issue 只有四个，生态还在早期。

验证清单可以很短。第一，postiz 用一台测试机搭起来，配好域名和 HTTPS，把一个渠道的 OAuth 走通再谈多平台。

第二，Unlimited OCR 拿自己最长的文档跑整篇解析，检查输出页数和页序。第三，ffmpeg-skill 先跑 doctor 看逐工具状态，再用有音轨的素材验证流构成没被改掉。

如果这次拆解帮你少走一段弯路，可以点个在看；想继续读这类带来源的 GitHub 拆解，把公众号设为星标就行。

•postiz-app 仓库与 README，https://github.com/gitroomhq/postiz-app

•postiz-app README 原文，https://raw.githubusercontent.com/gitroomhq/postiz-app/main/README.md

•postiz-app issue #918，https://github.com/gitroomhq/postiz-app/issues/918

•Unlimited-OCR 仓库与 README，https://github.com/baidu/Unlimited-OCR

•Unlimited-OCR README 原文，https://raw.githubusercontent.com/baidu/Unlimited-OCR/main/README.md

•Unlimited-OCR issue #66，https://github.com/baidu/Unlimited-OCR/issues/66

•ffmpeg-skill 仓库与 README，https://github.com/kajisho5/ffmpeg-skill

•ffmpeg-skill README 原文，https://raw.githubusercontent.com/kajisho5/ffmpeg-skill/main/README.md

•ffmpeg-skill issue #367，https://github.com/kajisho5/ffmpeg-skill/issues/367

•当日热榜候选快照，github-trending-candidates.json，采集于 2026 年 10 月 28 日 22 时 29 分（UTC）

我是千哥，持续分享 AI 工程化观察与干货，这里记录从论文、开源项目到工程系统的拆解。