Claude API Streaming 流式输出 + Batch 批量调用完全教程（2026）
用 Claude API 做产品，有两个问题绕不开：用户等不了模型想半天才给结果，以及跑大量请求的时候账单让人肉疼。
第一个问题的答案是 streaming——让模型一边想一边往回吐字，用户看到的是逐字出现的效果，体感等待时间从十几秒缩短到几百毫秒。第二个问题的答案是 Batch API——把不需要实时返回的请求打包，Anthropic 给你打五折。
这篇把这两件事拆开讲。streaming 那块从基础的 SSE 事件流到工具调用场景的流式处理，再到 Extended Thinking 的行为变化。Batch 那块讲 Message Batches API 怎么用、什么场景划算。末尾顺带聊下不同规模团队的接入选型。
Claude Streaming 流式输出
基本原理
Claude 的流式输出基于 Server-Sent Events（SSE）协议。发请求时加上 stream: true，服务端不再等模型完整生成后一次性返回，而是通过一条长连接持续推送 token。
对用户来说就是打字机效果——第一个字几百毫秒就出来，后面的内容陆续到达。对开发者来说，你需要处理的是一系列事件（event），而不是一个完整的 JSON 响应。
Claude 的 SSE 事件类型主要有这几种：
- message_start — 响应开始，包含消息的元数据（model、usage 等）
- content_block_start — 一个内容块开始（文本、工具调用、或思考过程）
- content_block_delta — 增量内容，文本块返回
text_delta，工具调用块返回input_json_delta - content_block_stop — 一个内容块结束
- message_delta — 消息级别的增量更新，主要是
stop_reason和最终的usage - message_stop — 整个响应结束
实际开发中不需要手动解析这些事件。Anthropic 的 Python 和 TypeScript SDK 都封装了流式接口，几行代码就能跑起来。
Python SDK 的流式调用大概长这样：
with client.messages.stream(
model="claude-sonnet-4-6-20250514",
max_tokens=1024,
messages=[{"role": "user", "content": "解释量子计算的基本原理"}]
) as stream:
for text in stream.text_stream:
print(text, end="", flush=True)TypeScript 那边用法差不多，SDK 返回一个异步迭代器，在 for await 循环里逐块处理就行。
通过 ofox.ai 等兼容 OpenAI 协议的平台调用时，也可以用 OpenAI SDK 的 stream=True 参数，效果一样。详细的接入配置参考《Claude API 国内怎么用》。
Fine-Grained Tool Streaming
做 Agent 或者带工具调用的应用时，streaming 碰上 tool use 曾经是个麻烦事。早期的实现是等工具调用的 JSON 参数完整生成后才一次性返回，导致用户在工具调用阶段看不到任何进度。
现在这个问题解决了。Claude 的 fine-grained tool streaming 已经 GA（正式发布），工具调用的参数也会以 input_json_delta 的形式逐块推送。
实际表现是这样的：模型在生成过程中决定调用工具，你会先收到 content_block_start 事件（包含工具名），然后是一系列 input_json_delta（参数的 JSON 片段逐个到达），最后 content_block_stop 标志这个工具调用块结束。你的代码需要把这些 JSON 片段拼起来，解析成完整的参数对象，再去执行工具。
用户那边的感受就不一样了：能看到「正在调用搜索工具」的中间状态，不用对着空白屏幕干等。
如果你已经在用 Claude 的 tool use 功能，streaming 这块基本不需要额外改代码。SDK 在流式模式下会自动处理 tool use 事件的拼接。
Extended Thinking + Streaming
Opus 4.6 和 Sonnet 4.6 都支持 Extended Thinking（扩展思考），开启后模型会在回答前先进行一段内部推理。在流式模式下，这段思考过程也会以 thinking 类型的 content block 实时推送。
4.6 系列有个变化值得注意：自适应推理（Adaptive Thinking）。以前得手动设 budget_tokens 控制思考预算，现在推荐用 thinking: {type: "adaptive"} 配合 effort 参数（low / medium / high / max）。简单问题自动少想点，复杂问题多想点，不用你操心。
流式场景下的一个实用技巧：如果你不需要展示思考过程给用户看，可以设置 thinking.display: "omitted" 来跳过思考内容的传输，减少网络带宽消耗，加快整体传输速度。但推理本身还是会进行的，只是不往客户端推了。
关于 Opus 4.6 的 Extended Thinking 和自适应推理的具体用法，《Claude Opus 4.6 API 完全指南》里有更详细的说明。
Streaming 的生产注意事项
生产环境跑 streaming，踩过几个坑分享一下。
超时是最先碰到的。流式连接是长连接，默认的 HTTP 超时经常不够用。Anthropic SDK 默认 10 分钟，开了 Extended Thinking 跑复杂推理的话，可能要往上调。
SSE 连接会断。网络波动、中间代理超时都可能导致连接中断，SDK 不会帮你自动重连。我的做法是检测到断连后带着已收到的上下文重新发请求，不算优雅但管用。
Token 计量别在中间做。增量事件里不带 token 计数，要等 message_stop 之后从最终的 message_delta 里取 usage 数据，再去做计费。
并发用户多的时候注意连接数。每个流式请求占一条长连接，服务器扛不住就 429 了。处理方式和普通请求一样，指数退避重试。
Message Batches API 批量调用
为什么要用 Batch
不是所有场景都需要实时响应。文档翻译、数据标注、内容批量生成、定期报告——这些任务可以等几分钟甚至几小时拿结果，但可能一次要跑成百上千个请求。
Claude 的 Message Batches API 干的就是这事：多个请求打包提交，Anthropic 后台异步跑，跑完你来取。重点是价格直接打五折，所有模型的输入输出都减半。
具体数字：
| 模型 | 标准输入 | 标准输出 | Batch 输入 | Batch 输出 |
|---|---|---|---|---|
| Haiku 4.5 | $1 | $5 | $0.5 | $2.5 |
| Sonnet 4.6 | $3 | $15 | $1.5 | $7.5 |
| Opus 4.6 | $5 | $25 | $2.5 | $12.5 |
价格单位：美元/百万 token
再叠加 Prompt Caching（重复的 system prompt 最多省 90%），综合下来一个月的账单能砍掉大半。具体怎么算的，这篇降本文章里有实测数据。
怎么用
用起来不复杂：创建批次、等它跑完、下载结果。
创建批次时，你提交一个请求数组，每个请求跟普通的 Messages API 参数一样（model、messages、max_tokens 等），外加一个 custom_id 用来在结果里对应。每个批次最多放 10,000 个请求。
batch = client.messages.batches.create(
requests=[
{
"custom_id": "doc-001",
"params": {
"model": "claude-sonnet-4-6-20250514",
"max_tokens": 1024,
"messages": [{"role": "user", "content": "翻译这段文字..."}]
}
},
# ... 更多请求
]
)等待处理。创建后批次进入 in_progress 状态。大部分批次在 1 小时内处理完，复杂的可能要更久。你可以轮询批次状态，也可以用 results_url 在完成后一次性下载所有结果。每个结果会标明成功（succeeded）或失败（errored），失败的请求会附带错误信息。
获取结果。结果是一个 JSONL 文件，每行对应一个请求的响应，通过 custom_id 关联。
适合 Batch 的场景
我用 Batch API 跑过的场景，效果比较好的有这几类：
大规模文本翻译。比如把一个产品的文档从英文翻成中文，几百个文件打包一个批次提交。不需要实时，隔天早上来收结果就行，成本直接砍半。
数据分析和标注。几千条用户反馈做情感分析，或者对一批简历做结构化提取。每条请求的 system prompt 一样，叠加 Prompt Caching 效果拉满。
定期内容生成。每周生成一批营销文案或产品描述。任务本身就不要求实时，用 Batch 纯省钱。
回归测试。跑一批固定的 prompt 测试模型输出的一致性。这个场景 Batch 特别合适——你关心的是结果正确性而不是响应速度。
不适合 Batch 的场景也很明确：用户正在等回复的聊天、需要毫秒级响应的在线推理、依赖前一步结果才能继续的链式调用。这些老老实实用 streaming。
Batch API 的 300K 输出
一个值得注意的新特性：Opus 4.6 和 Sonnet 4.6 在 Batch API 中支持最大 300K token 的输出（需要设置 output-300k-2026-03-24 beta header）。这在同步 Messages API 中是做不到的——Opus 同步最大输出 128K，Sonnet 是 64K。
写完整的技术文档、生成大段代码这种需要超长输出的场景，用 Batch 就不再受同步接口的输出上限制约了。
企业级使用方案
选什么接入方式，取决于你的团队规模和合规需求。
个人和小团队
直接用 Anthropic 官方 API 或者通过聚合平台调用。按量付费，没有最低消费。国内用户通过 ofox.ai 这类平台可以用人民币支付、国内直连，不需要折腾海外信用卡和网络问题。付费方案的详细对比之前写过。
聚合平台还有个好处：一个 Key 能调 Claude、GPT、Gemini 几十个模型，切换模型改个参数就行。还在纠结选哪个模型的团队，先用着再说。
中型团队
请求量上来之后，几件事会变得现实。
Rate Limit 是第一个卡脖子的。Anthropic 按 Tier 分级限流，Tier 1 的 RPM 和 TPM 往往不够。要么在 Console 主动申请升级，要么多 Key 轮转分散流量。
成本控制这块，Batch API + Prompt Caching 组合起来能覆盖大部分降本需求。建议设个每日预算上限，防止一次代码 bug 把月度账单拉爆。
再就是模型分级。不是每个请求都需要 Opus。分类、提取这种简单活儿扔给 Haiku，常规任务用 Sonnet，只有真正需要深度推理的才上 Opus。实测一个月能省 40-60%。
企业级
Anthropic 有正式的 Enterprise 方案，主要卖点是合规和管控：HIPAA 合规（医疗数据场景必须的）、SCIM 对接企业 SSO、全量审计日志、自定义 Rate Limit 不受标准 Tier 限制，以及 API 数据不用于模型训练的承诺。有专属技术支持，出问题直接找工程团队。
定价不公开，需要找 Anthropic 销售谈。
还有一条路：AWS Bedrock 和 Google Vertex AI 上都有 Claude。走云厂商的合同体系，合规认证借现成的，不用单独跟 Anthropic 签约。适合已经在用 AWS 或 GCP 的团队。
实际开发中的选择策略
不想看前面细节的，直接看这张表：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 用户在线聊天 | Streaming | 首 token 延迟低，体验好 |
| Agent / 工具调用 | Streaming + Fine-grained tool streaming | 实时展示工具调用进度 |
| 大规模文本处理 | Batch API | 半价，不急 |
| 超长内容生成 | Batch API（300K output） | 同步 API 输出长度不够 |
| 日常开发调试 | 标准 Messages API | 简单直接 |
| 高并发生产系统 | Streaming + Rate Limit 管理 | 用户体验 + 流量控制 |
这三种方式不冲突。我自己的项目里，用户聊天走 streaming，夜间的数据处理走 batch，开发时候调试用同步。混着用就对了。
相关阅读：
