AI 会话不该反复搬运历史：为什么需要 DASP

messages 数组正在变成客户端的隐性负担

传统无状态接口把上下文所有权交给客户端：每轮请求都要重新拼装并提交历史消息。短对话时这很直接，但一旦进入长对话、工具调用、文件分析和多端续写，客户端就必须同时承担上下文裁剪、并发控制、失败恢复与历史一致性。

真正的问题不只是多传了一些 Token，而是每个客户端都在重复实现一套并不属于产品界面的会话基础设施。Web、移动端、桌面端和第三方集成很容易形成不同的状态版本。

• 刷新或断线后，客户端难以判断在途输出应该恢复还是重新生成。
• 多个设备同时续写时，消息顺序与并发冲突缺少统一裁决。
• 编辑、打断和删除往往退化为各客户端自己的约定。
• 模型切换、上下文压缩与故障转移会直接泄漏到产品代码。

DASP 是什么

DASP 的全称是 Durable AI Session Protocol，即持久 AI 会话协议。它是一套厂商中立的服务端托管会话契约：服务端生成 sid，并负责 sid 背后的真实上下文、历史、流式事件和完整生命周期。

客户端第一次请求不传 sid，收到服务端返回的 sid 后保存它；后续每轮只提交这个 sid、新输入和模型配置。模型、存储、压缩与故障转移策略可以持续演进，而客户端契约保持稳定。

POST /v1/session/responses
sid: <server-generated-guid>
input: only the new turn

持久流式输出，解决的是可靠性而非动画效果

很多接口把流式输出理解成一次临时网络连接。连接中断，结果也随之丢失；客户端只能重试整次生成，既可能重复计费，也可能得到不同答案。

DASP 要求输出先进入可恢复的服务端状态，再交付给客户端。页面刷新、网络切换或进程重启后，客户端可以凭 sid 读取已经产生的事件，而不是再次调用模型。对于耗时 Agent、代码生成和文件处理，这种语义比单纯的 SSE 连接更重要。

会话需要明确的生命周期操作

真实产品不会只有“发送”和“完成”。用户会中途补充条件、取消错误任务、编辑上一轮问题，也会要求删除整个会话。DASP 把这些动作定义为协议能力，并为并发与终态提供确定语义。

• interrupt：原子地打断当前输出并追加新输入。
• cancel：停止当前生成，但保留可审计的会话历史。
• edit：修改最近用户轮次，并裁剪由旧输入产生的后续内容。
• delete：显式删除会话；删除与取消具有不同语义。

什么时候应该选择 DASP

协议选型只需要回答一个问题：谁应该持有对话状态？如果产品需要连续会话、跨端恢复、长任务、工具、文件或可编辑历史，服务端托管通常是更稳定的默认选择。一次性生成或已经自行持有完整状态的系统，仍然可以使用无状态 Responses API。

DASP 并不是为了替代所有 AI 接口，而是为会话型产品提供一个缺失已久的、可移植的状态边界。

把复杂度收回服务端，产品团队才能专注于体验

采用 DASP 后，客户端只需保存 sid、提交新增输入并渲染类型化事件。上下文窗口、消息投影、压缩、持久化、恢复与故障转移都由统一运行时处理。

这不仅减少代码量，也让不同客户端共享同一份会话事实。团队可以在不升级每个客户端的情况下改进模型路由和可靠性，让 AI 产品从“能对话”走向“可持续运行”。