公域数据采集 与 私域客户触达 两条独立链路如何在平台风控下保持稳定运作
系统对外只做两件事：从公开内容中收集潜在客户线索，再以个人身份完成首次触达。 两条链路独立设计、独立账号池、独立速率预算，任一侧被风控不影响另一侧。
每条链路都按"指纹层 → 行为层 → 速率层 → 状态机层"四档纵深防御。任一层失守，下一层兜底。
从短视频评论中找到表达需求的潜在客户
先用与官方 Web 端等价的请求签名直接调评论 / 主页 API。比浏览器自动化快一个数量级，请求形态与真实用户完全一致，绝大多数采集任务根本不需要打开浏览器。
API 路径失败时才落到无头浏览器。底层换用对协议级 bot 信号免疫的自动化框架，并在页面注入八项 JS 补丁——隐藏自动化标记、伪造插件列表、伪造 GPU 厂商与渲染器、给 Canvas 注入像素噪声、对齐语言时区屏幕分辨率，让 JS 可见的指纹接近真实桌面浏览器。
所有等待都包了一层抖动函数，让操作间隔围绕基准值上下浮动，破坏"机器规律性间隔"这一指纹信号；UA 池随机轮换，多个桌面平台型号交叉出现。
每个采集账号有日使用量与连续失败计数。选号优先用得最少的；失败次数到达低位阈值进入冷却期、到达高位阈值升级为疑似封禁告警。每次成功立即清零。多租户硬隔离——每个客户独立账号池，互不影响。
评论里大量是同行打的广告，会污染线索质量并浪费后续大模型评分预算。在写库前用规则识别招商加盟、加微留联、工厂直供、地理+行业组合等模式，命中即归档为"已跳过"，不进入意向打分流程。
把审核过的文案以个人账号身份送达陌生客户
从冷启动浏览器直接跳到目标用户主页，平台风控会判定为可疑行为并展示验证码中间页。 标准做法是：先验证登录态有效，再访问首页主信息流停留几秒，然后才跳目标主页。 模拟真人打字时还要逐字键入并加随机停顿，避免一次性灌满输入框。
遇到错误时严格区分两类：含"验证码 / 验证中间页"关键词的属于浏览器指纹被挑战，账号本身没事，只标记本次失败；含"未登录 / 账号封禁 / Cookie 失效"才是账号级故障，进入封禁流程。混淆两者会大量误封正常账号。
私信接口的"成功响应"分两层：协议层确认请求被收下，业务层才告诉你消息是否真的送达。 只看协议层会被风控静默丢弃迷惑——表面 200 OK，对方手机却收不到。 系统会对二进制响应解码后校验业务级状态码，只有业务级真正放行才标"已发送"。
三道速率墙叠加：单账号日上限（进程内计数 + 数据库字段双轨），守护进程层的长间隔节流（保守日上限 + 长间隔），以及触顶后睡到次日凌晨自动续跑。陌生人首条私信对速率最敏感，因此实际配额远低于平台名义上限。
守护进程启动前，先给一个已经建立过会话的目标发条无成本的"在的"——因为"非陌生人"消息不消耗陌生人配额，可以拿来探测当前是否仍在冷却中。一旦冷却未解，拒绝进入主循环。 运行中只要触发到一次速率风控信号，立即熔断：当前批次停止、卡片告警、进程退出，绝不"再试一条看看"——重试只会加深处罚。
批量发送时，同一份模板被风控聚类为"群发"是大概率事件。每条首发文案先用大模型按客户画像重写一遍，保证语气、长度、用词都不重复；后处理还会剥掉模型偶发输出的方括号表情代号等"机器味"残留。
两条链路在工程上看起来很不一样，但底下共用一套设计原则。
浏览器自动化是兜底，不是首选。能用真实 Web 端等价的签名请求拿到数据，就不要走 DOM 滚动。这层对成本、稳定性、风控暴露面都是数量级优化。
所有时序都加抖动，所有指纹都对齐桌面真实值，所有交互都先暖场再行动。 宁可慢一倍，不可让请求看起来"机器规律"。
验证码 ≠ 封号、协议 OK ≠ 业务送达、单次错误 ≠ 账号失效。 每一类故障对应不同的恢复策略——混在一起统一重试就是慢性自杀。
触达侧首次触发风控信号立即停手并告警。 重试只会让平台对账号的判定从"可疑"升级为"确认违规"，自愈周期从一天变成永封。
名义上限和实际安全上限不是一回事。从远低于名义上限的预算起跑，观察一段时间无异常再小步上调，永远不要为了"今天发完"而强冲。
每个账号都进入健康状态机被持续观测——日使用量、连续失败、最近成功时间、冷却阶段。 多租户场景下还做硬隔离，一个客户的账号被封，绝不影响另一个客户的可用池。