Agent SSE 可恢复流：后端别把长连接当任务生命周期

Tue, 12 May 2026 00:00:00 +0000

做 Agent 聊天时，最开始很容易把 SSE 当成一条“任务管道”。

用户点发送，后端开一个流，Agent 一边跑一边往这个 HTTP response 里写数据。浏览器断开，就认为用户不需要了，于是顺手把后台任务也取消。

这套在 demo 里很顺。但一到长任务就会暴露问题。

生成视频、跑工作流、调图像模型，可能要几十秒甚至几分钟。用户网络抖一下、页面切后台、代理断一下，SSE 连接断了。但 Agent 任务本身不应该死。

真正要拆开的，是两件事：

Agent run：后台任务生命周期
SSE connection：前端订阅事件的传输连接

连接可以断，可以重连。run 不能因为连接断了就被杀。

架构图

flowchart LR
  FE["Frontend<br/>sendMessage / resumeActiveRun<br/>POST /v1/agent/runs<br/>fetch-event-source 订阅 events<br/>最近 500 个 SSE id 去重"]
  API["Agent API<br/>POST /runs 创建 run<br/>GET /runs/{run_id}/events 订阅<br/>cancel / HITL<br/>active-run 只用于页面恢复"]
  Producer["Background Agent Producer<br/>执行 Agent run<br/>写 Redis Stream 事件<br/>刷新 runner lease<br/>最终历史写 MongoDB"]
  Redis["Redis Runtime Layer<br/>Stream per run<br/>id + event + data<br/>active run state<br/>runner lease TTL"]
  SSE["SSE Events Endpoint<br/>读取 Last-Event-ID header<br/>XREAD Redis Stream<br/>输出标准 SSE<br/>heartbeat comment"]
  Mongo["MongoDB Final History<br/>完整聊天历史<br/>最终一致性持久化"]

  FE -->|"create run / 409 active_run_id"| API
  API -->|"start background task"| Producer
  Producer -->|"XADD event"| Redis
  SSE -->|"XREAD from cursor"| Redis
  FE -.->|"SSE reconnect with Last-Event-ID"| SSE
  SSE -.->|"id / event / data"| FE
  Producer -->|"final messages"| Mongo
  SSE -.->|"closes only on run.completed / run.failed / run.cancelled"| FE

这个图里最重要的箭头不是 SSE，而是 Producer -> Redis。

支付重构里，我最后只信 Redis 那一扣

Tue, 12 May 2026 00:00:00 +0000

这次改支付链路，最开始我想错了一个地方。

我以为问题是“Agent 也要扣费”，所以把 Consumer 里那套工作流扣费逻辑搬过来就行。

后来发现不是。

真正的问题是：一次生成请求，到底在哪一刻算占用了用户余额？

这个问题如果不先回答，代码会很快散掉。LLM 在一个地方扣，tool 在另一个地方扣，工作流节点又有一套预扣。每条路都能跑，但每条路都在暗示不同的账务语义。

最后我接受的原则很简单：

Redis 决定请求能不能继续跑。MongoDB 负责把这次消费写成账本。

也就是先过运行期闸门，再补最终账本。

旧结构哪里开始疼

OpenCreator 原来的重扣费场景主要在 Workflow Consumer。

图片、视频、音频这些节点，通常能在调用模型前算出费用。Consumer 会在 Model Gateway 里先走 CreditBalanceCheckServiceV2.check_for_pre_deduction()，Redis 里扣成功后再调用外部模型。

这个结构放在工作流里是顺的。

节点要调用供应商，供应商可能会产生真实成本。余额不够，就别调用。调用失败，就 rollback。

Agent 接进来以后，事情变得没那么整齐。

Agent 一轮对话里有多次 LLM 调用。LLM token 费用要等 usage 回来才知道。tool 也可能返回 cost_usd，比如搜索工具、渲染工具、媒体分析工具。subagent 还可能继续开一条新的执行链。

如果沿着旧思路，把扣费写在 API handler 或 SSE hook 里，肯定会漏路径。

后来这部分被下沉到了 creato/core/executor.py：

async def _check_balance(self) -> None:
    ctx = get_billing_context()
    if not ctx or not ctx.manager.enabled:
        return
    await ctx.manager.check_balance_or_raise(ctx.user_id)


async def _bill_llm(self, usage: dict[str, int]) -> None:
    ctx = get_billing_context()
    if not ctx or not ctx.manager.enabled or not usage:
        return
    await ctx.manager.bill_llm(ctx.user_id, self.model, usage, ctx.session_id)


async def _bill_tool(self, tool_name: str, cost_usd: float | None) -> None:
    ctx = get_billing_context()
    if not ctx or not ctx.manager.enabled or cost_usd is None:
        return
    await ctx.manager.bill_tool(ctx.user_id, tool_name, cost_usd, ctx.session_id)

这个改动不是单纯挪位置。

Backend on niuzj

Agent SSE 可恢复流：后端别把长连接当任务生命周期

架构图

支付重构里，我最后只信 Redis 那一扣

旧结构哪里开始疼