一、全景图：九个动作排成一条线

① 人在表里写一行：选题＋关键词＋风格
                  │
                  ▼
② RPA 读出【待创作】的行 ──► ③ 调用 Agent（提交选题）
                                      │
                                      ▼
                          ④ Agent 生成：标题／正文／标签／配图提示词
                                      │
                                      ▼
                          ⑤ Agent 按提示词生成封面图（3:4）
                                      │
                  ┌───────────────────┘
                  ▼
⑥ RPA 取回结果写回表＋把图片下载到本地
                  │
                  ▼
⑦ 【人】审：改终稿、挑封面、查违禁词   ◄── 第一个把关点
                  │
                  ▼
⑧ RPA 打开创作页：填标题／正文／标签／传图
                  │
                  ▼
⑨ 【人】点【发布】─► RPA 记录笔记链接     ◄── 第二个把关点

这张图上有三个东西值得单独指出来：

1. 起点和终点都是人——第 ① 步是人写选题，最后一步是人点发布；
2. 中间全在机器手里——② 到 ⑥ 与 ⑧ 一次不用你干预；
3. 两个把关点之间隔着一次【人工审阅】——这不是不信任机器，而是质量与合规的最后一道闸。

二、七个节点的【输入／输出／责任方】

三、三个设计原则

原则一：表格当【交接台】

Agent 和 RPA 不直接对话，全部通过这张表交接。

为什么？因为表是可见、可查、可重跑的：

反例：让 RPA 直接调 Agent、Agent 直接触发 RPA——中间的请求与响应藏在两个平台的日志里，出错时你既看不见，也没法只重跑一条。

原则二：每个节点都能【单独重跑】

要做到这一点，靠的是两个设计：

1. 状态字段——每行标着它现在在哪一步（下一节详述）；
2. 每个节点只做一件事、并且做完就落盘——比如 N3 生成完立刻把结果写进表，不要攒在内存里等 N5 一起写。因为一旦中途出错，攒着的数据会全丢。

一条实用判据：如果某个节点失败后，你能从它的输入重新执行它、而不需要重跑前面所有节点，这个流程就算合格。

原则三：人在两个关键点把关

四、数据格式约定：把字段定下来

流程设计最容易忽略、也最容易返工的，就是这一步。 先把表的列定死，后面 Agent 和 RPA 才有共同语言：

五、状态机：一个字段管住整条流水线

状态字段是这条流水线的方向盘。 每一行只能处于一个状态，状态的转移就是流程的推进：

待创作 ──► 生成中 ──► 待审 ──► 待配图 ──► 待发布 ──► 已发布 ──► 已归档
   ▲          │          │                                    │
   │          ▼          ▼                                    │
   └──── 异常 ◄──────────┘  ◄──────────────────────────────────┘
        （重试或人工修）

六、⚠️ 2026 现状：为什么这套设计不做【全自动】

结论：本案例的流程不是【人能少干就少干】，而是【把搬运交给机器、把判断留给人】。这条线画在【发布按钮之前】，方案才长期可用。

七、动手 Demo：画出你自己的流程框图

准备：纸笔，或者任何画图工具（不用软件也能做，方框加箭头就行）。

第一步——列动作：把你要自动化的那件事，拆成 4 到 8 个动作，每个动作写成【动词 ＋ 对象】，例如【读表格】【调 Agent】【写回结果】。

第二步——标责任方：每个方框右上角标一个字母——人／A（Agent）／R（RPA）。

第三步——标交接物：每根箭头上写清【传的是什么】——一个字段、一个文件、还是整行数据。

第四步——圈出把关点：在【机器做完、对外动作之前】的位置画一个三角形，写上【人】。至少一个，最多三个。

┌──────────┐   选题+关键词   ┌──────────┐
│ ① 人写选题 │ ─────────────► │ ② RPA 提交 │
│    [人]   │                │    [R]    │
└──────────┘                └────┬─────┘
                                 │
                            ┌────▼─────┐
                            │ ③ Agent   │
                            │   [A]     │
                            └────┬─────┘
                                 │
                            ┌────▼─────┐
                            │ ▲ 人审     │
                            │ [人]      │
                            └──────────┘

看到什么算成功：

1. 每个箭头上都写得出【传的是什么】——写不出来的那根箭头，说明相邻两步之间还没想清接口，这就是以后最可能出 bug 的地方；
2. 人出现在【两个】位置，而且都在关键决策处——如果人出现在 5 个位置，说明自动化程度太低；如果人一次都不出现，说明这个方案会出事；
3. 图上的每个方框都只有一件事——出现【先读表再写文案再传图】这种多功能框，回去拆开。

读结果：这张图就是你的施工图。下一节开始，2.3 造 Agent、2.4 造 RPA，都是照着图上的方框填内容——图错了，代码写得再漂亮也白搭。

30 秒实验

看第 2.1.1 节的工时表，找到你花时间最多的那一个环节——它在本节的流程图上是第几号方框？

• 是 ①、⑦、⑨ 里的一个——恭喜，你时间最多的地方正是【只有你能做】的地方，自动化帮不上忙，该优化的是别处；
• 是 ② 到 ⑥、⑧ 里的一个——那就对了，这正是本课要替你省掉的部分。

结论：人最贵的三个位置（选题、审核、发布）通常只占流程图的三分之一，但它们是账号的命；省时间要从中间那一段省，而不是把人该做的事也交出去。

常见误区

1. 【先动手做，边做边想流程】——错。 流程错了要推倒重来的是【Agent 的输出格式 ＋ RPA 的解析逻辑 ＋ 表格的列】三处。这一节的纸面功夫，是最便宜的投入。
2. 【让 Agent 直接触发 RPA，省掉中间的表格】——错。 中间态进了黑盒：看不见、不能单行重跑、人也没法插手改。
3. 【字段先少定几个，不够再加】——错。 加列比留空列贵得多（牵三处），宁可先多留两列空着。
4. 【状态字段可有可无】——错。 没有状态字段，RPA 无法知道【哪一行该处理】，也无法知道【哪一行悬在半空】。它是流程的方向盘。
5. 【把关点放一个就够了】——错。 至少要两个：一个管内容质量（发布前审稿），一个管对外动作（点发布）。二者管的东西不一样，合成一个就会漏。

• ☐ 下一节（2.3.1 Agent图文整合工作流）

相关笔记

• 小红书运营助手实战案例 —— 三件交付物与七步分工表的出处
• RPA 的核心能力 —— 幂等与异常处理，本节的【生成中】状态就是它的落地
• RPA与Agent交互 —— 三种交互模式，本案例用的是【RPA 调 Agent】
• 🤖 Agent+RPA实战 · 索引 —— 全课路线图