Getting Started with LangChain: LLM Invocation, Agent Practice, and Environment Setup Guide

Why We Need a Framework Like LangChain

To understand LangChain's value, we first need to talk about the inherent limitations of Large Language Models (LLMs) themselves. At its core, an LLM is a conversational system that performs probabilistic reasoning based on training data—you ask, it answers. It seems intelligent, but in reality there are three unavoidable shortcomings.

Some background is worth knowing first: mainstream LLMs are built on the Transformer architecture. Through pre-training on massive amounts of text, they compress knowledge in the form of statistical patterns into billions or even trillions of model weights. The Transformer was proposed by Google in the 2017 paper "Attention Is All You Need," and its core innovation is the self-attention mechanism, which allows the model to dynamically focus on information at different positions when processing sequences—fundamentally solving the problem that earlier RNN/LSTM architectures struggled to capture long-range dependencies. During the pre-training phase, the model learns language patterns from massive text and fixes world knowledge into the form of weight parameters—this means updating knowledge requires retraining or fine-tuning; it cannot be written in real time like a database. This design of "knowledge fixed in the weights" is an essential characteristic of the LLM architecture rather than a flaw in engineering implementation, which naturally gives rise to the following three major limitations.

First, knowledge has a temporal boundary. The model only possesses knowledge up to its training cutoff point and knows nothing about events afterward. The mainstream engineering solution to this problem is Retrieval-Augmented Generation (RAG): when a user asks a question, relevant document snippets are first retrieved from an external knowledge base, then these snippets are fed into the model along with the question, allowing the model to generate answers based on real-time retrieved content rather than relying solely on static knowledge from training. The core dependency of RAG is the vector database (such as Pinecone, Chroma, Weaviate, Milvus), which converts text into high-dimensional dense vectors and builds an approximate nearest neighbor (ANN) index, making "retrieval by semantic similarity" possible—unlike traditional keyword search, vector retrieval can find documents with similar meaning but different wording. LangChain provides a complete abstraction layer for the RAG workflow, including document loaders (DocumentLoader), text splitters (TextSplitter), and a unified vector store interface (VectorStore), so developers can build an end-to-end knowledge Q&A system without worrying about the differences among underlying vector libraries. Second, the model itself has no memory. If you tell it "My name is Zhang San," and in the next round ask "What's my name?", a pure LLM cannot remember, because it lacks persistent storage capability—every conversation is a brand-new, stateless request as far as the model is concerned. This characteristic stems from the Transformer's inference mechanism: each forward pass starts from a blank context, and the intermediate state from the previous call is not retained inside the model; it must be explicitly maintained by an external system. Third, it cannot access business data, and therefore cannot truly serve specific enterprise scenarios.

It is precisely these three pain points that gave rise to AI application development frameworks represented by LangChain. The framework helps you systematically manage memory, maintain contextual state, and bind and invoke external tools, so developers don't need to handle these low-level details from scratch. It's worth emphasizing: learning LLM application development is not the same as researching algorithms. The capabilities of LLMs are already there; what we need to do is better embed these capabilities into business and build AI applications that can truly be deployed.

LangChain's Core Positioning and Advantages

LangChain is essentially a framework for developing AI applications. It was born in late 2022, right in time for the AI application boom triggered by ChatGPT, and with its active community and continuous iteration, it quickly became the de facto standard in the field of AI application development. Similar products include the OpenAI SDK and the Anthropic (Claude) SDK, but in enterprise practice, LangChain and its accompanying LangGraph ecosystem have the highest adoption rate.

LangGraph is an extension of LangChain, focused on building stateful, cyclic multi-agent workflows. It builds workflows based on the concept of a directed acyclic graph (DAG), where nodes represent computation steps and edges represent data flow paths, supporting conditional branching and loop structures. This design draws on ideas from functional programming and dataflow programming, making complex multi-agent collaboration possible—for example, one agent handles searching, another handles summarizing, and a third handles quality review, forming a pipeline. Unlike simple chain calls, LangGraph's state machine design lets the workflow dynamically adjust its execution path based on intermediate results, capable of handling complex business scenarios that require multi-step reasoning and loop validation. Together, LangChain and LangGraph form the most complete AI application development ecosystem to date.

Why do most people choose Python over Java? There are two reasons: First, almost all private deployments of LLMs (such as via vLLM) depend on the Python ecosystem, and Java lacks the corresponding frameworks. vLLM is a high-performance LLM inference engine developed by UC Berkeley. Its core innovation, PagedAttention, likens GPU memory management to an operating system's paged memory, splitting the KV Cache into fixed-size physical blocks allocated on demand, significantly improving concurrent inference efficiency and memory utilization—in high-concurrency scenarios, throughput can be several times higher than naive implementations. And it depends entirely on the Python ecosystem; CUDA bindings, Triton kernels, and the PyTorch backend all lack mature Java alternatives. Second, LangChain/LangGraph were among the earliest batch of AI application frameworks, and almost all newly released LLM APIs prioritize adapting to this ecosystem, forming a strong network effect.

The framework's core features can be summarized in two points:

Unified Model Interface

In the past, calling LLMs from different vendors meant each vendor had a different interface, and switching models required rewriting code. LangChain provides a unified invocation method—you only need to replace the model name, and the upper-layer code requires no changes; the framework automatically handles compatibility with each vendor's models. This is thanks to LangChain's unified internal encapsulation of various vendor SDKs: whether OpenAI, Anthropic, or domestic ones like DeepSeek and Tongyi Qianwen, all are abstracted into the same set of interfaces, making switching costs extremely low. This design pattern is called the "Adapter Pattern" in software engineering, with LangChain acting as an intermediate layer that translates the differentiated APIs of various vendors into a standardized invocation contract. From a broader perspective, this unified interface design also reduces enterprise dependence on a single model vendor—when a vendor raises prices, has unstable service, or a better alternative appears, the switching cost is nearly zero, which has significant strategic value commercially, and is an important consideration for large enterprises adopting LangChain to build AI infrastructure.

Modular Architecture

The state, context, message history, tool calls, prompts, middleware, and other elements involved in LLM interaction are all split into independent modules in the framework. This design allows features such as agents, tool calling, and memory management to be flexibly combined—developers can assemble the capabilities they need like building blocks, without worrying about low-level implementation details. It's worth mentioning that LangChain's modular design to some extent follows the pipeline philosophy of LCEL (LangChain Expression Language)—using the | operator to chain different components together, forming a processing chain from prompt to model to output parser, making the data flow clear and readable, while naturally supporting asynchronous execution and streaming output to meet production environment performance requirements.

The versions used in this article are LangChain 1.3.2 and LangGraph 1.2, with a development environment of PyCharm + Python 3.13.

Environment Setup and API Key Preparation

Before starting to code, you need to configure the Python environment in your project and introduce a .env file to manage keys. Although there are many configuration items in the example, only two are truly required: DEEPSEEK_API_KEY and DEEPSEEK_BASE_URL.

The way to obtain them is straightforward: log in to the DeepSeek official website, go to the API Keys page to create a new key, and at the same time find the corresponding Base URL in the API documentation, then fill both into .env. Of course, DeepSeek is just an example choice; you can also switch to any vendor such as OpenAI, Anthropic, Tencent Hunyuan, Alibaba Tongyi Qianwen, or Zhipu.

Using a .env file instead of hardcoding keys is a basic security norm in engineering practice—once a key is committed to a Git repository along with the code, it can easily be leaked. This is known in the industry as the "Secret Leakage" problem; GitHub's official statistics show that millions of API keys are exposed this way every year, resulting in unexpected bills at best and data security incidents at worst. In the code, the dotenv library loads the .env file, reading the configured keys as environment variables for use when initializing the model later. The .env file itself should be added to .gitignore, existing only in local and production environments, and never committed to version control. In team collaboration scenarios, an additional .env.example file is usually provided, listing all the variable names that need to be configured but without filling in the actual values, serving as a configuration template distributed alongside the codebase, so new members can quickly understand which keys they need to apply for—this is a widely adopted convention in engineering practice.

Initializing and Invoking the LLM

LangChain provides a universal model initialization method init_chat_model, which is also the most recommended approach. Core parameters include the model name, model provider, API Key, and Base URL.

The example uses the DeepSeek V4 Pro model, with the provider set to deepseek. Here there's a parameter worth noting—by setting the thinking type in extra_body to disable, you can turn off thinking mode.

Why It's Recommended to Turn Off Thinking Mode

DeepSeek has launched a new model lineup: the original deepseek-chat is a non-reasoning model, while deepseek-reasoner is a reasoning model with a thinking process; the Flash version corresponds to thinking mode, and the Pro version has stronger capabilities. So-called "thinking mode" is essentially the engineering implementation of Chain-of-Thought (CoT) technology. This method was systematically proposed by the Google Brain team in the 2022 paper "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models," with the core idea of having the model explicitly generate intermediate reasoning steps before outputting the final answer, simulating the human process of "working through a draft" when solving a problem. Research shows that CoT can improve accuracy by dozens of percentage points on tasks such as mathematical reasoning, logic puzzles, and multi-step problems, especially on models with large enough parameter counts. However, the cost is a significant increase in token consumption—the thinking process itself occupies a large amount of the context window, and a single inference may generate thousands or even tens of thousands of thinking tokens, directly driving up API call costs and increasing response latency. In LLM billing models, input tokens and output tokens are usually priced separately, and the tokens generated by the thinking process are output tokens. Looking at the pricing structures of mainstream vendors like DeepSeek, the unit price of output tokens is often several times that of input tokens, meaning that enabling thinking mode may cause the cost of a single call to multiply, imposing significant pressure on cost control in high-concurrency production environments. There are two reasons to recommend turning off thinking:

• Performance consideration: With thinking mode enabled, reply speed is noticeably slower, and most agent building or simple LLM applications don't require deep reasoning. For most scenarios, DeepSeek Flash is already accurate enough.
• Compatibility consideration: LangChain's current compatibility with thinking mode is not yet fully mature, and unexpected issues may occur.

When switching to models from other vendors, you only need to modify the provider name, API Key, and Base URL—the changes are minimal.

Detailed Explanation of Invocation Methods and Message Types

After the model is created, you can initiate a call via the invoke method. For example, passing in "Please introduce yourself," the model will return a result, and the returned content is in Markdown format by default—readability is average when printed directly, but the display effect is excellent after rendering.

The type of the returned object is AIMessage, which is key to understanding LangChain's message system. LangChain's message type design references the role division of the OpenAI Chat Completions API—this API divides conversation participants into three roles: system (system-level instructions, highest priority), user (user input), and assistant (model reply). This design later became an industry de facto standard, and mainstream vendors such as Anthropic and Mistral all adopt a compatible format. It's worth mentioning that the system role's instructions enjoy the highest priority during model processing—even if the user subsequently tries to override system instructions through conversation, the model usually still follows the system-level constraints—which is precisely the core mechanism enterprises use to define the behavioral boundaries of the model when deploying AI applications. LangChain abstracts this role system into framework-agnostic message classes: SystemMessage, HumanMessage, and AIMessage correspond to the three roles respectively, thereby achieving cross-vendor compatibility—no matter which vendor's model is called at the bottom, the upper-layer code interacts using the same set of message types. In addition to AIMessage, the framework has several other core message types:

• SystemMessage: The system prompt is stored here, used to set the model's role, behavioral norms, or background information, and is usually fixed in each round of conversation.
• HumanMessage: User input. What you write, "Please introduce yourself," is automatically wrapped into a HumanMessage at the bottom.
• ToolMessage: The message returned by a tool call, closely related to the agent's tool capabilities. An agent's tool calling is essentially an application-layer abstraction of the Function Calling mechanism—OpenAI formally introduced this capability in the GPT-3.5/4 series in 2023, allowing the model to output a structured function call intent (including the function name and parameters) before generating a reply. After the external system actually executes it, the result is injected into the context in the form of a ToolMessage for the model to synthesize the final reply. This mechanism opens up the interaction channel between the LLM and the external world: search engines, database queries, code executors, internal enterprise APIs, and even any capability that can be encapsulated as a function can be invoked by the LLM on demand via Function Calling. LangChain uniformly encapsulates the different implementations of Function Calling across vendors into a Tool interface, shielding low-level differences, so developers only need to define the tool's name, description, and input schema, and the framework automatically handles the interaction protocol with the model.

This division of message types is a direct embodiment of LangChain's modular design, and is also the foundation for subsequently building agents, implementing memory management, and tool calling.

Additional Notes on Model Classes

Besides the universal init_chat_model, the new version of LangChain also provides model classes for specific vendors, such as ChatDeepSeek, ChatOpenAI, etc. The recommendation is clear: prefer the universal approach, as it is already compatible with the vast majority of vendors. Only when you use a custom model, or a model that certain universal interfaces do not support, do you need to use the specific model class.

Summary

Starting from the three major limitations of LLMs, this article laid out LangChain's core value as an AI application development framework, and walked through the complete getting-started process from environment setup, API key preparation, and model initialization to actual invocation. After mastering the basic LLM invocation and message system, the next step is to deeply understand the essential difference between agents and LLMs—which is precisely the starting point of where LangChain's true power lies. For developers who hope to deploy AI capabilities into real business, laying this foundation is crucial.

Key Takeaways