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 带网关原话 / 正常返回）。
117 lines
3.9 KiB
Markdown
117 lines
3.9 KiB
Markdown
---
|
||
id: KB-SYS-ARCH
|
||
title: "AgentOS 加载与检索架构"
|
||
type: reference
|
||
status: active
|
||
nature: reference
|
||
domain: personal-management
|
||
subdomain: [系统设计]
|
||
tags: [架构, 加载, 检索, 向量, token优化]
|
||
confidence: 1.0
|
||
date_created: 2026-05-03
|
||
date_modified: 2026-05-03
|
||
version: 1
|
||
---
|
||
|
||
# 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|触发词匹配方案对比分析]]
|