octop通过sse协议实现web ui流式返回，后端用streamingresponse输出符合text/event-stream规范的数据，前端用eventsource消费；支持多专家并行隔离、结构化事件状态反馈及异常恢复。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Octop 实现 Web UI 的流式返回，核心不是靠自研渲染引擎，而是基于标准 HTTP 流式协议（text/event-stream）与前端事件驱动机制协同完成。它本身作为后端 Agent 运行平台，把流式能力“下沉”到通信层和响应构造环节，前端只需按 SSE 规范消费即可。
后端响应必须满足 SSE 格式规范
Octop 的 API 接口（如 /v1/chat/completions）在启用流式时，会返回 Content-Type: text/event-stream，每条数据以 data: 开头、双换行结束。例如：
data: {"id":"chat-xxx","delta":{"content":"今"},"finish_reason":null}data: {"id":"chat-xxx","delta":{"content":"天"},"finish_reason":null}data: {"id":"chat-xxx","delta":{"content":""},"finish_reason":"stop"}-
\n\n（严格两个换行符）
Octop 内部使用 FastAPI 或类似异步框架，通过 StreamingResponse 包裹生成器函数，确保响应不被中间件或反向代理（如 Nginx）缓冲。关键 header 必须包含：
Cache-Control: no-cache-
X-Accel-Buffering: no（专治 Nginx 缓冲） Connection: keep-alive
前端用 EventSource 原生支持流式消费
Octop 的 Web UI 默认采用 EventSource API 接收流，而非手动轮询或 WebSocket（除非用于多模态或长连接控制信道）。这种方式轻量、兼容性好、自动重连：
- 创建
new EventSource(url, { withCredentials: true })，自动携带 cookie 或 token - 监听
message事件，解析event.data中的 JSON 字符串 - 逐字追加到 DOM 元素（如
<div id="output"></div>），调用element.innerHTML += text或更安全的textContent拼接 - 遇到
error事件时，检查状态码并触发重试逻辑（Octop 前端内置退避重连）
多专家并行场景下流式需隔离上下文
当用户同时调用多个专家（如 @代码审校 + @营养师），Octop 不共用一个 SSE 连接。每个专家请求走独立的 EventSource 实例，响应中携带 event: expert_response 类型标识，并附带 expert_id 字段。前端据此路由到对应消息区块，避免内容错位。
这种设计也支撑了 Octop 的“多任务并行”特性：不同专家的 token 可交错到达，但前端按 id 和 expert_id 分组累积、渲染，保持语义完整性。
流式异常与中断恢复有明确状态标记
Octop 的流式响应不是裸 token 流，而是在关键节点插入结构化事件：
-
event: start表示推理启动，可触发 loading 动画 -
event: tool_call表示即将调用工具，携带参数快照，前端可展示“正在查询文档…” -
event: finish携带完整响应元信息（耗时、token 数、是否截断） -
event: error显式传递错误类型（如tool_timeout、context_overflow），便于前端精准提示
这些事件类型让 UI 不仅能“显示文字”，还能同步反馈执行状态，真正实现智能体级别的交互感。
