推不推、何时推？抖音、北大提出Agentic自主系统STEPS，一起RecSys 2026 Oral

核心结论：抖音与北京大学团队提出 STEPS 自触发式 Agentic 推送系统。论文获选 RecSys 2026 Industry Track 口头报告，经 14 天线上 A/B 测试验证，已全量部署于超 10 亿用户的抖音平台。 相比基线：用户活跃天数 +0.2843%，推送权限关闭率 -1.9089%。 打开手机，锁屏上躺着几条推送 —— 朋友发了新视频、关注的博主开播了、你可能感兴趣的内容更新了。 很多人以为这只是「系统想发就发」，但事实并非如此。每一条推送的背后，平台都在反复权衡两个问题：这条推送应该发吗？发多了用户直接关通知，发少了又拉不活用户；现在发，用户会点开还是会嫌烦？时机不对，不仅白白浪费资源，还可能对用户造成一次打扰。这就是 工业级推送系统的核心难题 ——「推不推」和「何时推」 。 来自抖音和北京大学的研究团队围绕这一核心问题，提出 自触发式 Agentic 推送系统 STEPS ，并发布论文《A Self-Triggered Agentic Push Recommendation System》。论文收录于第 20 届 ACM 推荐系统会议 RecSys 2026 Industry Track，获选口头报告。该方法通过线上随机 A/B 测试验证，已全量部署于拥有超 10 亿用户的抖音平台。今天我们就来拆解一下这套系统。 论文标题：A Self-Triggered Agentic Push Recommendation System 论文链接：https://arxiv.org/abs/2608.01949 传统推送系统的两种「被动」模式，都有硬伤 在传统 App 交互范式中，用户是绝对的主动发起方；而推送则是平台为数不多能「绕过主动打开」的逆向触达通道之一，但也格外难做。系统必须在连续时间轴上，考虑用户价值、负面体验来决定「推不推」 和「何时推」：发在对的时刻能把用户拉回来，发错了就换来一次权限关闭 —— 这是一个几乎不可逆的负向结果。 图 1：抖音推送通知示例 最暴力的解法，是系统每秒钟给每个用户都计算一遍推送价值。但面对十亿量级的用户池，每秒实时排序的算力成本简直是天方夜谭。为了向现实妥协，工业界演化出了两条主流的「被动」路线： 路线一：固定间隔轮询 这是一种绕过推送时机建模的方案：每隔一小段时间就唤醒系统一次，问自己「现在发不发？」思路简单，但问题很明显：如果间隔太短，大部分计算纯属浪费算力；如果间隔太长，又会完美错过用户的最佳接收窗口。系统始终在「算力开销」与「时机捕捉」之间反复拉扯。 路线二：提前排期 提前一段时间基于规则或因果建模对用户的发送条数、时机进行个性化计算，形成具体的未来排期，未来到点就发。这种方案做了用户个性化推送时机建模，但这无法感知用户当下的实时状态（如正在开会或刚打开过 App）。为了弥补实时性的不足，实际落地中通常需结合实时业务信号并结合启发式规则进行排期的动态修改（如刚活跃过的用户进行降频等）来进行动态改期。 目前业界基本沿用以上两种方案的思路或其变体，它们在支撑大规模业务上确实行之有效。但随着业务对推送系统的算力效率与用户体验提出更高要求，现有架构逐渐暴露出一个共同的底层瓶颈： 系统都是「被动执行机器」，缺乏自主决策能力 。具体表现在三个方面： 1. 时机被动 ： 被时钟或排期表驱动，不会自己思考「下一次该何时醒来」。 2. 静态链路 ： 每次被唤醒，系统都会机械地跑完昂贵的推送流水线，无法根据实时状态与推送价值灵活抉择。 3. 缺乏演进 ： 难以实现基于最终业务目标的线上用户反馈并利用强化学习进行自我迭代演进 这揭示了一个关键信号：推送系统必须从「被动响应」转变为具备自主规划、动态分支和自我演进能力的系统。 STEPS 的核心思路： 让系统「自己叫醒自己」 STEPS 全称为 Self-Triggered End-to-end Agentic Push System，中文可以理解为「自触发端到端推送智能体系统」。 它做了一件根本性的事： 把推送重新定义为一个「自触发闭环决策问题」 。 什么意思？传统推送系统是「别人叫我，我才按照固定流程做事」；STEPS 是「我自己决定本次做事流程，也自己决定下一次什么时候再做事」。系统不仅决定 「发不发」、「用多少资源」，还决定「我下一次什么时候醒过来做决策」。 整个系统由三个智能体协作，形成如下的完整闭环： 图 2：STEPS 自触发式端到端推送决策框架 三个智能体各有分工： 规划智能体（Planning Agent） ：负责「什么时候醒」，预测下一次最佳推送时间间隔 执行智能体（Execution Agent） ：负责「醒了之后发不发」，到点后评估实时上下文做二元决策 过滤智能体（Filtering Agent） ：实现「动态分支」，根据推送价值决策是否进入昂贵的执行环节。此外也能防止规划智能体产生不合理的触发行为，保障安全 在这个架构中，各模块均基于强化学习对齐业务目标进行端到端训练，并依据线上真实反馈实现持续的自我进化。 规划智能体： 生成式决策，实现「自主规划」 规划智能体以 Decision Transformer 为骨干，不依赖外部时钟和死板排期，让系统具备了自主规划下一次触发时机的能力。 要预测「下一次多久之后触发」，需要把「目标回报」（Return-to-Go, RTG）作为条件输入。听起来很标准，但工业环境有个致命问题： 目标回报信号的噪声极大、方差极高 。标准的做法是把 RTG 这个一维标量和其他高维状态特征拼在一起输入模型。结果呢？模型在优化时会发现这个一维信号太弱了，直接忽略它反而 loss 更低。于是模型不管你给什么 RTG，输出都差不多，这就是所谓的「条件忽略」（condition-ignoring）问题。 STEPS 的解法是 门控机制（Gated-RTG） ：不把 RTG 当普通特征拼进去，而是用它 乘性地调制状态表征 。相当于给状态嵌入加了一个「由 RTG 控制的开关」，模型想绕过都绕不过去。 另外，模型把 0-24 小时的连续时间划分为 100 个等频有序桶，并根据有序回归平滑解码出下一次时间间隔。 图 3：规划智能体的 Gated-RTG 与有序回归结构 执行智能体： 告别短视，强化学习对齐「长期价值」做决断 执行智能体读取实时状态和候选内容，输出二元动作决定「现在发还是不发」。这个决策看似简单，但背后有一个关键挑战： 推送的价值不是孤立的，而是累积的 。 什么意思？一条推送发出去，影响的不只是这一次的点击。用户今天已经收到了 3 条推送，第 4 条的边际价值就会大幅下降 —— 不是内容不好，而是用户已经疲劳了；反过来，如果用户已经一周没打开 App，一条恰到好处的推送可能就把他拉回来了。 当前决策的价值，高度依赖于之前发生了什么 ，这就是推送场景中的累积效应。 STEPS 的执行智能体基于 Decision Transformer， 把用户的历史交互看成一条完整的轨迹（trajectory ） —— 状态、动作、回报按时间顺序排列，模型在整条轨迹的上下文中做当前决策。这样一来，「用户最近活跃程度如何」、「之前几条推送效果怎样」、「现在是不是合适的时机