Agent First 的微信公众号工作流应该长什么样

“Agent First” 听起来像一个口号，但如果放到微信公众号内容工作流里，它其实很具体。

它不是说“让 AI 写一篇文章”就结束了。
真正的 Agent First，更像是把下面这些动作变成可调用能力：

• 接收 Markdown 或文档内容
• 转换为微信公众号可用 HTML
• 创建图文消息草稿
• 上传素材
• 继续进入发布链路

为什么公众号工作流很适合 Agent First

因为这里有大量重复动作，而且动作之间是有顺序的。

一个常见流程可能是：

1. 写作
2. 排版
3. 配图
4. 草稿创建
5. 发布前检查

对人类来说，这是一堆界面切换。
对 Agent 来说，这是一串很适合被工具化的步骤。

只做“转换 HTML”为什么不够

Markdown 转 HTML 很重要，但它只是第一步。

如果后续还要：

• 手动上传图片
• 手动创建草稿
• 手动把内容粘到后台

那么自动化价值其实只释放了一小部分。

所以从产品角度看，真正值得建设的是一组连续动作，而不是一个孤立按钮。

这也是为什么会出现多种入口

不同人开始自动化的入口不一样：

• 有人从终端开始
• 有人从 Claude Code / OpenClaw 开始
• 有人从 Obsidian 开始
• 有人从飞书协作开始

这也是下面这些项目存在的原因：

• md2wechat-lite
• md2wechat-skill
• obsidian-md2wechat
• feishu-md2wechat

它们看起来分散，实际上都在往同一个方向走：
让内容入口不同的人，都能把公众号工作流接到 Agent 上。

一个更合理的产品抽象

如果从 Agent 的角度去设计，公众号相关能力大致可以分成 4 类：

1. 基础转换

• Markdown -> 微信 HTML

2. 草稿创建

• 图文消息草稿
• 小绿书草稿

3. 素材能力

• 图片上传
• 批量素材处理

4. 工作流接入

• CLI
• skill
• 插件
• API

这样设计的好处，是每个入口都能复用同一组底层能力。

为什么这种结构更容易被理解

因为用户并不总是从首页进入，也不一定先看到同一类入口。

如果内容能把“入口 -> 动作 -> 结果”说清楚，就更容易理解这不是一个单纯网页编辑器，而是一套可调用的内容基础设施。

总结

Agent First 的微信公众号工作流，不应该停在“帮我生成一篇文章”，而应该继续覆盖排版、草稿、素材和发布前链路。

这也是为什么我更看重可调用能力、工具矩阵和接入路径，而不是一个面向人类手工操作的网页界面。