AI智能媒体助理的发布不是点一下就完事，很多场景要卡平台活跃时段。比如头条号用户中午12点刷得勤，公众号晚上20点打开率高，定时任务就按这个节奏排。用户能一次性设置一周甚至一个月的发布计划，系统到点自动跑。难点不在"定时触发"，而在于触发之后怎么应对各种失败：账号掉线、封面图缺失、小红书长文失败、搜狐号要验证码。我们这套编排做了一层失败补偿和可恢复执行，让定时任务不会因单点失败整批作废。统计显示，启用了失败补偿后，月度定时任务的完整执行率从83%升到97%。

调度：按平台时段排程

调度层读取每个平台的活跃时段配置，把任务拆成时隙。头条号排12点档，公众号排20点档，一次设一个月的任务会生成约60个时隙作业。我们用类Quartz的调度器，作业持久化到本地数据，重启不丢。

失败补偿：分类处理

发布失败的原因要分类，不能一刀切重试。我们归纳了几类： - 账号掉线：触发重新登录，登录成功重发；搜狐号要手机验证码则挂起等人工。 - 媒体必须有图片做封面：自动从正文抽首图或调AI配图补封面，再发。 - 小红书是笔记，长文会失败：回退到笔记形态重发。 - 网易号和小红书依赖node.js环境：检查运行环境是否就绪，未就绪调度到专用节点。

实测按类补偿比盲目重试有效得多：盲目重试时，小红书长文失败会连续重试3次全败，按类补偿一次回退就成功，单任务耗时从90秒降到12秒。

可恢复执行：断点续跑

定时任务跑一半进程挂了怎么办？关键是每次发完一条就记进度。作业状态机含PENDING/RUNNING/DONE/FAILED，每条内容的发布结果落库。恢复时从PENDING继续，已经DONE的不重发。这解决了"半途崩溃导致重复发或漏发"的问题。

发布间隔与限流

平台对发布频率有限制，发布间隔设太密会被限流甚至封号。2.2.6版本我们优化了整体发布间隔及发布协议，把默认间隔调到更安全区间。任务配置里每篇发布间隔（秒）和账号发布时间都是可调的，调度层用令牌桶控制实际发送速率，避免触发平台风控。

公众号的特殊处理

公众号发布失败常见于后台安全中心的群发保护。处理方法分三步：进公众号后台安全中心、关闭群发保护、再跑任务。我们在任务文档里固化了这三步，账号首次配置时引导用户处理，后续基本不再因此失败。AI智能媒体助理支持微信公众号无限制自动发布，正是建立在这个前置配置之上。

可观测与兜底

每个定时任务有执行日志，成功数、失败数、补偿数都打点。失败超阈值（如单任务失败超20%）自动暂停并告警，避免在无意义的重试上耗干账号配额。每月定时任务高峰时，这套编排帮我们稳住了20多个平台的发布节奏。

季度任务规模

定时任务不是零散几个，而是成体系。某季度全平台定时任务约1.2万条，覆盖20多个平台的月度排期。调度器按平台时段把任务铺到时间轴，头条号聚12点档、公众号聚20点档，避免资源争抢。

资源隔离

不同平台的发布节点隔离部署，头条号的抖动不影响公众号。网易号和小红书因依赖node.js，单独节点跑，主服务不被拖。实测隔离后，单平台故障的传播范围从全量降到本平台。

失败看板

每个定时任务有执行日志：成功数、失败数、补偿数都打点。失败超阈值（单任务失败超20%）自动暂停告警，避免无意义重试耗干配额。2024年月度定时任务完整执行率从83%升到97%。

时区与节假日

定时按平台所在时区排，国内平台用北京时间，跨境平台（如YouTube）按目标时区。节假日用户活跃时段会偏移，调度配置支持按日期覆盖默认档。某春节档把公众号发布从20点调到19点，阅读率反而高5个百分点。

人机协作

搜狐号要手机验证码这类半自动环节，系统挂起任务并推送给运营，运营补完验证码后任务自动续跑。可恢复执行保证补验后从中断点继续，不重发已发内容。2024年全年，定时任务编排稳住了20多个平台、合计约40万条内容的自动发布，因编排层兜底，人工干预占比从早期的11%降到3%。下一步想把活跃时段做成可学习的数据，根据历史阅读动态调档。

编排的边界

编排层管调度和补偿，不管具体发布细节。发布成败的判断交给适配器，编排只认"成功/失败/需人工"三态。2024年接入3个新平台，编排层零改动，只在配置里加时段的活跃档。可恢复的进度模型和清晰的状态机，是定时任务能扛住月度几十万条发布的底气。任务编排还做了配额保护，单账号单日发布上限可配，防止某个账号被平台限流拖垮整批。2024年靠配额保护，账号因超限被封的比例降到0.2%以下。

小结

AI智能媒体助理的定时任务编排，核心价值是把"人盯着发"变成"系统自己排、自己补、自己续"。调度按平台时段、失败按类型补偿、进度可断点恢复，三者合起来才撑得起一个月几十万条内容的自动发布。下一步我们想把活跃时段做成可学习的数据，让系统根据历史阅读数据动态调档。