butubb/MediaCrawler
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

feat(monitor): 抖音 Web 接口客户端 —— 绕开爬虫子进程，直接发 HTTP
Deploy VitePress site to Pages / build (push) Canceled after 0s
Details
Deploy VitePress site to Pages / Deploy (push) Canceled after 0s
Details

Browse Source 
移植自 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:
butubb
2026-10-10 17:12:25 +08:00
parent 21ff01b894
commit 2112c1a870
1601 changed files with 367425 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
mac-agent-os-main/90_archive/docs/AgentOS-完整说明文档_副本.md
+30
View File
@@ -0,0 +1,30 @@
# AgentOS 历史说明文档已归档
最后更新：2026-04-28
本文件原先承载的是一份大体量扩展说明，现已归档，不再作为 AgentOS v2.0 的正式基准。
## 当前正式入口
请优先查看：
1. `CORE-ARCHITECTURE.md`
2. `V2.0-SUMMARY.md`
3. `QUICKSTART.md`
4. `REVIEW-V2.0.md`
## 历史归档位置
完整历史内容已移动到：
- `90_archive/docs/AgentOS-完整说明文档_副本.v2.1-history.md`
## 说明
归档原因不是内容无价值，而是其中混合了：
- 原形信息
- 当前实现信息
- 后续升级设想
为避免继续与 v2.0 基准冲突，现仅作为历史备忘保留。
mac-agent-os-main/90_archive/docs/AgentOS-完整说明文档_副本.v2.1-history.md
+1318
View File
File diff suppressed because it is too large Load Diff
mac-agent-os-main/90_archive/docs/AgentOS-知识管理系统说明文档.md
+721
View File
@@ -0,0 +1,721 @@
# AgentOS 知识管理系统 —— 设计说明与操作指南
> **版本**：v1.0
> **最后更新**：2026-04-28
> **知识库路径**：`~/workbuddy-agent-os/agent-sync/03_knowledge/`（Obsidian Vault）
> **面向读者**：需要了解本系统设计思路、分类逻辑、目录结构、工作流程的协作者
---
## 一、系统定位与设计理念
### 1.1 这是什么？
AgentOS 知识管理系统是一套**自动化知识采集→分类→归档→检索**的完整解决方案。它不是一个简单的文件分类目录，而是一个具有以下特征的**智能知识加工流水线**：
| 特征 | 说明 |
|------|------|
| **自动采集** | 多平台信息源（B站/YouTube/小红书/抖音/RSS/网页）24h 自动抓取 |
| **智能分类** | 本地 LLM + 启发式规则自动判定知识的属性和领域 |
| **标准化归档** | 每条知识都有统一的 Frontmatter 元数据、唯一 ID、版本链 |
| **版本化管理** | 知识可进化（观点→事实、方法升级），旧版本自动保留 |
| **语义检索** | BM25 + 向量混合检索，用自然语言找到知识 |
| **双轨同步** | 坚果云实时同步 + Git 版本控制，跨设备安全可用 |
### 1.2 核心设计原则
1. **知识属性优先于内容类型**：不看"这是篇文章还是张图片"，而看"这是事实、方法、还是观点"
2. **两级分类正交设计**：**nature（知识属性）** 决定"放在哪个层"，**domain（领域）** 决定"属于哪个学科"，两者互不干扰
3. **英文目录 + 中文映射**：目录名用英文（跨平台兼容、无乱码风险），通过配置文件提供中文别名
4. **收件箱缓冲机制**：新内容不直接归档，先进入收件箱缓冲，由定时任务统一提纯
5. **自动化优先**：每日凌晨自动完成：收集→汇聚→提纯→归档→更新统计，人工干预最少化
---
## 二、目录结构总览
```
03_knowledge/
├── 00_inbox/ # 📥 收件箱（缓冲区，所有新内容先进这里）
├── 01_daily/ # 📅 日记（每日记录、闪念笔记）
├── 10_concepts/ # 💡 概念层（原子概念、公理、知识卡片）
├── 20_methods/ # 🔧 方法层（教程、最佳实践、操作步骤）
├── 30_facts/ # 📋 事实层（客观事实、法规、数据）
├── 40_references/ # 📎 参考层（论文、文档、外部资料）
├── 50_resources/ # 🛠 资源层（视频笔记、阅读笔记、灵感素材等原始收集物）
├── 60_opinions/ # 💭 观点层（主观看法、引用、推测）
├── 90_archive/ # 🗄 归档层（已过时或废弃的知识）
├── 99_system/ # ⚙️ 系统层（模板、分类表、提示词——不是知识内容）
│ ├── templates/ # 知识卡片模板（4种）
│ ├── taxonomies/ # 分类配置（领域表 + 属性表 + 中文映射）
│ ├── prompts/ # LLM 分类提示词
│ └── timelines/ # 知识版本时间线图（自动生成）
├── README.md # 知识库首页（统计 + 导览）
└── CHANGELOG.md # 知识库变更日志
```
### 2.1 为什么这样分目录？
目录按**知识属性（nature）** 分层，每个数字前缀代表一个"知识层级"：
| 目录 | 前缀 | 为什么设这个目录 | 里面放什么 |
|------|------|------------------|------------|
| `00_inbox` | 00 | **缓冲区**：新内容需要统一处理后才能精确分类，直接丢进来避免"不知道放哪"的决策负担 | 所有新采集/新收集的原始内容 |
| `01_daily` | 01 | **时间维度**：有些知识是"某天的记录"，有强时间属性，不适合按属性分类 | 日记、闪念笔记、每日总结 |
| `10_concepts` | 10 | **知识原子**：概念是知识的"基本粒子"，其他知识都建立在概念之上 | 概念定义、公理、术语解释 |
| `20_methods` | 30 | **怎么做的**：方法是"行动指南"，与其他知识有本质区别——它是可执行的 | 教程、步骤、最佳实践、操作手册 |
| `30_facts` | 30 | **是什么**：事实是"世界的客观描述"，可靠性最高 | 客观事实、法规制度、实验数据 |
| `40_references` | 40 | **别人说的**：参考资料不是你的知识，而是"外部信息的索引" | 论文链接、文档引用、网页存档 |
| `50_resources` | 50 | **原始素材**：这些是"未经加工的原材料"，如视频笔记、截图、翻译等 | 视频笔记、阅读笔记、灵感素材、语音转写、字幕存档 |
| `60_opinions` | 60 | **我觉得**：观点不是事实，需要明确标注可信度，避免与事实混淆 | 个人见解、他人语录、未验证的推测 |
| `90_archive` | 90 | **过期的**：知识会过时（技术更新、事实变更），归档而非删除，保留历史可追溯 | 已被新知识替代的旧版本 |
| `99_system` | 99 | **系统本身**：模板和配置不属于知识内容，单独隔离 | 模板文件、分类配置、提示词 |
**关键洞察**：`50_resources/` 和 `99_system/` 虽然也在知识库目录下，但它们**不是知识内容本身**——resources 是原始素材（等待被提纯），system 是系统配置（不参与知识流转）。
---
## 三、知识属性分类（nature）
这是整个系统最核心的设计。每条知识都有一个 `nature` 字段，它决定了这条知识**存放在哪个目录**。
### 3.1 九种知识属性
| nature 值 | 中文名 | 一句话定义 | 目标目录 | 默认可信度 | 举例 |
|-----------|--------|------------|----------|-----------|------|
| `fact` | 事实 | 已验证的客观事实 | `30_facts/` | 1.0 | "Python 3.12 于 2023-10-2 发布" |
| `method` | 方法 | 可操作的步骤/教程 | `20_methods/` | 1.0 | "使用 Playwright 抓取 SPA 页面的 5 个步骤" |
| `concept` | 概念 | 原子概念、术语定义 | `10_concepts/` | 0.8 | "RAG：检索增强生成，是结合检索和生成的 AI 范式" |
| `axiom` | 公理 | 公认的基础原理 | `10_concepts/` | 1.0 | "欧几里得第五公设：过直线外一点有且仅有一条平行线" |
| `regulation` | 规章 | 法律/法规/制度 | `30_facts/` | 1.0 | "《个人信息保护法》2021年11月1日起施行" |
| `reference` | 参考 | 论文/文档/外部资料 | `40_references/` | 0.7 | "《Attention is All You Need》论文存档" |
| `data` | 数据 | 测试数据/基准结果 | `30_facts/` | 0.9 | "M1 Mac 运行 LLaMA-7B 推理速度：32 tokens/s" |
| `opinion` | 观点 | 主观看法/推测 | `60_opinions/` | 0.5 | "我认为 Agent 框架会比单体 LLM 更有前景" |
| `quote` | 引用 | 他人原话/语录 | `60_opinions/` | 0.6 | "Joel Spolsky: 'The best code is no code at all'" |
### 3.2 为什么分 9 种？
这是一个**粒度权衡**的结果：
- **太粗（比如只分"事实"和"非事实"）**：`concept`（定义）和 `method`（步骤）混在一起，检索时无法区分"我想查某个概念"还是"我想找某个方法"
- **太细（比如分 20 种）**：分类成本太高，LLM 分类准确率下降，维护负担增加
- **9 种是平衡点**：覆盖了日常知识的所有主要类型，每种之间有清晰的判定边界
### 3.3 分类决策树
当 LLM 或人工需要判定一条内容属于哪个 nature 时，使用以下决策树：
```
这段内容是在描述"世界是什么样"还是在说"应该怎么做"？
│
├── "是什么" → 可能是 fact / opinion / quote / data / reference / axiom
│ │
│ ├── 有实验数据/论文支持？
│ │ ├─ 是 → fact（confidence: 0.8+）
│ │ └─ 否 ↓
│ │
│ ├── 是公认无需证明的原理？
│ │ ├─ 是 → axiom（confidence: 0.95+）
│ │ └─ 否 ↓
│ │
│ ├── 是作者的个人看法/推测？
│ │ ├─ 是 → opinion（confidence: 0.4-0.6）
│ │ └─ 否 ↓
│ │
│ ├── 是引用的他人原话？
│ │ ├─ 是 → quote（confidence: 标注来源可信度）
│ │ └─ 否 ↓
│ │
│ ├── 是外部资料的链接/存档？
│ │ ├─ 是 → reference（confidence: 0.7）
│ │ └─ 否 ↓
│ │
│ └── 是测试数据/基准结果？
│ ├─ 是 → data（confidence: 0.9）
│ └─ 否 → 默认 reference
│
└── "怎么做" → 可能是 method / regulation
│
├── 有法律/组织的强制力？
│ ├─ 是 → regulation（confidence: 1.0）
│ └─ 否 → method（confidence: 1.0）
```
### 3.4 属性变更规则
知识不是静态的，它的属性可能随着时间变化：
| 变化场景 | 处理方式 | 示例 |
|----------|----------|------|
| 观点被验证为事实 | `opinion` → `fact`，confidence 提升，文件移动到 `30_facts/` | "我推测 GPT-5 会在2025发布" → OpenAI 实际发布了 |
| 事实被推翻 | `fact` → `opinion`，confidence 降低，文件移动到 `60_opinions/` | "地球是平的" 被科学推翻 |
| 方法升级 | 保留旧版本文件，新建 v2 文件，通过 `related` 双向链接 | "部署方案 v1" → "部署方案 v2（Docker化）" |
| 知识过时 | 移动到 `90_archive/`，标记 `status: archived` | "Python 2.x 的字符串编码处理" |
> **注意**：所有属性变更都保留历史版本，不是直接覆盖。`previous_version` 和 `superseded_by` 字段构成版本链。
---
## 四、领域分类（domain）
领域分类解决的是"这条知识属于哪个学科/行业"的问题，与 nature 正交。
### 4.1 16 个一级领域
| 编号 | 英文目录名 | 中文名称 | 典型子领域 |
|------|-----------|----------|-----------|
| 01 | `cs` | 计算机科学 | 数据库、前端、后端、运维、安全 |
| 02 | `ai` | 人工智能 | NLP、CV、强化学习、RAG、Agent |
| 03 | `finance` | 金融 | 量化交易、价值投资、宏观经济 |
| 04 | `law` | 法律 | 民法、商法、知识产权 |
| 05 | `medicine` | 医学 | 中医、西医、营养学 |
| 06 | `physics` | 物理 | 量子力学、相对论、热力学 |
| 07 | `math` | 数学 | 线性代数、概率统计、微积分 |
| 08 | `psychology` | 心理学 | 认知心理学、社会心理学 |
| 09 | `philosophy` | 哲学 | 认识论、伦理学、美学 |
| 10 | `history` | 历史 | 中国史、世界史、科技史 |
| 11 | `engineering` | 工程 | 机械、电子、土木 |
| 12 | `design` | 设计 | UI/UX、平面设计、建筑设计 |
| 13 | `business` | 商业 | 创业、管理、营销、战略 |
| 14 | `personal-management` | 个人管理 | GTD、番茄工作法、精力管理 |
| 15 | `personal-insight` | 个人洞见 | 决策模型、价值观、反思 |
| 16 | `other` | 其他 | 暂未归类 |
### 4.2 领域 vs 属性：正交关系
一条知识的**最终存储位置**由两者共同决定：
```
物理路径 = 目标目录（由 nature 决定）+ 领域子目录（由 domain 决定）
```
**示例**：
| 知识标题 | nature | domain | 物理路径 |
|----------|--------|--------|----------|
| Transformer 架构解析 | concept | ai | `10_concepts/ai/transformer-架构解析.md` |
| macOS 终端快捷键 | method | cs | `20_methods/cs/macos-终端快捷键.md` |
| 2026年Q1 GDP 增速 5.4% | fact | finance | `30_facts/finance/2026q1-gdp.md` |
| 价值投资核心理念 | opinion | finance | `60_opinions/finance/价值投资核心理念.md` |
| GTD 工作流详解 | method | personal-management | `20_methods/personal-management/gdt-工作流.md` |
### 4.3 领域扩展规则
- 当 `other/` 类别下的文件数**超过总文件数的 5%** 时，系统会提示新增领域
- 新领域需同时定义：中文名称、英文目录名、说明、典型子领域
- 新增后需更新两个文件：`domains.md`（分类表）和 `folder-aliases.json`（中文映射）
---
## 五、知识卡片模板
每条归档的知识都是一个标准化的 Markdown 文件，使用对应的卡片模板。模板保证了知识的**结构一致性**，便于检索和版本管理。
### 5.1 为什么用 4 种模板而非 1 种？
不同属性的知识需要记录的信息完全不同：
| 属性 | 需要记录的关键信息 | 模板 |
|------|-------------------|------|
| 概念 | 定义、原理、与相关概念的区别 | `concept-card.md` |
| 方法 | 目标、前置条件、步骤、常见问题 | `method-card.md` |
| 事实 | 数据来源、事实内容表格、结论 | `fact-card.md` |
| 个人洞见 | 背景、核心观点、可复用原则、验证项 | `personal-insight-card.md` |
如果用一种"万能模板"，要么字段太多（大量留空），要么字段太少（丢失关键信息）。
### 5.2 模板一：概念卡片（concept-card.md）
**适用**：`nature: concept` 和 `nature: axiom`
```yaml
---
id: KB-YYYYMMDD-NNN # 唯一标识符（自动生成）
title: "__概念名称__"
type: concept # 卡片类型
status: draft # 状态：draft/review/published/archived
nature: fact # 知识属性
domain: [计算机科学] # 领域（1-3个）
subdomain: [] # 子领域（可选）
tags: [__标签1__, __标签2__] # 检索标签
confidence: 0.8 # 可信度（0-1）
source: "" # 来源 URL
source_type: literature # 来源类型
date_created: __DATE__ # 创建日期
date_modified: __DATE__ # 最后修改日期
version: 1 # 版本号
aliases: [__别称__] # 别名（方便不同叫法都能找到）
keywords: [__关键词__] # 关键词（用于 BM25 检索）
summary: "__一句话摘要__" # 摘要（用于 L2 摘要层检索）
related: [] # 关联知识（双向链接）
previous_version: "" # 上一版本 KB-ID
superseded_by: "" # 被哪个版本替代
---
```
**正文结构**：
1. **一句话定义**：用最简洁的语言定义
2. **核心原理**：3-5 个要点
3. **与相关概念的区别**：对比表格（擅长/不擅长）
4. **主流选择/实现**：业界常见方案
5. **相关概念**：`[[双向链接]]`
**设计意图**：概念卡片的目标是"让读者 30 秒内理解一个概念"。一句话定义是核心，其余部分提供上下文。
### 5.3 模板二：方法卡片（method-card.md）
**适用**：`nature: method`
```yaml
---
id: KB-YYYYMMDD-NNN
title: "__方法/教程标题__"
type: method
status: published
nature: method
domain: [__领域__]
confidence: 1.0
source: "__来源__"
date_created: __DATE__
date_modified: __DATE__
version: 1
previous_version: ""
superseded_by: ""
---
```
**正文结构**：
1. **目标**：这个方法解决什么问题？
2. **前置条件**：需要什么才能执行
3. **步骤**：编号步骤 + 代码示例
4. **注意事项**：踩过的坑
5. **常见问题**：问题-原因-方案 三列表格
6. **历史版本**：变更记录
**设计意图**：方法卡片的目标是"让读者照着做就能成功"。步骤是核心，常见问题是防错保障。
### 5.4 模板三：事实卡片（fact-card.md）
**适用**：`nature: fact`、`nature: regulation`、`nature: data`
```yaml
---
id: KB-YYYYMMDD-NNN
title: "__事实标题__"
type: fact
status: published
nature: fact
domain: [__领域__]
confidence: 0.9
source: "__来源URL或出处__"
source_type: experiment|literature|official_doc|personal_exp
date_created: __DATE__
date_modified: __DATE__
version: 1
previous_version: ""
superseded_by: ""
---
```
**正文结构**：
1. **数据来源**：来源说明、测试环境、文献出处
2. **事实内容**：维度-值-备注 三列表格
3. **结论**：基于事实得出的结论
4. **历史版本**：变更记录
**设计意图**：事实卡片的目标是"可追溯、可验证"。`source` 和 `source_type` 是关键——没有来源的事实不可信。
### 5.5 模板四：个人洞见卡片（personal-insight-card.md）
**适用**：`nature: opinion`（特别是个人洞见类）
```yaml
---
id: KB-YYYYMMDD-NNN
title: "__个人洞见标题__"
type: concept
status: draft # 洞见默认 draft，需验证后才 published
nature: opinion
domain: [个人洞见]
tags: [__标签1__, __标签2__]
confidence: 0.6 # 洞见默认 0.6（不高不低）
source_type: personal_exp # 来源类型固定为个人经验
date_created: __DATE__
date_modified: __DATE__
version: 1
previous_version: ""
superseded_by: ""
---
```
**正文结构**：
1. **背景**：什么情境下产生的
2. **核心观点**：一句话概括
3. **详细思考**：推理过程
4. **可复用的原则**：抽象出来的通用规则
5. **相关经历**：案例支撑
6. **后续验证**：待验证项 checklist
**设计意图**：个人洞见是"最有价值但最不可靠"的知识类型。默认 `status: draft` 和 `confidence: 0.6`，通过"后续验证"机制逐步提升可信度。当验证通过后可升级为 `fact`。
---
## 六、Frontmatter 字段详解
所有知识卡片共享一套 Frontmatter 字段体系。以下是每个字段的含义和用途：
### 6.1 必填字段
| 字段 | 类型 | 说明 | 示例 |
|------|------|------|------|
| `id` | string | 唯一标识符，自动生成 | `KB-20260428-001` |
| `title` | string | 知识标题 | `"Transformer 架构详解"` |
| `type` | enum | 卡片类型（与模板对应） | `concept` / `method` / `fact` |
| `status` | enum | 生命周期状态 | `draft` / `review` / `published` / `archived` |
| `nature` | enum | 知识属性（9种） | `fact` / `method` / `concept` / ... |
| `domain` | list | 领域分类（1-3个） | `[人工智能, 计算机科学]` |
| `confidence` | float | 可信度（0-1） | `0.85` |
| `source` | string | 来源 URL 或出处 | `"https://arxiv.org/abs/1706.03762"` |
| `date_created` | date | 创建日期 | `2026-04-28` |
| `date_modified` | date | 最后修改日期 | `2026-04-28` |
| `version` | int | 版本号 | `1` |
### 6.2 可选字段
| 字段 | 类型 | 说明 | 示例 |
|------|------|------|------|
| `subdomain` | list | 子领域 | `[自然语言处理, 大模型]` |
| `tags` | list | 标签（用于检索） | `[transformer, attention, nlp]` |
| `author` | string | 作者 | `"Ashish Vaswani"` |
| `source_type` | enum | 来源类型 | `official_doc` / `literature` / `personal_exp` / `social_media` / `unknown` |
| `related` | list | 关联知识的 KB-ID | `["KB-20260425-003"]` |
| `previous_version` | string | 上一版本的 KB-ID | `KB-20260420-001` |
| `superseded_by` | string | 被哪个新版本替代 | `KB-20260428-002` |
| `aliases` | list | 别名/同义词 | `[Self-Attention, 自注意力机制]` |
| `keywords` | list | 关键词（BM25 检索用） | `[attention, self-attention, transformer]` |
| `summary` | string | 一句话摘要 | `"Transformer 是一种基于自注意力机制的序列建模架构"` |
### 6.3 可信度评分（confidence）
可信度不是"我信不信"，而是**来源的客观可靠程度**：
| source_type | confidence | 说明 |
|-------------|-----------|------|
| `official_doc` | 0.9 | 官方文档、法律文本 |
| `literature` | 0.8 | 学术论文、经过同行评审 |
| `experiment` | 0.7 | 自己实验验证过 |
| `personal_exp` | 0.5 | 个人经验（可能有偏差） |
| `social_media` | 0.3 | 社交媒体（可靠性低） |
| `unknown` | 0.4 | 来源不明 |
**知识入库时的自动修正**：基础分 0.5，然后根据来源类型加减：
- 官方文档/学术论文：+0.3
- 知名技术博客/行业报告：+0.1
- 个人博客/论坛帖子：-0.1
- 未知来源/社交媒体：-0.3
---
## 七、知识生命周期
一条知识从"发现"到"归档"的完整生命周期：
```
┌──────────────────────────────────────────────────┐
│ 知识生命周期 │
└──────────────────────────────────────────────────┘
① 发现/采集 ② 汇聚 ③ 提纯/分类
┌───────────┐ ┌──────────┐ ┌───────────────┐
│ 多平台采集 │───原始──→│ 收件箱 │──标准──→│ 分类 + 模板化 │
│ B站/小红书 │ 内容 │ 00_inbox │ MD │ + ID 生成 │
│ RSS/网页 │ │ │ │ + 去重检查 │
└───────────┘ └──────────┘ └───────┬───────┘
│
┌─────────────────────────────────┤
│ │
▼ ▼
④ 归档入库 ⑤ 持续进化
┌──────────────┐ ┌──────────────────┐
│ 按nature分配 │ │ 属性变更 │
│ 到目标目录 │ │ opinion → fact │
│ + domain子目录│ │ method v1 → v2 │
│ + 更新统计 │ │ 过时 → archive │
└──────────────┘ └──────────────────┘
```
### 7.1 各阶段详情
#### 阶段①：自动采集
| 信息源 | 采集工具 | 保存位置 | 频率 |
|--------|----------|----------|------|
| B站/YouTube 订阅 | BiliNote | `50_resources/视频笔记/` | 每 30 分钟 |
| 小红书博主 | TikOmni | `50_resources/灵感素材/` | 每 2 小时 |
| 抖音账号 | TikOmni | `50_resources/灵感素材/` | 每 2 小时 |
| RSS 订阅源 | feedparser | `40_references/` | 每 15 分钟 |
| 指定网页 | Crawl4AI | `40_references/` | 每 1 小时 |
#### 阶段②：汇聚收件箱（collect_to_inbox 技能）
- **执行时间**：每日凌晨 2:30
- **做什么**：扫描 `50_resources/`、`20_methods/`、`40_references/`、`01_daily/` 等目录中的文件，提取主要内容生成标准化 MD，放入 `00_inbox/`
- **去重**：同名/同标题文件跳过，已标记 `collected: true` 的跳过
#### 阶段③：提纯分类（inbox_refine 技能）
- **执行时间**：每日凌晨 3:00
- **做什么**：
1. 读取 `00_inbox/` 所有文件
2. 用本地 LLM（oMLX + Qwen 模型）或启发式规则判定 nature + domain
3. 应用对应卡片模板
4. 生成唯一 ID（格式 `KB-YYYYMMDD-NNN`）
5. 去重检查（标题相似度 > 0.8 则合并）
6. 写入目标目录
7. 删除收件箱原文件
8. 更新首页统计和变更日志
#### 阶段④：归档入库
归档后的知识文件名格式：`{标题}.md`，存储在 `{nature对应目录}/{domain}/` 下。
#### 阶段⑤：持续进化
| 变化类型 | 触发条件 | 处理 |
|----------|----------|------|
| 属性变更 | 观点被验证/事实被推翻 | 更新 nature，移动文件，更新内链 |
| 版本升级 | 方法有更好的方案 | 保留旧版，新建 v2，双向链接 |
| 过期归档 | 180 天未更新的技术知识 | 标记 `archived`，移入 `90_archive/` |
| 知识修补 | 用户纠正 AI 输出 | 更新 confidence，记录修正日志 |
---
## 八、自动分类的实现机制
### 8.1 LLM 分类（主要方式）
使用本地 LLM（oMLX + Qwen2.5-VL-3B）调用以下提示词进行分类：
```
你是一个知识分类助手。请对以下内容进行分析，返回 JSON 格式。
输入：{{content}}
输出：
{
"domain": ["领域1", "领域2"], // 从16个领域中选择1-3个
"nature": "fact", // 从9种属性中选择
"confidence": 0.85, // 可信度评分
"tags": ["标签1", "标签2"], // 3-5个标签
"summary": "一句话摘要" // 60字以内
}
```
**降级机制**：当 LLM 不可用时，自动切换到基于关键词的启发式规则分类。
### 8.2 置信度阈值
- LLM 分类信心度 ≥ 0.4 → 采用 LLM 结果
- LLM 分类信心度 < 0.4 → 保留在 `00_inbox/`，标记 `#待分类`，等人工处理
### 8.3 去重策略
| 检测维度 | 阈值 | 处理 |
|----------|------|------|
| 标题完全一致 | 100% | 跳过，记录日志 |
| 标题相似度 | > 0.8 | 合并（补充细节到已有文件） |
| 内容完全一致 | 100% | 跳过 |
| 同一事实新旧矛盾 | — | 新事实覆盖，旧值写入 `previous_version` |
---
## 九、知识检索机制
### 9.1 检索分层
```
用户提问
↓
L1 关键词索引（BM25） ←── 快速粗筛
├─ 无匹配 → 返回"无相关记忆"
└─ 有匹配 ↓
L2 结构化摘要（SQLite facts.db） ←── 精确匹配
├─ 置信度 ≥ 0.7 → 返回摘要
└─ 置信度 < 0.7 → 截止，返回"无高置信结果"
↓
【不自动加载原文】
仅用户明确要求时 → L3 按行号加载原文片段
```
### 9.2 混合检索
- **BM25（关键词匹配）**：适合精确术语检索，如"RAG"、"transformer"
- **向量检索（ChromaDB + Qwen3-Embedding-0.6B）**：适合语义相似检索，如"怎么让 AI 记住之前说过的话"
- **RRF（倒数秩融合）**：将两路结果合并排序
### 9.3 检索不加载全文
这是关键设计——检索时只返回摘要和行号片段，不加载整个文件。原因：
1. **节省 token**：一个知识文件可能有几千字，但用户只需要其中的一个段落
2. **保护隐私**：L3 原文层不暴露给外部 API
3. **按需加载**：用户看到摘要后，觉得需要更多细节，再按行号加载指定片段
---
## 十、版本管理与时间线
### 10.1 三种变化类型
| 变化类型 | 举例 | 处理 |
|----------|------|------|
| **硬事实改变** | 服务器配置从 4C8G → 8C16G | 原地更新，旧值写入 `previous_version` |
| **软升级** | 方法 V1 → V2（V1 仍有参考价值） | 保留 V1 文件，新建 V2，通过 `related` 双向链接 |
| **观点→事实** | 推测经过验证变为可靠知识 | 更新 `nature`，提升 `confidence`，移动到对应目录 |
### 10.2 版本链
每条知识的 Frontmatter 中维护版本信息：
```yaml
version: 2
previous_version: KB-20260420-001 # 我是从哪个版本进化来的
superseded_by: "" # 我是否被新版本替代（空=当前有效）
```
当一条知识经过 **3 次以上重要更新**，系统自动在 `99_system/timelines/` 下生成 Mermaid 时间线图。
---
## 十一、中文映射机制
### 11.1 为什么用英文目录名？
- **跨平台兼容**：中文路径在 Windows/Git/NFS 等环境下容易出现编码问题
- **脚本友好**：Shell 脚本、Python 路径拼接不会因为中文出 bug
- **Git 友好**：避免提交时的文件名编码歧义
### 11.2 中文映射怎么工作？
`folder-aliases.json` 提供完整的目录中文映射：
```json
{
"knowledge": {
"00_inbox": "收件箱",
"10_concepts": "概念层",
"20_methods": "方法层",
"30_facts": "事实层",
...
},
"concepts_domains": {
"cs": "计算机科学",
"ai": "人工智能",
...
}
}
```
**使用场景**：
- LLM 分类时，输出中文领域名（"人工智能"），系统查表得到英文目录名（`ai`），用于拼接物理路径
- 知识库首页展示时，读取映射表显示中文名称
- 日志和通知中显示中文名，方便阅读
---
## 十二、配置文件清单
知识管理系统的所有配置集中在 `99_system/` 目录下：
| 文件 | 路径 | 作用 |
|------|------|------|
| 领域分类表 | `99_system/taxonomies/domains.md` | 定义 16 个一级领域及其子领域 |
| 属性分类表 | `99_system/taxonomies/nature-types.md` | 定义 9 种 nature 类型 + 分类决策树 |
| 中文映射 | `99_system/taxonomies/folder-aliases.json` | 英文目录 ↔ 中文名映射（JSON） |
| 概念卡片模板 | `99_system/templates/concept-card.md` | 概念/公理知识模板 |
| 方法卡片模板 | `99_system/templates/method-card.md` | 方法/教程知识模板 |
| 事实卡片模板 | `99_system/templates/fact-card.md` | 事实/法规/数据知识模板 |
| 个人洞见模板 | `99_system/templates/personal-insight-card.md` | 个人见解/反思模板 |
| 分类提示词 | `99_system/prompts/classify-knowledge.md` | LLM 自动分类的 Prompt 模板 |
---
## 十三、自动化任务时间表
知识管理涉及的定时任务：
| 时间 | 任务 | 技能 | 说明 |
|------|------|------|------|
| 02:00 | 每日记忆提炼 | memory_manager | 提炼昨日对话为结构化记忆 |
| 02:30 | 收件箱汇聚 | collect_to_inbox | 扫描各目录 → 提取 → 放入 00_inbox |
| 03:00 | 收件箱提纯 | inbox_refine | 00_inbox → 分类 + 模板化 → 归档 |
| 23:00 | 采集日报汇总 | auto_collector | 汇总当日采集数据 |
---
## 十四、操作速查
### 14.1 手动操作命令
| 操作 | 说/触发词 | 系统行为 |
|------|-----------|----------|
| 入库知识 | "入库"、"保存知识" | 内容 → `00_inbox/` |
| 提纯收件箱 | "提纯"、"inbox refine" | `00_inbox/` → 分类归档 |
| 汇聚收件箱 | "归集"、"collect inbox" | 各目录 → `00_inbox/` |
| 知识检索 | "查知识库"、"知识检索" | L2 摘要检索 → 返回结果 |
| 重分类 | "知识重分类" | 更新 nature → 移动文件 |
| 备份知识库 | "知识备份" | 全量/增量备份 |
### 14.2 手动添加知识的步骤
1. 将内容保存到 `00_inbox/`（手动创建 .md 文件，或说"入库 xxx"）
2. 系统会在下次提纯时（凌晨 3:00 或手动触发）自动分类
3. 分类后可在对应目录找到标准化知识卡片
### 14.3 直接归档（跳过收件箱）
对于已经有明确分类的知识，可以直接使用 `kb_manager` 的入库功能指定 nature 和 domain，跳过收件箱直接写入目标目录。
---
## 十五、知识库首页统计
知识库首页 `README.md` 自动维护统计信息：
```
| 英文目录 | 中文名称 | 文件数 | 最近更新 |
|----------|----------|--------|----------|
| 10_concepts | 概念层 | 1 | 2026-04-28 |
| 20_methods | 方法层 | 0 | — |
| 30_facts | 事实层 | 0 | — |
| ... | ... | ... | ... |
```
每次 inbox_refine 执行后自动刷新。
变更日志 `CHANGELOG.md` 记录每次归档操作：
```markdown
## 2026-04-28
### 归档
- [concept] 测试 LLM 分类器 → 10_concepts/ (KB-20260428-001)
```
---
## 十六、总结：知识管理系统的核心逻辑
```
┌─────────────────────────────────────────────────────────┐
│ 设计哲学 │
│ │
│ ① 知识是活的：可以进化、可以被修正、有过期时间 │
│ ② 分类是正交的：属性（nature）× 领域（domain） │
│ ③ 自动化优先：采集→汇聚→提纯→归档 全自动 │
│ ④ 可追溯性：每条知识都有来源、版本链、变更记录 │
│ ⑤ 可信度量化：不回避不确定性，用 confidence 评分表达 │
│ ⑥ 检索不加载：按需获取片段，节省 token │
└─────────────────────────────────────────────────────────┘
```
**一句话总结**：这是一个以 Obsidian Markdown 文件为基础、以 LLM 为分类引擎、以自动化任务为驱动、以版本化管理为保障的**全链路知识加工流水线**。
mac-agent-os-main/90_archive/docs/CHANGELOG.md
+106
View File
@@ -0,0 +1,106 @@
# AgentOS 项目变更日志
## [2.0.2] - 2026-04-28
### 文档收口
- 新增 `REVIEW-V2.0.md`，正式记录原形、当前实现与后续升级设想之间的差异
- 新增 `V2.0-SUMMARY.md`，作为面向使用者的最新说明汇总
- 重写 `CORE-ARCHITECTURE.md`，将当前仓库冻结为 AgentOS v2.0 基准定义
- 重写 `README.md`，统一项目入口与当前基准说明
- 更新 `QUICKSTART.md`，补充双根目录与软链接边界
- 重写 `SKILLS-CATALOG.md`，收口为 v2.0 技能目录
- 更新 `REQUIREMENTS.md`，移除过期运行状态并对齐 v2.0 口径
- 将 `AgentOS-完整说明文档_副本.md` 正式归档到 `90_archive/docs/`，原路径保留跳转页
### 架构决策
- 明确 `agent-os/` 与 `agent-os-local/` 的双根目录边界
- 明确 `04_memory/` 中共享内容与本机私有内容的分界
- 明确 v2.0 采用“双入口汇聚到 Inbox”的知识流定义
- 明确 `05_tools/` 是工具层，不默认等于技能层
- 明确 `category` / `SKILL_CARD.yaml` / `collect_from_local.py` 等能力延后到后续版本
## [2.0.1] - 2026-04-25
### 修复
- **依赖管理统一**：删除旧的 `04_memory/vector_db/.venv`，统一使用 managed Python 专用 venv
- 旧路径：`~/workbuddy-agent-os/agent-sync/04_memory/vector_db/.venv`（分散，与脚本运行环境不一致）
- 新路径：`~/.workbuddy/binaries/python/envs/agent-os/`（统一，脚本和自动化共用）
- **init.sh 修复**：指向新 venv，用 `requirements.txt` 安装依赖
- **daily_digest.py 重写**：接入三个真实数据源（Claw 工作日志、WorkBuddy 系统画像、上轮摘要）
- **自动化任务修复**：Python 路径更新为新 venv
### 新增
- **bootstrap_from_memory.py**：冷启动脚本，首次运行时将已有 MEMORY.md 灌入 L1/L2
- **requirements.txt**：集中声明 Python 依赖（trafilatura + sqlite-utils）
- **WorkBuddy 自动化**：每日凌晨 2:00 自动执行 `daily_digest.py`（ID: `agentos`）
- **冷启动执行**：L2 写入 36 条初始事实，L1 索引同步建立
### 文档更新
- **REQUIREMENTS.md**：修正 venv 路径、更新实际设备状态、写清固定安装命令、新增自动化配置说明
- **QUICKSTART.md**：新增步骤 4（冷启动记忆体）、修正坚果云路径为 `~/NutstoreCloudBridge/`
- **README.md**：新增记忆数据流说明、固定路径速查表、补全目录说明
## [2.0.0] - 2026-04-25
### 新增
#### 核心框架
- L0→L1→L2→L3 四级记忆模型
- SOUL.md v2.0：完整的三层规则体系（硬约束/软约束/学习规则）
- IDENTITY.md v2.0：Claw 身份档案，含设备信息自动填充
- USER.md v2.0：ghai 用户档案
- mcp.json：MCP 协议基础配置模板
#### 初始化脚本
- init.sh：自动创建目录、安装依赖、填充设备信息
- apply-config.sh：核心配置部署到 ~/.workbuddy/
- import_skills.sh：技能导入
- export_skills.sh：技能打包导出
#### 技能包
- memory_manager：每日对话提炼、去重、冲突检测、版本管理
- daily_digest.py：每日提炼脚本（凌晨 2:00 自动运行）
- bootstrap_from_memory.py：冷启动（首次导入已有记忆）
- memory_cleanup.py：冲突消解与过期清理
- agent_memory_init.py：记忆体初始化
- kb_manager：知识库入库、分类、检索、备份
- kb_ingest.py：知识入库脚本（支持 URL/文件/文本）
- _template：技能模板（SKILL.md + version.json + skill.py）
- web_crawler：网页抓取（占位）
- sync_manager：同步管理（占位，由坚果云替代）
#### 知识库
- 按属性分层目录结构（概念/方法/事实/参考/资源/观点）
- 16 个一级领域子目录
- 知识卡片模板（概念卡/事实卡/方法卡/个人洞见卡）
- 领域分类表（domains.md）
- 知识属性分类表（nature-types.md + 分类决策树）
- 中文映射配置（folder-aliases.json）
- 知识分类提示词模板
#### 迁移脚本
- pack.sh：全量打包
- unpack.sh：解包还原
- backup.sh：手动备份
#### 说明文件
- README.md：项目概览
- QUICKSTART.md：5 分钟快速上手
- REQUIREMENTS.md：环境依赖清单
- CHANGELOG.md：本文件
### 设计决策
| 决策 | 选择 | 原因 |
|---|---|---|
| 知识库物理目录分层 | 按属性（概念/方法/事实/...）为第一层 | 人找知识先想"类型"再想"领域"，机器检索空间更小 |
| 记忆读取策略 | L2 置信度不足直接截断，不 fallback 到 L3 | 节省 token，避免无关信息干扰 |
| 跨机同步 | 坚果云，不用 Git | 国内访问 Git 不稳定 |
| 存储策略 | 单条存储线 + 平台自适应 | 避免数据分裂，init.sh 自动检测系统 |
| 目录命名 | 英文文件夹名 + 中文映射 | 机器兼容性 + 人类可读性 |
| Python 环境 | managed Python + 专用 venv | 不污染系统环境，版本可控 |
mac-agent-os-main/90_archive/docs/CORE-ARCHITECTURE.md
+217
View File
@@ -0,0 +1,217 @@
# CORE-ARCHITECTURE.md —— AgentOS v2.0 基准定义
最后更新：2026-04-28
本文档是 AgentOS v2.0 的正式基准。后续若其他大体量说明与本文冲突，以本文为准。
## 1. v2.0 的定位
AgentOS v2.0 是一套运行在 WorkBuddy 上的本地优先个人智能体外骨骼系统。
它不是最早的单机原形复刻，也不是未来多机协同终态，而是当前仓库中已经落地并可恢复的一版稳定基准。
v2.0 只做三件事：
- 冻结当前可运行结构
- 明确同步与本地边界
- 统一文档口径，避免把未来升级方案混入当前实现
## 2. 根目录模型
### 2.1 `~/workbuddy-agent-os/agent-sync/`
作用：同步与版本化的主仓库。
应放入：
- 核心配置
- 技能层
- 知识库
- 共享记忆元数据
- 工具脚本
- 迁移脚本
- 说明文档
### 2.2 `~/workbuddy-agent-os/agent-sync/agent-local/`
作用：本机私有数据区，不进入主仓库，不作为 v2.0 的主文档对象，但作为正式运行边界的一部分存在。
应放入：
- L3 原文
- 向量库
- 临时缓存
- 原始素材
- 已提炼待投递素材
## 3. 目录职责
| 目录 | v2.0 职责 | 是否共享 |
|------|-----------|----------|
| `00_bootstrap/` | 初始化、部署、导入导出 | 是 |
| `01_core/` | SOUL、IDENTITY、USER、MCP 配置 | 是 |
| `02_skills/` | WorkBuddy 技能层 | 是 |
| `03_knowledge/` | Obsidian 知识库 | 是 |
| `04_memory/` | 事实库、摘要、日志与本地挂载点 | 部分共享 |
| `05_tools/` | 公共工具层 | 是 |
| `06_runtime/` | 任务记录与缓存挂载点 | 部分共享 |
| `07_migration/` | 打包、解包、备份 | 是 |
## 4. 本地挂载与共享边界
### 4.1 正式共享内容
以下内容属于 v2.0 的共享资产：
- `01_core/`
- `02_skills/`
- `03_knowledge/`
- `04_memory/long_term/facts.db`
- `04_memory/daily_summaries/`
- `04_memory/logs/`
- `05_tools/`
- `06_runtime/tasks/`
- `07_migration/`
### 4.2 正式本机私有内容
以下内容属于 v2.0 的本机私有资产：
- `04_memory/long_term/raw/`
- `04_memory/vector_db/`
- `06_runtime/cache/`
- `~/workbuddy-agent-os/agent-sync/agent-local/materials/`
### 4.3 软链接映射
当前正式映射如下：
```text
~/workbuddy-agent-os/agent-sync/04_memory/long_term/raw -> ~/workbuddy-agent-os/agent-sync/agent-local/memory/raw
~/workbuddy-agent-os/agent-sync/04_memory/vector_db -> ~/workbuddy-agent-os/agent-sync/agent-local/memory/vector_db
~/workbuddy-agent-os/agent-sync/06_runtime/cache -> ~/workbuddy-agent-os/agent-sync/agent-local/runtime/cache
```
`init.sh` 负责重建这些映射。
## 5. v2.0 的正式数据流
### 5.1 知识流
v2.0 明确定义为“双入口汇聚到 Inbox”。
入口 A：直接入 Inbox
- 已经标准化的内容可以直接写入 `03_knowledge/00_inbox/`
入口 B：分类目录汇聚
- 内容先写入 `50_resources/`、`01_daily/`、`20_methods/`、`40_references/` 等目录
- 再由 `collect_to_inbox` 汇聚进 `00_inbox/`
统一出口：
- `inbox_refine` 将 `00_inbox/` 内容提纯归档到知识库目标目录
因此，v2.0 不再把这两种入口视为冲突，而是视为同一流水线的两种合法前置路径。
### 5.2 记忆流
当前记忆流为：
```text
WorkBuddy 工作日志 / 系统画像 / 上轮摘要
-> daily_digest.py
-> facts.db
-> keyword_index.json / ChromaDB
-> 原文写入本机私有 raw/
```
### 5.3 工具流
`05_tools/` 是工具层，不等于技能层。
v2.0 允许在工具层中存在：
- 系统检查脚本
- 抓取工具
- 媒体处理脚本
- 独立小项目
但这些工具默认不自动视为对话技能。
## 6. 技能分类
### 6.1 system 技能
system 技能是架构层约定，表示后台自动运行或以系统流程为主：
- `memory_manager`
- `collect_to_inbox`
- `inbox_refine`
- `auto_collector`
- `kb_manager`
- `sync_manager`
### 6.2 user 技能
user 技能是对话直接触发的入口层：
- `content_processor`
- `web_crawler`
### 6.3 约束说明
v2.0 仅把 system / user 作为文档级约定。
以下能力不在 v2.0 强制落地：
- `category` 元数据全量补齐
- `SKILL_CARD.yaml`
- `skill_scanner.py`
这些属于后续版本。
## 7. 初始化与恢复基准
v2.0 的正式恢复步骤如下：
```bash
cd ~/workbuddy-agent-os/agent-sync/00_bootstrap
bash init.sh
bash apply-config.sh
bash import_skills.sh
~/.workbuddy/binaries/python/envs/agent-os/bin/python3 \
~/workbuddy-agent-os/agent-sync/02_skills/memory_manager/bootstrap_from_memory.py \
--root ~/workbuddy-agent-os/agent-sync
```
手动部分：
- 安装 WorkBuddy
- 安装坚果云
- 按需安装 Obsidian
- 安装 oMLX 与模型
## 8. v2.0 延后项
以下内容明确不属于 v2.0：
- 本地素材统一投递脚本 `collect_from_local.py`
- 技能身份证与统一扫描器
- 工具 manifest 与自动化安装体系
- 更细粒度的多机记忆隔离策略
- 基于 `agent-os-local/materials/` 的全新单入口采集体系
这些内容如果要做，必须以 v2.1 或更高版本单独立项。
## 9. 验收标准
满足以下条件，即视为 v2.0 收口完成：
1. 核心文档不再互相冲突
2. 目录边界和软链接边界明确
3. 恢复步骤可以从文档直接执行
4. 知识流与记忆流可以一句话解释清楚
5. 延后项不再混入当前基准描述
mac-agent-os-main/90_archive/docs/REVIEW-V2.0.md
+174
View File
@@ -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 基准
mac-agent-os-main/90_archive/docs/V2.0-SUMMARY.md
+133
View File
@@ -0,0 +1,133 @@
# AgentOS v2.0 最新说明汇总
最后更新：2026-04-28
## 1. 当前版本是什么
AgentOS v2.0 是当前仓库的稳定可运行基准版。
它不是最初的单机原形，也不是未来多机协同终态，而是已经落地并能恢复的一版正式基线。
## 2. 当前正式文档入口
请按以下顺序阅读：
1. `CORE-ARCHITECTURE.md`：正式基准、目录边界、数据流定义
2. `V2.0-SUMMARY.md`：本文件，最新说明汇总
3. `QUICKSTART.md`：初始化与恢复操作
4. `REQUIREMENTS.md`：环境要求与依赖说明
5. `SKILLS-CATALOG.md`：v2.0 技能目录
6. `REVIEW-V2.0.md`：审查结论与收口原因
历史大体量说明已归档到：
- `90_archive/docs/AgentOS-完整说明文档_副本.v2.1-history.md`
## 3. v2.0 一句话结构
```text
agent-os/ = 共享主仓库
agent-os-local/ = 本机私有目录
```
主仓库负责：配置、技能、知识、共享记忆元数据、工具、迁移脚本。
本机私有目录负责：L3 原文、向量库、缓存、原始素材和待投递素材。
## 4. v2.0 正式边界
### 共享内容
- `01_core/`
- `02_skills/`
- `03_knowledge/`
- `04_memory/long_term/facts.db`
- `04_memory/daily_summaries/`
- `04_memory/logs/`
- `05_tools/`
- `06_runtime/tasks/`
- `07_migration/`
### 本机私有内容
- `04_memory/long_term/raw/`
- `04_memory/vector_db/`
- `06_runtime/cache/`
- `~/workbuddy-agent-os/agent-sync/agent-local/materials/`
## 5. v2.0 正式数据流
### 知识流
v2.0 采用“双入口汇聚到 Inbox”：
- 入口 A：标准化内容直接写入 `03_knowledge/00_inbox/`
- 入口 B：分类目录内容由 `collect_to_inbox` 汇聚到 `00_inbox/`
- 统一出口：`inbox_refine` 提纯归档
### 记忆流
```text
WorkBuddy 工作日志 / 系统画像 / 上轮摘要
-> daily_digest.py
-> facts.db
-> keyword_index.json / ChromaDB
-> 原文写入本机 raw/
```
### 工具流
`05_tools/` 是工具层，不默认等于技能层。
## 6. v2.0 技能分组
### system 技能
- `memory_manager`
- `collect_to_inbox`
- `inbox_refine`
- `auto_collector`
- `kb_manager`
- `sync_manager`
### user 技能
- `content_processor`
- `web_crawler`
## 7. 恢复步骤
```bash
cd ~/workbuddy-agent-os/agent-sync/00_bootstrap
bash init.sh
bash apply-config.sh
bash import_skills.sh
~/.workbuddy/binaries/python/envs/agent-os/bin/python3 \
~/workbuddy-agent-os/agent-sync/02_skills/memory_manager/bootstrap_from_memory.py \
--root ~/workbuddy-agent-os/agent-sync
```
手动安装项：
- WorkBuddy
- 坚果云
- Obsidian（按需）
- oMLX 与模型
## 8. v2.0 不做什么
以下内容已经明确延后：
- `collect_from_local.py`
- `skill_scanner.py`
- `SKILL_CARD.yaml` 全量改造
- 工具 manifest / 自动化安装体系
- 更细粒度的多机记忆隔离策略
- 基于 `agent-os-local/materials/` 的全新单入口采集体系
## 9. 现在应该怎么理解这个仓库
如果只看一句话：
> 这是一个已经从原形长成“可运行增强版”的 AgentOS 仓库，v2.0 的任务不是继续发散，而是先把当前这版冻结、讲清、可恢复。
mac-agent-os-main/90_archive/docs/我的说明.md
+390
View File
@@ -0,0 +1,390 @@
agent-os多机协同
本系统通过 WorkBuddy 作为 AI 交互中枢，整合本地大模型、计划做一个多机可协同，知识库可自增长，自学习、自优化。记忆可以不断提炼更新，向量化，持久化、长期化的、自我进化的 Mac 全栈智能体。
多机采用共同底座及分机学习的模式，可进行快速迁移，快速生成复制快速恢复。
## agent-os（全局/多机共用内容）这是共同底座的部分。
1. **初始化脚本**
- 从零安装、环境配置、workbuddy等自动化脚本
- 建议统一放在 00_bootstrap，可细分 install、setup、update 等子目录
安装的时候主要包括一次性把权限给到位，相应的基础设施，核心的环境内容，包括软件依赖，虚拟环境全部设置到位，假设是从空白组机开始还原先铺环境，然后再按依赖，最后按主程序。并设置自动任务、自动备份及自动优化等相应的所有的任务系统。所有的任务复制过来以后，根据祖籍身份，有些任务可以暂时暂停，如果身份切换以后再启用。
2. **核心配置（01_core）**
- 系统身份、主机标识、主维护机配置
- 建议增加主机/维护机标识文件（如 `HOST_ID.md`、`MAINTAINER.md`）
包括智能体所有的基础设定规则，还有一些通用全局的设置文件，全部装在这里，方便拷贝生成，或者可以进行嗯几个版本的生成，到时候可以选择性的加载，因为可能还涉及到多智能体等其他的各种设置，总之这些文件都可以配置在这里头
3. **技能（02_skills）**
- 系统必需技能
- 自定义/个人维护技能
- 每个技能需有身份证明（如 `SKILL.md`），并标注维护主机
- 建议增加技能分类（如系统/自定义/第三方）
基于前面讨论的技能身份证和版本控制分层，你只需要增加以下文件：
A. 每个技能目录下：SKILL_CARD.yaml（技能身份证）
只加在你自己写的技能里，比如 memory_manager/、kb_manager/、inbox_refine/、collect_to_inbox/、auto_collector/。
以 memory_manager/ 为例，在 02_skills/memory_manager/ 下新增一个文件：
```yaml
# SKILL_CARD.yaml —— 技能身份证
skill:
name: "记忆管理器"
id: "memory_manager"
version: "1.1.0"
category: "core-system"
status: "active"
created: "2026-04-25"
updated: "2026-04-27"
description:
short: "每日对话提炼、去重、冲突检测、版本管理"
use_cases:
- "每日凌晨 2:00 自动提炼前一天记忆"
- "首次冷启动灌入已有 MEMORY.md"
- "手动触发记忆更新"
tags: ["记忆", "L1索引", "L2事实", "自动化"]
ownership:
master_editor: "macbook-air-m1"
readonly_on_other_devices: true
environment:
os: "macos"
python_path: "~/.workbuddy/binaries/python/envs/agent-os/bin/python3"
local_dependencies:
- "sqlite3（系统自带）"
pip_dependencies:
- "sqlite-utils>=3.35"
- "chromadb>=1.0.0"
setup:
install_script: "" # 由顶层 init.sh 统一安装
post_check: "python3 -c 'import sqlite3; print(\"OK\")'"
usage:
entry_point: "daily_digest.py"
scheduled: "每日 02:00（WorkBuddy 自动化 agentos）"
manual_trigger: "记忆更新"
changelog:
- version: "1.1.0"
date: "2026-04-27"
changes: "接入 oMLX Embedding，支持向量化"
- version: "1.0.0"
date: "2026-04-25"
changes: "初始版本"
```
对其他技能（kb_manager、inbox_refine、collect_to_inbox、auto_collector）同样操作，字段按实际填写。
外部技能（如 web-clipper、voice-summary、social-collector）暂不加 SKILL_CARD，因为它们不是你开发的，升级不归你控制。如果你后续改造了它们，那时再加。
---
B. 05_tools/ 下：skill_scanner.py（技能身份证扫描器）
让你在任何一台机器上运行一次，就知道哪些技能就绪、哪些缺依赖：
```python
#!/usr/bin/env python3
"""扫描所有 SKILL_CARD.yaml，生成技能状态报告"""
import os
import yaml
from pathlib import Path
SKILLS_DIR = Path.home() / "agent-os" / "02_skills"
def scan():
print("=" * 60)
print("AgentOS 技能状态报告")
print("=" * 60)
for skill_dir in sorted(SKILLS_DIR.iterdir()):
if not skill_dir.is_dir():
continue
card_path = skill_dir / "SKILL_CARD.yaml"
if not card_path.exists():
print(f" ⚠️ {skill_dir.name} — 无 SKILL_CARD.yaml（外部技能或待补充）")
continue
with open(card_path) as f:
card = yaml.safe_load(f)
s = card["skill"]
o = card.get("ownership", {})
print(f" ✅ {s['name']} (v{s['version']}) 主理: {o.get('master_editor', '未知')}")
print("=" * 60)
if __name__ == "__main__":
scan()
```
放在 05_tools/skill_scanner.py，用 AGENTOS_PYTHON 运行即可。
---
C. 根目录：SKILL_CARD_TEMPLATE.yaml（技能身份证模板）
当你在别的机器上新写一个技能时，复制这个模板来填，确保格式统一。放在 ~/workbuddy-agent-os/agent-sync/SKILL_CARD_TEMPLATE.yaml。
---
4. **知识库（03_knowledge）**
- 分类建议：
- 知识（外部资料、文档、教程等）
- 个人笔记，个人我自己去想到的一些事，或者说我的感悟，或者说临时的一个随手的记的笔记，那这个东西呢其实就相当于随手记，我觉得这块就是呃它可以不用当成知识库，但是可能我需要有一个随手记随手查的事情，特别是比方说我开会的一个笔记，或者是我个人记录的一些语音，或者是个人记事，其实这是个个人成长，在我的第1版里头，其实是按照这个分类来的，所以呃知识库你会看到它比较乱，它有好多分类，其实是我的一个思想过程，中间呃有刚开始按照类别分的，后面按照事实分的，也有按领域分的，还有按概念分的，所以这块我们可以再讨论，嗯我只是把我所有的信息先放进来，你去了解一下
- 记忆固化（长期记忆、总结、反思等）这个说的是整个我嗯好多机子的记忆体里头很多内容，它可能随着时间的偏移，它有些东西也变成了事实，也要记录下来。如果变成事实的东西，而且是通用的，不是说单机能用的，那其实也可以归集到总的知识库里头的记忆体里头，或者说是整个转到事实的记录，这块也要进行一个合理的判断
- 项目立项/成形（项目文档、方案、进展等）我自己写的一些项目立项文件记录，包括我们自己编的程序的进展什么的，可能要单独画出来，因为它可能记录的我的一个过程，它可能是个过程记录，并不是结果，等到整个项目都成型了，稳固下来，可能他会写到正式记忆体。所以他要单独处理一下，我想的，
- 向量化内容（如向量索引、embedding 数据）
- 收件箱（待整理内容）
- 建议每类下可细分为原始、已整理、归档等
── 8_收件箱/ # 临时收集，每月归档
├── 1_日记/ # 每日记录，自动生成
├── 20_项目/ # 活跃项目，Frontmatter包含type/status/areas
├── 30_研究/ # 永久参考，深度调研内容
├── 40_知识库/ # 原子概念，拆分独立知识点
├── 50_资源/ # 精选内容，新闻稿、行业简报
├── 90_计划/ # 执行计划，完成后归档
└── 99_系统/ # 模板、提示词、归档目
知识库结构详解
6.1 目录结构与命名规则
知识库路径：~/workbuddy-agent-os/agent-sync/03_knowledge/，同时作为 Obsidian Vault。
编号
目录
中文名
知识属性
说明
00
00_inbox/
📥 收件箱
—
待提纯内容暂存
01
01_daily/
📅 日记
—
每日日记、闪念笔记
10
10_concepts/
💡 概念层
concept/axiom
16 个子领域目录
20
20_methods/
🔧 方法层
method
可操作的步骤/教程
30
30_facts/
📋 事实层
fact/regulation/data
已验证的客观事实
40
40_references/
📎 参考层
reference
论文/文档/外部资料
50
50_resources/
🛠 资源层
resource
视频笔记/阅读笔记/灵感素材等
60
60_opinions/
💭 观点层
opinion/quote
主观看法/他人原话
90
90_archive/
🗄 归档层
—
已弃用的知识
99
99_system/
⚙️ 系统层
—
模板/分类/配置
6.2 领域分类体系
10_concepts/ 下按 16 个一级领域分子目录：
编号
英文目录
中文
典型子领域
01
cs
计算机科学
数据库、前端、后端、运维、安全
02
ai
人工智能
NLP、CV、强化学习、RAG、Agent
03
finance
金融
量化交易、价值投资、宏观经济
04
law
法律
民法、商法、知识产权
05
medicine
医学
中医、西医、营养学
06
physics
物理
量子力学、相对论、热力学
07
math
数学
线性代数、概率统计、微积分
08
psychology
心理学
认知心理学、社会心理学
09
philosophy
哲学
认识论、伦理学、美学
10
history
历史
中国史、世界史、科技史
11
engineering
工程
机械、电子、土木
12
design
设计
UI/UX、平面设计、建筑设计
13
business
商业
创业、管理、营销、战略
14
personal-management
个人管理
GTD、番茄工作法、精力管理
15
personal-insight
个人洞见
决策模型、价值观、反思
16
other
其他
待新增领域
当"其他"类别超过总知识 5% 时，memory_manager 会提示新增领域。
6.3 知识卡片模板
99_system/templates/ 下有 4 种标准化模板：
模板文件
适用类型
核心字段
concept-card.md
概念/公理
一句话定义、核心原理、与相关概念区别、主流选择
method-card.md
方法/教程
适用场景、步骤、注意事项、示例
fact-card.md
事实/数据
事实陈述、数据来源、可信度
personal-insight-card.md
个人洞见
背景、思考过程、结论、行动项
所有知识卡片使用标准 Frontmatter：
yaml
复制
---
id: KB-YYYYMMDD-NNN
title: "知识标题"
type: concept|method|fact|reference|resource|opinion
status: draft|review|published|archived
nature: fact|opinion|method|regulation|reference|data|quote|axiom
domain: [领域1, 领域2]
tags: [标签列表]
confidence: 0.0-1.0
source: "原始来源 URL"
source_type: official_doc|literature|experiment|personal_exp|social_media|unknown
date_created: YYYY-MM-DD
date_modified: YYYY-MM-DD
version: 1
previous_version: ""
superseded_by: ""
---
6.4 分类体系配置文件
文件
路径
说明
domains.md
99_system/taxonomies/domains.md
16 个一级领域定义
nature-types.md
99_system/taxonomies/nature-types.md
9 种 nature 类型 + 决策树
folder-aliases.json
99_system/taxonomies/folder-aliases.json
英文目录 ↔ 中文映射
classify-knowledge.md
99_system/prompts/classify-knowledge.md
知识分类 Prompt
5. **工具层（05_tools）**
- 非技能化的工具脚本
- 包括知识库管理、记忆管理、技能管理等
- 建议按功能模块细分
因为技能很更多的是自然语言或一些东西，它可能对于一些大量的个性化的工具，呃可能不一定使用得很好，所以我的工具做很多做cl i的终端化的处理，或者说直接写成一些接口的东西，这样子会被技能更好的去去调用，技能这面有一些东西，呃如果确实是可以写，那中间也可以转换，但这个转换过程可能要等着这个技能呃通用了，才可能放到技能里头，或者说它跟系统有关才放进去。我是这么想的，你可以给我点建议啊，我们在这个事上再讨论讨论
6. **系统管理（07_migration/90_archive）**
- 打包、解包、迁移、备份等脚本
- 系统归档、历史记录
---
## agent-os-local（本机专属内容）
1. **采集原始内容**
- 各类原始数据（音频、视频、网页、截图等），每个单机的原始讨论，可能还包括我说的一些话，一些笔记，这个其实和知识库那块来讲是联动的，它其实是先进行我从网上或者。说手机或者是新闻客户端收集到的内容全都看到了以后，先暂存到每台机子上，因为每台机子我在做项目的时候，同时会看到一些信息，这个信息就是临时性的，或者是一个闪念，但是过完以后可能再去收集整理，所以它就相当于是个前前端缓存，存。存完以后，有一些东西可能分门别类，这块跟知识库呢要对应起来，到时候连知识库的分门别类和这块一块讨论。这个才是这个项目可能比较核心的东西，最初我就是拿这个东西想写一个项目来着，但是后来发现其实是依托智能体，不过不光是做这个项目，还要做智能体的一些配置，运行状态等等，才会越写越大，最后涉及到多机联动
- 建议按类型细分 materials/audio、video、web、screenshots 等
2. **本机记忆**
- 个人/本机的记忆数据
- 建议分为原始、整理、归档等
本机的记忆，自己也涉及到和知识体的共享的，就是什么记忆提取出来变成长久的记忆，他记忆里头可能有一些东西是要加一些属性字段，也就是向量化处理的时候，可能在一些东西，比方说事实层，或者说具体的这种呃硬约束层，它可能。能能提取出来，分享给所有人用，呃有一些东西只有跟本机有关，比方说本机的CPU处理能力，或者本机的向量化处理能能力，这些东西只能在本机用，放在别的机器上不通用的，那其实是不要放，那这个中间如何去判断，如何去执行。所以我们这中间的这个知识管理和提炼，记忆提炼这两个程序，就要把这些东西都整理进去，所以这两个程序写起来就会很重要
3. **运行记录、对话记录、缓存**
- 任务缓存、运行日志、对话历史
- 建议分为 runtime/cache、memory/raw、memory/vector_db 等
这块主要是和这个智能体的一个对接的地方，因为将来有可能智能体我换了的话，用其他智能体如何对接，其实都要在这块处理，因为换一个智能整体可能我用openclaw和现在workbuddy可能将来用的对接的方式或者是运行状态，可能对话记录或者说是呃每次的呃这种上下文也不一样。如何能从用这个适合智能体的一些工具把它调用出来，这个是很重要的事情，都在这块解决
4. **本机情况数据说明记录**
- 本机环境、硬件、软件、配置说明
- 建议单独设 info/ 或 system/ 目录
---
## 需要你补充/确认的问题
1. **向量库（vector_db）**
你希望它只作为索引，还是也存储知识内容？是否需要和知识库内容分离，还是做成知识库的一个子模块？向亮库，我就在想，其实我本地本机是应该有个向量库，然后在共享的呃服务器知识体上，其实也是有一个向量库，那个向亮库可以全全域和多多台主机同步，但我本机就是我本机，其实不需要同步，呃本机根据依据本机的这个能力，其实。在进行，所以我中间这个有一个向量库，可能要全局通用，这样子才能同步起来，呃我理解是这个样子，你可能想想是不是再帮我补充一下
2. **主机/维护机标识**
是否需要每台主机有唯一标识？主维护机如何指定？是否需要自动同步主维护机的内容？
主机肯定是要维护的，因为我相当于是多台主机跨系统的一个跨主机的一个操作，所以每台主机它是什么一个唯一标识，然后它充当。什么角色，对刚才我讲的知识库、记忆、技能，所有的这种管理，包括整个这个主程序的管理，他们都有什么权限角色，其实我觉得这个还是需要的，因为谁写的智能体可能最好是在他原来的这台主机上继续在维护。体的知识库的管理，最好是有一台主机，就固定充当这台管理主机，然后他晚上就可以进行呃提炼管理，记忆体各自是各自的管理，然后管理与有了一些记忆可以共享升级的情况下，然后再去提取到中组主机里头去呃管理
3. **知识库分类**
你希望知识库的分类粒度到什么程度？是否需要支持多级分类、标签等？
知识库的分类，我前面讲了好多了，包括记忆体那块也讲了好多了，有很多对接的，所以我需要这块来讲，呃展开了，到时候我们再细聊，你可以发散性的给我提问题，帮助我去把这块这一部分去完善掉
4. **工具与技能的边界**
工具和技能的区别是否只在于是否被系统自动加载？有无交集或转换机制？
工具在加载这一块，我需要既要注重效率，又要呃合理的去呃扩展，呃这块你给出很好的建议
5. **本机数据说明**
本机情况数据说明，具体希望包含哪些内容？如硬件、软件、网络、环境变量等？
本机情况就是根据我系统将来要完成的所有的电脑相关的事项，给出来的所有的数据，其实这个数据最好固定的写在这儿，但是它有一些变化的时候，又能够动态更新，这个要有个很好的呃模式，我不想浪费太多的token，因为核心逻辑就是整个这个系统使用token的时候还是要尽量节省一点效率为先，我不不能太过于浪费
6. **同步/备份机制**
agent-os 与 agent-os-local 之间是否需要自动同步、定期备份？同步粒度和策略如何？ 我觉得你问这个问题就是你没搞清楚我现在在写什么，所以我现在才写了这么大一段东西给你