# AgentOS 核心业务架构 v4.0 — 业务领域划分与指挥体系

> **版本**: 4.0 | **更新**: 2026-06-17  
> **解决的核心问题**: 账号管理 vs 操作执行边界模糊、指挥链路不清晰、结果回传缺失

---

## 一、核心原则（先理解这个）

```
┌──────────────────────────────────────────────────────┐
│                     USER                              │
│   (Dashboard / AI Agent / CLI)                       │
└──────────┬────────────────────────────────┬───────────┘
           │                                │
           ▼                                ▼
┌──────────────────────┐    ┌──────────────────────────┐
│   🪪 账号管理层        │    │   ⚡ 操作执行层            │
│                      │    │                          │
│   只看不操作          │    │   只操作不看              │
│   - 查看账号列表      │    │   - 养号（日常活跃）      │
│   - 查看状态          │    │   - 信息采集              │
│   - 注册/删除         │    │   - 内容发布              │
│   - 跨机分配          │    │   - 定向评论              │
│   - 编辑配置          │    │   - 收藏点赞              │
│                      │    │   - 登录/登出             │
└──────────────────────┘    └──────────┬───────────────┘
                                       │
                                       ▼
                              ┌──────────────────┐
                              │   统一执行引擎     │
                              │   mc run / mc ops │
                              └──────────────────┘
```

**关键约束（解决了用户的困惑）：**

1. **账号管理 = 只读 + 配置**。它显示账号的登录状态、Cookie 有效性、昵称、上次采集时间，但不触发任何操作。
2. **信息采集是操作，不是管理**。采集应该放在「操作执行层」作为一个独立的操作类型，不应该混在账号管理里。
3. **所有操作走统一指挥体系**。无论是养号、采集、发布、评论，底层都走同一个执行引擎，只是参数不同。

---

## 二、业务领域划分

### 领域 1：账号管理 🪪 — "只看不操作"

| 功能   | 说明                                  | API                                       |
| :--- | :---------------------------------- | :---------------------------------------- |
| 账号列表 | 显示所有账号（跨机聚合）+ 登录状态 + Cookie状态 + 昵称  | `GET /api/matrix/accounts`                |
| 注册账号 | 在本机或指定机器创建新账号                       | `POST /api/matrix/accounts`               |
| 删除账号 | 删除账号 + 可选删除身份目录                     | `DELETE /api/matrix/accounts/{id}`        |
| 编辑账号 | 修改 phone / platform / owner_machine | `PUT /api/matrix/accounts/{id}`           |
| 跨机分配 | 将账号从一个机器移到另一个                       | `POST /api/matrix/accounts/{id}/relocate` |
| 身份管理 | 查看/编辑身份目录                           | `POST /api/matrix/identities`             |

**当前状态**: 这部分已有完整前后端，需要的是**和采集解耦**。

---

### 领域 2：操作执行 ⚡ — "只操作不看"

所有操作共享相同的执行基础设施：

```
All Ops → POST /api/ops/run → 自动路由(本机subprocess/远程SSH) → 执行 → 写结果文件
                                ↓
                          GET /api/ops/status   ← 轮询结果
                          GET /api/ops/results  ← 获取结果
                          GET /api/ops/log/{id} ← 查看日志
```

#### 操作类型清单

| 操作 | 命令 | 蓝图 | 说明 |
|:-----|:------|:------|:------|
| 🏃 养号执行 | `mc run --accounts=X --blueprints=Y` | douyin_daily / xhs_daily | 浏览、滑动、点赞、关注等日常活跃 |
| 📡 信息采集 | `mc collect` | — | 采集账号主页信息（昵称/粉丝数/作品数） |
| 📤 内容发布 | `mc publish` | — | 发布视频/图文到已登录账号 |
| 💬 定向评论 | `mc task comment` | — | 在指定作品下发表评论 |
| ❤️ 收藏点赞 | `mc task like/favorite` | — | 对指定内容点赞/收藏 |
| 🔑 登录/登出 | `mc smart-login` / `mc account logout` | — | 管理账号登录态 |

**关键设计**：所有操作通过 `POST /api/ops/run` 这一个入口，用 `type` 参数区分操作类型。

---

## 三、统一指挥体系（解决了"一台指挥三台"的问题）

### 3.1 当前架构（已实现）

```
Dashboard → /api/ops/run
  → 解析 type + accounts + params
  → 按 owner_machine 路由到各机器
  → 本机: subprocess.Popen  → nurture_runner.sh
  → 远程: SSH → remote_exec → nurture_runner.sh
  → 结果写入: ~/agent-local/runtime/ops/{type}_{timestamp}_{account}.json
```

### 3.2 同一个 API 处理所有操作

```
POST /api/ops/run
{
  "type": "nurture"|"collect"|"publish"|"comment"|"like",
  "accounts": ["douyin_01", "xhs_01"],
  "params": {
    "blueprint": "douyin_daily",   // 仅 nurture 用
    "rounds": 10,                  // 仅 nurture 用
    "url": "...",                  // 仅 comment/like 用
    "content": "..."               // 仅 comment 用
  },
  "machine": "",                   // 可选，自动路由
  "dry_run": false
}
```

**返回值**：
```json
{
  "status": "started",
  "ops": [
    {"account": "douyin_01", "run_id": "nurture_123_douyin_01", "machine": "chengzigedeAir"},
    {"account": "xhs_01", "run_id": "nurture_124_xhs_01", "machine": "7kecheng"}
  ]
}
```

### 3.3 结果回传（已实现）

```
每台机器执行完后写入:
  ~/agent-local/runtime/ops/{type}_{ts}_{account}.json

Dashboard 统一查询:
  GET /api/ops/results?type=nurture&limit=10
  GET /api/ops/status
  GET /api/ops/log/{run_id}
```

**跨机结果聚合**：
- 本机结果：直接读本地文件
- 远程结果：Dashboard 通过 HTTP 轮询远程机器的 `/api/ops/results` 端点

---

## 四、Dashboard 导航视图设计（新方案）

```
📱 矩阵
├── 🪪 账号管理        ← 只读 + 注册/删除/跨机 (原 sms-proxy)
├── 🏃 养号执行        ← 日常活跃 (原 nurture)
├── 📡 信息采集        ← 采集主页信息 (原 collect)
├── 📤 内容发布        ← 发作品 (原 publish)
├── 💬 定向评论        ← 评论 (原 comment)
├── ❤️ 收藏点赞        ← 点赞收藏 (新建)
├── 📋 蓝图管理        ← 编排原子操作 (原 blueprints)
├── 🔑 登录管理        ← 查看/管理登录态 (新建)
└── ⏱ 定时任务        ← 定时执行以上任何操作 (原 schedule)
```

**「账号管理」只做这些**：
✅ 查看所有账号（三机聚合）
✅ 显示昵称 / 手机号 / 登录态 / Cookie状态 / 上次采集时间
✅ 注册新账号
✅ 删除账号（可选删身份目录）
✅ 编辑账号（改平台/机器/备注）
✅ 跨机迁移

❌ **不做**：信息采集、养号执行、评论、发布（这些归到对应的操作视图）

---

## 五、「联邦指挥台」概念

一个独立的指挥视图，统一操作入口：

```
┌──────── 联邦指挥台 ────────┐
│                            │
│  目标机器: [▼全部/本机/7k] │
│  操作类型: [▼养号/采集/...] │
│  账号筛选: [按平台/机器...] │
│  参数设置: [轮数/蓝图...]   │
│                            │
│  [🚀 批量执行]             │
│                            │
│  执行记录:                 │
│  ┌──────────────────────┐ │
│  │ 12:30 douyin_01 ✅ 完成│ │
│  │ 12:30 xhs_01   ⏳ 执行│ │
│  │ 12:28 douyin_02 ❌ 失败│ │
│  └──────────────────────┘ │
└────────────────────────────┘
```

但这**不替代**各操作专用视图。专用视图提供更多操作特定参数（比如评论要有内容输入框、发布要有文件上传）。联邦指挥台用于快速批量操作。

---

## 六、执行计划（按此逐步落地）

### Phase 1（当前阶段）：统一 ops API + 结果追踪
| # | 事项 | 状态 |
|:-:|:-----|:-----|
| 1 | 账号管理解除采集耦合 | 🔴 待做 |
| 2 | `POST /api/ops/run` 统一入口 | 🟡 部分（已做 nurture） |
| 3 | `GET /api/ops/results` 结果查询 | ✅ 已实现 |
| 4 | `GET /api/ops/status` 状态查询 | ✅ 已实现 |
| 5 | `GET /api/ops/log/{id}` 日志查看 | ✅ 已实现 |

### Phase 2：各操作视图完善
| # | 事项 | 优先级 |
|:-:|:-----|:-------|
| 1 | 信息采集视图（独立于账号管理） | P0 |
| 2 | 收藏点赞视图（新建） | P1 |
| 3 | 登录管理视图（查看+批量登录） | P1 |
| 4 | 联邦指挥台（统一批量操作入口） | P2 |

### Phase 3：跨机结果聚合
| # | 事项 | 优先级 |
|:-:|:-----|:-------|
| 1 | 远程机器结果通过 HTTP 聚合到本机 Dashboard | P1 |
| 2 | 联邦指挥台显示所有机器的执行历史和状态 | P2 |