TLDR：我们引入了一种新的消息内容视图，它能标准化推理、引用、服务器端工具调用以及其他现代 LLM 功能（跨提供商）。这使得构建与推理提供商无关的应用程序变得更加容易，同时又能利用每个提供商的最新功能。此功能完全向后兼容，因为它可以通过延迟计算从现有消息内容中生成。
动机
LangChain 的核心优势之一是为大型语言模型提供“一次编写，随处运行”的抽象。这种抽象允许开发人员构建可以无缝切换不同 LLM 提供商而无需重写代码的应用程序。
包括 OpenAI、Anthropic 和 Google Gemini 在内的主要推理提供商近期提供的功能日益丰富多样。LLM 现在可以为查询执行多个不同的步骤，从阐述其推理过程、执行网络搜索和调用代码解释器，到生成带有引用和可能包含多模态数据（如图像）的最终响应。尽管每个提供商支持的功能集类似，但它们的 API 却存在差异，而兼容层（如每个提供商提供的 Chat Completions API）通常在支持（或根本不支持）提供商原生功能的完整集方面滞后。
LangChain 1.0 中的标准内容
我们为最新的 LLM 功能引入了新的标准类型，并将它们暴露在所有 LangChain 消息对象上，从而更容易构建提供商无关的应用程序，而不会牺牲对任何可用功能的支持。这些功能将在 langchain 1.0 中提供，并且同时适用于Python 和JS。
标准内容块确保相同的功能以相同的方式表示（跨提供商）。实际上，它们是一组类型化的数据结构，用于规范所有 LLM 提供商的消息内容。它们包括：
- 模型生成的标准文本输出（包括引用）
- 模型推理和思维链输出
- 来自任何来源（URL、base64、存储桶文件 ID）的图像、音频、视频和文档
- 工具/函数调用和执行
- 提供商特定的工具，包括内置的网络搜索功能和代码执行
详细信息
所有 LangChain 消息对象现在都实现了 .content_blocks 属性，该属性将惰性加载现有消息内容的新表示。以 Anthropic 的 Claude 和 OpenAI 的 Responses API 的结果为例。在此示例中，我们利用了它们的推理和网络搜索功能。原始的 .content 将通过提供商的原生格式传递。
Anthropic:
from langchain.chat_models import init_chat_model
llm = init_chat_model(
"anthropic:claude-sonnet-4-20250514",
thinking={"type": "enabled", "budget_tokens": 5_000},
).bind_tools([
{
"type": "web_search_20250305",
"name": "web_search",
"max_uses": 1,
}
])
response = llm.invoke("When was LangChain created?")
response.content
# [
# {
# "type": "thinking",
# "thinking": "...",
# "signature": "...",
# },
# {
# "type": "server_tool_use",
# "name": "web_search",
# "input": {...},
# "id": "...",
# },
# {
# "type": "web_search_tool_result",
# "content": [...],
# "tool_use_id": "...",
# }
# {
# "type": "text",
# "text": "...",
# "citations": [...],
# }
OpenAI:
from langchain.chat_models import init_chat_model
llm = init_chat_model(
"openai:gpt-5-nano",
reasoning={"effort": "low", "summary": "auto"},
).bind_tools([{"type": "web_search_preview"}])
response = llm.invoke("When was LangChain created?")
response.content
# [
# {
# "type": "reasoning",
# "summary": [...],
# "id": "...",
# },
# {
# "type": "web_search_call"
# "action": {...},
# "id": "...",
# ...
# },
# {
# "type": "text",
# "text": "...",
# "annotations": [...],
# "id": "...",
# }
尽管这些响应的内容相似，但 API 的细微差别会累积增加构建一个允许您在这两个提供商之间切换的应用程序的摩擦。
新的 .content_blocks 属性会将两个响应解析为一致的表示。
response.content_blocks
# [
# {
# "type": "reasoning",
# "reasoning": "...",
# },
# {
# "type": "web_search_call",
# "query": "...",
# "id": "...",
# "extras": {...},
# },
# {
# "type": "web_search_result",
# "urls": [...],
# "id": "...",
# "extras": {...},
# },
# {
# "type": "text",
# "text": "...",
# "annotations": [...],
# }
.content_blocks 的输出包括用于推理、引用、网络搜索、代码解释器调用的新类型，还包括用于（客户端）工具调用和多模态数据（如图像、PDF 文档和音频）的 LangChain 类型。
标准内容块目前为 alpha 版本，适用于：
- 实现聊天补全 API 的提供商（包括 OpenAI）
- OpenAI Responses API
- Anthropic (Claude)
langchain 1.0 将支持所有主要提供商。
向后兼容性
- 无破坏性更改；100% 兼容现有 LangChain 应用程序。
.content_blocks适用于所有消息类型，包括缓存中存储的旧类型。
展望未来
标准内容块代表了迈向更可靠、更易于维护的 LLM 应用程序的基本一步。
通过在提供商之间提供一致的接口，您可以：
- 自信地构建：类型安全可以在生产前捕获错误。
- 跨提供商扩展：切换模型而无需花费时间重写应用程序逻辑。
- 使应用程序面向未来：新的提供商功能无需破坏现有代码即可立即使用。
有疑问或反馈？ 请在此发布GitHub issue上发表评论。我们很乐意收到您的想法！