[!info] related notes

• 所属 MOC: LLM Streaming MOC
• 各模式: Multi-channel Stream, Structured Streaming, Event Sourcing AI
• 基础协议: Delta Stream, Append Event Stream, Full State Stream
• 基础对比: Delta Stream vs Append Stream

Streaming 高级协议模式

范围

对比和串联三种 LLM Streaming 的高级协议模式：Multi-channel Stream、Structured Streaming、Event Sourcing AI。它们是可组合的设计维度，不构成固定协议栈。

为什么要放在一起理解

这三种模式经常被混淆为”新的 streaming 方式”，但它们解决的是不同层面的问题：

模式	解决的问题
Multi-channel	输出到哪里？（分流）
Structured Streaming	事件长什么样？（封装）
Event Sourcing	事件怎么存和回放？（状态建模）

理解它们的层级关系，才能正确组合使用。

职责组合示意

以下树形只用于分组，不表示 Event Sourcing 必须位于某一网络层，也不表示 Delta 与 Append 互斥。

Structured Event Stream        ← 事件格式层："事件长什么样"
  └─ Multi-channel Routing     ← 分流层："更新到哪里"
       └─ Delta / Append / State  ← 增量模型层："怎么更新"

加上 Event Sourcing：

Structured Event Stream        ← 协议格式
  └─ Multi-channel Routing     ← 输出分流
       └─ Delta / Append       ← 增量方式
            └─ Event Sourcing  ← 存储与回放

它们如何叠加

组合一：Structured + Multi-channel + Delta

{
  "type": "message.delta",
  "channel": "text",
  "data": {
    "message_id": "m1",
    "content": "你好"
  }
}

这是：

• Structured Streaming：有稳定的 type + data 结构
• Multi-channel：有 channel: "text"
• Delta Stream：content 是追加到同一个 message 的文本增量

组合二：Structured + Multi-channel + Append

{
  "type": "tool_call.created",
  "channel": "tool",
  "data": {
    "tool_call_id": "t1",
    "name": "symptom_extract",
    "args": {}
  }
}

这是：

• Structured Streaming：有稳定的 type + data 结构
• Multi-channel：有 channel: "tool"
• Append Stream：追加了一个新的工具调用事件

组合三：Structured + Event Sourcing

{
  "eventId": "evt_001",
  "sessionId": "sess_123",
  "type": "ToolCallRequested",
  "sequenceNumber": 5,
  "data": {
    "tool_call_id": "t1",
    "name": "symptom_extract",
    "args": {}
  },
  "timestamp": 1719600000000
}

这是：

• Structured Streaming：有稳定的事件结构
• 具备事件溯源所需的部分标识；还须持久化完整事实、规定顺序范围、处理重复与版本，并提供无副作用的 reducer，才能可靠重建状态

各模式独立使用 vs 组合使用

场景	推荐模式
简单聊天	文本 delta，加完成/失败与消息标识
Agent / workflow	Append Stream
需要区分公开摘要/回答	+ Multi-channel，服务端先执行展示权限策略
需要统一事件格式	+ Structured Streaming
需以事件事实重建业务状态	评估 Event Sourcing；普通调试日志不必采用它

从文本展示扩展到任务状态

关注范围可以逐步扩大：

Text Streaming（流式传输文本）
    ↓
Event Streaming（流式传输事件）
    ↓
AI Runtime State Streaming（流式传输 AI 任务的状态演化过程）

早期 streaming 只关心：

assistant 正在说什么。

高级 streaming 还要表达：

• assistant 正在生成哪条消息
• 是否调用了工具，参数是什么
• 工具结果是否返回
• 是否产生了结构化信息
• 哪些内容展示给用户，哪些隐藏
• 当前任务处于什么状态
• 最终消息何时完成

对比与易混淆点

• 三者不是同一层的竞争关系：它们解决不同层面的问题，可以自由组合。
• 按状态与恢复需求组合，不必全部采用。
• 统一事件外壳有助于消费，但 payload 校验、兼容规则与终态语义仍需定义。
• Event Sourcing 涉及事实存储和状态重建；回放投影不能再次触发工具副作用，且不自动满足审计合规要求。
• Multi-channel 和 Semantic Router 的关系：Semantic Router 是后端的分流逻辑，Multi-channel 是协议层的通道标识。前者产生后者。