SSE、WebSocket 还是 DASP：持久 AI 会话不是一种传输协议

SSE、WebSocket 还是 DASP：持久 AI 会话不是一种传输协议

做 AI 对话时，团队常把三个问题混在一起：如何实时收到 Token、如何保持网络连接、如何在刷新或断网后继续同一会话。SSE 和 WebSocket 主要解决数据怎样在网络上传输，DASP 解决的则是会话状态、历史、在途响应和恢复语义。把传输方式当成会话协议，往往会得到一个“连接不断就能用，连接一断就失忆”的产品。

SSE 适合服务端持续输出

SSE 基于 HTTP，服务端可以连续发送类型化事件，浏览器接入简单，也容易穿过常见代理。文本生成大多是服务器向客户端单向推送，因此 SSE 往往已经足够。它不保证业务状态自动持久化，也不替应用定义一次响应何时完成、断线后从哪里继续。

WebSocket 解决双向长连接

WebSocket 适合双方都要高频主动发送数据的场景，例如实时语音、协同编辑和低延迟控制。代价是连接生命周期、心跳、负载均衡、断线重连与网关兼容都需要额外设计。连接本身也不是身份，更不是持久会话。

DASP 定义的是会话事实

DASP/1.0 使用 sid 定位持续 AI 会话。首次创建时客户端不发送 sid，由服务端生成并在响应头返回；续写、查询、恢复、取消和编辑时再携带同一 sid。sid 类似订单号，只负责定位，不能代替 API Key、用户身份或租户授权。

协议还定义 History、上下文、Response、类型化事件、分页 Cursor、错误和状态变化。客户端因此知道哪些内容已经成为会话事实，哪些仍在生成，取消后应期待什么结果，以及未知 Item 或事件该如何向前兼容。

恢复不是把整段文本再发一遍

可靠恢复需要稳定事件序号或 Cursor。客户端保存最后确认的位置，重连后请求后续事件；服务端从持久记录回放缺失部分，再接上仍在运行的输出。重复收到事件时按标识去重，而不是按文本内容猜测。

Cursor 可能因保留期、压缩或版本变化失效。此时服务端应返回明确错误，客户端退回 History 或完整 Response 快照重新建立本地状态。不能悄悄从头播放，否则界面会重复追加，工具动作也可能被误执行两次。

传输与语义可以自由组合

DASP 可以在创建或续写时使用普通 HTTP，在生成阶段用 SSE 输出事件，也可以在语音等场景通过 WebSocket 承载同样的会话标识与事件语义。关键不是选出唯一传输，而是让不同传输映射到同一个服务端事实模型。

客户端状态机比连接状态更重要

界面至少要区分 idle、submitting、streaming、reconnecting、completed、cancelled 和 failed。网络断开不等于模型失败，HTTP 超时也不代表服务端停止执行。重试前先查询会话或 Response 状态，使用幂等键避免重复提交。

AnyAIS 为什么推广 DASP

AnyAIS 同时承载文本、工具、Agent 与长任务，单纯保持一条流式连接无法覆盖刷新、跨设备、人工接管和异步恢复。DASP 把这些能力收敛为公开会话契约，让客户端只保存 sid 和必要 Cursor，复杂状态由服务端统一管理。

选择 SSE 还是 WebSocket，应由实时方向、网络环境和运维能力决定；选择 DASP，则是在决定产品是否拥有可恢复、可续写、可审计的会话语义。两者不是竞争关系，而是不同层次的工程选择。

参考资料

• [DASP/1.0 API 参考](https://www.anyais.com/dasp/reference)
• [DASP 协议语义与约束](https://www.anyais.com/dasp/protocol)
• [DASP 客户端接入指南](https://www.anyais.com/dasp/client)

如果你正在接入 AnyAIS，可以先用 HTTP 与 SSE 完成基础体验，再按 DASP 状态机实现 sid 保存、断线恢复、去重和取消。