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 带网关原话 / 正常返回）。

mac-agent-os-main/90_archive/10_next_version_discussion/讨论清单.md

@@ -0,0 +1,193 @@
+# AgentOS vNext 讨论清单（2026-04-28）
+
+## 一、待细化/待确认的核心议题
+
+1. 向量库（vector_db）
+   - 本地与全局的分工与同步机制
+   - 向量库与知识内容的分离/融合方式
+   - 多机向量同步的安全性与一致性
+2. 主机/维护机标识与权限体系
+   - 主机唯一ID生成与管理
+   - 主维护机的指定、切换与权限
+   - 多机协同下的角色分工与冲突解决
+3. 知识库分类体系
+   - 多级分类、标签体系的设计与落地
+   - 领域/属性/标签的扩展与动态调整机制
+   - 个人笔记、项目过程、记忆固化等特殊内容的归档策略
+4. 工具与技能的边界与互转
+   - 工具与技能的定义、加载机制
+   - CLI工具与自动化技能的互转标准
+   - 何时应将工具升级为技能，反之亦然
+5. 本机数据说明与动态更新
+   - 本机环境、硬件、软件、网络等数据的结构化存储
+   - 自动/手动更新机制与token效率
+   - 变更追踪与历史记录
+6. 同步/备份机制
+   - agent-os 与 agent-os-local 的同步策略
+   - 备份粒度、频率、冲突解决
+   - 多机间的增量同步与恢复流程
+7. 项目过程与知识归档的分离与融合
+   - 项目文档、过程记录与最终知识的转化机制
+   - 归档标准与自动化流程
+8. 自动化任务与定时调度体系
+   - 任务注册、启停、调度与监控
+   - 多机环境下的任务分发与容错
+9. 其他（请补充）
+
+---
+
+## 二、任务细化清单（可持续补充）
+
+- [ ] 设计向量库本地/全局结构与同步流程
+- [ ] 制定主机/维护机标识与权限管理方案
+- [ ] 优化知识库多级分类与标签体系
+- [ ] 明确工具与技能的互转标准与流程
+- [ ] 设计本机数据说明的结构与自动更新机制
+- [ ] 规划同步/备份的详细策略与实现步骤
+- [ ] 梳理项目过程与知识归档的转化流程
+- [ ] 设计自动化任务调度与监控体系
+- [ ] ...（后续补充）
+
+---
+
+## 三、讨论方向与预期（AI建议）
+
+### 1. 全局视角
+- 以“多机协同+知识自进化”为核心，兼顾效率、可维护性与安全性
+- 强化自动化与智能化，减少人工干预
+- 结构化、标准化、可追溯，便于后续扩展
+
+### 2. 细化建议
+- 每个议题可单独开子文件夹，沉淀方案、流程图、决策记录
+- 充分讨论后再进入开发，避免反复返工
+- 关键机制（如同步、权限、归档）优先原型验证
+
+### 3. 预期目标
+- 明确每一项机制的“为什么/做什么/怎么做/如何验证”
+- 形成可落地的设计文档与任务分解
+- 逐步推进，阶段性评审与复盘
+
+---
+
+## 四、AI补充的全方位思考方向（供参考）
+
+- 多机协同下的数据一致性与冲突解决最佳实践
+- 向量化知识检索的安全性与隐私保护
+- 个人与全局知识的边界与流转机制
+- 自动化任务的容错与自愈能力
+- 系统可观测性与监控体系建设
+- 版本管理与历史追溯的自动化
+- 用户体验与交互流程优化
+- 跨平台兼容性与迁移策略
+- ...（持续补充）
+
+---
+
+## 【2026-04-28 本机标识与角色机制简化方案】
+
+- 每台机器只需配置一个唯一“主机名”或“身份名”，如：`my-macbook_macOS14.4_16GB_master`。
+- 名字建议包含：
+  - 设备自定义名（如 my-macbook）
+  - 系统版本（如 macOS14.4）
+  - 内存（如 16GB）
+  - 当前角色（如 master/maintainer）
+- 例如：`office-pc_Win11_32GB_maintainer`
+- 这样可一眼识别本机情况，角色切换只需手动改名，无需复杂权限体系。
+- 适合个人和小规模多机协同，简单高效，易于维护。
+
+---
+
+## 【2026-04-28 工具与技能边界、互转与迁移机制补充】
+
+- 工具本身较重，依赖复杂环境，协同目录（如 agent-os/tools/）只同步“安装命令”“入口脚本”或“适配说明”，不直接同步所有依赖和环境。
+- 本地目录（agent-os-local/tools/）实际存放可执行脚本、依赖包、环境配置，确保工具能在本机落地运行。
+- 工具通过“标准化包装/描述文件”（如 TOOL_CARD.yaml），描述依赖、安装方式、适配平台、入口命令等，便于自动化部署和技能注册。
+- 支持“环境检测/自动适配”脚本，自动判断本地依赖是否齐全，缺失时友好提示或一键安装。
+- 技能本质是轻量化自动化脚本，调用本地已落地的工具，负责流程编排、输入输出标准化。
+- 工具与技能通过“标准化描述+适配层”灵活互转，协同目录轻量化，同步高效，落地灵活。
+- 工具卡和环境适配脚本为后续系统迁移、全量/部分备份、跨平台部署提供基础，迁移时只需同步描述和适配脚本，目标机自动完成环境适配和工具落地。
+
+> 工具卡与环境适配机制将在“同步/备份机制”章节详细展开。
+
+---
+
+## 【2026-04-28 本机数据说明机制补充】
+
+- 本机数据说明即“本机环境知识库”或“本机环境清单”，用于记录本机的硬件、系统、网络、环境变量、专用配置等关键信息。
+- 主要作用：
+  - 让智能体/程序快速识别本机情况，避免每次都重新检测。
+  - 便于记忆系统、自动化脚本、技能等直接读取和复用本机环境信息。
+  - 记录本机专属设置（如内存大小、特殊端口、独有依赖等），不参与多机协同，仅本机使用。
+- 建议存储为结构化文件（如 environment.yaml、machine_info.json），并定期/按需自动更新，或手动补充特殊项。
+- 可作为记忆系统的一个专属分支，便于后续检索和自动化调用。
+
+---
+
+## 【2026-04-28 项目过程与知识归档的分离与融合机制补充】
+
+- 项目过程、想法、实验性工具等内容，初期只保存在本机或本机项目知识库，支持高频变更和个性化探索。
+- 当项目或工具开发进入“转正”阶段（即具备通用价值、可协同复用）：
+  1. 在本机完成最终打包或生成安装脚本。
+  2. 通过“收件箱”机制，将打包文件、安装脚本、说明文档等统一提交到协同目录的专用收件箱（如 agent-sync/03_knowledge/00_inbox/projects/）。
+  3. 普通节点仅有提交权限，主机/维护机负责审核、验收和归档。
+  4. 主机/维护机审核通过后，将工具/项目内容正式迁移到协同目录的工具区（如 agent-os/05_tools/），并将相关知识、说明文档归档到知识库（如 agent-sync/03_knowledge/）。
+  5. 归档时添加元数据（如来源、归档时间、版本、作者等），便于追溯和管理。
+- 只有经过“收件箱-审核-归档”流程的内容，才会同步到多机协同，成为所有节点认可的“公共工具/知识”。
+- 未归档内容仅在本机或主机流转，避免半成品、实验性内容干扰全局协同。
+- 支持“项目过程-知识归档-全局共享”全流程的元数据记录，便于后续追溯和复盘。
+
+> 该机制确保项目内容从本地探索到全局协同的转化过程有据可查、权限清晰、流程严谨。
+你的思路非常清晰，补充总结如下：
+
+---
+
+## 【2026-04-28 自动化任务与定时调度体系补充】
+
+- 自动化任务（如记忆压缩、知识提炼、信息抓取等）在多机协同的同步目录中统一管理，每台主机都能获取完整任务清单。
+- 每台主机根据自身“主机名/角色”有选择性地启用相关任务：
+  - 普通主机只启用本地记忆压缩、体验类任务。
+  - 知识库管理主机启用知识提炼、归档、同步等核心任务。
+  - 特殊主机可启用自动抓取、外部采集等定制任务。
+- 任务启用逻辑简单高效：只需在任务配置中标明适用角色或主机名，系统自动判断是否执行。
+- 不做复杂的分发、容错、调度体系，单机/小规模协同下以“角色驱动”实现任务分工，灵活易维护。
+- 如后续有多用户/大规模协同需求，可再扩展任务分发、容错等机制。
+
+---
+
+你的方案已非常适合个人和小团队场景，简单高效，易于落地和维护。如需，我可以帮你设计任务配置模板或角色-任务映射示例。
+
+---
+
+# 【2026-04-28 最新讨论补充】本地/全局记忆与知识库、向量库、同步机制设计
+
+## 1. 目录与同步边界
+- `~/workbuddy-agent-os/agent-sync/`：所有内容都参与多机同步（知识库、协同收件箱、协同向量库等）。
+- `~/workbuddy-agent-os/agent-sync/agent-local/`：所有内容仅本机保存，绝不参与同步（本地记忆、个人笔记、本地素材等）。
+
+## 2. 数据流转与提炼机制
+1. **本地记忆/个人笔记产生**  
+   - 存在于 `~/workbuddy-agent-os/agent-sync/agent-local/materials/`，如记忆系统自动提存、个人随手笔记等。
+2. **记忆/笔记提炼**  
+   - 用户可手动或自动将有价值的内容，从 `~/workbuddy-agent-os/agent-sync/agent-local/materials/` 提取到 `~/workbuddy-agent-os/agent-sync/03_knowledge/00_inbox/`（协同收件箱）。
+   - 提取时可加属性（如“记忆”标签），以便后续分类。
+3. **知识库入库**  
+   - 协同收件箱只存 md 文件，知识管理系统定期/手动将内容加工、分类，正式入库到知识库（如 10_concepts、20_methods 等）。
+
+## 3. 向量数据库设计
+- **本地向量库**：`~/workbuddy-agent-os/agent-sync/agent-local/` 下的所有内容（记忆、个人笔记等）向量化，仅本机检索。
+- **协同向量库**：`~/workbuddy-agent-os/agent-sync/` 下知识库内容向量化，参与多机同步和协同检索。
+- 检索时，默认先查本地向量库，再查协同向量库，结果合并展示，体验无割裂。
+
+## 4. 分类与属性
+- 协同收件箱和知识库的 md 文件可通过 frontmatter 或标签标明来源（如“记忆提存”、“个人笔记”），方便后续分类和检索。
+- 知识库分类可灵活调整，不必强依赖文件名。
+
+## 5. 机制总结
+- 本地内容完全隔离，隐私安全。
+- 有价值内容通过“提炼-收件箱-知识库”机制流转，保证协同知识的高质量和结构化。
+- 多机协同时，检索体验顺畅，既能查本地记忆，也能查全局知识。
+
+---
+> 本节为 2026-04-28 讨论结论，后续如有新机制/细节调整请在此基础上补充。
+
+---