用 Python 把「流水线 Agent」从即兴发挥，收敛成可复用的工具

type

Post

status

Published

date

Apr 16, 2026

slug

summary

我们把内容流水线里重复、机械的操作（读草稿、调平台 API、更新发布状态、多平台一致性判断等）从「全靠 Agent 在对话里完成」收敛成 Python CLI 脚本：Agent 负责理解与成稿，脚本负责规则与副作用。这样减少了无效检索与拼 JSON 的 Token 消耗，也避免了单平台成功就误标「已发布」、以及临时脚本硬编码密钥等问题。Notion / 微博 / Moltbook 等发布路径统一走「正文进文件 → 一条命令发布 → 自动更新状态」；Moltbook 复用现有 API 封装并注意发帖间隔；Cron 与文档与脚本行为对齐。核心收获：确定性进代码，创造性留给模型。

我们解决了什么问题

1. 状态与「过早标记已发布」

多平台发布时，很容易出现：某一端成功了，就把整条素材标成「已发布」，而实际上其他端还没发完。

做法是引入统一的状态更新脚本：按「分发目标」逐平台记录成功/失败，只有所有目标都成功，才把整条内容推到终态。这样逻辑集中在一处，Agent 不必每次复述规则。

2. 发布逻辑从「批处理脚本」变成「CLI 工具」

以 Notion 为例，曾经出现过「脚本自己扫目录、自己拼内容」的批处理形态——和「先由 Agent 写好再发布」的职责混在一起，也容易长出一次性脚本、硬编码密钥或正文的坏味道。

现在的形态更接近微博那套：Agent 把正文写成文件（例如 Markdown），再调用一个带参数的发布命令。脚本负责：读文件、调平台、失败时写清原因、成功后更新流水线状态。不把业务正文写死在仓库里的 Python 里。

3. 密钥与配置：少搜、少猜、少浪费 Token

之前 Agent 会为了找「Notion Key 在哪」反复检索，纯烧 Token。

现在约定：脚本从固定、文档化的位置读密钥（与官方 Skill 一致），Agent 文档里写清楚「不要自己去翻一堆配置文件」。省下来的不只是调用次数，更是对话里的无效探索。

4. 封面等「可自动化」的增强

Notion 需要封面时，如果每次都让 Agent 去搜图、找 API，成本很高。

把「按标题/标签选一张风格合适的图」放进发布脚本里，失败时降级为无封面继续发，不阻断主流程。

5. 网络不稳时的务实处理

外部 API（例如图片服务）有时会超时。做法是：适当拉长超时、在 curl/子进程层给足余量，并允许「拿不到图就跳过」，避免一次封面请求拖死整次发布。

6. 新平台：Moltbook

Moltbook 侧我们不重复实现 HTTP 客户端：项目里已有完整的 moltbook.py（封装官方 API）。发布脚本只做「读正文 → 调已有客户端发帖 → 更新流水线状态」。

另外，官方对发帖频率有限制，我们在文档和 Cron 提示里写明：多篇连续发布时要留出间隔（例如在两次发帖之间等待数分钟），避免触发限流。

7. Cron 提示词也要跟着架构变

定时任务里如果还写着「手动调状态更新」「从过时路径读 Key」，Agent 会照做，反而破坏统一方案。

我们把 Cron 文案改成：读哪些规范文件、筛哪些 draft、如何用发布脚本、何时收尾清理——与当前脚本行为一致，减少歧义。

设计原则（可复用到别的流水线）

脚本管副作用，模型管语义：创建记录、改状态、调 API，尽量不进对话长文本。

CLI 优于批处理：输入是文件 + 元数据路径 + 业务 ID，输出是退出码 + 简短日志。

单一事实来源：状态怎么迁、何时算「全平台完成」，只在一处实现。

安全默认：禁止在仓库里塞密钥和整篇正文；一次性脚本该删就删。

可观测：失败要写清原因（含退出码、错误摘要），方便人和后续自动化处理。

小结

这次不是「多写了几个脚本」这么简单，而是把流水线里的确定性从模型侧挪到代码侧：Token 花在审稿和表达上，而不是花在重复查文档、拼 JSON、猜路径上。

如果你也在搭多 Agent 内容系统，可以问自己一句：这件事有没有固定规则？有的话，就该进脚本。