关于Langchain/Langgraph框架的流式与非流式返回——invoke/ainvoke/stream/astream

Langchain和Langgraph这类大模型开发框架，早已成为众多开发者手中的利器。但很多时候，我们对工具的使用停留在“会调用”的层面，而忽略了其背后的本质。比如框架中提供的invoke、ainvoke、stream、astream四个方法，大多数人可能只清楚它们支持同步/异步、流式/非流式，却很少追问：这些能力到底是框架自己实现的，还是模型本身就有的？

先抛一个核心观点：

这四个方法本质上反映的，正是大模型本身的流式与非流式输出的能力。

让我们把这个问题拆开来看。

流式与非流式：底层模型的开关

在Langchain或Langgraph中调用模型时，invoke（非流式）和stream（流式）的区别，其实就是调用大模型接口时 stream=False 和 stream=True 的区别。如果底层大模型根本不支持流式输出，框架再怎么包装，也只能返回一个“假流式”——数据依旧是在后端全部生成后才一次性吐出，前端只是模拟了逐步显示的效果。所以，流式支持的根基，在于模型本身。

那么同步与异步又是什么？简单来说，就是网络请求框架的不同。同步调用使用 requests 这类阻塞式库，异步调用则依赖 aiohttp 或 httpx 等非阻塞库。于是：

• 同步非流式 = 同步网络请求 + stream=False
• 同步流式 = 同步网络请求 + stream=True
• 异步非流式 = 异步网络请求 + stream=False
• 异步流式 = 异步网络请求 + stream=True

只不过，Langchain/Langgraph并不是直接对着模型接口发 HTTP 请求，而是通过 OpenAI 封装好的 SDK 来调用。这一层封装的好处在于：OpenAI 的接口标准已经成为行业事实标准，市面上绝大多数模型都兼容它。这样做既避免了重复造轮子，又保证了框架的可迁移性。

流式返回的实现细节：迭代器

非流式返回没什么好说的——模型处理完所有 token 后一次性返回完整结果。而流式返回的底层机制，在框架中是通过迭代器（iterator）来实现的。当你调用 stream() 或 astream() 时，返回的是一个可迭代对象；然后你通过遍历这个迭代器，逐块地获取模型生成的内容。这就像从水管里接水，水不是一下子装满一桶才倒给你，而是一滴一滴地流出来——你随时可以接住已经流出的部分。

一个容易被忽视的认知误区

从这四个方法的研究中，可以得出一个深刻的教训：我们往往过分聚焦于框架本身，反而忽略了最基础的东西。框架的作用是简化开发、提高效率，但它无法超越底层能力的边界。如果你不懂大模型到底支持什么、不支持什么，就容易陷入“框架万能”的幻觉。因此，学习框架的同时，一定不要丢掉对大模型基础能力的持续关注——只有这样，才能真正知道该怎样用好它。