Bili Review Console 吸收 OpenBiliClaw B站渲染搜索能力方案

Bili Review Console 吸收 OpenBiliClaw B站渲染搜索能力方案

结论

建议 有条件吸收，级别 L3 / Partial Absorb。吸收的不是 OpenBiliClaw 整套后端、扩展或画像系统，而是它在 B站上的一个能力单元：

当项目本地 B站 API / up_feed 出现 412、空结果或 UID 映射不稳时，用“渲染搜索任务桥”补一条可观测、低预算、人工审核友好的 browser-side discovery/rescue 通路。

但它不应该替代当前 Bili Review 的主链：

建议落点是 Bili Review 平台能力增强，具体表现为：

1. 控制台能发起“B站浏览器侧搜索诊断 / rescue 任务”。
2. 任务结果进入 Review Console 的任务记录和诊断区，而不是直接写正式 UP 池或默认视频队列。
3. 只有在 POC 证明收益后，再作为 broad_sample 的低预算 fallback adapter 候选。

背景与现有能力基线

当前本地体系已经具备较强 B站生产链路：

• bili-tech-pipeline 负责采集、broad sample、UP profile、权重治理、report/payload。
• bili-review-console 负责人工审核控制台、任务触发、Video Review / UP Review 队列。
• 控制台视频抓取主线已回到 broad_sample，不是旧的 stable_sample 探针。
• TaskService._run_broad_sample_video_crawl_until_target() 已按实际 inserted_review_items 循环到目标，而不是只看 publishable_count。
• Video Review Queue 已有本地 BVID 去重、同批去重、Feishu Bitable dedupe。
• UP 池已支持 profile-only source entity、空源 backfill、candidate_pool 导入 UP Review、连续低转化分级降权。
• 旧 412 方案已明确：Playwright/browser 只作为诊断 sidecar，不进默认采集主链。

当前 config/broad_sample_sources.json 的核心参数：

这说明我们不缺“主链能跑”的能力，缺的是：

• API 412 / 空结果时的 browser-side 对照证据。
• UP 名称 → UID 映射的可视化/可审核修复链。
• 对“浏览器页面可见但 API 不稳定”的 source，缺少一个比 Playwright 临时诊断更产品化的 Review Console 入口。

OpenBiliClaw B站能力可吸收点

OpenBiliClaw 的 B站链路是：

它的关键价值有三点：

1. 用真实浏览器页面做搜索 fallback：平台页面自己完成签名/风控上下文，content script 只读结果卡片。
2. 任务队列化：不是一次性 Playwright 脚本，而是后端有任务、状态、结果、超时、日志。
3. 产物结构化：输出 BV、标题、UP、封面、播放量等，能进入后续候选/审核链。

对我们的 Bili Review 来说，最值得吸的是“任务桥设计”，不是扩展代码本身。

与现有能力对比

判断：增强关系，不是替代关系。

推荐方案：Bili Rendered Search Rescue（BRSR）

目标

构建一个面向 Bili Review 的 B站浏览器侧搜索/诊断/rescue 能力，先作为人工可控任务入口，后续再评估是否接入 broad_sample fallback。

非目标

明确不做：

• 不安装/运行完整 OpenBiliClaw。
• 不导入其 Soul/推荐/候选池系统。
• 不改 Bili Review 默认视频抓取主链。
• 不把 browser sidecar 变成大规模采集器。
• 不自动写 up_profiles.json、sources.yaml、正式 Bitable。
• 不静默依赖用户登录态做无人值守批量抓取。

架构设计

Phase 0：只加 Review Console 诊断任务，不碰主链

新增一个控制台任务类型：

任务输入：

任务输出：

Phase 1：pipeline 侧新增只读脚本

在 bili-tech-pipeline 新增：

职责：

• 输入 source/keyword/search_type。
• 调用浏览器侧工具执行搜索。
• 解析渲染结果。
• 产出 JSON。
• 只写 tmp/diagnostics/。

这一阶段可以先复用 Playwright CLI / browser 工具，不急着做浏览器扩展。原因：

• 我们要先验证收益，不要先承担 extension 分发/权限/常驻调试成本。
• 旧 412 方案已经把 Playwright 定位为诊断 sidecar，和这一步一致。
• OpenBiliClaw 的“扩展任务桥”可以作为 Phase 3 产品化目标，不是 Phase 1 起点。

Phase 2：Review Console 接入任务

在 bili-review-console 增加：

• TaskService.enqueue_bili_rendered_search_probe(...)
• _run_bili_rendered_search_probe_task(...)
• LegacyRuntimeAdapter.run_bili_rendered_search_probe(...)
• 控制台任务列表展示该任务的：
• browser_access
• visible_user_candidates 数量
• visible_video_candidates 数量
• recommendation
• artifact_paths

此阶段仍不把视频候选写入 Video Review Queue。它只是诊断/候选证据。

Phase 3：可选转为低预算 fallback adapter

只有 Phase 0-2 证明收益后，再在 bili-tech-pipeline 新增 adapter：

触发条件必须窄：

输出要保持 CandidateVideo 兼容：

但即使进入 fallback，也必须继续走现有 scoring / payload / Review Queue / dedupe，不绕过现有验收。

文件级改造建议

bili-tech-pipeline

#### 新增脚本

CLI：

#### 新增测试

重点测试不依赖真实 B站页面，打桩 browser runner 输出 HTML/snapshot：

1. 能从 space.bilibili.com/<uid> 链接提取 UID。
2. 能从 /video/BV... 链接提取 BVID。
3. 遇到验证码/风险页面时输出 browser_access=captcha_or_risk。
4. 输出 JSON 不写正式 config。
5. --emit-override-candidate 只写 tmp/diagnostics/up_alias_override_candidates.json，不写 config/up_alias_overrides.json。

#### 可选新增 adapter

只有 Phase 3 才做。

#### 可选更新配置

默认必须是 false。

bili-review-console

#### 修改 TaskService

新增：

• enqueue_bili_rendered_search_probe(...)
• _run_bili_rendered_search_probe_task(...)

#### 修改 RuntimeAdapter

新增：

• run_bili_rendered_search_probe(...)
• subprocess 调 src/scripts/probe_bili_rendered_search.py
• 解析 JSON 输出，带 result_path

#### 修改 Repository / Migration

如果 console_tasks 继续用 task_type + params_json + result_json 通用结构，第一阶段可不加表。

如果后续要单独列表展示诊断历史，再新增：

但第一阶段不建议加表，避免过早产品化。

#### 前端 UI

增加一个轻入口：

字段：source、search_type、limit。

展示：

• browser_access badge
• UID 候选
• 视频候选数
• recommendation
• artifact path

测试验证流程

Layer 1：纯解析单元测试（bili-tech-pipeline）

命令：

验收：

• UID/BVID 解析稳定。
• 风险页分类稳定。
• 输出 schema 完整。
• 不触碰正式配置。

Layer 2：脚本级 dry-run / fixture 测试

命令：

验收：

• exit code 0。
• browser_access=ok。
• visible_user_candidates[0].uid 非空。
• 输出路径存在。

Layer 3：Review Console 后端任务测试

新增/扩展：

命令：

验收：

• enqueue 后 params_json 保留 source/search_type/limit。
• runtime fixture 返回后 task status=succeeded。
• result_json 含 result_path、browser_access、recommendation。
• 不新增 Video Review Queue item。
• action_logs 有 bili_rendered_search_probe_started/finished。

Layer 4：与现有 Video Review 边界回归

命令：

验收：

• 原 QA fixture 仍通过。
• broad_sample 仍按实际 inserted_review_items 循环。
• Video Review BVID 去重不受影响。
• UP discovery dry-run / candidate_pool 边界不受影响。

Layer 5：pipeline 现有 broad sample 回归

命令：

验收：

• profile-only source entity 仍可选中。
• backfill 逻辑不变。
• UP 池权重/降权不变。

Layer 6：真实单源 smoke（人工触发）

命令：

验收：

• 单 source < 90 秒。
• 若页面正常，至少能给出 UID 候选或明确 no_visible_candidate。
• 若页面风控，输出 browser_access=captcha_or_risk，不重试撞平台。

Layer 7：真实 broad_sample 对照

只在 Layer 6 成功后做：

对照字段：

• candidate_count
• eligible_count
• publishable_count
• target_meta.backfill
• warnings 中 412/empty source 数
• fallback_triggered / fallback_reason

验收不是“必须更多 publishable”，而是至少满足一个：

• 能把 412 source 分成 browser risk / UID mapping / source empty。
• 能产出高置信 UID override candidate。
• 能减少下一轮同一 source 的无效 412 消耗。

保留 / 回滚门槛

保留条件

满足任意两项才值得继续：

1. 对至少 3 个样本 source 做出稳定分类：API 412、browser risk、UID mapping、source empty。
2. 至少生成 1 个高置信 UID override candidate，并经 AutoCLI/SDK enrichment 后能拿到真实视频详情。
3. 单 source 运行时间 < 90 秒，失败时可解释，不挂死任务。
4. 接入 Review Console 后，不影响现有 video_crawl、up_discovery 测试和任务执行。
5. 对同一批 source 的后续 broad_sample，减少重复 412 或提升 candidate_count 稳定性。

禁用 / 回滚条件

出现任意一项就保持 diagnostic-only 或回滚：

1. 频繁触发登录/验证码，无法获得稳定证据。
2. 单 source 成本过高，拖慢控制台任务。
3. 开始依赖用户登录态/cookie 才能工作。
4. 误把诊断候选直接写入正式 UP 池或 Video Review Queue。
5. 对 candidate_count / eligible_count 没有可观测改善，只增加维护面。

回滚方式

• 删除/隐藏 Review Console 入口，不影响 video_crawl 主链。
• 保留脚本但默认 disabled。
• 删除 tmp/diagnostics/ 产物。
• 若误写 alias override，用 git diff 回滚 config/up_alias_overrides.json。
• broad_sample 配置中 rendered_search_enabled=false。

是否值得吸收

当前判断

值得吸收，但只吸 Phase 0-2 的控制台诊断/证据链；暂不吸 Phase 3 默认 fallback adapter。

原因：

• 当前主链已经可交付，不需要新 transport 抢主链。
• 412/UID/source health 的痛点是真实存在的，browser-side evidence 能提升判断质量。
• OpenBiliClaw 的扩展任务桥证明这个模式可产品化，但我们当前用 Playwright/脚本 POC 更稳，避免先背 extension 维护成本。
• Review Console 正好是人工审核/诊断入口，比把能力塞进 pipeline 默认 run 更合适。

决策

吸收内容：

• rendered search task bridge 的架构模式。
• B站 API 失败时的 browser-side 对照证据。
• 任务化、结构化 result、action log、artifact path。

不吸收内容：

• OpenBiliClaw 后端。
• OpenBiliClaw 浏览器扩展全量代码。
• Soul/推荐/候选池系统。
• 默认采集主链替换。

推荐实施顺序

1. 先实现 pipeline 侧 probe_bili_rendered_search.py fixture 版：无真实浏览器也能跑解析测试。
2. 再接 Review Console 后端任务：runtime fixture + action log + result_json，不写 Review Queue。
3. 做 1-2 个真实 source smoke：只验证分类/UID 候选，不要求产出 publishable。
4. 根据 smoke 决定是否进入 Phase 3 fallback adapter：默认先不要进。

证据来源

• 现有 Bili Review 控制台代码：/home/ht/.hermes/projects/bili-review-console/backend/app/services/task_service.py
• 现有 runtime adapter：/home/ht/.hermes/projects/bili-review-console/backend/app/services/runtime_adapter.py
• 现有 broad sample 配置：/home/ht/.hermes/projects/bili-tech-pipeline/config/broad_sample_sources.json
• 现有 pipeline adapter：src/adapters/up_feed.py、src/adapters/autocli_up_feed.py、src/adapters/base.py
• 现有测试：backend/tests/test_task_service_qa_fixture.py、backend/tests/test_task_service_regressions.py、tests/test_broad_sample_selection.py
• 既有 wiki：bili-412-optimization-with-playwright-sidecar-plan-2026-05-22.md、bili-review-console-and-source-pool-optimization-2026-05-22.md
• OpenBiliClaw 调研报告：https://decision.ht1072.top/2026-06-29-openbiliclaw-absorption-eval.html