Bin✳

学习笔记 · Obsidian

Chat 模型：主流云与高级能力

LangChainTypeScript
来源更新 2026-08-11下载 Markdown ↓

能力矩阵

下表来自各组件页的标准 feature table；“I/A/V”依次为图片、音频、视频输入。勾选表示 wrapper 支持，仍需用目标模型和端点验证。

类 / 包认证ToolStructuredI/A/VStreamUsage / Logprobs状态与重点
ChatAnthropic / @langchain/anthropicANTHROPIC_API_KEY✅✅✅/❌/❌✅✅/❌serializable；content blocks、citations、prompt cache、context editing
AzureChatOpenAI / @langchain/openaiAzure key 或 Managed Identity✅✅✅/❌/❌✅✅/✅deployment + API version；可自定义域和 header
ChatBedrockConverse / @langchain/awsAWS region + identity✅✅✅/❌/❌✅✅/❌模型级能力差异；可用 Bedrock bearer token
ChatCohere / @langchain/cohereCOHERE_API_KEY 或 custom client✅✅❌/❌/❌✅❌/❌serializable 标为 beta；原生 RAG documents/connectors
ChatGoogle / @langchain/googleAI Studio key、Vertex Express key、ADC/credential✅✅✅/✅/✅✅✅/✅新项目推荐；统一 AI Studio/Vertex；图像生成和 TTS
ChatGoogleGenerativeAI / @langchain/google-genaiGOOGLE_API_KEY✅✅✅/✅/✅✅✅/❌旧包 LTS，底层 SDK 已弃用，不再获新特性
ChatVertexAI / @langchain/google-vertexaiADC / web credential✅✅✅/✅/✅✅✅/✅旧 Node 包；Web/Edge 使用 google-vertexai-web
ChatWatsonx / @langchain/ibmIAM、bearer token 或 CP4D✅✅✅/❌/❌✅✅/❌model gateway、软件部署、多认证形态
ChatMistralAI / @langchain/mistralaiMISTRAL_API_KEY✅✅✅/❌/❌✅✅/❌不可序列化；HTTP lifecycle hooks
ChatOpenAI / @langchain/openaiOPENAI_API_KEY✅✅✅/❌/❌*✅✅/✅Responses API、built-in tools、strict schema、cache、audio 章节
ChatOpenRouter / @langchain/openrouterOPENROUTER_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 只能用于筛选候选。

← 继续探索AI 与智能体回到顶部 ↑