支付重构里，我最后只信 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)

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

Billing on niuzj

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

旧结构哪里开始疼