移植自 mac-agent-os 的 mediacrawler_adapter:不起子进程、不开页面,用浏览器里那份
登录态直接调抖音 Web 接口。产物键名照抄 store/douyin,所以 ingest 那条链路一个字不用改。
**目前能用的(真环境实测,非推断)**:
profile/other : 200, 7075 字节 —— 博主主页指标(粉丝/获赞/作品数/昵称)
aweme/detail : 200, 45425 字节 —— 单条作品详情(含点赞/评论/收藏/分享)
**目前不能用的:作品列表 `aweme/post`。** 两个互相独立的原因:
1. 这个接口被抖音单独升级成了真校验:不带 x-tt-argus 回 403「Uifid Not Found」,
带上 dummy 值回 200 + **空 body**。也就是说「头在不在」骗得过,「真校验」过不了。
同一套头打 profile/other 和 aweme/detail 都是通的 —— 抖音是挑着接口加保护的,
挑中的恰好是「批量拉作品列表」这个最敏感的动作。
2. 改走页面截获也不行:CDP 浏览器打开博主主页会落到「验证码中间页」(当天大量探测的
代价,过几小时要重测)。
所以现在的边界是:**已知作品的指标刷新能做,自动发现新作品做不了**。
**排查中控住变量后得到的两条事实**(都写进注释了):
· `Accept` / `Accept-Language` / `Referer` 才是主页接口能返回真数据的原因 —— 只有
UA+client hints+Cookie 时是 200 但仅 121 字节的空壳,补上这三个头变 7074 字节。
(我先前猜的 sec-ch-ua 不是关键。)
· 因此 UA 与 client hints 必须**成套地取自同一个浏览器**,所以 BrowserIdentity 一次
从 CDP 取齐 cookie + UA + hints,而不是各自写死。
「200 + 空 body 必须当场报错」也是刻意写死的:放过去它会在下游变成「这个博主没作品」,
把一次失败伪装成一条正常结果 —— 爬虫那条路正是这么栽的,还被翻译成「账号被封」。
测试 +11:cookie 解析、请求头成套性(含 uifid 缺失/回退)、产物键名与 store 对齐、
以及 _get 的三条失败路径(空 body / 403 带网关原话 / 正常返回)。
68 lines
2.3 KiB
Markdown
68 lines
2.3 KiB
Markdown
# Dashboard 集成审计报告
|
||
|
||
> 日期: 2026-06-27 | 基于当前代码状态
|
||
|
||
## 执行路径总览
|
||
|
||
```
|
||
前端视图 → POST /api/ops/run {type, accounts, params}
|
||
→ CommandBus.dispatch()
|
||
→ 按机器分组
|
||
→ _send_local() / _send_remote()
|
||
→ guardd /scheduler/submit (新路径 ✅)
|
||
→ guardd /task (旧路径降级)
|
||
→ subprocess / SSH (最终降级)
|
||
```
|
||
|
||
## 各视图集成状态
|
||
|
||
### ✅ 已走新路径(CommandBus → guardd 调度引擎)
|
||
|
||
| 视图 | 操作类型 | 提交方式 |
|
||
|:-----|:---------|:---------|
|
||
| `matrix-accounts.js` | collect, login | `fetch('/api/ops/run')` → 新路径 |
|
||
| `matrix-collect.js` | collect | `apiRequest('/api/ops/run')` → 新路径 |
|
||
| `matrix-nurture.js` | nurture | `apiRequest('/api/ops/run')` → 新路径 |
|
||
| `matrix-comment.js` | comment | `apiRequest('/api/ops/run')` → 新路径 |
|
||
| `matrix-interact.js` | interact | `apiRequest('/api/ops/run')` → 新路径 |
|
||
| `matrix-like.js` | like | `apiRequest('/api/ops/run')` → 新路径 |
|
||
| `ops-command.js` | 联邦指挥台 | 读 `/api/ops/queue` + `/api/ops/machines` |
|
||
|
||
### 🔶 需要注意的点
|
||
|
||
| 问题 | 说明 |
|
||
|:-----|:------|
|
||
| **账号管理页采集不显示在指挥台** | 已修复: `_send_local()` 优先走 scheduler,旧路径降级 |
|
||
| **指挥台只读不写** | 目前指挥台只能"看"不能"操作"(Phase 3a 实现) |
|
||
| **旧 `/task` 路径仍保留** | 作为降级方案,guardd 不可用时自动 fallback |
|
||
| **nurture_runner.sh 未集成到调度器** | 养号任务仍走旧 nurture_runner.sh 路径(通过 /task 降级) |
|
||
|
||
### ⏳ 待实现(Phase 3)
|
||
|
||
| 功能 | 优先级 |
|
||
|:-----|:-------|
|
||
| 指挥台操作按钮(取消/暂停/重排) | P0 |
|
||
| 告警中心(封号/登录失败高亮) | P1 |
|
||
| 三级接力 | P2 |
|
||
| 任务超时熔断自动恢复 | P1 |
|
||
|
||
## 当前数据流
|
||
|
||
```
|
||
用户点击"采集"
|
||
↓
|
||
matrix-accounts.js → POST /api/ops/run
|
||
↓
|
||
CommandBus.dispatch("collect", [account_id], params)
|
||
↓
|
||
_send_local() → guardd /scheduler/submit
|
||
↓
|
||
guardd scheduler → 15s循环 → executor.execute()
|
||
↓
|
||
指挥台每15秒 poll /api/ops/queue → 看到任务
|
||
```
|
||
|
||
## 测试方法
|
||
|
||
在账号管理页点"采集" → 等15秒 → 刷新指挥台 → 应该能看到任务出现在队列中
|