夜雨聆风
📋 本文目录
· OpenClaw 招聘助手系统架构
· Boss 直聘的反爬体系：层层递进
· 第一关：二维码格式不对
· 第二关：扫了也白扫
· 第三关：旧 cookie 来捣乱
· 第四关：登录成功，被自己删了
· 第五关：逆向 stoken 本体
· 最终防线：wt2 无法绕过
· OpenClaw 的解法：qr-auth-hub
· 五关总结
我们在用 OpenClaw 搭一个招聘小助手——让 AI Agent 自动盯 Boss 直聘、筛候选人、发飞书通知。
在 OpenClaw 框架里，Agent 是长期运行的后台进程。它不是人，没法拿起手机扫码。但 Boss 直聘的登录体系从头到尾都假设"对面是个真实用户"——于是从扫码到拿 cookie，我们踩了五道坑。
OpenClaw 招聘助手系统架构
人只需要参与一件事：扫码。扫完后 Agent 接管一切——凭证维护、会话续期、候选人采集、飞书推送。
但让 Agent 拿到这第一次扫码凭证，我们踩了五个坑。
Boss 直聘的反爬体系：层层递进
| 层级 | 防线名称 | 机制 |
|------|---------|------|
| 第 1 层 | 格式验证 | 二维码内容必须是服务端签发的图片 URL |
| 第 2 层 | 时序检测 | HTTP 200 ≠ 登录成功，用户必须在 APP 点"确认" |
| 第 3 层 | 凭证隔离 | stoken 与 wt2 强绑定，不可跨 session 混用 |
| 第 4 层 | 完整性校验 | 任意 token 缺失 → 整组凭证清除 |
| 第 5 层 | JS 混淆指纹 | OB 混淆 + 控制流平坦化，保护 stoken 生成逻辑 |
| 最终防线 | wt2 服务端签发 | 必须真实扫码，无法程序化获取 |
第一关：二维码格式不对
现象 & 根因
| 项目 | 内容 |
|------|------|
| 操作 | 把 qrId 直接拼成字符串生成二维码 |
| 现象 | Boss APP 扫码后无反应，不跳转登录页 |
| 根因 | Boss 二维码内容不是 qrId 字符串，而是服务端签发的图片 URL |
正确接口流程
Step 1 POST /wapi/zppassport/captcha/randkey
→ 返回 qrId
Step 2 GET /wapi/zpweixin/qrcode/getqrcode?content=<qrId>&w=200&h=200
→ 下载二维码图片（这张图片才是 Boss APP 认的码）
Step 3 用 Step 2 返回的图片 URL 生成二维码展示给用户
直接用 qrId 拼的二维码，Boss APP 根本不认——扫了也是白扫。
第二关：扫了也白扫
现象 & 根因
| 项目 | 内容 |
|------|------|
| 操作 | 检测到 HTTP 200 后立即读取 cookie |
| 现象 | cookie 为空，返回未登录状态 |
| 根因 | 扫码 ≠ 登录确认，用户在 APP 点"确认"才触发 cookie 下发 |
正确轮询方式
# ❌ 错误：固定 sleep 或短轮询
time.sleep(3)
cookies = get_cookies()
# ✅ 正确：长轮询，等 scaned=true
GET /wapi/zppassport/qrcode/scan?uuid=<qrId>
# 这是 100 秒长轮询接口，不是一次性请求
# 必须等返回 {"scaned": true} 才代表用户已确认
# 实现方式：用 run_in_executor 包裹长轮询，不阻塞事件循环
import asyncio, urllib.request
async def wait_for_scan(qr_id: str) -> bool:
loop = asyncio.get_event_loop()
def _poll():
url = f"https://www.zhipin.com/wapi/zppassport/qrcode/scan?uuid={qr_id}"
with urllib.request.urlopen(url, timeout=105) as r:
return json.loads(r.read())
result = await loop.run_in_executor(None, _poll)
return result.get("data", {}).get("loginInfo", {}).get("token") is not None
第三关：旧 cookie 来捣乱
现象 & 根因
| 项目 | 内容 |
|------|------|
| 操作 | 把旧 stoken 混入新 session 的 cookie jar |
| 现象 | 请求被拒，wt2 验证失败，整组凭证被服务端清除 |
| 根因 | stoken 与 wt2 是同一次登录的配对 token，跨 session 签名不匹配 |
stoken vs wt2 的本质区别
| 字段 | 生命周期 | 获取方式 | 能否程序化刷新 |
|------|---------|---------|--------------|
| __zp_stoken__ | 较短（小时级） | 前端 JS 动态生成 | ✅ 可逆向刷新 |
| wt2 | 较长（天级） | 服务端扫码登录签发 | ❌ 只能扫码获取 |
对 Agent 来说这个问题更麻烦：Agent 长期运行，session 可能中断再续。任何一次"把旧 stoken 接到新 session"的操作，都会触发这道防线，导致整组 cookie 被清掉、Agent 被踢出登录态。
第四关：登录成功，被自己删了
现象 & 根因
| 项目 | 内容 |
|------|------|
| 操作 | 登录流程跑完，再调一次 load_session() 确认状态 |
| 现象 | 凭证消失，重新回到未登录状态 |
| 根因 | 两道"守门员"校验都在执行"stoken 缺失 → 删整组 cookie" |
问题代码 vs 修复代码
# ❌ 问题代码：防御性代码写成了进攻性代码
def load_session(cookies):
if "__zp_stoken__" not in cookies:
delete_all_cookies() # 登录刚完成，stoken 还没到位，这里就把全部 cookie 删了
return False
# ✅ 修复：区分"完全无效"和"仅缺 stoken"两种情况
def load_session(cookies):
core_cookies = {"wt2", "ab_guid", "__a"}
if not core_cookies.issubset(cookies.keys()):
delete_all_cookies() # 核心 cookie 缺失，才是真正无效
return False
if "__zp_stoken__" not in cookies:
refresh_stoken(cookies) # 仅缺 stoken，走刷新逻辑补齐
return True
教训：防御性代码的逻辑应该是"有问题就修"，不是"有问题就删"。
第五关：逆向 stoken 本体
现象 & 根因
| 项目 | 内容 |
|------|------|
| 操作 | 用 Camoufox（stealth 浏览器）自动化获取 stoken |
| 现象 | 被识别为非真实用户，返回异常页面 |
| 根因 | Boss 前端 JS 做了环境指纹检测，stealth 浏览器特征被识别 |
| 转向 | 直接提取混淆 JS，在 Node.js 里补环境执行 |
Boss stoken JS 的两层保护
| 保护层 | 技术 | 效果 |
|-------|------|------|
| OB 混淆 | JavaScript Obfuscator | 变量名变成 _0x1a2b，逻辑拆散 |
| 控制流平坦化 | 展开成巨型 switch-case | 人工阅读成本极高 |
补环境跑通 stoken 生成
// 在 Node.js 里模拟浏览器环境，让混淆 JS "以为"自己在浏览器里
global.window = global;
global.navigator = { userAgent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)..." };
global.document = { cookie: "", createElement: () => ({}) };
global.location = { href: "https://www.zhipin.com/web/boss/job-manage" };
// 用 vm 隔离加载混淆 JS，避免污染全局
const vm = require("vm");
const code = require("fs").readFileSync("boss_stoken.js", "utf8");
vm.runInThisContext(code);
// 调用逆向还原的生成函数（示意，实际函数名需逆向确认）
const stoken = new StokenGenerator().generate(seed, Date.now());
// ✅ 跑通，返回有效 stoken
关键点：补环境成功的核心是让 window.location.href 返回正确的 Boss 域名页面路径，否则生成的 stoken 签名对不上。
最终防线：wt2 无法绕过
stoken 可以逆向，wt2 不行。
stoken ✅ 可逆向生成，可定期刷新，Agent 自动维护
wt2 ❌ 服务端在用户完成扫码时签发，没有任何客户端接口可以获取
这是 Boss 反爬的终极逻辑：不管你逆向了什么，登录的起点必须是一个真实的人扫了一次码。
反爬的终局，是"人的在场"。
OpenClaw 的解法：qr-auth-hub
接受这个约束，围绕它设计，而不是绕过它。
OpenClaw 内部有一个 qr-auth-hub 服务，专门处理需要人工扫码的认证场景：
① Agent 检测到 wt2 过期（通过 check_login_status 判断）
② qr-auth-hub 调 Boss 接口生成二维码
③ 飞书私信推送给用户："Boss 直聘 session 过期，请扫码续期 🔐"
④ 用户手机扫码 → APP 点确认
⑤ qr-auth-hub 长轮询到 scaned=true，取完整 cookie 存入 auth.db
⑥ Agent 自动读取新 cookie，继续运行
| 角色 | 做什么 |
|------|-------|
| 用户 | 扫一次码，点确认（30 秒） |
| qr-auth-hub | 生成码 → 推飞书 → 轮询 → 存 cookie |
| Agent | 检测过期 → 触发续期 → 拿新 cookie |
人只需要参与一次，其余的 Agent 全包。
五关总结
| 关卡 | 防线 | 踩坑原因 | 对 Agent 的特殊挑战 |
|------|------|---------|-------------------|
| 第一关 | 格式验证 | 以为 qrId 就是二维码内容 | 需要多一个 API 调用，不能偷懒 |
| 第二关 | 时序检测 | 把 HTTP 200 当成登录成功 | 100s 长轮询，短轮询/sleep 都会漏 |
| 第三关 | 凭证隔离 | 复用了旧 stoken | Agent 长期运行，session 续接时最容易触发 |
| 第四关 | 完整性校验 | 防御代码变进攻代码 | 多道校验互相干扰，自己把自己踢下线 |
| 第五关 | JS 混淆指纹 | stealth 浏览器被识别 | 补环境跑 OB 混淆 JS，Node.js vm 模块 |
| 最终防线 | wt2 服务端签发 | — | 不绕过，设计 qr-auth-hub 让扫码成为可管理的运维动作 |
*免责声明：本文记录的技术实践仅用于个人自用招聘工具开发，不用于商业爬取或大规模数据采集。请遵守 Boss 直聘用户协议及相关法律法规。*
