feedback: doubao_research 批量采集实测 — 字段不全 + 验证码风控 + 稳定性问题

[1012839419a-alt]

背景

用 doubao_research 渠道做了 240 个非品牌词的批量豆包搜索采集（每词独立新会话），发现渠道/适配器有若干可改进点与 bug。以下均为 2026-08-06 实测（opencli 1.8.6、opencli-admin 0.4.1-fixed、agent Chrome 151）。

一、功能建议：doubao_research 渠道采集字段不全

当前 doubao_research_channel.py 只返回：

• title（=question）、content（assistant 正文）、author、citations（回答内 URL 正则提取）

实际豆包页面还有这些可见模块，采集规范要求逐项记录，但渠道拿不到：

1. 会话 URL：opencli doubao ask 返回的 rows 里没有 conversation id；需要额外 doubao status（或适配器 ask 输出加一列 Url）才能拿到 https://www.doubao.com/chat/<id>。
2. 每词独立新会话：渠道直接 ask，用的是 adapter 默认 siteSession（persistent → 同一会话复用）。批量采集要求每词新会话，需要先 doubao new 再 ask（或 ask 支持 --site-session ephemeral 强制新会话）。
3. 页面模块（参考资料卡片、产品卡/外链、相关视频、推荐追问）无法从 ask 的文本输出获得，需要 CDP 对页面 DOM 提取（Runtime.evaluate）。当前渠道无此能力。

建议：doubao_research 渠道增加可配置项（如 capture_page=True），在 ask 后通过 CDP 提取页面模块并合并进 raw_data/normalized_data；输出里补 conversation_url。

二、Bug / 稳定性问题

1. 验证码风控（最影响批量使用）

• 连续采集 50~60 词后，豆包必弹验证码（rmc.bytedance.com/verifycenter/captcha/v2 iframe）。
• 渠道 Capabilities(default_rate="6/min") 声明的限速并未实际执行，触发后 ask 返回 COMMAND_EXEC / Doubao blocked the request with a verification challenge，任务直接 fail。
• 建议：检测到 captcha iframe 时自动降速/等待（如冷却 N 分钟重试），或在事件日志中明确提示需要人工通过（noVNC 可见），而不是直接 fail。

2. 偶发 doubao status 返回无会话 id

回答已生成后立即 status，偶发返回 Url: https://www.doubao.com/chat（无 id），重试 1-3 次（间隔数秒）可恢复。适配器 status 建议增加一次内部重试。

3. 适配器 ask 偶发崩溃

opencli doubao ask 偶发：Evaluate error: TypeError: Cannot read properties of null (reading 'cloneNode')（页面导航/状态竞态），退出码 1，无自动重试。

4. 容器内 daemon 只监听 localhost

agent-1 容器内 opencli daemon 实际监听 127.0.0.1:19825（entrypoint 里写了 OPENCLI_DAEMON_LISTEN=0.0.0.0 但未生效），导致 api 容器里 opencli browser <session> extract/state 报 "Remote Browser Bridge daemon at agent-1 is not reachable"，只能绕过用 CDP 直连 :19222。建议 daemon 默认绑 0.0.0.0 或让 api 走 CDP 模式（OPENCLI_CDP_ENDPOINT 已支持）。

5. agent 容器 Chrome 无登录态引导

agent-1 Chrome 是全新 profile（游客态），豆包高频提问必触发验证码；渠道文档/UI 没有"请先在 noVNC 登录目标站点"的引导。建议在创建 doubao_research 源时给出登录引导提示。

三、已用的绕过方案（供参考）

• 登录：用户经 noVNC http://localhost:6080 手动登录一次，登录 cookie 落盘 /home/chrome/.config/chromium。
• 每词流程：doubao new → doubao ask → doubao status（拿 URL）→ CDP Runtime.evaluate 提取页面模块。
• 验证码：人工通过 + CDP Page.reload 清残留 iframe；控制节奏（每词间隔 + 每批上限）降低触发频率。

复现环境

• opencli-admin 0.4.1-fixed（上游 0.4.1 缺 2 个 alembic 迁移文件的修复版）
• opencli 1.8.6、Chrome/Chromium 151.0.7922.71
• Windows 11 宿主机 + Docker Desktop，COLLECTION_MODE=local / AGENT_MODE=bridge

[1012839419a-alt]

补充支持材料（2026-08-06 实测，240 词批量采集已完成）：

实测脚本（可复现）

我们用的绕过方案包含三个脚本，核心逻辑如下：

1. 每词采集 worker（容器内执行）

opencli doubao new --site-session persistent -f json    # 每词先开新会话
opencli doubao ask "<词>" --site-session persistent --timeout 150 -f json
opencli doubao status --site-session persistent -f json  # 拿会话 URL（无 id 时重试3次）
# 再用 CDP Runtime.evaluate 对 doubao tab 提取页面模块

关键点：

• 每词独立新会话：必须显式 doubao new，否则 persistent site-session 复用同一会话
• 会话 URL：ask 输出不含 conversation id，需额外 status 拿 Url 字段
• 页面模块提取：CDP 直连 agent-1:19222（容器内 daemon 只监听 localhost，opencli browser <session> extract 跨容器不可用），对 doubao tab 执行 Runtime.evaluate，抓取：
  • keywords：input/textarea 值 + keyword/tag/chip 元素
  • ref_links：非 doubao.com 外链（排除 bytedance/zijieapi/byteimg）
  • product_links：item/product/mall/taobao/jd 等链接
  • video_links：video/douyin/bilibili 等
  • followups：recommend/suggest 区域带 ? 的短句（推荐追问）

2. 验证码处理

• 连续采集 50~60 词后必触发 captcha（rmc.bytedance.com/verifycenter/captcha/v2 iframe）
• 处理：用户经 noVNC 人工通过 → CDP Page.reload 清除残留 iframe → 继续
• 建议渠道能检测 captcha iframe 并自动冷却重试（或事件日志提示人工处理），而非直接 fail

3. 编排节奏

• 每词一次独立 docker exec（前台，跑完即退），避免容器内后台进程残留
• 每轮启动前对归档文件去重（防重复写入）
• 单轮上限 5-10 词，词间隔数秒，降低风控触发频率

实测数据

• 240/240 词全部完成（每词独立会话 URL），0 待补全
• 每词耗时 ~30-40s（new+ask+status+CDP 提取）
• 验证码触发约每 50-60 词一次，人工通过后可持续
• 豆包页面模块实测：240 词中推荐追问出现 ~164 次；参考资料/产品外链/相关视频模块在纯问答场景大多"页面未显示"（与提问类型相关）

对渠道实现的建议优先级

1. P0：ask 输出增加 conversation_url（或 status 合并进结果），批量场景必需
2. P0：支持 --site-session ephemeral（或 config 项）强制每词新会话
3. P1：验证码检测 + 自动冷却重试（当前 6/min 限速声明未实际执行）
4. P1：可选 capture_page=True 时用 CDP 提取页面模块并入 raw_data
5. P2：status 偶发返回无 id 的 /chat → 内部重试
6. P2：daemon 绑 0.0.0.0，让跨容器 browser 命令可用

如需要完整脚本文件（worker / driver / CDP helpers），我可以贴出来或提 PR。

[1012839419a-alt]

更正（重要）：关于"每词新会话"的结论需要修正

进一步核查 opencli 1.8.6 源码（dist/src/execution.js resolveAdapterBrowserSession）后确认：

• --site-session persistent → 浏览器会话固定为 site:doubao（复用，需手动 new 开新对话）
• --site-session ephemeral → 浏览器会话每次为 site:doubao:<randomUUID>（天然每次全新对话）

而 doubao_research_channel.py 第 91 行默认正是 str(config.get("site_session", "ephemeral"))——渠道默认已经满足"每词新会话"，我 issue 第 2 点（"渠道用 persistent 会话复用、需先 new"）不准确，撤回该条。

实际分工澄清

• 我在 worker 里用 --site-session persistent + 显式 doubao new（当时没注意到渠道默认 ephemeral，为稳妥手动开新会话）——这是个人实现选择，不是渠道缺陷。
• 渠道本身的正确用法：保持默认 ephemeral 即可每次新会话；不需要改代码支持 --site-session ephemeral（已是默认）。

更新后的有效建议清单

1. P0：ask 输出增加 conversation_url（status 的 Url 字段合并进结果），批量场景必须（当前渠道输出无会话 URL，需额外 status 调用）
2. P1：验证码检测 + 自动冷却重试（default_rate="6/min" 声明未实际执行；实测连续 50-60 词后必触发 captcha，当前直接 fail）
3. P1：可选 capture_page=True 时用 CDP 提取页面模块（参考资料/产品外链/相关视频/推荐追问）并入 raw_data
4. P2：status 偶发返回无 id 的 /chat → 内部重试
5. P2：agent-1 daemon 绑 0.0.0.0，让跨容器 browser 命令（extract/state）可用

其余（验证码 fail 行为、无会话 URL、daemon localhost、agent Chrome 无登录引导）维持原判。

[1012839419a-alt]

已把 P0（conversation_url）+ P1（验证码错误分类）落成 PR：#63（https://github.com/2233admin/opencli-Razormind/pull/63）

• 12 个单测全过（原 4 + 新增 8），ruff 全过
• 改动最小：2 文件 +154/-3，向后兼容（status 失败不影响 collect）
• 剩余建议（P1 capture_page 页面模块提取、P2 daemon 绑 0.0.0.0、P2 status 内部重试）欢迎讨论，需要的话可以继续提 PR