# Codex 多机协作系统详细技术选型

目标：

- 把整体技术方案从“架构概念”细化到“可以开工”的选型级别
- 明确每个核心模块建议用什么语言、数据库、中间件、向量库和部署方式
- 保持技术栈尽量少而稳，同时满足多机协作、跨设备运维、审计、多模态和硬件测试

---

## 1. 总体选型原则

1. 云端核心服务尽量少语言，优先统一到 `Python + TypeScript`。
2. 和 `Codex app-server / SDK`、硬件测试、审计链路耦合最深的服务，优先用 `Python 3.12`。
3. 手机端先做 `Web / PWA`，不要一开始就上双原生。
4. 默认先把数据平面统一到 `Postgres + pgvector`，把 `Redis / NATS / S3/MinIO` 作为后续按规模增加的能力。
5. 日志、指标、链路要从一开始就带上，不要后补。

---

## 2. 语言与框架建议

### 2.1 前端

- `TypeScript`
- `Next.js 15`
- `React 19`
- `Tailwind CSS 4`
- `shadcn/ui` 或自建轻量组件层

用途：

- 手机端 PWA
- Web 控制台
- 项目页、线程页、审批中心、节点状态页、运维中心

### 2.2 云端控制平面

- `Python 3.12`
- `FastAPI`
- `Pydantic 2`
- `SQLAlchemy 2`
- `LangGraph`

用途：

- Master Agent Runtime
- API Gateway / BFF
- 审计编排
- 运维编排
- Thread Registry / Broker 业务层

### 2.3 Worker / Gateway / Audit / Ops Agent

- `Python 3.12`

原因：

- 更适合直接对接 Codex SDK / app-server
- 更适合硬件库、串口、音视频、自动化测试工具
- 更适合复用审计与运维的同一套数据模型

推荐模块：

- `asyncio`
- `httpx`
- `websockets`
- `pydantic`
- `typer`
- `tenacity`

### 2.4 本地最小 Watchdog

优先方案：

- 先用 `Python` + 系统服务管理器实现
  - macOS: `launchd`
  - Linux / WSL2: `systemd`
  - Windows: `Task Scheduler` 或 `nssm`

后续如果要更强的单二进制守护能力，再考虑：

- `Go`

---

## 3. 数据与中间件选型

### 3.1 主数据库

推荐：

- `PostgreSQL 16`

用途：

- 项目、任务、线程镜像
- 审计请求与结果
- Capability Registry
- 运维域、运维工单、Runbook
- 主控状态、节点心跳、账号状态

原因：

- 事务能力强
- JSONB 足够灵活
- 能直接挂 `pgvector`
- 备份、高可用、迁移都成熟

### 3.2 向量库

MVP 推荐：

- `pgvector`

原因：

- 与主库同一套备份与权限体系
- 项目记忆规模在前期不会大到必须拆独立向量库
- 开发效率最高

中后期可选：

- `Qdrant`

切换条件：

- 检索量明显增长
- 需要独立分片与更强 ANN 性能
- 项目记忆规模、日志检索、经验检索都上来后

### 3.3 缓存与短任务状态

极轻云默认：

- 先不用独立 `Redis`
- 通过 `PostgreSQL 行锁 + 应用内 TTL cache` 处理

后续放大再补：

- `Redis 7`

适用用途：

- 会话级缓存
- 去重 key
- 短期锁
- SSE / WebSocket 会话映射
- 限流与节流

### 3.4 事件总线 / 跨设备指令总线

极轻云默认：

- `PostgreSQL job table + LISTEN/NOTIFY`

后续放大再升级：

- `NATS JetStream`

用途：

- 跨设备运维动作
- Worker 事件汇聚
- 审计任务触发
- Ops remote action
- 心跳广播与告警事件

说明：

- MVP 极轻云阶段，`PostgreSQL job table + LISTEN/NOTIFY` 就足够
- 当并发、订阅者数量、跨节点事件量明显上来后，再切到 `NATS JetStream`

### 3.5 对象存储

极轻云默认：

- 云主机本地磁盘做短期证据缓存
- 每日异步备份到低成本对象存储

后续放大再升级：

- `S3 兼容对象存储`
- 自管可选 `MinIO`

用途：

- 视频片段
- 音频片段
- 截图与关键帧
- 串口长日志
- 报告导出
- Patch 快照

---

## 4. 日志、指标、链路追踪

### 4.1 应用日志

MVP 推荐：

- 结构化 JSON 日志直接写文件 + 上传对象存储
- 核心 fault index 写 `Postgres`

中期推荐：

- `ClickHouse`

用途：

- 高吞吐故障检索
- fault_key 聚类
- 低 token 摘要查询

### 4.2 指标

极轻云默认：

- 先做健康探针 + 结构化指标表 + 轻量节点看板

后续放大再升级：

- `Prometheus`
- `Grafana`

用途：

- CPU / 内存 / 磁盘 / GPU
- 进程在线率
- 队列积压
- 事件流延迟
- 能力租约占用

### 4.3 链路追踪

极轻云默认：

- 关键链路先记录 `trace_id` 到结构化日志和 Postgres

后续放大再升级：

- `OpenTelemetry`
- 存储可接 `Grafana Tempo` 或兼容后端

---

## 5. 认证与密钥管理

### 5.1 节点到云端认证

推荐：

- `mTLS` 或节点签名 token

### 5.2 服务内部认证

推荐：

- `JWT` + 细粒度 service claims

### 5.3 密钥存储

推荐：

- 云上：`1Password Secrets Automation`、`Vault` 或云 KMS
- 本地节点：只保存最小必要 token，敏感密钥由云端短期签发

---

## 6. 服务到技术栈映射

| 模块 | 推荐语言 / 框架 | 存储 / 中间件 | 说明 |
|---|---|---|---|
| 手机端 / Web 控制台 | TypeScript + Next.js | SSE + BFF | 统一入口，先做 PWA |
| API Gateway / BFF | Python + FastAPI | Postgres | 聚合项目态、额度态、运维态 |
| Master Agent Runtime | Python + LangGraph | Postgres、pgvector | 项目编排与记忆 |
| Worker Daemon | Python | Postgres | 接 Codex、回传事件 |
| Thread Gateway | Python | Postgres job queue + LISTEN/NOTIFY | 线程对话与跨节点消息 |
| Audit Orchestrator | Python | Postgres | 审计任务编排 |
| Specialist Audit Agents | Python | 本地证据目录 + Postgres | 软件 / 硬件 / 多模态 |
| Capability Registry | Python | Postgres | 能力注册、租约、抢占 |
| Test Rig Gateway | Python | 本地证据目录 + Postgres | 摄像头、机器人、串口等 |
| Ops Control Plane | Python | Postgres | 主运维层控制面 |
| Local Ops Agent | Python | 本地日志 + Postgres job queue | 本地巡检与修复 |
| Local Ops Audit Agent | Python | Postgres | 复验、紧急修复判定 |
| gptpluscontrol Backend | 保持现有实现 | Postgres / API | 直接复用现有项目 |

---

## 7. 跨设备运维的技术落地

### 7.1 执行模式

跨设备运维不做成“任意节点互相 SSH”，而做成：

`Ops Control Plane -> Postgres job queue + LISTEN/NOTIFY -> target Local Ops Agent -> result -> Ops Audit Agent -> Ops Ledger`

### 7.2 远程动作能力

至少支持：

- `remote_exec`
- `remote_restart_service`
- `remote_fetch_logs`
- `remote_collect_snapshot`
- `remote_push_config`
- `remote_switch_account`
- `remote_run_runbook`

### 7.3 适配器类型

建议首批支持：

- `ssh`
- `http_api`
- `windows_service`
- `docker`
- `lan_rpc`

第二批再支持：

- `k8s`
- `adb`
- `serial_bridge`

---

## 8. 向量记忆与检索策略

### 8.1 存什么

- 项目摘要
- 关键决策
- 约束条件
- 失败复盘
- 审计结论
- 运维修复经验
- 已知故障与 runbook 关联

### 8.2 不存什么

- 全量源码原文
- 全量长日志原文
- 大体积视频

这些留在对象存储，只在需要时做摘要与引用。

### 8.3 检索策略

- 项目级记忆按 `project_id`
- 运维经验按 `fault_key`
- 审计经验按 `audit_type`
- 硬件经验按 `device_type / lab_tag`

---

## 9. 向量库迁移策略

### 9.1 能不能迁移

可以，而且建议从第一天就按“可迁移”去设计。

可迁移目标包括：

- 自建 `Postgres + pgvector`
- 自建 `Qdrant / Milvus`
- 腾讯云 `Tencent Cloud VectorDB`
- 阿里云 `PolarDB PostgreSQL + PGVector`
- 阿里云 `Milvus 版`
- 其他自建服务器上的向量库

### 9.2 为什么可以迁移

因为真正的“系统真相”不应该只存在向量库里，而应该分成两层：

- `Canonical Source`
  保存在主数据库和对象存储：
  - chunk 原文
  - chunk_id
  - project_id
  - metadata
  - embedding_model
  - embedding_dim
  - content_hash
- `Serving Vector Store`
  只是当前正在服务检索的向量后端

只要 `Canonical Source` 在，我们就可以：

- 直接导出已有向量并导入新向量库
- 或者在新向量库里重新生成 embedding 后重建索引

### 9.3 最推荐的可迁移设计

建议增加一层：

- `VectorStoreAdapter`
- `RetrievalService`

业务代码只调用 `RetrievalService`，不直接写死腾讯、阿里、pgvector、Qdrant 的 SDK。

### 9.4 迁移时怎么做

建议流程：

1. 新向量后端先建空库 / 空 collection
2. 从主数据库导出 chunk 与 metadata
3. 选择：
   - 复用原 embedding 直接导入
   - 或重新 embedding 后导入
4. 新后端做 shadow read
5. 对比召回结果与延迟
6. 通过后切主
7. 保留一段双写 / 回滚窗口

### 9.5 哪种迁移最平滑

- 从 `Postgres + pgvector` 迁到阿里云 `PolarDB PostgreSQL + PGVector`
  这条路径最平滑，因为仍然是 PostgreSQL / pgvector 体系。
- 迁到腾讯云 `VectorDB`
  也可行，但更像“后端替换”，需要通过适配层吸收查询、过滤、索引与导入方式差异。
- 迁到 `Milvus / Qdrant`
  也可行，但更适合把向量层彻底独立出去，而不是继续走“单库一体化”模式。

### 9.6 不建议怎么做

- 不要把厂商私有特性直接写进核心业务逻辑
- 不要让向量库成为唯一知识真相
- 不要把 embedding 模型版本信息丢掉

---

## 10. 为什么主数据库选 PostgreSQL，而不是 MySQL

先说结论：

不是 `MySQL` 做不到，而是对你这套系统来说，`PostgreSQL` 更顺手、更稳，也更容易和向量层放在一起演进。

### 10.1 这套系统的数据形态更像 PostgreSQL 的强项

你的系统里不只是传统表结构，还有很多半结构化对象：

- thread mirror
- 审计请求与结果
- capability metadata
- runbook 定义
- fault context
- ops domain / connector 配置

这些用 `PostgreSQL + jsonb` 更自然。PostgreSQL 官方文档也明确说过，绝大多数应用一般应优先使用 `jsonb`。  
来源：[PostgreSQL JSON Types](https://www.postgresql.org/docs/current/datatype-json.html)

### 10.2 PostgreSQL 和 pgvector 的一体化更成熟

`pgvector` 官方项目就是围绕 PostgreSQL 构建的，支持精确检索、HNSW、IVFFlat，并且能直接结合 Postgres 的 ACID、PITR、JOIN 等能力。  
来源：[pgvector GitHub](https://github.com/pgvector/pgvector)

这对我们非常重要，因为我们希望：

- 项目元数据
- 记忆向量
- 审计结构化结果
- 运维修复记录

尽量先落在一套数据库体系里。

### 10.3 后续云迁移更顺

如果我们以后迁到阿里云 `PolarDB PostgreSQL + PGVector`，路径非常平滑，因为官方就是 PostgreSQL + PGVector 体系。  
来源：[阿里云 PolarDB PGVector](https://help.aliyun.com/zh/polardb/polardb-for-postgresql/pgvector)

### 10.4 MySQL 什么时候也能选

如果你们满足这几个条件，`MySQL` 也可以：

- 团队强依赖 MySQL
- 向量层准备独立出去
- 复杂 JSON / 审计 / runbook / capability 元数据不想放主库
- 你愿意多维护一套检索后端和更多同步逻辑

但在当前这套产品里，我更建议默认 `PostgreSQL`。

---

## 11. 云服务器系统与最低配置建议

### 11.1 推荐系统

推荐主控云服务器使用：

- `Ubuntu Server 24.04 LTS`

备选：

- `Debian 12`
- `Rocky Linux 9`（如果你们团队偏 RPM 系）

不推荐：

- 用 Windows 作为主控制平面主机

### 11.2 为什么优先 Ubuntu / Debian

- `PostgreSQL + pgvector` 在 Debian / Ubuntu 体系安装最顺，官方 pgvector 也明确提供 Debian / Ubuntu 的 APT 包。  
  来源：[pgvector 安装说明](https://github.com/pgvector/pgvector)
- Python、NATS、Redis、Prometheus、Grafana、MinIO 的 Linux 运维生态更成熟
- systemd、Docker、observability 工具链都更稳

### 11.3 最低配置怎么分

这里分 3 档看：

#### A. 仅演示 / 极小规模 PoC

- `4 vCPU`
- `8 GB RAM`
- `100 GB SSD`

适用：

- 1 个主控
- 少量项目
- 2 到 3 个活跃 Worker
- 对象存储和监控可外置

#### B. 推荐 MVP 起步配置

- `8 vCPU`
- `16 GB RAM`
- `200 GB NVMe SSD`

适用：

- 控制平面
- Postgres
- Redis
- NATS
- 基础 WebSocket
- 小规模审计与运维编排

这是我最推荐的起步配置。

#### C. 更稳的生产起步

- 控制平面节点：`4 vCPU / 8-16 GB`
- 数据节点：`4-8 vCPU / 16-32 GB`
- 备用控制器：`2-4 vCPU / 4-8 GB`

也就是至少拆成 2 到 3 个角色，而不是一切都塞一台机。

### 11.4 磁盘建议

- 系统盘建议 `NVMe SSD`
- 不建议低于 `200 GB`

原因：

- 事件镜像
- 截图 / 视频 / 音频临时文件
- Postgres WAL
- 运维日志
- 审计证据缓存

都比较吃磁盘。

### 11.5 网络建议

- 优先选公网稳定、到你局域网延迟较低的地域
- 如果 Mac / Windows 都在同一局域网，云端主要扮演控制面和汇聚层，不需要极高带宽，但要稳定长连接
- 如果视频 / 音频证据频繁上传，建议至少保证稳定的上行和对象存储带宽

### 11.6 我的实际建议

如果你们现在就要启动：

- 主控云服务器先上 `Ubuntu 24.04 LTS`
- 起步配置直接用 `8 vCPU / 16 GB / 200 GB NVMe`
- 备用控制器先用 `2-4 vCPU / 4-8 GB`

这比从 `4c8g` 硬挤要稳得多。

---

## 12. 极限轻云方案（同时考虑容灾）

这部分不是“因为服务器小才降配”，而是一个更激进的原则：

无论云服务器多大，都主动把云端压缩到最轻，只保留不可替代的控制面真相；  
同时保留双云容灾，但让备云只承担接管准备，不承担常态重负载。

### 12.1 极限轻云下，云端最终只保留什么

我建议云端最终只保留这 4 类东西：

1. `控制面单体服务`
   包含：
   - BFF / API
   - Master Agent Runtime
   - Scheduler
   - Thread Registry / Broker 业务逻辑
   - Audit Orchestrator
   - Ops Control Plane
   - Quota 聚合逻辑

2. `PostgreSQL 16 + pgvector`
   同时承担：
   - 主数据库
   - 向量检索
   - job queue
   - repair ticket / audit request / thread mirror 持久化

3. `HTTP + SSE`
   - 聊天发送走 HTTP
   - 状态推送优先 SSE
   - 不在云端维持更重的实时基础设施

4. `证据索引与短期缓存`
   云端只保留证据索引、摘要和引用关系
   原始大文件尽量不在云端长期常驻

一句话：

`主云一个 Python 单体 + 一个 PostgreSQL，备云一个极轻接管面`

### 12.2 云端明确不要保留的

- 不要独立 `Redis`
- 不要独立 `NATS`
- 不要独立 `Qdrant / Milvus`
- 不要 `ClickHouse`
- 不要自建 `MinIO`
- 不要全套 `Prometheus + Grafana + Loki`
- 不要常驻多模态媒体处理服务
- 不要常驻重型审计 worker 池
- 不要把跨设备运维动作直接在云端执行

### 12.3 必须下沉到设备端本地的

- 视频流解析
- 连续音频流处理
- 摄像头原始流上传
- OCR / 检测的原始大批量处理
- 串口长时间采集
- 大日志全文上传
- Test Rig 执行动作
- 跨设备运维修复动作本体
- 重型 Runbook 执行

改为：

- 设备端先做边缘预处理
- 只上传关键帧、短片段、摘要、异常片段、压缩日志、结果结论

### 12.4 业务上最值得做的减法

1. 把控制平面做成单体，而不是多服务
2. 把事件总线降级为 Postgres job queue
3. 把 Redis 去掉
4. 把独立向量库去掉，只保留 `pgvector`
5. 把媒体处理前移到终端设备
6. 把审计 Agent 改成按需启动，不常驻
7. 把运维层做成“轻控制面 + 重边缘执行”
8. 把原始证据留在边缘，只把摘要和索引上云

### 12.5 哪些能力不能砍

这些能力即使极限轻云也必须保留：

- 单主 Agent 入口
- 多机 Worker 调度
- 线程镜像与聊天记录查看
- 基础跨节点线程对话
- on-demand 审计
- 主运维层与运维审计层
- 跨设备运维
- 主控失联后的紧急修复链路
- 关键故障与修复结果上云可见

### 12.6 哪些能力只改实现位置，不改能力边界

- 多模态审计：保留，但模型前处理放边缘
- 硬件闭环：保留，但执行与采样放边缘
- 运维抢修：保留，但修复动作本体放目标节点
- 向量记忆：保留，但先和主库合并，不拆独立服务
- 实时查看：保留，但优先 SSE，不追求最重实时架构

### 12.7 双云容灾在极限轻云下怎么做

既然你接受两台云服务器做备份，我建议：

- `Cloud A`
  平时主用
  跑：
  - 控制面单体
  - PostgreSQL 主库

- `Cloud B`
  平时热备 / 温备
  跑：
  - 备用控制面单体
  - PostgreSQL 备库
  - 关键快照和接管脚本

目标不是把两台云都跑满，而是：

- 平时只让一台主扛业务
- 另一台尽量轻，只负责接管准备

### 12.8 矛盾点与取舍矩阵

这里是最关键的一部分。

#### 矛盾 1：你要手机随时看项目进度，但云端又要极轻

取舍：

- 保留：线程文本、任务状态、摘要、故障、修复结果实时上云
- 下沉：原始媒体、大日志、长串口流、原始检测流

结论：

- “能看项目和聊天”必须保留在云端
- “能看所有原始大证据”改为按需回传

#### 矛盾 2：你要多机实时协作，但不想跑重消息系统

取舍：

- 保留：跨节点协作能力
- 替换：`NATS` 改 `Postgres job queue + LISTEN/NOTIFY`

结论：

- 功能不砍
- 吞吐上限降低
- 对 MVP 可接受

#### 矛盾 3：你要审计层、运维层、主控层都在，但云端还要极轻

取舍：

- 保留：逻辑角色
- 改实现：不做多个常驻服务，而做一个单体里的模块 + 按需执行器

结论：

- 角色不砍
- 物理进程数减少

#### 矛盾 4：你要跨设备运维，还要主运维层开放式扩展

取舍：

- 保留：开放式主运维层
- 下沉：具体修复动作在目标节点本地执行

结论：

- 云端只做决策与编排
- 边缘做执行

#### 矛盾 5：你要多模态、硬件测试，但云带宽只有 10Mbps

取舍：

- 保留：多模态审计和硬件闭环
- 替换：边缘先做裁剪、摘要、关键帧、短片段

结论：

- 保留测试能力
- 放弃原始流持续上云

#### 矛盾 6：你要云端尽可能轻，但又要双云容灾

取舍：

- 保留：双云容灾
- 改实现：第二台云机尽量只做热备 / 温备，不承担常态重负载

结论：

- 双云可以保留
- 但只有主云承载主流量，备云尽量只承担接管准备

### 12.9 最终取舍原则

在你的约束下，最应该坚持的不是“所有东西都放云上”，而是：

- 功能边界不砍
- 云端只保留系统真相和调度真相
- 执行、重媒体、重测试、重运维动作全部边缘化
- 双云只保留“主用 + 备用”，不做“双主都很重”

换句话说：

- `业务能力保留`
- `物理部署下沉`
- `实时性分层`
- `证据上传按冷热分级`

---

## 13. 推荐部署方式

### 13.1 云端

- `Cloud A`
  - 控制面单体
  - PostgreSQL 主库
- `Cloud B`
  - 备用控制面单体
  - PostgreSQL 备库
  - 接管脚本与关键快照

默认不常驻：

- Redis
- NATS
- 独立对象存储服务
- 全套观测平台

### 13.2 终端节点

每台 Mac / Windows / Cloud Worker / Test Rig 至少部署：

- Worker Daemon
- Thread Gateway
- Local Ops Agent
- Local Ops Audit Agent
- gptpluscontrol Agent

---

## 14. 极轻云双云最低配置要求

这里给两档：

- `硬最低可跑`
  能跑起来，但更适合 PoC 或很低并发试运行
- `不明显降低稳定性和业务保障能力的最低要求`
  这是我真正建议你按它采购和部署的下限

### 14.1 硬最低可跑

`Cloud A（主用）`

- `2 vCPU`
- `4 GB RAM`
- `80 GB SSD`

`Cloud B（备用）`

- `2 vCPU`
- `4 GB RAM`
- `80 GB SSD`

前提：

- 云端只跑控制面单体 + PostgreSQL
- 不上 Redis / NATS / ClickHouse / MinIO / Prometheus
- 终端承担全部重媒体和重测试
- 审计全部按需执行
- 并发项目数低

这档能跑，但我不把它定义成“业务保障最低”。

### 14.2 不明显降低稳定性和业务保障能力的最低要求

`Cloud A（主用）`

- `2 vCPU`
- `8 GB RAM`
- `100 GB SSD`

`Cloud B（备用）`

- `2 vCPU`
- `8 GB RAM`
- `100 GB SSD`

原因：

- PostgreSQL 主库 / 备库都要稳定吃下项目、线程、审计、运维修复账本
- 主控切换时，不希望备云明显掉性能
- 你要求“不放弃原来的业务和保障能力”，那备用云就不能太瘦

### 14.3 为什么我不建议把备云做得更小

如果 `Cloud B` 只有 `1C2G` 或 `1C4G`，在正常热备时也许没问题；  
但一旦切主，它就会同时承担：

- 控制面单体
- PostgreSQL 读写
- SSE / API
- 审计触发
- 运维接管记录

这时容易出现：

- failover 后延迟明显抬高
- PostgreSQL 内存压力过大
- 恢复期间 SSE / API 不稳定

所以如果你把“业务保障能力”也算进去，我建议两台云机至少对齐到 `2C8G`。

### 14.4 磁盘最低建议

最低不要低于：

- `80 GB`

更稳的起步：

- `100 GB`

如果你们会频繁保留：

- 审计截图
- 短视频片段
- 修复证据
- 数据库 WAL

那 `150 GB` 会更舒服。

### 14.5 带宽要求

极轻云下，云端不承载原始媒体流，所以带宽要求并不高。

最低建议：

- 稳定公网
- `5 Mbps` 以上可用上行 / 下行

更稳建议：

- `10 Mbps` 以上

重点不是峰值，而是：

- 长连接稳定
- 丢包低
- 抖动小

### 14.6 最终一句话

如果你要：

- 极限轻云
- 双云容灾
- 不明显降低稳定性和业务保障能力

那我建议把最低配置定成：

- `Cloud A = 2C8G / 100GB SSD`
- `Cloud B = 2C8G / 100GB SSD`

这已经是我认为比较保守、也比较负责任的下限了。

### 14.7 支持两种保活模式

这套系统建议正式支持两种保活方式，而不是只绑定双云：

#### 模式 A：单云 + 设备端备用池（首选单 Mac）

适用场景：

- 你想把云成本进一步压低
- 现场本来就有一台常开 Mac，或者多台可接入设备
- 你能接受“云机故障时，由设备端顶上最小控制面”

部署方式：

- `Cloud A`
  - 控制面单体
  - PostgreSQL 主库
- `Preferred Standby Device`
  - 默认首选一台常开 `Mac`
  - 也允许其他接入设备作为后备候选
  - 备用控制面轻实例
  - PostgreSQL 备库或周期快照恢复实例
  - `Standby Controller`
  - `Ops Rescue Gateway`

关键要求：

- 至少一台首选备用设备必须常开
- 其余接入设备可声明自己是否可作为后备容灾设备
- 需要一条不依赖主云的可达通路，例如：
  - 同一局域网直接访问
  - `Tailscale / WireGuard`
  - 独立长期反向隧道
- 手机 App 要支持主 / 备 endpoint 列表切换
- 控制面要维护 `standby_device_pool`
- 每台候选设备都要同步最小 `takeover package`

优点：

- 比双云便宜
- 救援动作离本地设备更近
- 对局域网内设备接管更快

边界：

- 如果云机和全部候选设备所在现场一起断电、断网，这条链路也会失效
- 它适合作为“低成本保活方案”，但上限不如双云

`Preferred Standby Device` 最低建议：

- `Apple Silicon M1` 或同级 Intel 4 核
- `8 GB RAM`
- `50 GB` 可用 SSD

更稳建议：

- `16 GB RAM`
- `100 GB` 可用 SSD

#### 模式 B：双云热备 / 温备

适用场景：

- 你更在意远程可达性和持续在线
- 不希望把备援绑在某一台现场设备上
- 希望主云故障时，备用云独立接管

部署方式：

- `Cloud A`
  - 控制面单体
  - PostgreSQL 主库
- `Cloud B`
  - 备用控制面单体
  - PostgreSQL 备库
  - 快照、恢复脚本、接管钩子

优点：

- 远程访问更稳
- 不依赖现场某一台设备
- 主控接管路径更标准化

边界：

- 成本高于“单云 + 单 Mac”
- 对本地硬件接管的最后一跳，仍然要依赖现场设备在线

#### 两种模式怎么选

如果你要：

- 最低云成本下仍然保留备援能力

优先选：

- `单云 + 单 Mac 备用控制器`

如果你要：

- 更强的远程持续在线
- 更稳定的公网接管能力

优先选：

- `双云热备 / 温备`

我的建议是：

- 系统从设计上同时支持两种模式
- 开发时统一抽象成 `standby_provider`
- 实际部署时可选：
  - `cloud_b`
  - `standby_mac`
  - `both`

也就是说，这套产品以后可以跑成：

- `Cloud A + Standby Mac`
- `Cloud A + Cloud B`
- `Cloud A + Cloud B + Standby Mac`

其中最后一种是最强兜底，但不是 MVP 必需。

### 14.8 还能不能继续压缩云服务器

能，但要分清楚三条线：

- `双云 + 不明显降低稳定性和业务保障能力`
  - 最低仍然建议：`Cloud A = 2C8G / 100GB`
  - `Cloud B = 2C8G / 100GB`
- `单云 + 设备端备用池`
  - 云端可以继续压到：`2C4G / 80GB`
  - 前提是绝大多数重执行都下沉到设备端
- `实验性极限压缩`
  - 理论上可以再试 `1C2G ~ 1C4G`
  - 但我不建议把它写成正式最低配置，因为它已经开始侵蚀稳定性和恢复速度

一句话：

- `2C8G / 100GB` 不是“系统绝对最小”
- 它是“在双云容灾下，不明显降低稳定性和业务保障能力”的最低要求
- 如果切到单云，并且把更多动作下沉到本地设备，云端可以继续压到 `2C4G / 80GB`

### 14.9 哪些东西还能继续下沉到设备端

下面这些能力，建议尽可能下沉：

| 能力 | 现在建议放哪 | 还能继续怎么压云 | 不该牺牲什么 |
|---|---|---|---|
| Embedding 生成 | 设备端 | 由 worker / audit 节点本地生成 embedding，再把结果写回云库 | 云端仍保存向量和元数据真相 |
| 长日志处理 | 设备端 | 本地先裁剪、归类 fault_key、保留最后 N 行，再上传 | 云端仍保留 fault ledger |
| 视频 / 音频处理 | 设备端 | 本地抽关键帧、短片段、OCR、检测结果，只传证据摘要 | 云端仍保留证据索引和结论 |
| 审计执行 | 设备端 | 软件/硬件/多模态审计尽量在拥有能力的节点本地完成 | 云端仍保留审计工单和结论 |
| Test Rig 控制 | 设备端 | 摄像头、串口、机器人、麦克风、扬声器一律本地网关执行 | 云端仍保留租约和抢占真相 |
| 运维修复动作 | 设备端 | 重启、拉日志、切账号、跑 runbook 都在目标节点本地执行 | 云端仍保留审批、工单、复验记录 |
| 线程摘要压缩 | 设备端 | 每个 worker 本地先做任务摘要，再把结构化摘要写回云端 | 云端仍保留项目主记忆 |
| gptpluscontrol 额度轮询 | 设备端 | 每台机器本地采集额度，再定时上报精简状态 | 云端仍保留统一额度视图 |

### 14.10 哪些东西不能再往本地下沉

下面这些是系统真相，不能完全放到某一台设备本地：

- 项目 / 任务 / 线程账本
- 审计结论与修复结论
- `standby_provider` / `standby_device_pool` 状态
- 主备 endpoint 注册表
- 最小项目索引和恢复索引
- 审批结果与权限真相

也就是说，云端再怎么压，也至少要保留：

- 控制面单体
- PostgreSQL
- SSE / API
- 最小证据索引

### 14.11 单服务器 + 单设备端保活时，设备端掉线怎么办

这个场景不能只做“一个固定备用 Mac”，必须做成：

- `preferred standby device`
- `eligible standby devices`
- `automatic standby promotion`

实现方式：

1. 控制面维护一个 `standby_device_pool`
2. 每台设备声明：
   - 是否可作为容灾设备
   - 优先级
   - 常开状态
   - 可用内存 / 磁盘
   - 网络连通性
3. 控制面为前 `N` 个候选设备同步最小 `takeover package`
4. 当前活动备用设备心跳丢失后，自动提升下一台候选设备
5. 手机 App 与 Worker 端都读取新的主 / 备 endpoint 清单

自动提升的评分建议：

- 是否常开
- 是否同局域网稳定在线
- 是否具备足够内存和磁盘
- 是否已具备最新 `takeover package`
- 是否最近未发生故障

一句话：

- 在单服务器模式下，设备端容灾必须是“备用池”，不能是“唯一备用机”

#### 14.11.1 你的判断是对的：如果是冷备，切换会很慢

如果备用设备只是“连接在系统里，但平时没有预部署控制面与运维组件”，那一旦当前设备崩掉，就会出现：

- 先发现故障
- 再选备用设备
- 再部署或拉起业务代码
- 再下发配置、密钥、隧道、endpoint
- 再恢复最小项目索引

这条链路会明显变长，而且中间很容易出问题。

所以真正的自动切换，不能建立在“临时重新部署一套设备端业务代码”上。

#### 14.11.2 必须区分冷备、温备、热备

- `冷备（cold standby）`
  - 设备在线，但没有预部署接管组件
  - 故障时才开始部署
  - 结论：不适合自动切换，只适合人工应急
- `温备（warm standby）`
  - 设备已预部署接管组件
  - 已同步 `takeover_package`
  - 平时不承载主流量，只保留轻实例和心跳
  - 结论：这是单云 + 设备端备用池的最低可接受形态
- `热备（hot standby）`
  - 设备已预部署并保持随时接管
  - 关键状态同步更频繁
  - 切换最快
  - 结论：体验最好，但会多吃一点本地资源

#### 14.11.3 我建议你们至少做温备，不要做冷备

也就是说，每一个合格的备用候选设备上，都应该提前放好：

- `Standby Controller`
- `Local Ops Agent`
- `Local Ops Audit Agent`
- `Ops Rescue Gateway`
- 最小运行时依赖
- 最小配置模板
- endpoint 清单
- 最近的 `takeover_package`

这样切换时做的就不是“重新部署”，而是：

- 切换角色
- 拉起轻实例
- 刷新 endpoint
- 恢复最小控制面

#### 14.11.4 切换时间预期

如果做成：

- `冷备`
  - 可能是 `3 ~ 10 分钟`，而且风险大
- `温备`
  - 目标应控制在 `15 ~ 60 秒`
- `热备`
  - 目标可进一步压到 `5 ~ 15 秒`

所以如果你要“自动启动另外一台连接设备作为容灾设备”，正确前提不是“自动部署”，而是“提前预热好备用池”。

### 14.12 API-first / Local-first 极限压缩模式

可以，而且这恰恰是你现在这套系统最适合走的方向。

因为你们的并发不高，只有 `2 ~ 3` 台电脑同时使用，所以没必要一开始就在云端常驻很多重服务。更合理的是：

- 云端只保留最小控制面和最小系统真相
- 能通过外部 API 调的，就不要自己在云端常驻算力
- 能在本地设备做的，就尽量放到设备端

#### 云端最终只保留什么

- `API Gateway / BFF`
- `Master Agent Runtime`
- `PostgreSQL`
- 最小 `pgvector`
- 主备 endpoint 注册表
- `standby_device_pool`
- 审批、审计、修复账本

#### 哪些业务可以直接 API 化

- 模型推理
  - 直接调用 OpenAI / 其他模型 API
  - 不在你的云端常驻推理服务
- OCR / 检测
  - 优先本地执行
  - 不够时再调用外部 API
- 文件 / 对象存储
  - 优先本地或 NAS
  - 云端只保存 manifest 和索引

#### 哪些业务更适合本地化

- embedding 生成
- 长日志裁剪
- 视频 / 音频预处理
- 审计执行
- Test Rig 控制
- 运维修复动作
- gptpluscontrol 本地额度采集

#### 这种模式下的最低云配置

如果采用：

- `单云`
- `standby_device_pool`
- `API-first`
- `local-first`
- 并发设备 `<= 3`

那我建议把起步云配置定成：

- `2C4G / 80GB SSD`

这是一个我认为可以认真尝试的“极限压缩起步线”。

如果想再压：

- `1C2G ~ 1C4G`

理论上能试，但只建议作为实验环境，不建议一开始就当生产起步线。

### 14.13 按设备数和任务数弹性升级

你说得对，不应该一上来就把最低配置拉很高。更合理的是按触发条件升级。

#### 起步档

- 场景：
  - `1 个 Cloud A`
  - `standby_device_pool`
  - 并发设备 `<= 3`
  - 同时活跃项目 `<= 3`
- 建议：
  - `2C4G / 80GB SSD`

#### 升级到下一档的触发条件

满足任意一条就建议升级：

- 同时接入设备数 `> 3`
- 同时活跃线程数 `> 10`
- 同时运行专项审计 / 硬件测试 `> 2`
- `Postgres` 内存持续高于 `70%`
- API / SSE `p95` 延迟持续高于 `500ms`
- 待处理修复工单和审计工单出现积压

#### 第一步升级建议

- 先升到：
  - `2C8G / 100GB`
- 或者补上：
  - `Cloud B`

#### 第二步升级建议

- 增加 `Redis`
- 再考虑 `NATS JetStream`
- 再考虑独立对象存储
- 再考虑独立向量库

一句话：

- 先把系统做成“轻云 + 重本地 + 可弹性升级”
- 不要一开始就把所有重能力堆到云端

---

## 15. MVP 最小落地建议

### 第一阶段

- 前端：Next.js PWA
- 云端：FastAPI + LangGraph
- 数据：Postgres 16 + pgvector
- 队列：Postgres job table + LISTEN/NOTIFY
- 文件：本机磁盘短期缓存 + 异步备份
- 运维：结构化 JSON 日志 + 健康探针 + Ops Ledger

### 第二阶段

- 视规模增加 Redis
- 视并发增加 NATS JetStream
- 增加 ClickHouse 做 fault_key 检索
- 增加 Qdrant 作为独立向量库候选
- 增加更多 Ops Connector

---

## 16. 一句话结论

如果要兼顾多机 Codex、审计、多模态、硬件接管、开放式主运维层和跨设备运维，  
最稳的主栈是：

`TypeScript + Next.js` 做前端，  
`Python + FastAPI + LangGraph` 做控制平面与 Agent 体系，  
`Postgres 16 + pgvector` 做最小数据底座，  
把 `Redis / NATS / 独立对象存储 / 重媒体处理 / 重运维执行` 尽量后移或下沉到边缘节点。