AI 对话不该困在一个页面里：DASP 让会话真正可恢复、可续写

流式输出只是表象，状态才是核心

一个演示型聊天页面通常只需保存 messages，然后把整段历史随下一次请求重新提交。它足以展示模型能力，却很难承担真实产品的复杂性：用户刷新页面、手机切到电脑、网络在生成中断开、Agent 连续执行十几个工具，或者用户想修改上一轮问题。只靠浏览器内存和一次 SSE 连接，这些动作都可能变成重复生成、历史错乱或无法解释的费用。

更隐蔽的成本来自多端实现。Web、App、桌面端和第三方集成各自维护上下文裁剪、重试和消息顺序，久而久之，同一个会话会出现多个版本。模型窗口、压缩算法和供应商路由一变化，所有客户端都要跟着升级。

DASP 把会话事实放回服务端

DASP 是 Durable AI Session Protocol，即持久 AI 会话协议。它以服务端生成的 sid 标识会话，客户端首次请求获得 sid，之后只提交 sid 与新增输入。真实历史、模型上下文、压缩结果、流式事件和生命周期状态由服务端统一保存。

这个边界让客户端明显变轻：它只需安全保存 sid、渲染类型化事件，并在网络恢复后读取已有进度。上下文如何裁剪、模型如何切换、存储如何扩展，都可以在服务端演进，而不会破坏产品契约。

断线恢复不应该等于重新收费

普通流式接口断开后，客户端往往只能重新 POST。新的调用可能产生不同答案，也可能造成重复 Token 消耗。DASP 的恢复语义是读取已经持久化的输出事件，不重新执行模型。对于代码生成、文件分析和耗时 Agent，这一差别直接决定了用户是否敢把重要任务交给系统。

会话还拥有明确操作：interrupt 用于打断当前输出并追加新意图；cancel 停止当前生成但保留历史；edit 修改最近用户轮次并裁剪旧分支；delete 则删除整个会话。动作有确定含义，多端产品就不必各自发明约定。

sid 让跨设备体验自然成立

当会话由服务端托管，手机不再需要把完整历史传给电脑。只要在同一认证边界内安全同步 sid，新设备就能读取历史和在途状态。用户可以在通勤时提出任务，到办公室继续查看；网页刷新后也能恢复未完成输出，而不是从头开始。

sid 不是身份凭证，仍需配合 API Key、JWT 或租户授权。正确做法是在切换用户、租户和环境时隔离 sid，并让服务端验证会话归属。

适合哪些产品

若产品包含连续聊天、Copilot、长耗时 Agent、文件任务、跨端续写或可编辑历史，DASP 通常比客户端持有完整 messages 更稳。一次性翻译、短摘要等无状态调用仍可继续使用普通 Responses API，二者并不冲突。

AnyAIS 将 DASP 与统一模型入口、用量、权限和日志放在同一平台。真正的升级不是多一个接口，而是让 AI 会话从临时连接变成可运营、可解释的产品资产。

上线前用故障场景验收

DASP 的价值必须通过故障测试证明。可以在输出过程中刷新页面、切换网络、同时从两台设备读取、连续发送 cancel 与 interrupt，并验证恢复后事件不重复、顺序不颠倒、模型没有再次执行。随后检查 sid 被其他账号使用时是否稳定拒绝，删除后是否无法继续访问。

监控指标也应围绕会话设计：创建成功率、恢复耗时、活跃会话数量、事件积压、取消完成时间和每个 sid 的累计成本。只有把协议语义和运营数据放在一起，持久会话才不是简单存聊天记录，而是能够支撑真实产品承诺的运行能力。