LangChain Unified Interface in Practice: init_chat_model Usage & DeepSeek Troubleshooting Guide

Why 90% of LLM Companies Choose Python + LangChain

In the field of LLM application development, Python has become the dominant language. According to industry observations, approximately 90% of companies working with large language models use Python for development, with LangChain and LangGraph being the most commonly used frameworks. Although languages like Java and TypeScript are gradually improving their support for LLM technologies, Python's ecosystem still holds a clear advantage in keeping up with the latest features.

The reason Python holds this position is rooted in over a decade of ecosystem accumulation in the machine learning field. After the deep learning wave began in 2012, scientific computing libraries like NumPy, SciPy, and Pandas had already taken deep root in the Python ecosystem. Subsequently, TensorFlow (2015) and PyTorch (2016) both chose Python as their primary interface, further cementing Python's dominance in AI. When the era of large language models arrived, Hugging Face's Transformers library and OpenAI's official SDK were both Python-centric, creating a powerful network effect — new frameworks and models almost invariably support Python first, with bindings for other languages often lagging by weeks or even months. This is the fundamental reason why Python's ecosystem consistently leads in supporting the latest features.

LangChain, an open-source framework for developing AI applications, was released in October 2022 by Harrison Chase. Its core design philosophy stems from the "Adapter Pattern" in software engineering. Facing dozens of LLM providers each with their own API designs, LangChain encapsulates these differences within an abstraction layer while exposing a unified calling interface — much like how JDBC unified database access and ODBC unified data source access historically. Its core value lies in providing a unified interface for models. When developers use LLMs from different providers (DeepSeek^Ad, OpenAI, Anthropic, Qwen, Zhipu, etc.), they only need to write code following a unified paradigm and switch the underlying model without maintaining separate calling logic for each provider. Beyond the unified model interface, LangChain also provides core abstractions like Chain (chained calls), Memory (conversation memory), Tools (tool calling), and Retriever, enabling developers to compose complex AI application logic like building blocks.

Two Ways to Create Models: Model Classes vs init_chat_model Unified Interface

Model Class Approach (Not Recommended)

In the latest version of LangChain, there are two ways to create LLM objects. The first is the model class approach, which uses a provider-specific class for each vendor:

• DeepSeek → ChatDeepSeek
• OpenAI → ChatOpenAI
• Anthropic → ChatAnthropic

Before using them, you need to prepare a .env file in your project, configure each provider's API Key and Base URL, and then load these configurations through environment variables. The code roughly looks like this: import the model class from the corresponding package, specify the API Key, Base URL, and model name, then create a model object and call it via the invoke method.

However, this approach is not recommended for production projects, mainly for two reasons:

1. High cognitive overhead: Different providers have different class names. Switching models requires changing import paths and class names, leading to high maintenance costs.
2. Compatibility issues: Objects created with model classes may return complex nested structures inconsistent with standard structures when used in AI Agents or LangGraph, causing frequent parsing errors.

init_chat_model Unified Interface (Recommended)

The second approach is the init_chat_model unified interface introduced in newer versions of LangChain, which is also the officially recommended method. It provides unified compatibility across providers with a very concise usage:

from langchain.chat_models import init_chat_model

deepseek_llm = init_chat_model(
    model="deepseek-v4-pro",
    model_provider="deepseek",  # Can also use "openai", or omit to let the framework auto-detect
    api_key=DEEPSEEK_API_KEY,
    base_url=DEEPSEEK_BASE_URL
)

The model_provider parameter supports a wide range of providers: OpenAI, Anthropic, Google, Amazon, Ollama, Hugging Face, Groq, and more. For some domestic Chinese providers not directly included (such as Zhipu), using openai as the provider also works fine. There's an important industry context behind this: the Chat Completions API format introduced by OpenAI in 2023 has de facto become the industry standard for LLM interfaces. This protocol defines core elements such as the messages array structure (role/content fields) in request bodies, SSE format for streaming output, and parameter specifications for function calling. Major domestic providers including Zhipu AI, Baidu Wenxin, Alibaba Qwen, and Moonshot (Kimi) all provide OpenAI-compatible endpoints alongside their own APIs — developers only need to replace the base_url and api_key to switch seamlessly. This standardization is similar to how HTTP unified web communication and is becoming the de facto specification for the LLM calling layer. This is the fundamental reason why most domestic providers are compatible with the OpenAI interface protocol.

The biggest benefit of using init_chat_model is: switching models only requires changing the model and model_provider parameters — the rest of the code stays completely unchanged, dramatically reducing the development cost of multi-model switching.

DeepSeek V4 Pro Thinking Mode Pitfall: The Hidden Switch You Must Disable

Here's a highly practical troubleshooting tip: DeepSeek V4 Pro has thinking mode enabled by default, which causes serious problems within the LangChain framework.

Thinking Mode is essentially a mechanism where the model outputs an internal reasoning process before generating the final answer, academically known as "Chain-of-Thought" (CoT). This technique was systematically proposed by the Google Brain team in their 2022 paper Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, and has been proven to significantly improve model performance on complex tasks like mathematical reasoning and logical judgment. DeepSeek's R series and V4 Pro internalize CoT reasoning as the model's default behavior, returning the reasoning process via a separate thinking field at the API level.

However, this design introduces severe challenges during framework integration, specifically:

• Extremely slow response: With thinking mode enabled, even simple questions require significantly longer wait times.
• Poor framework compatibility: LangChain's Message Parser and AgentExecutor are designed around the standard content field. The presence of the thinking field breaks the expected message structure format, causing tool call parameter extraction failures or incorrect loop termination condition judgments, resulting in frequent errors during Agent execution loops or tool calling processes.

The solution is to explicitly disable thinking mode via the extra_body parameter when creating the model:

deepseek_llm = init_chat_model(
    model="deepseek-v4-pro",
    model_provider="deepseek",
    api_key=DEEPSEEK_API_KEY,
    base_url=DEEPSEEK_BASE_URL,
    extra_body={
        "thinking": {
            "type": "disabled"
        }
    }
)

The root cause of this issue is that DeepSeek V4 Pro was only released at the end of April 2025, and the LangChain framework has not yet fully adapted to its thinking mode feature — this is a typical adaptation time-lag problem between new model capabilities and mature frameworks, which is extremely common in today's rapidly iterating AI landscape. It is recommended that developers universally disable thinking mode at this stage and wait for framework updates before considering re-enabling it, to ensure stable Agent workflow execution.

AI Agent in Practice: Deep Integration with Existing Business

A common misconception is viewing AI applications as standalone technologies. In reality, AI applications must serve existing business needs.