AI 多轮工具调用为什么丢上下文：tool_call_id、并行结果与回合配对

做多轮AI工具调用开发的时候，最头疼的不是工具本身抛错，是跑第二轮的时候模型直接像失忆了一样：要么反复调用同一个工具，要么接口直接返回工具结果缺失的报错。绝大多数场景下，问题根源都出在消息回放阶段没保留原始 tool_call_id，并行工具的返回结果还按响应时间瞎写回上下文，没做正确的配对绑定。

先确认丢的是哪一段上下文

碰到模型重复调用相同工具的现象，先把完整交互回合拆成四段：用户输入、模型发起的工具调用、工具返回结果、下一次给模型的输入。如果第二次发起请求的时候上一条工具调用记录直接没了，属于消息回放漏传；如果有调用记录但找不到对应结果，就是配对逻辑或者落库环节出了问题；如果结果已经存在模型还在重复调用，再去检查工具返回的内容和模型本身的终止判定规则。

把 tool_call_id 当成数据库主键用

别用“第一个调用的工具”“第二个调用的工具”这种位置语义来存返回结果。模型单次响应完全可能发起多个工具调用，中间的网关层也有可能改动返回数组的顺序。收到模型的工具调用响应后，先建好调用记录，再用对应的唯一标识写入后续的返回结果。

type CallRecord struct {
    ID string
    Name string
    Args json.RawMessage
    Status string
}

calls := map[string]*CallRecord{}
for _, call := range modelMessage.ToolCalls {
    calls[call.ID] = &CallRecord{ID: call.ID, Name: call.Name, Args: call.Arguments, Status: "pending"}
}

for result := range runTools(calls) {
    call, ok := calls[result.CallID]
    if !ok { return fmt.Errorf("unknown tool_call_id: %s", result.CallID) }
    call.Status = result.Status
}

工具名可以重复，传入的参数也可能高度相似，唯一能把单次调用和单次返回结果精准绑定的，就是同一轮生成的调用标识。

并行工具返回要按标识回填

并行执行多个工具的时候，搜索类服务可能先返回结果，库存类的慢接口可能后返回结果。回放构造上下文的时候，要完全保留模型原始返回的工具调用顺序，再把拿到的结果按 tool_call_id 放回对应的位置。别直接把接口的完成顺序当成上下文里的元素顺序。

orderedResults := make([]ToolResult, 0, len(modelMessage.ToolCalls))
for _, call := range modelMessage.ToolCalls {
    result, ok := resultsByID[call.ID]
    if !ok { return fmt.Errorf("missing result for %s", call.ID) }
    orderedResults = append(orderedResults, result)
}

如果业务允许部分调用失败，可以直接把失败状态编码成该调用对应的工具结果，让模型明确知道这次调用已经走完流程；别偷偷把失败的调用项从上下文里删掉，不然下一轮模型可能会把“没有返回结果”误判成“还没发起调用”，直接重复请求。

重试边界要和副作用逻辑分开处理

纯读取类的工具接口一般可以安全重试，但写入订单、发送通知、扣减库存这类操作必须配套幂等键机制。网络超时只能说明客户端没收到服务端的确认响应，不能判定服务端没有实际执行完调用。发起重试前可以先查询对应业务键的执行记录，或者让工具服务端用数据库唯一约束直接拦截重复写入的请求。

func invokeWithKey(ctx context.Context, call CallRecord, key string) (ToolResult, error) {
    if saved, ok := loadResult(key); ok { return saved, nil }
    result, err := invoke(ctx, call.Args, key)
    if err != nil { return ToolResult{}, err }
    return saveOnce(key, result)
}

链路日志里至少要存请求标识、回合号、tool_call_id、工具名、幂等键和当前状态。如果调用参数里包含用户隐私信息，只需要保留脱敏后的摘要，不要把核心的调用标识字段省略掉。

上线前用五组回放样本做验收

• 单工具成功场景：确认下一轮输入同时包含完整的调用消息和对应的工具结果。
• 两个工具并行成功场景：故意让后发起的调用先返回，确认回放逻辑仍然能按调用标识完成正确配对。
• 单个工具调用失败场景：确认失败结果仍然能正常终结该次调用，不会触发无条件重复调用逻辑。
• 网络超时后重试场景：确认幂等键不会产生第二次真实的业务副作用。
• 服务重启后续接场景：从持久化消息里恢复一整轮交互，确认 tool_call_id 没有被重新生成。

相关问题

tool_call_id 可以由客户端重新生成吗？

不建议这么做。续接历史回合的时候要原样保留原有标识，只有发起全新的一轮工具调用时才可以生成新的标识。

为什么工具名相同也不能用工具名配对？

同一轮交互完全可能并行调用同一个工具两次，工具名只能标识对应的能力，没法区分某一次具体的调用操作。

工具失败后应该让模型自动重试还是直接抛错中断？

读取超时场景可以配置有限次数的自动重试；碰到权限不足、参数非法、业务冲突这类错误，要把明确的错误信息直接交给模型或者前端用户，避免进入无效循环。

结语

多轮工具调用的上下文不是一段拼接起来的普通文本，而是一组带唯一身份标记的事件流。保留所有原始消息、按 tool_call_id 完成配对、靠业务键控制重试逻辑，再用完整的回放样本做上线验收，之前碰到的重复调用和结果串台这类偶发问题，就能变成完全可定位的状态异常。