Codex 多机协作控制架构

一、核心结论

二、系统总览图

说明：主 Agent 不直接持有全部项目真相，所有关键状态都会落在事件库、任务账本和项目记忆中，因此主 Agent 崩溃后可以被接管。

三、整体架构思维导图（完整版）

这张是完整的总架构脑图，不是摘要版。你可以把它理解成“整个产品怎么拼起来”的树状图。

四、技术实现方案

1. 手机端

• 建议先做 PWA 或响应式 Web 控制台，再按需要封装成 iOS / Android App。
• 页面包括：主对话页、项目列表页、项目线程页、审批中心、节点状态页、告警页。
• 所有实时状态通过 WebSocket 推送，点开项目后直接读取 thread mirror 和增量事件。
• 主对话页顶部增加一个非常轻量的“当前主控身份提示条”，只占一行小胶囊区域，显示当前主脑来源：`主 GPT`、`备用 GPT` 或 `API 容灾`。
• 这个提示条默认只显示 3 段信息：当前身份、所在线节点、最近切换时间；点击后再展开完整详情，不占据主聊天区。

2. 控制平面

• 主控服务放在云服务器，避免主调度器依赖某一台个人电脑。
• LangGraph 负责任务拆解、状态流转、checkpoint 恢复和人工介入。
• Project Memory 负责保存项目目标、约束、阶段总结、未决问题、关键决策。
• Scheduler 根据节点能力、系统负载、Codex 限额和任务类型选择执行节点。

3. Worker 节点

• 每台 Mac、Windows、云服务器都运行一个 worker daemon。
• worker daemon 连接本机 Codex app-server / SDK，启动和恢复线程，读取事件并上传到事件库。
• 每个任务使用独立 worktree / branch，避免不同线程直接写同一个工作目录。
• Windows 节点建议用 WSL2 跑 worker，本地 GPU、PowerShell、原生程序通过桥接服务暴露。

4. 线程与记忆策略

• 每个项目不是一个超长线程，而是多个短线程：功能线程、修复线程、实验线程、评审线程。
• 线程执行结束后，worker 自动回传阶段摘要、关键文件、风险、测试结果和待办。
• 主控只把最小必要上下文派给下一次线程，避免长期上下文压缩导致能力下降。
• 每个 worker 必须持续上报线程上下文预算：`context_budget_remaining_pct`、`context_budget_level`、`compaction_expected_at`。
• 手机端会话列表第三层使用统一的圆环进度标记显示“背景信息窗口余量”，该标记与设备端线程页保持一致，不能由前端自行估算。
• 主 Agent 必须把“压缩前收尾”当成一等公民，在上下文预算进入危险区前优先完成关键结论固化、补丁固化、测试结论固化和线程交接。

5. 额度监控集成（直接复用 gptpluscontrol）

• 不重新发明额度监控，直接复用 `/Users/kris/code/gptpluscontrol` 已有的后端、Agent、SSE 和数据结构。
• 手机 App 和 Web 控制台从控制平面读取“主控状态”，同时从 gptpluscontrol 读取“各 Codex 节点剩余额度和当前占用状态”。
• 建议先把 gptpluscontrol 作为独立服务并行部署，再由控制平面聚合其接口；后续若要统一，可再把其接口协议并入主系统。

6. 跨节点线程对话机制

• 允许 Mac、Windows、云节点上的任意 Codex 线程在主 Agent 监管下进行线程到线程对话，但不采用裸点对点直连。
• 系统实现采用“逻辑直连、物理经主控转发”：发送线程把消息交给本地 `Thread Gateway`，再经 `Inter-Thread Broker` 路由到目标节点。
• 默认只允许同一项目内线程互通，跨项目通信必须显式授权。
• 消息默认只传任务摘要、必要上下文、附件引用和最近结论，不直接透传完整历史，避免上下文污染和容量膨胀。

7. 开发规格：线程地址、消息协议与监管模式

8. 线程对话的权限与审计要求

• 所有跨节点线程对话必须带 `project_id` 和 `intent`，禁止匿名消息。
• `Inter-Thread Broker` 必须检查 ACL：项目边界、角色边界、节点边界、监管模式、最大 turn 数和消息 TTL。
• 所有线程对话都必须写入 `Event Store`，手机端项目页可以查看“谁在向谁发起对话、原因是什么、结果是什么”。
• 主 Agent 对线程对话有冻结权、禁言权和强制断链权，审计层可对异常通信做告警。

9. UI 表达与产品交互

• 项目线程页要显示“跨节点协作”时间线，突出展示 `发送线程`、`目标线程`、`intent`、`状态`、`摘要结果`。
• 节点详情页要显示该设备当前正在参与的跨节点对话数、最近交互对象和失败次数。
• 主对话页里，当主 Agent让某个线程去和其他节点线程协作时，应出现一条简短系统消息，例如“已让 Mac 前端线程向 Windows GPU 线程请求推理结果”。

10. 开放式审计与硬件接管

• 审计层不只审代码，还要能在需要时接管真实测试硬件，因此必须设计成开放能力系统，而不是只读日志的观察者。
• 每台设备都可以注册自己的“测试能力”，例如摄像头、麦克风、扬声器、屏幕采集、串口、USB 控制器、拇指机器人、继电器、可编程电源等。
• 控制平面维护统一的 `Capability Registry`，记录每个能力所在节点、当前占用状态、优先级和可抢占性。
• 审计 Agent 在被授权后，通过 `Device Lease / Preemption` 机制秒级接管这些能力，完成交互测试、硬件回归和多模态验证。
• 视频流不建议长期整路上传，边缘节点先提取关键帧、短视频片段、OCR 和检测结果，再由多模态审计 Agent 复核。

11. 运维层与运维审计层

• 在整个系统的最外层增加 `Ops Layer` 和 `Ops Audit Layer`，它们负责监管主控、Worker、审计层、硬件层、数据层、额度层是否健康。
• 每一台接入系统的终端设备，无论是 Mac、Windows、云工作机还是独立测试台，都必须常驻 `Local Ops Agent` 和 `Local Ops Audit Agent`。
• `Local Ops Agent` 负责巡检、分类、执行修复；`Local Ops Audit Agent` 负责监督运维 Agent、判定修复权限、执行修复复验。
• 巡检频率由 `Ops Policy Engine` 动态调节：高频使用状态下每 5 分钟一次；无人使用且没有现场工作时每 1 小时一次。
• 主 Agent 每小时至少检查一次整个运维层是否健康，确认所有节点的运维 Agent / 运维审计 Agent 在线且最近一次巡检成功。
• 当主 Agent 在线且能正常响应时，运维 Agent 发起修复必须先经主 Agent 同意；当主 Agent 失联时，运维审计 Agent 才能做最终修复执行判断。

五、每个服务运行在哪台机器

六、主 Agent 怎么使用 ChatGPT 蓝色账号上的 Codex 额度

设计原则：Plus 额度按“节点级账号”使用，不按“中央公共额度池”设计。调度器要监控每个节点账号的剩余额度和速率限制。

七、向量库存在哪里

八、Codex 剩余额度显示与 gptpluscontrol 集成

额度监控不新做，直接复用现有 `gptpluscontrol` 项目。当前项目已经具备云端 Backend、macOS / Windows Agent、REST API 和 SSE 实时刷新能力。

1. 推荐集成方式

• 把 `gptpluscontrol Backend` 部署在云服务器，与主控控制平面同域或同内网。
• 每台 Mac / Windows 设备同时运行 `worker daemon` 和 `gptpluscontrol agent`。
• 手机 App 和 Web 端通过控制平面 BFF 聚合两类数据：项目执行数据来自主控，额度和账号状态来自 gptpluscontrol。
• 前端只显示最终聚合后的统一视图，避免手机端同时直连多个系统。

2. 可以直接复用的数据接口

3. 当前可直接利用的关键字段

• `codex_current_display_name`：当前设备绑定的 Codex 账号显示名。
• `codex_current_window_5h_remaining`：当前 5 小时窗口剩余额度。
• `codex_current_window_7d_remaining`：当前 7 天窗口剩余额度。
• `codex_last_switch_at` / `codex_last_switch_from` / `codex_last_switch_to`：最近切号时间与来源目标。
• `codex_last_handoff_status` / `codex_last_handoff_reason`：最近交接状态和原因。
• `usage_state`：账号当前是否被占用、是谁在使用、角色优先级和最近动作。

4. App 里的 UI 设计要求

5. 开发实现建议

• MVP 先不把 gptpluscontrol 代码强行并入主控服务，先作为独立服务部署，降低耦合。
• 主控服务新增一个 BFF 层，把 gptpluscontrol 的 API 结果转换成手机端需要的统一字段。
• 等主系统稳定后，再考虑把 gptpluscontrol 的 schema 和事件流整合进统一数据库。

九、跨节点线程对话机制

可开发的消息流

推荐的 intent 类型

• `ask_compute`：请求 GPU 推理、批处理或算力任务。
• `request_artifact`：请求文件、产物、日志、截图或模型输出。
• `request_hardware_check`：请求目标节点执行硬件检查。
• `request_ui_validation`：请求目标节点做 UI 或交互验证。
• `request_test_step`：请求目标节点执行测试步骤并返回结果。

十、混合审计架构：规则审计 + 专项审计 Agent

建议的分工

开放式硬件接管要求

• 审计 Agent 必须可以接管任意在线节点上的测试硬件能力，只要该能力已在系统注册并被授权。
• 支持的能力包括但不限于：摄像头、麦克风、扬声器、屏幕采集、USB 设备、串口、继电器、拇指机器人、可编程电源、机械按键器。
• 接管不是直接抢占操作系统桌面，而是通过 `Test Rig Gateway` 暴露标准能力接口，便于审计层按能力调用。
• 所有接管都要有租约、超时、占用记录和回放证据，避免多个审计线程同时争抢同一个外设。
• 如果某个项目的交互逻辑需要完整拟人化测试，审计 Agent 可以串联摄像头 + 麦克风 + 扬声器 + 机器人执行器完成闭环测试。

十一、运维层与运维审计层

1. 组件与职责

2. 日志命名与低 token 定位原则

• 所有错误键统一采用：`<LAYER>.<DOMAIN>.<COMPONENT>.<ACTION>.<ERROR_CODE>`。
• 示例：`MASTER.SCHEDULER.DISPATCH.NODE_UNAVAILABLE`、`WORKER.CODEX.THREAD_START.RATE_LIMIT`、`OPS_AUDIT.REPAIR.VERIFY.RESTART_FAILED`。
• 每条日志至少带：`fault_key`、`severity`、`node_id`、`service_name`、`project_id`、`thread_ref`、`trace_id`、`runbook_id`。
• Ops Agent 汇报问题时优先输出 `fault_key`、受影响节点、首次/最近时间、建议动作和 runbook，不直接把长日志贴给主控。

3. 除日志之外必须增加的救援手段

• 心跳与存活探针：主控、Worker、线程网关、审计层、硬件桥、gptpluscontrol 都要有 heartbeat。
• 合成探针：周期性模拟创建项目、启动轻量线程、读取 thread history、申请能力租约，验证业务链路没有“表面存活、实际已坏”。
• 事件流与队列监控：看 Event Store 写入延迟、WebSocket/SSE 推送中断、消息积压、线程停滞。
• 资源与依赖监控：CPU / 内存 / GPU / 磁盘、数据库复制延迟、对象存储写失败率、网络抖动。
• 认证与额度监控：Codex 登录态、API key、Plus 剩余额度、gptpluscontrol 新鲜度、账号切换结果。
• 孤儿状态清理：孤儿 lease、孤儿 thread、孤儿 repair ticket、无人接手的审计任务。
• 现场快照抽样：关键摄像头关键帧、OCR、串口短日志、设备状态采样，用于发现“服务活着但现场已经坏了”的情况。
• 开放运维域探针：对其他接入项目的 SSH、HTTP API、Docker、K8s、Windows Service、局域网 RPC 做统一健康采样和修复映射。
• 跨设备运维动作：支持远程拉日志、远程重启服务、远程切换账号、远程重连桥接服务、远程执行 Runbook，并统一经过主运维层审批与复验。

4. 在线与离线两种修复模式

5. 当运维层自身挂了，但主 Agent 在线

• 如果 `Ops Control Plane`、`Ops Ledger`、`Ops Connector Runtime` 或大面积 `Local Ops Agent / Ops Audit Agent` 自身出问题，主 Agent 必须切到 `ops_rescue_mode`。
• 进入该模式后，主 Agent 通过独立的最小救援通道直连节点或备用控制器，对运维层发起反向抢救。
• 反向抢救不能依赖已经损坏的运维控制面本身，必须保留保底通道，例如紧急 RPC、备用控制器、本地 Watchdog 接口或只读健康快照通道。
• 运维层恢复后，仍然要由 `Ops Audit Agent` 做复验，再把结果回报主 Agent。

6. 主控恢复后的回放要求

• 主 Agent 恢复后必须收到：故障摘要、影响范围、已执行修复动作、复验结论、剩余风险、是否建议人工复盘。
• 若运维修复在主控离线时发生，系统必须自动补发一条“修复回放报告”到主会话和运维中心。
• 若是主 Agent 自己发起的运维层反向抢救，也必须写入同一套运维账本，避免形成黑盒修复。

详细协议文档见：ops_layer_and_repair_protocol_cn.md

十二、容灾与故障恢复

1. 主控故障

• Master Agent 的任务状态和项目记忆不保存在上下文里，而是落在 Postgres、对象存储和向量记忆里。
• 启用 Standby Controller，持续订阅事件库和任务账本，主控故障后接管调度。
• LangGraph 的 checkpoint 用于恢复到最近一次可执行状态。

2. 数据库故障

• Postgres 使用主从复制或云数据库高可用版本。
• 每天全量备份，按小时增量备份，保留至少 7 到 30 天。
• 事件日志追加写入对象存储，数据库损坏后仍可回放构建状态。

3. 单台 worker 故障

• worker 维持心跳，超过阈值则标记离线，并触发重新调度。
• 每个任务都绑定 branch / worktree，失败后可以迁移到其他节点继续执行。
• Windows GPU 任务失败时，可降级转移到云 GPU 或改为排队等待恢复。

4. 账号或额度问题

• Quota Monitor 记录每个 ChatGPT / Codex 节点的可用额度与速率限制。
• 单个账号额度不足时，自动切换到其他 worker 节点执行。
• 主脑如使用 API，可与 worker 层的 Plus 账号使用路径解耦。

5. 网络故障

• 局域网内的 Mac 和 Windows 节点优先直连云控制平面。
• 如家庭宽带不稳定，可在云端部署轻量 relay，worker 与 relay 保持长连接。
• 手机端通过 HTTPS + WebSocket 访问，断线重连后根据事件序号补拉缺失记录。

6. 人工接管

• 手机端和 Web 控制台提供“暂停调度”“冻结项目”“人工审核后继续”的按钮。
• 任何时刻都可以把某个 worker thread 升级为人工接管模式。
• 系统要支持导出项目摘要、当前分支、最近命令、失败原因，便于人工介入。

十三、推荐的第一阶段落地方式

十四、中文思维导图

下面这块是压缩后的方案总览，适合快速过一遍全局逻辑，也方便你后面拿去继续讨论产品边界和开发排期。

十五、开发规格文档入口

下面这份文档已经单独整理成可直接开发的协议规格，建议后续数据库、API、消息总线、前端联调都以它为准，不再从正文里反复抽取定义。

建议的直接开发顺序

十六、当前流程思维导图图片版

这张图把当前已经确定下来的主流程、执行层、审计层、能力层和容灾层压成一张图，适合直接对着讨论开发边界和服务拆分。

图片文件： current_flow_mindmap_cn.svg

十七、业务流程思维导图图片版

这张图专门从业务推进角度整理，从你发起项目、主控拆任务、多机开发、审计复核、硬件测试到结果交付和异常恢复，每个环节都标了使用的关键技术。

图片文件： business_flow_mindmap_cn.svg

十八、业务流程泳道图图片版

如果你想更直观看“谁在什么时候做什么”，就看这张泳道图。它现在把用户、主 Agent、Worker、审计层、硬件能力层、运维层 / 运维审计层、数据与容灾层拆成 7 条泳道，并标出了关键技术、开放式运维接入和反向抢救切换点。

图片文件： business_flow_swimlane_cn.svg

十九、运维与抢修泳道图图片版

这张图专门把运维层和运维审计层拆开，展示动态巡检、日志命名、主控在线审批、主控离线紧急接管、修复复验和主控恢复回放的完整闭环。

图片文件： ops_repair_swimlane_cn.svg

二十、详细技术栈建议

下面这版是“可以直接开工”的技术选型，不再停留在抽象架构层，重点回答：用什么语言、什么数据库、什么消息总线、什么向量库、什么对象存储、什么观测体系。

跨设备运维的具体落地

• 极轻云默认建议统一走：`Ops Control Plane -> Postgres job queue + LISTEN/NOTIFY -> target Local Ops Agent -> Ops Audit Agent -> Ops Ledger`。
• 首批支持的远程运维动作：`remote_exec`、`remote_restart_service`、`remote_fetch_logs`、`remote_collect_snapshot`、`remote_push_config`、`remote_switch_account`、`remote_run_runbook`。
• 首批连接器类型：`ssh`、`http_api`、`windows_service`、`docker`、`lan_rpc`。

详细选型文档见：detailed_technical_stack_cn.md

二十一、极限轻云方案（同时考虑容灾）

这里不是因为服务器小才降配，而是无论云服务器配置如何，都主动把云端压缩到最轻；同时保留双云容灾，但让备云只承担接管准备，不承担常态重负载。

最值得做的减法

• 把控制平面做成 Python 单体，而不是多微服务。
• 把事件总线从 `NATS JetStream` 降到 `Postgres job table + LISTEN/NOTIFY`。
• 先不用 `Redis`，用 Postgres 行锁和应用内 TTL cache 替代。
• 先不用独立向量库，只保留 `pgvector`。
• 聊天发送走 HTTP，状态更新优先 `SSE`，不要一开始把所有实时能力都堆到 WebSocket 上。
• 审计 Agent 改成按需触发，不常驻。
• 运维层做成“轻控制面 + 重边缘执行”，跨设备运维动作由目标节点本地 Ops Agent 执行。

双云容灾下怎么做轻量化

• `Cloud A`：主用，只跑控制面单体和 PostgreSQL 主库。
• `Cloud B`：热备 / 温备，只跑备用控制面单体、PostgreSQL 备库、关键快照和接管脚本。
• 目标不是让两台云都跑得很重，而是“主云承担业务，备云保持可接管”。

不建议放在云端长期常驻的

• 持续视频流接入与转码
• 长时间音频流处理
• 大规模日志全文索引
• 独立向量数据库集群
• 全套 Prometheus + Grafana + Loki + ClickHouse 观测平台

这套极轻云方案能保住什么

• 单主 Agent 入口
• 多机 Worker 调度
• 线程镜像和聊天记录查看
• 基础跨节点线程对话
• 按需审计
• 基础运维修复与主控失联应急链路

详细极轻云方案见：detailed_technical_stack_cn.md

二十二、矛盾点与取舍矩阵

这里不是继续堆技术，而是明确说明：在“云端尽可能轻”和“原有业务能力不能砍”之间，哪些可以换实现位置，哪些是唯一真正的硬矛盾。

最终建议

• 不砍功能边界，只改变物理部署位置。
• 云端只保留“系统真相”和“调度真相”。
• 重执行、重媒体、重测试、重运维动作全部边缘化。
• 证据上传分冷热两层：热数据立即上云，冷数据按需回传。

更完整的分析见：detailed_technical_stack_cn.md

二十三、极限轻云双云部署拓扑图图片版

这张图把最终确定下来的部署原则画成了可落地的拓扑：`Cloud A` 只承担主用控制面和主库，`Cloud B` 只承担热备 / 温备和接管准备，所有重执行、重媒体、重测试、重运维动作全部下沉到设备端。

• `Cloud A`：控制面单体、主 Agent 编排逻辑、PostgreSQL 主库、pgvector、HTTP + SSE。
• `Cloud B`：备用控制面单体、PostgreSQL 备库、接管脚本、快照和恢复钩子。
• 设备端：Codex Worker、审计执行器、Test Rig、跨设备运维动作、本地证据缓存。
• 默认不在云端常驻：`Redis`、`NATS`、独立对象存储、重媒体处理、重审计池。

二十四、双云最低配置速览

在“云端尽可能轻”且“不能明显降低稳定性和业务保障能力”的前提下，我建议按下面这个下限准备两台云服务器。

• “硬最低可跑”更适合 PoC 或超低并发试运行，不建议拿它做业务保障下限。
• 真正推荐的最低要求是：`Cloud A = 2C8G / 100GB SSD`，`Cloud B = 2C8G / 100GB SSD`。
• 如果你们保留较多审计截图、短视频片段、修复证据和数据库 WAL，磁盘建议直接上到 `150 GB`。
• 带宽重点看稳定性，最低建议 `5 Mbps`，更稳建议 `10 Mbps` 以上。

更完整的最小配置解释见：detailed_technical_stack_cn.md

二十五、两种保活模式

系统从设计上同时支持两种备用接管路径：`单云 + 单 Mac 备用控制器`，以及 `双云热备 / 温备`。部署时可以二选一，也可以同时启用。

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

• `Cloud A` 跑控制面单体和 PostgreSQL 主库。
• 默认首选一台 `Standby Mac`，但系统同时维护 `standby_device_pool`，允许其他接入设备自动成为后备容灾设备。
• 当前活动备用设备运行备用控制面轻实例、`Standby Controller`、`Ops Rescue Gateway`，以及备库或快照恢复实例。
• 手机 App 必须支持主 / 备 endpoint 列表切换。
• 必须准备一条不依赖主云的可达路径，例如同局域网、`Tailscale / WireGuard` 或长期反向隧道。
• `Standby Mac` 最低建议：`M1` 或同级 4 核、`8 GB RAM`、`50 GB` 可用 SSD；更稳建议 `16 GB RAM / 100 GB SSD`。

模式 B：双云热备 / 温备

• `Cloud A` 跑主用控制面和 PostgreSQL 主库。
• `Cloud B` 只跑备用控制面、PostgreSQL 备库、接管脚本和恢复钩子。
• 推荐最低要求：`Cloud A = 2C8G / 100GB SSD`，`Cloud B = 2C8G / 100GB SSD`。
• 目标不是让两台云都很重，而是“主云承载业务，备云保持可接管”。

统一抽象

• 开发时统一抽象成 `standby_provider`。
• 部署时可选：`standby_mac`、`cloud_b`、`both`。
• 这意味着同一套代码可以跑成：`Cloud A + Standby Mac`、`Cloud A + Cloud B`、或 `Cloud A + Cloud B + Standby Mac`。

二十六、还能不能继续压缩云服务器

可以，但要分清楚“功能还能跑”和“稳定性与业务保障能力不明显下降”不是一回事。这里把可继续压缩的边界和不能继续下沉的系统真相拆开。

先给结论

• `2C8G / 100GB` 不是系统绝对最小，而是“双云容灾下，不明显降低稳定性和业务保障能力”的最低要求。
• 如果切到 `单云 + 设备端备用池`，并把更多执行、审计、媒体处理下沉到本地，云端可以继续压到 `2C4G / 80GB`。
• `1C2G ~ 1C4G` 只适合实验性极限压缩，不建议作为正式业务下限。

哪些能力还能继续下沉到设备端

哪些东西不能继续往本地下沉

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

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

• 不能只做一个固定 `Standby Mac`，必须做成 `standby_device_pool`。
• 每台设备声明自己是否可作为容灾设备，并上报常开状态、内存、磁盘、网络可达性和 `takeover package` 版本。
• 控制面为前 `N` 个候选设备同步最小接管包。
• 当前活动备用设备心跳丢失后，系统自动提升下一台候选设备为新的 `active_standby_device`。
• 手机 App、Worker、运维层都读取最新的主 / 备 endpoint 清单。

这个切换会不会很慢

• 如果备用设备是“冷备”，也就是平时没预部署接管组件，那你的理解是对的：切换会慢，而且容易出问题，因为它等于要临时重新部署一套设备端业务代码。
• 所以自动切换不能基于冷备，必须基于 `warm standby` 或 `hot standby`。
• `warm standby`：设备已预部署 `Standby Controller / Local Ops Agent / Local Ops Audit Agent / Ops Rescue Gateway`，并已同步最近的 `takeover package`。
• `hot standby`：在温备基础上做更高频状态同步，切换更快，但会多占一点本地资源。
• 目标时间建议：冷备 `3~10 分钟`，温备 `15~60 秒`，热备 `5~15 秒`。

二十七、API-first / Local-first 极限压缩模式

可以把云端进一步压轻。思路不是把业务砍掉，而是把“云端常驻重服务”改成“外部 API 调用 + 设备端本地执行”，让云端只做最小控制面和最小系统真相。

这套模式的核心原则

• 能通过外部 API 调的，不在你的云端常驻算力。
• 能在本地设备完成的，不回云端执行。
• 云端只保留：`API Gateway / BFF`、`Master Agent Runtime`、`PostgreSQL`、最小 `pgvector`、endpoint 注册表、`standby_device_pool`、审批/审计/修复账本。

哪些业务适合 API 化

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

哪些业务更适合本地化

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

这条线下的起步配置

• 如果并发设备 `<= 3`，而且采用 `单云 + standby_device_pool + API-first + local-first`，起步云配置可以认真尝试 `2C4G / 80GB SSD`。
• `1C2G ~ 1C4G` 只建议当实验环境，不建议直接作为正式起步线。

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

• 起步档：`1 个 Cloud A + standby_device_pool`，并发设备 `<= 3`，建议 `2C4G / 80GB SSD`。
• 如果同时接入设备数 `> 3`、活跃线程数 `> 10`、专项审计 / 硬件测试并发 `> 2`，就建议升到 `2C8G / 100GB` 或补上 `Cloud B`。
• 只有在再往上走时，才考虑依次增加 `Redis`、`NATS JetStream`、独立对象存储、独立向量库。