butubb/MediaCrawler

Fork 0

Files

T

butubb 2112c1a870

Deploy VitePress site to Pages / build (push) Canceled after 0s

Details

Deploy VitePress site to Pages / Deploy (push) Canceled after 0s

Details

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

2026-10-10 17:12:25 +08:00

3.9 KiB

Raw Blame History

id, title, type, status, nature, domain, subdomain, tags, confidence, date_created, date_modified, version

title

type

status

nature

domain

subdomain

AgentOS 加载与检索架构

版本：v1.0 | 最后更新：2026-05-03 本文档描述 AgentOS 的四条独立加载/检索管道及其协作方式。

一、核心设计原则

不同类型的信息，用不同的方式加载。不混在一起，不相互干扰。

行为控制层（身份+协议）→ 不走向量检索，靠注入和触发词
内容检索层（知识+记忆）→ 走向量检索，靠语义匹配

二、四管道架构

管道①：身份注入（常驻）

属性	值
文件	SOUL.md + IDENTITY.md + USER.md
存储	`~/.workbuddy/`
加载方式	WorkBuddy 每次对话启动时自动注入
Token 占用	~750（常驻）
是否走向量	❌ 不走向量检索
内容	行为规则、模式切换、安全边界、身份、用户画像

管道②：协议按需加载（触发词激活）

属性	值
文件	meta-thinking.md / cross-domain.md / stuck-intervention.md / knowledge-review.md
存储	`03_knowledge/99_system/protocols/`
加载方式	SOUL.md 检测触发词后读取对应文件，执行完退出
Token 占用	每个 ~200（用完即退）
是否走向量	❌ 不走向量检索（存放在 99_system/，不参与知识搜索）
触发机制	当前：关键词匹配 → 可升级为语义相似度匹配

管道③：知识库语义检索（按需搜索）

属性	值
目录	`03_knowledge/`（排除 99_system/）
内容	概念知识 (10_concepts/)、方法论 (20_methods/)、参考资料 (40_references/)
检索方式	BM25 关键词 + ChromaDB 语义向量 + RRF 融合排序
向量模型	Qwen3-Embedding-0.6B（1024 维）
是否常驻	❌ 不常驻，用户提问时按需检索
负责技能	kb_manager

管道④：记忆系统分层检索（自动触发）

属性	值
目录	`04_memory/`
检索流程	L1 → L2 → L3 分层截断
L1	keyword_index.json + ChromaDB 向量 → 关键词+语义混合检索
L2	facts.db（SQLite 结构化事实，置信度 ≥ 0.7 才返回）
L3	raw 原文存档（仅用户明确要求时才加载）
截断规则	L1 无匹配 → 停止；L2 置信度不足 → 不 fallback
负责技能	memory_manager

三、数据流图

用户输入
    │
    ├─→ 管道①（身份注入已常驻）→ 行为规则已就位
    │
    ├─→ SOUL.md 检测触发词
    │     ├─ 命中 → 管道②：加载对应协议文件 → 执行 → 退出
    │     └─ 未命中 → 继续工程模式
    │
    ├─→ 用户询问知识 → 管道③：BM25+ChromaDB 检索知识库
    │
    └─→ 用户提问触发记忆 → 管道④：L1→L2 分层检索

四、Token 优化策略

策略	实现	节省效果
分层截断	L1 无匹配立即停止	避免整库扫描
置信度阈值	L2 < 0.7 不返回	避免低质量事实占用 context
协议退出	协议文件用完即退出上下文	每个协议 ~200 tokens 不持续占用
L3 延迟加载	仅用户明确要求才加载	最大节省（原文通常很大）
按需加载	知识库检索只返回片段	避免全文件读取
99_system 排除	系统文档不参与向量检索	减少搜索噪音

五、触发词匹配：关键词 vs 语义相似度

见 99_system/architecture/trigger-matching-analysis

3.9 KiB Raw Blame History Unescape Escape