AI Agent 运营工具周报：从发布 CLI 到中文内容采集，8 个入口值得试 (2026)

如果你的内容运营 Agent 现在只会「生成文案」，下一步最容易卡住的不是模型，而是它能不能稳定读到素材、把内容发出去、再把状态回传成机器可读结果。过去一周重新验证下来，最有价值的信号集中在三类：国内平台发布 CLI、平台内容采集 MCP，以及能把 CMS / 社媒账号接进 Agent 的官方或准官方入口。

先看结论：这周的优先级不是追新，而是补链路

工具	一句话定位	更适合的运营场景	Agent 接口形态	主要风险
PostEverywhere CLI	面向 AI Agent、脚本和 CI 的社交媒体发布 CLI；支持 11 个海外平台，并提供 `--json` 输出、REST API 和托管 MCP Server。1	海外矩阵号、产品更新、CI/CD 后自动发帖	npm CLI / REST API / MCP	依赖商业账号；不覆盖国内平台
social-auto-upload	面向创作者和运营者的一键多平台视频 / 图文发布工具；抖音、Bilibili、小红书、快手等已接入 CLI 和 Agent Skill。2	国内视频号之外的多平台分发、账号登录态复用	`sau` CLI / skills / 浏览器自动化	项目正在重构，文档部分滞后；视频号尚未接入 CLI
Contentful MCP Server	Contentful 官方 MCP Server，可让 AI 助手创建、编辑、组织和发布 CMS 内容；Codex 可用 `codex mcp add contentful ... -- npx -y @contentful/mcp-server` 接入。3	官网、帮助中心、内容库的结构化编辑与发布	MCP / npx / DXT	写入权限要用受保护环境和 RBAC 双重约束
xhs-mcp-server	小红书单平台 MCP Server，借助 Broxy 在浏览器页内把笔记 / 用户搜索和通知监控等能力暴露给 AI 客户端。4	小红书素材检索、账号消息监控、轻量运营助手	StreamableHTTP MCP / Broxy 配置	请求频繁或 `xsec_token` 不匹配可能触发风控
media-crawler-mcp-service	面向个人的数据获取 MCP 服务，已完成 Bilibili 和小红书搜索、详情、创作者信息、评论等工具，抖音、知乎、微博仍在进行中。5	选题监测、竞品内容采集、评论素材结构化	Python MCP 服务 / Playwright / Redis	默认本地无鉴权；公网部署必须加网关认证
ChubbySkills	一套遵循 Agent Skills 开放标准的中文全渠道内容采集工具集，覆盖抖音、B 站、微博、知乎、微信公众号、小红书、X、YouTube、播客等来源。6	把多平台内容沉淀进个人知识库，再供 Agent 检索和复用	Agent Skills / 脚本 / 知识库 MCP	采集类能力只适合个人学习研究，必须控制频率和授权边界
Amplipost	基于 Claude Code Multi-Agent 架构的营销中台，支持闲鱼、小红书、B 站专栏、抖音图文，并内置小红书发布层安装脚本。7	从一句话需求生成并分发多平台营销内容	Multi-Agent workflow / Playwright / xiaohongshu-mcp	Star 和提交数仍低，适合试验流程，不适合直接压生产
social_media_pubulish_MCP	轻量 MCP Server，用 Playwright 控制可见浏览器完成小红书图文草稿和抖音上传发布流程。8	想最小化验证「Agent 能否操作创作者后台」的团队	Node.js MCP / Playwright / Skill	只有小红书和抖音两条链路，且仓库规模很小

发布层：先分清「官方 API 发布」和「浏览器后台发布」

PostEverywhere CLI 的优势是边界清楚：它把 Instagram、TikTok、LinkedIn、YouTube、Facebook、X、Threads、Pinterest、Bluesky、Telegram、Discord 等 11 个平台收进一个 CLI，并声明通过对应平台官方 API 发布；命令支持 --json，这对 Agent 很关键，因为执行结果可以直接进入下一步判断。1

它更像海外社媒发布的「稳定出口」。如果你的 Agent 已经能写发布文案、生成图片或视频，只缺一个可审计的发帖动作，PostEverywhere CLI 比直接让浏览器 Agent 点后台更容易做重试、日志和权限撤销。代价是商业账号依赖明显，国内平台也不在覆盖范围内。1

国内平台这边，social-auto-upload 更接近「把浏览器自动化长期维护成产品」。它把抖音、Bilibili、小红书、快手的登录、视频上传、图文上传、定时发布、CLI 和 Skill 状态列成矩阵；当前主线命令包括 sau [平台名] login、sau [平台名] upload-video、sau [平台名] upload-note。2

这个项目的落地价值在于多账号、多平台和 CLI 主线，而不是 MCP 形式本身。对内容团队来说，它适合承担「发」这一层；但 README 也明确提到项目正在整体重构，Web 端代码不是当前主线，详细文档已落后。生产试用时应先固定 1-2 个账号、1-2 个平台做冒烟测试，再扩展到矩阵号。2

采集层：小红书与 B 站的 MCP 化正在变密

xhs-mcp-server 的设计很轻：打开小红书网页，借助 Broxy 导入配置，就能拿到 MCP 服务地址；项目说明内置 10 个 MCP 工具，并通过 StreamableHTTP 连接 AI 客户端。4

它适合做小红书单平台的搜索、消息监控和运营助手原型，不适合高频批量任务。作者把风险写得很直白：接口请求过频，或 xsec_token 参数不匹配，都可能触发风控并导致账号异常退出。对 Agent 来说，这意味着调用前必须先做频控和 ID 校验，不能让模型自己编笔记 ID 去试。4

media-crawler-mcp-service 则更偏「可分析的数据输入层」。它把登录外部化管理、任务级配置隔离、浏览器上下文复用和结构化输出写进项目定位；已完成 Bilibili、小红书的搜索、详情、创作者信息、评论，抖音、知乎、微博仍处于进行中状态。5

如果你的工作流是「每天抓候选内容 → 让 Agent 总结选题 → 再进入发布链路」，这个项目比单纯上传工具更前置。它的风险也更偏工程侧：依赖 Python 3.13+、Redis、Chrome/Chromium，默认本地/内网无鉴权，公网部署必须自行加认证。5

内容库与知识库：别只盯社媒后台

Contentful MCP Server 是这周最值得 CMS 用户试的官方入口。它不是社媒发布工具，而是把 Contentful 的内容创建、编辑、组织、发布暴露给 AI 助手；支持 Cursor、Claude Desktop、OpenAI Codex 和 VS Code，Codex 接入方式已经给出完整命令。3

这类工具的价值在「管内容」而不是「发动态」。如果团队的内容资产在 CMS 里，Agent 可以先改条目、补字段、整理内容模型，再交给现有发布链路。风险也更严肃：Contentful MCP 提供 PROTECTED_ENVIRONMENTS 保护写入 / 删除，但 README 同时提醒，这个保护只在本 MCP 服务内生效，不替代 Contentful 自身权限。3

ChubbySkills 则从另一个方向补内容库：它把中文全渠道内容采集、图文 / 视频分流处理、内容加工和知识库管理做成可被 Claude Code 等 Agent 加载的 Skills。平台覆盖很宽，包括抖音、B 站、微博、知乎、微信公众号、小红书、X、YouTube 和播客。6

它不应该被理解成「帮你批量抓内容」的生产爬虫，更适合个人研究、选题输入和知识库沉淀。项目说明也把限制写清楚：遵守服务条款、robots.txt 和法律法规，控制请求频率，不用于商用爬取、二次分发或侵权场景。6

两个实验仓：能给思路，但别直接压生产

Amplipost 和 social_media_pubulish_MCP 都值得看，但更像流程样板。

Amplipost 的方向很完整：一句话触发，多 Agent 判断内容类型，再分发到闲鱼、小红书、B 站专栏、抖音图文；它还把 Playwright、Scrapling、小红书 MCP 安装脚本放进初始化链路。7 但仓库目前只有 34 stars、21 次提交，建议先拆它的架构和提示词，不要把它当稳定平台。7

social_media_pubulish_MCP 更小，边界也更清楚：用 MCP + Playwright 操作可见浏览器，小红书支持创建图文草稿，抖音支持上传后设为仅自己可见再发布，并保留验证码续提交流程。8 它强调不生成内容、不绕过验证码、不逆向私有接口、不保存账号密码；这正是国内平台发布自动化该守住的底线。8

本周建议：把工具按链路装，而不是按热度装

如果只能先试 3 个，建议按链路选：

海外社媒发布：先试 PostEverywhere CLI，看 --json 输出能否被你的 Agent 正确解析。
国内多平台发布：先试 social-auto-upload，只验证抖音 / Bilibili / 小红书 / 快手里最关键的 1-2 个平台。
小红书或 B 站素材输入：在 xhs-mcp-server 和 media-crawler-mcp-service 之间二选一；前者轻，后者更像长期数据服务。

不要一开始就追求全自动发全平台。更稳的路线是先让 Agent 完成「生成 → 草稿 → 人工确认 → 发布 → 回传状态」五步闭环；当每一步都有日志、失败分支和频控，再逐步放开自动发布。

AI Agent 运营工具周报：从发布 CLI 到中文内容采集，8 个入口值得试