OpenAI Responses API 怎么把工具调用结果串成多轮任务

把 Responses API 接入订单、库存或内部查询时，真正容易出错的不是工具定义，而是第二轮请求没有把“哪一次调用的结果”交还给模型。稳定做法只有一条：读取 response.output 里的 function_call，按 name 执行本地函数，再用同一个 call_id 生成 function_call_output。需要继续对话时，可以用 previous_response_id 接上响应链；但 tools 和 instructions 仍应在下一轮明确提供。

先把一次工具调用拆成三类状态

以“查询订单后再给出处理建议”为例，模型先返回调用名和参数，应用执行数据库或业务服务，最后再把结果交回模型。这里至少要保存三类状态：模型请求的 arguments、用于关联的 call_id、以及可供模型继续判断的业务结果。不要只把结果拼成一段普通用户文本，否则下一轮缺少工具调用上下文。

import json
from openai import OpenAI

client = OpenAI()

# 工具参数只描述模型需要决定的字段，业务权限仍由本地代码控制
tools = [{
    "type": "function",
    "name": "lookup_order",
    "description": "查询订单当前状态和可执行的下一步",
    "parameters": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
        "additionalProperties": False,
    },
}]

# 首轮只负责让模型判断是否需要工具
response = client.responses.create(
    model="gpt-5",
    instructions="只能根据工具返回的订单事实回答，不要猜测状态。",
    tools=tools,
    input="帮我查订单 A-1024，并说明下一步。",
)

tool_outputs = []
for item in response.output:
    if item.type != "function_call":
        continue

    args = json.loads(item.arguments)
    # 生产代码应在这里校验订单格式、租户和访问权限
    result = lookup_order(args["order_id"])
    tool_outputs.append({
        "type": "function_call_output",
        "call_id": item.call_id,  # 必须回填模型给出的同一标识
        "output": json.dumps(result, ensure_ascii=False),
    })

一个响应可能含有多个函数调用，所以应遍历整个 response.output，而不是只取第一个。工具异常也建议返回结构化结果，例如 {"ok": false, "code": "ORDER_NOT_FOUND"}，让模型决定如何向用户解释；不要把数据库异常堆栈直接暴露给模型。

用 previous_response_id 把下一轮继续接上

拿到工具结果后，下一次请求需要让模型同时看到上一轮响应和本轮工具输出。短链路可以使用 previous_response_id=response.id，并把工具结果作为新的 input 传入：

# 用上一轮 response.id 续接，但仍显式声明工具和行为约束
follow_up = client.responses.create(
    model="gpt-5",
    previous_response_id=response.id,
    instructions="只用工具结果回答；如果结果失败，给出可操作的排查建议。",
    tools=tools,
    input=tool_outputs,
)

print(follow_up.output_text)

这里有两个常见误解。第一，previous_response_id 是响应链的指针，不等于你自己的会话数据库；需要跨租户审计时仍要落库。第二，官方文档明确提醒，使用它时上一轮的 instructions 不会自动带到下一轮，因此每一轮都要把关键约束写清楚。

多轮循环里，参数和错误要各自负责

如果模型在收到订单结果后还需要查询物流，应用会再次得到新的 function_call。因此不要把流程硬编码成“最多两次请求”，而是用有上限的循环：每轮处理所有调用，达到上限就返回人工接管或明确失败。参数 JSON 解析失败、未知工具名、业务超时，都应该在应用侧记录并转成稳定的错误对象。

工具数量也不宜一次暴露过多。先提供当前任务真正需要的函数，既减少输入上下文，也让模型更容易选对工具。对于需要人工确认的写操作，工具函数先返回“待确认”状态，把真正提交动作放到确认后的独立接口。

什么时候保存 previous_response_id，什么时候保存完整历史

只做一次查询和一次解释时，保存最后一个 response.id 就够轻量；要支持重放、问题定位、跨服务恢复或合规审计，则应保存每轮输入、响应摘要、调用参数、工具输出和错误码。自己维护 input 历史时，要把上一轮响应中的相关输出项与工具结果一起纳入下一次请求，不能只保存最终文本。

• 短任务：previous_response_id + 每轮重复的 tools 与 instructions。
• 可恢复任务：自管事件表，按 response_id、call_id 和业务请求号建立关联。
• 高风险写操作：工具返回待确认状态，确认事件与真正执行事件分开记录。

常见问题

为什么回传工具结果后模型仍然重复调用？

优先检查 call_id 是否与对应的 function_call 完全一致，以及下一轮是否仍提供了同一工具定义和清晰的完成条件。

多个 function_call 可以只回传一个吗？

不建议。遍历本轮全部调用并逐个回传；漏掉其中一个时，模型可能一直等待缺失结果。

工具结果应该返回字符串还是 JSON？

两者都可以，关键是稳定、短小且可解释。订单状态、错误码和下一步建议适合用 JSON，便于应用日志与模型理解保持一致。