一个流量切换决策到底该由谁来做
做百度推广的人，早晚都会撞上一个挺具体的问题：同一个落地页，审核人员看到的和真实访客看到的为什么要不一样，而这个"不一样"到底该在什么时机切？要是全靠固定规则——看见某个IP段就切，看见某个UA就切——那规则一旦被批量识别出来，整条投放链路几分钟之内就废了。百度斗篷真正要解决的事，说白了不是"要不要切换"，而是"什么条件下切、这一手切下去置信度有多高、切完以后信号不对了怎么退回来"。它把流量分发这件事从静态规则往上抬了一层，做成了一套带反馈的决策系统，核心机制落在强化学习上。
输入：决策生命周期中采集什么信号
百度斗篷每一次决策，都是从请求进接入层那一刻开始的。输入端采集什么信号，直接决定了后面模型判断的天花板。这里头有两条并行要求，一条是采集粒度，另一条是信号维度。
静态信号
静态信号在一次会话里基本不变，属于决策的骨架。包括IP归属地、IP信誉评分、ASN自治域信息、User-Agent字符串、Accept-Language语言偏好、屏幕分辨率与视口尺寸、Canvas指纹、WebGL渲染器信息、时区偏移与时间戳一致性。放在百度生态里，还得额外盯着百度账号登录态、百度统计Cookie是否存在、以及从百度搜索结果页跳过来时候带的Referer头完不完整。
这些静态信号单拎出来哪一个都不够触发切换，但凑在一起就能拼出一个很清晰的特征向量。比如说一个请求来自数据中心IP段，UA是无头浏览器的特征，时区和IP地理位置对不上，身上又没有半点百度Cookie——这种请求的特征向量摆在那儿，模型基本就可以给一个高置信度的"内容适配"决策了。
动态信号
动态信号来自访客在页面上的行为序列。包括首屏停留时长、滚动深度和速度、鼠标移动轨迹的熵值、点击热区分布、触屏事件的加速度特征，甚至页面可见性变化的时间节律。动态信号说到底是在回答一个问题：这个请求后头，是不是真有一个活人按照正常的浏览节奏在消费内容。
采动态信号得靠前端脚本配合，但脚本本身不能变成特征暴露源。百度斗篷这边的处理办法是把行为采集代码和业务代码拆开，采集逻辑由服务端动态注入，而且采集频率做了随机抖动处理，避免形成固定的数据上报节奏。
处理：强化学习如何做切换决策
强化学习在百度斗篷里的角色，不是把规则全部干掉，而是把"规则权重的调整过程"接过来。传统规则引擎得靠人工拍阈值——比如IP风险分高过多少就切——阈值定高了，真实用户被误伤；定低了，异常请求又漏过去。强化学习把这个阈值怎么调的事，交给了环境反馈。
状态空间与动作空间
状态空间就是前面那些静态信号和动态信号过了特征工程之后拼出来的向量。原始信号维度高，离散值又一大堆，工程实现里通常先过一层嵌入层，把离散特征映射成稠密向量，再和连续特征拼起来，形成模型能处理的状态表示。
动作空间在百度斗篷这个场景里并不是连续的流量比例，而是几个离散的动作选项：展示标准页面、展示适配页面、展示中间过渡页、还有请求二次验证。四个动作对应不同的决策置信度层级，模型输出的是一组动作概率分布，工程侧按照这个分布采样执行。
奖励函数设计
奖励函数是整个系统里最核心的工程决策。百度斗篷的奖励目标不是一个单一指标，是复合函数。模型对真实用户展示了标准页面，用户完成了转化动作，给正向奖励；模型对真实用户展示了适配页面，跳出率上去了，给负向惩罚；模型对异常信号请求展示了标准页面，后面平台风控信号触发了，给一个大幅负向惩罚；模型正确识别了异常信号并且完成了内容适配，给正向奖励。
奖励函数里权重的配比，直接决定模型的行为风格。异常信号漏判的惩罚权重给得太高，模型就会倾向于过度切换，误伤率往上涨；误伤惩罚权重太高，模型就变得保守，异常请求的拦截率又往下掉。这个平衡点不是固定不变的，得跟着投放阶段走——新账户冷启动期和稳定投放期，目标函数应该是不一样的。
在线更新与离线回放
强化学习模型的更新频率，是另一个关键设计决策。百度斗篷用的是在线增量学习和离线批量回放结合的路子。在线部分只更新价值函数最后一层的参数，保证延迟可控；离线部分定期拿积累的经验回放池对完整网络做批量训练，训完的模型走灰度发布逐步替换线上模型。这种架构的好处是避开了在线学习可能带来的策略震荡，同时又保持了对环境变化的响应速度。
输出：决策结果如何落地
模型吐出来的是一个动作，但从动作到页面真正呈现在用户面前，中间还隔着一截链路。百度斗篷的落地机制分三个层面。
动作执行
决策结果一确定，服务端在响应阶段就完成内容路由。标准页面直接返回业务落地页的HTML；适配页面返回的是经过内容组装的内容合适页面。这里头有个容易忽略的细节：切换动作不应该改变响应的状态码语义。不管返回哪个页面版本，HTTP状态码都保持200，从网络层看根本没有"重定向"这回事，决策过程完全在服务端内部走完。
决策日志
每一次决策都得完整记录状态向量、动作输出、奖励信号，还有最终用户行为结果。决策日志是模型迭代的基础数据，也是排查异常案例时候翻的原始证据。日志设计上要分实时流和离线存储两层：实时流给在线学习和实时监控看板用，离线存储给周期性模型训练和审计回溯用。日志里涉及IP地址和指纹数据的部分，得按最小化原则做脱敏，留下决策要用的统计特征，原始可识别信息不要存。
回退路径
任何决策系统都有失败的概率。百度斗篷的回退路径设计遵循"失败安全"原则：模型不可用、决策超时、或者特征采集异常的时候，默认展示标准页面。这个默认值的选择是有明确理由的——标准页面是平台审核通过的内容，哪怕对异常信号请求展示了标准页面，最坏的结果不过是被平台审计系统记一笔，不至于因为内容和投放声明不一致弄出更严重的后果。回退路径的存在也把模型的行为边界给框住了：底线不能跨，模型只在上限范围内做优化。
运行边界：这套机制在什么条件下成立
百度斗篷的强化学习决策系统不是万能方案，它有几个明确的运行边界。
流量量级这件事，直接决定模型训练效率。强化学习要足够的交互数据才能更新策略，如果账户日均点击就几十个，经验回放池积累得太慢，模型在很长时间里都会停在初始策略附近晃悠，效果还不如直接上规则引擎。从工程经验来看，日均点击稳定在三位数以上，强化学习的优势才开始显出来。
信号采集链路必须稳定，这是另一个前提。强化学习对状态空间的完整性有依赖，前端行为采集脚本要是被浏览器插件拦了、CDN缓存导致脚本版本不一致、移动端弱网环境下动态信号丢得厉害，模型拿到的状态向量就是残缺的，决策质量会明显往下掉。信号采集链路的可用性监控和降级策略，是这套机制能跑起来的前置条件。
还有奖励信号的延迟问题。用户在页面上的转化行为，可能发生在第一次访问之后好几个小时甚至好几天，而强化学习模型需要及时拿到奖励信号来更新策略。工程上得用延迟奖励机制处理这个时间差，常见做法是把后续转化事件通过唯一会话标识回写到对应的历史决策记录上，离线训练的时候再把时间线对齐。
与规则引擎的对比：什么时候该用哪种
百度斗篷场景里，强化学习和规则引擎不是谁替代谁，是分层协作的关系。规则引擎适合处理那些边界清楚、几乎没有模糊地带的条件——比如某个IP段是已知的数据中心出口，某个UA字符串直接命中了已知的自动化工具特征。这些条件用规则处理，成本低、延迟小、可解释性也强。
强化学习的价值在规则覆盖不到的模糊地带。一个行为和真实用户高度相似但IP信誉偏低的请求，规则引擎要么放要么拦，中间没有精细判断的空间；强化学习能输出一个介于两者之间的动作概率，靠调阈值来精确控制误伤率和漏放率之间的平衡。
说一个实际的工作复盘案例。某服务类账户，日均点击在一千二三左右，服务器用的是四核八G的云主机加基础版CDN。最初配了八十多条规则，常见的异常IP段和UA特征都覆盖了，但账户信号异常频率还是不稳定。后来把规则精简到二十条，只留高置信度的硬规则，剩下的判断全交给模型。调整后的前两周里，模型在线更新了三次，切换策略从最初的偏保守逐步收敛到稳定状态，期间没有出现大规模的误伤投诉。这个案例能成立的条件是流量量级够支撑在线学习，要是日均点击只有一两百，模型收敛会慢得多，规则引擎可能仍然是更务实的选择。
概念性FAQ
普通AB页跳转通常基于固定规则或简单条件判断，规则一旦设定就静态执行。百度斗篷在这个基础上引入了持续学习的决策模型，能根据每一次决策的后续结果来调整切换策略，属于从静态分发到动态决策的升级。
强化学习决策会增加页面加载延迟吗
决策延迟取决于特征采集和模型推理的时间消耗。工程上把模型推理放在服务端请求处理链路内完成，特征采集和页面渲染并行进行，决策总延迟通常可以控制在几十毫秒级别。部署架构合理的话，不会对首屏时间造成明显影响。
流量量级小的时候能用强化学习吗
能运行，但不一定有优势。小流量场景下经验积累速度慢，模型在较长时间内停留在初始策略附近，维护成本高于直接使用规则引擎。建议流量量级达到一定水平后再切换。
