LangChain 工具调用出错：先检查消息角色与调用 ID 配对

从一次完整的调用链开始排查 先保存一条最小调用轨迹：用户问题、模型产生的工具调用、应用执行的结果、回传给模型的消息，以及下一次模型响应。不要一开始就把整段历史压成一个字符串。LangChain 消息由角色、内容与元数据组成，结构本身也承载了模型与应用如何交互的信息。 四种消息分别承担什么工作 SystemMessage 用于提供行为规则和上下文，HumanMessage 表示用户输入，AIMessage 表示模型输出，ToolMessage 表示工具执行结果。AIMessage 不一定只有一段可展示的回答，也可能包含 tool_calls 和其他结构化内容。开发界面时若只渲染文本，会遗漏“模型正在请求执行工具”这一状态。 把工具名称和调用身份分开 一次工具请求带有名称、参数和调用 ID。应用执行工具后，ToolMessage 的 tool_call_id 必须匹配对应调用的 ID。名称回答“调用哪一种工具”，ID 回答“这份结果属于哪一次调用”。同一个检索工具被调用两次时，仅按名称关联就可能把不同问题的结果接反。 建议先测试单次调用，再加入两个参数不同的同名调用，最后检查执行完成顺序与调用顺序不同时的结果归属。这是对应用实现的验收建议，不代表 LangChain 会自动修复错误的 ID。 用两次同名查询暴露错误配对 以自拟库存查询为例，模型先请求 get_stock，参数为 {"sku":"A12"}，调用 ID 为 call_a；随后请求同一个工具，参数为 {"sku":"B09"}，调用 ID 为 call_b。即使 B09 先查完，它的结果也必须回到 call_b，不能因为先完成就占用第一项结果的位置。 保存时可把每次调用视为一条带身份的记录：call_a → A12 → 库存 12，call_b → B09 → 库存 9。这些库存数字仅用于演示。生成 ToolMessage 时从对应调用记录取 ID，不在结果返回后重新按数组下标猜测。模型看到的历史中应保留发起调用的 AIMessage，再附上与各调用对应的结果。 若 call_b 查询失败，也要保留它与 call_b 的关联，按所用工具接口返回明确失败信息或走失败分支。不能拿 call_a 的成功结果补空，也不能把重试前后的两个结果都当成不同的业务事实。测试时故意让第二个请求先完成，并让其中一个失败，更容易发现只在串行演示中看不出的实现问题。 哪些内容进入模型，哪些留在应用 官方消息文档区分了 ToolMessage 的 content 与 artifact。前者是交给模型使用的工具输出；后者可保留文档标识、页码等应用需要的数据，但不会作为工具内容送给模型。检索应用可将相关片段放入 content，将页面跳转所需的文档 ID 和页码保存在 artifact。 这个区分也给出一个检查方法：若回答缺少必要事实，确认事实是否真的进入 content；若只是前端来源按钮丢失，检查 artifact 的保存和读取。不要通过把所有调试信息追加到回答文本来解决展示问题。 流式响应需要独立处理 流式调用返回 AIMessageChunk，官方文档支持把消息块累积成完整消息。界面逐步展示的文本，与业务层最后用于保存、继续对话的完整消息，不应混为一个临时变量。建议用一段短回答核对块合并后的内容，再测试包含工具调用的分支。 工具参数的流式分块尤其需要小心：某一块可能只有不完整的 JSON 字符串，它还不是可执行参数。先按消息接口累积调用片段，得到完整调用并验证参数后再执行工具；不要在界面刚显示出工具名称时就发起操作。否则同一次生成可能被重复执行，或者使用了尚未补全的参数。 最后检查上下文是否仍然自洽 历史裁剪或重试后，重新检查调用和结果是否仍然配对。若只保留结果而丢掉产生该结果的调用，或者重复追加上一次执行结果，下一轮输入就与真实执行轨迹不一致。对话日志应保留可用于定位问题的调用身份，但不应默认公开完整工具结果。 适用边界 本篇核对的是 LangChain 的消息语义，并未覆盖所有模型供应商的协议差异。供应商可能对消息字段有不同处理；例如官方文档提示 name 字段并非在所有供应商上具有相同作用。切换供应商后，应重新运行消息配对和流式回归样例。

本篇涉及的工具1

LangChain

消息类型与工具调用结果配对由 LangChain 的公共消息接口表示。

适合场景

需要控制多轮历史、工具回传和来源展示的应用。

需要留意

统一消息结构不能消除供应商协议差异；仍需核对实际接入模型。

了解项目 访问官网