风控脚本一更新，最常见的反应是把整条链重拆一遍。
新的 URL、更大的体积、消失的调试接口，看起来都像“算法已经换了”。Akamai Bot Manager 的一次续跑给出相反的证据：引导脚本和主脚本都变了，控制流扁平化的分支数也变了，但遥测组装的四段结构和正文替换层的输入输出关系仍能对上。
混淆强度变化是事实。协议层是否变化，要另做对照。
先钉住不会随混淆漂移的结构
这一次我没有从新脚本的第一行重新读起。先问三个可以跨版本复述的问题：
- 遥测出口是否仍按同一组分段拼装；
- 分段是否仍映射到同一组会话 cookie 字段；
- 正文替换层的种子、字母表和可逆关系是否仍成立。
运行时核对后，出口仍是四段拼接；cookie 到分段的映射仍逐字节成立；经典头结构仍在。正文替换层用固定样本做前后对照，短输入和长前缀都能对上。脚本 URL 换了，内嵌的脚本常量会跟着换，可那是版本材料，不是算法家族切换。
这和淘宝 MTOP 的分层验收是同一类判断，只是对象不同。淘宝那次先锁定纯算、再确认指纹头是否进入成功路径，见 《淘宝 MTOP 纯算签名与分层验收》。这次是看见混淆升级，却先核对照协议层是否仍在。
哪些变化其实不在算法层
续跑里确实发生了变化。主脚本和引导脚本都变大；switch 分支数量改变；某个列举内部函数的 API 被拿掉。这些会让旧的 hook 点失效，也会让“按函数名搜索”的笔记过期。
它们不能单独推出“加密换了”。如果 cookie 映射和替换层的 fixtures 仍绿，更准确的说法是：对抗面收缩了，协议层还在。下一步应该补的是跨版本门禁，而不是把已经收敛的纯算法模块推倒。
还有一层容易看错。字段打包看起来像独立变换，解密后却发现本次调用并不改内容，明文仍是有序字段串。若把“看起来像 CFF 分发器”当成“必须先纯算完打包逻辑”，就会在已经可逆的层前面再挖一个坑。打包层是否改变字节，只能用解密后的明文对照，不能用控制流长得复杂来代替。
跨站也要分开记账
同一套传感器协议，在不同站点上的硬门槛并不一样。有的站点把传感器提交当成软评分，业务页不因缺少某段 cookie 就硬拦；有的站点在更外层用客户端特征直接拒绝。跨站复用算法模块时，失败要先问是边缘拦截、会话材料，还是算法回归。
三站对照只证明一件事：协议层可以跨站点复述，站点策略不能。低优先级站点的边缘拒绝，不能用来否定已经对齐的算法 fixtures。高优先级站点的软评分，也不能被写成“完整信任态已经离线伪造完成”。后一项明确不在公开结论里。
还缺什么，就必须停在缺什么
正文替换层可逆，不等于行为事件已经可生成。服务端接受浏览器内或模板参数化后的传感器提交，不等于会话信任态已被完整还原。公开文章不讨论如何构造行为字段，也不提供可复现的提交入口。
《补环境脚本为什么会越补越错》 说的是环境桩。版本漂移有同样的纪律：没有跨版本 fixtures，就不宣称算法仍在；fixtures 仍绿，就不把混淆变化写成协议重写。需要重拆的是对不上的那一层。
所以下次看到脚本体积跳变，我先跑旧的结构门禁。门禁还在，协议就还在。门禁坏了，再打开对应层。整包重拆是最后一步，不是第一反应。