用户点下“开始分析”界面转了 30 秒没有结果也不知道系统在做什么。有人刷新页面任务消失有人点了 Stop前端停了后台模型却还在跑还有人重新进入页面只能从头再来。这些问题看起来分散加载状态、WebSocket、SSE、后台任务、断线恢复、请求取消。其实都指向同一个核心当 AI 任务从“一次请求一次响应”变成长时间执行时产品必须把它当成一个有生命周期的任务而不是一条还没返回的 HTTP 请求。30 秒等待界面最怕“假死”如果一个 Tool 可能执行 30 秒界面不应该只放一个无限旋转的 loading。用户真正想知道三件事系统是否还活着、现在进行到哪一步、我还能做什么。更合理的界面可以把执行拆成阶段正在准备、正在调用工具、正在处理结果、正在生成回答。能拿到真实进度就显示真实进度拿不到就显示阶段不要虚构“73%”。同时保留已完成步骤例如“已读取文件”“已查询数据库”“正在生成总结”。这类反馈不一定让任务更快却能减少用户对卡死的判断。还要给用户控制权Stop、离开页面继续执行或者后台运行后再回来查看。长任务最差的体验不是慢而是慢且不可判断。WebSocket 和 SSE不要按“谁更先进”来选很多团队把 WebSocket 当成实时系统的默认答案其实 AI 场景里SSE 往往已经够用。如果数据主要是服务端持续推给前端比如模型 token、工具状态、日志和阶段事件SSE 很合适。它基于 HTTP浏览器支持也成熟断线重连和基础设施兼容相对直接。WebSocket 更适合高频、双向、持续交互。比如前端不断发送语音流、多人协同编辑、实时控制设备客户端和服务端都在频繁交换消息。AI Agent 的典型页面通常是“用户发起一次任务服务端持续回传状态”。这种情况下SSE 更简单。Stop 也不需要依赖同一条长连接可以单独调用取消接口。选择标准不是“实时不实时”而是通信是否真的需要长期双向。用户关掉页面任务要不要继续这个问题不能由前端连接决定而要由产品语义决定。如果任务只是“帮我改写一句话”页面关闭后继续跑通常没有价值。连接断开后取消可以节省模型和工具成本。如果任务是“分析 20 个文件并生成报告”用户关闭标签页不应该意味着任务作废。更合理的做法是前端只负责创建任务后端把任务交给独立 worker 执行。浏览器连接可以断任务仍有自己的 task_id、状态和结果。关键是把“连接生命周期”和“任务生命周期”拆开。只要后台任务依附于某个 HTTP 请求或 WebSocket 进程断线、重启、扩容都会变得麻烦。重新进入页面恢复的不是动画而是状态任务持久化以后恢复进度就自然了。创建任务时服务端返回 task_id。后端记录状态例如 queued、running、completed、failed、cancelled并保存阶段、输出和必要的事件日志。用户重新进入页面时不需要“找回原来的 SSE 连接”。只要根据 task_id 查询当前状态再重新订阅后续事件。如果任务已完成就直接返回结果如果还在执行就展示当前阶段并继续接收更新如果失败告诉用户失败在哪里以及是否允许重试。这里最容易犯的错是把前端内存当成唯一状态源。页面一刷新组件 state 全没了。真正可恢复的状态必须在服务端。用户点 Stop必须真的停Stop 不能只是把 loading 隐藏掉。比较稳妥的做法是给任务维护 cancellation token 或取消状态。用户点击 Stop 后前端调用取消接口服务端把任务标记为 cancelling并尝试终止正在进行的模型请求、Tool 调用或后续步骤。如果模型服务支持取消流或中止请求应主动 abort如果某个外部 Tool 无法中途取消也至少要阻止后续步骤继续执行并把最终状态记为 cancelled。还要接受一个现实取消通常不是瞬时的。比如数据库查询已经发出、第三方 API 不支持终止系统只能“尽快停止”而不是保证所有计算立刻消失。因此界面最好区分“正在停止”和“已停止”。这比用户点一下按钮界面马上装作什么都结束了更可信。把一次请求升级成一项任务这五个问题放在一起答案其实很统一不要围着某一条连接设计长任务而要围着 task_id 设计任务系统。前端负责发起、展示和控制SSE 或 WebSocket 负责传递实时事件后端任务系统负责持久化状态模型和 Tool 执行层负责响应取消结果存储负责断线后的恢复。如果你正在做 AI Agent、代码生成、深度搜索或文件分析最值得先补的不是更漂亮的 loading而是任务状态机。只要任务有明确的创建、执行、完成、失败、取消和恢复路径30 秒等待就不再是一段不可控的空白而会变成用户可以理解、离开、返回和终止的过程。