butubb
2112c1a870
移植自 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 带网关原话 / 正常返回）。
9.7 KiB
9.7 KiB
AgentOS 核心业务架构 v4.0 — 业务领域划分与指挥体系
版本: 4.0 | 更新: 2026-06-17
解决的核心问题: 账号管理 vs 操作执行边界模糊、指挥链路不清晰、结果回传缺失
一、核心原则（先理解这个）
┌──────────────────────────────────────────────────────┐
│ USER │
│ (Dashboard / AI Agent / CLI) │
└──────────┬────────────────────────────────┬───────────┘
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────────────────┐
│ 🪪 账号管理层 │ │ ⚡ 操作执行层 │
│ │ │ │
│ 只看不操作 │ │ 只操作不看 │
│ - 查看账号列表 │ │ - 养号（日常活跃） │
│ - 查看状态 │ │ - 信息采集 │
│ - 注册/删除 │ │ - 内容发布 │
│ - 跨机分配 │ │ - 定向评论 │
│ - 编辑配置 │ │ - 收藏点赞 │
│ │ │ - 登录/登出 │
└──────────────────────┘ └──────────┬───────────────┘
│
▼
┌──────────────────┐
│ 统一执行引擎 │
│ mc run / mc ops │
└──────────────────┘
关键约束（解决了用户的困惑）：
- 账号管理 = 只读 + 配置。它显示账号的登录状态、Cookie 有效性、昵称、上次采集时间，但不触发任何操作。
- 信息采集是操作，不是管理。采集应该放在「操作执行层」作为一个独立的操作类型，不应该混在账号管理里。
- 所有操作走统一指挥体系。无论是养号、采集、发布、评论，底层都走同一个执行引擎，只是参数不同。
二、业务领域划分
领域 1：账号管理 🪪 — "只看不操作"
| 功能 | 说明 | API |
|---|---|---|
| 账号列表 | 显示所有账号（跨机聚合）+ 登录状态 + Cookie状态 + 昵称 | GET /api/matrix/accounts |
| 注册账号 | 在本机或指定机器创建新账号 | POST /api/matrix/accounts |
| 删除账号 | 删除账号 + 可选删除身份目录 | DELETE /api/matrix/accounts/{id} |
| 编辑账号 | 修改 phone / platform / owner_machine | PUT /api/matrix/accounts/{id} |
| 跨机分配 | 将账号从一个机器移到另一个 | POST /api/matrix/accounts/{id}/relocate |
| 身份管理 | 查看/编辑身份目录 | POST /api/matrix/identities |
当前状态: 这部分已有完整前后端，需要的是和采集解耦。
领域 2：操作执行 ⚡ — "只操作不看"
所有操作共享相同的执行基础设施：
All Ops → POST /api/ops/run → 自动路由(本机subprocess/远程SSH) → 执行 → 写结果文件
↓
GET /api/ops/status ← 轮询结果
GET /api/ops/results ← 获取结果
GET /api/ops/log/{id} ← 查看日志
操作类型清单
| 操作 | 命令 | 蓝图 | 说明 |
|---|---|---|---|
| 🏃 养号执行 | mc run --accounts=X --blueprints=Y |
douyin_daily / xhs_daily | 浏览、滑动、点赞、关注等日常活跃 |
| 📡 信息采集 | mc collect |
— | 采集账号主页信息（昵称/粉丝数/作品数） |
| 📤 内容发布 | mc publish |
— | 发布视频/图文到已登录账号 |
| 💬 定向评论 | mc task comment |
— | 在指定作品下发表评论 |
| ❤️ 收藏点赞 | mc task like/favorite |
— | 对指定内容点赞/收藏 |
| 🔑 登录/登出 | mc smart-login / mc account logout |
— | 管理账号登录态 |
关键设计：所有操作通过 POST /api/ops/run 这一个入口，用 type 参数区分操作类型。
三、统一指挥体系（解决了"一台指挥三台"的问题）
3.1 当前架构（已实现）
Dashboard → /api/ops/run
→ 解析 type + accounts + params
→ 按 owner_machine 路由到各机器
→ 本机: subprocess.Popen → nurture_runner.sh
→ 远程: SSH → remote_exec → nurture_runner.sh
→ 结果写入: ~/agent-local/runtime/ops/{type}_{timestamp}_{account}.json
3.2 同一个 API 处理所有操作
POST /api/ops/run
{
"type": "nurture"|"collect"|"publish"|"comment"|"like",
"accounts": ["douyin_01", "xhs_01"],
"params": {
"blueprint": "douyin_daily", // 仅 nurture 用
"rounds": 10, // 仅 nurture 用
"url": "...", // 仅 comment/like 用
"content": "..." // 仅 comment 用
},
"machine": "", // 可选，自动路由
"dry_run": false
}
返回值：
{
"status": "started",
"ops": [
{"account": "douyin_01", "run_id": "nurture_123_douyin_01", "machine": "chengzigedeAir"},
{"account": "xhs_01", "run_id": "nurture_124_xhs_01", "machine": "7kecheng"}
]
}
3.3 结果回传（已实现）
每台机器执行完后写入:
~/agent-local/runtime/ops/{type}_{ts}_{account}.json
Dashboard 统一查询:
GET /api/ops/results?type=nurture&limit=10
GET /api/ops/status
GET /api/ops/log/{run_id}
跨机结果聚合：
- 本机结果：直接读本地文件
- 远程结果：Dashboard 通过 HTTP 轮询远程机器的
/api/ops/results端点
四、Dashboard 导航视图设计（新方案）
📱 矩阵
├── 🪪 账号管理 ← 只读 + 注册/删除/跨机 (原 sms-proxy)
├── 🏃 养号执行 ← 日常活跃 (原 nurture)
├── 📡 信息采集 ← 采集主页信息 (原 collect)
├── 📤 内容发布 ← 发作品 (原 publish)
├── 💬 定向评论 ← 评论 (原 comment)
├── ❤️ 收藏点赞 ← 点赞收藏 (新建)
├── 📋 蓝图管理 ← 编排原子操作 (原 blueprints)
├── 🔑 登录管理 ← 查看/管理登录态 (新建)
└── ⏱ 定时任务 ← 定时执行以上任何操作 (原 schedule)
「账号管理」只做这些： ✅ 查看所有账号（三机聚合） ✅ 显示昵称 / 手机号 / 登录态 / Cookie状态 / 上次采集时间 ✅ 注册新账号 ✅ 删除账号（可选删身份目录） ✅ 编辑账号（改平台/机器/备注） ✅ 跨机迁移
❌ 不做：信息采集、养号执行、评论、发布（这些归到对应的操作视图）
五、「联邦指挥台」概念
一个独立的指挥视图，统一操作入口：
┌──────── 联邦指挥台 ────────┐
│ │
│ 目标机器: [▼全部/本机/7k] │
│ 操作类型: [▼养号/采集/...] │
│ 账号筛选: [按平台/机器...] │
│ 参数设置: [轮数/蓝图...] │
│ │
│ [🚀 批量执行] │
│ │
│ 执行记录: │
│ ┌──────────────────────┐ │
│ │ 12:30 douyin_01 ✅ 完成│ │
│ │ 12:30 xhs_01 ⏳ 执行│ │
│ │ 12:28 douyin_02 ❌ 失败│ │
│ └──────────────────────┘ │
└────────────────────────────┘
但这不替代各操作专用视图。专用视图提供更多操作特定参数（比如评论要有内容输入框、发布要有文件上传）。联邦指挥台用于快速批量操作。
六、执行计划（按此逐步落地）
Phase 1（当前阶段）：统一 ops API + 结果追踪
| # | 事项 | 状态 |
|---|---|---|
| 1 | 账号管理解除采集耦合 | 🔴 待做 |
| 2 | POST /api/ops/run 统一入口 |
🟡 部分（已做 nurture） |
| 3 | GET /api/ops/results 结果查询 |
✅ 已实现 |
| 4 | GET /api/ops/status 状态查询 |
✅ 已实现 |
| 5 | GET /api/ops/log/{id} 日志查看 |
✅ 已实现 |
Phase 2：各操作视图完善
| # | 事项 | 优先级 |
|---|---|---|
| 1 | 信息采集视图（独立于账号管理） | P0 |
| 2 | 收藏点赞视图（新建） | P1 |
| 3 | 登录管理视图（查看+批量登录） | P1 |
| 4 | 联邦指挥台（统一批量操作入口） | P2 |
Phase 3：跨机结果聚合
| # | 事项 | 优先级 |
|---|---|---|
| 1 | 远程机器结果通过 HTTP 聚合到本机 Dashboard | P1 |
| 2 | 联邦指挥台显示所有机器的执行历史和状态 | P2 |