AI Agent 运营工具周报：从排版到草稿箱，6 个长文分发入口值得试 (2026)

把一篇写好的长文从 Markdown 变成能在公众号、知乎、掘金上正常发出去的成品，中间有四件事要做：把 Markdown 排成各平台能接住的富文本、把正文图片和封面送进平台素材库、拿到对应平台的发布凭据、再让文字读起来不像模型写的。这四件事各自长出了一批工具，而它们的发布机制差别很大，直接决定 Agent 能看到什么、能改什么、发出去之后还能不能收回来。

本期挑出的 6 个入口分布在这条链路的四层上。判断先装哪一个，最省事的办法是先看发布机制：稿子是从本机复制粘贴出去的，还是通过平台官方接口直推草稿箱的，还是靠浏览器里已经登录好的账号发出去的。机制定了，凭据怎么存、权限怎么撤、失败后怎么重试才有答案。

先按发布机制分层，再挑工具

下表的字段在每条里保持一致，最后两列是选型时最先要看的部分。「成熟度」一列的 star 数与提交数取自 2026 年 9 月 21 日打开仓库时的页面快照，只反映当时的状态。

工具	一句话定位	Agent 接入形态	发布机制与凭据	硬边界与成熟度快照
doocs/md	微信 Markdown 编辑器，把 Markdown 即时渲染成微信图文	在线编辑器、`@doocs/md-cli`、Docker 镜像	不接触账号：渲染完由人复制粘贴进公众号后台	凭据零暴露，也无法自动发文；13.4k star、1660 次提交 1 2
文颜 wenyan-mcp	让 AI 客户端把 Markdown 排版后直接发进微信公众号草稿箱	MCP Server（本地 stdio / 远程 Server）、Docker、`wenyan-cli`	走公众号官方接口，用 AppID + AppSecret，机器 IP 需进白名单	产出是草稿，不是已发布文章；1.3k star、66 次提交 3 4
Wechatsync 文章同步助手	一次排版，把文章同步到 29+ 个内容平台	Chrome 扩展 + `@wechatsync/cli` + MCP Server + Claude Code Skill	复用浏览器里已有的登录态，调用各平台官方 Web API，默认存草稿	数据不过第三方服务器，扩展必须开在本机；6.3k star、306 次提交 5
juejin-release-mcp	掘金单平台 MCP：草稿、发布、更新、删除、分类标签一条链管完	MCP Server（`uvx` 或 pip 安装）	走掘金创作者接口，用 `sessionid` Cookie	`publish_article` 一步创建草稿并直接发布；0 star、7 次提交，实验状态 6 7
humanizer	发布前把 AI 味文字改回人写的，同时保住原文事实	Agent Skill（纯 Markdown）	只处理文字，平台账号不参与这一步	改完仍需人工复核事实；50.6k star、4.1k fork、75 次提交 8
DearAgent	给每个 Agent 一个自己的邮箱收件箱	REST API + MCP Server（`/mcp`）+ Agent Skill	自托管在自己的 Cloudflare 账号，单租户单 API Key	需要自备域名与 Workers；作者标注实验状态；27 star、16 次提交 9

排版层：doocs/md 把 Markdown 变成公众号吃得下的图文

公众号后台的编辑器只认富文本，模型输出的 Markdown 直接粘进去会丢掉标题层级、代码块和公式。doocs/md 解决的是这一层：把 Markdown 即时渲染成微信图文，渲染结果复制进后台就能保住样式 1。

它支持 KaTeX 数学公式、Mermaid 图表、PlantUML 和 GitHub 的警告块语法，代码块可以换高亮主题，也能整体替换自定义 CSS 1。图片上传配了多种图床，包括 GitHub、阿里云 OSS、腾讯云 COS、七牛云、MinIO、S3 兼容存储、Cloudflare R2，以及直接用公众号本身当图床 1。编辑器里还挂了 DeepSeek、OpenAI、通义千问、腾讯混元、火山方舟等模型做辅助写作 1。

对 Agent 来说更实用的是它的命令行形态。@doocs/md-cli 可以在脚本里跑渲染，Docker 镜像 doocs/md 则让这件事进容器，不需要每人装一套 Node 环境 1 2。

典型使用场景：Agent 写完稿子，团队用 CLI 或容器渲染出公众号版式，人工粘贴发出。图片可以先存进自己的对象存储，不经过第三方图床。
安装与入口：在线编辑器在 md.doocs.org，命令行版本是 npm 上的 @doocs/md-cli，容器镜像发布在 Docker Hub 的 doocs/md 1。
硬边界：这一步从头到尾不接触你的账号，也正因为如此，它到复制粘贴为止，不会帮你把文章发出去。适合把「排版」和「发布」拆开、让 Agent 只做前一半的团队。

官方接口直推：文颜把稿子送进草稿箱

如果希望 Agent 一路走到草稿箱，文颜（Wenyan）是这条链路上装得最完整的一套。它的 MCP 版本 wenyan-mcp 让 Claude Desktop 之类的客户端直接调用排版引擎：Markdown 转成微信富文本、自动上传文内图片与封面、按主题渲染，最后创建公众号草稿 3。

文颜提供的不止 MCP 一种形态。macOS 有 App Store 版本，Windows 与 Linux 有跨平台桌面版，命令行版本 wenyan-cli 面向 CI 自动化发布 3。文章需要在 Markdown 顶部写一段 frontmatter，title 必填，cover、author、source_url 选填；把 type 设为 image 并给一组图片路径，发出去的就是公众号的图片消息，也就是常说的小绿书，图片最多 20 张 3。

真正需要提前想清楚的是凭据和网络这两件事。文颜要求启动时配置 WECHAT_APP_ID 与 WECHAT_APP_SECRET，并且运行机器的 IP 必须加进公众号后台的白名单，否则上传接口直接调用失败 3。项目为此提供了一套远程客户端模式：本机的 MCP 只当客户端，把发布请求发到部署在云服务器上的文颜 Server，由服务器去调公众号接口，这样本机没有固定 IP 也能用 3。多个公众号一起发也只有 Server 模式才支持 3。

典型使用场景：公众号运营把「选题 → 写稿 → 调排版 → 存草稿」压进同一个对话窗口，Agent 存完草稿后由人登录后台确认再发。
安装与接入：npm install -g @wenyan-md/mcp，在客户端配置里写入 WECHAT_APP_ID 与 WECHAT_APP_SECRET；不想装 Node 可以直接 docker pull caol64/wenyan-mcp:latest 3 10。
硬边界：项目采用 Apache-2.0 协议，产出停在草稿箱，正式发布仍需人在后台点一次 3。AppSecret 相当于账号的一把长期钥匙，放进 MCP 配置就等于放进任何能读到该配置的进程，团队多人共用一台发布机时要先确定谁能读。

本机登录态复用：Wechatsync 一次排版同步到 29 个平台

公众号发完，同一篇文章通常还要去知乎、掘金、头条、CSDN 各发一遍，每个平台的编辑器对格式的容忍度都不一样。Wechatsync（中文名「文章同步助手」）把这一步做成了一个 Chrome 扩展，支持同步到 29 个以上平台，包括微信公众号、知乎、微博、小红书、掘金、CSDN、简书、头条号、B 站专栏、百家号、语雀、豆瓣、搜狐号、雪球、51CTO、慕课网、开源中国、SegmentFault、博客园、什么值得买、网易号，海外平台里的 X，以及 WordPress、Typecho 等自建站 5。

它的工作方式值得单独说一句。扩展直接用你浏览器里已有的 Cookie，调用各平台 Web 编辑器本身使用的那套官方接口，请求从本机浏览器直接发往平台，中间没有第三方服务器，默认把文章存成草稿 5。这条设计回答了「Agent 拿什么身份发」这个问题：它借的是你自己的登录态。

Agent 侧有三种接法。命令行最轻，npm install -g @wechatsync/cli 之后先 wechatsync platforms --auth 看哪些平台还登录着，再用 wechatsync sync article.md -p zhihu,juejin,csdn 指定平台同步 5。Claude Code 用户可以直接装 Skill：/plugin marketplace add wechatsync 加 /plugin install wechatsync 5。要走 MCP 的话，先在扩展设置里打开「MCP 连接」并设一个 Token，再把这个 Token 填进 MCP 配置，可用工具包括 list_platforms、check_auth、sync_article、extract_article 和 upload_image_file 5。

典型使用场景：技术博客写完，一次同步到掘金、CSDN、SegmentFault 和知乎；或者把公众号已发的文章补发到头条号与百家号。
安装与接入：从 Chrome 网上应用店安装扩展，或下载 Release 手动加载，支持 Chrome、Edge、360、QQ 等 Chromium 内核浏览器 5。
硬边界：项目采用 GPL-3.0 协议，最新版本 v2.0.9 发布于 2026 年 3 月 24 日 5。它的发布能力绑定在一台开着浏览器、登录着账号的机器上，做不了无人值守的服务器端定时发布；扩展所在的浏览器也就等于拿到了所有已登录平台的发布权，装它的机器要按发布机来管。

单平台直连：juejin-release-mcp 与不做草稿的取舍

上述工具都默认把结果停在草稿。juejin-release-mcp 走的是另一条路：它把掘金创作者接口封成 MCP，提供 create_draft、update_draft、delete_draft、list_drafts 管草稿，get_article、list_articles、update_article、delete_article 管已发布文章，list_categories 与 list_tags 取分类标签，get_user_info 读当前登录账号 6。其中 publish_article 会连着做两步：先创建草稿，再直接发布，一次调用就上线 6。

安装很轻，uvx juejin-release-mcp 即可运行，也可以 pip 安装，配置里给一个 JUEJIN_COOKIE=sessionid=... 环境变量就够；项目声明 Cookie 只存在本地，不上传第三方 6。仓库采用 MIT 协议，Python 版本要求 3.10 以上，PyPI 包名为 juejin-release-mcp 6 7。

典型使用场景：技术团队把内部周报、版本说明类的固定栏目交给 Agent 直发掘金，或者先 create_draft 存草稿、人工看完再让 Agent 发布。
硬边界：这个仓库在 2026 年 9 月 21 日观察时是 0 star、7 次提交、版本号 0.1.1，属于实验阶段的项目，不适合直接压到生产上 6。publish_article 跳过人工确认这一点要靠纪律补回来：调用它的 Agent 提示词里最好只允许走 create_draft，把发布权限留在人手上。sessionid 是账号登录凭据，放进环境变量就意味着同一台机器上任何能读环境变量的进程都能拿到。

发布前终检：humanizer 检查的是文字像不像人写的

把模型生成的文章直接发出去，读者通常能一眼看出痕迹。humanizer 是一个纯 Markdown 的 Agent Skill，专门在发布前做这一道检查：它按 25 类模式扫描文本，把 AI 腔调改掉，同时保持原文说的是什么不变 8。

这 25 类模式分成五组：用铺垫代替陈述（比如「不只是 X，而是 Y」这类句式、每节结尾的一句总结、听起来深刻的格言）、按规则生成的节奏（三件套排比、重复的句子开头、破折号当万能连接符）、夸大与借来的权威（抬高意义、含糊的关联表述、销售式措辞、用「专家认为」撑场）、按规则生成的排版（加粗当装饰、带 emoji 的标题），以及从对话和草稿里留下的残留（「好问题！」「希望这有帮助」、说明知识范围的话、标题在正文第一句又重复一遍） 8。这份模式清单的出处是维基百科的「Signs of AI writing」条目 11。

它的工作纪律也写明白了：先标出找到的痕迹，按明显程度排序，再起草改写稿，回头拿模式和原文事实核对一遍，最后出终稿。名字、数字、日期、引文这类事实必须来自原文或作者，遇到缺的细节它会先来问你 8。指向一个文件时，它只改散文部分，代码、数据、frontmatter 和链接地址都保持原样 8。

典型使用场景：Agent 出稿后、进排版和发布之前，把 Markdown 交给它过一遍；想更像自己的语气，可以顺手贴两三段自己以前写的文字让它对齐节奏和用词 8。
安装与接入：npx skills add blader/humanizer --global，之后用 /humanizer 调用；Claude Code 2.1.142 及以上版本也可以走插件市场安装，Claude Desktop 则把这个仓库下载成 ZIP 作为 Skill 上传 8。
硬边界：它处理的是文字读起来像不像人写的，事实准确性和平台规则都不在它的检查范围内。改完之后仍然需要有人核对事实，也需要单独做合规与敏感词检查。

账号身份：DearAgent 给 Agent 一个自己的邮箱

前面几层都建立在「账号已经存在、也登录好了」这个前提上。有些流程走不到这一步：Agent 要去的服务需要填邮箱收验证码，用运营人员的个人邮箱会把私人收件箱和自动化流量混在一起。DearAgent 处理的就是这一段，它给每个 Agent 一个独立的收件箱，整套跑在自己的 Cloudflare 账号里 9。

部署形态是一个 Cloudflare Worker，用 D1 存邮件、R2 存附件，入站邮件经 Email Routing 进入 Worker，出站走 Cloudflare 的邮件发送绑定 9。Agent 能用的接口是 REST 加一个挂在 /mcp 上的 MCP Server，其中包括 wait_for_message：调用后阻塞在那里，等验证码邮件到了再返回发件人、主题和正文 9。邮件按 In-Reply-To 分线程，主题相同的自动邮件不会被拼到一起；正文和发件人支持 SQLite FTS5 全文检索；message.received 与 message.sent 两个事件可以推 HMAC 签名的 webhook，并留投递日志 9。地址还能带过期时间，例如把地址写成带 ttl 的形式，用满一段时间后自动失效，配合 RETENTION_DAYS 做定期清理 9。

典型使用场景：Agent 注册需要邮箱验证的第三方服务，或者用独立地址接收入站询盘、退信通知，再由 webhook 触发下一步流程。
安装与接入：需要一个专用域名接入 Cloudflare Email Routing，按仓库里的 wrangler.example.jsonc 部署 Worker；官网上有一个公开演示实例，打开页面就能拿到一个十五分钟后失效的地址试发 9 12。
硬边界：仓库自己在开头就写了这是早期软件、没有经过深入安全审计、API 还可能变，指向敏感数据或接入不受信任的 Agent 之前要先自己审一遍代码 9。它是单租户设计，只有一个 API Key，多个 Agent 共用时要自己在前面加一层鉴权做隔离 9。

这套链路怎么装：从排版到草稿，再谈自动发布

这 6 个入口的权限级别差别很大，按顺序装比一次全上更稳。

第一步只做排版，装 doocs/md。这一步不碰账号，试错成本最低，团队能先看清「Markdown 进、公众号图文出」这一环是否满足自己的版式要求。

第二步把草稿自动化。公众号侧装文颜，把 Agent 的终点定在草稿箱；需要多平台分发就再装 Wechatsync，用它已有的登录态把稿子铺到知乎、掘金、头条这些平台，同样停在草稿。这两步都在「人确认」之前结束，Agent 出错的代价是一份要改的草稿。

第三步加发布前终检。humanizer 放在排版之前，因为它改的是散文，改完再排版能避免样式白调一遍。

只有在前三步稳定跑过一段时间、并且账号本身能承受误发之后，才考虑把正式发布交给 Agent。到这一步能选的只有两种机制：官方接口直连（文颜、juejin-release-mcp 这一类）和本机登录态复用（Wechatsync 这一类）。前者权限可以靠平台后台撤销 AppSecret 或重新登录一次收回来，失败有明确的状态码；后者能不能发取决于那台机器上的浏览器登录态，出了问题的第一反应是去平台里改密码。选哪一种，取决于你能接受哪一种失败。

邮箱身份这类需求可以先放在最后。DearAgent 解决的是真实存在的卡点，但它当前的状态只适合先在自己的账号里跑通流程，不适合承载生产流量。

一个本期没有覆盖的缺口：没有开放平台接口、也没有现成自动化项目的平台，Agent 仍然只能靠浏览器操作创作者后台，浏览器方案的登录态复用、验证码处理和频控要单独判断。

References

1
doocs/md 仓库
github.com
2
@doocs/md-cli
npmjs.com
3
caol64/wenyan-mcp 仓库
github.com
4
wenyan-cli
github.com
5
wechatsync/Wechatsync 仓库
github.com
6
iceycn/juejin-release-mcp 仓库
github.com
7
juejin-release-mcp 包页
pypi.org
8
blader/humanizer 仓库
github.com
9
panda-sandeep/dearagent 仓库
github.com
10
@wenyan-md/mcp 包页
npmjs.com
11
Wikipedia: Signs of AI writing
en.wikipedia.org
12
DearAgent 官网
dearagent.sh