素材工房 · 搜索优化 · 设计草案 v2
现在搜素材只有一条路:发起研究任务,agent 搜 TikTok、转存、逐条分析,几分钟后回来一批入库的样片。这份方案加两样东西:一个秒级返回的快速搜索(新 tobatsu workflow,跳过重活),和给现有搜索加更多平台源。
01 · 现状
material_board_preview_research_test 给 tobatsu2,agent 把 idea 翻译成关键词,调 TikHub 搜 TikTok。material_board_daily_crawl 用的是同一个搜索 skill(viral-trawler-test),所以源加在 skill 里,两条链路一起受益。02 · 方案总览
viral-trawler-test skill 里加 TikHub 其他平台端点:同一把 key、同一个返回结构,改动是文档级的。03 · 快速搜索
和完整链路相比,fast 这条路在拿到 TikHub 结果后就直接回调——没有 R2 转存、没有 Gemini 分析、没有入库。这三步正是分钟级耗时的来源,砍掉之后剩下的只有 agent 翻译意图和一次 HTTP 搜索。
| 步骤 | 完整搜索(现有 preview_research) | 快速搜索(新 fast_search) |
|---|---|---|
| 意图 → 关键词 | agent 翻译 | agent 翻译(同款逻辑) |
| TikHub 搜索 | 有 | 有,支持多源参数 |
| mp4 转存 R2 | 有(拿永久地址) | 无 — 展示用 share_url + 封面 |
| Gemini 视频分析 | 有(逐条看片写判断) | 无 — 只有平台自带的标题/数据 |
| 入素材库 | 6 条全入 hot_materials | 不入库,结果暂存展示 |
| 耗时(tobatsu 实测量级) | 分钟级 | p50 约 1–2 分钟;打包 runner 后可压到 30–60s(见下) |
| 结果去向 | 素材卡片,可直接加入成片 | 候选列表;勾选"转正"后走一次完整重活入库 |
| 档位 | 形态 | 端到端 | 说明 |
|---|---|---|---|
| 本期 | tobatsu workflow · agent 单轮 | p50 约 1–2 分钟,p95 3 分钟+ | 容器启动 + 排队 10–30s 是固定开销;agent 翻译意图 + 打 2–3 发 TikHub 30–90s |
| 优化 | 同 workflow,逻辑打包成 python runner,agent 只执行一条命令 | 30–60s 地板 | 去掉 LLM 自由发挥的不确定性;kamila 系已验证的模式 |
| 终局 | material-board 后端直调 TikHub(不经 tobatsu) | <5s | 只有明确 keyword+源时才成立;自然语言 brief 的翻译步在哪边都要 LLM。搜索核心从第一天就写成独立 .py,将来搬过去零重写 |
04 · 契约草案
material_board_fast_search,测试流量走 tag:"test",不再造 _test 复制品。st 上 creative 已经在用这个模式(TOBATSU_TASK_TAG),fast 沿用即可。viral-trawler-test skill(搜索端点手册就在里面),但逻辑打包成独立 python runner,agent 只执行一条命令——压耗时,也为将来搬后端直调留后路。// POST /tasks · task_type: material_board_fast_search + tag:"test"(测试流量) { "brief": "俄罗斯户外生存题材热梗,末世建造感", "sources": ["tiktok", "douyin"], // UI 源选择,缺省 ["tiktok"] "count": 20, // 每源 top 20,多源总 cap 50(一发=一次计费,翻页费用线性涨) "region": "US", // 可选 "callback_url": "https://sozai-st.../api/fast-search/:id/result", "callback_token": "..." }
{
"task_id": "...",
"mode": "fast_search",
"sources_searched": ["tiktok", "douyin"],
"per_source_counts": { "tiktok": 20, "douyin": 18 },
"failed_sources": [], // 部分源挂只降级,不整单失败
"candidates": [{
"source": "tiktok | douyin | youtube",
"id": "aweme_id / video_id", // 平台稳定 id,"转正"用
"title": "...",
"author": { "name": "...", "id": "..." },
"stats": { "plays": 0, "likes": 0, "comments": 0, "shares": 0 },
"duration_seconds": 34,
"share_url": "跳转用,稳定",
"cover_url": "封面 CDN,签名过期(小时~天级)",
"published_at": "ISO8601",
"search_meta": { "keyword": "...", "sort": "...", "cursor": 0 }
}]
}
material-board 侧新增:一个 fast-search 状态表(或复用 slot 加类型字段)、回调端点、结果面板 UI、以及"转正入库"按钮(对单条候选派一次现有的转存+分析)。具体表结构等 tobatsu 侧契约意见回来后定。
05 · 现有搜索加源
| 平台 | 可用端点 | 结果 | 说明 |
|---|---|---|---|
| TikTok | GET .../tiktok/app/v3/fetch_video_search_result | ✓ 200 | 现役对照组,不动 |
| 抖音 | POST .../douyin/search/fetch_video_search_v2 | ✓ 200 | 用这个;旧 app/v3 GET 是 TikHub 上游坏(400,非权限),skill 里标"勿用" |
| YouTube | GET .../youtube/web_v2/get_shorts_search(优先)+ 通用 web/search_video | ✓ 200 | 素材场景优先 shorts |
| 小红书 | web_v3/fetch_search_notes 等 | ✗ 403 | key 没开 XHS scope,要去 TikHub 后台开通/加购;开通前 UI 不放小红书或标"待开通" |
分页参数三平台三样,skill 端点表必须写死,不然 agent 翻页会瞎猜:TikTok 用 offset、抖音 v2 用 cursor(要回传 search_id)、YouTube 用 continuation_token。一个小尾巴:这次打的是 viral-trawler 本地 .env 的 key,和 tobatsu runtime-env 里那把大概率同一把,收尾时在容器里补一发确认。
| 步骤 | 做什么 | 改哪里 | 状态 |
|---|---|---|---|
| 1 · key 探测 | 实测各平台端点开通情况 | tobatsu 侧直打 TikHub | ✓ 已完成(见上表) |
| 2 · skill 加端点 | SKILL.md 加「平台端点表 + 每平台单独的响应→candidate 映射 + 分页语义」,含 id 前缀(dy_/yt_)、source 显式标注;抖音 v2 的 aweme 结构与 TikTok 相近但统计字段名有差,YouTube shorts 完全另一套要单独 parse | viral-trawler-test(纯文档改动,workflow 零改) | 可以开做 |
| 3 · 源参数透传 | UI 源选择跟着研究任务一起传,agent 按 sources 挑端点;不传维持 TikTok 缺省 | material-board 派发 inputs + skill 里的路由指导 | 随 fast 搜索一起做 |
-test 版 → st 真机 smoke → 拷到 prod 版 viral-trawler。06 · 环境与开放问题
material_board_preview_research_test)。TOBATSU_TASK_TAG="test" 只影响 creative 阶段(发裸名 + tag),搜索和 delivery 不受影响。material_board_fast_search,st 派发时带 tag:"test" 区分测试流量(tobatsu2 推荐姿势,creative 已在用),不再造 _test 复制品;UI 改动只发 st——test/prod 零感知。