feat(monitor): 抖音 Web 接口客户端 —— 绕开爬虫子进程，直接发 HTTP
移植自 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 带网关原话 / 正常返回）。
This commit is contained in:
@@ -0,0 +1,174 @@
|
||||
# AgentOS v2.0 审查与收口文档
|
||||
|
||||
最后更新：2026-04-28
|
||||
|
||||
## 1. 审查范围
|
||||
|
||||
本次审查只做一件事：把 AgentOS 的原形、当前实现、未来升级想法彻底拆开，收口成一个可执行的 v2.0 基准。
|
||||
|
||||
审查对象包括：
|
||||
|
||||
- 根目录说明文档
|
||||
- `00_bootstrap/` 初始化与部署脚本
|
||||
- `01_core/` 核心配置
|
||||
- `02_skills/` 当前已落地技能
|
||||
- `03_knowledge/` 知识库结构与收件箱流水线
|
||||
- `04_memory/` 记忆体与本地私有目录边界
|
||||
- `05_tools/` 工具层
|
||||
- `07_migration/` 迁移脚本
|
||||
|
||||
## 2. 审查结论
|
||||
|
||||
### 结论 A：当前仓库不是原形复刻，而是原形之后的第一阶段增强版
|
||||
|
||||
原形是一个单机优先、骨架优先、目录清晰的 AgentOS。
|
||||
|
||||
当前仓库已经在原形之上新增：
|
||||
|
||||
- `agent-os-local/` 本机私有目录
|
||||
- 软链接隔离（raw、vector_db、cache）
|
||||
- `collect_to_inbox` / `inbox_refine` 收件箱双阶段流水线
|
||||
- `content_processor` / `auto_collector` 等扩展技能
|
||||
- WorkBuddy managed Python / Node 运行时约束
|
||||
- MCP 与本地 LLM 运行时集成
|
||||
|
||||
因此，当前仓库应被定义为“v2.0 基准版”，而不是“原形本身”。
|
||||
|
||||
### 结论 B：主要问题是文档基线失真，不是代码主干先坏了
|
||||
|
||||
目前最大问题不是脚本无法运行，而是多个文档分别在描述不同阶段：
|
||||
|
||||
- 有的描述原形
|
||||
- 有的描述当前实现
|
||||
- 有的描述未来升级设想
|
||||
|
||||
结果是同一件事出现多套口径，尤其集中在：
|
||||
|
||||
- 版本号
|
||||
- 技能数量
|
||||
- 知识流入口
|
||||
- 记忆同步边界
|
||||
- `05_tools/` 与 `02_skills/` 的职责划分
|
||||
|
||||
### 结论 C：v2.0 需要冻结一条“当前可运行”的基准，而不是继续把 v2.1 设想混进来
|
||||
|
||||
v2.0 的目标不是把所有未来升级一次做完，而是把当前仓库收口成：
|
||||
|
||||
- 文档统一
|
||||
- 边界明确
|
||||
- 路径一致
|
||||
- 恢复流程明确
|
||||
- 延后项清楚标注
|
||||
|
||||
## 3. 核心发现
|
||||
|
||||
### 高优先级
|
||||
|
||||
1. 知识流入口存在两种合法路径，但之前没有被正式定义
|
||||
|
||||
- 路径一：内容已标准化，直接写入 `03_knowledge/00_inbox/`
|
||||
- 路径二：内容先落在分类目录，再由 `collect_to_inbox` 汇聚进 `00_inbox/`
|
||||
|
||||
此前文档把它写成互相冲突。v2.0 统一定义为“双入口汇聚到 Inbox”，不再视为矛盾。
|
||||
|
||||
2. `04_memory/` 与 `agent-os-local/` 的边界缺少一句话定义
|
||||
|
||||
v2.0 统一定义：
|
||||
|
||||
- 共享并可同步：`facts.db`、`daily_summaries/`、`logs/`
|
||||
- 本机私有：`long_term/raw/`、`vector_db/`、`06_runtime/cache/`
|
||||
|
||||
3. `05_tools/` 在原形中是空骨架，在当前实现中已经变成工具层
|
||||
|
||||
v2.0 统一定义：
|
||||
|
||||
- `02_skills/` 是 WorkBuddy 技能层
|
||||
- `05_tools/` 是底层公共工具层
|
||||
- 工具层中允许存在独立小项目，但不自动视为对话技能
|
||||
|
||||
### 中优先级
|
||||
|
||||
4. system/user 技能分类已成为架构约定，但尚未有统一元数据强制落地
|
||||
|
||||
v2.0 结论：保留该分类作为文档级约定，不在本版本强推 `SKILL_CARD.yaml`、`skill_scanner.py`。
|
||||
|
||||
5. `agent-os-local/materials/` 已经存在，但尚未成为系统主数据入口
|
||||
|
||||
v2.0 结论：
|
||||
|
||||
- 它是本机原始素材存储区
|
||||
- 它服务于工具层与后续升级
|
||||
- 它不作为 v2.0 的唯一入库入口
|
||||
|
||||
### 低优先级
|
||||
|
||||
6. 大体量说明文档信息很多，但不适合作为唯一基准
|
||||
|
||||
v2.0 结论：
|
||||
|
||||
- 保留该文件作为扩展历史说明
|
||||
- 以 `README.md`、`CORE-ARCHITECTURE.md`、本文件为正式基准
|
||||
|
||||
## 4. v2.0 最终定稿
|
||||
|
||||
### 4.1 当前基准
|
||||
|
||||
AgentOS v2.0 是一套运行在 WorkBuddy 上的本地优先个人智能体外骨骼系统，当前以以下结构为正式基准：
|
||||
|
||||
- `agent-os/`：同步与版本化的主仓库
|
||||
- `agent-os-local/`：本机私有数据区
|
||||
- `01_core/`：核心配置
|
||||
- `02_skills/`：技能层
|
||||
- `03_knowledge/`：Obsidian 知识库
|
||||
- `04_memory/`：共享记忆元数据与结构化事实
|
||||
- `05_tools/`：公共工具层
|
||||
- `06_runtime/`：任务记录与缓存挂载点
|
||||
- `07_migration/`：迁移与打包
|
||||
|
||||
### 4.2 目标表述
|
||||
|
||||
v2.0 的正式目标表述如下：
|
||||
|
||||
> AgentOS v2.0 不是“未来多机协同终态”，而是“当前仓库的稳定可运行基准版”。
|
||||
> 它保留原形的骨架清晰性，同时承认已经落地的本地私有层、收件箱流水线和工具层增强。
|
||||
> v2.0 的任务是冻结边界、统一口径、保证可恢复、为 v2.1 升级留出明确接口。
|
||||
|
||||
### 4.3 明确不纳入 v2.0 的内容
|
||||
|
||||
以下内容属于后续版本，不纳入本次收口：
|
||||
|
||||
- `collect_from_local.py` 本地素材统一提炼入口
|
||||
- `skill_scanner.py` 和统一技能身份证体系
|
||||
- `SKILL_CARD.yaml` 全量改造
|
||||
- `setup_tools.sh` 与工具 manifest 规范
|
||||
- 更细粒度的记忆多机隔离策略
|
||||
|
||||
## 5. 修改计划
|
||||
|
||||
### 已完成
|
||||
|
||||
1. 统一 v2.0 基准文档入口
|
||||
2. 固化审查结论
|
||||
3. 统一当前基准与目标表述
|
||||
4. 将历史大文档降级为参考资料
|
||||
|
||||
### v2.0 收口后可继续执行
|
||||
|
||||
1. 先做 `collect_to_inbox` 与 `content_processor` 的入口契约统一
|
||||
2. 再做 `agent-os-local/materials/` 到 `00_inbox/` 的新流水线
|
||||
3. 最后补技能元数据和工具 manifest
|
||||
|
||||
## 6. 使用原则
|
||||
|
||||
从本文件起，后续若出现文档冲突，按以下优先级理解：
|
||||
|
||||
1. `CORE-ARCHITECTURE.md`
|
||||
2. `README.md`
|
||||
3. `REVIEW-V2.0.md`
|
||||
4. 其他大体量说明文件
|
||||
|
||||
这意味着：
|
||||
|
||||
- 大说明文档用于补充背景
|
||||
- 正式口径以基准文档为准
|
||||
- 升级想法必须单独标注版本，不得直接混入 v2.0 基准
|
||||
Reference in New Issue
Block a user