OpenAI Responses API 的 tool call 状态怎样串联

OpenAI Responses API 的 tool call 状态，核心不是把工具返回值拼到一段普通文本里，而是保留一条可追踪的关联：先从 response.output 找到 function_call，再用它的 call_id 创建 function_call_output。需要延续上下文时，再把回传项交给下一次 Responses 请求，或使用 previous_response_id 连接前一条响应。

官方地址：https://developers.openai.com/api/docs/guides/function-calling

最稳妥的做法是把模型产生的调用项、应用执行的结果和下一轮上下文分开保存：模型只提出调用意图，应用负责校验、执行、绑定 call_id 并记录结果。

先把 Responses API 的状态对象分开

这条链上至少有四类状态。用户输入是任务上下文；响应对象提供 id 和 output；output 里的 function_call 表示模型希望应用调用某个工具；function_call_output 则是应用把执行结果交还给模型的输入项。call_id 是中间的关联键，不能用工具名或数组下标代替。

如果使用 previous_response_id，它表达的是“继续哪一个响应上下文”，不是某一次工具调用的替代 ID。两者职责不同：前者连接响应上下文，后者连接具体工具结果。

最容易出错的攻击路径是什么

从安全角度看，function_call.name、arguments 和工具返回值都位于不同信任边界。模型输出不是授权凭证，不能因为参数看起来像内部命令就直接执行；工具返回值也不能被当成系统提示词或管理员指令。

• 关联丢失：回传时缺少正确的 call_id，模型无法把结果对应到原调用。
• 能力越界：只按模型给出的字符串动态查找任意函数，没有白名单和参数约束。
• 上下文丢失：只保存文本，丢掉了工具调用项；对需要保留 reasoning items 的模型尤其危险。
• 重复执行：重试时没有按调用 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,
    },
    "strict": True,
}]

def dispatch_tool(name, arguments):
    # 只允许白名单工具，避免把模型输出当作任意函数名执行。
    if name != "lookup_order":
        raise ValueError(f"unknown tool: {name}")
    # 生产环境还应校验租户、权限、参数长度和订单访问范围。
    return {"order_id": arguments["order_id"], "status": "processing"}

response = client.responses.create(
    model="gpt-5",
    input="查询订单 A-1001 的状态",
    tools=TOOLS,
)

input_items = list(response.output)
for item in response.output:
    if item.type != "function_call":
        continue
    # arguments 是 JSON 字符串，解析失败时应记录错误并停止该调用。
    args = json.loads(item.arguments)
    result = dispatch_tool(item.name, args)
    input_items.append({
        "type": "function_call_output",
        "call_id": item.call_id,
        "output": json.dumps(result, ensure_ascii=False),
    })

final_response = client.responses.create(
    model="gpt-5",
    input=input_items,
    tools=TOOLS,
)
print(final_response.output_text)

这里的关键动作有三个：先把原始输出项保留下来，再按具体 call_id 生成回传项，最后把完整输入项交给下一次请求。若使用推理模型，不能只挑出可见的 function call；官方说明要求把相关 reasoning items 一并传回。

用审计记录守住参数和结果边界

建议每次调用至少记录响应 ID、调用 ID、工具名、参数摘要、授权结果、执行状态和回传时间。参数摘要可以脱敏后保存，密钥、个人信息和完整业务 payload 不应直接写入普通日志。

一个简单的审计对象可以这样设计；这是严格 JSON，不在其中插入注释，字段含义紧跟在代码块后说明：

{
  "response_id": "resp_example",
  "call_id": "call_example",
  "tool_name": "lookup_order",
  "argument_digest": "sha256:脱敏后的摘要",
  "authorization": "allowed",
  "execution": "success",
  "output_attached": true
}

argument_digest 用于关联排查而不是还原敏感参数；authorization 记录应用是否允许执行；output_attached 可帮助发现函数已经完成但回传项没有进入下一轮输入的缺口。

上线前检查哪些状态

如果只需要一次只读查询，可以把循环限制在明确的工具集合内；如果工具会写数据库、发消息或改变业务状态，还要把幂等、人工确认和失败补偿放在模型之外。

相关问题

为什么不能只把工具结果拼成用户消息？

这样会丢失工具调用与结果之间的结构化关联，模型也无法稳定判断结果属于哪一个调用。应使用带有原始 call_id 的 function_call_output。

多个 tool call 可以共用一轮回传吗？

可以在同一轮收集多个调用结果，但每个结果都要保留自己的 call_id，并分别校验工具名、参数和授权状态。

什么时候需要 previous_response_id？

当你希望下一次 Responses 请求继续前一条响应的上下文时使用它；它不能替代具体工具结果的 call_id。