--- type: study created: 2026-08-11 updated: 2026-08-11 sensitivity: standard status: verified tags: - study - langchain - typescript - integrations - chat-models - tool-calling - multimodal topic: LangChain JavaScript 主流云 Chat 模型与高级能力 sources: - https://docs.langchain.com/oss/javascript/integrations/chat/anthropic - https://docs.langchain.com/oss/javascript/integrations/chat/azure - https://docs.langchain.com/oss/javascript/integrations/chat/bedrock_converse - https://docs.langchain.com/oss/javascript/integrations/chat/cohere - https://docs.langchain.com/oss/javascript/integrations/chat/google - https://docs.langchain.com/oss/javascript/integrations/chat/google_generative_ai - https://docs.langchain.com/oss/javascript/integrations/chat/google_vertex_ai - https://docs.langchain.com/oss/javascript/integrations/chat/ibm - https://docs.langchain.com/oss/javascript/integrations/chat/mistral - https://docs.langchain.com/oss/javascript/integrations/chat/openai - https://docs.langchain.com/oss/javascript/integrations/chat/openrouter last_verified: 2026-08-11 --- # Chat 模型：主流云与高级能力 ## 能力矩阵 下表来自各组件页的标准 feature table；“I/A/V”依次为图片、音频、视频输入。勾选表示 wrapper 支持，仍需用目标模型和端点验证。 | 类 / 包 | 认证 | Tool | Structured | I/A/V | Stream | Usage / Logprobs | 状态与重点 | |---|---|---:|---:|---|---:|---|---| | `ChatAnthropic` / `@langchain/anthropic` | `ANTHROPIC_API_KEY` | ✅ | ✅ | ✅/❌/❌ | ✅ | ✅/❌ | serializable；content blocks、citations、prompt cache、context editing | | `AzureChatOpenAI` / `@langchain/openai` | Azure key 或 Managed Identity | ✅ | ✅ | ✅/❌/❌ | ✅ | ✅/✅ | deployment + API version；可自定义域和 header | | `ChatBedrockConverse` / `@langchain/aws` | AWS region + identity | ✅ | ✅ | ✅/❌/❌ | ✅ | ✅/❌ | 模型级能力差异；可用 Bedrock bearer token | | `ChatCohere` / `@langchain/cohere` | `COHERE_API_KEY` 或 custom client | ✅ | ✅ | ❌/❌/❌ | ✅ | ❌/❌ | serializable 标为 beta；原生 RAG documents/connectors | | `ChatGoogle` / `@langchain/google` | AI Studio key、Vertex Express key、ADC/credential | ✅ | ✅ | ✅/✅/✅ | ✅ | ✅/✅ | 新项目推荐；统一 AI Studio/Vertex；图像生成和 TTS | | `ChatGoogleGenerativeAI` / `@langchain/google-genai` | `GOOGLE_API_KEY` | ✅ | ✅ | ✅/✅/✅ | ✅ | ✅/❌ | 旧包 LTS，底层 SDK 已弃用，不再获新特性 | | `ChatVertexAI` / `@langchain/google-vertexai` | ADC / web credential | ✅ | ✅ | ✅/✅/✅ | ✅ | ✅/✅ | 旧 Node 包；Web/Edge 使用 `google-vertexai-web` | | `ChatWatsonx` / `@langchain/ibm` | IAM、bearer token 或 CP4D | ✅ | ✅ | ✅/❌/❌ | ✅ | ✅/❌ | model gateway、软件部署、多认证形态 | | `ChatMistralAI` / `@langchain/mistralai` | `MISTRAL_API_KEY` | ✅ | ✅ | ✅/❌/❌ | ✅ | ✅/❌ | 不可序列化；HTTP lifecycle hooks | | `ChatOpenAI` / `@langchain/openai` | `OPENAI_API_KEY` | ✅ | ✅ | ✅/❌/❌* | ✅ | ✅/✅ | Responses API、built-in tools、strict schema、cache、audio 章节 | | `ChatOpenRouter` / `@langchain/openrouter` | `OPENROUTER_API_KEY` | ✅ | ✅ | ✅/✅/✅ | ✅ | ✅/✅ | provider / multi-model routing、plugins、数据策略 | \* OpenAI 页的顶层矩阵把 audio input 标为否，但后文又给出兼容音频模型的 audio input/output 与 streaming 示例。这是模型/端点/版本级差异，不能据任一处做全局承诺。 ## 标准初始化 所有组件都遵循 `new ChatXxx({ model, temperature, maxRetries, ...providerConfig })` 与 `invoke(messages)`。生产实例应按 `(provider, model, endpoint, tenant-policy)` 复用连接配置，但不要跨租户共享可变 header 或临时 credential。 消息解析必须优先使用标准字段：`AIMessage.tool_calls`、`usage_metadata`、`response_metadata` 和 content blocks。不要只读取 `content as string`：Anthropic、Google、OpenAI Responses 和多模态输出都可能返回 block 数组。 ## OpenAI - `configuration.baseURL` 与 `defaultHeaders` 可接代理；OpenAI-compatible 并不保证 `stream_options` 等扩展，代理不支持 streaming usage 时设置 `streamUsage: false`。 - `strict: true` 可用于 `.bindTools()` 与 `.withStructuredOutput()`，但只接受 JSON Schema 子集，optional/default 参数尤其容易不兼容；业务层仍需 Zod 校验。 - 使用 built-in web/file search、computer use、conversation state 或显式 `useResponsesApi: true` 时走 Responses API。响应会含 annotations、content blocks 与 provider-specific tool outputs。 - reasoning 模型的结构化 schema 中，缺省字段宜用 nullable，而不是期待 optional 被遵守。 - prompt cache usage 尚未完全标准化，缓存 token 可能位于 `response_metadata`；成本采集要兼容两处。 - custom tool 可接收任意字符串或 grammar，但执行器必须在隔离环境中做权限、超时和输出限制。 ## Anthropic - 同一 `AIMessage.content` 可能是字符串或 content blocks；tool use 同时出现在 content blocks 与标准 `tool_calls`，业务侧只选一个权威执行路径，避免执行两次。 - prompt cache 通过 block/tool 上的 ephemeral cache control 标记；默认寿命约 5 分钟且命中刷新，可请求 1 小时 TTL。首次写缓存成本更高，并有最小可缓存长度。 - citations 可基于 document、search result 或自带 RAG tool result；应保存 citation 与原文 chunk 的稳定映射。 - context editing 需要特定包版本和 beta header，可自动清理旧 tool result；启用前必须回放长会话，确认不会删掉业务必需状态。 - provider overview 还要求 system message 只能位于首条。 ## Google - Node.js 推荐从 `@langchain/google/node` 导入；Web/Edge 从 `@langchain/google` 导入。 - 有 API key 时默认 Google AI；有 credential/ADC 时默认 Vertex；Vertex Express 使用 key 时必须显式 `platformType: "gcp"`。 - Google Cloud 生产环境优先 ADC。`GOOGLE_CLOUD_CREDENTIALS` 是 credential JSON 内容而非路径；不得把它发到客户端 bundle。 - Google 建议保留 temperature/topP/topK 默认值，以 prompt 控制风格。 - specialty tools（code execution、Google Search 等）不能与标准 LangChain tools 混在同一请求。 - implicit context caching 自动发生；显式 cache 需在 LangChain 外创建，再以 cache name 引用。 - `contentBlocks` 支持图片、音频、视频；生成图片和 TTS 也通过 blocks 返回。部分 TTS 返回 raw PCM，需要应用添加 WAV header。 ## Azure、Bedrock、IBM 与 Cohere - Azure Managed Identity 用 `DefaultAzureCredential` + bearer token provider；生产不应长期保存 API key。自定义域需要 `azureOpenAIBasePath`，`api-key` header 不能被普通 custom header 覆盖。 - Bedrock 可使用 access/secret/region 或 bearer token；开通模型访问与 IAM 权限是初始化的一部分。并非所有模型支持 tool calling。 - IBM 有 IAM、bearer token、CP4D 软件认证与 model gateway。认证方式、project/deployment/space 与 gateway alias 必须作为不同部署 profile 管理。 - Cohere 接受 custom `CohereClient` 以连接 Azure、Bedrock 或独立部署；提供 client 后环境 key 和 constructor key 会被忽略。RAG documents 与 web connector 是 provider-native invocation options，需单独记录引用与计费。 ## OpenRouter - `provider.order/only/ignore/sort` 控制上游；`data_collection: "deny"`、quantization 和 `require_parameters` 应进入显式策略，不依赖平台默认值。 - multi-model fallback 时实际模型能力未知，structured output 会回退到 function calling。路由提高可用性，同时扩大数据处理方、模型漂移和结果不一致风险。 - plugins 包括 web、file parser、moderation、auto-router、response-healing；每个插件都是新的数据出口和失败面。 - 生产日志必须记录最终上游 provider/model、fallback 次数和计费，而不只记录 OpenRouter 名称。 ## 上线验证 对每个固定模型至少验证普通 invoke、stream abort、tool 参数校验、structured schema 失败、多模态大小边界、429/5xx 重试、usage 汇总与 provider request id。高级能力必须在锁定 npm 版本后执行真实 API smoke；静态 feature table 只能用于筛选候选。