MDE 高级讲义 · 实战专题（第四模块）· 第二篇
正向路线：19-EClass 轨迹元模型全量参考
本仓自研元模型 trajectory.ecore 的完整字典：19 个类、9 个枚举、20 条不变量，一个不漏。开篇先看全类总图建立地图感，再按五簇走读，最后看「元模型即代码」的工程纪律——怎么用一份 .ecore 管住整套语言的演化。
概览
19
EClass
9
EEnum（48 个取值）
20
条不变量
18+3
容纳边 + 跨引用边
| 项目 | 说明 |
|---|---|
| 设计立场 | 以「模型实际看见了什么」为中心：事件流（L1）是原料，上下文流（L2）是主角——每个概念都为可计算的上下文生命周期服务 |
| 两层结构 | 骨架层（MultiAgentTrajectory → AgentTrajectory → Event）保真记录；上下文层（ContextFlow → CallFrame → ContextView）重建每次模型调用的视野 |
| 真源纪律 | 全部内容只存在于 trajectory.ecore 一个文件；任何修改回 .ecore，投影一键再生（见本讲末篇） |
| 本页用法 | 先总图后字典：走读遇到不认识的类，回到本页查卡片；07 讲实例走读将反复链接回这里的类卡 |
第一篇 · 全类总图
本篇 · 1 张总图
图 1 · 19-EClass 全类总图（与 .ecore 真源逐边对照）。上部骨架层回答「发生过什么」；下部上下文层回答「模型每一步看见了什么」。Event / Step 为骨架层独立锚点，经 id 引用被上下文层反向引用（event_refs 等属性）
骨架层在上，上下文层在下
classDiagram
direction TB
class MultiAgentTrajectory
class AgentTrajectory
class Event
class Step
class ContextFlow
class CallFrame
class ContextView
class Decision
class StateDelta
class ToolCall
class ToolResult
class EnvChange
class Message
class ContentBlock
class ToolDef
class Attachment
class AssemblyOp
class SemanticSlot
class Provenance
MultiAgentTrajectory "1" *-- "0..*" AgentTrajectory : agents
MultiAgentTrajectory "1" *-- "0..*" Event : collaborations
AgentTrajectory "1" *-- "0..*" Event : events
ContextFlow "1" *-- "0..*" CallFrame : frames
ContextFlow "1" *-- "0..*" Message : messages
ContextFlow "1" *-- "0..*" AssemblyOp : ops
ContextFlow "1" *-- "0..*" SemanticSlot : slots
CallFrame "1" *-- "1" ContextView : context_view
CallFrame "1" *-- "1" Decision : decision
CallFrame "1" *-- "1" StateDelta : state_delta
ContextView "1" *-- "0..*" ContentBlock : system_blocks
ContextView "1" *-- "0..*" ToolDef : tool_definitions
ContextView "1" *-- "0..*" Attachment : attachments
ContextView "0..*" o-- "0..*" Message : message_ids
Decision "1" *-- "0..*" ToolCall : tool_calls
StateDelta "1" *-- "0..*" ToolResult : tool_results
StateDelta "1" *-- "0..*" EnvChange : env_changes
Message "1" *-- "0..*" ContentBlock : blocks
Message "1" *-- "1" Provenance : provenance
SemanticSlot "0..*" o-- "0..*" CallFrame : anchored
第二篇 · 五簇走读（19 类逐类字典）
簇 1 · 轨迹骨架（4 类）
MultiAgentTrajectory / AgentTrajectory / Event / Step —— 保真记录「发生过什么」
骨架层的第一职责是不丢信息：把每家 agent 的原始事件序列原样收进来，配上统一的编号与类型。
| 类 | 关键属性 | 职责 |
|---|---|---|
| MultiAgentTrajectory | run_id* | 多 agent 协作全程的根容器：容纳各家的 AgentTrajectory + 跨 agent 协作事件（collaborations） |
| AgentTrajectory | run_id*、agent_id*、metadata | 单个 agent 的一段轨迹，容纳它的全部 Event；metadata 存加载器附加信息 |
| Event | run_id*、agent_id*、idx*、event_type*、parse_format*、raw_json*……共 18 个属性 | 原子事件。raw_json 保留原始记录实现零损耗；tool_name/tool_input/tool_output 内联常见工具信号；parent_event_id + causality_id 提供因果线；sender/receiver 支撑多 agent 消息 |
| Step | step_id*、agent_id、idx、label、event_refs[] | 人读友好的步骤分组：把一串 Event 圈成一个有名字的步骤（如「读文件」「改代码」），event_refs 回指事件编号 |
本簇专属枚举 · EventType（12 值）
- 对话类：SYSTEM / USER / ASSISTANT / MESSAGE；工具类：TOOL_USE / TOOL_RESULT / RESULT
- 异常与控制类：ERROR / HANDOFF / SPAWN / DELEGATE / JOIN——后四值专为多 agent 协作预留
Step 与 Event 的关系：分组视图，不是拷贝——真相只在 Event
簇 2 · 上下文流（5 类，本元模型的心脏）
ContextFlow / CallFrame / ContextView / AssemblyOp / SemanticSlot —— 重建「模型看见了什么」
骨架层记录发生过的，上下文层回答更有研究价值的问题：第 N 次模型调用时，上下文窗口里到底装了什么。
| 类 | 关键属性 | 职责 |
|---|---|---|
| ContextFlow | meta | 一次完整运行的上下文总账：全部帧（CallFrame）、全部消息（Message）、全部装配操作（AssemblyOp）、全部语义槽（SemanticSlot）的根 |
| CallFrame | frame_id*、trigger、protocol、stop_reason、token_usage、latency_ms、fidelity、event_refs[]、raw | 一次模型调用的完整剖面：谁触发（trigger）、走什么协议、为何停止、耗了多少 token；内含当次的三件套——视野（ContextView）+ 决策（Decision）+ 状态变化（StateDelta） |
| ContextView | token_estimate、token_parity、ordering_note、fidelity_notes | 当次调用的「视野快照」：哪些消息可见（message_ids 跨引用）、系统块、工具定义表、附件；token_estimate 供与官方用量对账 |
| AssemblyOp | op_id*、op_type*、target、tokens_before/after、lossy、evidence | 视野变化的一次显式操作（增/删/压缩/重写）。lossy=true 必须给 evidence——信息丢了，判据不能丢 |
| SemanticSlot | slot_type*、statement、filled_by、confidence、evidence_event_ids[] | 语义级「填空题」：如「任务目标是什么」，谁在哪一帧填的、置信度多少、证据是哪些事件；anchored 跨引用到帧 |
本簇专属枚举
- Trigger（5）：TASK_START / TOOL_RESULT / USER_INPUT / RESUME / RETRY——帧为什么被触发
- Fidelity（3）：F0_OBSERVED（逐字观测）/ F1_STRUCTURAL（结构可靠、内容近似）/ F2_OPAQUE（只知发生了调用）——每帧标注重建可信度，禁止把猜测伪装成观测
- OpType（9）：APPEND / INJECT / PIN / DROP / COMPACT / TRUNCATE / EVICT / REWRITE_SYSTEM / UNKNOWN_DELTA——上下文装配的全部操作动词；UNKNOWN_DELTA 是诚实兜底：变了但说不清怎么变
与 06 讲对照：COMPACT（此处一个操作动词）vs CompactionRecord（彼处一个完整记录类）
簇 3 · 消息与工具（6 类）
Message / ContentBlock / ToolDef / Attachment / ToolCall / ToolResult —— 窗口里的实体
| 类 | 关键属性 | 职责 |
|---|---|---|
| Message | msg_id*、role*、origin、frame_introduced、dropped_at、pinned、compact_summary | 一条消息的完整生命周期：哪一帧进入视野（frame_introduced）、哪一帧被丢弃（dropped_at）、是否钉住（pinned）、是否本身是压缩产物（compact_summary） |
| ContentBlock | block_type、text、tool_call_id、tool_name、tool_input、tool_output、is_error、content_digest、content_ref | 消息内的内容块（文本/工具调用/工具结果…）；digest + ref 支持「内容指纹 + 外置原文」，大载荷不撑爆模型 |
| ToolDef | name*、description、input_schema、sent、visible | 工具定义。sent/visible 两级开关：发进上下文 ≠ 用户看得见（hidden tool 是真实现象） |
| Attachment | kind*、content_digest、content_ref、frame_introduced | 随帧附加的材料（文件/图像/检索结果），同样带指纹与外置引用 |
| ToolCall | call_id*、name*、input、raw | 模型发出的一次工具调用（挂在 Decision 下——是决策的产物） |
| ToolResult | call_id*、status、output_excerpt、output_digest、error | 工具执行的回包；excerpt + digest 兼顾人读与可核对 |
本簇专属枚举 · Origin（6 值）
- INITIAL / TASK_PROMPT / MODEL_OUTPUT / TOOL_OUTPUT / HUMAN_INJECTION / RETRIEVAL——每条消息「从哪来」，配合 Dimension（LOCAL / INTERACTION）区分本地演化与交互产生
簇 4 · 决策与状态（3 类）
Decision / StateDelta —— 模型做了什么，世界变了什么
| 类 | 关键属性 | 职责 |
|---|---|---|
| Decision | kind、reasoning、text、confidence_signals、raw；tool_calls[] | 当次模型决策剖面：是推理（REASON）、发工具（EMIT_TOOL_CALLS）、收工（TERMINATE）还是移交（HANDOFF）；tool_calls 挂在此处而非 Message——调用是决策的直接产物 |
| StateDelta | （无自有属性） | 这一帧引起的世界变化，聚合两类后果：tool_results + env_changes |
| EnvChange | kind、detail、observability | 环境侧变化（文件被改/进程退出…）。Observability（OBSERVED / INFERRED / UNKNOWN）诚实标注：这变化是看见的、推断的还是不知道的 |
本簇专属枚举
- DecisionKind（4）：REASON / EMIT_TOOL_CALLS / TERMINATE / HANDOFF
- Observability（3）：OBSERVED / INFERRED / UNKNOWN
簇 5 · 溯源（1 类）
Provenance —— 每条消息的血统证书
| 类 | 关键属性 | 职责 |
|---|---|---|
| Provenance | relation、origin_event_ids[]、origin_frame_ids[]、note | 消息与其来源的关系：ORIGINATES_FROM（直接来源）/ DERIVES_FROM（加工改写，如摘要）/ COPIED_FROM（复制）/ INITIAL（初始就有）。压缩摘要消息正是靠 DERIVES_FROM 找回它概括了谁 |
本簇专属枚举 · ProvenanceRelation（4 值）
- ORIGINATES_FROM / DERIVES_FROM / COPIED_FROM / INITIAL
第三篇 · 9 枚举全表
本篇 · 字典附表
48 个取值一览（按簇归组）
| EEnum | 取值数 | 全部取值 |
|---|---|---|
| EventType | 12 | SYSTEM · USER · ASSISTANT · TOOL_USE · TOOL_RESULT · RESULT · ERROR · HANDOFF · SPAWN · DELEGATE · MESSAGE · JOIN |
| Trigger | 5 | TASK_START · TOOL_RESULT · USER_INPUT · RESUME · RETRY |
| Fidelity | 3 | F0_OBSERVED · F1_STRUCTURAL · F2_OPAQUE |
| Origin | 6 | INITIAL · TASK_PROMPT · MODEL_OUTPUT · TOOL_OUTPUT · HUMAN_INJECTION · RETRIEVAL |
| ProvenanceRelation | 4 | ORIGINATES_FROM · DERIVES_FROM · COPIED_FROM · INITIAL |
| DecisionKind | 4 | REASON · EMIT_TOOL_CALLS · TERMINATE · HANDOFF |
| Observability | 3 | OBSERVED · INFERRED · UNKNOWN |
| OpType | 9 | APPEND · INJECT · PIN · DROP · COMPACT · TRUNCATE · EVICT · REWRITE_SYSTEM · UNKNOWN_DELTA |
| Dimension | 2 | LOCAL · INTERACTION |
三处「诚实设计」值得注意：Fidelity 承认重建有三档可信度、Observability 承认环境变化有的只能推断、OpType 留 UNKNOWN_DELTA 承认有的变化说不清。元模型不装全知，才配当研究工具。
第四篇 · 20 条不变量逐条讲
本篇 · 全 20 条
编号 I0–I6 + IG + I4a + 11 条具名规则
| 编号 / 名称 | 规则原文 | 人话解释 |
|---|---|---|
| I0 | 零帧即失败——空模型与成功必须可区分 | 一个帧都没有就不是有效重建；不许拿「空」冒充「成功」 |
| I1 | 每个 ToolResult 必有其 ToolCall 来源 | 没有调用哪来结果——孤儿结果一律非法 |
| I2 | 非 initial 消息必须指回 L1 事件/历史帧 | 凭空出现的消息不存在，必须能对上事件层证据 |
| I3 | len(frames) = 实际模型调用次数 | 帧数就是调用数，多一帧少一帧都是重建失真 |
| I4 | 上下文变化可被 AssemblyOp 解释 | 视野变了必须留下操作记录，不许有「无解释的变化」 |
| I5 | 每个内容项 origin 已知（可映射 Dimension） | 内容从哪来必须说得清 |
| I6 | 帧不覆盖本地非交互段（初始化/宿主行为/环境漂移） | 模型调用只对交互段负责，本地行为别硬塞进帧 |
| IG | F2 帧不得携带内容级载荷（伪精确防护） | 看不清的帧（OPAQUE）不许假装看得清——防伪造精度 |
| I4a | 相邻帧的可见消息集差分必须等于 introduced 减 dropped（I4 的严格形态，单列） | 帧间视野变化必须逐条对账：新进的减退出的，正好等于差集 |
| ToolCallHasDefinition | 帧内每个 ToolCall 的 name 必须在该帧 context_view.tool_definitions 中存在且 visible | 调用的工具必须当帧真的声明过、且可见 |
| LossyOpHasEvidence | lossy=true 的 AssemblyOp 必须携带非空 evidence | 有损操作必须给出判定依据 |
| LifecycleMonotonic | dropped_at 非空时必须 ≥ frame_introduced | 消息不能先丢后进——生命周期单调 |
| PinnedNeverDropped | pinned=true 的消息不得有 dropped_at | 钉住 = 永不丢弃 |
| TokenDeltaConsistent | AssemblyOp 的 tokens_before/tokens_after 与 op_type 的增减方向一致（非 append 类不得净增） | 操作类型与 token 增减方向要对得上 |
| VisibilitySubsetOfSent | ToolDef.visible=true 蕴含 sent=true | 没发送的工具不可能可见 |
| AssemblyOpsBelongToFrame | AssemblyOp.frame_id 非空时必须能解析到所属 ContextFlow 的某帧 | 操作必须挂在真实存在的帧上 |
| ToolCallKindConsistency | Decision.kind=emit_tool_calls 时 tool_calls 必须非空 | 说了发工具就得真有工具调用 |
| TaskRefResolves | SemanticSlot.filled_by 等引用必须可解析到注册对象 | 引用不许悬空 |
| FrameRoundTripClosure | 帧经 to_dict/from_dict 往返后语义不变 | 序列化不能偷改语义（往返闭合） |
| TokenEstimateNonNegative | ContextView.token_estimate 非空时必须 ≥ 0 | token 估算不许出现负数 |
第五篇 · 工程纪律：元模型即代码
本篇 · 1 条流水线
图 2 · 元模型工程流水线：真源单点、投影再生、实现 reconcile 双向对账、--check 字节闸防手改漂移。同一提交内 .ecore + 投影 + 实现适配必须一起走
唯一真源 → 字节闸 → 投影 → 对账
19 个类的世界里，trajectory.ecore 是唯一定义处。改元模型只有一个合法动作：改 .ecore，然后按序跑再生。手改任何投影产物 = 违法。
flowchart LR
E["trajectory.ecore
唯一真源（19 类/9 枚举/20 不变量）"] R["regenerate
一键再生"] P1["metamodel.json"] P2["类图 .mmd / .svg"] G["_gen 生成层
（结构变更时 --gen 重建）"] T["pytest 双解析一致性
+ reconcile 2.0 对账"] CK["regenerate --check
字节级新鲜度闸门"] E --> R R --> P1 R --> P2 R --> G R --> T T --> CK
唯一真源（19 类/9 枚举/20 不变量）"] R["regenerate
一键再生"] P1["metamodel.json"] P2["类图 .mmd / .svg"] G["_gen 生成层
（结构变更时 --gen 重建）"] T["pytest 双解析一致性
+ reconcile 2.0 对账"] CK["regenerate --check
字节级新鲜度闸门"] E --> R R --> P1 R --> P2 R --> G R --> T T --> CK
这套纪律教给我们什么
- 单真源：类图、JSON schema、生成代码全是投影——衍生品永不手改，杜绝「三份真相各自漂移」
- 字节闸：regenerate --check 逐字节比对投影是否新鲜，手改立刻红灯
- 双向对账：reconcile 让实现侧与 .ecore 互相对账——实现里冒出 .ecore 未收录的类型/字段即红灯，防止「实现先斩后奏」
- 同批提交：.ecore + 再生投影 + 实现适配必须同一 commit，禁止分家——演化永远原子
MDE 理论呼应：这就是「模型作为首要制品」落到工程的样子
对照读：逆向路线的另一套治理（认源 + 拒答）→