推不推、何时推？抖音、北大提出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）—— 状态、动作、回报按时间顺序排列，模型在整条轨迹的上下文中做当前决策。这样一来，「用户最近活跃程度如何」、「之前几条推送效果怎样」、「现在是不是合适的时机」这些信息都被自然编码进了轨迹表征，模型能基于完整上下文判断当前动作的长期价值。

但光有轨迹还不够。离线日志里的历史行为不一定是最优的 —— 可能该发的时候没发，不该发的时候发了。如果直接模仿学习，等于把坏习惯也学进去了。STEPS 的做法是用贝尔曼（Bellman）方程迭代估计正、负长期回报：分别计算「在当前状态下发推送」和「不发推送」长期来看各自能带来多少价值，得到两个 Q 值。然后根据相对 Q 值为训练样本加权 —— 长期价值越高的动作，对策略更新的影响越大。这就是所谓的价值引导学习（Value-Guided Learning）：模型学的不是「历史上系统怎么做」，而是「怎么做长期来看更好」，从而主动纠正离线数据中的次优行为。

图 4：基于贝尔曼方程的执行智能体结构

过滤智能体：

告别流水线，实现「动态分支」

过滤智能体（Filtering Agent）扮演着轻量的守门员角色，它的核心价值在于打破了传统的静态推荐工作流，实现了算力的动态分支。

在传统系统中，一旦触发就会无脑跑完「召回 - 粗排 - 精排」全链路，这部分的计算开销是过滤智能体的50 倍以上。在 STEPS 中，除了规划智能体生成的触发时间，实时业务事件（比如朋友发了新视频）也可以唤醒系统。智能体每次醒来都会先进行快速评估，过滤智能体会基于轻量级的 RL 模型来判断此次发送的价值，动态决策是进入昂贵的「下发计算分支」，还是直接拦截并规划下一次苏醒。

它的筛选阈值不是「随机砍流量」，而是价值感知的。这在全勤用户上表现最为明显：这类用户业务事件多（关注的人开播、朋友发视频）、拉活价值低，大量推送其实是冗余的，过滤智能体会主动拦掉这些重复打扰（拦截率 85.65%）。

过滤智能体还有第二个作用：安全护栏。它能防止规划智能体产生不合理的触发行为（比如过于频繁地唤醒系统导致对用户的过度打扰），相当于给闭环加了一道保险丝。

十亿用户线上 A/B 测试：

价值、体验与效率同时改善

离线训练与评估使用超过 6 个月的生产日志，覆盖超过 10 亿全量抖音用户。线上实验在抖音推送平台按用户设备完全随机分组，连续运行 14 天。比较对象包括当时的预先规划生产基线，以及资源消耗被调到尽量接近基线的固定间隔触发方案。

相对预先规划生产基线，STEPS 将用户活跃天数（User Active Days, UAD）提高 0.2843%，将用户负面体验（关闭推送权限）降低 1.9089%，并把系统总体计算资源消耗降低 79.42%。三项指标相对生产基线均得到改善。

注：消融实验显示，规划智能体是活跃和体验改善的最大贡献者；执行智能体继续放大收益；过滤智能体单独带来了 74.88% 的资源下降。

比总量指标更有意思的是论文给出的实验分析 —— 每个设计点都配了一个可以被质疑的观测量，接下来我们依次看下。

Gated-RTG 机制有效让模型「听懂」目标

图 5：训练过程中目标回报与动作的相关比率变化

为了验证条件注入是否有效，作者定义了 Correlation Ratio：给同一批样本分别喂 RTG=0.0 与 RTG=1.0，看预测间隔的期望之比。比值接近 1.0 意味着模型完全忽略条件，明显偏离 1.0 才说明条件 — 动作对齐真的建立起来了。

标准 DT 的比值在 1.0 附近随机游走，等于把 RTG 白喂了；Gated-RTG 则把比值稳定地推离 1.0，和真实数据的经验统计高度吻合，说明当给模型设定更高的拉活目标 RTG 时，它会给出更小的预测间隔。模型终于「听进去」了目标信号。

发送分布更合理，极端触达被抑制

规划智能体上线后，部分用户被密集发送的情况明显改善。0-20 分钟的极短推送间隔占比下降 35.93%，整体分布向较长间隔移动，发送间隔更为合理。

同时，结合执行智能体的实验分析，能发现发送条数也更均衡了：每天接收 1-20 次推送的用户占比增加 20.31%，极高频用户（超过 30 次）占比显著下降 9.30%，完全没收到推送的用户占比也有所下降。模型成功抑制了过多与过少两种极端情况。

日内发送概率随用户价值变化

图 6 (a)：当前未活跃用户的执行通过率日内增量。历史高活与低活用户走向完全相反。

这部分分析非常有趣，说明了模型如何看待一天当中的用户价值变化。对当前未活跃、但历史高活跃的用户，越晚发送概率越高 ——这类用户到了晚上还没来，很可能是今天还没想起来打开 App，推一条的价值更大。而对当前未活跃、历史低活跃的用户，越晚价值越低：这类用户如果一整天都没被拉活成功，大概率今天也就没戏了，推送价值低。模型在同一时段会对不同用户给出方向相反的判断。

模型预估的可靠性也做了检查：预测 Q 与真实 RTG 的比值全天稳定在 1.0 到 1.1 之间，预估准度可靠。

过滤智能体按价值动态分配算力

相对无过滤设置，过滤智能体总体裁剪 74.88% 的请求；对低活跃、高活跃和全勤用户的裁剪率分别为 78.86%、66.63% 和 85.65%。全勤用户上的裁剪最强，这部分用户拉活价值不高，说明模型学到了价值最大化的拦截模式，将算力分配到价值更高的请求上：倾向于提前剔除边际价值低、却会触发昂贵排序的冗余机会。

总结：

从「被动响应」到「主动闭环」的范式转变

STEPS 这篇论文的价值，不仅在于跑通了一个具体的系统，更在于探索了一种新的技术范式。

传统推送系统通常是「被动」的 —— 被时间表或固定时钟驱动，系统本身缺乏决定「行动节奏」的能力。STEPS 尝试将推送转化为一个自触发的智能体闭环，使系统在工业实践中初步展现了 Agentic 的三个关键特征：

• 自主规划：系统基于模型预测「下一次唤醒时间」，用生成式决策替代了外部时钟与固定排期，在时间选择上获得了更高的灵活度；
• 动态分支：系统在唤醒后通过轻量级评估决定后续的计算链路，优化了传统的静态流水线，提升了算力的使用效率；
• 自我演进：系统引入强化学习框架，在与用户的交互中逐步对齐长期价值，有效减少了对人工启发式打扰规则的依赖。

这种思路与当下 Agentic AI 的发展趋势相契合：系统正逐步从等待外部输入的静态函数，向能与环境交互、具备一定规划能力的自触发的智能体闭环系统演进。