[KongchangAI]
· 2 min read· 1,274 words

Getting Started with LangChain: From Framework Positioning to Agent in Practice

Getting Started with LangChain: From Framework Positioning to Agent in Practice

LangChain is the engineering foundation for agent applications, solving three LLM shortcomings and shifting to graph orchestration.

The article explains that LangChain is often mistaken for just an API wrapper; its real positioning is closer to Spring—a pre-built agent architecture and tool integration layer. It addresses three LLM shortcomings: time-limited training data and error-prone computation (via Function Call to tools), inability to access external systems (tool integration layer), and statelessness (memory components). The ecosystem includes LangChain, LangGraph, and LangSmith, with graph orchestration as the key to going deeper.

Why Do We Need LangChain?

In LLM application development, LangChain is almost unavoidable as the first framework you encounter. But many beginners mistakenly think of it as simply a "wrapper library for calling APIs," and this misconception causes them to miss its real value. According to the Bilibili tutorial "Basic LangChain Full Course," LangChain's positioning is closer to Spring in the Java ecosystem—it provides a pre-built agent architecture and rich tool integrations, so developers don't have to build complex integration layers from scratch.

LangChain pre-built components

In other words, if you just want to chat with DeepSeekAd or Claude, calling the API directly is enough; but if you want to build an Agent product with memory that can call external tools and access private data, LangChain provides a complete engineering foundation.

Three Model Shortcomings That LangChain Solves

Limited Knowledge and Inaccurate Computation

LLM training data has a clear cutoff point. A model trained on August 10th cannot answer questions about what happened on August 11th. When users feel that "Doubao knows," they're actually using an already-wrapped application, not the bare model. LangChain uses the Function Call mechanism to let models call external tools for real-time data, such as weather queries.

The difference between models and applications

The same approach applies to precise computation. LLMs are prone to errors with complex arithmetic, so LangChain lets the model call a calculator tool, delegating the computation to deterministic code.

Function Call is a structured output capability provided by LLMs: developers pre-declare a set of available tools (function names, parameter schemas, functionality descriptions), the model determines during conversation whether it needs to call a tool and returns the function name and parameters to call in JSON format, and the application layer actually executes it before passing the result back to the model. It decouples "the model decides what to do" from "the code handles how to do it," and is the underlying foundation of LangChain's tool integration capabilities. Note that the model itself doesn't execute any functions—it's only responsible for generating call intents, while actual execution, authentication, and result validation all happen on the application side, which is why tool calls require security boundary design.

Cannot Interact with External Systems

The model itself cannot directly call third-party APIs or connect to databases via JDBC. Enterprise internal data lives in databases, and the model has no channel to read it. LangChain's tool integration layer fills this gap, enabling models to securely access external systems and private data.

No State Retention Capability

LLMs are essentially question-and-answer; they don't automatically remember what was discussed in the previous round. If you feel it "remembers," it's because the application layer stitches together historical messages for you. LangChain provides memory components that turn multi-turn conversation state management into a framework-level capability, rather than hand-writing stitching logic every time.

Multi-turn conversation state management

The "statelessness" of LLMs means that a single API request itself carries no prior context information, and the server does not save conversation context for any particular user. So-called "memory" is essentially the application stitching historical messages into the messages array of the current request according to certain strategies before sending to the model. This brings two engineering problems: first, context length has an upper limit, so history cannot be appended indefinitely—it needs truncation, summarization, or filtering by importance; second, token consumption grows linearly with each round, directly affecting cost and latency. LangChain's memory components abstract strategies like "what to store, how long to keep it, and how to compress it" into replaceable modules.

The Origin of the LangChain Name and Its Ecosystem

LangChain = Language + Chain. Language refers to large language models, and Chain refers to chained interaction—connecting the model with other computer resources in a chain to build more powerful AI applications. The name itself explains its core design philosophy: rather than calling the model in isolation, embed the model into an orchestrate-able processing chain.

The current LangChain ecosystem includes several core components: LangChain itself handles model wrapping and chain orchestration, LangGraph handles stateful graph-structured workflows, and LangSmith provides debugging and observability. The tutorial mentions "these three are what you mainly work with"—they have different roles but are used together.

LangChain ecosystem components

In terms of underlying implementation, LangChain has shifted to LangGraph as its execution engine while also integrating DeepAgent-related capabilities. This means learning LangChain isn't just about the surface-level Chain API—understanding Graph orchestration is the key to going deeper.

LangGraph is a stateful orchestration framework launched by the LangChain team, with the core abstraction being a graph structure of "nodes + edges + shared state." Compared to the early linear Chain, the graph structure supports conditional branching, loops, parallelism, and human-in-the-loop, and can checkpoint and persist execution processes to support resumption from breakpoints and multi-turn state recovery. LangSmith is the accompanying observability platform, used to trace the input/output, latency, and token consumption of each call, and to evaluate and debug the chain. The relationship among the three can be understood as: LangChain provides model and tool wrapping, LangGraph provides execution and state orchestration, and LangSmith provides the observation and optimization loop.

Suggested Learning Path

LangChain iterates quickly, and the official documentation is the most reliable reference. English docs update most promptly, while Chinese docs are basically in sync with consistent code—if English is difficult, the Chinese version is completely sufficient. The suggested learning order is: first get model calls and Prompt templates working, then understand Chain orchestration logic, then move to Tool and Agent practice, and finally cover LangGraph state management. Skipping the basics and jumping straight to Agent examples easily results in copying code without being able to explain the principles.

For developers with a Java background, analogizing LangChain to Spring quickly builds intuition: the IoC container corresponds to tool and model registration management, AOP corresponds to chain interception and middleware, and starters correspond to pre-built integration packages. This analogy isn't precise, but it's enough to help you understand why it's not a thin wrapper.

Prompt templates are a structured way to assemble user input, system instructions, historical context, and tool descriptions into the final request, typically including variable placeholders, role division, and output format constraints. They seem simple but directly determine the stability of model output: with the same model, differences in instruction order, number of examples, and format requirements in the template can cause noticeably different results. LangChain abstracts templates into reusable, composable objects for easy sharing and version management across different chains—this is its first layer of engineering value that distinguishes it from "string concatenation API calls."

One-line Summary

LangChain is the engineering foundation for agent applications, solving three major LLM shortcomings and having shifted to graph orchestration.

Paragraph Summary

The article points out that LangChain is often mistaken for just an API wrapper library, when its true positioning is closer to Spring in the Java ecosystem—providing a pre-built agent architecture and tool integration layer. It mainly addresses three LLM shortcomings: training data has a time cutoff and complex computation is error-prone, solvable through Function Call to external tools and calculators; models cannot directly access third-party APIs, databases, and other external systems, filled in by the tool integration layer; models are inherently stateless, and multi-turn memory requires application-layer stitching, which LangChain abstracts into a framework capability. The name comes from Language + Chain, emphasizing embedding models into orchestrate-able processing chains. The current ecosystem consists of LangChain, LangGraph, and LangSmith, with underlying execution having shifted to LangGraph, making understanding graph orchestration the key to going deeper. For learning, follow the official documentation and progress through model calls, Chain orchestration, Tool/Agent practice, and LangGraph state management.

Share:

Related articles