React Native AI 聊天：流式回复、断线重试与扣次

消息显示状态与服务端操作状态分开

页面可能正在加载、展示片段或离线，服务端却仍在继续生成。界面要解释未知状态，而非把所有网络错误都当作生成失败。

断线恢复应该做什么

1. 客户端保留待回复消息对应的操作编号。
2. 重新连接时向服务端查询原操作。
3. 若已完成，读取保存答案和既有用量回执。
4. 若仍在运行，按支持的传输方式恢复或查询，不新建第二个操作。
5. 明确失败后，再提供约定的重试；区分新尝试与重复投递。

SSE、fetch 流或其他方式取决于原生运行环境、所选库和生命周期要求，需要在目标构建上分别验证两个平台。桌面浏览器流式示例不能证明移动端断线恢复正常。

停止显示不一定停止模型成本

Stop 按钮究竟是隐藏回复、请求取消还是结束操作，需要明确。取消到达提供方之前可能已经产生 token；模型账单与用户的 App 次数是两种不同计费单位。

对部分结果、取消和断线后完成分别定义用户规则。如果只对完整保存答案扣次，取消或部分回复就不能暗中变为已完成扣次。取消与完成竞态应在服务端收敛，不能对同一预占同时释放和结算。

上下文绑定正确报告和用户

服务端先验证报告访问权限，再把指定报告版本、有边界的聊天历史和允许使用的当前偏好快照送入上下文。模型凭证留在服务端。除非另有明确必要性与说明，日志避免保存报告正文、健康信息或原始聊天文本。

用户纠正偏好后，下次操作使用新值，不能顺手改写已交付报告。具体纠正和删除边界见可编辑记忆指南。

可放进上线范围的失败验收清单

• 连续点两次发送：只产生预期的一次操作和一次结算。
• 流式回复中断线：重新进入先查询原操作。
• 杀掉并重启 App：能找回已完成答案。
• 提供方在完成前失败：余额符合约定规则。
• 取消与完成同时发生：最终结算只有一种结果。
• 生成期间登录失效：其他用户不能读取之前的答案。
• 两台设备争用最后一次额度：服务端原子预占生效。

AppBento 失败重试示例展示 6 → 6 → 5 的模拟余额。它不是生产恢复系统；实际集成需要确认上述哪些场景必须在客户环境通过。