用 AI Agent 做自动化内容发布系统，踩了一个月坑后的总结

最近用 AI Agent 搭了一套自动化内容发布系统，把这段时间踩过的坑总结一下，顺便聊聊架构上的一些思考。

背景：目标是让 AI 团队替代部分人工完成内容创作 + 多平台分发（微博、掘金、CSDN 等），每天定时自动执行。

最大的坑：Agent 说「完成了」但其实没完

这是我踩过最多次的坑。Agent 调用工具发布文章，工具返回了某个值，Agent 就宣告完成。但实际上：

• API 返回 200 但内容是错误信息（某些平台喜欢把错误包在 200 里）
• 发布成功但文章处于审核/草稿状态，外部不可见
• 文章发出去了但图片挂了

解决方案：在 Agent 的 SOUL.md 里写死规则——「任务完成」的定义必须包含可验证的外部状态（ HTTP 状态码 + 返回内容检查 + URL 可访问），不能只看工具调用是否返回。

Cookie 管理是个持续工程

各平台的 Cookie 有效期差异很大，有的几天，有的几个月。一旦 Cookie 过期，自动化流程就静默失败了。

现在的方案：每次发布前先 health check （用 Cookie 请求一个需要登录的 API 端点），health check 失败立刻通知 + 停止本次任务，把 Cookie 过期时间记录在配置里提前 3 天提醒。

多 Agent 协作的上下文传递

用文件系统而不是内存传递上下文，原因：持久化（ Agent 崩溃重启后能恢复）、可审计（出问题能看到每一步的输入输出）、多 Agent 并发时不会互相覆盖（用不同路径）。

Cron Job 的 systemEvent 要带足够上下文

Cron 触发的任务是无会话的，Agent 完全靠 prompt 里的上下文判断。这意味着 Cron 的 systemEvent text 要包含：今天的日期、任务目标、相关的资源路径、上次执行状态摘要。不能依赖「 Agent 记得上次聊了什么」，因为 Cron 每次都是全新会话。

工具失败的处理策略

不要无限重试，最多 3 次；每次重试前等待（ exponential backoff ）；失败后写明失败原因到日志，不要吞掉错误；超过重试上限后通知人工介入，不要假装成功。

目前这套系统在我自己的服务器上稳定运行了一个多月，基本实现了「每天早上醒来内容已经发完」的状态。偶尔还是需要手动处理 Cookie 过期和平台审核问题，但大部分流程已经自动化了。

更多踩坑细节和架构图记录在公众号「 Wesley AI 日记」，如果做类似方向欢迎交流。