欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

引言

本篇做常见的AI对话接口入参解析。
更多LLM应用设计分享可以看https://github.com/tataCrayon/llm-for-python-developers/tree/master/doc/system%20design。

1 入参解析

1.1 核心参数

• session_id/chat_session_id
  会话id，唯一标识对话链路，用于多轮上下文关联。

• parent_msg_id
  消息id，用于标记当前消息在会话中的位置，实现消息顺序管理。

1.2 核心参数细节解析

就通义千问和DeepSeek而言，核心参数的获取流程如下：

• session_id
  核心的session_id，QW是创建对话后第一次请求返回的，而DS是先通过create方法调用获取chat_session_id。

• parent_msg_id

内容有所不同：
两者第一次请求时，parent_msg_id都是空的，DS是null，而QW是""。
且两者值有很大不同，QW估计是UUIDv4或者哈希值，而DS简单的多，是从1开始递增的整数。

获取流程不同：
不同的地方在于后续parent_msg_id的获取，QW是通过上一次请求返回的message_id获取，DS是

parent_msg_id其他分析：

• 对话分支
  msg_id与parent_msg_id是典型的树形结构的邻接设计，应当是可以和Gemini一样支持“对话分支”的。
  DS和QW不支持“对话分支”的话可以只采用一个msg_id作为最新消息标识的，即last_msg_id。
  但是设计一个这样也挺好的。
• 连续对话的null值（边界问题，暂且忽略，TODO）
  所以实际设计时要注意连续对话中的parent_msg_id，如果为null或者""，应当是有问题的。

1.3 其他参数

会有一些其他参数设计用于做功能控制，比如：

• 超时控制
• 访问类型
• 上下文长度
• 调试参数
• 文件信息
• AI行为修改
• …

这些参数也可能在Headers中，本项目暂不做分析与设计。

1.4 入参总结

简单工程觉得可以融合QW与DS，我们第一次不额外调用create接口生成seesion_id，而是第一次请求返回，同时msg_id使用整数。
简单的入参可以如下：

{
  "session_id": "首次请求留空", 
  "parent_msg_id": 0, // 首次为0，后续为上次响应的 msg_id
  "content": "你好！",
  "stream": true,
  "options": {
    "max_tokens": 1024,
    "temperature": 0.7
  }
}

2 响应解析

• message_id\parent_msg_id
  QW每次请求都会返回一个msg_id作为下一次请求的parent_msg_id。
  DS也一样，名称不同。这里的细节有两点。

2.1 QW的冗余

这里值得注意的地方在于：
返回的每条data数据中都包含session_id、message_id和parent_msg_id。

作为同样火热的产品，为什么QW有这样的冗余，而DS又没有？

• 数据独立性
  简单分析是QW为了每条流式响应的数据的独立性，类似gRPC流式调用（每个帧自带元数据）。
• 多会话并行支持
  经验证，同一session_id下多开对话是可以的，msg_id不同，互不干扰。
  但是并没有做到对话分支的效果，而是保留时间靠后的对话作为patent_msg。
• 更灵活
  多标识多灵活多功能。易于调试、恢复等。虽然提升了复杂度。

DS设计相对精简。QW的这点数据量其实也可以忽略不计。

2.2 大量的元数据

我们可以看到QW返回的元数据密度极高，而DS极低。
两者设计理念差异巨大，这里用DS做简单分析：

维度	通义千问 (QW)	DeepSeek (DS)	设计理念差异
元数据密度	极高（每帧 20+ 字段）	极低（核心仅 2-3 字段）	QW：状态完备性；DS：传输效率
消息结构	全量快照式（含完整历史）	增量补丁式（仅最新内容）	QW：客户端免计算；DS：带宽优化
状态管理	显式声明（msgStatus/contentType等）	隐式事件驱动（event: finish等）	QW：强状态机；DS：轻事件驱动
内容传递	通过 contents[].content 传递完整内容	直接通过 v 传递纯文本增量	QW：结构化优先；DS：极简优先
会话控制	内嵌会话元数据（sessionOpen/share等）	独立会话事件（update_session）	QW：耦合设计；DS：关注点分离

总结：QW牺牲带宽提升了每帧数据的独立性，进而提升了对话整体可用性。DS则保证了带宽。

2.3 响应总结

简单融合一下，DS方案更适合做一个一般项目。

// 初始帧（携带元数据）
{
  "session_id": "sess-123",
  "msg_id": 5,
  "features": {  // 功能开关
    "can_share": true,
    "can_feedback": false 
  }
}

// 增量帧（极简传输）
{"delta": "Hello"}

// 状态帧（按需发送）
{"status": "generating", "token_used": 128}

// 结束帧
{"status": "finished", "full_text": "Hello World!"}

3 Header分析(使用了AI)

DS和QW的Request Header都存储了较多的信息。

DS如下：

Header 名称	方向	设计目的	示例值
Authorization	请求	身份验证核心机制	Bearer sk-xxx 或 Bearer sess-zzz
Content-Type	请求	声明请求体格式	application/json
Accept	请求	指定可接受的响应格式	application/json
X-Session-Id	响应	返回当前会话ID (替代传统session cookie)	sess-abc123xyz456
X-Request-ID	双向	全链路追踪ID (微服务调试关键)	req-9876543210
X-RateLimit-Limit	响应	单位时间最大请求数	100
X-RateLimit-Remaining	响应	剩余可用请求数	97
X-RateLimit-Reset	响应	限额重置时间戳 (秒)	1698765432
X-Conversation-ID	响应	长对话唯一标识 (跨session持续对话)	conv-5e8f7a3d
X-User-Id	请求	可选 业务系统用户ID (用于审计/分析)	user_12345
Stream	请求	启用流式响应 (SSE技术)	true
Cache-Control	双向	控制缓存行为	no-cache, no-store

• Authorization 的双模式设计

# 模式1：API Key 认证（首次请求）
Authorization: Bearer sk-98c572b6f5a84f2a90b2c7d3e8f45912

# 模式2：Session 认证（后续请求）
Authorization: Bearer sess-abc123xyz456

• 流式传输
  Stream: true 显式声明需要流式响应
  text/event-stream 启用 Server-Sent Events (SSE)
  chunked 编码实现动态内容分块传输

# 请求
Stream: true
Accept: text/event-stream

# 响应
Content-Type: text/event-stream
Transfer-Encoding: chunked