门户首页
MDE 高级讲义 · 实战专题（第四模块）· 第三篇

逆向路线：13-EClass 与多源还原

正向路线先设计语言再装数据；这一讲反着来——先收下 26 家 agent 的真实落盘，从数据里把公共概念「挣」出来，变成 13 个 EClass。你会看到模型变换（源模型 → 目标元模型）的真实工程形态，以及三个只有真实轨迹才会逼出来的新概念：子代理链、上下文压缩记录、上下文纪元。

生成时间：2026-10-08 · 版本 v0.2.2 · 覆盖 13 EClass / 12 EEnum 全结构 + 26 个源模型定义机制 + 三类全量展开（SubagentLink / CompactionRecord / ContextEpoch）· 生成 Agent：ZCode (LLM: GLM-5.3) · 载体：agentsoft-research-platform teaching-web-platform · 证据源：vendored trajectory_metamodel/ecore/trajectory_v2.ecore（VENDOR-PIN 钉版）+ demo-corpus 18 源实测（2026-10）
← 返回 MDE 模块入口 04 开篇 05 全量参考 06 逆向路线（本页） 07 实例案例集 08 动手与思考

概览

13
EClass
12
EEnum
26
个源模型定义
18
源真实语料实测
项目说明
范式逆向成模（reverse modeling）：日志 → 模型。经典 MDE 是模型生成代码，这里是数据归纳语言——前沿方向之一
还原链认源（这文件是哪家的？）→ 源模型（它的原生概念是什么？）→ canonical map（概念怎么映射？）→ 目标元模型实例 + 回译校验
诚实立场宁可拒答，不可错认——认不出、映射不满就给 rejected / partial，不硬造模型（07 讲有真实拒解案例）
与 05 讲的关系同一领域的设计空间另一端：19 系从上下文研究正向生长，13 系从多源数据逆向归纳；两套并行、互不合并

第一篇 · 逆向成模：先收数据，再定语言

第一篇 · 范式与还原链
一个文件从「认出你是谁」到「变成合法实例」要走五步，每步都可能诚实地说「不行」。
本篇 · 1 条还原链

认源 → 源模型 → 映射 → 实例 → 回译

flowchart LR F["真实文件
（任意格式）"] S1["① 认源
多信号打分
认不出 → rejected"] S2["② 源模型
26 个 definition
（各家原生概念）"] S3["③ canonical map
源概念 → 13 类"] S4["④ 实例
conforms-to 13 EClass"] S5["⑤ 回译校验
译不回 → partial"] F --> S1 S1 -->|"置信度足够"| S2 S1 -->|"信号不足"| RJ["拒解
（07 讲案例）"] S2 --> S3 S3 --> S4 S4 --> S5
图 1 · 多源还原链：认源打分决定「配不配被建模」，源模型 + canonical map 完成模型变换，回译校验兜底「还原得对不对」。三处诚实出口：认不出拒解、映射不满降档、回译失败标 partial
与经典 MDE 的方向对照
  • 经典正向：设计元模型 → 定义建模语言 → 生成代码 / 变换出其他模型
  • 本路线逆向：先有海量异构数据 → 归纳公共概念成元模型 → 每个源各自写「方言 → 标准」的映射
  • 26 个源模型定义（definition/sources/）正是 MDE 里「模型变换规格」的实物：每家一份 .ecore 源模型 + canonical map
认源打分细节（19 源信号体系）见专题 05 工具链讲义

第二篇 · 13 类走读

第二篇 · 语言本体
分三组：会话骨架（4 类）、会话组织（4 类）、轨迹现象与挂接（5 类）。带 * 为必填。
本篇 · 实拍 + 结构图

先看工具里长什么样，再看结构图

TMR 工具中渲染的 13-EClass 元模型图：Session、Trajectory、Agent、Tool、Turn、Step、Message、Part、SubagentLink、CompactionRecord、ContextEpoch、AnalysisReport、AnalysisRecord 及关系边
图 2 · 13-EClass 在 TMR 工具「模型 M1」视图中的真实渲染（判档着色与本讲义无关）。结构与下方类图逐边一致
classDiagram direction TB class Session class Trajectory class Agent class Tool class Turn class Step class Message class Part class SubagentLink class CompactionRecord class ContextEpoch class AnalysisReport class AnalysisRecord Session "1" *-- "0..*" Trajectory : trajectories Session "1" --> "1" Trajectory : activeTrajectory Session "1" --> "1" Agent : owner Trajectory "1" *-- "0..*" Turn : turns Trajectory "1" *-- "0..*" Step : steps Trajectory "1" *-- "0..*" Message : messages Trajectory "1" *-- "0..*" SubagentLink : subagentLinks Trajectory "1" *-- "0..*" CompactionRecord : compactionRecords Trajectory "1" *-- "0..*" ContextEpoch : contextEpochs Agent "1" --> "0..*" Tool : toolSet Turn "1" --> "0..*" Step : steps Step "1" --> "0..*" Message : producedMessages Step "0..*" --> "1" Agent : agentRef Message "1" *-- "0..*" Part : parts Part "0..*" --> "0..1" Tool : toolRef CompactionRecord "1" --> "0..*" Message : covers CompactionRecord "1" --> "1" Message : produces ContextEpoch "0..*" --> "1" Step : atStep AnalysisReport "1" *-- "0..*" AnalysisRecord : records AnalysisRecord "0..*" --> Trajectory
图 3 · 13-EClass 结构图（与 trajectory_v2.ecore 逐边对照）：实心菱形为容纳，箭头为跨引用。Session 是会话根，Trajectory 是建模主角，AnalysisReport/AnalysisRecord 是挂接其上的分析层
组 1 · 会话骨架（4 类）

Session / Trajectory / Agent / Tool

类关键属性职责
Sessionid*、lifecycle、currentHistory[]、activeTrajectory、owner一次会话的壳：生命周期（active / suspended / resumable / archived）、当前轨迹、归属 agent
Trajectoryid*、format、turnEndReason、parentTrajectory建模主角：容纳 turns / steps / messages / subagentLinks / compactionRecords / contextEpochs 六大名单；format 记录原生格式；parentTrajectory 支持父子轨迹（fork / 子代理）
Agentid*、origin（root / spawned）、model、toolSet执行主体。origin 区分根 agent 与被生成（spawned）的子代理——多 agent 现象的一等公民
Toolname*、description、inputSchema工具定义表，被 Part 经 toolRef 引用
组 2 · 会话组织（4 类）

Turn / Step / Message / Part —— 四层套娃

这是 13 系对「一次会话怎么组织」的回答，四层各管一段粒度：

类关键属性职责
Turnid*、steeringSignal、followUpSignal一轮对话回合；两个信号位标记「用户中途介入 / 追问」——真实会话里很常见的打断现象
Stepid*、kind（regular / planning / final_answer）、decision、decisionKind、attempt、modelOverride、reasoningEffortagent 的一个动作单元；attempt 记录重试次数、modelOverride 记录中途换模型——工程现场的两类真实噪声
Messageid*、role*、seq、timestamp、control、controlDetail一条消息；control/controlDetail 承载协议级控制信息（如中断、重试指令）
PartpartType*（text / reasoning / tool_use / tool_result / file / audio / attachment）、content、callId、toolName、toolState消息内的最小内容块。reasoning 独立成类型——思维链在真实落盘里就是一等公民；toolState 四态（pending / running / completed / error）把工具生命周期写进类型
组 2 专属枚举
  • Role（4）：system / user / assistant / tool　StepKind（3）：regular / planning / final_answer　AgentOrigin（2）：root / spawned
  • PartType（7）：text / reasoning / tool_use / tool_result / file / audio / attachment　ToolPartState（4）：pending / running / completed / error
  • TurnEndReason（8）：completed / error / aborted / max_tokens / max_turns / blocked / stuck / interrupted——一轮怎么结束的八种方式，每一种都是真实失败模式
组 3 · 三个新现象（全量展开）

SubagentLink / CompactionRecord / ContextEpoch —— 数据逼出来的概念

这三个类是逆向路线的勋章：不是先设计出来等人用，而是多源数据里反复出现、不立类就说不清，才在元模型里挣到席位。

类关键属性职责 + 实测佐证
SubagentLinkkind（embedded / ref / fork）、granularity、trajectoryRef、childAgent子代理关系的三种挂法：内嵌（子轨迹全文在父轨迹里）/ 引用（只存指针）/ fork（分叉出去独立跑）。实测：demo-corpus 的 goose 会话还原出 9 个 Agent——一个会话里 9 个主体协作，没有这个类就只剩一团乱线
CompactionRecordsemantics（forgetful / retentive）、medium（event / message / file）、trigger（manual / threshold / overflow / provider-error）、strategy、summary、firstKeptEntryId、tokensBefore、shadowedRange、forgottenEventIds、covers[]、produces一次上下文压缩的完整档案：是「忘掉」还是「留摘要」（semantics）、压在哪层介质、谁触发、压缩前后边界在哪、覆盖了哪些消息、产出了哪条摘要消息。实测：demo-corpus 的 dsh 会话（compaction-recovery 场景）还原出 1 条 CompactionRecord——压缩-恢复全流程可追溯
ContextEpochbaseline、baselineSeq、atStep上下文纪元：一次基线重置（如 /clear 或大规模压缩后）把会话切成「纪元」，每纪元有自己的可信基线。挂在具体 Step 上，说明世界从哪一步起「重新开始」
组 3 专属枚举
  • SubagentLinkKind（3）：embedded / ref / fork
  • CompactionSemantics（2）：forgetful / retentive　CompactionMedium（3）：event / message / file　CompactionTrigger（4）：manual / threshold / overflow / provider-error
与 05 讲的对照：同一个「上下文压缩」现象，19 系用 AssemblyOp 的一个 COMPACT 操作动词 + lossy/evidence 属性表达（操作视角）；13 系升级为一个完整的 CompactionRecord 类（档案视角，还带 trigger/semantics 语义）。同一现象、两种抽象粒度——这就是元模型设计空间的活教材。
组 4 · 分析挂接（2 类）

AnalysisReport / AnalysisRecord —— 模型上长出分析层

类关键属性职责
AnalysisReportid*、subjectTrajectoryId、kind、evidenceGrade、measure针对某条轨迹的分析报告：错误标注 / 失败模式 / 过程指标 / 成本归因 / 可靠性指标五类（AnalysisKind）
AnalysisRecordkind、label、evidenceGrade、measure、sourceRef、trajectoryRef / stepRef / turnRef / messageRef / partRef单条分析发现，五级引用可精确挂到轨迹的任意层（轨迹 → 回合 → 步 → 消息 → 块）——评估结果不漂在空中，钉在模型上
组 4 专属枚举 · AnalysisKind（5）
  • error_annotation / failure_mode / process_metric / cost_attribution / reliability_metric

第三篇 · 四态：还原结果的诚实分级

本篇 · 与不变量对应的另一套诚实机制

ok / partial / rejected / done——每个作业落一个态

19 系用 20 条不变量在语言内部守诚实；13 系在还原流水线出口守：每个分析作业（job）结束时必须落一个态，不许含糊。

态含义实测例（07 讲）
ok认源 + 映射 + 回译全通，实例完整可用18 源中 15 源的样例（claude / aider / codex / sweagent …）
partial部分还原：认得出、映射不满或回译有缺，实例可用但要打折扣看dsh 的两个会话（快照式落盘，部分内容译不回）
rejected认源失败或格式不达标，拒绝建模——不硬造一段伪装成轨迹的杂乱文本（07 讲拒解案例）
done跑完但产物为空 / 不可展示（如零事件文件）空壳作业
「宁可拒答，不可错认」的完整论证见专题 05 工具链讲义第三篇