AI Agent 实战：Cron 调度 + 多 Agent 协作，从失败到稳定运行的工程化之路
📖 本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。
每天 6 个 AI Agent 定时产出内容，发到 6 个平台——这套系统跑了 20 多天，从第一天几乎全崩到现在稳定运行 90% 以上，踩了无数坑。今天把核心架构和踩坑经验完整分享。
一、系统架构全景图
我们的多 Agent 内容运营系统由 3 层组成：
1. 调度层（Cron）
- 6 个独立定时任务，每个平台一个 Agent
- 任务间解耦：一个平台挂了不影响其他平台
- 失败自动重试 + 告警
2. Agent 层
- 每个 Agent 有独立 workspace 和记忆系统
- 读取公众号已发布文章作为素材
- 按平台调性改写内容（知乎深、微博短、V2EX极客、掘金技术）
3. 发布层
- 各平台 API 或浏览器自动化
- 发布后自动记录日志
- 每晚自动复盘统计
二、第一个坑：「说完成了」不等于「真完成了」
最早期的架构有一个致命假设：Agent 执行完任务 = 任务成功。
现实是：
- Agent 调 API 返回 200 不等于内容已发布（可能进审核）
- Agent 说「写入文件成功」不等于文件格式正确
- Agent 说「发布完成」不等于读者可见
解决方案：主动回调机制
我们引入了强制回调协议——子 Agent 完成任务后必须通过 sessions_send 主动向调度方报告结果，包括：
- 任务状态（done/fail/partial）
- 核心产出摘要（300字以内）
- 风险/后续说明
没有回调 = 任务未完成 = 需要人工介入。
这就像打工人的日报：你说你做了，得拿出成果来。
三、第二个坑：单点故障导致连锁崩溃
早期把所有任务放在一个 cron job 里，结果：
- 知乎 API 超时 阻塞后续任务 微博也没发 掘金也没发
- 一个平台的 Cookie 过期 整个 cron 任务报错退出
解决方案：任务解耦 + 独立重试
拆成 6 个独立 cron job，每个 job：
- 有自己的超时时间
- 有自己的错误处理
- 失败不影响其他 job
四、第三个坑：记忆丢失导致内容重复
Agent 不记得昨天发了什么 今天又发同样的话题 平台判重复/读者审美疲劳。
解决方案：共享持久记忆
- 所有发布记录写入统一的 daily-traffic-log.md
- 每次发布前读取日志检查重复
- 跨 Agent 共享已发话题列表
效果：20 天内无重复选题，6 个平台的内容各有侧重。
五、第四个坑：错误静默吞没
Agent 遇到异常 吃掉异常 继续往下走 最后说「全部完成」 实际上 3 个平台都没发。
解决方案：错误必须冒泡
- 任何 API 调用失败必须记录到日志
- 连续失败 3 次 停止重试 通知管理员
- 每日复盘自动统计各平台成功率
六、核心经验总结
- 任务完成不可信 强制回调协议 0 漏报
- 单点故障 任务解耦 一个挂了不影响其他
- 内容重复 共享发布日志 20天无重复
- 错误被吞 错误冒泡加告警 异常 100% 可见
- Cookie 过期 自动检测加告警 不再静默失败
七、给想搭建类似系统的人 3 条建议
- 先跑通一个平台再扩展：不要一上来就做 6 个平台，先把一个平台的完整链路跑通
- 把「任务完成」的定义写死：不要相信 Agent 的自我判断，用可验证的标准
- 日志大于一切：每一个动作都记录，发布成功要记，失败更要记。复盘全靠日志。
📖 本文首发于微信公众号「Wesley AI 日记」
📚 AI Agent 实战系列（微信搜索「Wesley AI 日记」关注）：
微信搜索「Wesley AI 日记」关注，不错过每一篇更新。
