05元序运行时架构

元序 WorldScript 运行时架构

本文档定义元序解释器/运行时的内部架构，包括五大引擎的实现机制、Tick 调度器、内存模型、因果匹配算法与并发模型。
面向元序实现者与核心贡献者。

一、运行时总览

1.1 架构分层

┌─────────────────────────────────────────────────────────┐
│                   元序运行时 (WorldScript Runtime)        │
├─────────────────────────────────────────────────────────┤
│                                                           │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │
│  │  状态场引擎  │  │ 因果匹配引擎 │  │ 层级耦合引擎 │      │
│  │ StateField  │  │  Causality  │  │   Scale     │      │
│  │   Engine    │  │   Engine    │  │   Engine    │      │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘      │
│         │                │                │              │
│         └────────────────┼────────────────┘              │
│                          │                               │
│  ┌─────────────┐  ┌──────┴──────┐  ┌─────────────┐      │
│  │  偏差收敛引擎 │  │ Tick 调度器 │  │  演化引擎    │      │
│  │  Deviation  │  │  Scheduler  │  │  Evolution  │      │
│  │   Engine    │  │             │  │   Engine    │      │
│  └─────────────┘  └─────────────┘  └─────────────┘      │
│                                                           │
├─────────────────────────────────────────────────────────┤
│                    共享状态层 (Shared State)               │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│  │ 状态场存储 │ │ 规则注册表 │ │ 偏差流队列 │ │ 经验库    │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘   │
├─────────────────────────────────────────────────────────┤
│                    基础设施层 (Infrastructure)             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐   │
│  │ 时间轴队列 │ │ 事件总线  │ │ 配置中心  │ │ 持久化层  │   │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘   │
└─────────────────────────────────────────────────────────┘

1.2 设计原则

  1. 共享无锁状态：所有引擎读写同一份状态场，通过 Tick 级别的批量提交避免锁竞争
  2. 引擎间无直接调用：引擎通过共享状态与事件总线通信，不直接互相调用函数
  3. 确定性可回放：给定相同初始状态与外部输入序列，运行结果完全确定，支持回放调试
  4. 渐进式精度：因果匹配、趋势拟合等计算支持精度/性能权衡配置

1.3 语义边界：三层分离

元序明确区分三个层次，避免「语言语义」与「运行时策略」与「AI推断」混淆：

层次 性质 说明 可变性
L1 语言语义 确定的 语法、BNF、五种句式结构、状态场定义、因果规则结构、量纲系统 所有实现必须一致，变更需修订规范
L2 运行时策略 可配置的 因果权重分配、聚合方式、收敛策略、演化步长、偏差衰减率 有默认策略，允许显式覆盖，运行后可解释
L3 AI 推断 可选的 自动规则生成、自然语言转规则、智能参数推荐、异常根因分析 可选增强，不影响语言语义，可关闭

关键原则：所有「自动」均为「默认策略 + 可显式覆盖 + 运行后可解释」，而非黑箱决策。

机制 默认策略 可显式覆盖 可解释性
因果权重 合取条件平均分配 When 条件(权重=0.7) & 条件(权重=0.3) 条件贡献度分解
聚合方式 加权平均 Link 源 聚合→ 目标 方式=max 聚合计算过程
收敛策略 四级启发式（观察/局部/全局/保护） 偏差[D] 收敛策略=LocalAdjustment 偏差溯源+收敛轨迹
演化步长 εmax=0.05 Evolve 目标 步长=0.02 演化审计日志
偏差衰减 每Tick 5% 偏差[D] 衰减率=0.03 偏差强度历史

设计说明：Trae 评审指出「语义过宽」是元序最大风险——如果边界不收紧，同一段程序不同实现可能跑出完全不同结果。三层分离确保：L1 保证可移植性，L2 保证可控性，L3 保证可选性。用户永远知道哪些是语言保证的、哪些是运行时选择的、哪些是AI建议的。

二、Tick 调度器

2.1 职责

Tick 调度器是运行时的心脏，负责按固定顺序驱动八大阶段（详见《元序规则》第十章），并管理 Tick 间的状态提交。

2.2 Tick 生命周期状态机

     ┌──────────┐
     │  IDLE    │  等待启动信号
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_1 │  状态更新
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_2 │  因果匹配
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_3 │  涌现执行
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_4 │  层级耦合
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_5 │  趋势分析
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_6 │  偏差收敛
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_7 │  演化
     └────┬─────┘
          ▼
     ┌──────────┐
     │  PHASE_8 │  输出与持久化
     └────┬─────┘
          ▼
     ┌──────────┐
     │  COMMIT  │  原子提交本 Tick 所有状态变更
     └────┬─────┘
          ▼
     回到 PHASE_1（下一 Tick）

2.3 两阶段提交

每个 Tick 的状态变更采用两阶段提交：

  • 阶段 A（计算）：所有引擎读取当前状态场快照，计算变更，写入暂存区（Staging Area）
  • 阶段 B（提交）：调度器合并暂存区的所有变更（冲突消解），原子写入正式状态场

这保证了：同一 Tick 内所有引擎看到的是一致的状态快照，不会出现读到半更新状态的问题。

2.4 Tick 速率控制

  • 逻辑模式：Tick 尽可能快地执行（用于模拟/推演）
  • 实时模式：Tick 间隔绑定物理时间（1 Tick = 配置的物理时长），支持加速/减速/暂停
  • 步进模式：每个 Tick 等待外部确认后才继续（用于调试）

三、状态场引擎（StateField Engine）

3.1 职责

  • 维护所有状态场的当前值与历史值
  • 处理状态修改的平滑过渡（Δmax 约束）
  • 管理连续融合的计算
  • 提供状态查询接口

3.2 状态场存储结构

StateField {
    id: Identifier
    domain: Micro | Meso | Macro
    dimensions: Map<FieldName, DimensionState>
}

DimensionState {
    current: float          // 当前值 [0,1]
    previous: float         // 上一 Tick 值
    history: RingBuffer     // 最近 N 个 Tick 的历史（供 Track 使用）
    target: float?          // 渐变目标值（若有进行中的修改）
    transition_rate: float  // 每 Tick 变化速率
    source_links: List<LinkID>  // 指向本维度的聚合/约束链接
}

3.3 平滑过渡算法

当一个状态修改动作要求将维度 X 从当前值改为目标值 T 时：

每 Tick 实际变化量 = clamp(T - current, -Δmax, +Δmax)
current = current + 实际变化量
若 |current - T| < ε: 标记过渡完成

这保证了状态不会跳变，始终连续。

3.4 连续融合算法

连续融合(a↑, b↓, c↑) 的计算：

输入: 带方向标注的维度列表 [(v1, dir1), (v2, dir2), ...]
权重: 初始平均分配，经 Evolve 迭代修正

归一化每个维度: n_i = normalize(v_i)
方向应用: s_i = dir_i == UP ? n_i : (1 - n_i)
融合结果 = Σ(w_i × s_i) / Σ(w_i)

融合结果写入派生维度的 current，每 Tick 重新计算。

四、因果匹配引擎（Causality Engine）

4.1 职责

  • 每个 Tick 并行评估所有 When 规则
  • 计算每条规则的因果强度
  • 筛选并排序触发的规则
  • 管理延迟因果队列

4.2 规则注册表

RuleRegistry {
    rules: Map<RuleID, CompiledRule>
}

CompiledRule {
    id: RuleID
    conditions: List<Condition>        // 编译后的条件树
    weights: List<float>               // 各条件权重（和为1）
    threshold: float                   // 涌现阈值（默认0.6）
    actions: List<Action>              // 涌现时执行的动作
    triggered_count: int               // 历史触发次数
    last_triggered_tick: int?          // 上次触发 Tick
    effectiveness_score: float         // 历史有效度评分
}

4.3 条件满足度计算

对于比较条件 state OP value：

// 大于
satisfaction(state > threshold) =
    clamp((state - threshold) / reference_range, 0, 1)

// 小于
satisfaction(state < threshold) =
    clamp((threshold - state) / reference_range, 0, 1)

// 等于（连续接近度）
satisfaction(state == target) =
    1 / (1 + |state - target| / sensitivity)

// 区间隶属
satisfaction(state in [a, b]) =
    1 if a <= state <= b
    else exp(-|state - nearest_boundary| / decay)

reference_range 是该维度的典型波动范围，初始为 1.0，可由演化引擎根据历史数据修正。

4.4 因果强度计算

// 多条件叠加（& / 且）
causal_strength = Σ(w_i × satisfaction_i)

// 多条件或（或）
causal_strength = max(satisfaction_i)

// 非
causal_strength = 1 - satisfaction

当 causal_strength >= threshold 时，规则触发。

4.5 并行匹配策略

  • 所有规则的条件评估并行执行（可利用多线程/GPU）
  • 条件之间无依赖，可独立计算
  • 匹配结果按因果强度降序排列，存入触发队列
  • 同 Tick 内触发的规则全部执行，不因某条规则的执行而跳过其他规则

4.6 延迟因果队列

DelayQueue {
    entries: PriorityQueue<DelayEntry>  // 按到期 Tick 排序
}

DelayEntry {
    due_tick: int              // 到期 Tick
    due_tick_max: int?         // 若为区间延迟，最大到期 Tick
    action: Action             // 到期执行的动作
    intensity: float           // 强度系数
    source_rule: RuleID        // 来源规则
    cancellable: bool          // 是否可被其他规则取消
}

每个 Tick 开始时（PHASE_1），调度器检查到期的延迟条目并执行。区间延迟在 [due_tick, due_tick_max] 内随机选择一个 Tick 到期。

五、层级耦合引擎（Scale Engine）

5.1 职责

  • 维护微/中/宏三级域的拓扑关系
  • 执行微→中→宏的状态聚合
  • 执行宏→中→微的约束下发
  • 检测层级失配偏差

5.2 域拓扑

DomainGraph {
    micro_nodes: Map<NodeID, MicroNode>
    meso_nodes: Map<NodeID, MesoNode>
    macro_nodes: Map<NodeID, MacroNode>
    aggregation_links: List<AggregationLink>
    constraint_links: List<ConstraintLink>
}

AggregationLink {
    source: NodeID          // 低级域节点
    target: NodeID          // 高级域节点
    source_field: FieldName
    target_field: FieldName
    method: Sum | Avg | WeightedAvg | Density | Max | Custom
    weight: float           // 该源在聚合中的权重
}

ConstraintLink {
    source: NodeID          // 高级域节点
    target: NodeID          // 低级域节点
    source_field: FieldName
    target_field: FieldName
    strength: float         // 约束强度 [0,1]
    mode: Bias | Limit | Redirect
}

5.3 聚合算法

// 加权平均聚合（最常用）
target_value = Σ(weight_i × source_value_i) / Σ(weight_i)

// 求和聚合（如总车流量）
target_value = Σ(source_value_i)，然后归一化

// 密度聚合（如拥堵密度）
target_value = active_count / total_count

聚合结果写入目标维度的暂存区，经冲突消解后提交。

5.4 约束下发算法

约束不是强制赋值，而是改变低级维度的演化倾向：

// Bias 模式：偏移目标
target.transition_bias += (source_value - 0.5) × strength × 0.1

// Limit 模式：限制范围
target.allowed_range = intersect(
    target.allowed_range,
    [0.5 - source_value × 0.5, 0.5 + source_value × 0.5]
)

// Redirect 模式：重定向（如路径偏好）
target.preference_vector = normalize(
    target.preference_vector + source_vector × strength
)

5.5 层级失配检测

当聚合结果与宏观观测值偏差超过 15% 时，产生层级失配偏差：

mismatch = |aggregated_value - observed_value| / observed_value
if mismatch > 0.15:
    emit Deviation(type="层级失配", source=link_id, intensity=mismatch)

六、偏差收敛引擎（Deviation Engine）

6.1 职责

  • 维护活跃偏差流
  • 观测偏差强度变化
  • 选择并执行收敛策略
  • 记录已收敛偏差供演化学习

6.2 偏差流结构

DeviationFlow {
    active: Map<DeviationID, Deviation>
    history: RingBuffer<Deviation>   // 已收敛偏差的历史
    convergence_strategies: Map<DeviationType, Strategy>
}

Deviation {
    id: DeviationID
    type: string
    source: Reference
    level: Low | Medium | High | Critical
    intensity: float          // [0,1]
    spread_radius: float
    priority: Low | Medium | High | Critical
    status: Observing | Converging | Converged | Resolved
    created_tick: int
    converged_tick: int?
    intensity_history: List<(tick, value)>  // 强度变化轨迹
    root_cause: CausalChain?   // 溯源因果链
}

6.3 收敛策略选择

function select_strategy(deviation):
    if deviation.level == Critical:
        return SystemProtectionStrategy()
    elif deviation.level == High:
        return GlobalDampeningStrategy()
    elif deviation.level == Medium:
        return LocalAdjustmentStrategy()
    else:
        return ObserveOnlyStrategy()
策略 行为
ObserveOnly 仅记录，不干预
LocalAdjustment 调整偏差源附近状态的修改方向
GlobalDampening 临时降低相关规则的因果权重（×0.5）
SystemProtection 切换保守模式，冻结非关键演化，最高优先级覆盖

6.4 偏差溯源

偏差产生时，引擎回溯因果链：

function trace_root_cause(deviation):
    chain = []
    current = deviation.source
    while current has incoming causal links:
        predecessors = find_causal_predecessors(current, within_last_N_ticks)
        if predecessors is empty: break
        strongest = max_by(predecessors, causal_contribution)
        chain.append(strongest)
        current = strongest
    return reverse(chain)

溯源结果存入偏差的 root_cause 字段，供演化引擎分析「为什么会产生这个偏差」。

七、演化引擎（Evolution Engine）

7.1 职责

  • 按调度条件触发演化操作
  • 在影子模式下验证参数修改
  • 应用通过验证的演化
  • 回滚导致偏差扩大的演化
  • 管理经验库

7.1.1 MVP 阶段安全限制（v1.1 新增）

元宝和 Trae 的评审均指出 Evolve 是最危险的部分：「无 Error + 自演化 + 自动收敛」叠加会导致错误被静默固化。因此 MVP 阶段施加以下安全限制：

限制 说明
只允许参数调优 Evolve 只能调整已注册的可演化参数（阈值、delta_max、权重、步长），禁止自动生成/淘汰规则
偏差持续告警 偏差持续 N 个 Tick（默认15）不收敛时，触发告警而非静默吸收，告警包含偏差来源规则
告警时暂停演化 存在告警偏差时，不执行新的演化操作
告警时自动回滚 存在告警偏差时，回滚最近一次演化操作
全量审计日志 所有演化操作记录 Tick、目标、旧值、新值、原因、是否回滚
可演化参数注册表 只有显式注册的参数可被演化，防止演化触及不可变公理

这些限制在 M3 阶段可逐步放宽，但「审计日志」和「偏差告警」是永久保留的安全基础设施。

7.2 演化操作类型

EvolutionOp {
    target: Reference           // 要修改的对象（规则权重/阈值/系数/融合权重）
    delta: float                // 修改量
    direction: Increase | Decrease | Multiply
    reason: string              // 触发原因
    proposed_tick: int
    shadow_result: ShadowResult?// 影子验证结果
    applied: bool
    rolled_back: bool
}

7.3 影子验证流程

1. 生成演化操作 Op
2. 复制当前规则参数为 ShadowParams
3. 应用 Op 到 ShadowParams
4. 用 ShadowParams 重放最近 N 个 Tick 的历史数据
5. 计算 Shadow 下的系统偏差率
6. 对比 Shadow 偏差率 vs 实际偏差率
7. 若 Shadow 偏差率 <= 实际偏差率 × 1.2: 验证通过，应用 Op
   否则: 丢弃 Op，记录失败原因

影子验证保证演化不会让系统变得更差。

7.4 自动回滚

演化应用后，持续监控后续 M 个 Tick：

if post_evolution_deviation_rate > pre_evolution_deviation_rate × 1.2:
    rollback(evolution_op)
    mark_target_as_sensitive(target)  // 该目标后续演化步长减半
    emit Deviation(type="演化震荡", source=target)

7.5 经验库管理

ExperienceLibrary {
    entries: Map<ExpID, ExperienceEntry>
    index: SearchIndex   // 按场景关键词索引
}

ExperienceEntry {
    id: ExpID
    scenario: string            // 场景描述
    trigger: ConditionExpr      // 适用条件
    strategy: ActionBlock       // 执行策略
    effectiveness: float        // 效果评分 [0,1]
    use_count: int
    last_verified_tick: int
    tags: List<string>
}

经验库操作：

  • 沉淀：偏差成功收敛后，将「触发条件 + 收敛策略 + 效果评分」存入经验库
  • 查询：When 规则可通过 使用经验("名称") 直接加载策略
  • 淘汰：效果评分 < 0.3 且超过 100 Tick 未被使用的条目自动淘汰
  • 导入/导出：经验库可序列化为 JSON，跨程序复用

八、共享状态层

8.1 状态场存储

  • 主存储：列式存储（每个维度一个连续数组，便于趋势分析与向量化计算）
  • 历史存储：环形缓冲区，默认保留最近 1024 个 Tick
  • 快照：每 N 个 Tick 生成一个完整快照，支持回放与分支推演

8.2 规则注册表

  • 编译时将所有 When/Track/Evolve 声明编译为内部表示
  • 规则按涉及的状态维度建立倒排索引，便于快速定位「哪些规则读取了维度 X」
  • 规则不可在运行时增删（但可通过 Evolve 修改权重/阈值）

8.3 并发模型

  • 五大引擎在每个 Tick 的各阶段内并行执行
  • 引擎间通过暂存区交换数据，不直接共享可变状态
  • 提交阶段由调度器单线程执行，保证一致性
  • 匹配阶段（PHASE_2）是计算密集型，可水平扩展（多线程/多机）

九、性能特征

9.1 复杂度

操作 时间复杂度 说明
单 Tick 状态更新 O(D) D = 维度总数
因果匹配 O(R × C) R = 规则数, C = 平均条件数（可并行）
层级聚合 O(L) L = 联动链接数
趋势分析 O(T × W) T = Track 规则数, W = 窗口大小
偏差收敛 O(Dev) Dev = 活跃偏差数
演化验证 O(E × H) E = 演化操作数, H = 重放历史长度

9.2 参考性能（预估）

在普通笔记本（8核CPU）上：

  • 1000 维度 + 100 规则 + 10 万微域节点：约 50ms/Tick
  • 1万维度 + 1000 规则 + 100万微域节点：约 500ms/Tick（需向量化优化）
  • 因果匹配阶段可线性扩展到多机分布式

十、可观测性与调试

10.1 运行时探针

运行时提供以下探针接口：

探针 输出
tick_snapshot 完整状态场快照
rule_evaluation 每条规则的条件满足度与因果强度
deviation_trace 偏差的产生、扩散、收敛全轨迹
evolution_log 所有演化操作的提议、验证、应用、回滚记录
causal_chain 指定涌现事件的完整因果链溯源

10.2 回放调试

  • 任意 Tick 可从快照恢复
  • 支持单步执行（步进模式）
  • 支持分支推演：从某快照出发，修改参数后并行推演，对比结果
  • 支持「如果当时...」反事实推演

十一、可解释性引擎（v1.1 新增）

11.1 职责

可解释性引擎回答三个核心问题：

  1. 为什么触发：这条规则为什么在这个 Tick 触发？各条件贡献多少？
  2. 偏差从哪来：这个偏差是从哪条因果链扩散来的？
  3. 为什么调参：Evolve 为什么调整了这个参数？调整前后是什么？

详见《17元序可解释性设计》。

11.2 条件贡献度计算

因果引擎在评估规则时，递归计算每个子条件的：

  • 满足度（satisfaction）：0~1，该条件被满足的程度
  • 权重（weight）：该条件在父条件中的权重（合取默认平均分配）
  • 贡献度（contribution）= 满足度 × 权重

输出示例：

规则 [温度过低加热] ✓ 触发 (强度=0.800, 阈值=0.400)
  条件贡献度分解:
    环境.温度 < 环境.目标温度
      满足度=0.800 权重=1.00 贡献=0.800 ███████████████

11.3 偏差溯源

每个偏差记录携带 source_rule 字段，标识产生该偏差的规则。偏差持续不收敛时，告警包含来源规则，帮助定位上游问题。

11.4 演化审计

EvolutionLog 维护所有演化操作的完整记录，支持回滚。存在告警偏差时自动暂停演化并回滚最近操作。

11.5 CLI 支持

python -m worldscript.cli program.ws --explain   # 开启可解释性输出

文档版本: WorldScript Runtime Architecture v1.1
修订日期: 2026-09-03
修订内容: 新增1.3语义边界三层分离、7.1.1 Evolve安全限制、第十一章可解释性引擎
关联文档: 《元序规则》第十章、《元序实现路线图》、《17可解释性设计》、《16验证与确认体系》

posted @ 2026-09-03 16:23  新哲  阅读(8)  评论(0)    收藏  举报