调模型这件事，看起来就一句话：
把请求发过去，把结果拿回来。
但结果怎么返回，有三种常见的调用方式。
一种是等它整个生成完再给你，一种是边生成边往外送，还有一种是一次发一批。
LangChain 把它们做成了三个方法：invoke、stream、batch。
| 调用方式 | 结果怎么返回 | 典型场景 |
|---|---|---|
invoke |
等模型整个生成完，一次拿到完整结果 | 拿到结果才能往下走的任务 |
stream |
边生成边返回，一段一段地拿 | 对话、长文生成这类要有实时感的场景 |
batch |
整批跑完后，按输入顺序返回 | 离线的批量任务 |
这三种调用方式，各自还有一个异步版本。
异步版的方法名只多一个 a：
ainvoke、astream、abatch。
用法上跟同步版有差别：
结果得靠 await 拿，astream 那边还要配合 async for 来循环。
下面一个一个说。
等结果全出来再拿走
invoke 是最基础的一个，也最容易理解。
发一次请求，模型把整段结果生成完，再一次性返回。
这是同步调用，整段结果没回来之前，调用方一直等着，中途拿不到任何片段。
打个比方，像在面馆点单：
只能干等着，厨房把整碗做好了才给你端上来。
invoke 适合这几类任务：
- 短文本分类、意图识别，只要一个结论
- 对延迟不敏感的后台任务
- 下一步必须拿到完整结果才能继续的逻辑，比如先拿到模型给出的参数，再拿这个参数去查数据库
最后这条是硬要求，要的是完整结果，跟用哪个方法没关系。
stream 也能接这种活，只是你得自己把片段拼成完整的一条，才能交给下一步。
python
result = model.invoke("把这句话归类：是投诉、咨询，还是表扬？") # 整段结果拿到手，再决定下一步边生成边往外送
stream 不等结果全出来。
模型生成一点，往外送一点，返回的是一串片段，拼起来才是完整的一条消息。
同步调用时，stream 给的是个迭代器，每循环一次拿到一个片段，可以立刻显示给用户。
像对面一边说，你一边听。
好处有两个：
生成到哪儿，用户就能看到哪儿，不用盯着空屏幕干等。
模型要是跑偏了，不用等整段生成完才发现。
典型场景有这么几类：
- 对话类应用，做出打字机效果
- 长文本或代码生成，用户可以边看边判断要不要继续
- 任何需要实时反馈的交互界面
代价是拿到的只是片段，拼接、累积这些活都得你自己来。
要是下一步非要等到完整结果不可，那就直接用 invoke 更省事。
python
for chunk in model.stream("讲讲 LangChain 的模型调用方式"): # 一段一段地显示，不用等整段
print(chunk.content, end="", flush=True)一次发一批
batch 处理的是很多条彼此独立的输入。
一次把一批输入交出去，并发跑完，最后统一收结果。
batch 的默认实现，是并发调用多次 invoke。
它没向模型要什么新能力，只是用线程池把一条条 invoke 一起跑起来。
个别组件要自己实现批处理，那就不走这条默认路子。
原来你写个循环一条一条调，现在交给 batch 并发跑，整体耗时能压下来。
像把一沓单子一次递过去，柜台同时开几个窗口办。
开几个窗口是可以设定的，用 max_concurrency 参数。
不设的话，并发度走线程池的默认值。
输入一多，短时间内同时发出的请求就多，一旦触发服务商的限流，或者超出配额，这些请求就可能失败。
batch 默认会把整批跑完再返回，结果按输入顺序排好，跟传进去的列表一一对应。
要想按完成顺序收结果：
可以用 batch_as_completed，哪条先跑完，哪条的结果就先返回，还带着对应的输入序号，代价是顺序不再保证。
batch 的适用场景主要是两类：
- 离线的批量任务，比如大批量文本分类、数据标注
- 一批彼此独立的请求，要尽快跑完
日常写业务代码，batch 通常用得比 invoke 和 stream 少。
python
inputs = ["这句话是投诉", "这句话是咨询", "这句话是表扬"]
results = model.batch(inputs, config={"max_concurrency": 5}) # 结果按输入顺序返回怎么挑
用哪个方法，看结果怎么用就知道了。
页面上的对话、要有实时感的生成，走 stream。
离线的批量活，走 batch。
剩下的场景用 invoke 就够了，它也最省心。
一个应用里，三种方式常常一起用：
页面上的对话在流式返回，后台的批量任务在并发跑，中间那些必须拿到完整结果才继续的步骤，老老实实等 invoke 返回。