实例模型案例集：从真实文件到元模型的三层一线

原始字段 → 实例元素 → 元类 → 含义

文件首行原文（Claude Code 的 JSONL 事件流，一行一个事件）：

{"type":"queue-operation","operation":"enqueue","timestamp":"2026-08-30T11:03:23.610Z",
 "sessionId":"8ee257b6-b37e-4cb2-9a51-66e596cb14e5","content":"当前的模型是什么"}

四栏对照（右侧两栏的实例值取自 TMR 还原结果原文）：

这份文件的另一个教学细节：实例里还有一条 Message m9（content="[Request interrupted by user]"）——用户中途打断也被诚实还原为一条 user 消息，而不是被丢弃。

业界标准格式：一切皆事件

{"type":"queue-operation","operation":"enqueue", …,"content":"当前的模型是什么"}
{"type":"queue-operation","operation":"dequeue", …}

• 队列操作事件被过滤为会话语境，真正的对话内容落为 2 个 Message（m3 提问、m9 打断）各含 1 个 text Part
• 分布：Session 1 / Trajectory 1 / Agent 1 / Message 2 / Part 2——最小但五脏俱全的实例

• queue-operation 事件 → 不直接成类，成为认源信号（06 讲：认源打分靠这类指纹字段判「这是 claude-code」）
• content → Part.content（partType=text）；sessionId → Session.id

• 事件流格式的还原策略：不是每个事件都配成为模型元素——元模型的筛子把「协议噪声」留在认源层，把「语义内容」放进实例层

纯文本也能逆向成模——本批最丰满实例

# aider chat started at 2026-09-29 21:34:16
> /tmp/w77-trae/venv/bin/aider --model openai/glm-4.5-flash … --message 创建 calc.py 实现两数相加函数…
> Warning for openai/glm-4.5-flash: Unknown context window size…

• 本批语料分布最富的实例：Session 1 / Trajectory 1 / Step 9 / Message 12 / Part 14 / Agent 1 / Tool 1
• Markdown 的段落结构（标题、引用行、代码块）被解析为 Step 分组与 Message/Part 链

• chat 标题时间 → Session 起点；每个 > 交互块 → Turn/Step；正文与代码块 → Part（text / file 型）
• aider 落盘里出现的编辑动作 → Tool（aider 内建 edit 工具面）+ tool_use/tool_result 型 Part

• 「格式多样性行不行」的试金石：连 Markdown 都能还原，说明筛子在「语义结构」层工作，不在「文件格式」层较劲

Part 粒度爆炸：同一句话切出 81 个内容块

{"timestamp":"2026-08-28T20:40:52.01","type":"session_meta","payload":{…}}
{"timestamp":"…","type":"response_item","payload":{"type":"message","role":"user", …}}

• 分布：Session 1 / Trajectory 1 / Step 8 / Message 11 / Part 81 / Agent 1 / Tool 1
• Part 数是 Message 数的 7 倍多——rollout 格式把细粒度事件（增量文本、推理块、工具交互）都切成了 Part

• response_item 事件流 → Step（8 步聚合 200+ 事件）；payload 内的消息 → Message；细粒度内容/推理块 → Part（text / reasoning 型——reasoning 是 13 系一等公民）

• 同一元模型下不同源的自然「体型差」：粒度是源的属性，不是模型的属性——元模型不强迫各家一样细，只保证都能装下
• 对比着看：claude 2 个 Part vs codex 81 个 Part，做跨源统计时 Part 数必须按源分层，不能直接平均

最小闭环：学术 agent 的教科书形态

{"history":[
  {"role":"system","content":"SETTING: You are an autonomous programmer…","message_type":"system_prompt"},
  {"role":"user","content":"We're currently solving the following issue…","message_type":"observation"}]}

• 分布：Session 1 / Trajectory 1 / Step 5 / Message 7 / Part 7 / Agent 1——无 Tool（该样例走 function-calling 演示，工具交互内联在消息里）

• history 数组逐项 → Message（role 直接映射 Role 枚举 system/user）；message_type 语义 → 消息在 Step 里的分组依据
• 整个文件一个 JSON → 单 Trajectory，无父子轨迹

• 「最小合规实例」长什么样：Turn 为空、SubagentLink/CompactionRecord/ContextEpoch 全空——13 类中一大半允许为空，这正是 conforms-to 但不饱满的形态（对比 05 讲 I0「零帧即失败」：空的是现象类，骨架类一个不少）

模型拒绝收编的边界：宁可拒答，不可错认

{"role":"user","content":"hi"}
random text line
{"foo": 1}

• 认源打分不出任何一家的高置信信号——文件被判定为拒解（rejected），不生成实例

• 无实例可钉——这正是教学点：conforms-to 的前提是先通过认源门禁；元模型的守门在语言之前

• 错误模型比没有模型更危险：硬把杂文本塞成 Session/Trajectory，下游所有分析全部污染。四态里的 rejected 就是流水线的「熔断器」
• 延伸：本仓 5-brand（kimi/mimo/opencode…）实验轨迹流也全部拒解——它们是平台自产的事件表格式，不在已登记源之列（08 讲习题：该不该为它立源？）

源 → 格式 → 实例分布 → 要点