1. 接口函数签名设计 // Provider 返回一个只读通道，以及立即可能会发生的前置错误 GenerateStream(ctx context.Context, messages []schema.Message, tools []schema.ToolDefinition) (<-chan schema.StreamEvent, error) // 流事件包装结构体 type StreamEvent struct { ContentDelta string // 文本增量碎片 ToolCallDeltas []ToolCallChunk // 工具调用的增量碎片 Error error // 传输过程中的异常 } 2. 在主循环（或者专门负责消费流的函数）中，做三件事：监听打印、增量拼接和还原结构。 a. 在 Provider 的具体实现中启动一个 Goroutine 去持续读取 SSE (Server-Sent Events) 并向 Channel 发送数据，读完后 close(channel) b. 在 Main Loop 端，利用 for event := range ch 阻塞式地遍历通道数据。只要遇到 ContentDelta 有值，立刻 fmt.Print(event.ContentDelta) 输出到终端，形成打字机效果。如果遇到 event.Error 则中断抛出。 c. 使用 strings.Builder 将打印过的文本同步追加进去。声明一个 map[int]*ToolCall 作为缓冲区。针对收到的 ToolCallDeltas，利用它们的序号（Index）作为 key，把零碎的 ID、Name、和一部分一部分吐出的 Arguments JSON 字符串持续追加合并。当 Channel 被关闭 for range 退出后，遍历缓冲好的 Builder 和 map，拼装出一个包含着完整参数和全文本的最终 *schema.Message 供下一轮作为上下文。 疑问： 对于 ToolCall 参数的解析，我是“利用序号作为 key 持续追加合并，当 Channel 关闭后统一拼装反序列化”。但大模型在输出复杂的工具调用参数时经常会“抽风”（比如少闭合一个括号，或是产生了幻觉输出了非 JSON 文本）。如果让用户苦等了几十秒的打字机输出，直到最后一刻（Channel 关闭）才去反序列化并抛出 JSON 解析错误，无论是用户体验还是 API Token 成本都是极大的浪费。 针对工具参数的流式生成，需要做到什么颗粒度的校验？还是傻等到全部输出完毕再校验？