1375 lines
33 KiB
Markdown
1375 lines
33 KiB
Markdown
# 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 / 独立对象存储 / 重媒体处理 / 重运维执行` 尽量后移或下沉到边缘节点。
|