从内容抓取到公众号草稿：我为 AI Agent 设计的一条内容创作工具链

我这两年越来越明确的一件事是：

我不是只想做一个工具，而是想为 AI Agent 搭一整条内容创作工具链。

因为内容自动化真正卡住的地方，从来都不只是“模型会不会写”，而是下面这些步骤能不能被稳定串起来：

1. 内容获取
2. 内容筛选与选题
3. 内容生成
4. 自动排版
5. 一键进入公众号草稿箱

如果这 5 步里任何一步还是手工、临时、容易断掉，那整条链路都很难称得上真正的自动化。

为什么很多 AI 内容创作流程最后都停在半路

因为很多系统只解决了其中一段。

有些工具只解决：

• AI 写作

有些工具只解决：

• Markdown 转公众号 HTML

还有一些工具只解决：

• 素材抓取

单点看都成立，但串起来就会发现中间还是有很多断层：

• 素材从哪里来
• URL 怎么读
• 选题怎么做
• 输出怎么转成公众号适配格式
• 图片和素材怎么处理
• 草稿怎么进后台

所以对我来说，真正值得做的不是一个个孤立按钮，而是一条 Agent 可以持续调用的内容工作流。

第一段：内容获取，是整个自动化链路的起点

很多人一上来就想让 Agent 直接写文章。

但如果输入来源本身是脏的、不稳定的、不适合模型处理的，那后面的写作质量大概率也不会稳定。

这一层我希望解决的是：

• 去哪里找内容
• 怎么搜索内容
• 怎么把 URL 变成可继续处理的正文
• 怎么让网页内容进入 Agent 工作流

这就是 jina-cli 的位置。

jina-cli 在链路里的职责

jina-cli 是一个面向 AI Agent 的网页阅读 CLI。

它负责：

• 搜索网页内容
• 读取网页正文
• 把 URL 转成 Markdown / Text / HTML / JSON 这类更适合模型消费的输入

如果把整个内容创作流程看成一条流水线，jina-cli 负责的就是最前面的输入层。

它不是最终内容产品，它是：

• 素材采集层
• URL 阅读层
• Agent 的网页输入层

第二段：选题与结构，不应该靠模型“凭空写”

内容拿到之后，不应该马上让模型无条件开始生成。

更稳妥的中间层应该是：

• 先归纳素材
• 再判断选题
• 再做结构设计
• 最后再进入成稿

这一层的重点不是“生成速度”，而是“编辑决策”。

我更希望 Agent 在中间做这些事：

• 哪些资料值得继续写
• 哪个角度更适合公众号读者
• 哪些来源能互相补充
• 哪些观点可以合并成一篇文章
• 这篇文章应该写成资讯稿、教程稿还是观点稿

如果没有前面的内容获取层，这一步就很容易变成：

模型凭记忆组织内容。

而一旦有了 jina-cli 这样的输入层，选题和结构就可以建立在真实网页素材上。

第三段：内容生成，是中间层，不是全部

很多人把“AI 内容工具”直接等同于“AI 写作工具”。

但我越来越觉得，写作只是中间层。

它当然重要，但真正决定流程能不能落地的，是它前后有没有被打通。

在这一层，Agent 可以完成：

• 文章大纲生成
• 选题角度提炼
• 摘要转长文
• 多来源内容融合
• 资讯稿转公众号文章

也就是说，生成不应该建立在空白输入上，而应该建立在：

• 已经读取过的内容
• 已经筛选过的主题
• 已经明确的目标平台

之上。

第四段：自动排版，是内容创作里最容易被低估的一环

很多自动化流程死在这里。

文章写出来了，但一进入公众号后台，排版全乱了：

• 标题层级不稳定
• 引用样式不统一
• 图片布局不自然
• 代码块和段落间距失真

所以我后来继续做了 md2wechat 相关工具和站点。

这一层解决的是：

• Markdown 转公众号可用 HTML
• 自动排版
• 主题和样式控制
• 更稳定地衔接真实发布环境

如果说 jina-cli 解决的是前期内容输入问题，那么 md2wechat 解决的就是后期排版问题。

你可以继续看这些相关文章：

• md2wechat-skill
• md2wechat-lite
• 微信图文自动化发布工作流应该怎么设计

第五段：进入草稿箱，才是真正接近闭环

排版不是终点。

真正更接近业务闭环的，是让 Agent 把内容推进到“待审核、待发布”的状态，而不是停在本地 Markdown 或 HTML 文件。

这就是 md2wechat Agent API 的价值。

它适合放在后期：

• 把内容转成微信适配 HTML
• 创建图文消息草稿
• 创建小绿书草稿
• 批量上传素材
• 把内容直接送进公众号草稿箱

这样整条链路就会变成：

前期

• jina-cli
• 搜索内容
• 读取网页
• 建立素材池

中期

• Agent 做选题、摘要、结构设计、成稿生成

后期

• md2wechat
• 自动排版
• 素材处理
• 推送到公众号草稿箱

这条工具链解决的，不只是“写文章”

更准确地说，它解决的是：

如何把内容创作变成一条 Agent 可以持续执行的生产线。

我希望这条链路每一层都尽量边界清晰：

• jina-cli 负责内容获取
• 写作 Agent 负责理解、筛选和生成
• md2wechat 负责排版和发布

这和“大而全平台”的思路不一样。

我更偏向做的是：

• CLI
• Skill
• API
• 可以自由组合的工具层

因为 Agent 时代更适合的是：

• 输入输出清晰的工具
• 可嵌入脚本和运行时的接口
• 可以自由串联的工作流模块

为什么我会持续做面向 Agent 的 CLI 工具集

我越来越相信，未来很多软件真正的调用者不是人，而是 Agent。

所以工具设计不应该只考虑：

• 人怎么点按钮

还应该考虑：

• Agent 怎么调命令
• Agent 怎么调用 API
• Agent 怎么把多个工具串起来

这也是为什么我会持续做围绕 Agent 的内容工具：

• 内容获取工具
• 网页阅读工具
• 排版工具
• 草稿与发布工具

它们看起来分散，但本质上都在解决同一件事：

把自动化内容创作链路里最容易断掉的几个关键环节，做成可复用的 Agent 能力。

未来我想做的，不是一篇文章，而是一套基础设施

从更长远的角度看，我希望这些项目不是零散存在，而是逐渐组成一套面向内容创作的 Agent 基础设施。

它可以服务于：

• 公众号创作者
• 技术内容团队
• AI 资讯聚合
• 垂直行业媒体
• 需要半自动发布流程的团队

今天它可能主要包括：

• jina-cli
• md2wechat
• md2wechat Agent API

未来它还可以继续扩展到：

• 选题判断
• 内容质量评估
• 风格约束
• 多平台分发
• 结果回流优化

总结

如果你真的想让 AI Agent 参与内容创作，重点不是换多少模型，而是把链路打通。

对我来说，这条链路至少包括三段：

• 前期：内容获取
• 中期：选题与内容生成
• 后期：排版与草稿发布

jina-cli 解决前期。
md2wechat 和 md2wechat Agent API 解决后期。
中间的筛选、选题、成稿，则交给 Agent 工作流去完成。

我想做的不是一个孤立工具，而是一条真正可执行的内容创作流水线。

继续阅读

• 内容获取层：geekjourneyx/jina-cli
• 排版与发布层：md2wechat Agent API
• 自动发布流程拆解：微信图文自动化发布工作流应该怎么设计