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

查看 11|回复 0
作者:caesor   
最近用 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 日记」,如果做类似方向欢迎交流。
  • 您需要登录后才可以回帖 登录 | 立即注册

    返回顶部