Getting Started with LangChain: LLM Limitations, Agent Principles, and Environment Setup in Practice

Why We Need a Framework Like LangChain

To understand the value of LangChain's existence, we must first recognize the three inherent limitations of large language models (LLMs) themselves. This underlying logic is a required course for beginners in AI application development and is worth systematically reviewing.

First, knowledge has a time cutoff. LLMs are trained on data up to a certain point in time. Events and knowledge beyond the training cutoff date are completely unknown to the model.

Background: Why does model knowledge "expire"? LLMs are pre-trained on massive text corpora, "compressing" world knowledge into the model in the form of parameter weights. But this process is one-time—once training is complete, the model parameters are frozen and knowledge is no longer updated. This is fundamentally different from how search engines crawl and index in real time. Take GPT-4 as an example: its knowledge cutoff date is April 2023; DeepSeek-V3's cutoff is around July 2024. This means the model cannot answer any events that occurred afterward through "memory"—it can only rely on external tools to inject real-time information.

Second, LLMs have no memory. This is the most common misconception among beginners. If you tell the model "My name is Zhang San," it can respond "Hello, Zhang San"; but if you simply call the model again in the next round of conversation, it won't remember that your name is Zhang San. The chat products we use daily maintain context by having the application layer manage the message history itself, not because the model has memory.

Background: The principle behind stateless APIs and conversation context LLM API calls are essentially "stateless" HTTP requests—each call is an independent transaction, and the server does not retain any session information. The "coherent conversation" we experience when using ChatGPT or Claude daily is achieved by the application layer concatenating the message history into an extremely long Prompt and passing it into the model as a whole. Specifically, the complete conversation history (with SystemMessage, HumanMessage, and AIMessage alternating) is fed in as the context window, and the model generates its reply on this basis. This also explains why conversation length is limited by the model's "Context Window" size, which ranges from 32K to 200K tokens across mainstream models.

Third, LLMs cannot access business-specific data. Model knowledge has a cutoff point. To serve a specific business, you must actively "feed" it business data—this is exactly where the concept of Tool Calling comes from: using tools to let the model access external knowledge during inference.

Background: The technical principle of tool calling Tool Calling (early on also called Function Calling) is a capability first introduced by OpenAI in 2023 and has now become a standard feature of mainstream models. It works as follows: when the developer calls the model, a list of tool definitions (including tool name, function description, and parameter schema) is attached along with the Prompt. If the model determines during inference that it needs to call a certain tool, it returns a structured call instruction in its output rather than a direct answer. The application layer parses this instruction, executes the corresponding tool (such as querying a database or calling a weather API), and then passes the result back into the model as a ToolMessage. The model finally generates a complete reply based on the tool's return value. This "model → tool → model" loop is the foundation of an Agent's multi-step reasoning.

It is precisely to systematically solve these three major problems—memory management, tool calling, and context/state maintenance—that AI application development frameworks like LangChain emerged. Its positioning is very clear: LangChain is a framework for developing AI applications, with similar products including the Claude SDK, OpenAI SDK, and others.

Core Features and Technology Choices of LangChain

Why Python Instead of Java

Learning LLM application development is not the same as studying algorithms. The current mainstream work in enterprises is integrating existing LLM capabilities into business and building AI applications, rather than training models from scratch.

When it comes to language choice, over 90% of projects in the industry choose Python, for two reasons:

• Private deployment is a hard requirement: Private deployment of LLMs relies heavily on the Python ecosystem (such as inference frameworks like vLLM), and the corresponding toolchain is virtually nonexistent in the Java ecosystem.
• First-mover advantage in framework ecosystem: LangChain / LangGraph were among the first batch of mature AI application frameworks. Almost all newly released LLM APIs prioritize adapting to the LangChain ecosystem, and community resources are more abundant.

Background: vLLM and the private deployment ecosystem vLLM is a high-performance LLM inference engine developed by UC Berkeley, designed specifically for production-grade deployment on GPU clusters. Its core innovation is PagedAttention technology, which manages the KV Cache in GPU memory analogously to an operating system's virtual memory paging, greatly improving memory utilization and concurrent throughput. In private deployment scenarios, enterprises typically need to deploy open-source models (such as Llama, Qwen, DeepSeek, etc.) on their own servers to meet data security and compliance requirements. Python is the only supported language for inference frameworks such as vLLM, Ollama, and TGI (Text Generation Inference), which is one of the fundamental reasons why AI application development relies heavily on the Python ecosystem.

Two Core Framework Features

Unified model interface: In the past, calling LLMs from different vendors meant each had a different interface, and switching models required changing code. With LangChain, you only need to replace the model name—the upper-level business logic requires no changes, and the framework automatically handles compatibility adaptation across vendors.

Modular architecture: LLM applications involve many components such as state management, message history, tool calling, RAG retrieval, prompt engineering, middleware, and more. LangChain breaks all these capabilities into modular components, allowing developers to combine them as needed and reducing system complexity.

Background: RAG (Retrieval-Augmented Generation) RAG (Retrieval-Augmented Generation) is the mainstream technical approach to solving the problems of LLM knowledge timeliness and business-specific data. Its core idea is: during model inference, it first uses vector retrieval to find the document fragments most relevant to the user's question from an external knowledge base, then injects these fragments into the Prompt as context, allowing the model to generate answers based on "facts retrieved in real time" rather than solely relying on the parametric knowledge compressed during training. The RAG process typically includes five steps: document chunking, vector embedding, vector database storage, semantic retrieval, and Prompt assembly. LangChain provides complete modular support for this entire process, which will be a key focus of subsequent hands-on work.

Environment Setup and API Configuration

The recommended development environment is PyCharm + Python 3.13, along with LangChain 1.3.2 and LangGraph 1.2.x.

The configuration steps are as follows:

1. Create a .env file in the project root directory. At its core, you only need to configure two items: DEEPSEEK_API_KEY and DEEPSEEK_BASE_URL.
2. Log in to the DeepSeek official website, create a new key on the API Keys page, and find the corresponding Base URL in the API documentation.
3. Use python-dotenv to load the .env file, reading the configuration into environment variables for code to use.

Background: Why use a .env file to manage keys? In AI application development, API Keys are highly sensitive credential information. Hardcoding them directly in source code poses serious security risks—once code is committed to a public repository (such as GitHub), the key immediately faces the risk of exposure. The industry-standard practice is to write all keys and configurations into a .env file and explicitly exclude the file in .gitignore so that it never enters version control. The python-dotenv library uses the load_dotenv() function to inject key-value pairs from .env into the current process's environment variables, and the code reads them via os.getenv('DEEPSEEK_API_KEY'), achieving a complete separation of configuration and code. This pattern shares the same design philosophy as production-grade key management solutions such as Kubernetes Secret and AWS Secrets Manager.

The tutorial uses DeepSeek as an example, but the same approach supports mainstream models including OpenAI, Anthropic, Tencent Hunyuan, Alibaba Tongyi Qianwen, Zhipu, and others—switching only requires changing the vendor identifier and API Key.

Initializing the LLM: A Detailed Look at init_chat_model

Once the configuration is ready, use LangChain's officially recommended general-purpose method init_chat_model to initialize the model:

from langchain.chat_models import init_chat_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"}}
)

There is one key parameter here that needs special explanation: in extra_body, thinking is set to disabled, meaning the thinking (reasoning) mode is turned off. The reasons are as follows:

• Performance considerations: When Thinking mode is enabled, the model must first go through a thinking process before producing output, which noticeably slows down response speed. For building agents or general AI applications, the vast majority of business scenarios do not require deep reasoning. The current DeepSeek Pro version is already capable enough on its own, and Chat mode's accuracy fully meets requirements in most scenarios.
• Compatibility issues: Currently, LangChain's support for thinking mode is not yet mature, and enabling it may cause unexpected exceptions.

General-Purpose Approach vs. Specific Model Classes

In addition to the general-purpose init_chat_model, LangChain also provides vendor-specific model classes such as ChatDeepSeek and ChatOpenAI. The general-purpose approach is recommended first—it is compatible with all mainstream vendors and has extremely low code migration cost. Only consider using specific model classes when working with custom models or when a certain model is not supported by the general-purpose approach.

Calling the Model and the Four Types of Messages

After initialization, you can make a call using the invoke method:

response = deepseek_llm.invoke("请介绍一下自己")
print(response)
print(type(response))

The returned content is in Markdown format by default. Directly using print offers limited readability, but combined with front-end Markdown rendering, the result is excellent—this is also a capability that subsequent web projects will focus on demonstrating.

The type of the returned object is AIMessage. Understanding LangChain's message system is the key step in moving from "calling the LLM" to "building an Agent." Under langchain_core.messages, there are mainly four types of messages:

• SystemMessage: The system prompt, used to set the model's role and behavioral boundaries
• HumanMessage: User input; during a call, the framework automatically wraps a string into a HumanMessage
• AIMessage: The reply content returned by the model
• ToolMessage: The result returned by a tool call—the core message type for subsequent Agent development

Background: The origins of LangChain message types and OpenAI's message format LangChain's four message types were not designed out of thin air but are an abstract encapsulation of the OpenAI Chat Completions API message format. The OpenAI API defines four roles—system, user, assistant, and tool—which correspond one-to-one with LangChain's four message types. This format later became the de facto standard, and almost all mainstream LLMs (including Anthropic Claude, Google Gemini, DeepSeek, Qwen, etc.) are compatible with this message structure. On this basis, LangChain provides object-oriented Python class encapsulation, allowing developers to organize conversation context in a strongly typed manner, while the framework automatically handles format conversion when calling different vendors' APIs, hiding the underlying differences.

Mastering the semantics and use cases of these four message types is the foundation for building any LangChain application.

From LLM to Agent: Core Differences and Next Steps

The focus of this tutorial series is Agent development. LLMs solve the problem of "whether it can speak"—performing probabilistic reasoning based on training data; whereas Agents build on this by adding capabilities such as tool calling, memory management, and multi-step planning, enabling AI to actually complete specific business tasks.

Simply put: the LLM is responsible for "thinking," and the Agent is responsible for "doing."

Background: The architectural evolution of Agents The concept of an Agent originates from the "autonomous decision-making entity" in AI research and has been redefined in the era of large models. The current mainstream LLM Agent architecture follows the "ReAct" paradigm (Reasoning + Acting), proposed by DeepMind in 2022: the model alternates through a loop of "Thought → Action → Observation" until it completes the target task. LangGraph is a graph computation framework introduced by the LangChain team for complex Agent scenarios. It models the Agent's workflow as a directed graph (nodes are processing steps, edges are state transition conditions), supporting complex control flows such as loops, conditional branching, and parallel execution. Compared with the earlier linear Chain, it is better suited for building production-grade Agent systems involving multi-step, multi-tool collaboration.

Having understood the three major limitations of LLMs, as well as how LangChain compensates for these shortcomings through a unified interface and modular architecture, you have laid a solid foundation for subsequent hands-on Agent work and RAG retrieval-augmented projects. For engineers hoping to get started with AI application development, becoming proficient in using init_chat_model and understanding the semantics of the four Message types is an unavoidable first lesson.

Key Takeaways