/v1/dual 不适合一直聊
/v1/dual 很适合展示双轨：一次请求同时返回 A 线和 B 线。可是拿它做连续问诊，就开始别扭。
用户只是补一句“疼了两天”，也要等 B 线报告一起跑完。A 线本来应该轻快，结果被同步报告拖住。这个体验不太像聊天，更像每轮都在提交一份表单。
所以 v1.1 的目标不是重做双轨，而是把 A 线从 /v1/dual 里解放出来。
新增三类接口
这一轮加了几个更像聊天产品的接口：
POST /v1/chat：提交一轮用户消息；GET /v1/sessions/{id}/messages：读取会话消息；POST /v1/consult/stream：用 SSE 返回 A 线流式回复。
这样连续问诊和双轨演示分开了。/v1/dual 继续保留，用来展示 A/B 同时输出；新的 chat/stream 路径服务真实一点的多轮体验。
为什么选 SSE
这里没有用 WebSocket。不是 WebSocket 不好，而是当前需求用不上双向实时通信。
A 线只需要服务端把文本一点点推给浏览器。SSE 足够简单，FastAPI 支持也顺，调试时 curl 都能看。反向代理层面也比 WebSocket 少一些坑。
这个选择很像前面几轮的原则：先解决当前问题，不提前把系统做重。
多轮上下文开始重要了
加了消息读取接口以后，前端可以恢复历史消息，后端也能基于最近几轮继续追问。
这里仍然只是 demo 级会话，不是病历系统，也不是账号体系。它的目标是让问诊状态能连起来：上一轮问了什么，用户补了什么，下一轮还缺什么。
B 线问题还没完全解决
v1.1 解决的是 A 线体验，B 线仍然偏同步。
这其实暴露了下一步：报告不应该每轮都生成。用户还在补信息时，A 线继续聊就行；B 线更适合低频、异步地产出版本。
所以 v1.1 更像过渡版本。它让 A 线终于像对话了，也保留了 /v1/dual 作为教学对比。真正的 A/B 解耦，要留到 v1.2。