2114 lines
94 KiB
HTML
2114 lines
94 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="zh-CN">
|
||
<head>
|
||
<meta charset="UTF-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
<title>Codex 多机协作架构方案</title>
|
||
<style>
|
||
:root {
|
||
--bg: #f5f7fb;
|
||
--panel: #ffffff;
|
||
--panel-soft: #f0f4ff;
|
||
--text: #182230;
|
||
--muted: #516174;
|
||
--line: #d7dfeb;
|
||
--brand: #0f62fe;
|
||
--brand-soft: #e8f0ff;
|
||
--ok: #117a37;
|
||
--warn: #9a5d00;
|
||
--danger: #b42318;
|
||
--shadow: 0 10px 30px rgba(16, 24, 40, 0.08);
|
||
--radius: 18px;
|
||
}
|
||
|
||
* {
|
||
box-sizing: border-box;
|
||
}
|
||
|
||
body {
|
||
margin: 0;
|
||
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "PingFang SC",
|
||
"Hiragino Sans GB", "Microsoft YaHei", sans-serif;
|
||
background:
|
||
radial-gradient(circle at top right, rgba(15, 98, 254, 0.12), transparent 28%),
|
||
linear-gradient(180deg, #f7f9fc 0%, #eef3fb 100%);
|
||
color: var(--text);
|
||
line-height: 1.65;
|
||
}
|
||
|
||
.page {
|
||
width: min(1200px, calc(100% - 32px));
|
||
margin: 0 auto;
|
||
padding: 28px 0 64px;
|
||
}
|
||
|
||
.hero {
|
||
background: linear-gradient(135deg, #0f62fe 0%, #3b82f6 55%, #7aa8ff 100%);
|
||
color: #fff;
|
||
border-radius: 28px;
|
||
padding: 38px 36px;
|
||
box-shadow: var(--shadow);
|
||
margin-bottom: 22px;
|
||
}
|
||
|
||
.hero h1 {
|
||
margin: 0 0 14px;
|
||
font-size: 34px;
|
||
line-height: 1.2;
|
||
}
|
||
|
||
.hero p {
|
||
margin: 0;
|
||
max-width: 920px;
|
||
font-size: 16px;
|
||
color: rgba(255, 255, 255, 0.9);
|
||
}
|
||
|
||
.section {
|
||
background: var(--panel);
|
||
border: 1px solid var(--line);
|
||
border-radius: var(--radius);
|
||
padding: 28px;
|
||
box-shadow: var(--shadow);
|
||
margin-top: 18px;
|
||
}
|
||
|
||
.section h2 {
|
||
margin: 0 0 14px;
|
||
font-size: 24px;
|
||
line-height: 1.25;
|
||
}
|
||
|
||
.section h3 {
|
||
margin: 22px 0 10px;
|
||
font-size: 18px;
|
||
}
|
||
|
||
.lead {
|
||
color: var(--muted);
|
||
margin: 0 0 10px;
|
||
}
|
||
|
||
.grid {
|
||
display: grid;
|
||
grid-template-columns: repeat(12, 1fr);
|
||
gap: 16px;
|
||
}
|
||
|
||
.card {
|
||
background: var(--panel);
|
||
border: 1px solid var(--line);
|
||
border-radius: 16px;
|
||
padding: 18px;
|
||
}
|
||
|
||
.soft {
|
||
background: var(--panel-soft);
|
||
}
|
||
|
||
.span-4 {
|
||
grid-column: span 4;
|
||
}
|
||
|
||
.span-6 {
|
||
grid-column: span 6;
|
||
}
|
||
|
||
.span-8 {
|
||
grid-column: span 8;
|
||
}
|
||
|
||
.span-12 {
|
||
grid-column: span 12;
|
||
}
|
||
|
||
.tag {
|
||
display: inline-block;
|
||
padding: 4px 10px;
|
||
border-radius: 999px;
|
||
font-size: 12px;
|
||
font-weight: 600;
|
||
background: var(--brand-soft);
|
||
color: var(--brand);
|
||
margin-bottom: 10px;
|
||
}
|
||
|
||
.status-ok {
|
||
background: #e8f7ed;
|
||
color: var(--ok);
|
||
}
|
||
|
||
.status-warn {
|
||
background: #fff3e0;
|
||
color: var(--warn);
|
||
}
|
||
|
||
.status-danger {
|
||
background: #fdecec;
|
||
color: var(--danger);
|
||
}
|
||
|
||
.diagram {
|
||
background: #0b1220;
|
||
color: #dce6ff;
|
||
border-radius: 18px;
|
||
padding: 20px;
|
||
overflow: auto;
|
||
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
|
||
font-size: 13px;
|
||
line-height: 1.6;
|
||
border: 1px solid rgba(255, 255, 255, 0.08);
|
||
}
|
||
|
||
.list {
|
||
margin: 10px 0 0;
|
||
padding-left: 18px;
|
||
color: var(--muted);
|
||
}
|
||
|
||
.list li + li {
|
||
margin-top: 8px;
|
||
}
|
||
|
||
table {
|
||
width: 100%;
|
||
border-collapse: collapse;
|
||
margin-top: 10px;
|
||
font-size: 14px;
|
||
}
|
||
|
||
th, td {
|
||
border: 1px solid var(--line);
|
||
padding: 12px 14px;
|
||
text-align: left;
|
||
vertical-align: top;
|
||
}
|
||
|
||
th {
|
||
background: #f8fafc;
|
||
font-weight: 700;
|
||
}
|
||
|
||
.footer-note {
|
||
color: var(--muted);
|
||
font-size: 13px;
|
||
margin-top: 12px;
|
||
}
|
||
|
||
.illustration {
|
||
width: 100%;
|
||
border-radius: 22px;
|
||
border: 1px solid var(--line);
|
||
background: #fff;
|
||
box-shadow: var(--shadow);
|
||
}
|
||
|
||
.mindmap-shell {
|
||
background:
|
||
radial-gradient(circle at top, rgba(15, 98, 254, 0.08), transparent 32%),
|
||
linear-gradient(180deg, #f8fbff 0%, #f3f7ff 100%);
|
||
border: 1px solid var(--line);
|
||
border-radius: 22px;
|
||
padding: 26px 18px 22px;
|
||
}
|
||
|
||
.mindmap-center {
|
||
width: min(360px, 100%);
|
||
margin: 0 auto 20px;
|
||
background: linear-gradient(135deg, #0f62fe 0%, #2b7cff 100%);
|
||
color: #fff;
|
||
padding: 18px 20px;
|
||
border-radius: 18px;
|
||
text-align: center;
|
||
box-shadow: var(--shadow);
|
||
}
|
||
|
||
.mindmap-center strong {
|
||
display: block;
|
||
font-size: 20px;
|
||
margin-bottom: 6px;
|
||
}
|
||
|
||
.mindmap-grid {
|
||
display: grid;
|
||
grid-template-columns: repeat(2, minmax(0, 1fr));
|
||
gap: 18px;
|
||
position: relative;
|
||
}
|
||
|
||
.branch {
|
||
background: #fff;
|
||
border: 1px solid var(--line);
|
||
border-radius: 18px;
|
||
padding: 18px;
|
||
box-shadow: 0 8px 24px rgba(16, 24, 40, 0.06);
|
||
}
|
||
|
||
.branch-title {
|
||
display: inline-flex;
|
||
align-items: center;
|
||
padding: 6px 12px;
|
||
border-radius: 999px;
|
||
background: var(--brand-soft);
|
||
color: var(--brand);
|
||
font-size: 13px;
|
||
font-weight: 700;
|
||
margin-bottom: 10px;
|
||
}
|
||
|
||
.branch ul {
|
||
margin: 10px 0 0;
|
||
padding-left: 18px;
|
||
color: var(--muted);
|
||
}
|
||
|
||
.branch li + li {
|
||
margin-top: 8px;
|
||
}
|
||
|
||
.tree-diagram {
|
||
background: #0b1220;
|
||
color: #dce6ff;
|
||
border-radius: 18px;
|
||
padding: 20px;
|
||
overflow: auto;
|
||
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
|
||
font-size: 13px;
|
||
line-height: 1.75;
|
||
border: 1px solid rgba(255, 255, 255, 0.08);
|
||
white-space: pre;
|
||
}
|
||
|
||
@media (max-width: 900px) {
|
||
.span-4, .span-6, .span-8, .span-12 {
|
||
grid-column: span 12;
|
||
}
|
||
|
||
.hero {
|
||
padding: 28px 22px;
|
||
}
|
||
|
||
.hero h1 {
|
||
font-size: 28px;
|
||
}
|
||
|
||
.mindmap-grid {
|
||
grid-template-columns: 1fr;
|
||
}
|
||
}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<div class="page">
|
||
<section class="hero">
|
||
<h1>Codex 多机协作控制架构</h1>
|
||
<p>
|
||
目标是让你只和一个主 Agent 对话，由主 Agent 调度多台 Mac、Windows 和云服务器上的 Codex 线程进行开发。
|
||
每个项目都可以查看聊天记录、执行进度、命令历史和补丁结果，并通过外部记忆系统解决长上下文导致的“越写越钝”问题。
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>一、核心结论</h2>
|
||
<div class="grid">
|
||
<div class="card soft span-4">
|
||
<div class="tag">产品形态</div>
|
||
<strong>单主会话，多执行线程</strong>
|
||
<p class="lead">
|
||
手机端始终只有一个主对话入口，真正执行代码的是多个短上下文 Codex worker。
|
||
</p>
|
||
</div>
|
||
<div class="card soft span-4">
|
||
<div class="tag">技术底座</div>
|
||
<strong>LangGraph + Codex app-server / SDK</strong>
|
||
<p class="lead">
|
||
LangGraph 负责任务编排，Codex 负责本地和远程代码执行，会话历史由统一事件库镜像。
|
||
</p>
|
||
</div>
|
||
<div class="card soft span-4">
|
||
<div class="tag">记忆策略</div>
|
||
<strong>系统记忆外置，不依赖单线程上下文</strong>
|
||
<p class="lead">
|
||
项目事实、设计约束、决策记录和阶段摘要统一保存在控制平面，避免单个线程长期膨胀。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二、系统总览图</h2>
|
||
<div class="diagram">
|
||
[ 手机 App / Web 控制台 ]
|
||
|
|
||
v
|
||
[ API 网关 + WebSocket 实时推送 ]
|
||
|
|
||
v
|
||
[ 运维层 / 运维审计层 ]
|
||
├─ 主运维层（可接管其他项目）
|
||
├─ Ops Control Plane
|
||
├─ Ops Policy Engine
|
||
├─ Chief Ops Audit Agent
|
||
├─ Ops Ledger
|
||
├─ Ops Extension Registry / Connector Runtime
|
||
└─ 全局健康矩阵 / 修复工单 / Runbook / Rescue Mode
|
||
|
|
||
v
|
||
[ Control Plane / 云服务器 ]
|
||
├─ Master Agent Runtime (LangGraph)
|
||
├─ Project Memory (决策账本 + 向量记忆)
|
||
├─ Event Store (聊天记录 / 命令 / Patch / 审批)
|
||
├─ Scheduler / Capability Router
|
||
├─ Thread Registry
|
||
├─ Inter-Thread Broker
|
||
├─ Audit Orchestrator
|
||
├─ Rules Audit Engine
|
||
├─ Specialist Audit Agents
|
||
│ ├─ 软件审计 Agent
|
||
│ ├─ 硬件审计 Agent
|
||
│ ├─ 多模态审计 Agent
|
||
│ └─ 总审计 Agent
|
||
└─ Quota / Rate Limit Monitor
|
||
|
|
||
+--------------------+--------------------+--------------------+
|
||
| | | |
|
||
v v v v
|
||
[ Mac Worker ] [ Windows Worker ] [ Cloud Worker ] [ Standby Controller ]
|
||
├─ Codex app-server ├─ Codex app-server ├─ Codex app-server ├─ 冷/热备控制器
|
||
├─ Repo Worktrees ├─ WSL2 + Repo ├─ Repo Worktrees ├─ 接管调度
|
||
├─ MCP / 本地工具 ├─ GPU Service ├─ CI / 长任务 └─ 读取事件和状态
|
||
├─ Thread Gateway ├─ Thread Gateway ├─ Thread Gateway
|
||
├─ Local Ops Agent ├─ Local Ops Agent ├─ Local Ops Agent
|
||
├─ Local Ops Audit ├─ Local Ops Audit ├─ Local Ops Audit
|
||
├─ Camera / Mic / Speaker
|
||
└─ Test Rig Gateway ├─ Thumb Robot / USB / Relay
|
||
└─ 心跳与事件上报 └─ 心跳与事件上报 └─ 心跳与事件上报
|
||
</div>
|
||
<p class="footer-note">
|
||
说明：主 Agent 不直接持有全部项目真相，所有关键状态都会落在事件库、任务账本和项目记忆中，因此主 Agent 崩溃后可以被接管。
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>三、整体架构思维导图（完整版）</h2>
|
||
<p class="lead">
|
||
这张是完整的总架构脑图，不是摘要版。你可以把它理解成“整个产品怎么拼起来”的树状图。
|
||
</p>
|
||
<div class="tree-diagram">Codex 多机协作系统
|
||
├─ 1. 用户入口
|
||
│ ├─ 手机 App / Web
|
||
│ ├─ 单一主对话窗口
|
||
│ ├─ 项目列表
|
||
│ ├─ 线程详情页
|
||
│ └─ 审批 / 告警 / 节点状态
|
||
├─ 2. 主控层（云服务器）
|
||
│ ├─ API 网关
|
||
│ ├─ WebSocket 实时推送
|
||
│ ├─ Master Agent Runtime
|
||
│ │ ├─ LangGraph 编排
|
||
│ │ ├─ 任务拆分
|
||
│ │ ├─ 节点选择
|
||
│ │ ├─ 上下文裁剪
|
||
│ │ └─ 人工协同
|
||
│ ├─ Scheduler / Capability Router
|
||
│ ├─ Thread Registry
|
||
│ ├─ Inter-Thread Broker
|
||
│ ├─ Quota / Rate Limit Monitor
|
||
│ └─ Standby Controller
|
||
├─ 2.5 运维层与运维审计层
|
||
│ ├─ 主运维层
|
||
│ │ ├─ 当前 Codex 协作系统
|
||
│ │ └─ 未来接入的其他项目运维域
|
||
│ ├─ Ops Control Plane
|
||
│ ├─ Ops Policy Engine
|
||
│ ├─ Chief Ops Audit Agent
|
||
│ ├─ Ops Ledger
|
||
│ ├─ Ops Extension Registry
|
||
│ ├─ Ops Connector Runtime
|
||
│ ├─ 高频模式巡检（5 分钟）
|
||
│ ├─ 空闲模式巡检（1 小时）
|
||
│ ├─ 主控反向抢救运维层
|
||
│ ├─ 主控在线审批修复
|
||
│ └─ 主控离线紧急接管修复
|
||
├─ 3. 记忆与数据层（云服务器）
|
||
│ ├─ Postgres
|
||
│ │ ├─ 项目
|
||
│ │ ├─ 任务
|
||
│ │ ├─ 线程镜像
|
||
│ │ ├─ 审批记录
|
||
│ │ └─ 节点心跳
|
||
│ ├─ Vector Store
|
||
│ │ ├─ 项目长期记忆
|
||
│ │ ├─ 阶段摘要
|
||
│ │ ├─ 设计约束
|
||
│ │ └─ 经验检索
|
||
│ ├─ Object Storage
|
||
│ │ ├─ 原始事件日志
|
||
│ │ ├─ 导出的报告
|
||
│ │ └─ 补丁快照
|
||
│ └─ Redis / Queue
|
||
│ ├─ 任务队列
|
||
│ └─ 事件广播
|
||
├─ 4. 执行层（多节点）
|
||
│ ├─ Mac Worker
|
||
│ │ ├─ Codex app-server / SDK
|
||
│ │ ├─ worktree / branch
|
||
│ │ ├─ MCP / 本地工具
|
||
│ │ ├─ Thread Gateway
|
||
│ │ ├─ Local Ops Agent
|
||
│ │ ├─ Local Ops Audit Agent
|
||
│ │ └─ 前端 / iOS / macOS 任务
|
||
│ ├─ Windows Worker（WSL2）
|
||
│ │ ├─ Codex app-server / SDK
|
||
│ │ ├─ GPU Bridge
|
||
│ │ ├─ PowerShell / 原生工具桥
|
||
│ │ ├─ Thread Gateway
|
||
│ │ ├─ Local Ops Agent
|
||
│ │ ├─ Local Ops Audit Agent
|
||
│ │ └─ CUDA / NVIDIA / Windows 任务
|
||
│ └─ Cloud Worker
|
||
│ ├─ Codex app-server / SDK
|
||
│ ├─ CI / 测试矩阵
|
||
│ ├─ Thread Gateway
|
||
│ ├─ Local Ops Agent
|
||
│ ├─ Local Ops Audit Agent
|
||
│ ├─ 长耗时任务
|
||
│ └─ 批处理任务
|
||
├─ 5. 审计层
|
||
│ ├─ Audit Orchestrator
|
||
│ ├─ Rules Audit Engine
|
||
│ │ ├─ 超时检测
|
||
│ │ ├─ 卡死检测
|
||
│ │ ├─ 重复失败检测
|
||
│ │ ├─ 上下文压缩过多检测
|
||
│ │ ├─ 视频流 / 摄像头在线检测
|
||
│ │ └─ 额度异常检测
|
||
│ ├─ 软件审计 Agent
|
||
│ ├─ 硬件审计 Agent
|
||
│ ├─ 多模态审计 Agent
|
||
│ └─ 总审计 Agent
|
||
├─ 6. 测试硬件能力层
|
||
│ ├─ Capability Registry
|
||
│ ├─ Device Lease / Preemption
|
||
│ ├─ Camera / Mic / Speaker
|
||
│ ├─ Thumb Robot / Relay / USB 控制器
|
||
│ └─ 视频流 / 关键帧 / 传感器采样
|
||
└─ 7. 容灾层
|
||
├─ 主控故障切换
|
||
├─ 数据库备份恢复
|
||
├─ worker 重派
|
||
├─ 账号额度切换
|
||
├─ 运维紧急修复
|
||
└─ 人工接管</div>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>四、技术实现方案</h2>
|
||
<h3>1. 手机端</h3>
|
||
<ul class="list">
|
||
<li>建议先做 PWA 或响应式 Web 控制台，再按需要封装成 iOS / Android App。</li>
|
||
<li>页面包括：主对话页、项目列表页、项目线程页、审批中心、节点状态页、告警页。</li>
|
||
<li>所有实时状态通过 WebSocket 推送，点开项目后直接读取 thread mirror 和增量事件。</li>
|
||
<li>主对话页顶部增加一个非常轻量的“当前主控身份提示条”，只占一行小胶囊区域，显示当前主脑来源：`主 GPT`、`备用 GPT` 或 `API 容灾`。</li>
|
||
<li>这个提示条默认只显示 3 段信息：当前身份、所在线节点、最近切换时间；点击后再展开完整详情，不占据主聊天区。</li>
|
||
</ul>
|
||
|
||
<h3>2. 控制平面</h3>
|
||
<ul class="list">
|
||
<li>主控服务放在云服务器，避免主调度器依赖某一台个人电脑。</li>
|
||
<li>LangGraph 负责任务拆解、状态流转、checkpoint 恢复和人工介入。</li>
|
||
<li>Project Memory 负责保存项目目标、约束、阶段总结、未决问题、关键决策。</li>
|
||
<li>Scheduler 根据节点能力、系统负载、Codex 限额和任务类型选择执行节点。</li>
|
||
</ul>
|
||
|
||
<h3>3. Worker 节点</h3>
|
||
<ul class="list">
|
||
<li>每台 Mac、Windows、云服务器都运行一个 worker daemon。</li>
|
||
<li>worker daemon 连接本机 Codex app-server / SDK，启动和恢复线程，读取事件并上传到事件库。</li>
|
||
<li>每个任务使用独立 worktree / branch，避免不同线程直接写同一个工作目录。</li>
|
||
<li>Windows 节点建议用 WSL2 跑 worker，本地 GPU、PowerShell、原生程序通过桥接服务暴露。</li>
|
||
</ul>
|
||
|
||
<h3>4. 线程与记忆策略</h3>
|
||
<ul class="list">
|
||
<li>每个项目不是一个超长线程，而是多个短线程：功能线程、修复线程、实验线程、评审线程。</li>
|
||
<li>线程执行结束后，worker 自动回传阶段摘要、关键文件、风险、测试结果和待办。</li>
|
||
<li>主控只把最小必要上下文派给下一次线程，避免长期上下文压缩导致能力下降。</li>
|
||
<li>每个 worker 必须持续上报线程上下文预算：`context_budget_remaining_pct`、`context_budget_level`、`compaction_expected_at`。</li>
|
||
<li>手机端会话列表第三层使用统一的圆环进度标记显示“背景信息窗口余量”，该标记与设备端线程页保持一致，不能由前端自行估算。</li>
|
||
<li>主 Agent 必须把“压缩前收尾”当成一等公民，在上下文预算进入危险区前优先完成关键结论固化、补丁固化、测试结论固化和线程交接。</li>
|
||
</ul>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>上下文预算等级</th>
|
||
<th>阈值</th>
|
||
<th>主 Agent 默认动作</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>`safe`</td>
|
||
<td>`>= 60%`</td>
|
||
<td>正常推进任务，但持续刷新阶段摘要和关键证据引用。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`watch`</td>
|
||
<td>`40% ~ 59%`</td>
|
||
<td>不再向该线程追加大块背景信息，开始准备阶段摘要和下一线程交接包。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`urgent`</td>
|
||
<td>`25% ~ 39%`</td>
|
||
<td>优先完成当前原子子任务，同时预创建接力线程，确保 compaction 前完成 handoff。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`critical`</td>
|
||
<td>`< 25%`</td>
|
||
<td>禁止继续扩张上下文，立即执行“压缩前收尾”：固化 patch、命令、测试结论、关键决策、未决问题和证据链接。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>5. 额度监控集成（直接复用 gptpluscontrol）</h3>
|
||
<ul class="list">
|
||
<li>不重新发明额度监控，直接复用 `/Users/kris/code/gptpluscontrol` 已有的后端、Agent、SSE 和数据结构。</li>
|
||
<li>手机 App 和 Web 控制台从控制平面读取“主控状态”，同时从 gptpluscontrol 读取“各 Codex 节点剩余额度和当前占用状态”。</li>
|
||
<li>建议先把 gptpluscontrol 作为独立服务并行部署，再由控制平面聚合其接口；后续若要统一，可再把其接口协议并入主系统。</li>
|
||
</ul>
|
||
|
||
<h3>6. 跨节点线程对话机制</h3>
|
||
<ul class="list">
|
||
<li>允许 Mac、Windows、云节点上的任意 Codex 线程在主 Agent 监管下进行线程到线程对话，但不采用裸点对点直连。</li>
|
||
<li>系统实现采用“逻辑直连、物理经主控转发”：发送线程把消息交给本地 `Thread Gateway`，再经 `Inter-Thread Broker` 路由到目标节点。</li>
|
||
<li>默认只允许同一项目内线程互通，跨项目通信必须显式授权。</li>
|
||
<li>消息默认只传任务摘要、必要上下文、附件引用和最近结论，不直接透传完整历史，避免上下文污染和容量膨胀。</li>
|
||
</ul>
|
||
|
||
<h3>7. 开发规格：线程地址、消息协议与监管模式</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>设计项</th>
|
||
<th>规格</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>线程全局地址</td>
|
||
<td>`{node_id}:{thread_id}`，例如 `mac-01:thread-abc`、`win-gpu-02:thread-xyz`。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Thread Registry</td>
|
||
<td>保存 `project_id`、`node_id`、`thread_id`、`role`、`status`、`allowed_peers`、`access_mode`、`last_seen_at`、`context_budget`。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>消息 Envelope</td>
|
||
<td>至少包含 `message_id`、`project_id`、`sender_thread_ref`、`receiver_thread_ref`、`intent`、`summary`、`attachments`、`ttl_seconds`、`approval_mode`、`created_at`。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>监管模式</td>
|
||
<td>`observe`、`approve_first`、`strict` 三种。默认项目内线程采用 `approve_first`。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>传输链路</td>
|
||
<td>`Sender Thread -> Local Thread Gateway -> Inter-Thread Broker -> Receiver Gateway -> Receiver Thread`。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>结果回传</td>
|
||
<td>目标线程回复后，结果按原路返回并写入双方 thread mirror，同时产生 broker 级事件日志。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>失败处理</td>
|
||
<td>目标线程离线、超时、拒绝、权限不足时进入重试或 dead-letter 队列，并由主 Agent 决定重派、降级或人工介入。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>8. 线程对话的权限与审计要求</h3>
|
||
<ul class="list">
|
||
<li>所有跨节点线程对话必须带 `project_id` 和 `intent`，禁止匿名消息。</li>
|
||
<li>`Inter-Thread Broker` 必须检查 ACL：项目边界、角色边界、节点边界、监管模式、最大 turn 数和消息 TTL。</li>
|
||
<li>所有线程对话都必须写入 `Event Store`，手机端项目页可以查看“谁在向谁发起对话、原因是什么、结果是什么”。</li>
|
||
<li>主 Agent 对线程对话有冻结权、禁言权和强制断链权，审计层可对异常通信做告警。</li>
|
||
</ul>
|
||
|
||
<h3>9. UI 表达与产品交互</h3>
|
||
<ul class="list">
|
||
<li>项目线程页要显示“跨节点协作”时间线，突出展示 `发送线程`、`目标线程`、`intent`、`状态`、`摘要结果`。</li>
|
||
<li>节点详情页要显示该设备当前正在参与的跨节点对话数、最近交互对象和失败次数。</li>
|
||
<li>主对话页里，当主 Agent让某个线程去和其他节点线程协作时，应出现一条简短系统消息，例如“已让 Mac 前端线程向 Windows GPU 线程请求推理结果”。</li>
|
||
</ul>
|
||
|
||
<h3>10. 开放式审计与硬件接管</h3>
|
||
<ul class="list">
|
||
<li>审计层不只审代码，还要能在需要时接管真实测试硬件，因此必须设计成开放能力系统，而不是只读日志的观察者。</li>
|
||
<li>每台设备都可以注册自己的“测试能力”，例如摄像头、麦克风、扬声器、屏幕采集、串口、USB 控制器、拇指机器人、继电器、可编程电源等。</li>
|
||
<li>控制平面维护统一的 `Capability Registry`，记录每个能力所在节点、当前占用状态、优先级和可抢占性。</li>
|
||
<li>审计 Agent 在被授权后，通过 `Device Lease / Preemption` 机制秒级接管这些能力，完成交互测试、硬件回归和多模态验证。</li>
|
||
<li>视频流不建议长期整路上传，边缘节点先提取关键帧、短视频片段、OCR 和检测结果，再由多模态审计 Agent 复核。</li>
|
||
</ul>
|
||
|
||
<h3>11. 运维层与运维审计层</h3>
|
||
<ul class="list">
|
||
<li>在整个系统的最外层增加 `Ops Layer` 和 `Ops Audit Layer`，它们负责监管主控、Worker、审计层、硬件层、数据层、额度层是否健康。</li>
|
||
<li>每一台接入系统的终端设备，无论是 Mac、Windows、云工作机还是独立测试台，都必须常驻 `Local Ops Agent` 和 `Local Ops Audit Agent`。</li>
|
||
<li>`Local Ops Agent` 负责巡检、分类、执行修复；`Local Ops Audit Agent` 负责监督运维 Agent、判定修复权限、执行修复复验。</li>
|
||
<li>巡检频率由 `Ops Policy Engine` 动态调节：高频使用状态下每 5 分钟一次；无人使用且没有现场工作时每 1 小时一次。</li>
|
||
<li>主 Agent 每小时至少检查一次整个运维层是否健康，确认所有节点的运维 Agent / 运维审计 Agent 在线且最近一次巡检成功。</li>
|
||
<li>当主 Agent 在线且能正常响应时，运维 Agent 发起修复必须先经主 Agent 同意；当主 Agent 失联时，运维审计 Agent 才能做最终修复执行判断。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>五、每个服务运行在哪台机器</h2>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>服务</th>
|
||
<th>建议部署位置</th>
|
||
<th>原因</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>手机端 Web / App</td>
|
||
<td>手机浏览器 / App</td>
|
||
<td>只作为统一入口，不承担调度和记忆。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>API 网关 + WebSocket</td>
|
||
<td>云服务器</td>
|
||
<td>保证外网访问稳定，统一所有设备接入。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Master Agent Runtime</td>
|
||
<td>云服务器主节点</td>
|
||
<td>主调度器不依赖个人电脑是否开机，适合持续运行。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Thread Registry / Inter-Thread Broker</td>
|
||
<td>云服务器</td>
|
||
<td>管理跨节点线程地址、权限、消息路由、重试和审计留痕。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Project Memory / Event Store / Postgres / Redis</td>
|
||
<td>云服务器或云数据库</td>
|
||
<td>需要集中存储，便于跨设备读取和灾难恢复。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>gptpluscontrol Backend</td>
|
||
<td>云服务器</td>
|
||
<td>作为现成额度监控服务，提供账号、Agent、容量和 SSE 实时流。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Audit Orchestrator</td>
|
||
<td>云服务器</td>
|
||
<td>负责编排规则审计、软件审计、硬件审计、多模态审计和总审计结果汇总。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Ops Control Plane / Ops Policy Engine</td>
|
||
<td>云服务器</td>
|
||
<td>统一计算巡检模式、汇总节点健康、管理修复工单、审批策略与紧急接管规则。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Ops Extension Registry / Connector Runtime</td>
|
||
<td>云服务器</td>
|
||
<td>作为开放式主运维层的扩展入口，用来注册其他项目、其他服务、其他测试台的运维域、连接器和 Runbook Pack。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Chief Ops Audit Agent / Ops Ledger</td>
|
||
<td>云服务器</td>
|
||
<td>负责跨节点运维复核、主控离线时的最终修复判断、修复留痕与主控恢复后的同步汇报。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Rules Audit Engine</td>
|
||
<td>云服务器</td>
|
||
<td>与主控分离运行，持续监听任务和节点状态。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Specialist Audit Agents</td>
|
||
<td>云服务器</td>
|
||
<td>包含软件审计、硬件审计、多模态审计和总审计 Agent，按事件或策略触发。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Mac Worker Daemon</td>
|
||
<td>每台 Mac 本机</td>
|
||
<td>负责 Xcode、前端、macOS / iOS 相关开发任务。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Thread Gateway（Mac）</td>
|
||
<td>每台 Mac 本机</td>
|
||
<td>接收和发送本机线程消息，把跨节点对话接入 Broker。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>gptpluscontrol Agent（Mac）</td>
|
||
<td>每台 Mac 本机</td>
|
||
<td>负责上报本机 Codex 当前账号、5h/7d 剩余额度、登录切换和心跳。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Agent（Mac）</td>
|
||
<td>每台 Mac 本机</td>
|
||
<td>负责本机 Worker、Thread Gateway、Test Rig、gptpluscontrol Agent 等组件的巡检与修复执行。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Audit Agent（Mac）</td>
|
||
<td>每台 Mac 本机</td>
|
||
<td>负责监督本机运维 Agent、复验修复动作、在主控离线时参与紧急修复判断。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Windows Worker Daemon</td>
|
||
<td>Windows 本机的 WSL2</td>
|
||
<td>兼顾 Codex 兼容性和 NVIDIA / Windows 工具链调用。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Thread Gateway（Windows）</td>
|
||
<td>Windows 本机的 WSL2 或本机桥接层</td>
|
||
<td>负责 Windows 线程与云端 Broker 之间的消息收发和状态同步。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>gptpluscontrol Agent（Windows）</td>
|
||
<td>Windows 本机</td>
|
||
<td>负责上报 Windows 节点的额度、当前绑定账号、Agent 在线状态和切换事件。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Agent（Windows）</td>
|
||
<td>Windows 本机或 WSL2 邻近桥接层</td>
|
||
<td>负责本机 Worker、GPU Bridge、Thread Gateway、测试桥的巡检与自愈执行。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Audit Agent（Windows）</td>
|
||
<td>Windows 本机或 WSL2 邻近桥接层</td>
|
||
<td>负责监督本机运维 Agent、复验修复动作、在主控离线时做本地紧急修复复核。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>GPU Bridge / Windows 工具桥</td>
|
||
<td>Windows 本机</td>
|
||
<td>为 Mac 或云端 worker 暴露 GPU 推理和原生工具能力。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Test Rig Gateway / 硬件测试桥</td>
|
||
<td>挂载测试外设的 Mac / Windows / 独立测试台</td>
|
||
<td>向审计层暴露摄像头、麦克风、扬声器、拇指机器人、串口、继电器等可接管测试能力。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Cloud Worker Daemon</td>
|
||
<td>云服务器或云工作机</td>
|
||
<td>承担长耗时任务、批处理、CI、测试矩阵和后台流程。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Thread Gateway（Cloud）</td>
|
||
<td>云 worker 同机部署</td>
|
||
<td>负责云侧线程加入跨节点协作网络并接收主控监管。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Agent（Cloud）</td>
|
||
<td>每台云 worker 同机部署</td>
|
||
<td>负责云 worker、线程网关、CI 进程、日志上报和修复脚本执行。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Audit Agent（Cloud）</td>
|
||
<td>每台云 worker 同机部署</td>
|
||
<td>负责监督本机运维 Agent、复验修复动作、保障云侧节点自愈链路可用。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Standby Controller</td>
|
||
<td>第二台云服务器或同云异可用区</td>
|
||
<td>主控故障时接管调度。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>六、主 Agent 怎么使用 ChatGPT 蓝色账号上的 Codex 额度</h2>
|
||
<div class="grid">
|
||
<div class="card span-6">
|
||
<div class="tag status-ok">推荐方案</div>
|
||
<strong>主控用 API，Worker 用 Plus 账号登录 Codex</strong>
|
||
<ul class="list">
|
||
<li>主 Agent 运行在云端，使用 API 模型做编排与决策。</li>
|
||
<li>每个 worker 节点用一个 ChatGPT Plus 账号登录本机 Codex。</li>
|
||
<li>调度器读取每个 worker 的限额和负载，把任务派给还有余量的节点。</li>
|
||
<li>这种方式最稳，因为主脑不被单个桌面账号会话绑定。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-6">
|
||
<div class="tag status-warn">可选方案</div>
|
||
<strong>单独放一台 Master Codex Node</strong>
|
||
<ul class="list">
|
||
<li>单独一台机器运行“主控 Codex”，绑定一个蓝色账号。</li>
|
||
<li>控制平面通过 Codex app-server / SDK 调用它，视它为主脑执行器。</li>
|
||
<li>适合保留强烈的 Codex 使用体验，但稳定性低于 API 主脑方案。</li>
|
||
<li>不建议把多个 Plus 账号设计成一个透明共享额度池，而是按节点账号分别调度。</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<p class="footer-note">
|
||
设计原则：Plus 额度按“节点级账号”使用，不按“中央公共额度池”设计。调度器要监控每个节点账号的剩余额度和速率限制。
|
||
</p>
|
||
<div class="card soft span-12" style="margin-top:16px;">
|
||
<div class="tag status-danger">关键澄清</div>
|
||
<strong>云服务器上的纯主控服务，不能直接继承你的 ChatGPT Plus“最新模型额度”</strong>
|
||
<ul class="list">
|
||
<li>如果主 Agent 只是一个运行在云服务器上的 LangGraph / API 服务，它使用的是 API 计费和 API 限额，不会自动继承 ChatGPT Plus 的聊天或 Codex 订阅额度。</li>
|
||
<li>OpenAI 官方目前明确说明：ChatGPT 中的模型可用性与 Codex 分开管理，API 的可用性和价格也单独管理。</li>
|
||
<li>所以你不能把“云上的主控 API 服务”直接视作“在吃 ChatGPT Plus 最新模型额度”。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card soft span-12" style="margin-top:16px;">
|
||
<div class="tag status-warn">如果你坚持要用 Plus 额度</div>
|
||
<strong>要把主 Agent 变成一个“Master Codex Node”</strong>
|
||
<ul class="list">
|
||
<li>单独准备一台始终在线的机器，例如一台常开 Mac mini、常开 Windows WSL2 节点，或者你确认可稳定登录的云工作机。</li>
|
||
<li>这台机器上登录一个 ChatGPT Plus 账号，让本机 Codex 作为“主脑执行器”。</li>
|
||
<li>云上的控制平面不直接调用 Plus 额度，而是通过 app-server / SDK 去调用这台 Master Codex Node。</li>
|
||
<li>这时消耗的是这台主控节点绑定账号的 Codex 配额，而不是云主控服务本身的 API 配额。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card soft span-12" style="margin-top:16px;">
|
||
<div class="tag">UI 要求</div>
|
||
<strong>主控身份提示条的交互规范</strong>
|
||
<ul class="list">
|
||
<li>位置：主对话页顶部标题栏右侧，优先做成一个小胶囊标签，不占据大卡片区域。</li>
|
||
<li>状态值：`主 GPT`、`备用 GPT`、`API 容灾`。</li>
|
||
<li>展开信息：当前节点名、当前账号 display name、最近切换时间、切换原因。</li>
|
||
<li>颜色建议：主 GPT 用蓝色，备用 GPT 用橙色，API 容灾用灰色或紫灰色。</li>
|
||
</ul>
|
||
</div>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>七、向量库存在哪里</h2>
|
||
<div class="grid">
|
||
<div class="card span-6">
|
||
<div class="tag status-ok">推荐位置</div>
|
||
<strong>向量库放在云端，作为控制平面的集中记忆层</strong>
|
||
<ul class="list">
|
||
<li>建议和 `Postgres` 一起放在云服务器或云数据库中，MVP 阶段优先使用 `pgvector`，最简单也最稳。</li>
|
||
<li>它保存的不是源代码本身，而是项目摘要、设计约束、阶段结论、排障经验、已知风险和历史决策。</li>
|
||
<li>所有 worker 都只读写这一个“中心记忆库”，不要每台电脑各自维护一套主记忆。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-6">
|
||
<div class="tag status-warn">为什么不放本地</div>
|
||
<strong>本地只能有缓存，不能有主版本</strong>
|
||
<ul class="list">
|
||
<li>如果主记忆放在某台 Mac 或 Windows 本地，这台机器掉线时，主 Agent 就会失明。</li>
|
||
<li>你要的是手机统一查看、跨设备协作，所以 canonical memory 必须在云端。</li>
|
||
<li>本地 worker 可以保留短期缓存或索引副本，但最终真相必须回写到云端向量库和数据库。</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>方案</th>
|
||
<th>建议</th>
|
||
<th>适用阶段</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Postgres + pgvector</td>
|
||
<td>最推荐，部署简单，备份和高可用可以与主数据库统一管理。</td>
|
||
<td>MVP 到中期产品</td>
|
||
</tr>
|
||
<tr>
|
||
<td>独立 Qdrant / Weaviate</td>
|
||
<td>当检索规模、性能、分片需求更高时再拆出。</td>
|
||
<td>中后期</td>
|
||
</tr>
|
||
<tr>
|
||
<td>每台 worker 本地向量库</td>
|
||
<td>不建议作为主记忆，只能做本地加速缓存。</td>
|
||
<td>仅优化阶段</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>八、Codex 剩余额度显示与 gptpluscontrol 集成</h2>
|
||
<p class="lead">
|
||
额度监控不新做，直接复用现有 `gptpluscontrol` 项目。当前项目已经具备云端 Backend、macOS / Windows Agent、REST API 和 SSE 实时刷新能力。
|
||
</p>
|
||
|
||
<h3>1. 推荐集成方式</h3>
|
||
<ul class="list">
|
||
<li>把 `gptpluscontrol Backend` 部署在云服务器，与主控控制平面同域或同内网。</li>
|
||
<li>每台 Mac / Windows 设备同时运行 `worker daemon` 和 `gptpluscontrol agent`。</li>
|
||
<li>手机 App 和 Web 端通过控制平面 BFF 聚合两类数据：项目执行数据来自主控，额度和账号状态来自 gptpluscontrol。</li>
|
||
<li>前端只显示最终聚合后的统一视图，避免手机端同时直连多个系统。</li>
|
||
</ul>
|
||
|
||
<h3>2. 可以直接复用的数据接口</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>接口</th>
|
||
<th>用途</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>`GET /api/v1/agents`</td>
|
||
<td>读取每台设备的在线状态、当前 Codex 账号、5h/7d 剩余额度、最近切号和交接信息。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`GET /api/v1/accounts`</td>
|
||
<td>读取账号池列表、剩余额度、重置时间、当前使用状态、账号占用情况。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`GET /api/v1/accounts/{account_id}`</td>
|
||
<td>读取单个账号的详细历史、错误和趋势。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`GET /api/v1/dashboard/summary`</td>
|
||
<td>读取总账号数、正常数、失败数、在线 Agent 数量等总览卡片数据。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`GET /api/v1/capacity/report`</td>
|
||
<td>读取容量预警、剩余覆盖天数、预计耗尽时间和建议。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`GET /api/v1/events/stream`</td>
|
||
<td>通过 SSE 接收实时刷新事件，推动前端更新设备和额度状态。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>3. 当前可直接利用的关键字段</h3>
|
||
<ul class="list">
|
||
<li>`codex_current_display_name`：当前设备绑定的 Codex 账号显示名。</li>
|
||
<li>`codex_current_window_5h_remaining`：当前 5 小时窗口剩余额度。</li>
|
||
<li>`codex_current_window_7d_remaining`：当前 7 天窗口剩余额度。</li>
|
||
<li>`codex_last_switch_at` / `codex_last_switch_from` / `codex_last_switch_to`：最近切号时间与来源目标。</li>
|
||
<li>`codex_last_handoff_status` / `codex_last_handoff_reason`：最近交接状态和原因。</li>
|
||
<li>`usage_state`：账号当前是否被占用、是谁在使用、角色优先级和最近动作。</li>
|
||
</ul>
|
||
|
||
<h3>4. App 里的 UI 设计要求</h3>
|
||
<div class="grid">
|
||
<div class="card span-6">
|
||
<div class="tag status-ok">轻量状态提示</div>
|
||
<strong>主会话顶部显示主控身份</strong>
|
||
<ul class="list">
|
||
<li>显示：`主 GPT` / `备用 GPT` / `API 容灾`。</li>
|
||
<li>可加一个很小的副文本：当前账号简称或当前节点名。</li>
|
||
<li>点击后展开完整状态，不默认铺满页面。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-6">
|
||
<div class="tag status-ok">实时额度面板</div>
|
||
<strong>项目页和节点页显示绑定 Codex 客户端剩余额度</strong>
|
||
<ul class="list">
|
||
<li>每个节点卡片显示：设备名、在线状态、当前账号、5h 剩余、7d 剩余。</li>
|
||
<li>如果节点正在切号或等待人工登录，显示醒目的次级提示。</li>
|
||
<li>额度不足时以黄 / 红两级预警。</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<h3>5. 开发实现建议</h3>
|
||
<ul class="list">
|
||
<li>MVP 先不把 gptpluscontrol 代码强行并入主控服务，先作为独立服务部署，降低耦合。</li>
|
||
<li>主控服务新增一个 BFF 层，把 gptpluscontrol 的 API 结果转换成手机端需要的统一字段。</li>
|
||
<li>等主系统稳定后，再考虑把 gptpluscontrol 的 schema 和事件流整合进统一数据库。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>九、跨节点线程对话机制</h2>
|
||
<div class="grid">
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">核心原则</div>
|
||
<strong>逻辑直连，物理经主控转发</strong>
|
||
<p class="lead">
|
||
Mac、Windows、云节点上的线程可以互相对话，但消息必须经过 `Inter-Thread Broker` 和主控监管。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-warn">边界控制</div>
|
||
<strong>默认同项目互通，跨项目需授权</strong>
|
||
<p class="lead">
|
||
线程通信受项目边界、角色边界、监管模式、TTL 和 turn 预算共同限制。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-danger">风险规避</div>
|
||
<strong>不透传完整历史，防止上下文污染</strong>
|
||
<p class="lead">
|
||
默认只传摘要、必要附件和最近结论，避免两个线程互相放大无关上下文。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<h3>可开发的消息流</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>步骤</th>
|
||
<th>说明</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>1. 发送方封装请求</td>
|
||
<td>发送线程生成 `intent + summary + attachments`，交给本地 Thread Gateway。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>2. Broker 做权限与策略检查</td>
|
||
<td>检查 sender / receiver 是否允许通信，是否同项目，是否超过 turn budget，是否需要主 Agent 审批。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>3. 路由到目标节点</td>
|
||
<td>Broker 把消息转发到目标节点的 Thread Gateway，再交给目标 Codex 线程。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>4. 目标线程执行</td>
|
||
<td>目标线程基于收到的摘要完成计算、读取文件、运行命令或请求本地硬件能力。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>5. 结果回传</td>
|
||
<td>目标线程将摘要结果、状态、附件引用返回给 Broker，再回传给发送线程。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>6. 留痕与展示</td>
|
||
<td>整段通信写入 Event Store，并在项目 UI 的“跨节点协作”时间线上展示。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>推荐的 intent 类型</h3>
|
||
<ul class="list">
|
||
<li>`ask_compute`：请求 GPU 推理、批处理或算力任务。</li>
|
||
<li>`request_artifact`：请求文件、产物、日志、截图或模型输出。</li>
|
||
<li>`request_hardware_check`：请求目标节点执行硬件检查。</li>
|
||
<li>`request_ui_validation`：请求目标节点做 UI 或交互验证。</li>
|
||
<li>`request_test_step`：请求目标节点执行测试步骤并返回结果。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十、混合审计架构：规则审计 + 专项审计 Agent</h2>
|
||
<div class="grid">
|
||
<div class="card span-4">
|
||
<div class="tag status-danger">风险</div>
|
||
<strong>自我确认偏差</strong>
|
||
<p class="lead">
|
||
如果主 Agent 既派任务又自己评价自己，就容易忽略执行偏差、低效率循环和错误判断。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">更稳做法</div>
|
||
<strong>规则审计和多种审计 Agent 并存</strong>
|
||
<p class="lead">
|
||
规则引擎做硬性判断，专项审计 Agent 做语义判断，多模态和硬件场景由专门审计 Agent 接管。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-warn">主控职责</div>
|
||
<strong>主 Agent 做调度，不独占系统真相</strong>
|
||
<p class="lead">
|
||
所有关键信息都写入事件库和项目记忆，主控只是当前执行者，而不是唯一记忆体。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<h3>建议的分工</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>组件</th>
|
||
<th>职责</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>主 Agent</td>
|
||
<td>任务拆分、节点选择、上下文裁剪、上下文预算管理、压缩前收尾调度、阶段调度、人工沟通。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Rules Audit Engine</td>
|
||
<td>检测超时、重复失败、压缩次数过多、rate limit、队列积压、worker 离线、视频流断开、测试进程缺失等硬规则异常。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>软件审计 Agent</td>
|
||
<td>复核代码变更、测试覆盖、行为回归、接口契约、日志解释和发布风险。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>硬件审计 Agent</td>
|
||
<td>复核固件版本、设备状态、串口日志、传感器读数、OTA 后行为和外设联动是否正确。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>多模态审计 Agent</td>
|
||
<td>分析截图、关键帧、短视频、摄像头画面、音频片段，判断设备动作、屏幕状态和拟人化交互是否符合预期。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>总审计 Agent</td>
|
||
<td>汇总规则审计和各专项审计的结论，给出通过、驳回、需人工复核和返工建议。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>开放式硬件接管要求</h3>
|
||
<ul class="list">
|
||
<li>审计 Agent 必须可以接管任意在线节点上的测试硬件能力，只要该能力已在系统注册并被授权。</li>
|
||
<li>支持的能力包括但不限于：摄像头、麦克风、扬声器、屏幕采集、USB 设备、串口、继电器、拇指机器人、可编程电源、机械按键器。</li>
|
||
<li>接管不是直接抢占操作系统桌面，而是通过 `Test Rig Gateway` 暴露标准能力接口，便于审计层按能力调用。</li>
|
||
<li>所有接管都要有租约、超时、占用记录和回放证据，避免多个审计线程同时争抢同一个外设。</li>
|
||
<li>如果某个项目的交互逻辑需要完整拟人化测试，审计 Agent 可以串联摄像头 + 麦克风 + 扬声器 + 机器人执行器完成闭环测试。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十一、运维层与运维审计层</h2>
|
||
<div class="grid">
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">角色</div>
|
||
<strong>Ops Agent 负责修，Ops Audit Agent 负责判与验</strong>
|
||
<p class="lead">
|
||
运维层负责发现问题和执行修复，运维审计层负责监督运维行为、判断权限、复验结果和紧急接管。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-warn">频率</div>
|
||
<strong>高频使用时 5 分钟，空闲时 1 小时</strong>
|
||
<p class="lead">
|
||
高频模式看活跃用户、活跃任务、能力租约、现场测试和高优先级告警；全空闲时降到每小时一次。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-danger">兜底</div>
|
||
<strong>主控失联后，运维审计层可紧急决策修复</strong>
|
||
<p class="lead">
|
||
只要主 Agent 在线且可正常响应，运维修复必须先经它同意；主控失联后才由运维审计层做最终修复判断。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div class="grid" style="margin-top:16px;">
|
||
<div class="card span-6 soft">
|
||
<div class="tag">主定位</div>
|
||
<strong>运维层是主运维层，不只服务当前这一套系统</strong>
|
||
<p class="lead">
|
||
它既监管当前 Codex 多机协作系统，也作为统一运维底座接管后续其他项目、其他服务、其他测试台和其他机器群的运维场景。
|
||
</p>
|
||
</div>
|
||
<div class="card span-6 soft">
|
||
<div class="tag">开放式</div>
|
||
<strong>通过 Domain / Connector / Runbook Pack 开放扩展</strong>
|
||
<p class="lead">
|
||
新项目接入时，不需要重写整套运维层；只要注册新的运维域、连接器类型、健康探针和修复剧本，就能接入主运维层统一监管。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<h3>1. 组件与职责</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>组件</th>
|
||
<th>职责</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Ops Control Plane</td>
|
||
<td>汇总全局健康、管理巡检模式、修复工单、Runbook、开放式运维域和紧急接管策略。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Agent</td>
|
||
<td>在每个节点本地巡检进程、日志、队列、额度、硬件桥和网关，并执行修复动作。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Local Ops Audit Agent</td>
|
||
<td>监督本地 Ops Agent 是否健康、是否越权、修复是否成功，并在主控离线时做紧急修复判断。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Chief Ops Audit Agent</td>
|
||
<td>做跨节点复核、处理主控失联下的最终修复判定、在主控恢复后回放修复结果。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Ops Extension Registry / Connector Runtime</td>
|
||
<td>负责把其他项目、外部服务、外部测试台通过标准化 Connector 与 Runbook Pack 接入主运维层。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Ops Ledger</td>
|
||
<td>保存故障、修复动作、复验结论、主控恢复回执和 Runbook 映射。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>2. 日志命名与低 token 定位原则</h3>
|
||
<ul class="list">
|
||
<li>所有错误键统一采用：`<LAYER>.<DOMAIN>.<COMPONENT>.<ACTION>.<ERROR_CODE>`。</li>
|
||
<li>示例：`MASTER.SCHEDULER.DISPATCH.NODE_UNAVAILABLE`、`WORKER.CODEX.THREAD_START.RATE_LIMIT`、`OPS_AUDIT.REPAIR.VERIFY.RESTART_FAILED`。</li>
|
||
<li>每条日志至少带：`fault_key`、`severity`、`node_id`、`service_name`、`project_id`、`thread_ref`、`trace_id`、`runbook_id`。</li>
|
||
<li>Ops Agent 汇报问题时优先输出 `fault_key`、受影响节点、首次/最近时间、建议动作和 runbook，不直接把长日志贴给主控。</li>
|
||
</ul>
|
||
|
||
<h3>3. 除日志之外必须增加的救援手段</h3>
|
||
<ul class="list">
|
||
<li>心跳与存活探针：主控、Worker、线程网关、审计层、硬件桥、gptpluscontrol 都要有 heartbeat。</li>
|
||
<li>合成探针：周期性模拟创建项目、启动轻量线程、读取 thread history、申请能力租约，验证业务链路没有“表面存活、实际已坏”。</li>
|
||
<li>事件流与队列监控：看 Event Store 写入延迟、WebSocket/SSE 推送中断、消息积压、线程停滞。</li>
|
||
<li>资源与依赖监控：CPU / 内存 / GPU / 磁盘、数据库复制延迟、对象存储写失败率、网络抖动。</li>
|
||
<li>认证与额度监控：Codex 登录态、API key、Plus 剩余额度、gptpluscontrol 新鲜度、账号切换结果。</li>
|
||
<li>孤儿状态清理：孤儿 lease、孤儿 thread、孤儿 repair ticket、无人接手的审计任务。</li>
|
||
<li>现场快照抽样：关键摄像头关键帧、OCR、串口短日志、设备状态采样，用于发现“服务活着但现场已经坏了”的情况。</li>
|
||
<li>开放运维域探针：对其他接入项目的 SSH、HTTP API、Docker、K8s、Windows Service、局域网 RPC 做统一健康采样和修复映射。</li>
|
||
<li>跨设备运维动作：支持远程拉日志、远程重启服务、远程切换账号、远程重连桥接服务、远程执行 Runbook，并统一经过主运维层审批与复验。</li>
|
||
</ul>
|
||
|
||
<h3>4. 在线与离线两种修复模式</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>场景</th>
|
||
<th>决策链路</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>主 Agent 在线且能正常返回</td>
|
||
<td>`Ops Agent` 发现问题后先提交修复建议，由主 Agent 审批；审批通过后执行修复，再由 `Ops Audit Agent` 复验并回报主 Agent。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>主 Agent 失联</td>
|
||
<td>`Ops Audit Agent` 确认主控失联并升级到 `Chief Ops Audit Agent`；运维审计层做最终修复执行判断，`Ops Agent` 执行修复，运维审计层复验并写入账本，待主控恢复后同步。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>5. 当运维层自身挂了，但主 Agent 在线</h3>
|
||
<ul class="list">
|
||
<li>如果 `Ops Control Plane`、`Ops Ledger`、`Ops Connector Runtime` 或大面积 `Local Ops Agent / Ops Audit Agent` 自身出问题，主 Agent 必须切到 `ops_rescue_mode`。</li>
|
||
<li>进入该模式后，主 Agent 通过独立的最小救援通道直连节点或备用控制器，对运维层发起反向抢救。</li>
|
||
<li>反向抢救不能依赖已经损坏的运维控制面本身，必须保留保底通道，例如紧急 RPC、备用控制器、本地 Watchdog 接口或只读健康快照通道。</li>
|
||
<li>运维层恢复后，仍然要由 `Ops Audit Agent` 做复验，再把结果回报主 Agent。</li>
|
||
</ul>
|
||
|
||
<h3>6. 主控恢复后的回放要求</h3>
|
||
<ul class="list">
|
||
<li>主 Agent 恢复后必须收到：故障摘要、影响范围、已执行修复动作、复验结论、剩余风险、是否建议人工复盘。</li>
|
||
<li>若运维修复在主控离线时发生，系统必须自动补发一条“修复回放报告”到主会话和运维中心。</li>
|
||
<li>若是主 Agent 自己发起的运维层反向抢救，也必须写入同一套运维账本，避免形成黑盒修复。</li>
|
||
</ul>
|
||
|
||
<p class="footer-note">
|
||
详细协议文档见：<a href="ops_layer_and_repair_protocol_cn.md">ops_layer_and_repair_protocol_cn.md</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十二、容灾与故障恢复</h2>
|
||
<h3>1. 主控故障</h3>
|
||
<ul class="list">
|
||
<li>Master Agent 的任务状态和项目记忆不保存在上下文里，而是落在 Postgres、对象存储和向量记忆里。</li>
|
||
<li>启用 Standby Controller，持续订阅事件库和任务账本，主控故障后接管调度。</li>
|
||
<li>LangGraph 的 checkpoint 用于恢复到最近一次可执行状态。</li>
|
||
</ul>
|
||
|
||
<h3>2. 数据库故障</h3>
|
||
<ul class="list">
|
||
<li>Postgres 使用主从复制或云数据库高可用版本。</li>
|
||
<li>每天全量备份，按小时增量备份，保留至少 7 到 30 天。</li>
|
||
<li>事件日志追加写入对象存储，数据库损坏后仍可回放构建状态。</li>
|
||
</ul>
|
||
|
||
<h3>3. 单台 worker 故障</h3>
|
||
<ul class="list">
|
||
<li>worker 维持心跳，超过阈值则标记离线，并触发重新调度。</li>
|
||
<li>每个任务都绑定 branch / worktree，失败后可以迁移到其他节点继续执行。</li>
|
||
<li>Windows GPU 任务失败时，可降级转移到云 GPU 或改为排队等待恢复。</li>
|
||
</ul>
|
||
|
||
<h3>4. 账号或额度问题</h3>
|
||
<ul class="list">
|
||
<li>Quota Monitor 记录每个 ChatGPT / Codex 节点的可用额度与速率限制。</li>
|
||
<li>单个账号额度不足时，自动切换到其他 worker 节点执行。</li>
|
||
<li>主脑如使用 API，可与 worker 层的 Plus 账号使用路径解耦。</li>
|
||
</ul>
|
||
|
||
<h3>5. 网络故障</h3>
|
||
<ul class="list">
|
||
<li>局域网内的 Mac 和 Windows 节点优先直连云控制平面。</li>
|
||
<li>如家庭宽带不稳定，可在云端部署轻量 relay，worker 与 relay 保持长连接。</li>
|
||
<li>手机端通过 HTTPS + WebSocket 访问，断线重连后根据事件序号补拉缺失记录。</li>
|
||
</ul>
|
||
|
||
<h3>6. 人工接管</h3>
|
||
<ul class="list">
|
||
<li>手机端和 Web 控制台提供“暂停调度”“冻结项目”“人工审核后继续”的按钮。</li>
|
||
<li>任何时刻都可以把某个 worker thread 升级为人工接管模式。</li>
|
||
<li>系统要支持导出项目摘要、当前分支、最近命令、失败原因，便于人工介入。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十三、推荐的第一阶段落地方式</h2>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>阶段</th>
|
||
<th>目标</th>
|
||
<th>部署</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>V1</td>
|
||
<td>先跑通 1 个主控 + 2 台 Mac + 1 台 Windows + 1 台云 worker 的项目调度、线程查看，以及每节点最小运维 Agent / 运维审计 Agent 心跳与修复工单。</td>
|
||
<td>主控和数据库在云端，worker 在各自本机；所有节点同步部署 Local Ops Agent 与 Local Ops Audit Agent。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>V2</td>
|
||
<td>加入项目记忆、自动摘要、跨节点线程对话、规则审计、专项审计 Agent、限额调度、异常重派，以及主控离线下的运维紧急修复判定与复验。</td>
|
||
<td>新增向量库、线程 Broker、审计编排服务、Ops Control Plane、Chief Ops Audit Agent、备用控制器。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>V3</td>
|
||
<td>加入开放式硬件接管、跨项目调度、GPU 任务编排、拇指机器人和多模态完整测试链路，以及多节点联动自愈和策略化运维。</td>
|
||
<td>扩展云 worker、Windows GPU 服务、硬件测试台、合成探针与更细粒度 Runbook 策略。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十四、中文思维导图</h2>
|
||
<p class="lead">
|
||
下面这块是压缩后的方案总览，适合快速过一遍全局逻辑，也方便你后面拿去继续讨论产品边界和开发排期。
|
||
</p>
|
||
<div class="mindmap-shell">
|
||
<div class="mindmap-center">
|
||
<strong>Codex 多机协作产品</strong>
|
||
<span>一个主 Agent，对接多台电脑上的 Codex 线程</span>
|
||
</div>
|
||
<div class="mindmap-grid">
|
||
<div class="branch">
|
||
<div class="branch-title">产品目标</div>
|
||
<ul>
|
||
<li>手机端只保留一个主对话入口。</li>
|
||
<li>同时调度 Mac、Windows、云服务器上的 Codex。</li>
|
||
<li>每个项目可查看聊天记录、命令、补丁和状态。</li>
|
||
<li>通过多短线程和外部记忆解决长上下文退化。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="branch">
|
||
<div class="branch-title">核心技术</div>
|
||
<ul>
|
||
<li>LangGraph 作为主控编排引擎。</li>
|
||
<li>Codex app-server / SDK 作为 worker 接入层。</li>
|
||
<li>Project Memory 保存项目目标、约束、摘要和决策。</li>
|
||
<li>Event Store 镜像 thread、命令、patch、审批和告警。</li>
|
||
<li>Inter-Thread Broker 让 Mac / Windows / 云线程在监管下互相协作。</li>
|
||
<li>混合审计层可接管摄像头、音频和机器人外设做硬件测试。</li>
|
||
<li>运维层和运维审计层负责动态巡检、修复审批、复验和主控失联兜底。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="branch">
|
||
<div class="branch-title">部署位置</div>
|
||
<ul>
|
||
<li>云服务器运行主控、数据库、审计、实时推送。</li>
|
||
<li>每台 Mac 本机运行 Mac Worker Daemon。</li>
|
||
<li>Windows 通过 WSL2 运行 Worker，并桥接 GPU 能力。</li>
|
||
<li>云 worker 负责 CI、长任务、批处理和后台执行。</li>
|
||
<li>所有接入节点都必须常驻 Local Ops Agent 和 Local Ops Audit Agent。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="branch">
|
||
<div class="branch-title">容灾策略</div>
|
||
<ul>
|
||
<li>主控状态外置，Standby Controller 可接管。</li>
|
||
<li>Postgres 高可用，事件日志回写对象存储。</li>
|
||
<li>worker 心跳检测，故障后自动重派任务。</li>
|
||
<li>按节点监控 Codex 额度，账号异常时自动切换。</li>
|
||
<li>主控失联时由运维审计层做紧急修复判断，恢复后自动回放修复报告。</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十五、开发规格文档入口</h2>
|
||
<p class="lead">
|
||
下面这份文档已经单独整理成可直接开发的协议规格，建议后续数据库、API、消息总线、前端联调都以它为准，不再从正文里反复抽取定义。
|
||
</p>
|
||
|
||
<div class="grid">
|
||
<div class="card span-8 soft">
|
||
<div class="tag status-ok">主规格</div>
|
||
<strong>Capability Registry 与审计 Agent 协议开发规格</strong>
|
||
<ul class="list">
|
||
<li>定义能力提供方、能力实例、租约、会话、证据的核心实体。</li>
|
||
<li>定义摄像头、麦克风、扬声器、串口、拇指机器人、继电器、电源、屏幕采集等能力类型。</li>
|
||
<li>定义注册、心跳、租约、续租、释放、抢占和事件流。</li>
|
||
<li>定义软件审计、硬件审计、多模态审计、总审计的输入输出协议。</li>
|
||
<li>包含最小数据库表建议和 MVP 演进路径。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-8 soft">
|
||
<div class="tag status-ok">开发拆解</div>
|
||
<strong>开发子任务与交付计划</strong>
|
||
<ul class="list">
|
||
<li>把余下设计工作拆成 `A ~ H` 共 8 个工作包。</li>
|
||
<li>覆盖数据库、API、状态机、设备端预部署、前端字段、安全边界、演练与验收。</li>
|
||
<li>每个子任务都带目标、输出、依赖、优先级和验收标准。</li>
|
||
<li>明确哪些内容必须先冻结，哪些内容可以并行开发。</li>
|
||
<li>适合作为接下来正式开工的总任务入口。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-8 soft">
|
||
<div class="tag status-ok">UI 参考</div>
|
||
<strong>中国区产品 UI 参考库</strong>
|
||
<ul class="list">
|
||
<li>按“单入口、项目页、设备页、运维页、硬件页、AI 助手页”拆分参考对象。</li>
|
||
<li>覆盖飞书、钉钉、企业微信、向日葵、ToDesk、腾讯云助手、阿里云 App、观测云、PingCode、TAPD、米家、腾讯元宝等。</li>
|
||
<li>每个参考对象都标出：为什么适合参考、最值得借的 UI 点、官方来源。</li>
|
||
<li>适合直接作为后续产品原型和设计稿的输入清单。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-8 soft">
|
||
<div class="tag status-ok">首页冻结</div>
|
||
<strong>微信式项目会话首页映射规格</strong>
|
||
<ul class="list">
|
||
<li>把第一屏冻结成“主 Agent 置顶 + 项目会话列表”的微信式结构。</li>
|
||
<li>定义项目会话如何和设备端 GUI 项目文件夹一一对应。</li>
|
||
<li>定义单设备头像、群聊式组合头像、最近消息排序和手动置顶规则。</li>
|
||
<li>定义首页最小字段、建议新增的数据对象和前端展示边界。</li>
|
||
<li>适合作为首页和会话列表开发的直接规格。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-8 soft">
|
||
<div class="tag status-ok">上下文预算</div>
|
||
<strong>线程上下文预算与压缩前接力协议</strong>
|
||
<ul class="list">
|
||
<li>冻结设备端线程上下文预算的上报字段、阈值、事件和 handoff 包。</li>
|
||
<li>定义首页圆环进度标记、项目详情页展开和 BFF 返回结构。</li>
|
||
<li>明确主 Agent 在 `safe / watch / urgent / critical` 四个等级下的默认动作。</li>
|
||
<li>把“压缩前收尾”提升成正式调度规则，而不是临时经验。</li>
|
||
</ul>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag">文档路径</div>
|
||
<p class="lead">
|
||
Markdown 规格文档：
|
||
<br />
|
||
<a href="capability_registry_and_audit_protocol_cn.md">capability_registry_and_audit_protocol_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
运维规格文档：
|
||
<br />
|
||
<a href="ops_layer_and_repair_protocol_cn.md">ops_layer_and_repair_protocol_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
技术选型文档：
|
||
<br />
|
||
<a href="detailed_technical_stack_cn.md">detailed_technical_stack_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
开发子任务文档：
|
||
<br />
|
||
<a href="development_subtasks_and_delivery_plan_cn.md">development_subtasks_and_delivery_plan_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
中国区 UI 参考库：
|
||
<br />
|
||
<a href="china_ui_reference_apps_cn.md">china_ui_reference_apps_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
微信式会话首页规格：
|
||
<br />
|
||
<a href="wechat_project_conversation_mapping_cn.md">wechat_project_conversation_mapping_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
上下文预算规格：
|
||
<br />
|
||
<a href="thread_context_budget_and_handoff_protocol_cn.md">thread_context_budget_and_handoff_protocol_cn.md</a>
|
||
</p>
|
||
<p class="lead">
|
||
本机绝对路径：
|
||
<br />
|
||
<code>/Users/kris/code/Talking/capability_registry_and_audit_protocol_cn.md</code>
|
||
</p>
|
||
<p class="lead">
|
||
<code>/Users/kris/code/Talking/ops_layer_and_repair_protocol_cn.md</code>
|
||
</p>
|
||
<p class="lead">
|
||
<code>/Users/kris/code/Talking/thread_context_budget_and_handoff_protocol_cn.md</code>
|
||
</p>
|
||
<p class="lead">
|
||
<code>/Users/kris/code/Talking/detailed_technical_stack_cn.md</code>
|
||
</p>
|
||
<p class="lead">
|
||
<code>/Users/kris/code/Talking/development_subtasks_and_delivery_plan_cn.md</code>
|
||
</p>
|
||
<p class="lead">
|
||
<code>/Users/kris/code/Talking/china_ui_reference_apps_cn.md</code>
|
||
</p>
|
||
<p class="lead">
|
||
<code>/Users/kris/code/Talking/wechat_project_conversation_mapping_cn.md</code>
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<h3>建议的直接开发顺序</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>顺序</th>
|
||
<th>先做什么</th>
|
||
<th>原因</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>1</td>
|
||
<td>建 `capability_providers` / `capabilities` / `capability_leases` / `audit_requests` 等基础表</td>
|
||
<td>先把注册、租约、任务账本落库，后续协议才有稳定主键和状态流。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>2</td>
|
||
<td>做 Capability Gateway 的注册、心跳、租约接口</td>
|
||
<td>这是摄像头、串口、机器人接入和后续抢占的最小闭环。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>3</td>
|
||
<td>做 Audit Orchestrator 和三类专项审计任务协议</td>
|
||
<td>先打通任务下发和结构化结果回收，后面再接真实模型与硬件。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>4</td>
|
||
<td>接 Evidence Collector 和对象存储</td>
|
||
<td>没有证据归档，多模态和硬件审计无法复盘。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>5</td>
|
||
<td>接前端项目页的能力占用、审计结果、抢占事件展示</td>
|
||
<td>这样手机端和 Web 控制台才能真正看到系统状态，不只是跑后台逻辑。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十六、当前流程思维导图图片版</h2>
|
||
<p class="lead">
|
||
这张图把当前已经确定下来的主流程、执行层、审计层、能力层和容灾层压成一张图，适合直接对着讨论开发边界和服务拆分。
|
||
</p>
|
||
<img class="illustration" src="current_flow_mindmap_cn.svg" alt="Codex 多机协作当前流程思维导图" />
|
||
<p class="footer-note">
|
||
图片文件：
|
||
<a href="current_flow_mindmap_cn.svg">current_flow_mindmap_cn.svg</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十七、业务流程思维导图图片版</h2>
|
||
<p class="lead">
|
||
这张图专门从业务推进角度整理，从你发起项目、主控拆任务、多机开发、审计复核、硬件测试到结果交付和异常恢复，每个环节都标了使用的关键技术。
|
||
</p>
|
||
<img class="illustration" src="business_flow_mindmap_cn.svg" alt="Codex 多机协作业务流程思维导图" />
|
||
<p class="footer-note">
|
||
图片文件：
|
||
<a href="business_flow_mindmap_cn.svg">business_flow_mindmap_cn.svg</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十八、业务流程泳道图图片版</h2>
|
||
<p class="lead">
|
||
如果你想更直观看“谁在什么时候做什么”，就看这张泳道图。它现在把用户、主 Agent、Worker、审计层、硬件能力层、运维层 / 运维审计层、数据与容灾层拆成 7 条泳道，并标出了关键技术、开放式运维接入和反向抢救切换点。
|
||
</p>
|
||
<img class="illustration" src="business_flow_swimlane_cn.svg" alt="Codex 多机协作业务流程泳道图" />
|
||
<p class="footer-note">
|
||
图片文件：
|
||
<a href="business_flow_swimlane_cn.svg">business_flow_swimlane_cn.svg</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>十九、运维与抢修泳道图图片版</h2>
|
||
<p class="lead">
|
||
这张图专门把运维层和运维审计层拆开，展示动态巡检、日志命名、主控在线审批、主控离线紧急接管、修复复验和主控恢复回放的完整闭环。
|
||
</p>
|
||
<img class="illustration" src="ops_repair_swimlane_cn.svg" alt="运维层与运维审计层抢修流程泳道图" />
|
||
<p class="footer-note">
|
||
图片文件：
|
||
<a href="ops_repair_swimlane_cn.svg">ops_repair_swimlane_cn.svg</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十、详细技术栈建议</h2>
|
||
<p class="lead">
|
||
下面这版是“可以直接开工”的技术选型，不再停留在抽象架构层，重点回答：用什么语言、什么数据库、什么消息总线、什么向量库、什么对象存储、什么观测体系。
|
||
</p>
|
||
|
||
<div class="grid">
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">前端</div>
|
||
<strong>TypeScript + Next.js 15 + React 19</strong>
|
||
<p class="lead">
|
||
先做 PWA / Web 控制台，再视情况封装原生 App。这样手机端和管理后台可以共用一套组件和状态流。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">云端控制平面</div>
|
||
<strong>Python 3.12 + FastAPI + LangGraph</strong>
|
||
<p class="lead">
|
||
主控编排、审计编排、运维编排、Capability Registry、Thread Registry 都建议统一到 Python 栈。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">Worker / Agent / Gateway</div>
|
||
<strong>Python 3.12</strong>
|
||
<p class="lead">
|
||
因为需要深度对接 Codex app-server / SDK、串口、音视频、硬件测试和多模态审计，Python 最顺手。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>层</th>
|
||
<th>推荐选型</th>
|
||
<th>理由</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>主数据库</td>
|
||
<td>`PostgreSQL 16`</td>
|
||
<td>项目、任务、线程、审计、Capability、运维工单都能统一管理，事务和 JSONB 足够稳。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>向量库</td>
|
||
<td>`pgvector` 起步，后期再考虑 `Qdrant`</td>
|
||
<td>MVP 阶段最简单，和主库同备份；规模上来后再拆独立向量库。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>缓存 / 锁</td>
|
||
<td>极轻云默认先不用，后续按需补 `Redis 7`</td>
|
||
<td>MVP 先用 Postgres 行锁和应用内 TTL cache 顶住，放大后再补 Redis。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>事件总线</td>
|
||
<td>极轻云默认 `Postgres job table + LISTEN/NOTIFY`，后续可升级 `NATS JetStream`</td>
|
||
<td>先保住功能，不先引入额外常驻服务；等并发和消息量上来再升级。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>对象存储</td>
|
||
<td>极轻云默认本机短期缓存 + 异步备份，后续可接 `S3 / MinIO`</td>
|
||
<td>云端不常驻对象存储服务，原始大证据尽量留在边缘节点。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>监控指标</td>
|
||
<td>极轻云默认健康探针 + 结构化指标表，后续可接 `Prometheus + Grafana`</td>
|
||
<td>先保住健康检查和关键指标，不先上重型观测栈。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>日志检索</td>
|
||
<td>MVP 用 `Postgres + JSON 日志`，中期补 `ClickHouse`</td>
|
||
<td>先快落地，后面再把高吞吐 fault_key 检索单独拆出。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>跨设备运维的具体落地</h3>
|
||
<ul class="list">
|
||
<li>极轻云默认建议统一走：`Ops Control Plane -> Postgres job queue + LISTEN/NOTIFY -> target Local Ops Agent -> Ops Audit Agent -> Ops Ledger`。</li>
|
||
<li>首批支持的远程运维动作：`remote_exec`、`remote_restart_service`、`remote_fetch_logs`、`remote_collect_snapshot`、`remote_push_config`、`remote_switch_account`、`remote_run_runbook`。</li>
|
||
<li>首批连接器类型：`ssh`、`http_api`、`windows_service`、`docker`、`lan_rpc`。</li>
|
||
</ul>
|
||
|
||
<p class="footer-note">
|
||
详细选型文档见：<a href="detailed_technical_stack_cn.md">detailed_technical_stack_cn.md</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十一、极限轻云方案（同时考虑容灾）</h2>
|
||
<p class="lead">
|
||
这里不是因为服务器小才降配，而是无论云服务器配置如何，都主动把云端压缩到最轻；同时保留双云容灾，但让备云只承担接管准备，不承担常态重负载。
|
||
</p>
|
||
|
||
<div class="grid">
|
||
<div class="card span-4">
|
||
<div class="tag status-ok">保留</div>
|
||
<strong>云端只保留控制面核心</strong>
|
||
<p class="lead">
|
||
建议保留 `FastAPI BFF + Master Agent + Audit Orchestrator + Ops Control Plane + PostgreSQL + pgvector`，其余尽量不常驻。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-warn">降配</div>
|
||
<strong>去掉额外常驻中间件</strong>
|
||
<p class="lead">
|
||
默认先不单独上 `Redis`、`NATS`、`Qdrant`、`ClickHouse`、`MinIO`，优先用单体服务 + Postgres 顶住。
|
||
</p>
|
||
</div>
|
||
<div class="card span-4">
|
||
<div class="tag status-danger">下沉</div>
|
||
<strong>把重活前移到终端</strong>
|
||
<p class="lead">
|
||
视频流、音频流、OCR、检测、串口长采集都放到 Mac / Windows / Test Rig 节点先做边缘处理，只上传摘要、关键帧和异常片段。
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<h3>最值得做的减法</h3>
|
||
<ul class="list">
|
||
<li>把控制平面做成 Python 单体，而不是多微服务。</li>
|
||
<li>把事件总线从 `NATS JetStream` 降到 `Postgres job table + LISTEN/NOTIFY`。</li>
|
||
<li>先不用 `Redis`，用 Postgres 行锁和应用内 TTL cache 替代。</li>
|
||
<li>先不用独立向量库，只保留 `pgvector`。</li>
|
||
<li>聊天发送走 HTTP，状态更新优先 `SSE`，不要一开始把所有实时能力都堆到 WebSocket 上。</li>
|
||
<li>审计 Agent 改成按需触发，不常驻。</li>
|
||
<li>运维层做成“轻控制面 + 重边缘执行”，跨设备运维动作由目标节点本地 Ops Agent 执行。</li>
|
||
</ul>
|
||
|
||
<h3>双云容灾下怎么做轻量化</h3>
|
||
<ul class="list">
|
||
<li>`Cloud A`：主用，只跑控制面单体和 PostgreSQL 主库。</li>
|
||
<li>`Cloud B`：热备 / 温备，只跑备用控制面单体、PostgreSQL 备库、关键快照和接管脚本。</li>
|
||
<li>目标不是让两台云都跑得很重，而是“主云承担业务，备云保持可接管”。</li>
|
||
</ul>
|
||
|
||
<h3>不建议放在云端长期常驻的</h3>
|
||
<ul class="list">
|
||
<li>持续视频流接入与转码</li>
|
||
<li>长时间音频流处理</li>
|
||
<li>大规模日志全文索引</li>
|
||
<li>独立向量数据库集群</li>
|
||
<li>全套 Prometheus + Grafana + Loki + ClickHouse 观测平台</li>
|
||
</ul>
|
||
|
||
<h3>这套极轻云方案能保住什么</h3>
|
||
<ul class="list">
|
||
<li>单主 Agent 入口</li>
|
||
<li>多机 Worker 调度</li>
|
||
<li>线程镜像和聊天记录查看</li>
|
||
<li>基础跨节点线程对话</li>
|
||
<li>按需审计</li>
|
||
<li>基础运维修复与主控失联应急链路</li>
|
||
</ul>
|
||
|
||
<p class="footer-note">
|
||
详细极轻云方案见：<a href="detailed_technical_stack_cn.md">detailed_technical_stack_cn.md</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十二、矛盾点与取舍矩阵</h2>
|
||
<p class="lead">
|
||
这里不是继续堆技术，而是明确说明：在“云端尽可能轻”和“原有业务能力不能砍”之间，哪些可以换实现位置，哪些是唯一真正的硬矛盾。
|
||
</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>矛盾点</th>
|
||
<th>推荐取舍</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>手机端要随时看项目进度，但云端又要极轻</td>
|
||
<td>保留文本线程、状态、摘要、故障、修复结果实时上云；原始视频、音频、大日志改为按需回传，不持续上传。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>要多机实时协作，但不想跑重消息系统</td>
|
||
<td>保留跨节点协作能力，把 `NATS` 降成 `Postgres job queue + LISTEN/NOTIFY`；功能不砍，但吞吐上限降低。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>要主控层、审计层、运维层都在，但云内存很小</td>
|
||
<td>保留逻辑角色，不保留多常驻进程；改成单体服务里的模块 + 按需执行器。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>要跨设备运维，还要开放式主运维层</td>
|
||
<td>云端只做编排和审批，具体修复动作下沉到目标节点的 `Local Ops Agent` 本地执行。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>要多模态、硬件测试，但云带宽和云成本都要压低</td>
|
||
<td>保留测试闭环，放弃原始流持续上云；边缘先做裁剪、摘要、关键帧、短片段。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>既要云端尽可能轻，又要云端容灾</td>
|
||
<td>保留双云，但让 `Cloud B` 只做热备 / 温备，不承担常态重负载。主云承担业务，备云承担接管准备。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>最终建议</h3>
|
||
<ul class="list">
|
||
<li>不砍功能边界，只改变物理部署位置。</li>
|
||
<li>云端只保留“系统真相”和“调度真相”。</li>
|
||
<li>重执行、重媒体、重测试、重运维动作全部边缘化。</li>
|
||
<li>证据上传分冷热两层：热数据立即上云，冷数据按需回传。</li>
|
||
</ul>
|
||
|
||
<p class="footer-note">
|
||
更完整的分析见：<a href="detailed_technical_stack_cn.md">detailed_technical_stack_cn.md</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十三、极限轻云双云部署拓扑图图片版</h2>
|
||
<p class="lead">
|
||
这张图把最终确定下来的部署原则画成了可落地的拓扑：`Cloud A` 只承担主用控制面和主库，`Cloud B`
|
||
只承担热备 / 温备和接管准备，所有重执行、重媒体、重测试、重运维动作全部下沉到设备端。
|
||
</p>
|
||
|
||
<img class="illustration" src="ultra_light_dual_cloud_topology_cn.svg" alt="极限轻云双云部署拓扑图" />
|
||
|
||
<ul class="list">
|
||
<li>`Cloud A`：控制面单体、主 Agent 编排逻辑、PostgreSQL 主库、pgvector、HTTP + SSE。</li>
|
||
<li>`Cloud B`：备用控制面单体、PostgreSQL 备库、接管脚本、快照和恢复钩子。</li>
|
||
<li>设备端：Codex Worker、审计执行器、Test Rig、跨设备运维动作、本地证据缓存。</li>
|
||
<li>默认不在云端常驻：`Redis`、`NATS`、独立对象存储、重媒体处理、重审计池。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十四、双云最低配置速览</h2>
|
||
<p class="lead">
|
||
在“云端尽可能轻”且“不能明显降低稳定性和业务保障能力”的前提下，我建议按下面这个下限准备两台云服务器。
|
||
</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>角色</th>
|
||
<th>硬最低可跑</th>
|
||
<th>推荐最低要求</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>`Cloud A`（主用）</td>
|
||
<td>`2 vCPU / 4 GB / 80 GB SSD`</td>
|
||
<td>`2 vCPU / 8 GB / 100 GB SSD`</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`Cloud B`（备用）</td>
|
||
<td>`2 vCPU / 4 GB / 80 GB SSD`</td>
|
||
<td>`2 vCPU / 8 GB / 100 GB SSD`</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<ul class="list">
|
||
<li>“硬最低可跑”更适合 PoC 或超低并发试运行，不建议拿它做业务保障下限。</li>
|
||
<li>真正推荐的最低要求是：`Cloud A = 2C8G / 100GB SSD`，`Cloud B = 2C8G / 100GB SSD`。</li>
|
||
<li>如果你们保留较多审计截图、短视频片段、修复证据和数据库 WAL，磁盘建议直接上到 `150 GB`。</li>
|
||
<li>带宽重点看稳定性，最低建议 `5 Mbps`，更稳建议 `10 Mbps` 以上。</li>
|
||
</ul>
|
||
|
||
<p class="footer-note">
|
||
更完整的最小配置解释见：<a href="detailed_technical_stack_cn.md">detailed_technical_stack_cn.md</a>
|
||
</p>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十五、两种保活模式</h2>
|
||
<p class="lead">
|
||
系统从设计上同时支持两种备用接管路径：`单云 + 单 Mac 备用控制器`，以及 `双云热备 / 温备`。部署时可以二选一，也可以同时启用。
|
||
</p>
|
||
|
||
<img class="illustration" src="ha_modes_cn.svg" alt="两种保活模式对比图" />
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>模式</th>
|
||
<th>组成</th>
|
||
<th>优点</th>
|
||
<th>边界</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>`单云 + 单 Mac 备用控制器`</td>
|
||
<td>`Cloud A` + 一台常开 `Standby Mac`</td>
|
||
<td>更省云成本，本地接管更快，适合已有常开 Mac mini 的环境。</td>
|
||
<td>如果主云和现场 Mac 同时断电或断网，这条链路也会失效。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>`双云热备 / 温备`</td>
|
||
<td>`Cloud A` + `Cloud B`</td>
|
||
<td>公网可达性更稳，不依赖现场某一台设备，接管路径更标准化。</td>
|
||
<td>成本更高；最后一跳的硬件接管仍要依赖现场设备在线。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>模式 A：单云 + 设备端备用池（首选单 Mac）</h3>
|
||
<ul class="list">
|
||
<li>`Cloud A` 跑控制面单体和 PostgreSQL 主库。</li>
|
||
<li>默认首选一台 `Standby Mac`，但系统同时维护 `standby_device_pool`，允许其他接入设备自动成为后备容灾设备。</li>
|
||
<li>当前活动备用设备运行备用控制面轻实例、`Standby Controller`、`Ops Rescue Gateway`，以及备库或快照恢复实例。</li>
|
||
<li>手机 App 必须支持主 / 备 endpoint 列表切换。</li>
|
||
<li>必须准备一条不依赖主云的可达路径，例如同局域网、`Tailscale / WireGuard` 或长期反向隧道。</li>
|
||
<li>`Standby Mac` 最低建议：`M1` 或同级 4 核、`8 GB RAM`、`50 GB` 可用 SSD；更稳建议 `16 GB RAM / 100 GB SSD`。</li>
|
||
</ul>
|
||
|
||
<h3>模式 B：双云热备 / 温备</h3>
|
||
<ul class="list">
|
||
<li>`Cloud A` 跑主用控制面和 PostgreSQL 主库。</li>
|
||
<li>`Cloud B` 只跑备用控制面、PostgreSQL 备库、接管脚本和恢复钩子。</li>
|
||
<li>推荐最低要求：`Cloud A = 2C8G / 100GB SSD`，`Cloud B = 2C8G / 100GB SSD`。</li>
|
||
<li>目标不是让两台云都很重，而是“主云承载业务，备云保持可接管”。</li>
|
||
</ul>
|
||
|
||
<h3>统一抽象</h3>
|
||
<ul class="list">
|
||
<li>开发时统一抽象成 `standby_provider`。</li>
|
||
<li>部署时可选：`standby_mac`、`cloud_b`、`both`。</li>
|
||
<li>这意味着同一套代码可以跑成：`Cloud A + Standby Mac`、`Cloud A + Cloud B`、或 `Cloud A + Cloud B + Standby Mac`。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十六、还能不能继续压缩云服务器</h2>
|
||
<p class="lead">
|
||
可以，但要分清楚“功能还能跑”和“稳定性与业务保障能力不明显下降”不是一回事。这里把可继续压缩的边界和不能继续下沉的系统真相拆开。
|
||
</p>
|
||
|
||
<h3>先给结论</h3>
|
||
<ul class="list">
|
||
<li>`2C8G / 100GB` 不是系统绝对最小，而是“双云容灾下，不明显降低稳定性和业务保障能力”的最低要求。</li>
|
||
<li>如果切到 `单云 + 设备端备用池`，并把更多执行、审计、媒体处理下沉到本地，云端可以继续压到 `2C4G / 80GB`。</li>
|
||
<li>`1C2G ~ 1C4G` 只适合实验性极限压缩，不建议作为正式业务下限。</li>
|
||
</ul>
|
||
|
||
<h3>哪些能力还能继续下沉到设备端</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>能力</th>
|
||
<th>继续压云的做法</th>
|
||
<th>云端仍需保留的真相</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Embedding 生成</td>
|
||
<td>在 worker / audit 节点本地生成 embedding，再写回云端。</td>
|
||
<td>向量、chunk 元数据、项目记忆索引。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>长日志处理</td>
|
||
<td>本地先裁剪、归类 fault_key、保留最后 N 行再上传。</td>
|
||
<td>fault ledger、工单、修复记录。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>视频 / 音频处理</td>
|
||
<td>本地做关键帧、短片段、OCR、检测，只传证据摘要。</td>
|
||
<td>证据索引、审计结论、回放引用。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>审计执行</td>
|
||
<td>尽量在拥有能力的节点本地跑专项审计。</td>
|
||
<td>审计工单、复验结论、风险等级。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Test Rig 控制</td>
|
||
<td>摄像头、串口、机器人、麦克风、扬声器一律本地网关执行。</td>
|
||
<td>租约、抢占真相、任务结论。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>运维修复动作</td>
|
||
<td>重启、拉日志、切账号、跑 runbook 都在目标节点本地执行。</td>
|
||
<td>审批、修复工单、复验结果。</td>
|
||
</tr>
|
||
<tr>
|
||
<td>额度轮询</td>
|
||
<td>每台机器本地采集 Codex 额度，再定时回报精简状态。</td>
|
||
<td>统一额度看板、切换历史。</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>哪些东西不能继续往本地下沉</h3>
|
||
<ul class="list">
|
||
<li>项目 / 任务 / 线程账本。</li>
|
||
<li>审计结论与修复结论。</li>
|
||
<li>`standby_provider` 和 `standby_device_pool` 状态。</li>
|
||
<li>主备 endpoint 注册表。</li>
|
||
<li>审批结果与权限真相。</li>
|
||
</ul>
|
||
|
||
<h3>单服务器 + 设备端保活时，设备端掉线怎么办</h3>
|
||
<ul class="list">
|
||
<li>不能只做一个固定 `Standby Mac`，必须做成 `standby_device_pool`。</li>
|
||
<li>每台设备声明自己是否可作为容灾设备，并上报常开状态、内存、磁盘、网络可达性和 `takeover package` 版本。</li>
|
||
<li>控制面为前 `N` 个候选设备同步最小接管包。</li>
|
||
<li>当前活动备用设备心跳丢失后，系统自动提升下一台候选设备为新的 `active_standby_device`。</li>
|
||
<li>手机 App、Worker、运维层都读取最新的主 / 备 endpoint 清单。</li>
|
||
</ul>
|
||
|
||
<h3>这个切换会不会很慢</h3>
|
||
<ul class="list">
|
||
<li>如果备用设备是“冷备”，也就是平时没预部署接管组件，那你的理解是对的：切换会慢，而且容易出问题，因为它等于要临时重新部署一套设备端业务代码。</li>
|
||
<li>所以自动切换不能基于冷备，必须基于 `warm standby` 或 `hot standby`。</li>
|
||
<li>`warm standby`：设备已预部署 `Standby Controller / Local Ops Agent / Local Ops Audit Agent / Ops Rescue Gateway`，并已同步最近的 `takeover package`。</li>
|
||
<li>`hot standby`：在温备基础上做更高频状态同步，切换更快，但会多占一点本地资源。</li>
|
||
<li>目标时间建议：冷备 `3~10 分钟`，温备 `15~60 秒`，热备 `5~15 秒`。</li>
|
||
</ul>
|
||
</section>
|
||
|
||
<section class="section">
|
||
<h2>二十七、API-first / Local-first 极限压缩模式</h2>
|
||
<p class="lead">
|
||
可以把云端进一步压轻。思路不是把业务砍掉，而是把“云端常驻重服务”改成“外部 API 调用 + 设备端本地执行”，让云端只做最小控制面和最小系统真相。
|
||
</p>
|
||
|
||
<h3>这套模式的核心原则</h3>
|
||
<ul class="list">
|
||
<li>能通过外部 API 调的，不在你的云端常驻算力。</li>
|
||
<li>能在本地设备完成的，不回云端执行。</li>
|
||
<li>云端只保留：`API Gateway / BFF`、`Master Agent Runtime`、`PostgreSQL`、最小 `pgvector`、endpoint 注册表、`standby_device_pool`、审批/审计/修复账本。</li>
|
||
</ul>
|
||
|
||
<h3>哪些业务适合 API 化</h3>
|
||
<ul class="list">
|
||
<li>模型推理：直接调用 OpenAI 或其他模型 API，不在你的云端常驻推理服务。</li>
|
||
<li>OCR / 检测：优先本地执行，不够时再走外部 API。</li>
|
||
<li>文件 / 对象存储：优先本地或 NAS，云端只保留 manifest 和索引。</li>
|
||
</ul>
|
||
|
||
<h3>哪些业务更适合本地化</h3>
|
||
<ul class="list">
|
||
<li>embedding 生成</li>
|
||
<li>长日志裁剪</li>
|
||
<li>视频 / 音频预处理</li>
|
||
<li>专项审计执行</li>
|
||
<li>Test Rig 控制</li>
|
||
<li>运维修复动作</li>
|
||
<li>gptpluscontrol 本地额度采集</li>
|
||
</ul>
|
||
|
||
<h3>这条线下的起步配置</h3>
|
||
<ul class="list">
|
||
<li>如果并发设备 `<= 3`，而且采用 `单云 + standby_device_pool + API-first + local-first`，起步云配置可以认真尝试 `2C4G / 80GB SSD`。</li>
|
||
<li>`1C2G ~ 1C4G` 只建议当实验环境，不建议直接作为正式起步线。</li>
|
||
</ul>
|
||
|
||
<h3>按设备数和任务数弹性升级</h3>
|
||
<ul class="list">
|
||
<li>起步档：`1 个 Cloud A + standby_device_pool`，并发设备 `<= 3`，建议 `2C4G / 80GB SSD`。</li>
|
||
<li>如果同时接入设备数 `> 3`、活跃线程数 `> 10`、专项审计 / 硬件测试并发 `> 2`，就建议升到 `2C8G / 100GB` 或补上 `Cloud B`。</li>
|
||
<li>只有在再往上走时，才考虑依次增加 `Redis`、`NATS JetStream`、独立对象存储、独立向量库。</li>
|
||
</ul>
|
||
</section>
|
||
</div>
|
||
</body>
|
||
</html>
|