AI 网关怎样避免流式请求串线：request_id、连接复用与日志关联

AI 网关一旦同时承载多路流式回答转发，最难排查的故障通常不是模型返回 500，而是 A 用户的输出片段意外出现在 B 用户的页面里。现场日志看起来每个请求都“收到了 token”，前端也没有明显报错，直到有人发现回答中间突然切换了完全无关的另一个问题的上下文。

这类串线一般不是模型生成错了，而是网关在异步转发、连接复用或日志落盘时丢失了请求身份。比较稳的做法是把 request_id 设为一等字段，从入口生成或校验，沿着上游连接、事件队列、SSE 写出和最终日志一路传递；任何没有身份的事件都拒绝进入客户端。

先把“一个请求”定义成完整边界

很多网关只在入口日志中打印一次请求编号，进入流式处理后就靠 goroutine、Promise 或连接对象隐含传递上下文。这样做的问题是：连接对象可能来自池，事件对象可能进入共享队列，最终日志又被多个异步回调同时写入。只要其中一层没有携带身份，排查就会变成毫无方向的猜测。

conversation_id 不能代替 request_id。同一个会话可能同时发起重试、停止旧回答和提交新问题，三条流必须能被单独取消和验收。入口如果收到客户端自带的编号，也要限制长度和字符集，避免把日志控制字符或过长内容带进链路；更稳妥的方式是生成网关自己的编号，把客户端编号作为单独字段保存。

连接复用时，哪些状态绝对不能共享

连接池复用的是底层网络资源，不是一次请求的业务状态。可以复用 HTTP/TCP 连接、TLS 会话或客户端连接池，但下面这些对象必须在每个请求开始时新建，在终态到达后释放：

• 事件缓冲区：只接受当前 request_id 的事件。
• 取消信号：停止 A 请求不能触发 B 请求的取消。
• 序号计数器：每条流从 0 或 1 开始，不能沿用池中上一次的值。
• 完成标记：completed、cancelled 和 failed 只能命中一个终态。

一个常见错误是把这些字段放在“上游连接包装对象”里，然后把包装对象放回连接池。下一次请求拿到它时，旧的 event_seq 和旧的取消标记仍然存在。修复方法不是在借出连接时清空几个字段，而是把请求状态单独建模，让连接对象只保存传输层能力。

type StreamContext struct {
    RequestID string
    UpstreamID string
    EventSeq uint64
    Done atomic.Bool
    Cancel context.CancelFunc
}

func acceptEvent(ctx *StreamContext, event Event) error {
    if event.RequestID != ctx.RequestID {
        return fmt.Errorf("request_id mismatch: got=%s want=%s", event.RequestID, ctx.RequestID)
    }
    if event.Seq != ctx.EventSeq+1 {
        return fmt.Errorf("event sequence gap: got=%d want=%d", event.Seq, ctx.EventSeq+1)
    }
    ctx.EventSeq = event.Seq
    return nil
}

这里的序号检查不是为了替代重连机制，而是为了尽早暴露“事件属于谁”和“事件顺序是否连续”这两个问题。发现身份不匹配时，宁可让当前请求失败，也不要把不确定的片段继续写给用户。

用状态机收口流式事件

流式处理至少会遇到增量片段、上游完成、客户端取消、上游错误和网关超时。若每个回调都可以直接关闭响应，多个回调同时到达时就可能重复写尾部、重复记账，甚至把另一个请求的缓冲区冲刷出来。

可以把状态限制为 open、closing 和一个终态。事件处理器先校验 request_id，再通过原子状态转移决定是否继续写出：

前端看到“回答结束”不代表所有后台资源已经回收。网关仍要关闭上游读取、从事件路由表删除 request_id，并清理超时定时器。清理动作可以重复调用，但状态结算和用量记账必须幂等。

日志关联要能还原一条完整流

只打印“收到 token”没有定位价值。建议至少在入口、借出上游连接、收到事件、写出客户端、终态收口五个位置打印同一个 request_id，同时带上 upstream_id、event_seq、状态和耗时。日志字段要保持结构化，否则并发时依靠字符串搜索很容易漏掉一半。

{
  "request_id": "gw_01J8K3",
  "upstream_id": "up_42",
  "event": "delta",
  "event_seq": 17,
  "state": "open",
  "bytes": 126,
  "elapsed_ms": 842
}

排查串线时先按 request_id 排序，再检查三件事：序号是否从头到尾连续、所有日志的 upstream_id 是否一致、终态之后是否还有写出记录。如果一个请求的序号突然跳变，同时另一个请求出现相同片段，优先查事件队列的键和回调闭包捕获变量，不要先怀疑模型。

并发验收：故意制造交错片段

单请求测试很难发现串线。测试桩应让两个请求以明显不同的节奏返回，例如 A 每 20 毫秒发送 A-01、A-02，B 每 35 毫秒发送 B-01、B-02，再随机延迟完成和取消。验收不是看最终文本是否“差不多”，而是逐事件检查：

• 客户端收到的每个片段都带有正确的 request_id。
• 同一请求的 event_seq 单调递增且无重复。
• A 的终态不会关闭 B 的响应，B 取消不会改变 A 的状态。
• 所有请求的连接、定时器、事件路由表在终态后都归零。

压测时把连接池大小、并发数、取消比例和上游片段间隔记录下来。否则一次“没有复现”只能说明这组时序没撞上问题，不能说明共享状态已经安全。

相关问题：常见误区与判断边界

request_id 应该由客户端传入吗？

可以接收客户端关联号，但网关应生成自己的唯一主键并做长度、字符集和冲突校验。日志、状态机和上游路由优先使用网关编号，客户端编号只作为辅助关联字段。

HTTP 连接复用会直接导致回答串线吗？

底层连接复用本身不等于业务数据复用。真正危险的是把请求级缓冲区、取消信号、序号或回调上下文挂在可复用连接对象上，导致下一次借用时残留旧状态。

发现一个事件身份不匹配时，能不能只丢掉这一个片段？

如果无法证明后续事件仍然属于当前请求，应该终止当前流并记录证据。静默丢一个片段可能让回答看似继续，却把更严重的路由污染隐藏起来。

上线前的流式网关检查清单

• 入口是否生成并校验独立的 request_id，且与 conversation_id 分开。
• 连接池借出和归还时，事件队列、取消信号、序号和完成标记是否属于请求上下文。
• 每个事件是否检查身份、序号和当前状态，重复终态是否幂等处理。
• 日志能否按请求编号还原入口、上游、事件、写出和收口全过程。
• 并发交错、随机取消、超时和连接复用测试是否覆盖了不同事件时序。

AI 网关的流式串线，本质上是请求身份没有跟着数据一起流动。把身份、状态和清理边界拆开后，连接可以继续复用，异步处理也可以继续扩展，但任何一段事件都不能脱离自己的 request_id。