krisolo/boss
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
codex/native-boss-android-2-1-0
boss/docs/architecture/detailed_technical_stack_cn.md
kris 90cb6b7ff1 feat: ship native boss android console
2026-03-26 23:16:56 +08:00

33 KiB
Raw Permalink Blame History

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

10.2 PostgreSQL 和 pgvector 的一体化更成熟

pgvector 官方项目就是围绕 PostgreSQL 构建的，支持精确检索、HNSW、IVFFlat，并且能直接结合 Postgres 的 ACID、PITR、JOIN 等能力。
来源：pgvector GitHub

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

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

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

10.3 后续云迁移更顺

如果我们以后迁到阿里云 PolarDB PostgreSQL + PGVector，路径非常平滑，因为官方就是 PostgreSQL + PGVector 体系。
来源：阿里云 PolarDB 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 安装说明
  • 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 / 独立对象存储 / 重媒体处理 / 重运维执行 尽量后移或下沉到边缘节点。