bookworm-smart-assistant/docs/AI-Universal-Control-Plane-WhitePaper-v1.4.md
Bookworm Admin b7a8e29d21 release: v6.7.0 - OTA E2E test release
- VERSION file as authoritative version source
- export.mjs reads VERSION with package.json fallback
- bw-ota.ps1 DryRun mode for safe testing
- auto-setup.ps1 bumped to v3.2.0 (Phase 8 OTA)
2026-04-27 17:59:44 +08:00

40 KiB
Raw Permalink Blame History

AI Universal Control Plane

架构白皮书 v1.4 (诚实化收官版)

v1.3 → v1.4 不引入新机制, 专门收口"自审盲区": 班次/时区/仪式视频/ROI/延迟预算/程序化 enforce

字段 内容
版本 v1.4
日期 2026-04-25
状态 Phase 1 候选基线 — 待第三方红队复审
父版本 v1.3 (终审 ≈79.6-83.2, 未达 B+)
修订原则 诚实化: 不再自评通胀, 不再用工程完成度替代市场验证
目标评分 ≥ 86 (B+) — 经第三方独立审定后正式接受
工作量诚实化 v1.3 500 → v1.4 560 人日 (+60, 含 ISV/双 bump/异构裁判/AGV/OSSD 等真实工程量)

0. v1.3 → v1.4 修订摘要

三专家共识必修 (5 项, 阻塞 B+)

ID 缺口 修订章节
H1 双裁判 approve/分歧阈值反激励 §1 交叉锁定
H2 异构裁判仅文档约束, 无程序 enforce §2 family 字典 + CI/启动期硬阻断
H3 班次定义 + 时区显式 (4 版连续未补) §3 受签 shifts.yaml + IANA tz
H4 wall clock 墓碑死锁 (未来时戳无上限) §4 双向时戳健全性检查
H5 不可逆 + HARD 抢占语义冲突 §5 带外硬件急停 + 低风险写豁免

CTO 设计冲突 (3 项)

ID 缺口 修订章节
C1 ND1 双裁判延迟 P95 易破 3s (无延迟预算) §6 延迟预算分解
C2 ND2 周期重验证 100 设备 RPC 风暴 §7 token bucket + jittered batch
C3 cap.range 除零 + 反向编码静默绕过 §8 边界守卫

市场/合规缺口 (4 项)

ID 缺口 修订章节
M1 双裁判 + 双 bump ROI 模型黑洞 §9 真实成本模型 (含 PoC 实测留位)
M2 等保 2.0 实质条款映射 (附录 F 占位) §10 三列映射表 (条款→技术控制→证据)
M3 边缘 AI Phase 归属 + MCP 弱网降级 §11
M4 离线 HSM 仪式视频留证 + ISV 返点访谈 §12

算法 + 红队遗留 (3 项)

ID 缺口 修订章节
A1 UUIDv7 多大脑节点全局单调 §13 distributed seq
A2 boot_epoch SPI flash 物理拆读重放 §14 ATECC608 隔离
A3 安全预算"永不 deny" 反成 DoS §15 oncall 疲劳防护

v1.4 共修 15 项, 不引入新机制, 不再自评通胀


1. 双裁判共识阈值交叉锁定 (H1)

1.1 v1.3 漏洞

# v1.3 §1.4 反激励设计
if abs(result_a.risk_score - result_b.risk_score) > 0.4:
    raise SafetyDivergence(...)
# 攻击者: A=0.5 (approve), B=0.89 (approve, 分差 0.39<0.4) → 通过
# 同流合污比打架更安全

1.2 v1.4 修订

# brain/safety/judge_consensus.py
HARD_ACTION_REQUIREMENTS = {
    'max_individual_risk': 0.30,      # 任一裁判 risk≥0.3 即否决
    'max_score_divergence': 0.20,     # 两者分差>0.2 视为可疑
    'min_approve_count': 2,           # 必须双 approve
}

async def hard_action_consensus(intent, plan):
    result_a, result_b = await asyncio.gather(
        judge_a.review(intent, plan),
        judge_b.review(intent, plan),
    )
    
    # 强约束 1: 双 approve
    if not (result_a.approve and result_b.approve):
        raise SafetyVeto('judge_disagree', a=result_a, b=result_b)
    
    # 强约束 2: 双低风险 (任一裁判 ≥0.3 即否)
    if max(result_a.risk_score, result_b.risk_score) >= 0.30:
        raise SafetyVeto('risk_too_high', a=result_a, b=result_b)
    
    # 强约束 3: 分歧检测 (>0.2 可疑, 触发第三裁判仲裁)
    if abs(result_a.risk_score - result_b.risk_score) > 0.20:
        result_c = await judge_c.review(intent, plan)   # 第三异构裁判
        if not result_c.approve or result_c.risk_score >= 0.30:
            raise SafetyVeto('tiebreaker_rejected', c=result_c)
    
    return ConsensusOk(scores=[result_a, result_b])

1.3 防御博弈分析

攻击者策略 v1.3 行为 v1.4 行为
A=0.5, B=0.89 (双 approve, 分差 0.39) 通过 A 已 ≥0.3 否决
A=0.29, B=0.29 (双 approve, 一致投毒) 通过 ⚠️ 通过, 但有第三裁判机会 (若 A/B 同源, 异构强制可避免)
A=0.10, B=0.31 (单裁判被攻陷) ⚠️ 接近边缘 B ≥0.3 否决
A=0.10, B=0.50 (一裁判明显异常) 分差超阈 B ≥0.3 + 分差>0.2 双否

2. 异构裁判程序化强制 (H2)

2.1 模型家族字典

# llm-family-registry.yaml (受 security-key 签名, ops 不可改)
schema_version: "2026.04"

families:
  qwen:
    members: [qwen3-max, qwen3-max-thinking, qwen2.5-72b, qwen3-235b-a22b, qwen3-vl, qwq-32b]
    vendor: alibaba
    architecture: transformer_moe
    pretrain_data: alibaba_cn_corpus_v3
  
  glm:
    members: [glm-4.6, glm-4-air, glm-zero-air, glm-4-9b]
    vendor: zhipu
    architecture: transformer_dense
    pretrain_data: zhipu_corpus_v2
  
  deepseek:
    members: [deepseek-chat, deepseek-reasoner, deepseek-v3.1, deepseek-r1, deepseek-v2]
    vendor: deepseek
    architecture: transformer_mla_moe   # MLA 注意力
    pretrain_data: deepseek_corpus_v3
  
  llama:
    members: [llama-4-maverick, llama-4-scout, llama-3.3-70b]
    vendor: meta
    architecture: transformer_dense
    pretrain_data: llama_pretrain_v4
  
  claude:
    members: [claude-opus-4-7, claude-sonnet-4-6]
    vendor: anthropic
    architecture: transformer_proprietary
    pretrain_data: anthropic_corpus
  
  # ... 其他家族

# 异构性硬约束: 必须满足以下三项
heterogeneity_rules:
  - rule: different_family
    desc: 家族 ID 必须不同
    enforce: hard_block_on_startup
  
  - rule: different_vendor
    desc: 厂商不同 (防同公司多模型同源)
    enforce: hard_block_on_startup
  
  - rule: different_architecture_or_pretrain
    desc: 架构或预训练数据至少一项不同
    enforce: hard_block_on_startup

2.2 启动期硬阻断

# brain/safety/judge_validator.py
def validate_judge_heterogeneity(primary_id, judge_a_id, judge_b_id):
    registry = load_signed('llm-family-registry.yaml')
    
    primary_family = registry.lookup(primary_id)
    judge_a_family = registry.lookup(judge_a_id)
    judge_b_family = registry.lookup(judge_b_id)
    
    if not primary_family or not judge_a_family or not judge_b_family:
        # 未登记的模型, 拒绝启动
        raise UnknownLLMFamily(f'{primary_id}/{judge_a_id}/{judge_b_id}')
    
    for rule in registry.heterogeneity_rules:
        for pair in [(primary_family, judge_a_family),
                     (primary_family, judge_b_family),
                     (judge_a_family, judge_b_family)]:
            if not rule.check(*pair):
                # 大脑拒绝启动 + Audit + 通知 csso
                raise HeterogeneityViolation(
                    rule=rule.rule,
                    pair=(pair[0].family, pair[1].family),
                    enforce='hard_block_on_startup'
                )

2.3 CI 静态检查

# .github/workflows/judge-config-validate.yml
- name: Validate judge config heterogeneity
  run: |
    python tools/judge-config-validator.py \
      --primary $(yq .primary llm-router.yaml) \
      --judges "$(yq '.judge_pool[].id' llm-router.yaml)" \
      --family-registry llm-family-registry.yaml
    if [ $? -ne 0 ]; then
      echo "BLOCKED: judge config violates heterogeneity rules"
      exit 1
    fi    

PR merge 前必跑, 失败阻断。

2.4 防御对策

攻击者尝试 v1.3 v1.4
配置 judge_a=qwen3-max, judge_b=qwen3-max-thinking ⚠️ 文档禁止但无 enforce 启动失败: same family qwen
配置 judge_a=qwen3-max, judge_b=qwen3-vl ⚠️ 看似异构 same vendor alibaba
配置主+judge=qwen+glm (合规) 通过 通过
主+judge=qwen+deepseek (推荐配对) 通过 通过 (MLA vs MoE 架构异构)

3. 班次 + 时区显式化 (H3, 4 版连续未补)

3.1 受签班次定义

# shifts.yaml (受 ops-key 签名)
schema_version: "2026.04"
default_timezone: Asia/Shanghai

# 工厂班次定义 (覆盖 cold start / 业务时间策略 / 跨夜 / DST)
shifts:
  - id: morning
    label: 早班
    start: "06:00"
    end: "14:00"
    timezone: Asia/Shanghai
    weekdays: [MON, TUE, WED, THU, FRI, SAT]
  
  - id: afternoon
    label: 中班
    start: "14:00"
    end: "22:00"
    timezone: Asia/Shanghai
    weekdays: [MON, TUE, WED, THU, FRI, SAT]
  
  - id: night
    label: 夜班
    start: "22:00"
    end: "06:00"           # 跨日, 系统识别 end<start 为跨夜
    timezone: Asia/Shanghai
    weekdays: [MON, TUE, WED, THU, FRI]
  
  - id: maintenance_window
    label: 维护窗口
    start: "08:00"
    end: "12:00"
    timezone: Asia/Shanghai
    weekdays: [SUN]
    capability_blacklist: ['*']    # 维护窗口禁止任何 AI 写入

dst_handling:
  policy: respect_iana            # 严格按 IANA 时区数据库, 自动应对 DST
  shift_anchor: start_time         # 跨 DST 日按"开始时刻"判断, 23h/25h 是物理事实

3.2 cold start 班次判定

# brain/timeseries/cold_start.py
def has_full_shift(series, shifts_config):
    """检测序列是否覆盖至少一个完整班次"""
    if not series:
        return False
    
    # 用事件实际跨度判断, 不依赖班次 label
    span_seconds = (series[-1].ts - series[0].ts).total_seconds()
    
    # 至少 8 小时事件跨度 (典型班次最短) + 样本密度足够
    if span_seconds < 8 * 3600:
        return False
    
    # 样本密度: 至少 1000 个有效样本
    valid = [s for s in series if not (math.isnan(s.value) or math.isinf(s.value))]
    if len(valid) < 1000:
        return False
    
    # 时区跨夜处理: 用 UTC 内部存储, 显示时按 shifts_config.default_timezone
    # 跨 DST 日: 23h 也算"完整班次"(物理事实优先 vs 标签长度)
    return True

3.3 时区错配防护

启动期检测:

def validate_timezone_consistency():
    sys_tz = time.tzname                              # OS 时区
    shifts_tz = shifts_config.default_timezone        # 配置时区
    plc_tz = registry.get_plc_timezone()              # PLC 报告时区 (如有)
    
    if sys_tz != shifts_tz:
        warn(f'OS timezone {sys_tz} != shifts default {shifts_tz}')
    
    if plc_tz and plc_tz != shifts_tz:
        warn(f'PLC timezone {plc_tz} != shifts default {shifts_tz}')
    
    # 强制内部用 UTC, 显示层转换
    set_internal_clock_to_utc()

4. wall clock 墓碑死锁防护 (H4)

4.1 v1.3 漏洞

# v1.3 §2.2: last_wall_ms 因之前 NTP 异常写入"未来 10min"
# cur < last - 5min 永远成立 → 永久无法启动

4.2 v1.4 双向健全性检查

# brain/saga/clock_v2.py
class HybridClockV2:
    MAX_PAST_TOLERANCE_MS = 5 * 60 * 1000     # 容忍过去 5min
    MAX_FUTURE_TOLERANCE_MS = 1 * 60 * 1000   # 容忍未来 1min
    NTP_HEALTH_CHECK_TIMEOUT_S = 10
    
    def open(self):
        last_wall_ms = self.db.get_last_saga_wall_ts()
        cur_wall_ms = HybridClock.wall_now_ms()
        
        # 检查 1: NTP 健康 (启动期强制)
        if not self._ntp_healthy():
            raise NTPUnhealthy('启动期 NTP 不可达, 拒绝启动')
        
        delta_ms = cur_wall_ms - last_wall_ms
        
        # 检查 2: 过去回拨
        if delta_ms < -self.MAX_PAST_TOLERANCE_MS:
            raise ClockSkewBackward(f'wall clock backward {-delta_ms/1000:.1f}s')
        
        # 检查 3: 未来时戳 (墓碑死锁防护)
        if delta_ms < -self.MAX_FUTURE_TOLERANCE_MS - self.MAX_PAST_TOLERANCE_MS:
            # last_wall_ms 显著大于现在 = 墓碑值
            # 触发管理员介入流程
            raise TombstoneDetected(
                last=last_wall_ms,
                cur=cur_wall_ms,
                hint='last_wall_ms 像是写自未来, 可能 NTP 历史异常. 需 ops 手工 reset'
            )
        
        # 正常路径
        self._proc_start_mono = HybridClock.monotonic_ms()
    
    def _ntp_healthy(self) -> bool:
        """与配置的 NTP 服务器对比, 偏差 < 1s 视为健康"""
        try:
            ntp_now = ntp_client.query(timeout=self.NTP_HEALTH_CHECK_TIMEOUT_S)
            local_now = time.time()
            return abs(ntp_now - local_now) < 1.0
        except Exception:
            return False

4.3 ops 手工 reset 流程

# ops 工具
$ brain-saga-tool reset-tombstone --confirm
WARN: 即将重置 last_wall_ts. 当前持久化值: 2026-05-15T10:00:00Z (未来)
WARN: 当前 wall clock: 2026-04-25T22:30:00Z
WARN: 这通常意味着 NTP 异常导致写入了未来时戳.
WARN: reset 前必须验证: (1) NTP 已修复 (2) 没有未完成的 saga
请输入 "I_CONFIRM_TOMBSTONE_RESET" 确认: I_CONFIRM_TOMBSTONE_RESET
✅ tombstone reset, 大脑可启动

5. 不可逆 + HARD 抢占语义冲突解决 (H5)

5.1 v1.3 冲突

§6.2 不可逆动作 acquire_exclusive_lock 持有期间, §11 HARD_ACTION 抢占无法中断 → 安全 PLC 50ms 看门狗 vs VRRP 100ms 切备 → 设计上不可共存。

5.2 v1.4 解法: 急停带外硬件回路

[软件层 (大脑 + Edge Gateway + MCP)]
   ↑
   只跑 HARD_ACTION 的"决策评估" (双裁判共识 + 审批)
   ↑
   不参与急停的物理执行
   
[带外硬件回路] (与软件解耦)
   ┌──────────────┐
   │ 物理急停按钮  │ → 安全 PLC SIL3 → 切断主电源
   └──────────────┘
   ┌──────────────┐
   │ AI 软急停请求 │ → 通知人工 → 人工按物理按钮
   └──────────────┘
   
   关键: AI 永远只能"建议急停", 不能"执行急停"

5.3 不可逆 SOFT_PARAM 豁免通道

# irreversible-actions-v2.yaml
irreversible_actions:
  - capability_pattern: "agv.*move"
    reason: AGV 已搬运
    saga_compensation: forward_only_with_human_review
    
    # v1.4 新增: 低风险写豁免
    low_risk_exemption:
      enabled: true
      conditions:
        - distance_meters: { op: "<=", value: 50 }       # 短距离调度
        - within_known_route: true                       # 已知路径
        - hour_of_day: { in: [9,10,11,14,15,16] }        # 业务时间
      effect: skip_dual_confirm                          # 跳过双确认, 但仍走 Saga forward_only
      audit: required                                    # 审计照常

5.4 抢占语义重写

# brain/scheduler/preemption_v2.py
class PreemptionPolicy:
    def can_preempt(self, holder_task, requester_task):
        # 不可逆 SOFT_PARAM 持有锁时, HARD_ACTION 不抢占, 走带外
        if holder_task.is_irreversible():
            if requester_task.safety_level == 'HARD_ACTION':
                # AI 不抢, 通知人工
                self.notify_human_for_physical_estop(requester_task)
                return False    # 不抢占
        
        # 可逆操作可被抢占
        return True

6. 延迟预算分解 (C1)

6.1 端到端延迟目标

路径 P50 P95 P99 备注
READ_ONLY (单设备) 200ms 500ms 1s Tool RTT 主导
SOFT_PARAM (单设备) 800ms 2s 4s 含主 LLM 推理
HARD_ACTION (含双裁判) 1.5s 3s 5s 含主 LLM + 双裁判共识 + 用户确认
带外物理急停 < 50ms < 50ms < 50ms 硬件回路, AI 不在路径

6.2 HARD_ACTION 延迟分解

[用户请求] 0ms
   ↓
[意图解析 + 设备路由] 50-100ms
   ↓
[主 LLM 推理 (Qwen3-Max)] 600-1500ms
   ↓
[Policy Engine 评估] 10-30ms
   ↓
[双裁判并发推理 (asyncio.gather)] 600-1500ms ← 不串联
   ↓ 任一拒绝立即返回
[用户 dual-confirm UI] 5-30s ← 不计入软件延迟
   ↓ 用户确认后
[物理钥匙心跳验证] 10ms
   ↓
[MCP 调用 → Gateway → PLC] 100-500ms (含 bump-in-wire DPI)
   ↓
[结果聚合 + Audit Log] 50-100ms
   ↓
[返回] = 1.5-3.5s (不含用户确认时间)

6.3 性能优化措施

# 措施 1: 主 LLM 与裁判 LLM 并行 (在主推理同时启动裁判预热)
async def hard_action_pipeline(intent):
    # 主 LLM 流式输出, 边生成边送入裁判
    primary_stream = primary_llm.stream(intent)
    
    plan_partial = ""
    judge_tasks = []
    
    async for chunk in primary_stream:
        plan_partial += chunk
        # 累计到关键决策点时, 启动裁判 (不等主 LLM 完成)
        if reached_decision_checkpoint(plan_partial):
            judge_tasks.append(asyncio.create_task(
                judge_a.review_partial(plan_partial)
            ))
            judge_tasks.append(asyncio.create_task(
                judge_b.review_partial(plan_partial)
            ))
            break    # 主 LLM 仍在跑, 裁判已并行启动
    
    # 主 + 双裁判同时进行
    plan_full, judge_a_result, judge_b_result = await asyncio.gather(
        primary_stream.collect(),
        *judge_tasks
    )
    # 节省 ~30% 端到端延迟

# 措施 2: 裁判 LLM 本地化 (Qwen3-235B + DeepSeek-R1, 本地 GPU)
# 推理延迟 200-500ms vs 云端 800-1500ms

# 措施 3: HARD_ACTION 场景预热裁判 LLM (kept-warm pool)

6.4 SLA 与告警

# performance-sla.yaml
hard_action:
  p50_target_ms: 1500
  p95_target_ms: 3000
  p99_target_ms: 5000
  alert_on_breach:
    - p95_breach_count_in_5min > 3 → page oncall
    - p99 > 8s → SLO violation, 通知 csso

read_only:
  p95_target_ms: 500
  
soft_param:
  p95_target_ms: 2000

7. 周期重验证速率限制 (C2)

# brain/registry/periodic_validator_v2.py
import asyncio
from collections import deque
import random

class TokenBucket:
    def __init__(self, rate_per_sec, burst):
        self.rate = rate_per_sec
        self.tokens = burst
        self.max_tokens = burst
        self.last_refill = time.monotonic()
    
    async def acquire(self):
        while self.tokens < 1:
            await asyncio.sleep(0.05)
            self._refill()
        self.tokens -= 1
    
    def _refill(self):
        now = time.monotonic()
        delta = now - self.last_refill
        self.tokens = min(self.max_tokens, self.tokens + delta * self.rate)
        self.last_refill = now

async def periodic_revalidate_v2(registry):
    """100 设备 24h 全量重验, 速率限制 + jitter, 防 RPC 风暴"""
    
    bucket = TokenBucket(rate_per_sec=2, burst=10)    # 平均 2 RPS, 峰值 10
    
    capabilities = list(registry.all_capabilities())
    random.shuffle(capabilities)    # 打乱避免设备级集中
    
    for cap in capabilities:
        await bucket.acquire()
        
        # 抖动: 每个调用前随机延迟 0-500ms
        await asyncio.sleep(random.uniform(0, 0.5))
        
        try:
            actual = await mcp_client.introspect(cap.address, cap.protocol)
            handle_drift(cap, actual)
        except DeviceMaintenanceWindow:
            cap.last_verify_skip_reason = 'maintenance'   # 不标 unreachable
        except CapabilityVerificationError as e:
            cap.mark_unreachable(reason=str(e))
    
    # 100 设备 × 平均 5 capability = 500 调用, 2 RPS → 250s = 4 min
    # 比 v1.3 同步 RPC 风暴 (秒级数千 RPC) 安全得多

7.2 维护窗口豁免

# devices.yaml 扩展
- id: prod-line-12-plc
  maintenance_windows:
    - cron: "0 8-12 * * 0"           # 周日 8-12 点
      timezone: Asia/Shanghai
      action_during: skip_periodic_validation

8. cap.range 边界守卫 (C3)

# brain/policy/range_validator.py
def compute_ratio_safe(actual, cap_range, capability_id):
    """安全计算 actual_ratio, 防除零 + 反向编码"""
    lo, hi = cap_range
    
    # 检查 1: range 退化 (单点校准 / enum)
    if lo == hi:
        raise InvalidRangeError(
            f'{capability_id}: range={lo}=={hi}, '
            f'cannot compute ratio. 应使用 enum 类型而非 ratio'
        )
    
    # 检查 2: 反向编码
    if lo > hi:
        # 显式声明的反向 (如真空泵 "压力越低速度越高")
        if not registry.is_inverse_encoded(capability_id):
            raise InverseEncodingNotDeclared(
                f'{capability_id}: range={lo}>{hi} but not declared inverse. '
                f'若是真实反向编码, 需在 Registry 设 inverse_encoded: true'
            )
        # 反向计算
        return (hi - actual) / (hi - lo)
    
    # 正常路径
    return (actual - lo) / (hi - lo)

8.2 Registry 反向编码声明

- id: vacuum_pump_speed_via_pressure
  type: read
  protocol: opc-ua
  address: ns=2;s=DB10.PressureFromPump
  datatype: float
  range: [10, 0.001]                # 看似反向: 0.001 是高速对应的低压
  inverse_encoded: true              # 显式声明
  inverse_reason: |
    真空泵转速越高, 出口压力越低 (物理倒置).
    应用层应理解为"压力 0.001 mbar 对应 100% 速度".    

CI 静态检查: 任何 range[0] > range[1] 必须有 inverse_encoded: true, 否则阻 merge。


9. ROI 真实成本模型 (M1)

9.1 中型工厂 30 设备 ROI 模型 (含 v1.3 累积成本)

一次性成本

项目 单价 数量 小计 (CNY)
中央服务器 (大脑主+备 HA) ¥10k 2 ¥20k
本地 GPU 服务器 (跑 Qwen3-235B + DeepSeek-R1 双裁判) ¥80k 1 ¥80k
Edge Gateway 工业网关 ¥4k 6 (每车间) ¥24k
bump-in-wire 双冗余 (轻量档可单 bump 减半) ¥4k 12 (双) or 6 (单) ¥48k / ¥24k
TPM 模块 (LetsTrust + ATECC608) ¥300 30 ¥9k
物理钥匙开关 + OSSD 双通道 ¥800 30 ¥24k
安全 PLC SIL3 (现有工厂复用) ¥0 ¥0
Headscale + DERP 服务器 (北京+广州 4c8g 各 1 台) ¥6k/年×2 2 ¥12k/年 (运营成本)
软件 License (¥800/设备/年 起) ¥800 30 ¥24k/年
系统集成实施费 (60-120 人日 × ¥1500/人日) ¥1500 90 ¥135k
一次性总额 ¥340-365k

月度运行成本

项目 估算
LLM API (国内主, Qwen-Max + GLM-4.6) ¥3-8k/月
LLM API (本地裁判 + GPU 电费) ¥800-1500/月 (电+维护)
Headscale + DERP 服务器 ¥1k/月
维护人工 (0.5-1 人日/月 × ¥1500) ¥1.5-3k/月
月度总额 ¥6-13k

年度成本汇总

档位 一次性 年运行 12 月总
轻量 (单 bump, 主 LLM 国内云, 无本地 GPU) ¥260k ¥48-90k ¥308-350k
标准 (双 bump + 本地 GPU + 双裁判) ¥365k ¥72-156k ¥437-521k
高合规 (M-of-N HSM + 数据二极管 + 仪式视频) ¥600k+ ¥150k+ ¥750k+

9.2 ROI 收益估算 (中型工厂, 标准档)

收益项 估算
操作员工时节省 (50% 重复任务自动化, 8 操作员 × 工时 × ¥80/h) ¥80-120k/年
故障 MTTR 30→8min (年减少停机损失) ¥150-300k/年 (取决于产线产值)
巡检自动化 (替代 1-2 个全职巡检员) ¥100-150k/年
数据驱动质量提升 (废品率降 1-2%) ¥50-150k/年
年收益 ¥380-720k

9.3 ROI 周期

档位 12 月成本 12 月收益 ROI 周期
轻量 ¥308-350k ¥380-720k 8-11 月
标准 ¥437-521k ¥380-720k 9-16 月
高合规 ¥750k+ ¥600-1000k+ (大型工厂规模收益) 12-18 月

9.4 PoC 实测留位 (诚实化关键)

⚠️ 以上数字是模型估算, Phase 0 PoC 必须实测以下数据并回填:

  1. 实际 LLM API 月账单 (主 + 双裁判)
  2. 单 bump 与双 bump 实际部署成本对比
  3. 实际故障 MTTR 改善 (PoC 前后 4 周对比)
  4. 操作员实际节省工时 (调研问卷 + 时间日志)
  5. 至少 2 家目标客户 ROI 反馈访谈

PoC 数据回填后形成 v1.4.1 实测版 ROI 模型, 销售材料以实测为准, 严禁使用本节估算数字直接对客户承诺。


10. 等保 2.0 实质条款映射 (M2)

10.1 三列映射表 (核心节选)

等保 2.0 条款 (GB/T 22239-2019) 本架构技术控制 证据 (审计可查)
8.1.4.1 b) 应对登录的用户进行身份鉴别, 身份标识具有唯一性 mTLS 双向证书 + Tailscale ACL + 大脑 brain-runtime-key (24h 短期证书) mTLS handshake 日志 + Tailscale audit log
8.1.4.1 c) 应启用登录失败处理功能, 配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施 Edge Agent 5 次 mTLS 失败锁 IP 30min + session 24h 强制超时 Edge Agent local audit log
8.1.4.1 d) 当进行远程管理时, 应采取必要措施防止鉴别信息在网络传输过程中被窃听 全程 TLS 1.3 + Tailscale WireGuard + bump-in-wire (国产 PLC 兜底) Wireshark 抓包验证
8.1.4.2 a) 应对登录的用户分配账户和权限 Policy Engine 角色矩阵 (operator/engineer/supervisor/admin) policies.yaml + audit log
8.1.4.2 c) 应授予管理用户所需的最小权限, 实现管理用户的权限分离 各 Edge Agent 仅持本机能力 + Gateway HSM 凭证按设备隔离 + ISV Skill capability_whitelist 白名单 Registry capabilities + sandbox config
8.1.4.3 a) 应启用安全审计功能, 审计覆盖到每个用户, 对重要的用户行为和重要安全事件进行审计 Audit Log Merkle chain + RFC 3161 + WORM 存储 audit.jsonl + anchor 时间戳
8.1.4.3 c) 应对审计记录进行保护, 定期备份, 避免受到未预期的删除、修改或覆盖等 链式 hash + WORM 对象存储 (MinIO immutable) + 异地备份 hash chain 验证脚本
8.1.4.3 d) 审计记录的留存时间符合法律法规要求 三档分级: 轻量 6 月 / 标准 1 年 / 高合规 5 年 retention policy yaml
8.1.4.5 a) 应在网络边界、重要网络节点进行安全审计 Edge Gateway DPI 全量记录 + bump-in-wire 流量审计 bump-in-wire DPI log
8.1.4.6 a) 应能发现可能存在的已知漏洞 CI 跑 npm/pip audit + cosign 验签 + SBOM CI artifacts
8.1.4.7 a) 应采用密码技术保证通信过程中数据的完整性 TLS 1.3 + 大脑签名 challenge + Audit Merkle chain Crypto config
8.1.4.7 b) 应采用密码技术保证通信过程中数据的保密性 TLS 1.3 + DERP padding 防侧信道 同上
8.1.4.10 a) 应保证操作系统和数据库系统用户的标识具有唯一性 brain-runtime-key 唯一 + Edge Agent 唯一 ID + ISV isv-key-* 命名空间 PKI 注册表
8.1.4.10 d) 应限制默认账户的访问权限 二进制 cosign 签名 + 启动期校验 + 默认拒绝 (default_action: DENY) policies.yaml

10.2 证据收集自动化

# evidence-collector.yaml
collectors:
  - id: mtls-handshake-evidence
    source: edge-agent.audit_log
    filter: event_type=mtls_handshake
    output: /evidence/mtls/{date}.jsonl
    retention: 5y
  
  - id: audit-merkle-chain-anchor
    source: brain.audit_log
    schedule: hourly
    output: /evidence/anchor/{hour}.json
    sign: rfc3161
  
  # ... 共 30 个收集器

等保测评时, 测评机构按"条款 → 证据路径"清单一一核对, 无需现场临时整理。

10.3 涉密 / CIIA 客户增项

附录 G 单独列出涉密系统 BMB 认证 + CIIA 关基设施认定的额外要求 (本主文档不展开, 涉密客户专项)。


11. 边缘 AI 路线 + MCP 弱网降级 (M3)

11.1 边缘 AI 推理路线图

Phase 边缘 AI 能力 目标
Phase 0-1 无边缘 AI, 全云端 验证整体架构, 网络稳定即可
Phase 2 (6 月起) 边缘规则引擎 (无 LLM, 纯 rule-based) 实时告警 < 100ms, 不依赖云端
Phase 2.5 (9 月起) 边缘小模型 (Qwen2.5-1.5B / GLM-4-Flash, ARM 边缘盒子) 本地分类/摘要, 实时性 < 500ms
Phase 3 (12 月+) 边缘中模型 (Qwen3-7B, NVIDIA Jetson Orin) 本地 RAG + 简单工具调用, 网络故障兜底

11.2 MCP 弱网降级策略

# mcp-degradation-policy.yaml
degradation_modes:
  network_healthy:
    description: 大脑 ↔ Edge Gateway 延迟 P95 < 100ms, 无丢包
    behavior: 全功能, 实时调用大脑 LLM
  
  network_degraded:
    description: 延迟 100ms-1s, 丢包率 1-5%
    behavior:
      - READ_ONLY: 缓存优先 (5min TTL)
      - SOFT_PARAM: 仍走大脑, 但增加超时 + 重试
      - HARD_ACTION: 降级人工 (大脑请求超时 → 通知 oncall)
  
  network_offline:
    description: 大脑不可达 > 30s
    behavior:
      - READ_ONLY: Edge Gateway 本地缓存
      - SOFT_PARAM: 降级到 Edge 边缘规则引擎 (Phase 2+) 或拒绝 (Phase 0-1)
      - HARD_ACTION: 完全拒绝, 必须等大脑恢复
      - 告警: 立即推送 oncall + 现场声光报警
  
  network_recovery:
    description: 大脑恢复后, Edge 同步缓存事件
    behavior: Saga 续跑 + 离线期事件重放上报

11.3 Edge 离线队列

# edge-gateway/offline_queue.py
class OfflineQueue:
    def __init__(self):
        self.queue = SQLiteQueue('/var/lib/bookworm/offline.db')
        self.max_size = 10000
    
    async def enqueue(self, event):
        if self.queue.size() >= self.max_size:
            # 队满, 按优先级丢弃 (READ_ONLY 先丢)
            self.queue.evict_lowest_priority()
        self.queue.put(event)
    
    async def replay_when_online(self):
        while not self.queue.empty():
            event = self.queue.peek()
            try:
                await brain_client.replay(event)
                self.queue.dequeue()
            except NetworkError:
                await asyncio.sleep(5)

12. 离线 HSM 仪式视频 + ISV 返点访谈 (M4)

12.1 仪式视频留证 (高合规档强制)

# hsm-ceremony-policy.yaml (受 security-key 签名)
ceremony_requirements:
  applicable_to: [high_compliance]
  
  participants:
    minimum_count: 2          # 双盲监督
    role_requirements:
      - role: signer_a
        idp: corporate_sso
        requires_2fa: true
        cannot_be_pr_submitter: true
      - role: signer_b
        idp: external_sso     # 不同 IdP
        requires_2fa: true
        cannot_be_pr_submitter: true
      - role: witness
        role: csso_or_legal   # 第三方监督
  
  physical_security:
    location: air_gapped_signing_room
    require_biometric_entry: true
    require_phone_locker: true       # 手机存柜
    require_signed_in_register: true
  
  recording:
    video_camera_count: 2            # 双视角
    audio_recording: true
    retention_days: 1825             # 5 年
    storage: WORM_blockchain_anchored
    encryption: AES-256-GCM
    tamper_detection: hourly_hash_chain
  
  procedure:
    step_1: 三人到场签到 + 身份核验 (生物识别)
    step_2: 入场前手机/电子设备锁柜
    step_3: 启动录像 + 时间戳 anchored
    step_4: 验证 PR + sig-1 + sig-2 + git_commit hash
    step_5: HSM 唤醒 (M-of-N) + 签名
    step_6: 输出 sig-final + version_proof + 离场
    step_7: 录像归档 + 三方签名"仪式确认书"
  
  audit:
    quarterly_review: true            # 季度法务/CSO 抽查
    anomaly_detection: 
      - signing_outside_business_hours
      - same_signer_consecutive
      - participant_substitution

12.2 ISV 返点访谈 (待 PoC 期间执行)

⚠️ 诚实声明: v1.3 的 ISV 返点 35-40% 是基于 SAP/用友等成熟平台对标, 未经国内中小工业集成商访谈验证

PoC 期间 (Phase 0 第 4-6 周) 执行 ISV 访谈:

# isv-survey-plan.yaml
target_count: 5-8 
target_profile:
  - 国内中型自动化集成商 (年营收 ¥1000-5000 万)
  - 已服务过 5+ 家中型工厂的成功案例
  - 覆盖至少 3 个不同地区 (长三角/珠三角/华北)

survey_questions:
  - 你目前与平台合作的常规返点比例是多少?
  - 35-40% 平台返点 + 10% 平台服务费, 你的实际净利空间能否覆盖人力成本?
  - 铂金级"5 个真实部署 + 工程师驻场"的门槛对你的公司是否合理?
  - 培训 3 天 + 认证考核, 你的工程师团队接受意愿如何?
  - 在你的客户场景中, 最看重平台提供的哪三项核心能力?
  - PMF 关键判据: 你愿意推荐至 2 个客户吗?

deliverable: ISV 访谈报告 (定性 + 量化, 反馈给 v1.4.1)

PoC 结束后, 基于真实访谈数据修订 §10 ISV 框架, 形成 v1.4.1。


13. UUIDv7 多实例全局单调 (A1)

# brain/saga/distributed_seq.py
import etcd3

class DistributedSequence:
    """多大脑节点的全局单调序号"""
    
    def __init__(self, etcd_endpoints):
        self.client = etcd3.client(host=etcd_endpoints)
        self.key = '/bookworm/saga/seq'
    
    async def next(self) -> int:
        """通过 etcd CAS 获取全局单调递增序号"""
        for attempt in range(10):
            cur = self.client.get(self.key)
            new_val = (int(cur[0]) if cur[0] else 0) + 1
            
            success, _ = self.client.transaction(
                compare=[
                    self.client.transactions.value(self.key) == cur[0]
                ],
                success=[
                    self.client.transactions.put(self.key, str(new_val))
                ],
                failure=[]
            )
            
            if success:
                return new_val
        
        raise DistributedSeqExhausted('etcd CAS retry exceeded 10x')

# Saga ID 组成: timestamp_ms + global_seq + node_id
def generate_saga_id():
    return f'{wall_now_ms()}-{distributed_seq.next()}-{node_id}'

14. ATECC608 隔离 boot_epoch (A2)

14.1 v1.3 漏洞

STM32 内置 flash 物理拆下可读, last_epoch + HMAC key 同位置即全暴露。

14.2 v1.4 修订

// 硬件分区:
// - HMAC key:    ATECC608 secure element (写入即不可读出)
// - boot_epoch:  ATECC608 monotonic counter (硬件保证单调, 不可重置)
// - 应用数据:    STM32 内置 flash (允许物理拆读, 不存任何敏感数据)

uint32_t get_boot_epoch_from_atecc608() {
    uint32_t counter_value;
    atcab_counter(ATCA_COUNTER_INC, COUNTER_ID_BOOT_EPOCH, &counter_value);
    // ATECC608 monotonic counter:
    // - 硬件保证只能 +1
    // - 物理拆下也无法读出 + 写入
    // - 容量 2,097,151 次 (足够 100 年/天 1 次重启)
    return counter_value;
}

14.3 ATECC608 容量诚实化

指标 ATECC608A 备注
Monotonic counter 容量 2,097,151 21 bit
100 年 × 365 天 = 36,500 重启 远小于容量 安全
但: 开发期看门狗高频重启 (每分钟 1 次, 1 年 = 525,600) 接近容量 开发模式应用专用 epoch sector, 不复用生产
预防: 生产固件烧写时 reset counter ID 定义生产/开发独立 counter 文档要求

15. 安全预算 oncall 疲劳防护 (A3)

15.1 v1.3 漏洞

safety_budget 永不 deny → 攻击者批量伪造 HARD_ACTION 耗尽预算 + jam GPU → oncall 疲劳放行。

15.2 v1.4 修订

# brain/safety/oncall_protection.py
class OnCallProtection:
    MAX_PAGES_PER_HOUR = 5           # 每小时最多 5 次告警
    SUSPICION_THRESHOLD = 10         # 1 小时内 >10 次 HARD 请求即视为可疑
    
    async def evaluate_hard_action_burst(self, requests):
        if len(requests) > self.SUSPICION_THRESHOLD:
            # 异常高频, 可能 DoS 攻击
            await self._alert_csso(
                'HARD_ACTION 请求高频异常', 
                request_count=len(requests),
                window='1h'
            )
            
            # 限流: 同一用户 1h 内 HARD 请求上限 5 次
            return self._apply_user_throttle(requests)
        
        return requests
    
    async def _alert_csso(self, *args, **kwargs):
        """CSO 直接告警, 绕过 oncall (oncall 已疲劳)"""
        await csso_pager.page(*args, **kwargs)
    
    def _check_oncall_fatigue(self, oncall_user):
        """oncall 1h 内被 page > 5 次, 视为疲劳, 自动切备班"""
        recent_pages = self.audit.count_pages_in_window(oncall_user, '1h')
        if recent_pages > self.MAX_PAGES_PER_HOUR:
            return self._switch_to_backup_oncall()

16. 工作量诚实化 (D3)

Phase v1.3 v1.4 (诚实化) 增量原因
Phase 0 PoC 60 人日 60 人日 不变
Phase 1 生产基础 160 人日 180 人日 +20 (异构裁判 enforce + 班次签名 + 仪式视频流程)
Phase 2 工业接入 280 人日 320 人日 +40 (3 家 AGV 厂商 MCP 接入 + 等保映射证据自动化 + 边缘规则引擎)
Phase 3 智能化 (累计) (累计) 不变
总工作量 500 560 +60 人日

诚实承认 v1.3 的"+40"低估。每个新增组件都是独立工程模块, 不是 stub。


17. 重新评分预期 (诚实化)

维度 v1.3 终审 v1.4 自评 (保守) v1.4 第三方实评预期
架构稳健性 83.2 88 86-88
市场可行性 79.6 84 82-85
算法稳健性 72.5 80 78-80
红队安全 83 86 85-87
综合 79.6 84.5 ≈ 83-85

v1.4 自评策略: 不再在每维度上加 5+ 分, 各维度增量保守在 3-5 分以内。

B+ (≥85) 达成条件:

  • 综合 ≥85 需四维全部 ≥83
  • v1.4 第三方实评预期 83-85, 处于 B+ 临界
  • 不保证达成, 但比 v1.3 的"自评 85, 实评 79.6"误差缩小到 1-2 分

18. 修订记录

版本 日期 主要变更 自评 第三方实评
v1.0 2026-04-25 初版 56.6
v1.1 2026-04-25 7 CRITICAL 修 + 国产 + 多 LLM 80 75
v1.1.1 2026-04-25 LLM 旗舰更新 80 76
v1.2 2026-04-25 全配置签名 + bump-in-wire + 裁判 LLM + ISV 85 79.5 (差距 5.5)
v1.3 2026-04-25 22 项收口 (异构裁判+时钟+强 schema+客群分级+...) 86 79.6 (差距 6.4)
v1.4 2026-04-25 15 项诚实化 (共识阈值交叉锁+异构 enforce+班次时区+墓碑防护+不可逆抢占+延迟预算+ROI 模型+等保映射+仪式视频+...) + 工作量+60 人日 84.5 预期 83-85

19. v1.0 → v1.4 自审改进记录

每次评审后, 自评 vs 实评的差距:

版本 自评 实评 差距 教训
v1.1 80 75 -5 工程未完成度低估
v1.2 85 79.5 -5.5 修复未全栈穿透 + 新机制带新债
v1.3 86 79.6 -6.4 用工程完成度替代市场验证 + 自审深度不足
v1.4 84.5 预期 83-85 -1~+0.5 诚实化, 不再在每维度加 5+ 分

v1.4 的核心改进不是修了多少漏洞, 而是自评校准:

  • 工作量诚实化: 460 → 500 → 560 人日
  • ROI 模型给出真实成本 + 留位 PoC 实测
  • 等保映射给出条款级证据路径
  • 仪式视频流程实质化
  • 不再在自评中虚报"+5 分增量"

20. 最终判定

v1.4 是 Phase 1 候选基线

条件批准 Phase 1:

  • 第三方独立红队复审通过 ≥85
  • Phase 0 PoC 实测数据回填 ROI 模型 (形成 v1.4.1)
  • ISV 访谈完成, 返点比例验证
  • 离线 HSM 仪式流程在试点工厂演练通过

Phase 0 PoC 立即启动:

  • 不依赖 v1.4 第三方复审通过 (v1.4 修复均为文档级 + 程序化 enforce, PoC 期间可并行验证)
  • PoC 期间收集 v1.4.1 所需实测数据
  • PoC 第 4 周触发 v1.4 第三方红队复审

给董事会的最终一句话

v1.0→v1.3 我们花 4 轮证明"修复 22 项漏洞", v1.4 我们做了第 5 件事: 诚实化。 不再用工程完成度替代市场验证, 不再在自评中虚报增量, 不再隐藏延迟预算与 ROI 黑洞。 综合自评从虚高的 86 降到诚实的 84.5, 第三方差距从 6.4 收敛到 1-2。 Phase 0 立即启动, Phase 1 等独立复审 + PoC 实测数据, 这才是真正的工程纪律。


v1.4 承诺: 这是 Phase 1 候选基线最终版。后续修订均基于 PoC 实测数据反哺, 不再靠纸面推演。