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/03_knowledge/99_system/architecture/IMPLEMENTATION-PLAN-v1.md

@@ -0,0 +1,416 @@
+---
+type: concept
+domain: system
+nature: plan
+tags: [agentos, v3.0, implementation, plan, tasks]
+status: active
+created: 2026-06-16
+updated: 2026-06-16
+version: 1.0.0
+supersedes: []
+---
+
+# AgentOS 联邦指挥台 — 实施计划 v1.0
+
+> 基于 `federation-operations-architecture.md` 设计文档
+> 参考: `federated-multi-machine-architecture.md` / `dashboard-v4-design.md` / `CORE-ARCHITECTURE.md`
+> 总体估计: ≈ 20 小时
+
+---
+
+## 一、优先级总览
+
+```
+P0 ─── 感知层: 让指挥台"看到"所有机器状态
+  ├─ 机器状态条(在线/离线/忙碌)
+  ├─ 账号级忙碌状态
+  └─ 操作前的资源检查
+
+P1 ─── 路由层: 让指挥台"指挥"远程机器
+  ├─ owner_machine 操作路由
+  ├─ 远程执行通道完善
+  └─ 按钮状态智能化(灰掉/提示/远程执行)
+
+P2 ─── 引擎层: 操作生命周期管理
+  ├─ 统一操作队列(状态机)
+  ├─ 资源锁系统
+  ├─ 状态归零(pre-flight reset)
+  └─ 日志聚合
+
+P3 ─── 生态层: 高级功能和系统完备
+  ├─ 文件级 WPRA 写入规范
+  ├─ guardd 模块补全
+  ├─ 9 插件体系完善
+  └─ 键盘锁定/离线队列/DAG
+```
+
+---
+
+## 二、依赖关系拓扑
+
+```
+P0-1 机器状态条
+  └── 依赖: guardd 心跳已实现 ✅
+  └── 阻塞: P1-1 (操作路由需要知道机器是否在线)
+
+P0-2 账号忙碌状态
+  └── 依赖: 本地资源锁文件
+  └── 阻塞: P2-2 (资源锁系统)
+
+P1-1 操作路由 (owner_machine 判断)
+  └── 依赖: P0-1 (机器在线状态)
+  └── 阻塞: P1-2 (远程执行通道)
+
+P1-2 远程执行通道
+  └── 依赖: federation API 已部分实现 ✅
+  └── 前置: 完善 /api/federation/exec 支持所有操作类型
+
+P2-1 状态机队列
+  └── 依赖: P1-1, P1-2
+  └── 前置: cross_machine/tasks/ 目录
+
+P2-2 资源锁系统
+  └── 依赖: 本地文件锁 + guardd 锁管理
+  └── 前置: guardd 锁模块
+
+P3-1 WPRA 写入规范
+  └── 依赖: cross_machine/data/ 目录结构已存在 ✅
+  └── 前置: 插件改写为文件级写入
+```
+
+---
+
+## 三、Phase 0: 立即修复 (之前审计发现的问题)
+
+| # | 任务 | 文件 | 估计 | 优先级 |
+|:-:|:-----|:-----|:----:|:------:|
+| 0.1 | 账号管理跨机显示(已做) | index.html | ✅ 已完成 | P0 |
+| 0.2 | 修复 matrix-mgmt 路由 | app.py | ✅ 已完成 | P0 |
+| 0.3 | 修复 cross-machines API | app.py | ✅ 已完成 | P0 |
+| 0.4 | 修复 loadSmsAccounts 数据格式 | index.html | ✅ 已完成 | P0 |
+| 0.5 | SMS API 加 owner_machine | sms_proxy_api.py | ✅ 已完成 | P0 |
+| 0.6 | 前端代理/调度/任务路径错配 | index.html | ≈ 20min | P0 |
+| 0.7 | 语料库缺失API补充 | routes/matrix.py | ≈ 30min | P0 |
+
+---
+
+## 四、Phase 1: 感知层 — 让指挥台"看见" (≈ 3h)
+
+### 1.1 机器状态条 (≈ 1h)
+
+在每个视图顶部增加机器状态条:
+
+```
+┌─────────────────────────────────────────────────────┐
+│  🟢 chengzigedeAir  🟢 5kechengdeAir  ⚪ 7kecheng  │
+│  账号: 5在线/5总      账号: 0在线/5总    离线30分钟   │
+└─────────────────────────────────────────────────────┘
+```
+
+**文件**: `index.html` + `core.js` (添加全局状态条组件)
+**实现**:
+- 每 30s 轮询 `/api/federation/health` 获取三台机器在线状态
+- 状态条渲染为全局组件,所有视图共用
+- 绿/黄/灰三色: 在线 / 忙碌(有任务运行) / 离线(>5min无心跳)
+
+### 1.2 账号级忙碌状态 (≈ 1h)
+
+```
+douyin_01  🟢 在线 ✅ 可操作
+douyin_02  🔴 忙碌 ⏳ 正在养号中 (剩余23分钟)
+douyin_03  ⚪ 离线 ❌ 机器5kecheng当前离线
+```
+
+**文件**: `sms_proxy_api.py` (加忙碌字段) + `index.html` (展示)
+**实现**:
+- guardd 维护一个 `locks.json`,记录当前哪个账号正在被操作
+- SMS API 响应中加 `busy: true/false`, `busy_since: timestamp`
+- 忙碌的账号按钮灰掉,显示"正在操作中"
+
+### 1.3 前端路径错配修复 (≈ 20min)
+
+| 前端调用 | 改为 | 文件 |
+|:---------|:-----|:-----|
+| `/api/matrix/proxy/list` | `/api/matrix/proxies` | index.html |
+| `/api/matrix/schedule/list` | `/api/matrix/schedules` | index.html |
+| `/api/matrix/task/comment` | `/api/matrix/task/run` (POST+type=comment) | index.html |
+
+---
+
+## 五、Phase 2: 路由层 — 让指挥台"指挥" (≈ 5h)
+
+### 2.1 操作路由 — 本地 vs 远程 (≈ 2h)
+
+**核心逻辑** (所有操作按钮的通用函数):
+
+```javascript
+async function executeOperation(accountId, operationType, params) {
+  // 1. 查账号所属机器
+  const account = findAccount(accountId);
+  const targetMachine = account.owner_machine;
+  
+  // 2. 查机器是否在线
+  const machineStatus = await getMachineStatus(targetMachine);
+  if (machineStatus === 'offline') {
+    showError(`${targetMachine} 当前离线，无法操作`);
+    return;
+  }
+  
+  // 3. 如果是本机 → 本地API
+  if (targetMachine === currentMachine) {
+    return localExecute(operationType, params);
+  }
+  
+  // 4. 如果是远程机器 → 联邦 exec
+  return remoteExecute(targetMachine, operationType, params);
+}
+```
+
+**文件**: 新建 `static/modules/operation-router.js`
+**改动**:
+- `accountLogin()` → 通过路由执行
+- `clearCookies()` → 通过路由执行
+- `deleteAccount()` → 通过路由执行
+- `batchExecute()` → 支持跨机批量
+
+### 2.2 远程执行通道完善 (≈ 2h)
+
+**文件**: `services/remote_exec.py`
+**新增能力**:
+- 支持登录命令: `ssh {machine} "cd agent-sync && agentos matrix login {account}"`
+- 支持养号命令: `ssh {machine} "cd agent-sync && agentos matrix run --blueprint {bp} --rounds {n}"`
+- 支持采集命令: `ssh {machine} "cd agent-sync && agentos matrix collect {phone}"`
+- 统一返回格式: `{status, output, error, duration_sec}`
+
+### 2.3 新建前端模块目录 (≈ 30min)
+
+```bash
+static/modules/
+├── core.js              # 框架核心 ✅ 现有
+├── operation-router.js  # 操作路由 (新建)
+├── machine-bar.js       # 机器状态条 (新建)
+├── operation-queue.js   # 操作队列 (Phase 3)
+├── resource-lock.js     # 资源锁 (Phase 3)
+└── ...                  # 现有其他模块
+```
+
+**文件**: `index.html` — 加入新的 script 加载顺序
+
+### 2.4 按钮状态智能化 (≈ 30min)
+
+| 账号状态 | 登录按钮 | 养号按钮 | 采集按钮 |
+|:---------|:--------|:---------|:---------|
+| 本机·在线·空闲 | 🟢 可用 | 🟢 可用 | 🟢 可用 |
+| 本机·在线·忙碌 | 🔴 灰掉"正在养号中" | 🔴 灰掉 | 🟢 可用 |
+| 远程·在线·空闲 | 🟢 "远程执行" | 🟢 "远程执行" | 🟢 "远程执行" |
+| 远程·离线 | ⚪ 灰掉"XX机离线" | ⚪ 灰掉 | ⚪ 灰掉 |
+
+---
+
+## 六、Phase 3: 引擎层 — 操作生命周期管理 (≈ 7h)
+
+### 3.1 统一操作队列 + 状态机 (≈ 3h)
+
+**文件**: 
+- `guardd/modules/operation_queue.py` (新建)
+- `static/modules/operation-queue.js` (新建)
+
+**后端**:
+```python
+# guardd/modules/operation_queue.py
+class OperationQueue:
+    """操作队列 — 管理本机所有操作的生命周期"""
+    
+    def submit(self, op_type, params) -> str:
+        """提交操作,返回 operation_id"""
+        # 写 cross_machine/tasks/pending/{op_id}.json
+        
+    def check(self, op_id) -> dict:
+        """查询操作状态"""
+        
+    def cancel(self, op_id) -> bool:
+        """取消正在运行的操作"""
+        
+    def cleanup(self, op_id):
+        """操作完成后清理"""
+```
+
+**前端**: 操作日志面板,按机器/时间/类型过滤
+
+### 3.2 资源锁系统 (≈ 2h)
+
+**文件**: 
+- `guardd/modules/resource_lock.py` (新建)
+- `static/modules/resource-lock.js` (新建)
+
+**锁表**:
+```python
+locks = {
+    "browser": {"held_by": "op_001", "acquired_at": "...", "ttl": 3600},
+    "account:douyin_01": {"held_by": "op_001", ...},
+    "identity:douyin_01_camo": {"held_by": "op_001", ...},
+}
+```
+
+**规则**:
+- 锁自动过期 (TTL)
+- 锁可被强制释放 (管理员)
+- 锁冲突时: 拒绝新操作,提示"资源被 XX 操作占用"
+
+### 3.3 状态归零 Pre-flight Reset (≈ 1h)
+
+**文件**: `guardd/modules/preflight.py` (新建)
+
+每次操作前自动执行:
+
+```bash
+1. pkill -f camoufox          # 杀残留浏览器
+2. pkill -f playwright        # 杀残留驱动
+3. rm -rf /tmp/camoufox_*     # 清临时文件
+4. check_locks()              # 检查并释放过期锁
+5. check_disk_space()         # 检查磁盘空间
+6. return "ready"             # 返回就绪状态
+```
+
+### 3.4 日志聚合 (≈ 1h)
+
+**文件**: 
+- `app.py` 新增 `/api/logs/push` 端点
+- `guardd/modules/log_aggregator.py` (新建)
+
+**日志格式**:
+```json
+{
+  "op_id": "op_20260616_001",
+  "machine": "5kechengdeAir",
+  "type": "nurture_run",
+  "status": "completed",
+  "states": [...],
+  "output": "...",
+  "duration_sec": 360,
+  "triggered_by": "dashboard"
+}
+```
+
+---
+
+## 七、Phase 4: 生态层 — 系统完备 (≈ 5h)
+
+### 4.1 WPRA 写入规范落地 (≈ 2h)
+
+参考 `dashboard-v4-design.md` 中的 cross_machine 数据规范:
+
+```python
+# 每个插件写数据时遵循
+CROSS_MACHINE / "data" / {plugin} / {uid}.json
+# 内容包含
+{"plugin": "...", "version": "...", "machine_uid": "...", 
+ "hostname": "...", "timestamp": "...", "data": {...}}
+```
+
+**文件**: 
+- `plugins/base.py` — 更新 `write_shared_data()`
+- `plugins/matrix.py` — 改写为文件级写入
+- `plugins/guardd.py` — 改写为文件级写入
+
+### 4.2 guardd 模块补全 (≈ 2h)
+
+参考 `federated-multi-machine-architecture.md`:
+
+| 模块 | 状态 | 任务 |
+|:-----|:----:|:-----|
+| `heartbeat` | ✅ 已实现 | — |
+| `task_worker` | ⏳ 部分 | 扫描 cross_machine/tasks/ 执行 |
+| `upgrade_checker` | ❌ 缺失 | 版本比对+自动拉取 |
+| `memory_triage` | ❌ 缺失 | 记忆过滤→提交箱 |
+| `knowledge_sync` | ❌ 缺失 | 知识库变更通知 |
+| `encrypted_channel` | ❌ 缺失 | RSA 加密通信 |
+| `cleanup` | ❌ 缺失 | 清理30天以上旧数据 |
+| `operation_queue` | ❌ 缺失 | Phase 3 新建 |
+| `resource_lock` | ❌ 缺失 | Phase 3 新建 |
+| `preflight` | ❌ 缺失 | Phase 3 新建 |
+
+### 4.3 9 插件体系完善 (≈ 1h)
+
+检查现有插件 vs 设计:
+
+| 插件 | dashboard-v4 设计 | 现状 |
+|:-----|:-----------------|:-----|
+| guardd | 🖥 联邦机器 | ✅ 已实现 |
+| matrix | 📱 矩阵养号 | ✅ 已实现 |
+| ave | 🎬 视频工厂 | ✅ 已实现 |
+| collector | 📡 内容采集 | ⏳ crawl.py 新建 |
+| skills | 🧩 技能树 | ❌ 缺失 |
+| knowledge | 📚 知识库 | ✅ kb_api.py |
+| automation | ⏰ 自动任务 | ⏳ scheduler.py 新建 |
+| tools | 🔧 工具集 | ❌ 缺失 |
+| system | ⚙️ 系统核心 | ⏳ system_plugins.py |
+
+---
+
+## 八、实施顺序总结
+
+```
+Week 1 (3天)    Phase 1: 感知层
+                ├── 1.1 机器状态条     ≈ 1h
+                ├── 1.2 账号忙碌状态   ≈ 1h  
+                └── 1.3 前端路径修复   ≈ 20min
+
+Week 2 (3天)    Phase 2: 路由层
+                ├── 2.1 操作路由       ≈ 2h
+                ├── 2.2 远程执行通道   ≈ 2h
+                ├── 2.3 前端模块化     ≈ 30min
+                └── 2.4 按钮状态智能化 ≈ 30min
+
+Week 3 (3天)    Phase 3: 引擎层
+                ├── 3.1 操作队列       ≈ 3h
+                ├── 3.2 资源锁         ≈ 2h
+                ├── 3.3 状态归零       ≈ 1h
+                └── 3.4 日志聚合       ≈ 1h
+
+Week 4 (2天)    Phase 4: 生态层
+                ├── 4.1 WPRA 写入规范  ≈ 2h
+                ├── 4.2 guardd 模块    ≈ 2h
+                └── 4.3 9插件体系      ≈ 1h
+
+Phase 0 (已做)  ✅ 6项审计修复完成
+Phase 0 (待做)  ❌ 0.6 前端路径错配 ≈ 20min
+                ❌ 0.7 语料库API    ≈ 30min
+```
+
+---
+
+## 九、风险与缓解
+
+| 风险 | 概率 | 影响 | 缓解 |
+|:-----|:----:|:----:|:-----|
+| SSH 远程执行权限不足 | 中 | 高 | 先实现本地操作,远程执行作为可选升级 |
+| 资源锁导致操作阻塞 | 低 | 中 | 锁设 TTL,管理员可强制释放 |
+| guardd 模块太多难维护 | 中 | 中 | 模块化设计,每个模块独立文件,可单独启用/禁用 |
+| 前端模块化导致加载顺序问题 | 低 | 高 | 使用串行加载器,明确依赖顺序 |
+| 文件级 WPRA 写入增加 Git 冲突 | 低 | 中 | 按 machine_uid 隔离文件,不会冲突 |
+
+---
+
+## 十、验收标准
+
+### Phase 1 完成标志
+- [ ] 每个视图顶部显示三台机器状态条
+- [ ] 账号卡片显示忙碌状态
+- [ ] 前端所有 fetch 路径正确,无 404
+
+### Phase 2 完成标志
+- [ ] 远程账号按钮自动路由到对应机器
+- [ ] 离线机器操作按钮灰掉并提示
+- [ ] 可通过 Dashboard 远程登录/养号/采集
+
+### Phase 3 完成标志
+- [ ] 每个操作有完整生命周期追踪
+- [ ] 资源冲突时正确拒绝或排队
+- [ ] 操作前自动清理残留进程
+- [ ] 操作日志可查看、可过滤
+
+### Phase 4 完成标志
+- [ ] 所有插件按 WPRA 规范写入
+- [ ] guardd 10 模块正常运行
+- [ ] 9 插件体系完整

mac-agent-os-main/03_knowledge/99_system/architecture/federated-multi-machine-architecture.md

@@ -0,0 +1,97 @@
+---
+type: concept
+domain: system
+nature: architecture
+tags: [agentos, v2.1, federated, multi-machine, architecture, guardd]
+status: active
+created: 2026-05-15
+updated: 2026-05-15
+version: 1.0.0
+---
+
+# 联邦式多机协同架构（V2.1）
+
+> AgentOS 支持多台 Mac 组成**智能体联邦**，通过三层架构实现数据隔离 + 轻量协同。
+
+## 架构总览
+
+```
+┌──────────────┐     ┌──────────────┐     ┌──────────────┐
+│  machine a   │     │  machine b   │     │  machine c   │
+│  (redmi-12c) │     │ (mac-mini)   │     │ (macbook air)│
+│              │     │              │     │              │
+│  agent-local │     │  agent-local │     │  agent-local │
+│  (私钥/记忆/  │     │  (私钥/记忆/  │     │  (私钥/记忆/  │
+│   重资产)     │     │   重资产)     │     │   重资产)     │
+└──────┬───────┘     └──────┬───────┘     └──────┬───────┘
+       │                    │                    │
+       └──────────┬─────────┴─────────┬──────────┘
+                  │    agent-sync/    │
+                  │  (NutSync 同步)   │
+                  └──────────────────┘
+                   events/  status/  tasks/
+                   encrypted/  knowledge/
+                  ┌──────────────────┐
+                  │  直传层 (SSH/AirDrop) │
+                  └──────────────────┘
+```
+
+## 三层数据架构
+
+| 层 | 路径 | 内容 | 同步方式 |
+|----|------|------|---------|
+| **agent-local/** | 本机专属 | 私钥 · API Key · 素材库 · 本地记忆 · 提交箱 · 守护进程日志 | ❌ 永不共享 |
+| **agent-sync/** | 共享目录 | 配置 · 知识库 · 技能 · 记忆摘要 · 工具脚本 | NutSync 双向同步 |
+| **直传层** | 点对点 | 大文件传输（视频/素材等） | SSH rsync / AirDrop |
+
+## 七大协同子系统
+
+| # | 子系统 | 说明 | 关键文件 | 状态 |
+|---|--------|------|---------|------|
+| ① | **状态机** | 每台 5-10 分钟上报心跳，15 分钟无心跳判离线 | `cross_machine/status/{host}/heartbeat.json` | ✅ 已实现 |
+| ② | **事件总线** | 跨机事件日志（任务完成/错误/更新等 10 种类型） | `cross_machine/events/{date}/*.json` | ✅ 已实现 |
+| ③ | **任务协作** | 跨机任务请求/响应（异步文件机制） | `cross_machine/tasks/` | ✅ 已实现 |
+| ④ | **加密通讯** | RSA-4096 密钥对，公钥注册/私钥本地 | `cross_machine/encrypted/` | ✅ 已实现 |
+| ⑤ | **知识同步** | 双向：拉取知识库 + 推送本地新知识到收件匣 | `03_knowledge/01_submissions/` | ✅ 已实现 |
+| ⑥ | **自动升级** | 版本清单驱动，非破坏性更新自动执行 | `cross_machine/knowledge/versions.json` | ✅ 已实现 |
+| ⑦ | **文件直传** | 同局域网 SSH rsync / AirDrop 直传大文件 | `guardd/modules/transfer.py` | ✅ 已实现 |
+
+## 安全边界
+
+| 内容 | 存储位置 | 安全性 |
+|------|---------|--------|
+| 公钥 | `cross_machine/registry/*_pub.pem` | ✅ 公开安全 |
+| 加密消息 | `cross_machine/encrypted/` | ✅ 无私钥不可读 |
+| 私钥/API Key | `agent-local/identity/secrets/` | ✅ 永不共享 |
+| 记忆数据 | `agent-local/memory/` | ✅ 每机独立 |
+| 重资产 | `agent-local/tools/*/` | ✅ 不跨机同步 |
+
+## 守护进程 guardd
+
+每台机器运行 `guardd` 守护进程，负责 7 个子系统的自动化执行。
+
+- **安装**: launchd 管理，300 秒周期
+- **引擎**: 纯规则引擎，0 token 消耗
+- **路径**: `05_tools/00_setup/guardd/guardd.py`
+- **日志**: `agent-local/runtime/guardd/`
+
+### guardd 9 模块
+
+| 模块 | 职责 |
+|------|------|
+| `heartbeat` | 状态上报（CPU/内存/任务）写入 heartbeat.json + 推送 Dashboard |
+| `dashboard_sync` | 将本机 Dashboard 插件数据写入跨机共享目录 |
+| `task_worker` | 扫描本机任务并执行 |
+| `upgrade_checker` | 版本清单比对，自动/手动升级 |
+| `memory_triage` | 过滤本地记忆，推送通用内容到提交箱 |
+| `knowledge_sync` | 检测知识库变更 + 推送本地提交箱到远程 |
+| `encrypted_channel` | 解密加密消息到本地 |
+| `sync_checker` | 自动 git pull 拉取远程变更 |
+| `cleanup` | 清理 30 天以上的旧事件和已完成任务 |
+
+## 相关文件
+
+- `docs/DASHBOARD_DATA_LAYER_V2.md` — 联邦式数据架构完整设计
+- `01_core/MAINTENANCE_GUIDE.md` — guardd 运维操作手册
+- `README.md` — 系统入口（多机联邦章节）
+- `CHANGELOG.md` — V2.1 变更记录

mac-agent-os-main/03_knowledge/99_system/architecture/federation-operations-architecture.md

@@ -0,0 +1,324 @@
+---
+type: concept
+domain: system
+nature: architecture
+tags: [agentos, v3.0, federated, multi-machine, operations, orchestration]
+status: draft
+created: 2026-06-16
+updated: 2026-06-16
+version: 1.0.0
+supersedes: []
+---
+
+# AgentOS 联邦指挥台 — 操作架构设计 v1.0
+
+> 版本: 1.0.0-draft | 2026-06-16
+> 设计目标: 创建世界级的多机智能体编排系统,可扩展为大规模计算机军团
+
+---
+
+## 一、设计哲学
+
+### 核心原则
+
+1. **指挥台只负责聚合和分发,不直接执行** — 所有操作在目标机器上运行
+2. **每台机器是自治的智能体** — 离线也能独立运行,在线时接受指挥台调度
+3. **操作即状态机** — 每个操作都有明确的声明周期,可追踪、可重试、可审计
+4. **先检后动** — 操作前检查资源状态,保证不会破坏正在运行的任务
+5. **双模交互** — Dashboard(图形)和 CLI(命令行)完全对等,同一套底层
+
+### 参考架构
+
+| 来源 | 借鉴点 |
+|:-----|:-------|
+| Selenium Grid Hub-Node | 中央调度 + 分布式执行节点 |
+| Kubernetes Job/Pod | 声明式任务 + 状态机 + 日志聚合 |
+| Apache Airflow DAG | 操作依赖管理 + 重试 + 告警 |
+| Erlang/Elixir Actor | 每台机器 = 一个 Actor,通过消息通信 |
+| Unix Pipeline | 每个操作 = 一个进程,stdin/stdout/stderr |
+
+---
+
+## 二、系统架构:三层模型
+
+```
+┌──────────────────────────────────────────────────────────────────┐
+│                    Layer 1: Command Center                        │
+│  (Dashboard Web UI + CLI)                                        │
+│                                                                  │
+│  功能: 聚合展示 + 命令输入 + 日志查看 + 状态监控                │
+│  位置: chengzigedeAir (master)                                   │
+│  也支持: 任何机器浏览器打开看板,或本地 CLI 直接执行              │
+└──────────────────────┬───────────────────────────────────────────┘
+                       │ HTTP / WebSocket / SSE
+┌──────────────────────┴───────────────────────────────────────────┐
+│                    Layer 2: Orchestration Bus                     │
+│                                                                  │
+│  - federation API (REST): /api/federation/*                      │
+│  - event stream (SSE):   /api/events                             │
+│  - remote exec (SSH):    /api/federation/exec                    │
+│  - log aggregation:      每台机器推送日志到中心存储              │
+└──────────────────────┬───────────────────────────────────────────┘
+                       │ SSH / HTTP / Tailscale
+      ┌────────────────┼────────────────┐
+      ▼                ▼                ▼
+┌────────────┐ ┌────────────┐ ┌────────────┐
+│ Machine A  │ │ Machine B  │ │ Machine C  │
+│ chengzige  │ │ 5kecheng   │ │ 7kecheng   │
+├────────────┤ ├────────────┤ ├────────────┤
+│ Layer 3a   │ │ Layer 3a   │ │ Layer 3a   │
+│ Agent Daemon│ │ Agent D.  │ │ Agent D.   │
+│ (guardd)   │ │ (guardd)   │ │ (guardd)   │
+├────────────┤ ├────────────┤ ├────────────┤
+│ Layer 3b   │ │ Layer 3b   │ │ Layer 3b   │
+│ Camoufox   │ │ Camoufox   │ │ Camoufox   │
+│ Browser    │ │ Browser    │ │ Browser    │
+└────────────┘ └────────────┘ └────────────┘
+```
+
+### 每台机器上的 Agent Daemon (guardd)
+
+每台机器运行一个常驻后台进程 `guardd`,职责:
+
+| 职责 | 说明 |
+|:-----|:-----|
+| 心跳上报 | 每 300s 写一次 heartbeat.json,含 CPU/内存/磁盘/任务状态 |
+| 操作队列 | 接收指挥台下发的操作,排队执行 |
+| 资源锁 | 管理浏览器实例/账号的使用状态,防止冲突 |
+| 日志推送 | 操作日志实时推送到中心日志存储 |
+| 状态归零 | 操作完成后清理浏览器进程、还原环境 |
+
+---
+
+## 三、操作状态机
+
+### 所有操作的通用生命周期
+
+```
+                  ┌──────────┐
+                  │  pending  │  ← 用户下发操作,等待调度
+                  └────┬─────┘
+                       ↓
+                  ┌──────────┐
+         ┌──────→│ checking │  ← 检查目标机器状态、资源可用性
+         │       └────┬─────┘
+         │            ↓
+         │       ┌──────────┐
+         │       │preparing │  ← 关闭旧浏览器、清理缓存、锁资源
+         │       └────┬─────┘
+         │            ↓
+         │       ┌──────────┐
+         │    ┌─→│ running  │  ← 操作执行中(浏览器打开/脚本运行)
+         │    │  └────┬─────┘
+         │    │       ↓
+         │    │  ┌──────────┐     ┌──────────┐
+         │    │  │completed │ 或  │  failed  │  ← 成功完成或出错
+         │    │  └────┬─────┘     └────┬─────┘
+         │    │       ↓                ↓
+         │    │  ┌──────────┐     ┌──────────┐
+         │    │  │ cleaning │     │ cleaning │  ← 清理资源、释放锁
+         │    │  └────┬─────┘     └────┬─────┘
+         │    │       ↓                ↓
+         │    │  ┌──────────┐     ┌──────────┐
+         │    └──│  done    │     │  error   │
+         │       └──────────┘     └──────────┘
+         │
+         └── 任何阶段都可被"取消"或"超时"
+             超时后进入 cleaning → error
+```
+
+### 状态转换规则
+
+| 转换 | 触发条件 | 动作 |
+|:-----|:---------|:-----|
+| pending → checking | 调度器获取执行权 | 读取目标机器心跳、检查是否有其他任务在跑 |
+| checking → preparing | 资源检查通过 | 发送 prepare 命令到目标机器 |
+| checking → pending | 资源忙 | 重新排队,等待重试 |
+| checking → failed | 目标机器离线 | 标记失败,通知用户 |
+| preparing → running | 准备完成 | 执行具体操作 |
+| running → completed | 正常结束 | 收集结果 |
+| running → failed | 异常退出 | 收集错误信息 |
+| * → cleaning | 任何非 done 状态的完成 | 执行清理脚本 |
+| cleaning → done | 清理完成 | 更新最终状态 |
+| * → failed | 超时(默认 30min) | 强行终止,清理 |
+
+---
+
+## 四、资源管理
+
+### 资源类型
+
+| 资源 | 粒度 | 冲突规则 |
+|:-----|:-----|:---------|
+| 浏览器实例 | 每机器 1 个 Camoufox | 全局互斥——同一台机器不能开两个浏览器 |
+| 账号登录态 | 每个 account_id | 同一账号不能同时被两个操作使用 |
+| 身份指纹 | 每个 identity_dir | 同一身份不能同时被两个浏览器使用 |
+| 键盘/鼠标 | 每机器独占 | 远程操作时锁定本地输入(可选) |
+
+### 资源锁实现
+
+```python
+# 每台机器上的  guardd 维护的锁表
+locks = {
+    "browser": {"held_by": "task_001", "acquired_at": "2026-06-16T18:00:00"},
+    "account:douyin_01": {"held_by": "task_001", "acquired_at": "..."},
+    "identity:douyin_01_camo": {"held_by": "task_001", "acquired_at": "..."},
+}
+```
+
+### 状态归零 (Pre-flight Reset)
+
+每个操作执行前,目标机器必须执行:
+
+1. **检查是否有残留浏览器进程** — `pkill -f camoufox` (如果有, kill)
+2. **检查是否有残留的 Playwright 进程** — `pkill -f playwright`
+3. **检查账号登录锁** — 清除该账号的锁
+4. **清理临时文件** — 删除上次操作的临时缓存
+5. **重置代理状态** — 恢复默认代理配置
+6. **确认资源可用** — 返回"已就绪"状态
+
+---
+
+## 五、操作类型全表
+
+| 操作 | 类型 | 机器 | 状态管理 | 并发 | 超时 |
+|:-----|:-----|:-----|:---------|:----|:-----|
+| 账号登录 | A 本机浏览器 | assigned_machine | 锁 browser + 锁 account | 1 账号/次 | 120s |
+| 养号执行 | A 本机浏览器 | assigned_machine | 锁 browser + 锁 identity | 1 身份/次 | 60min |
+| 信息采集 | B 远程脚本 | 任意在线机器 | 只读,无需锁 | 并发 | 60s |
+| 内容发布 | A 本机浏览器 | assigned_machine | 锁 browser + 锁 account | 1 账号/次 | 300s |
+| 环境同步 | B 远程脚本 | 指定机器 | 互斥(同一机器不能同时同步) | 1 台/次 | 120s |
+| 对账检查 | B 远程脚本 | 指定机器 | 只读,无需锁 | 并发 | 60s |
+| 远程Shell | B 远程脚本 | 指定机器 | 无锁 | 并发 | 30s |
+| 状态监控 | C 聚合 | 所有机器 | 只读 | 并发 | 10s |
+
+---
+
+## 六、日志与审计
+
+### 日志结构
+
+每个操作产生一条结构化日志:
+
+```json
+{
+  "operation_id": "op_20260616_001",
+  "type": "account_login",
+  "target_machine": "5kechengdeAir",
+  "target_account": "douyin_01",
+  "status": "completed",
+  "states": [
+    {"state": "pending", "time": "18:00:00"},
+    {"state": "checking", "time": "18:00:01"},
+    {"state": "preparing", "time": "18:00:02"},
+    {"state": "running",  "time": "18:00:05"},
+    {"state": "completed","time": "18:01:15"},
+    {"state": "cleaning", "time": "18:01:16"},
+    {"state": "done",     "time": "18:01:17"}
+  ],
+  "output": "login successful, cookie saved",
+  "error": null,
+  "triggered_by": "dashboard_user",
+  "duration_sec": 77
+}
+```
+
+### 日志聚合
+
+- 每台机器的 guardd 实时推送日志到中心 `/api/logs/push`
+- Dashboard 提供日志查看器: 按机器/操作/时间/状态过滤
+- 日志保留 30 天,自动归档
+
+---
+
+## 七、并发与互斥策略
+
+| 场景 | 策略 |
+|:-----|:-----|
+| 用户点「养号」时机器已在养号 | 拒绝,提示"5kecheng 正在养号中,是否停止当前任务?" |
+| 用户点「登录」时浏览器已打开 | 先关闭浏览器,再重新打开 |
+| 两台机器同时给同一账号发命令 | 不可能——账号只属于一台机器(ORACLE.yaml) |
+| 用户从 Dashboard 和 CLI 同时操作 | 共享同一资源锁表,后到者等待或拒绝 |
+| 机器离线时下发操作 | 缓存到队列,机器上线后自动执行(可选) |
+
+---
+
+## 八、安全与锁定
+
+### 远程操作时的机器锁定
+
+当通过 Dashboard 远程控制 5kechengdeAir 执行浏览器操作时:
+
+| 安全措施 | 实现 |
+|:---------|:-----|
+| 键盘锁定 | 操作开始时,5kecheng 本地键盘暂时屏蔽(防止误触) |
+| 屏幕提示 | 5kecheng 显示器显示"正在被远程控制"的提示 |
+| 强制停止 | 任何时候按 Ctrl+C 或点击「停止」终止操作 |
+| 超时自动释放 | 30min 无活动自动关闭浏览器并释放锁 |
+
+### 注意
+
+键盘锁定是进阶功能。初期先实现资源锁+状态机,锁定后续再做。
+
+---
+
+## 九、Dashboard 落地计划
+
+### Phase 1: 状态感知 (优先级最高)
+- [x] 三台机器心跳检测 (guardd 已有)
+- [ ] 机器状态条: 每个视图顶部显示三台机器在线/离线/忙碌
+- [ ] 账号级别的忙碌状态 (是否正在被操作)
+
+### Phase 2: 操作路由 (当前)
+- [ ] `accountLogin()` 加 owner_machine 判断 + 远程执行
+- [ ] `clearCookies()` 加 owner_machine 判断
+- [ ] `deleteAccount()` 加 owner_machine 判断
+- [ ] 按钮状态: 远程账号显示"需在 XX 机器操作"或"远程执行"
+
+### Phase 3: 状态机引擎
+- [ ] 统一的操作队列: `pending → checking → running → done`
+- [ ] 资源锁: 账号级别和浏览器级别
+- [ ] 操作前的 state reset (清理旧进程)
+- [ ] 操作日志存储 + 查看器
+
+### Phase 4: 高级功能
+- [ ] 键盘锁定 / 屏幕提示
+- [ ] 离线队列 / 上线自动执行
+- [ ] 操作 DAG (先后依赖)
+- [ ] 多用户协作
+
+---
+
+## 附录: 参考的原始架构文档
+
+本文设计参考了以下原有系统文档中的思想:
+
+| 文档 | 关键借鉴 |
+|:-----|:---------|
+| `architecture/federated-multi-machine-architecture.md` | 7大协同子系统(心跳/事件/任务/加密/知识/升级/传输)、guardd 7模块、三层数据架构 |
+| `archive/CORE-ARCHITECTURE.md` | 目录职责边界、agent-local/agent-sync 分离原则、软链接映射、技能分类 |
+| `dashboard-v4-design.md` | cross_machine/data/ WPRA 写入规范、9个内置插件规范、机器感知设计、24h TTL 过期策略 |
+| `COMMAND-CENTER-PLAN.md` (99_system/) | 命名空间分层(agentos matrix/ave/crawl/fleet/serve) |
+| `cross_machine/ARCHITECTURE-v2.md` (04_memory/) | WPRA 写分区·读聚合模型、Git 冲突消除方案 |
+
+### 本次设计新增的概念
+
+| 概念 | 来源 | 说明 |
+|:-----|:-----|:------|
+| 操作状态机 | 新建 | pending→checking→preparing→running→completed→cleaning→done 完整生命周期 |
+| 资源锁 | 新建 | 浏览器级/账号级/身份级互斥,防止冲突操作 |
+| 状态归零 | 新建 | 操作前自动清理残留进程、释放锁、重置环境 |
+| 操作路由 | 新建 | 根据 owner_machine 将操作路由到对应机器执行 |
+| 双模对等 | 新建 | Dashboard 和 CLI 共享同一套底层 API |
+
+---
+
+## 十一、关键设计决策记录
+
+| 决策 | 选项 | 选择 | 理由 |
+|:-----|:-----|:-----|:------|
+| 操作同步还是异步? | 同步等待 / 异步队列 | **混合**: 短操作(<10s)同步,长操作异步 | 登录等短操作需要实时反馈 |
+| 远程执行通道 | SSH / HTTP / WebSocket | **SSH** (现有) + **HTTP API** (未来) | SSH 已打通,HTTP 需要额外服务 |
+| 状态存储 | Redis / SQLite / 文件 | **文件** (现有 heartbeats/目录) | 零依赖,随 Git 同步 |
+| 浏览器管理 | 每机器 1 个 / 多实例 | **1 个 Camoufox,轮流使用** | 指纹一致性,避免被检测 |
+| CLI 与 Dashboard 关系 | 主从 / 对等 | **对等**—同一套底层 API | CLI 无网络时也能用 |

mac-agent-os-main/03_knowledge/99_system/architecture/loading-architecture.md

@@ -0,0 +1,116 @@
+---
+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|触发词匹配方案对比分析]]

mac-agent-os-main/03_knowledge/99_system/architecture/login-system-tech-map.md

@@ -0,0 +1,216 @@
+---
+type: concept
+domain: system
+nature: architecture
+tags: [agentos, v3.0, matrix, login, auth, sms]
+status: draft
+created: 2026-06-16
+updated: 2026-06-16
+version: 1.0.0
+---
+
+# AgentOS 联邦登录系统 — 技术图谱 v1.0
+
+> 目标: 全自动跨平台登录，智能匹配登录方式，零人工介入
+
+---
+
+## 一、现有代码结构总览
+
+```
+scripts/
+├── login_identity.py              # 手动登录（旧，等待用户按Enter）
+├── auth_manager.py                # 登录态检测原子模块 ✅
+├── cdp_connector.py               # 浏览器连接器（Camoufox持久化/CDP）✅
+│
+├── matrix_modules/account/
+│   ├── douyin_login.py            # 抖音自动登录（含SMS）✅ 核心
+│   ├── xiaohongshu_login.py       # 小红书自动登录 ❌ 缺失
+│   ├── sms_login.py               # SMS验证码原子操作 ✅ 核心
+│   └── sms/
+│       ├── __init__.py            # 统一导出
+│       ├── base.py                # SMSHandler 抽象基类
+│       └── api.py                 # ApiSMSHandler API轮询 ✅ 核心
+│
+├── dashboard/plugins/
+│   └── sms_proxy_api.py           # Dashboard登录API（调的是旧脚本）⚠️
+│
+└── archive/
+    ├── scan_login.py              # 扫码登录（归档）📦
+    └── test_sms_login.py          # 短信登录测试（归档）📦
+```
+
+## 二、平台登录流程对比
+
+### 2.1 抖音登录（已有 douyin_login.py）
+
+```
+前置检测:
+  1. 读取 accounts.yaml → 手机号
+  2. 创建/确认身份目录
+  3. 启动 Camoufox 持久化浏览器
+
+执行流程:
+  1. 导航 https://www.douyin.com/
+  2. 等待6秒 → 检测登录面板 #login-panel-new
+  3. 如果已经登录（检测 data-e2e=user-avatar）→ 跳过
+  4. 没检测到面板 → 等待15秒让用户手动点"登录"
+  5. 检测到面板 → 调用 sms_login 流程
+
+SMS登录子流程 (sms_login.py):
+  Step 1: 点"一键登录"按钮
+  Step 2: 等待验证码输入框出现
+  Step 3: ApiSMSHandler 轮询获取验证码（最多3次，超时重发）
+  Step 4: 填入验证码（JS设置value+dispatchEvent）
+  Step 5: 点确认（DOM点击 → 系统级鼠标兜底）
+  Step 6: 验证登录态（面板消失+有头像）
+
+后置处理:
+  - 写操作日志 login_log.jsonl
+  - 采集用户资料 ProfileScraper
+  - 浏览器保持打开
+```
+
+### 2.2 小红书登录（缺失）
+
+```
+当前状态:
+  - 无独立入口脚本
+  - sms_login.py 的原子操作可复用（点击按钮/填验证码/点确认）
+  - 登录面板检测、一键登录、URL导航需要适配
+
+差异点:
+  - 登录URL不同: https://www.xiaohongshu.com/explore
+  - 登录面板CSS选择器不同
+  - "一键登录"按钮文本可能不同
+  - 登录态Cookie名不同: a1 / web_session
+```
+
+### 2.3 扫码登录（归档）
+
+```
+archive/scan_login.py 已实现:
+  - 生成二维码
+  - 检测扫码结果
+  - 确认登录
+
+适用场景: 桌面端抖音扫码登录
+```
+
+## 三、登录态检测体系
+
+### 3.1 四维状态检测（当前 sms_proxy_api.py）
+
+| 维度 | 检测方式 | 判断依据 |
+|:-----|:---------|:---------|
+| has_identity | 文件夹存在性 | `identities/{name}/user_data/` 是否存在 |
+| has_cookie | Firefox cookies.sqlite | `SELECT count(*) FROM moz_cookies WHERE name LIKE '%session%'` |
+| has_profile | 文件存在性 | `user_data/profiles.yaml` 是否存在 |
+| has_registry | 注册表存在性 | 账号是否在 accounts.yaml 注册 |
+
+### 3.2 Cookie 级检测（auth_manager.py）
+
+| 平台 | 关键Cookie | 检测方式 |
+|:-----|:-----------|:---------|
+| 抖音 | `sessionid`, `sid_guard` | Cookie名匹配 |
+| 小红书 | `a1`, `web_session` | Cookie名匹配 |
+
+### 3.3 DOM 级检测（auth_manager.py）
+
+| 平台 | 选择器 | 说明 |
+|:-----|:-------|:-----|
+| 抖音 | `[data-e2e='user-avatar']` | 主指示器 |
+| 抖音 | `[data-e2e='user-detail']` | 备用 |
+| 小红书 | `.user-avatar` | 头像元素 |
+| 小红书 | `.reds-count` | 计数元素 |
+
+### 3.4 综合检测逻辑 (get_login_status)
+
+```
+Cookie 检测ok 且 DOM 检测ok → method='both'
+Cookie 检测ok               → method='cookie'
+DOM 检测ok                  → method='dom'
+兜底: Cookie数量 > 30       → 判定已登录
+```
+
+## 四、需要补充的环节
+
+### P0: Dashboard 调正确脚本
+```
+当前:  /api/matrix/accounts/{id}/login → login_identity.py（手动）
+预期:  根据 platform 自动路由:
+         douyin     → douyin_login.py（全自动）
+         xiaohongshu → xiaohongshu_login.py（待创建）
+```
+
+### P0: 小红书入口脚本 (xiaohongshu_login.py)
+```
+复用 douyin_login.py 框架 + sms_login.py，仅修改:
+  - 平台URL → xiaohongshu.com/explore
+  - 登录面板选择器 → 小红书专用
+  - 一键登录按钮文本 → 适配小红书
+  - Cookie规则 → auth_manager 已有
+```
+
+### P1: 智能匹配引擎
+```
+根据账号信息自动选择登录方式:
+  1. 已登录 → 跳过（检测 has_cookie + 验证过期）
+  2. 有身份无Cookie → 按平台执行自动登录
+  3. 首次登录 → 创建身份 → 自动登录
+  4. 短信登录 → 自动触发短信 → 轮询获取 → 自动填入
+  5. 扫码兜底 → 检测平台是否支持扫码
+```
+
+### P1: 过期session检测
+```
+方法: 在登录页检测"已登录"状态后，导航到个人中心
+      检查是否可加载用户信息（不发敏感请求）
+      如果跳转到登录页 → session过期
+```
+
+### P2: 跨机路由
+```
+远程机器登录:
+  Dashboard → fire-and-forget 发送命令
+  远程机器 → 执行 douyin_login.py
+  完成后 → 更新本地 has_cookie 状态
+```
+
+## 五、当前系统完整调用链
+
+```
+Dashboard 🔑 点击
+  ↓
+POST /api/matrix/accounts/{id}/login
+  ↓
+sms_proxy_api.py: api_account_login()
+  ↓
+subprocess.Popen([agent-os python, -m, mc, account, login, {id}])
+  ↓  (当前链路)
+mc/cli.py: cmd_login()
+  ↓
+subprocess.Popen([sys.executable, login_identity.py, {id}, --platform {p}])
+  ↓
+login_identity.py → 开Camoufox → 等Enter → 检测Cookie → 退出
+  ⚠️ 需要人按Enter，不是全自动
+
+  ↓  (目标链路)
+mc/cli.py: 新增路由 → 检测platform
+  ↓  douyin
+douyin_login.py → 开Camoufox → 自动点一键登录 → 自动收短信 → 自动填 → 自动确认 → 自动验证
+  ↓  xiaohongshu (待创建)
+xiaohongshu_login.py → 同上逻辑
+```
+
+## 六、设计原则（不改原有代码，只加新功能）
+
+1. **原有脚本不动** — `login_identity.py` 保留，通过新入口分流
+2. **新增平台脚本** — 按 `douyin_login.py` 模板创建 `xiaohongshu_login.py`
+3. **智能分流** — `mc account login` 检测 platform 自动路由
+4. **逐步替换** — 新流程跑通后再切换 Dashboard 默认调用
+5. **兜底机制** — 自动流程失败后提示用户手动操作
+
+---
+
+*版本: 1.0.0-draft | 2026-06-16*

mac-agent-os-main/03_knowledge/99_system/architecture/trigger-matching-analysis.md

@@ -0,0 +1,133 @@
+# 触发词匹配方案：关键词 vs 语义相似度
+
+> 版本：v1.0 | 最后更新：2026-05-03
+
+---
+
+## 一、现状：关键词匹配
+
+**工作原理**：SOUL.md 中列出触发词列表，检测用户输入中是否包含这些词。
+
+| 类别 | 触发词 |
+|------|--------|
+| 升维审视 | 升维思考、第一性原理、前提挑战、深层原因、本质是什么、批判地看 |
+| 跨域联想 | 跨界视角、换个角度、类比一下、新视角、别的领域、借鉴一下 |
+| 知识操作 | 入库、记录这条、保存知识、知识审查 |
+
+### 优点
+- **零延迟**：字符串匹配，毫秒级
+- **零依赖**：不需要调用任何模型
+- **确定性**：100% 可预测，不会误触发
+
+### 缺点
+- **漏匹配**：用户说"换个思路"不会触发"换个角度"；说"从别的学科看看"不会触发"跨界视角"
+- **维护成本**：需要人工维护触发词列表，不断追加变体
+- **僵化**：没法处理同义表达
+
+---
+
+## 二、升级方案：语义相似度匹配
+
+**工作原理**：用现有 Qwen3-Embedding-0.6B 模型，把用户消息转为向量，与触发类别种子词的向量计算相似度。
+
+### 架构
+
+```
+用户消息: "从这个角度看有点像生物学里的共生关系"
+    ↓
+调 Embedding API → 转为 1024 维向量
+    ↓
+与各触发类别的种子词向量做余弦相似度
+    ↓
+跨域联想类别: 相似度 0.89（阈值 0.8）→ 触发 ✅
+升维审视类别: 相似度 0.45 → 不触发 ❌
+```
+
+### 种子词设计
+
+| 类别 | 种子词（3-5 个示例，模型自动泛化） |
+|------|-----------------------------------|
+| 升维审视 | 升维、本质、第一性原理、前提挑战、深层原因 |
+| 跨域联想 | 跨界、类比、换个角度、别的领域、借鉴 |
+| 知识操作 | 入库、记录、保存、知识审查 |
+
+不需要穷举，Embedding 模型会自动处理近义词。
+
+### 优点
+
+| 维度 | 关键词匹配 | 语义相似度 |
+|------|-----------|-----------|
+| 覆盖范围 | 仅精确匹配列表中的词 | 自动覆盖同义词、近义表达 |
+| 维护成本 | 需手动追加变体 | 种子词固定，无需频繁维护 |
+| 灵活性 | 僵化 | 自然 |
+
+### 缺点
+
+| 维度 | 影响 | 评估 |
+|------|------|------|
+| 延迟 | 每次调用 Embedding API | ~50-100ms，相对 LLM 响应时间（3-30s）可忽略 |
+| 依赖 | 需要 oMLX 运行 Embedding 模型 | 各机器需确保 Embedding 模型已加载 |
+| 误触发 | 语义相似但不相关的表达可能过阈值 | 可调整阈值（建议 0.8）+ 结合关键词兜底 |
+| 实现复杂度 | 需维护种子词向量 + 相似度计算逻辑 | 约 50 行 Python 代码 |
+
+---
+
+## 三、速度影响实测
+
+```
+纯关键词匹配:        0ms
++ Embedding API 调用: 50-100ms
+LLM 生成响应:        3,000-30,000ms
+
+增加的比例: 约 0.3%-3% → 无感知
+```
+
+**结论：对用户体验无影响。**
+
+---
+
+## 四、建议方案：混合匹配
+
+```
+收到用户消息
+    ↓
+第一步：关键词快速匹配（0ms）
+  ├─ 命中 → 直接触发 ✅（极速）
+  └─ 未命中 → 进入第二步
+              ↓
+第二步：语义相似度计算（50-100ms）
+  ├─ 相似度 ≥ 0.8 → 触发 ✅
+  └─ 相似度 < 0.8 → 不触发 ❌
+```
+
+### 好处
+- 常见触发词（用户明确说的）0ms 响应
+- 边缘表达也能覆盖（语义泛化）
+- 关键词作为第一道防线，减少 Embedding 调用频率
+
+---
+
+## 五、多机同步影响
+
+| 项目 | 影响 | 说明 |
+|------|------|------|
+| **触发词列表** | ❌ 不需要修改 | 种子词写在 SOUL.md 中，Git 同步即可 |
+| **种子词向量** | ⚠️ 需每台机器生成 | 各机器第一次使用时自动计算并缓存 |
+| **Embedding 模型** | ✅ 各机器已有 | Qwen3-Embedding-0.6B 已在 oMLX 中加载 |
+| **相似度计算代码** | ⚠️ 需写一个轻量脚本 | ~50 行 Python，Git 同步 |
+| **向量库** | ❌ 不受影响 | 记忆向量和知识向量不变 |
+| **知识库** | ❌ 不受影响 | 知识库内容不变 |
+
+**综合评估**：升级成本很低，无破坏性影响，各机器各自运行 Embedding 模型即可。
+
+---
+
+## 六、最终建议
+
+| 选项 | 做法 | 推荐程度 |
+|------|------|---------|
+| **A：保持关键词匹配** | 维持现状，手动维护触发词列表 | ⭐ 够用 |
+| **B：纯语义相似度** | 完全依赖 Embedding | ⭐⭐ |
+| **C：混合模式** | 关键词 + 语义兜底 | ⭐⭐⭐ **推荐** |
+
+**推荐选 C**：关键词负责"快"，语义负责"全"。先关键词匹配（0ms），未命中再调 Embedding（50-100ms）。大部分情况下用户会直接说触发词，关键词匹配就够了。