AI 请求与任务流程

AI 请求并不都适合采用同一种处理方式。文本对话通常需要尽快输出首段内容，而绘图、视频或复杂工作流更适合创建异步任务。

流式对话

sequenceDiagram
  participant U as 用户端
  participant A as 业务 API
  participant B as 计费与权限
  participant M as 模型适配器
  participant P as 模型服务

  U->>A: 提交消息和会话编号
  A->>B: 校验身份、套餐和额度
  B-->>A: 允许调用并预占额度
  A->>M: 统一聊天请求
  M->>P: 转换为服务商协议
  P-->>M: 流式内容
  M-->>A: 标准化内容片段
  A-->>U: 持续推送输出
  A->>B: 按实际用量结算

对话链路需要特别处理客户端中断、上游超时和部分输出。已经产生的内容应被保存，预占额度则按实际结果结算，避免重复扣费。

异步生成

异步任务使用一组可追踪的状态推进：

1. pending：平台已创建任务，等待 Worker 获取；
2. running：Worker 已开始请求模型服务；
3. waiting：模型服务已接收，需要等待回调或轮询；
4. retry：发生临时错误，尚未超过重试上限；
5. succeeded：结果已保存并可供客户端读取；
6. failed：超过重试上限或发生不可恢复错误。

任务表至少要记录业务任务编号、用户、模型、输入摘要、状态、远端任务编号、重试次数、错误原因与结果地址。客户端根据平台任务编号查询，不直接依赖服务商编号。

一次调用的检查顺序

1. 校验登录状态和业务参数；
2. 确认模型在当前场景、租户和客户端可用；
3. 检查套餐、余额或剩余额度；
4. 生成幂等键，防止重复提交；
5. 预占额度并创建调用记录；
6. 执行同步调用或投递异步任务；
7. 保存结果并结算实际消耗；
8. 失败时释放预占额度，并记录可排查的错误信息。

可靠性要点

• 对同一业务操作使用幂等键，避免网络重试生成两份结果；
• 区分“模型拒绝”“额度不足”“上游超时”和“系统异常”；
• 为不同模型配置独立超时、并发和重试策略；
• 日志记录平台任务编号，不记录完整密钥或敏感提示词；
• 对异步回调进行签名校验，并允许回调重复到达。