LangChain 工具调用无响应？模型兼容性是关键原因

LangChain 调用工具返回空气 content，通常不是代码逻辑错误，而是所选的大模型(如 Mixtral-8x7B)虽然声称支持工具调用，但实际上并没有正确实现 tool_choice 或 tool_calls 响应分析机制；切换到真正本地支持结构化工具调用的模型(如 GPT-4o-mini）即可解决。

langchain 调用工具返回空气 content，通常不是代码逻辑错误，而是所选择的大型模型(例如 mixtral-8x7b)虽然声称支持工具调用，但实际上并没有正确实现 `tool_choice` 或 `tool_calls` 响应分析机制；切换到真正本地支持结构化工具调用的模型(如 gpt-4o-mini）即可解决。

在 LangChain 端到端工具调用实现端到端工具调用（Tool Calling），三个关键条件需要满足：LLM 支持结构化工具声明，正确输出 tool_calls、并能在后续轮中理解和响应 ToolMessage。您提供的代码逻辑是完全正确的-使用 bind_tools、解析 response.tool_calls、构造 ToolMessage 并将其添加到新闻历史中，再次调用 LLM——这正是 LangChain 官方推荐的标准流程。

然而，问题的根源在于模型层的兼容性。您使用的 mistralai/Mixtral-8x7B-Instruct-v0.1（通过 Together AI 提供)虽然支持某些函数的调用格式，但其推理后端并没有严格遵循 OpenAI-style 的 tool_calls JSON Schema 规范，导致:

• 虽然包含了第一次响应 tool_calls 但是字段(说明触发了工具识别) content 为空；
• 第二次调用时，模型无法调用 ToolMessage（如 content='36'）在上下文中有效整合，只输出空字符串（content=''）与极低 token 数（output_tokens: 1），表明它根本没有产生有意义的自然语言回复。

✅ 正确的解决方案:用充分验证的原始工具调用模型代替。例如:

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="gpt-4o-mini",  # ✅ 官方强力支持工具调用，稳定可靠
    api_key="your_api_key",
    temperature=0,
)

? 补充建议：

• 避免“伪工具支持”模型 GPT-4o、GPT-4o-mini 外，Claude-3.5-Sonnet、Gemini-1.5-Pro 也有成熟的工具调用能力；而且大多数开源模型(即使标注“”supports function calling”）在 LangChain 生态需要额外的适配器或响应格式偏差。
• 务必启用 bind_tools + 显式 tool_choice="auto"（默认）：确保模型清楚地知道当前阶段需要选择工具，而不是自由回答。
• 检查消息类型顺序：LangChain 要求 ToolMessage 必须紧跟触发它 AIMessage，且 tool_call_id 严格匹配-您的代码已正确实现此约束。
• 调试技巧：印刷 second_response.response_metadata['finish_reason']，若为 "eos"(如你的案例)而非 "stop" 或 "tool_calls"，这通常意味着模型不了解工具结果，应优先考虑模型的兼容性。

总而言之，这不是 LangChain 的 Bug，但是模型能力的边界问题。坚持使用标准 API 流程，同时选择经典 LangChain 社区广泛验证的官方文档和模型可以获得预期的自然语言聚合答案(如 “The result of 3 times 12 is 36, and the result of 11 + 49 is 60.”）。