AI Agent 运营工具周报：从中文内容采集到审批发布，7 个新入口值得试
本期盘点 Prism、chubbyskills、OpenPost、Locality、Activepieces、OpenViking 与 OPENBOT，核对中文平台采集、跨平台发布、文件写回、人工审批、长期记忆和浏览器 Agent 的真实入口与落地边界。
这期更值得看的，是把 Agent 接到运营流程中间的七个入口：有的负责中文平台采集，有的把成稿送进发布队列，有的把外部应用投影成本地文件，还有的专门保存记忆、安排审批或隔离工具凭据。它们解决的是不同工序，接入前需要先确认一个问题：Agent 看到的内容、准备执行的动作，以及真正发生的写入，能不能分别查到来源和结果。
本期挑出 7 个此前没有在频道重点覆盖的项目。信息以 2026 年 8 月 24 日 08:00（北京时间）前后仍可读取的官方 GitHub README、项目文档和 Product Hunt 产品页为准。README 明确写出的国内平台能力才会写进正文；平台名单、浏览器能力或 MCP 入口本身，不足以推出完整的发布链路。
先看：7 个入口各自补哪一段
| 工具 | 一句话定位 | Agent 接口 | 适合接入的工序 | 先记住的边界 |
|---|---|---|---|---|
| Prism | 用本地浏览器会话把视频内容批量投放到多个平台 | CLI / Web / Docker / 浏览器自动化 | 多账号排程、视频发布、抖音与 B 站数据回收 | README 明写的发布平台包含抖音、快手、小红书、视频号和 B 站；登录态、设备证明、验证码与平台风控仍决定实际成功率。1 |
| chubbyskills | 把中文全渠道内容采集、转写和知识库检索拆成可安装的 Agent Skill | Skill / 本地脚本 / 知识库 MCP | 竞品监测、素材入库、视频转写、选题回收 | 这是采集与知识库入口，不是发布器；视频和播客转写需要额外依赖，真实平台测试仍受 Cookie、地区和风控影响。2 |
| OpenPost | 用同一套 token、API、CLI 和 MCP 管理跨平台成稿与排程 | API / CLI / MCP / Web | 成稿审核、定时发布、状态查询、失败重试 | README 列出海外平台适配，国内平台不在明示范围；已实现适配器与 Hosted 服务实际开放情况要按 Provider Readiness 逐项确认。3 |
| Locality | 把 Notion、Gmail、Linear 等系统记录源投影成 Agent 可读写的本地文件 | 文件系统 / loc CLI / Agent 指令文件 | 运营资料检索、草稿整理、经过审查的写回 | Slack 和 Granola 只读；Locality Cloud 是独立产品，不能把 Desktop 的本地投影直接当成集中式权限控制。4 |
| Activepieces | 用可视化工作流、MCP 和人在回路节点编排运营动作 | Workflow / MCP / TypeScript pieces | 表单触发、审批、定时任务、跨服务编排 | README 对 pieces 数量有 280+ 与约 400 两种口径；结构化输出 schema 也没有在 README 中明确说明。5 |
| OpenViking | 把 Agent 记忆、知识 RAG 和 Skill 放进同一个上下文数据库 | ov CLI / HTTP 服务 / MCP 客户端 | 长期选题记忆、内容库检索、Skill 复用 | 主项目 README 仍标为 early stages，主项目采用 AGPLv3；它补的是上下文层，不是平台发布层。6 |
| OPENBOT | 让持久化 Bot 共享浏览器、Shell、文件系统和 MCP 连接器 | 桌面端 / CLI / MCP / Cron | 定时巡检、浏览器操作、需要人工确认的任务 | 项目当前标为 Pre-alpha；Bot 共享浏览器会话、Shell 凭据和文件，guest 也不是虚拟机或容器。7 |
1. Prism：国内多平台发布，先把登录态当成一等问题
Prism 的 README 把它定位成一个批量定时发布和上传工具。项目列出的内置适配器包括抖音、快手、小红书、视频号、B 站、TikTok 和 YouTube；README 还写明，抖音和 B 站目前支持已发布视频的数据回收。1
它的运营价值在执行层。一个成稿可以进入统一任务队列，再组合目标平台、账号和素材，最后读取发布结果、失败重试、执行日志和数据回收。README 明确写到「一句话投放」会生成标题、标签和话题，并定时发布到多个平台；这让 Prism 更适合做内容矩阵的排程入口，而不是只做一次性的浏览器脚本。1
典型场景是把已通过人工审核的视频放进队列：Agent 负责生成平台差异化标题，人工确认目标账号和发布时间，Prism 执行上传并回传任务状态。README 没有把「发布成功」简化为一个布尔值，而是同时列出任务看板、执行日志、失败重试和数据回收，接入时可以要求流程保存平台、账号、素材、任务状态和失败原因。1
安装入口有 Docker、本地 Python 环境和 CLI。Docker 部署会启动 Redis、应用、前端、Celery Worker 和 Automation Worker；本地部署示例使用 Python 3.11.4、Redis、FastAPI、Celery 与前端，CLI 可以通过
pip install -e . 安装。1登录态是 Prism 的第一验收项。抖音、快手、小红书、视频号和 B 站的正式登录路径，是在运行 Prism 的本机浏览器中登录并复用 Patchright 登录态；TikTok 和 YouTube 也会保存浏览器 storage state 供任务队列复用。README 还写明，抖音纯 HTTP 二维码登录的后续登录态仍依赖平台设备证明，暂不作为正式发布链路。1
这意味着 Prism 适合先用小号和低频任务验收。账号文件、本地浏览器目录、设备证明、验证码和平台频控都会影响结果；项目 README 也提醒，规模化发布必须配合内部审核、风控和平台规则。平台名单可以说明项目做过适配，不能替你保证某个账号今天一定能发出去。1
2. chubbyskills：把中文平台内容送进 Agent 能搜索的知识库
chubbyskills 把中文内容采集拆成 13 个 Agent Skill。README 明确列出 B 站、YouTube、抖音、TikTok、微博、知乎、播客、微信公众号、小红书和 X / Twitter 等来源；能力包括字幕优先转写、图文存图、视频转文字稿、爆款拆解和衍生选题。2
它解决的是「读什么、存在哪里、下一次怎么搜」。采集结果默认写成带 YAML frontmatter 的 Markdown，字段包括标题、平台、来源、作者、标签、运行编号、内容状态和素材信息。内容可以进入 Obsidian 或本地 vault，再由 SQLite 提供全文搜索、语义检索、索引统计和健康检查。2
知识库 MCP 暴露了搜索 vault、语义搜索、读取笔记、重建索引和查看统计等能力。Agent 可以先搜索最近一个月的小红书和 B 站素材，再读取原文笔记和附件，最后把反复出现的问题写成选题卡。MCP 在这里负责检索和读写知识库，平台采集 skill 负责把内容变成文件；两层职责分开，故障也更容易定位。2
安装入口是分档脚本：
bash setup.sh 安装轻量依赖，bash setup.sh video 加装视频转录依赖，bash setup.sh podcast 加装播客依赖，bash setup.sh wechat 加装公众号与 PDF 处理依赖，bash setup.sh doctor 做环境体检。README 说明，视频和播客转写会引入 ffmpeg、funasr、yt-dlp 或 faster-whisper 等依赖，轻量模式更适合先做图文采集和知识库检索。2项目页面显示当前版本为 0.11.0，采用 MIT License，并提供离线 quickstart、平台健康检查、smoke tests、golden outputs 和 schema 校验。README 同时提醒，真实平台测试需要显式开启，Cookie、地区、风控、依赖和链接有效期都可能让采集失败。2
它适合放在发布流程之前：Agent 先收集公开内容和素材，再把每条笔记的原始链接、采集时间和平台字段保留下来。它不提供平台发布能力，不能因为它能读取微信公众号、小红书或抖音，就把它写成这些平台的自动发布器。
3. OpenPost：用 token 把「成稿—审批—发布—状态」接起来
OpenPost 同时提供 API、CLI、MCP Server 和 Web 端。README 的关键承诺是：自动化操作使用与 Web 应用相同的工作区、权限和状态，Agent 通过 token 接入，团队不需要把社交平台登录凭据直接交给 CLI 或 MCP。3
这条权限边界适合内容团队做最小化授权。Agent 可以先创建草稿、写入排程，再由人工批准；发布任务会进入数据库，服务器重启后仍然保留。README 明确列出的状态包括
queued、published、failed 和 waiting to retry，因此流程可以根据状态决定是否重试或转人工，而不是只等待一个模糊的「完成」。3平台范围需要读得很窄。README 列出 X、Mastodon、Bluesky、LinkedIn、Threads、Facebook Pages、Instagram、TikTok、YouTube 和 Discord Webhooks；没有明写微信、小红书、抖音、B 站、知乎、微博或视频号。README 还提醒，已实现的适配器不等于 Hosted 服务已经开放，部分平台需要应用审核、账号类型或额外 scopes，正式接入前要查看 Provider Readiness 和 Platform Limits。3
入口与部署有两种。读者可以使用 Hosted service 的 14 天试用，也可以通过 Docker Compose 自托管；自托管默认使用 SQLite、本地媒体存储和持久化任务，仓库还提供
ghcr.io/getopenpost/openpost 的 amd64 镜像。3OpenPost 的回执目前至少能回答三个问题：任务排在什么状态、发布结果是什么、连接账户页面显示的 provider 状态是什么。README 没有承诺统一的详细回执字段、平台原生回执格式或 webhook，所以第一轮验收要自己记录平台帖子 ID、实际发布时间、错误正文和重试次数。3
4. Locality：让 Agent 用文件工具读写运营资料
Locality Desktop 把 Notion、Google Docs、Google Calendar、Gmail、Linear、Slack 和 Granola 的内容投影成本地文件夹。连接的应用仍然是记录源，Locality 负责同步文件、元数据和附件；Agent 可以像处理代码库一样，用搜索、脚本和编辑器读取这些文件。4
它对运营团队的价值在于降低连接器切换成本。Agent 可以用同一套文件操作搜索会议纪要、整理 Gmail 线程、读取 Linear Issue，再把一个内容排程草稿写到本地。
loc CLI 可以定位、检查、刷新、审查和安全更新挂载内容，适合让任务脚本把「读到什么、准备改什么」留在文件差异里。4写回动作有明确的人工接手点。Locality 会在写入前检查远程版本，遇到并发编辑、版本漂移、不支持的操作、破坏性变更或可能造成内容损失时暂停，并要求人工审查。Notion 页面、块、属性和数据库行，Google Docs，Gmail 草稿，Calendar 事件草稿以及 Linear Issue 有各自的写回范围；Slack 和 Granola 保持只读。4
典型场景是把一个周报工作流拆成三步：Agent 从本地投影读取上周的发布记录，从 Gmail 和会议纪要整理候选，再把本周草稿写到一个待审目录。人确认差异后，系统才把允许的更新同步回 Notion 或 Gmail。这个动作链保留了远程版本检查和变更列表，适合先做低风险的草稿与资料整理。
入口是 Locality 下载页，README 还提供
make setup、make build、make test 和 make dev-tauri 等源码命令。项目采用 Apache License 2.0，README 页面显示约 2,000 次提交、17 stars 和 3 forks，并注明项目仍在持续开发。4权限边界要分清：README 所说的 Desktop 在本机直接连接各应用 API，不经过 Locality 后端，也不收集使用遥测；Locality Cloud 是面向生产 Agent 的独立产品，提供预同步缓存、沙箱挂载和集中式细粒度访问控制。团队若需要中心化权限，应单独评估 Cloud 的产品边界，不能把 Desktop 的本地文件夹当成权限系统。4
5. Activepieces：把审批节点放进可编排的工作流
Activepieces 是开源的 AI 自动化和工作流平台。README 列出的能力包括可视化流程、循环、分支、自动重试、HTTP 请求、代码步骤、版本化、AI pieces 和 Human in the Loop；集成 pieces 还会作为 MCP server 提供给 Claude Desktop、Cursor 和 Windsurf。5
它适合承接跨服务的运营动作。一个表单可以触发选题收集，HTTP 步骤读取外部数据，代码步骤清洗字段，审批节点等待内容负责人确认，最后再调用发布或通知动作。README 还提到 Google Sheets、OpenAI、Discord、RSS 等集成，以及用 TypeScript pieces 框架创建自定义触发器和动作。5
安装与运行支持自托管和网络隔离环境，仓库提供 Dockerfile、Docker Compose 与部署文档入口。Community Edition 采用 MIT License，企业功能采用商业许可。5
它的一个实际优点，是把人工批准作为工作流节点保存下来。Agent 可以负责准备标题、素材、目标平台和发布时间，审批人只需要查看差异与风险；拒绝后，流程可以回到改稿步骤，批准后再执行下一步。这样「有人看过」会成为任务状态，而不是一句写在提示词里的要求。5
项目文档存在两个需要留意的口径：README 正文写有 280+ pieces 可作为 MCP，仓库 About 区域又写约 400 个 MCP servers；这两个数字没有统一解释。README 也没有明确承诺 JSON Schema、固定字段或其他结构化输出协议。接入时要直接查看具体 piece 的输入输出定义，不能用总数代替接口验收。5
6. OpenViking：把长期选题记忆和 Skill 放在同一层
OpenViking 将自己定位成面向 AI Agent 的开源 Context Database，统一管理 Agent Memory、Knowledge RAG 和 Skills。它使用
viking:// 虚拟文件系统保存资源、记忆和 Skill，Agent 可以用 ls、tree、find 和 grep 逐层浏览上下文。6这套分层加载模型适合长期运营内容库。每条内容会生成 L0 摘要、L1 概览和 L2 细节，Agent 可以先判断目录是否相关，再加载原文；检索过程还会保留目录浏览轨迹，便于回看 Agent 为什么找到某条资料。6
典型场景是让每周选题拥有持续记忆。Agent 把过去发布过的主题、受众反馈、平台边界和失败原因写入记忆，再用
ov find 找出相近选题；下一步读取完整资料前，Agent 先用目录层级排除重复内容。这个场景补的是记忆和检索，实际发布仍要接另一个写入工具。安装入口是 Python 包和独立服务：
pip install openviking --upgrade，再运行 openviking-server init 生成配置，使用 openviking-server doctor 检查 Provider、模型和磁盘空间，最后启动 openviking-server。服务运行后，内置 ov CLI 可以执行 ov status、ov add-resource、ov ls、ov tree、ov find 和 ov grep。6项目 README 列出 Claude Code、Codex、OpenClaw、Hermes、Cursor、TRAE、OpenCode、LangChain、LangGraph 和 MCP clients 等集成方式。README 同时把主项目标为 early stages，页面显示约 2,068 次提交、32.5k stars 和 2.5k forks；0.3.22 已用于 README 所列的评测，主项目采用 AGPLv3。6
因此，OpenViking 适合把「记住什么、如何检索、哪些 Skill 可复用」先在本地或隔离环境里跑通。团队若要把它用于商业服务，应先核对 AGPLv3、上下文数据存储位置、模型 Provider 和删除机制，再把生产内容库接进去。
7. OPENBOT：持久 Bot 加浏览器，审批仍在 hub 一层
OPENBOT 在 Product Hunt 页面上的定位，是给 Agent 一个持久的工作伙伴：Bot 有自己的对话、记忆和日程，多个 Bot 共享一台带浏览器、Shell 和文件系统的计算机；有 MCP 连接器时走 MCP，没有连接器时走浏览器。Product Hunt 页面提供了 GitHub 获取入口，项目 README 则给出了桌面端、CLI 和源码运行方式。78
它适合需要持续运行的轻量任务。Agent 可以通过 Cron 触发器每天巡检公开页面，整理结果后等待人工确认；也可以把没有 MCP 连接器的页面交给浏览器工具操作。
openbot routine new 可以创建绑定 Bot 的 Cron 任务，项目还提供非活跃保护：一段时间内没有人查看账户时，Routine 会暂停执行。7审批由 hub 统一执行。流程是 Agent 请求调用工具，hub 先做策略检查，必要时要求用户批准，再由 guest 执行；用户可以只允许一次、允许本次会话或拒绝。审批 hook 超时、崩溃或返回无法解析的结果时，默认会拒绝调用，除非显式配置
fail_open。7安装入口包括 Windows
.exe、macOS .dmg、Linux .AppImage 和 .deb，也可以用 Rust 1.89+ 从源码安装：cargo install --path crates/openbot-cli，再运行 openbot up。README 还提供 openbot run --demo --approve auto "prove it" 的无 API Key 演示。7安全边界决定了它目前更适合实验。guest 以当前用户身份运行，是普通进程，不是虚拟机或容器；Bot 之间共享文件、浏览器会话和 Shell 凭据；文件系统限制由应用代码实现，还可以通过参数关闭。README 将项目标为 Pre-alpha，并提醒浏览器自动化可能被网站检测，网页提示注入也可能诱导 Bot 执行恶意操作。7
如果用 OPENBOT 接触内容平台，先把浏览器任务限定在读取、截图和生成草稿，给写入、发帖、删除和外部 Shell 命令设置逐次审批。这个边界与项目当前的实验状态相匹配，也能避免把共享会话误当成账号隔离。
一条更容易验收的接入顺序
这 7 个项目适合分层试，不适合一次性全部接入生产环境：
- 先读。 用 chubbyskills 收集公开内容，把原始链接、平台、作者和采集时间写进 Markdown；用 OpenViking 保存选题记忆和失败原因。
- 再整理。 用 Locality 把 Notion、Gmail、Linear 等资料投影成本地文件，让 Agent 先生成差异和草稿；涉及写回时，保留远程版本检查和人工审查。
- 再编排。 用 Activepieces 把表单、HTTP、代码步骤和人工审批串起来；每个 piece 单独核对输入、输出和权限。
- 再执行。 国内视频矩阵可以先用 Prism 做低频、小号测试；海外或明确列出的平台可以评估 OpenPost，但要先看 provider readiness。
- 最后试浏览器 Agent。 OPENBOT 先做只读巡检和草稿生成，给 Shell、文件写入和平台写操作设置逐次审批。
每个试点都保留五类记录：来源 URL、Agent 计划、实际调用、任务状态、人工确认结果。发布类任务再加平台帖子 ID、账号、发布时间、失败正文和重试次数。一个工具如果只返回「已完成」，却没有来源、状态或可查询的结果，就先留在实验环境。
结论：Prism 补的是国内视频平台的浏览器执行和任务回收，chubbyskills 补的是中文内容采集与知识库入口，OpenPost 补的是带状态的 API / CLI / MCP 发布，Locality 把企业资料变成 Agent 可处理的文件，Activepieces 负责跨服务编排和人工审批，OpenViking 负责长期记忆，OPENBOT 则把持久 Bot、浏览器和审批放到同一个运行时里。它们分别解决读、整理、编排、执行和记忆，读者可以按自己的缺口先验收一层，再决定是否继续扩大权限。
References
- 1Prism README
github.com
- 2chubbyskills README
github.com
- 3OpenPost README
github.com
- 4Locality README
github.com
- 5Activepieces README
github.com
- 6OpenViking README
github.com
- 7OPENBOT README
github.com
- 8OPENBOT Product Hunt 页面
producthunt.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.