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 带网关原话 / 正常返回）。
369 lines
15 KiB
Markdown
369 lines
15 KiB
Markdown
# AgentOS 功能节点全量拆解与优化评估
|
||
|
||
> 版本：v1.0 | 最后更新：2026-06-15
|
||
> 用途：逐条评估每个功能节点的现状、问题、优化方向、难度、影响范围
|
||
|
||
---
|
||
|
||
## 符号说明
|
||
|
||
| 标记 | 含义 |
|
||
|:----:|:------|
|
||
| ⭐ | 难度：★易～★★★★★极难 |
|
||
| 📐 | 影响范围：局部/模块/系统/跨机 |
|
||
| 🔗 | 依赖关系：该节点优化后会影响的其他节点 |
|
||
| 🎯 | 核心痛点：当前最突出的问题 |
|
||
|
||
---
|
||
|
||
## 一、代码仓储与同步（底层基础设施）
|
||
|
||
### 1.1 Git 仓库管理
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 单仓库 ~1GB（含 .git 409MB + 工作树 594MB），包含浏览器缓存 `.so` 文件 |
|
||
| **问题** | push 超时、clone 慢、冲突频繁、新机器部署痛苦 |
|
||
| **目标** | 纯代码仓库 ≤50MB，运行时数据不入库 |
|
||
| **方案** | ① 更新 .gitignore ② git filter-branch 清除历史大文件 ③ 配置 git-lfs 管理大文件 |
|
||
| **难度** | ⭐⭐（git filter-branch 需谨慎操作，建议先备份） |
|
||
| **影响** | 📐 跨机 — 所有机器 clone/push 速度提升 10x |
|
||
| **🔗 连锁** | → 路径统一(1.3) → 依赖管理(1.4) 前置条件 |
|
||
|
||
### 1.2 多机同步机制
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | WPRA 写分区·读聚合 v2.0。每台机器写 machines/{uid}/，Dashboard 聚合读取。但 guardd 仍有全局写入 |
|
||
| **问题** | `_registry.json` 历史冲突、`git add -A` 跨文件 staging、架构复杂 |
|
||
| **目标** | 废除 WPRA 写入端，改为 ORACLE 只读 + heartbeat 仅汇报 |
|
||
| **方案** | ① 创建 ORACLE.yaml（只读宪法）② 每台机器读 ORACLE 对账 ③ heartbeat 精简为仅状态汇报 ④ 删除 WPRA 写入代码 |
|
||
| **难度** | ⭐⭐⭐（涉及 guardd、Dashboard、matrix_mgmt 多个模块修改） |
|
||
| **影响** | 📐 系统 — 消除 Git 冲突根源，简化整体架构 |
|
||
| **🔗 连锁** | → 影响所有涉及多机数据同步的模块 |
|
||
|
||
### 1.3 路径统一
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 12+ 处 `Path.home() / "workbuddy-agent-os"` 硬编码在 app.py，其他文件更多 |
|
||
| **问题** | 每台机器 home 目录/结构不同，改一台其他都断 |
|
||
| **目标** | 所有代码使用 `$AGENT_SYNC` / `$AGENT_LOCAL` 环境变量 |
|
||
| **方案** | ① 在 .zshrc 定义环境变量 ② 批量替换所有脚本中的硬编码路径 ③ Dashboard base.py 已经定义了常量，推广使用 |
|
||
| **难度** | ⭐（机械替换，但需全面扫描所有文件） |
|
||
| **影响** | 📐 跨机 — 解决 80% 的跨机兼容性问题 |
|
||
| **🔗 连锁** | → 是其他所有优化的前置条件 |
|
||
|
||
### 1.4 依赖与环境管理
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | Python 3.9(系统) + 3.13(管理) 并存，orjson 签名问题，Camoufox 依赖复杂 |
|
||
| **问题** | 新机器部署步骤多，环境不一致导致同一代码表现不同 |
|
||
| **目标** | 一键检测+安装+修复环境 |
|
||
| **方案** | 升级 init.sh：检测 Python/Node/依赖/签名问题，自动修复或报清晰错误 |
|
||
| **难度** | ⭐⭐（编写检测逻辑，测试各机器） |
|
||
| **影响** | 📐 局部 — 降低新机器部署时间从 2 小时到 10 分钟 |
|
||
| **🔗 连锁** | → 依赖 1.1(仓库干净) 和 1.3(路径统一) |
|
||
|
||
---
|
||
|
||
## 二、账号管理体系
|
||
|
||
### 2.1 账号注册与配置（accounts.yaml）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 本地 `agent-local/tools/matrix/config/accounts.yaml` 定义账号，WPRA 有一份拷贝 |
|
||
| **问题** | 两份数据不一致时互相覆盖，同步逻辑复杂 |
|
||
| **目标** | 单一权威来源，本地配置规范化 |
|
||
| **方案** | 废除 WPRA 的 accounts.yaml，只用本地一份。ORACLE.yaml 只定义"哪个机器有哪些身份" |
|
||
| **难度** | ⭐⭐（需修改 matrix_mgmt.py 的读取逻辑） |
|
||
| **影响** | 📐 模块 — 消除账号数据的不一致性 |
|
||
| **🔗 连锁** | → 依赖 1.2(同步机制) |
|
||
|
||
### 2.2 身份管理（Identity）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 身份按手机号聚合，一个身份可绑定多平台。已在 Dashboard 实现删除/解绑功能 |
|
||
| **问题** | 基本功能已有，但身份目录命名不一致（有的 `phone_xxx` 有的直接用账号名） |
|
||
| **目标** | 统一身份命名规范，梳理现有身份的目录结构 |
|
||
| **方案** | 将独立身份目录（douyin_133 等）统一命名为 phone_xxx，清理 xhs_01 等遗留目录 |
|
||
| **难度** | ⭐（主要是数据迁移工作，系统逻辑已支持） |
|
||
| **影响** | 📐 局部 — Dashboard 身份管理页更清晰 |
|
||
| **🔗 连锁** | → 依赖 2.1(账号配置) |
|
||
|
||
### 2.3 登录态管理
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | Cookie 存储在 `identities/{name}/user_data/cookies.sqlite`，可通过 `mc login` 扫码登录 |
|
||
| **问题** | Cookie 过期后系统不一定能及时发现，需人工检查 |
|
||
| **目标** | 自动检测 Cookie 有效性 + 登录态过期告警 |
|
||
| **方案** | 在 guardd 或定时任务中加入 Cookie 有效性检查，过期时 Dashboard 标红 |
|
||
| **难度** | ⭐⭐（需要实现 Cookie 有效性验证逻辑） |
|
||
| **影响** | 📐 局部 — 减少"以为登录了其实过期了"的情况 |
|
||
| **🔗 连锁** | → 依赖 1.4(环境) 和 2.1(账号) |
|
||
|
||
---
|
||
|
||
## 三、养号执行系统（Matrix）
|
||
|
||
### 3.1 mc CLI
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 统一 CLI 入口，10+ 子命令（run/account/blueprint/task/remote...） |
|
||
| **问题** | mc 脚本引用 `/Users/5kecheng/` 旧路径（已修复） |
|
||
| **目标** | CLI 稳定可用，路径 0 硬编码 |
|
||
| **方案** | 完成路径审计（已做了 90%），确保所有子命令都能跨机执行 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 模块 |
|
||
|
||
### 3.2 养号引擎（engine.py）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | BatchEngine 异步并行，支持 Camoufox 浏览器 + 原子操作组合 |
|
||
| **问题** | orjson 签名问题导致部分机器 Camoufox 无法启动（已修复） |
|
||
| **目标** | 稳定运行，跨机一致 |
|
||
| **方案** | 环境修复 + 更好的错误提示（不要抛 orjson 裸错误） |
|
||
| **难度** | ⭐⭐ |
|
||
| **影响** | 📐 模块 |
|
||
|
||
### 3.3 14 个蓝图
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 抖音 9 个 + 小红书 4 个 + 录制 1 个 |
|
||
| **问题** | 部分蓝图执行失败率高（如评论蓝图遇到验证码） |
|
||
| **目标** | 提高执行成功率 |
|
||
| **方案** | 增加重试机制、验证码处理、更智能的等待 |
|
||
| **难度** | ⭐⭐⭐（反爬对抗，需要持续优化） |
|
||
| **影响** | 📐 局部 |
|
||
|
||
### 3.4 日常养号调度器（nurture_daily.py）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 调度器 v1.0，支持多身份并发、随机打乱、错峰启动 |
|
||
| **问题** | 调度规则硬编码在脚本中，不与 ORACLE 联动 |
|
||
| **目标** | 调度器从 ORACLE 读取规则（什么时候跑、跑什么） |
|
||
| **方案** | nurture_daily.py 增加 `--oracle` 模式，读取 ORACLE.yaml 确定任务参数 |
|
||
| **难度** | ⭐⭐ |
|
||
| **影响** | 📐 模块 |
|
||
|
||
### 3.5 采集器（collect_batch_runner.py）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 批量主页信息采集，支持全部/按手机号/按账号 |
|
||
| **问题** | 采集进度通过本地 JSON 文件共享，与其他机器不互通 |
|
||
| **目标** | 采集结果通过心跳/ORACLE 共享 |
|
||
| **方案** | 采集完成后更新 heartbeat.json，其他机器/Dashboard 可见 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
---
|
||
|
||
## 四、Dashboard 看板
|
||
|
||
### 4.1 app.py（后端 API）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 3000+ 行单文件，包含所有 API 路由 |
|
||
| **问题** | 太大难以维护，两次出现重复路由导致功能不可用 |
|
||
| **目标** | 拆分为多个路由模块 |
|
||
| **方案** | 按功能拆分：matrix_routes.py, system_routes.py, kb_routes.py 等 |
|
||
| **难度** | ⭐⭐⭐（后端重构，需确保 API 兼容性） |
|
||
| **影响** | 📐 模块 — 提高可维护性，减少重复路由 Bug |
|
||
| **🔗 连锁** | → 依赖 1.2(同步) 的部分 API 数据源会变化 |
|
||
|
||
### 4.2 index.html（前端）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 4000+ 行单页，包含所有 UI 和交互逻辑 |
|
||
| **问题** | 巨大难以维护，HTML 注释混入 JS 导致页面黑屏 |
|
||
| **目标** | 拆分为多文件组件 |
|
||
| **方案** | 按视图拆分：matrix-accounts.html, matrix-blueprints.html, matrix-settings.html |
|
||
| **难度** | ⭐⭐⭐（需重建前端加载机制） |
|
||
| **影响** | 📐 模块 |
|
||
|
||
### 4.3 身份管理页
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | ✅ 已实现，按身份分组展示，支持删除身份/解绑平台 |
|
||
| **问题** | 基本功能可用，缺少批量操作 |
|
||
| **目标** | 稳定使用，按需扩展 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
### 4.4 命令与任务页
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 全部养号 + 批量执行 + 定向评论 三个 TAB |
|
||
| **问题** | ✅ 上次已修复重复路由导致"全部养号"不可用的问题 |
|
||
| **目标** | 稳定使用 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
---
|
||
|
||
## 五、知识库系统
|
||
|
||
### 5.1 知识库存储（03_knowledge/）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 按分类目录（00_inbox ~ 50_resources）组织，包含采集的教程、方法、参考等 |
|
||
| **问题** | 无固定分类规范，新知识入库标准不明确 |
|
||
| **目标** | 规范化分类体系 |
|
||
| **方案** | 制定知识卡片模板 + 分类规则文档 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
### 5.2 向量库（ChromaDB）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | ChromaDB + oMLX Qwen3-Embedding-0.6B，1024 维向量 |
|
||
| **问题** | 现有 1 个自动化任务（02:30 向量更新，ACTIVE），但记忆提炼的向量更新已暂停 |
|
||
| **目标** | 知识库更新后自动重建向量索引 |
|
||
| **方案** | 保留现有自动化，确保跑通 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
### 5.3 记忆系统（04_memory/）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | L1 关键词索引 + L2 facts.db + L3 原文，四层记忆体系 |
|
||
| **问题** | 原 02:00 记忆提炼已 PAUSED，向量更新也已停，记忆系统不完整 |
|
||
| **目标** | 恢复记忆提炼自动化 |
|
||
| **方案** | 调查 PAUSED 原因（oMLX 稳定性？脚本错误？）→修复→恢复 |
|
||
| **难度** | ⭐⭐（需先诊断 PAUSED 原因） |
|
||
| **影响** | 📐 系统 — 影响语义检索质量 |
|
||
| **🔗 连锁** | → 依赖 1.4(环境) oMLX 须稳定运行 |
|
||
|
||
---
|
||
|
||
## 六、远程执行与互联
|
||
|
||
### 6.1 mc remote（SSH）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | `mc remote exec/status/ping/list` 已实现，通过 SSH 执行远程命令 |
|
||
| **问题** | 需要 SSH key 配置、主机名/IP 对应关系。本机未装 Tailscale，局域网可用但公网不可达 |
|
||
| **目标** | 稳定可靠的远程执行通道 |
|
||
| **方案** | ① 本机安装 Tailscale ② 完善 mc remote 的错误处理和反馈 ③ 将远程执行集成到 Dashboard |
|
||
| **难度** | ⭐⭐（Tailscale 安装简单，完善命令需要一些工作） |
|
||
| **影响** | 📐 跨机 — 能远程控制其他机器执行养号/采集 |
|
||
| **🔗 连锁** | → 依赖 1.2(同步)，执行前需确保 ORACLE 已同步 |
|
||
|
||
### 6.2 guardd 守护进程
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 7 模块主循环：心跳 + 自动化 + 事件 + 知识同步 + 系统信息 + Git 同步 + 跨机数据 |
|
||
| **问题** | 角色过多（身兼三职），部分模块写全局文件导致 Git 冲突 |
|
||
| **目标** | 精简为"心跳 + ORACLE 对账"两个核心职责 |
|
||
| **方案** | ① 移除全局文件写入 ② 增加 ORACLE 对账逻辑 ③ 自动同步移到独立 cron |
|
||
| **难度** | ⭐⭐⭐（涉及 guardd.py 核心重构） |
|
||
| **影响** | 📐 系统 — 消除 Git 冲突根源，简化运维 |
|
||
| **🔗 连锁** | → 是所有跨机操作的核心依赖 |
|
||
|
||
---
|
||
|
||
## 七、内容生产系统
|
||
|
||
### 7.1 视频工厂（09_ave）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 服务层 API + 主程序，有独立安装脚本 |
|
||
| **问题** | 与主系统的集成度低，独立运行 |
|
||
| **目标** | 纳入 ORACLE 统一管理 |
|
||
| **方案** | 在 ORACLE 中注册视频工厂的任务，与其他任务统一调度 |
|
||
| **难度** | ⭐⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
### 7.2 内容灵感采集（content-inspiration）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 豆包浏览器驱动，采集热榜/灵感 |
|
||
| **问题** | 独立脚本，未纳入统一采集体系 |
|
||
| **目标** | 与 collect_batch_runner 合并或统一调度 |
|
||
| **难度** | ⭐⭐ |
|
||
| **影响** | 📐 局部 |
|
||
|
||
### 7.3 发布系统（social-auto-upload）
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 已克隆但未整合，当前系统中不存在可执行代码 |
|
||
| **问题** | 未接入任何流程 |
|
||
| **目标** | 评估是否需要，如需则纳入 ORACLE |
|
||
| **难度** | ⭐⭐⭐（需要从零整合） |
|
||
| **影响** | 📐 局部 |
|
||
|
||
---
|
||
|
||
## 八、底层数据层
|
||
|
||
### 8.1 agent-local 数据目录
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | 身份/Cookie/记忆/向量库/运行时数据混在 agent-local 下 |
|
||
| **问题** | 缺少统一的本地配置入口（config.yaml） |
|
||
| **目标** | 标准化 agent-local 结构 |
|
||
| **方案** | 新增 `agent-local/config.yaml` 作为本机唯一配置入口 |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 系统 — 所有读取本机配置的脚本都统一路径 |
|
||
| **🔗 连锁** | → 依赖 1.3(路径统一)，是所有模块的基础 |
|
||
|
||
### 8.2 跨机心跳文件
|
||
|
||
| 维度 | 内容 |
|
||
|:-----|:------|
|
||
| **现状** | heartbeat.json 包含大量运行时状态信息 |
|
||
| **问题** | 内容过多，且与其他机器共享时可能泄露敏感信息 |
|
||
| **目标** | 精简心跳，仅含：机器名、在线状态、当前任务、合规性 |
|
||
| **方案** | 重新设计 heartbeat.json schema |
|
||
| **难度** | ⭐ |
|
||
| **影响** | 📐 系统 |
|
||
| **🔗 连锁** | → 依赖 1.2(同步机制) |
|
||
|
||
---
|
||
|
||
## 九、优化依赖关系图
|
||
|
||
```
|
||
阶段1（基础清理，2-3天） 阶段2（架构优化，3-5天） 阶段3（功能增强，按需）
|
||
──────────────────────── ──────────────────────── ────────────────────────
|
||
1.3 路径统一 ← 无依赖 1.2 同步机制 ← 依赖阶段1 3.4 调度器 ORACLE 联动
|
||
1.1 Git 仓库减肥 6.2 guardd 精简 4.1 app.py 拆分
|
||
1.4 环境依赖管理 8.2 心跳精简 6.1 远程执行完善
|
||
8.1 本地配置标准化 2.1 账号配置规范 5.3 记忆系统恢复
|
||
ORACLE.yaml 创建
|
||
```
|
||
|
||
---
|
||
|
||
## 十、综合评估
|
||
|
||
| 维度 | 评估 |
|
||
|:-----|:------|
|
||
| **总工作量** | 阶段1: 2-3天 | 阶段2: 3-5天 | 阶段3: 按需 |
|
||
| **最大痛点** | Git 仓库 1GB + 路径硬编码（阶段1解决） |
|
||
| **最大风险** | guardd 重构（6.2）和同步机制变更（1.2）涉及面广 |
|
||
| **最小投入最大收益** | 路径统一(1.3) + Git 减肥(1.1) — 两天解决 80% 痛苦 |
|
||
| **是否可分批推进** | ✅ 三个阶段完全独立，阶段1做完即可显著改善体验 |
|