👁 20 次阅读

LangGraph 调用 GPT-OSS 报“No call message found”该怎样排查？

来源链接：https://github.com/langchain-ai/langchain/issues/32885

现象描述

在 LangGraph 的 create_react_agent 工作流中调用 OpenAI 兼容接口（模型为 openai/gpt-oss-120b）并启用工具调用时，请求返回 400 Bad Request 错误。错误信息如下：

BadRequestError: Error code: 400 - {'error': {'message': 'No call message found for call_82802943873c42629d7e0eb32fb1d505 None', 'type': 'BadRequestError', 'param': None, 'code': 400}}

该错误出现在任务执行过程中，上下文为：

During task with name 'agent' and id '5b2e6...

触发该错误的示例代码（节选关键配置）：

model = ChatOpenAI(
    model="openai/gpt-oss-120b",
    api_key=environ.get("TOKEN"),
    streaming=True,
    base_url=environ.get("API_BASE"),
    http_async_client=AsyncClient(),
    http_client=Client(),
    reasoning=reasoning,
    use_responses_api=True,
    output_version="responses/v1",
)

agent = create_react_agent(
    model,
    [get_cve],
    checkpointer=InMemorySaver(),
    prompt="You are a helpful assistant.",
)

input = {"messages": [HumanMessage("Describe CVE-2024-1015.")]}
config = {
    "configurable": {"thread_id": get_ident()},
    "recursion_limit": recursion_limit
}

res = agent.invoke(input, config=config, stream_model="values")

该 issue 当前状态为 open，标签为 bug、integration、openai、external，截至最后一条实质评论（2026-05-10）仍未有官方修复合入。

背景原因

根据 issue 中的社区讨论，问题的核心在于 LangGraph 与 OpenAI Responses API 之间对工具调用状态的协调不一致。

LangGraph 侧的状态预期：create_react_agent 在工具调用循环中，会维护一个内部状态机，其中包含对“调用消息”（call message）的引用。该引用用于将模型返回的工具调用与后续的工具执行结果进行配对。
OpenAI 侧的实际返回：当使用 gpt-oss-120b 且启用 use_responses_api=True 与 output_version="responses/v1" 时，API 返回的响应结构可能未包含 LangGraph 所期望的 function_call.status 字段，或者该字段被丢弃，导致 LangGraph 在后续步骤中找不到对应的调用消息，从而抛出 No call message found。

评论中 OpenSourceGHub 指出：“There’s a mismatch between LangGraph’s expected state with what the API provides, as it expects a valid call message. If they don’t synchronize, then that’s where the bug might occur.”（LangGraph 期望的状态与 API 提供的状态不匹配，API 期望一个有效的调用消息，如果两者不同步，就可能出现这个 bug。） GilbertKrantz 在 2025-09-12 直接提问：“So is responses api not supported with GPT OSS right now?”（所以现在 Responses API 不支持 GPT OSS 吗？）——这反映了社区对该组合兼容性的普遍疑虑。

排查或量化方法

issue 中有多位用户尝试了不同的排查路径，以下是可复现的定位步骤： 1. 最小化复现：使用 issue 顶部给出的完整示例代码（包含 get_cve 工具、InMemorySaver 检查点、stream_model="values" 配置），在本地环境运行，观察是否稳定触发 400 Bad Request。 2. 移除 Responses API 相关参数：starchou6 在 2025-09-11 提供了一个快速验证方案——去掉 use_responses_api=True 与 output_version="responses/v1" 两行配置后重新运行。该用户表示该改动可以绕过错误（“try this quick fix”），但未给出进一步的稳定性验证。 3. 更换模型或简化工具 Schema：ll188562461 在 2026-02-05 分享经验，称“it’s usually a compatibility issue rather than a bug in the codebase. Sometimes the model simply doesn’t support certain tool call formats. What worked for me was switching to a different model or simplifying the tool schema.”（这通常是兼容性问题而非代码库 bug。有时模型不支持某些工具调用格式，更换模型或简化工具 Schema 有效。） 4. 构建复现脚手架：awamonem 在 2026-03-05 提供了一个独立的复现仓库（https://github.com/aashmawy/trajectly-experiments/tree/main/langchain-issue-32885-harness），其中包含“baseline run that passes”（可通过的基线运行）与“regression run that fails in a deterministic way”（可确定性失败的回归运行），可用于量化对比不同配置下的表现。

完整解决方案

截至 2026-05-10，官方尚未合入修复。issue 处于 open 状态，没有维护者确认的修复版本。社区侧的可行方案有以下几种，但各自存在局限：

方案一：移除 Responses API 参数（临时绕过）

在 ChatOpenAI 初始化时去掉 use_responses_api=True 与 output_version="responses/v1"：

model = ChatOpenAI(
    model="openai/gpt-oss-120b",
    api_key=environ.get("TOKEN"),
    streaming=True,
    base_url=environ.get("API_BASE"),
    http_async_client=AsyncClient(),
    http_client=Client(),
    reasoning=reasoning,
    # 移除以下两行：
    # use_responses_api=True,
    # output_version="responses/v1",
)

局限：该方案来自用户评论，未经验证是否影响模型推理质量或工具调用的其他行为。GilbertKrantz 的提问表明，社区对该参数组合的官方支持状态并不明确。

方案二：更换模型或简化工具 Schema

将 model 参数切换为其他 OpenAI 兼容模型（如 gpt-4o 等），或减少工具函数的参数复杂度。局限：ll188562461 指出这只是个人经验，未提供系统性对比数据；且该方案改变了业务依赖的模型，并非所有场景都适用。

方案三：避开 `create_react_agent`（针对 Bedrock 环境）

MukundaKatta 在 2026-05-10 针对 Bedrock 环境给出了具体建议： > Harmony format and Bedrock Converse’s tool format don’t fully align. gpt-oss-120b expects channel-tagged tool calls (analysis/commentary/final) which create_react_agent doesn’t emit, so Bedrock rejects the request as malformed. Workaround: don’t use create_react_agent with gpt-oss on Bedrock. Drop to the raw bedrock_runtime.converse with the harmony tool prompt template directly, parse the channel-tagged response… 即：不使用 create_react_agent，直接调用 bedrock_runtime.converse，并使用 harmony 工具提示模板，自行解析 channel-tagged 的响应。局限：该方案仅适用于 Bedrock 部署，且需要自行实现工具调用循环，工作量大。

社区修复尝试与阻塞

giulio-leone 在 2026-03-07 至 03-12 期间连续提交了三个 PR（#35618、#35764、#35772），标题为 fix(openai): preserve function_call status for GPT-OSS，目标是保留 function_call.status 字段。但前两个 PR 因“减少 PR 数量”和“未分配 issue”被关闭，第三个 PR 因 require-issue-link 工作流要求 issue 分配而自动关闭。该用户请求维护者分配 issue 以便 PR 自动重开，但截至最后一条评论（2026-05-10），未见分配结果。

参数或对比表格

方案	操作方式	验证状态	局限
移除 Responses API 参数	去掉 `use_responses_api` 与 `output_version`	用户 starchou6 验证可绕过错误	未确认对其他功能的影响
更换模型或简化工具	修改 `model` 参数或工具 Schema	用户 ll188562461 个人经验有效	改变业务依赖，非通用方案
使用原始 Bedrock Converse	绕开 `create_react_agent`，直接调用 `bedrock_runtime.converse`	用户 MukundaKatta 在 Bedrock 场景验证	仅适用 Bedrock，需自行实现循环逻辑
官方修复 PR	PR #35618 / #35764 / #35772	均被自动关闭，未合入	等待 issue 分配，当前无进展

常见错误排查

错误消息中的 call_82802943873c42629d7e0eb32fb1d505 是什么？

这是 OpenAI API 返回的工具调用 ID。LangGraph 在后续步骤中需要用它来匹配工具执行结果。报错说明 LangGraph 在状态中找不到该 ID 对应的调用消息记录。

移除 use_responses_api 后错误消失，是否意味着 Responses API 本身有问题？

不一定。这只能说明在 gpt-oss-120b 模型上，Responses API 与 LangGraph 的工具调用状态机存在不兼容。具体是模型侧不支持还是 LangGraph 侧处理缺失，issue 中没有定论。

是否所有 OpenAI 兼容模型都会触发此错误？

不是。ll188562461 的经验是“某些 GPT 模型”才会出现，通常与模型对工具调用格式的支持程度有关。

错误是否与 streaming=True 相关？

当前 issue 中所有复现代码均开启了 streaming=True，但没有用户报告关闭流式后的对比结果，因此无法确定该参数是否为必要触发条件。

是否可以通过设置 recursion_limit 避免？

不能。报错发生在请求阶段（400 Bad Request），是 API 层返回的拒绝，与循环深度无关。recursion_limit 只控制 LangGraph 图执行的步数上限。

实践建议

若业务可以接受，优先尝试移除 use_responses_api=True 与 output_version="responses/v1"，这是社区中反馈最快生效的绕过方式。
若必须保留 Responses API，考虑更换为 gpt-4o 等更成熟的模型，以规避 gpt-oss-120b 的工具调用格式兼容问题。
对于 Bedrock 部署场景，直接使用 bedrock_runtime.converse 并配合 harmony 模板自行实现工具循环，避免 create_react_agent 的封装。
关注 PR #35772 的状态。若维护者完成 issue 分配并合入该修复，后续版本可能解决 function_call.status 被丢弃的问题。但在此之前，不应假设官方已有可用补丁。
如需稳定复现与对比，可参考 awamonem 提供的复现脚手架（https://github.com/aashmawy/trajectly-experiments/tree/main/langchain-issue-32885-harness），其中包含通过与失败的确定性运行样本。

FAQ

问：No call message found for call_82802943873c42629d7e0eb32fb1d505 一定意味着代码写错了吗？ 答：不一定。issue 中多位用户指出，代码本身可能是正确的，问题出在 LangGraph 与特定模型/API 组合的状态同步上。 问：该 issue 是否已修复？ 答：截至最后一条实质评论（2026-05-10），issue 仍为 open 状态。虽然有用户提交了修复 PR，但因工作流原因被自动关闭，官方尚未合入任何修复。 问：使用 vLLM 部署的模型是否也会遇到类似问题？ 答：N777777 在 2026-03-17 提到，其 vLLM Docker 部署在旧版本上遇到了“closely related error”，但错误消息并非完全一致。该用户未提供最终解决方案，仅确认了同类故障的存在。 问：function_call.status 是什么，为什么它重要？ 答：根据 giulio-leone 的 PR 描述，该字段用于指示工具调用的状态（如进行中、已完成）。当该字段被丢弃时，LangGraph 无法正确关联工具调用的上下文，从而触发 400 错误。 问：是否所有 OpenAI 兼容端点（如 Azure OpenAI）都会受影响？ 答：issue 中仅涉及 openai/gpt-oss-120b 与 Bedrock 两种端点。其他端点的兼容性未在讨论中涉及，不能推断为同样受影响。