Getting Started with LangChain 1.3: Core Concepts of LLMs and Agents

Why Everyone Is Learning LangChain Right Now

In the field of AI application development, a clear trend is emerging: more and more job postings explicitly list keywords like large language models, LangChain, and LangGraph in their requirements. Many engineers with years of experience in front-end development, testing, or general software development find, when switching jobs or looking for work, that nearly every relevant position on the market requires proficiency in LLM application development—and most of these revolve around the LangChain and LangGraph ecosystems.

What lies behind this is a structural shift in the industry: large language models are no longer the exclusive domain of researchers, but are gradually evolving into an applied engineering capability. Mastering a framework like LangChain essentially means mastering the core tools for bringing LLM capabilities into real business scenarios.

The origins and rise of LangChain are worth understanding. It was created by Harrison Chase in October 2022 and initially released as an open-source project on GitHub. Its birth coincided perfectly with the explosion of LLM applications sparked by ChatGPT, and within just a few months it became one of the fastest-growing open-source projects on GitHub. LangChain's core design philosophy is "chaining"—combining different AI capability modules like building blocks to construct complex application workflows. This idea stems from the pipeline concept in functional programming: each processing step takes the output of the previous step as input, with each module having a single responsibility and clear boundaries. This design philosophy has decades of practical history in the Unix operating system's pipe operator (|). LangChain brought it into the AI application layer, allowing steps such as prompt templates, model invocation, output parsing, and tool execution to be freely combined and reused, dramatically lowering the barrier to developing complex AI workflows. It is precisely this approach of modularizing and standardizing complex engineering problems that made it rapidly become the de facto standard for AI application development, setting an open-source project record in 2023 with over 75,000 GitHub Stars.

A detail worth mentioning: the version issue. LangChain has now iterated to version 1.3, yet a large number of free tutorials on the market are still stuck on old versions like 0.2, 0.6, and 0.8. Here's a clear piece of advice: versions prior to 1.0 are no longer worth spending time learning, because the architecture and APIs have changed significantly, and learning them offers limited practical value. Learning should be based on the latest 1.3 version.

It's worth noting that LangChain's leap from 0.x to 1.x was not a simple accumulation of features, but a deep architectural refactoring. The team split all functionality that had previously been coupled into a single package into a three-tier structure: langchain-core (core abstractions), langchain-community (community integrations), and vendor-specific packages (such as langchain-openai). It also introduced LCEL (LangChain Expression Language) as a unified chaining syntax. LCEL is based on overloading Python's pipe operator (|), making a chained call like prompt | model | output_parser intuitively express the flow of data at the syntax level, while natively supporting asynchronous calls, streaming output, and batch processing—engineering capabilities that older versions could not provide.

Truly Understanding the Three Major Limitations of LLMs

To understand why a framework like LangChain is needed, we must first understand the capability boundaries of large language models (LLMs) themselves. As application developers, we don't need to dive deep into the algorithmic principles, but we must be clear about where the models fall short.

The essence of a large language model (LLM) is a probabilistic model trained on massive amounts of text data. It generates text by predicting the next word (Token). Architecturally, virtually all modern LLMs are based on the Transformer architecture, whose core mechanism—"self-attention"—enables the model to capture dependencies between any two positions in the text. The Transformer architecture was proposed by Google in the 2017 paper Attention Is All You Need, completely replacing the previously dominant recurrent neural networks (RNNs). The key to the self-attention mechanism is this: for every Token in a sequence, the model computes relevance weights against all other Tokens in the sequence, allowing it to "attend to" the global context when generating each word, rather than relying only on a local window. This mechanism grants LLMs powerful language understanding and generation capabilities. However, once training is complete, the model's parameter weights are frozen—its "knowledge" is statically encoded in billions or even hundreds of billions of parameters, and cannot automatically update as the external world changes. This fundamental characteristic gives rise to the following three engineering constraints.

Limitation 1: Knowledge Has a Cutoff Date

LLMs are trained on internet data up to a certain point in time. Events or new knowledge that occur after the training cutoff are entirely unknown to the model—this is the "knowledge cutoff" problem, and it's a hard constraint that must be faced when developing AI applications.

Take GPT-4 as an example: its training data cuts off in April 2023, meaning all events after that are "the future" as far as it's concerned. In enterprise application scenarios, this problem is even more pronounced—private knowledge such as business data, product information, and internal regulations is likewise absent from the model's training set.

The mainstream solution to this problem is RAG (Retrieval-Augmented Generation) technology: before the model generates an answer, it first retrieves relevant document fragments from an external knowledge base, then injects these fragments as context into the prompt, allowing the model to generate answers based on the latest and most relevant information. The RAG workflow is typically divided into two stages: in the indexing stage, documents are split into small chunks, which are then transformed into high-dimensional vectors by an embedding model and stored in a vector database; in the retrieval stage, the user query is likewise vectorized, and algorithms such as cosine similarity are used to find the most relevant document fragments, which are concatenated into the prompt.

Understanding this process requires an intuition for "vectorization": an embedding model maps a piece of text into a floating-point vector space of hundreds to thousands of dimensions, where semantically similar texts are closer together in this space. For example, the phrases "how to apply for sick leave" and "what is the sick leave process"—despite differing in wording—have a high cosine similarity between their vector representations, so they can match each other during retrieval. This semantic-based retrieval capability far exceeds the matching precision of traditional keyword search. RAG organically combines vector databases, embedding models, and generation models to achieve dynamic updating of the knowledge base at extremely low cost. It has become a standard architecture for enterprise-grade AI applications and is one of the core capabilities that LangChain focuses on supporting.

Limitation 2: The Model Itself Has No Memory

Many people have a misconception: since products like ChatGPT and DeepSeek can remember conversation content, the model must have memory. In reality, the LLM itself has no memory function. If you tell it "my name is Zhang San," it won't remember this in a subsequent independent conversation. The "memory" we normally experience is achieved at the application layer through means such as maintaining conversation history and context management—it's not a capability of the model itself.

Understood at a technical level, each call to an LLM API is essentially a stateless function call—the model receives input (the prompt) and returns output (the generated text), nothing more. The server retains no session state between requests; each call is completely independent. Statelessness is a fundamental principle of modern web services—it allows services to scale horizontally without depending on specific instances—but it also means that the responsibility for "memory" falls entirely on the caller (i.e., the application developer). The reason conversational products "have memory" is that the application layer concatenates the list of historical conversation messages into the context of each request, letting the model "see" the complete history within a single call.

This mechanism also directly introduces the concept of the context window—there is a clear upper limit on the length of text a model can process in a single call, measured in Tokens (e.g., GPT-4 Turbo supports 128K Tokens, roughly equivalent to 100,000 Chinese characters). A Token is not simply equivalent to a character or a word: for English, one Token is about 0.75 words; for Chinese, one character typically corresponds to 1-2 Tokens, depending on the tokenizer implementation. As the number of conversation turns increases, accumulated historical messages rapidly consume context capacity, and anything beyond the limit is truncated. How to efficiently manage information within a limited context—for example, by summarizing and compressing old messages, or extracting key entities to store in external memory—is one of the core challenges of AI application engineering, and it's precisely the problem that LangChain's memory management module focuses on solving.

Limitation 3: Cannot Directly Access Business Data

The model cannot access information after its training cutoff, nor can it directly read private business data. To make an LLM serve specific business scenarios, you need to bind tools to it, using tool calling (also known as function calling) to obtain additional knowledge and real-time data. Tool calling is essentially a structured output mechanism: the developer declares the names, descriptions, and parameter formats (usually defined by JSON Schema) of available tools in the prompt. The model decides whether to call a tool based on the user's intent and outputs structured call parameters. The application layer then performs the actual external operation (such as querying a database, calling an API, or executing code), and returns the result to the model for continued reasoning.

The emergence of tool-calling capabilities is a key turning point in the transformation of LLMs from "knowledge Q&A systems" to "autonomous execution systems." Take a practical scenario: a user asks "help me check today's weather in Beijing." The model itself cannot access the internet, but it can output a structured call instruction like {"tool": "get_weather", "params": {"city": "Beijing", "date": "today"}}. The application layer then actually requests the weather API, injects the returned result (such as "sunny, 25℃") into the subsequent conversation, and the model finally generates a natural language answer. The entire process is completely transparent to the user, yet it achieves a substantial extension of the model's capabilities.

These three limitations are precisely what constitute the fundamental reason for the existence of AI application frameworks like LangChain.

What Problem Does LangChain Actually Solve

Developing AI applications was extremely tedious in the early days—to compensate for the model's inherent shortcomings, developers had to build a large amount of infrastructure from scratch. LangChain arose against this backdrop; it is essentially an engineering framework designed specifically for AI application development.

In real enterprise environments, LangChain and LangGraph are the most widely used choices. It primarily solves the following core problems:

A Unified LLM Interface

In the era before frameworks, each LLM vendor had its own independent and different API interface, and switching models meant rewriting large amounts of code. LangChain provides a unified model interface layer, allowing developers to simply replace the model name while keeping the upper-layer business code almost unchanged, with the framework automatically handling compatibility with each vendor's LLM.

The value of this design is especially pronounced in the rapidly changing LLM market. LangChain currently officially supports over 80 model providers, including OpenAI, Anthropic, Google, Baidu, Alibaba, DeepSeek, and other mainstream vendors. A unified interface not only reduces migration costs but also makes multi-model comparison testing and on-demand switching possible—crucial for enterprises seeking to balance cost control and performance. From an architectural design perspective, this is essentially an embodiment of the Dependency Inversion Principle: upper-layer business logic depends on abstract interfaces rather than concrete implementations, making the replacement of the underlying model completely transparent to the upper layers. This principle comes from the SOLID principles of object-oriented design, which have been widely validated in traditional software engineering. LangChain successfully transplanted it to the cross-model compatibility scenario of AI applications, making engineering decisions like "develop with GPT-4 today, switch to DeepSeek tomorrow to reduce costs" extremely low-friction.

A Modular Engineering Architecture

LangChain modularizes the various components of an LLM application—state management, context, message history, tool calling, prompts, middleware, and more. This design makes complex AI application development clear and orderly, with each module fulfilling its own responsibility, dramatically reducing maintenance costs.

Memory and Context Management

To address the problem of the model "not remembering conversations," the LangChain framework provides systematic management solutions for short-term and long-term memory. Developers don't need to intervene manually—the framework automatically maintains conversation state and context, which is a key capability for building usable AI applications.

Short-term memory typically refers to the management of historical messages within a single conversation session. LangChain provides multiple strategies: retaining all historical messages in full (ConversationBufferMemory), keeping only the most recent N turns (ConversationBufferWindowMemory), automatically summarizing overly long history (ConversationSummaryMemory), and so on—developers can flexibly choose based on business needs. The summarization strategy is particularly noteworthy: it compresses old conversations into a brief summary by making a single LLM call, dramatically reducing Token consumption while losing minimal information, a common engineering tradeoff for long-conversation scenarios. Long-term memory involves persistent storage of user information across sessions, typically implemented with the help of vector databases (such as Chroma, Pinecone, Weaviate) or relational databases. LangChain provides out-of-the-box abstraction layers for both memory modes, hiding the underlying storage details.

Why AI Application Development Chooses Python Over Java

Regarding development languages, a common question is: why do mainstream AI application frameworks all use Python instead of Java? There are two main reasons:

The hard requirement of private deployment. The private deployment of all large models almost entirely relies on frameworks in the Python ecosystem (such as vLLM); there simply are no corresponding mature tools in the Java ecosystem.

vLLM is a high-performance LLM inference framework developed by UC Berkeley, optimized specifically for large-scale model deployment on GPU clusters. Its core innovations lie in two key technologies: Continuous Batching allows the inference service to dynamically insert new requests into a batch that is already being processed, greatly improving GPU throughput—traditional static batching requires waiting for an entire batch of requests to complete before processing the next batch, while continuous batching keeps GPU utilization near full capacity; PagedAttention borrows the paged memory management concept from operating system virtual memory, storing the KV Cache (key-value cache, used to store intermediate states that accelerate self-attention computation) non-contiguously in GPU memory, avoiding memory fragmentation, boosting memory utilization to near the theoretical limit, and increasing the number of parallel requests by 3-4x. The role of the KV Cache is this: when processing consecutive Tokens of the same conversation, there's no need to repeatedly compute the attention key-value pairs of the already-processed portion—they only need to be cached and reused, which is a core engineering technique for accelerating LLM inference. These low-level inference frameworks are deeply dependent on the Python and CUDA ecosystems and are highly integrated with scientific computing libraries like NumPy and PyTorch, where Java has virtually no competitiveness.

The first-mover ecosystem advantage. LangChain and LangGraph were among the earliest AI application frameworks to appear, and almost all newly released LLM APIs prioritize support for the LangChain ecosystem. Python has accumulated over 20 years of ecosystem advantage in the AI/ML field—from NumPy and SciPy to TensorFlow and PyTorch, and then to Hugging Face's Transformers library, the entire AI tech stack is built almost entirely around Python as its core language. This "ecosystem self-reinforcement" effect is especially evident in Python's AI domain: the more researchers publish results using Python, the more engineers will learn Python to reproduce those results; the more engineers master Python, the more inclined enterprises are to hire Python developers and adopt the Python tech stack, forming a positive flywheel. According to statistics, over 90% of relevant enterprises choose Python as their AI application development language.

From LangChain to DeepAgent: The Evolution of the Harness Architecture

In the current job market, the concept of "Harness architecture" appears frequently. It's an architectural philosophy encompassing a full set of mechanisms including context management, tool management, execution state management, context compression, prompt engineering, and more.

To understand this evolutionary thread, we first need to clarify the core concept of the Agent. An Agent refers to an AI system capable of autonomously perceiving its environment, making decisions, and taking actions. Unlike a simple Q&A model, an Agent has a "think-act-observe" loop capability, namely the ReAct framework (Reasoning + Acting, proposed by Google Research in 2022): the model first reasons about the current task (Reasoning) to produce an action plan; then executes a specific action (Acting), calling external tools (such as search engines, databases, code executors, APIs); and finally observes (Observation) the result returned by the tool, incorporating it into the context of the next round of reasoning. This "reasoning-acting-observing" loop iterates continuously until the model determines that the task is complete.

The design of the ReAct framework was inspired by research in cognitive science on human decision-making processes—when solving complex problems, humans likewise alternate between internal reasoning (thinking) and external actions (experimenting, querying), adjusting their strategies based on environmental feedback. The core contribution of ReAct is providing a structured paradigm for this process that can be executed by language models: the reasoning process is explicitly output in the form of a natural-language "chain of thought," actions are executed in the form of structured tool calls, and the two interweave to form a traceable, debuggable execution trace. This transparency is crucial for troubleshooting in production environments. The ReAct framework evolves LLMs from passive answerers into executors capable of autonomously decomposing goals, calling resources, handling exceptions, and ultimately completing complex tasks—the core design paradigm of modern AI Agents.

Building on this, LangGraph (launched by the LangChain team in 2024) uses a graph structure (directed graph) to orchestrate Agent workflows: nodes represent computation steps or Agent behaviors, edges represent the conditional logic of state transitions, and the running state of the entire workflow flows between nodes through a shared state object. Compared to a linear chain structure, LangGraph supports loop iteration (a node can point back to itself or an upstream node), conditional branching (dynamically choosing the next node based on the current state), and parallel execution (multiple subgraphs running concurrently), making it especially suitable for complex scenarios requiring multiple rounds of autonomous decision-making, such as multi-agent collaboration, task planning, and dynamic adjustment.

This graph structure design draws on the concepts of directed acyclic graphs (DAGs) and finite state machines (FSMs) from computer science, and makes a key breakthrough on this basis: LangGraph allows cycles to exist in the graph—i.e., it supports node loops—which enables the iterative pattern of "think-execute-reflect-re-execute" to be naturally expressed, without having to unfold each iteration into independent nodes as a DAG would. LangGraph also has a built-in persistent checkpoint mechanism, supporting the resumption of a workflow from a breakpoint and state rollback, which is crucial for reliability in production environments.

DeepAgent is precisely one implementation of the Harness architecture philosophy. It didn't emerge out of nowhere but is a highly encapsulated product built on LangChain and LangGraph—the underlying dependencies being precisely the two core concepts of LLMs and Agents. The evolutionary thread of the entire tech stack is: LLMs and Agents → LangGraph → DeepAgent, layer upon layer of encapsulation, each bearing different engineering responsibilities.

Although some argue that "LangGraph is no longer needed," in reality LangGraph remains an important underlying support for the entire tech stack. In complex workflow scenarios, its value is especially prominent, and the framework itself is irreplaceable.

The Complete LangChain 1.3 Learning Path

From the perspective of systematic learning, a complete LangChain 1.3 learning roadmap should cover the following modules: environment setup and framework characteristics, using Models, the core mechanisms of Agents, short-term and long-term memory management, Human in the Loop (HITL), safety Guardrails, context runtime management, and more.

Building on this, you also need to extend your learning to the following advanced topics:

• MCP Protocol: An open standard protocol released by Anthropic in late 2024 (Model Context Protocol), aimed at unifying the way AI models interact with external tools and data sources. MCP adopts a client-server architecture: the MCP Server encapsulates specific tools or data sources (such as file systems, databases, web search), and the MCP Client (usually an AI application) discovers and calls these services through a standardized protocol, with the entire process being independent of the specific model implementation. Just as the USB interface unified hardware connection standards, MCP provides AI applications with a standardized tool-calling interface, enabling seamless interoperability between models and tools from different vendors. From a more macro perspective, MCP attempts to solve the "fragmentation" problem of the AI tool ecosystem: before MCP appeared, each AI framework (LangChain, LlamaIndex, AutoGPT, etc.) had its own tool plugin format, forcing tool developers to repeatedly adapt for different frameworks, while users couldn't reuse tools across frameworks. By defining a framework-agnostic JSON-RPC protocol specification, MCP allows a tool to be implemented once and called by all MCP-supporting clients, eliminating the fragmentation problem where each framework operated in isolation and tool plugins couldn't be reused. Currently, hundreds of MCP Servers have been contributed by the open-source community, and MCP is becoming an important infrastructure standard for the AI application layer, as well as an important direction for expanding the LangChain ecosystem.

• RAG (Retrieval-Augmented Generation): Combines vector databases, embedding models, and generation models to solve the problems of accessing private knowledge and retrieving real-time information—the most common deployment paradigm for enterprise-grade AI applications. Advanced directions include hybrid retrieval (dense vector retrieval + sparse keyword retrieval), reranking, and multi-hop reasoning RAG. Hybrid retrieval combines the advantages of semantic vector retrieval (good at capturing semantic similarity) and sparse keyword retrieval such as BM25 (good at exact matching of specific terms), and has been proven in industry to significantly outperform a single method; reranking, on the other hand, uses a dedicated Cross-Encoder model to perform more fine-grained relevance scoring on query-document pairs among the candidate documents recalled by the initial retrieval, further improving the quality of the documents ultimately injected into the context.

• LangGraph Workflows: Used to build stateful, cyclic complex Agent workflows, supporting multi-agent collaboration and autonomous task planning scenarios. Mastering LangGraph's graph definitions, state management, conditional routing, and checkpoint persistence is essential for advanced AI application development.

The LangChain fundamentals alone can accumulate over 280 pages of detailed notes, with each knowledge point corresponding to a specific code example.

For beginners, a practical piece of advice is: start with the basic concepts of LLMs, gradually understand the Agent mechanism, and then extend to complex application scenarios. Even without a Python foundation, as long as you follow along, practice hands-on, and understand the responsibilities of each module, you can absolutely get started with this system. The LangChain framework itself is not complex; its true value lies in using it to effectively combine LLM capabilities with real business scenarios.

Key Takeaways

Key Takeaways