Getting Started with LangChain: A Deep Dive into Model and Agent Core Concepts

Preface: Why We Need to Rethink LangChain

As large model applications evolve from "able to chat" to "able to work," LangChain—the most mainstream framework for LLM application development—is undergoing a significant version iteration.

LangChain was released by Harrison Chase in October 2022, initially as a Python library to help developers connect large language models with external data sources and toolchains. With the popularization of powerful models like GPT-4, LangChain quickly became one of the most popular open-source frameworks in AI application development, surpassing 70,000 GitHub stars in just one year. The new version (0.2 and above) underwent a major architectural restructuring, splitting the framework into sub-packages like langchain-core and langchain-community, and introducing LCEL (LangChain Expression Language) as a unified chain-calling syntax that significantly improves code readability and composability.

Behind this architectural restructuring lies the maturation of the entire LLM application development paradigm. The monolithic design of earlier versions exposed engineering issues like dependency bloat and version conflicts as the community scaled—the langchain-community sub-package contains hundreds of third-party integrations, and installing them all would introduce massive unnecessary dependencies. The new sub-package system strictly separates core abstractions (langchain-core), community integrations (langchain-community), and official partner integrations (such as langchain-openai, langchain-anthropic), allowing developers to import only what they need, significantly improving dependency management. This "small core, large ecosystem" design philosophy is highly consistent with the evolution path of mature Python libraries like requests and httpx.

LCEL's design philosophy draws from Unix pipes—using the | operator to chain Runnable components into data pipelines, enabling declarative task orchestration. Under the hood, it unifies four execution modes: synchronous calls, asynchronous calls, streaming output, and batch processing, so developers don't need to write different calling code for different scenarios, greatly reducing engineering complexity. The new LangChain not only restructured core abstractions but also introduced a Middleware mechanism, giving developers greater control when building Agents.

This article focuses on two of the most critical concepts—Model and Agent—to help readers with no prior background build a systematic understanding of LangChain. These two modules form the backbone of virtually all LLM applications, and understanding their relationship is the first step toward practical development.

Model: The Foundation of LangChain

What Exactly Is a Model?

In the LangChain world, Model is the most fundamental and core abstraction. Whether you're calling OpenAI's GPT, DeepSeek, or a locally deployed open-source model, LangChain wraps them all with a unified interface. The benefit is obvious: switch models without changing code.

LangChain's unified interface design follows the software engineering "Dependency Inversion Principle." The framework defines abstract base classes like BaseChatModel and BaseLanguageModel, and all concrete models (such as ChatOpenAI, ChatAnthropic, ChatOllama) inherit and implement the standard methods of these base classes. This means developers always call the same set of interface specifications, while the underlying adapter layer handles translating standard calls into each vendor's specific API format. Currently, LangChain supports over 50 model providers, including OpenAI, Anthropic, Google, Mistral, DeepSeek, and local open-source models running through Ollama, truly achieving the engineering goal of "write once, run anywhere."

It's worth noting that the value of this abstraction design in practical engineering far exceeds model switching alone. During the development lifecycle of LLM applications, teams often need different models at different stages: using low-cost smaller models for rapid iteration during prototype validation, switching to more powerful flagship models for production, and routing cost-sensitive batch processing tasks to cheaper API endpoints. LangChain's abstraction layer allows this "model routing" strategy to be handled at the configuration level without touching any business logic code—a significant engineering value in enterprise scenarios with multi-model hybrid deployments.

Developers only need to program against the standard interfaces provided by LangChain; which vendor's model is actually called underneath and which API is used can all be flexibly switched through configuration. This "abstraction isolation" design approach is where framework value shines—encapsulating engineering complexity and letting developers focus on business logic itself.

Common Pitfalls at the Model Layer

Many beginners tend to oversimplify Model as just "an API call wrapper," but there are many details worth paying attention to in actual use:

• Message Format: LangChain uses structured message types (such as SystemMessage, HumanMessage, AIMessage) to organize conversations rather than simple string concatenation. This design isn't mere formalism but has deep engineering reasons. Modern large language models (especially Chat models aligned through RLHF) distinguish between inputs from different roles during training: System messages set the model's behavioral guidelines and role positioning, Human messages represent user input, and AI messages are the model's historical responses. This role distinction directly affects output quality—incorrectly mixing system prompts into user messages often causes model behavior to deviate from expectations.

  It's worth understanding in depth that RLHF (Reinforcement Learning from Human Feedback) is the core technical approach for alignment training of mainstream Chat models today, systematically described by OpenAI in the InstructGPT paper (2022). The training process has three stages: first, supervised fine-tuning (SFT) on high-quality dialogue data; then training a Reward Model to predict human preferences for different responses; and finally using the PPO (Proximal Policy Optimization) algorithm to maximize the reward model's scores. Each sample in the training dataset is strictly annotated with system/user/assistant roles, so the model learns high sensitivity to role boundaries. This explains why mixing instructions that should be in System messages into Human messages often causes the model to "forget" instructions or produce inconsistent behavior—this directly conflicts with the role expectations formed during training. LangChain's message type design is highly aligned with OpenAI's Chat Completions API messages array format, while shielding subtle differences in message formats across vendors through its abstraction layer. Correct use of message types is a prerequisite for stable output.

  Additionally, different vendors have subtle differences in message role support: some models don't support consecutive messages of the same role, some have strict requirements on System message positioning (must be first in the conversation), and some open-source models use entirely different dialogue template formats (like Llama's [INST] tags). LangChain's message abstraction layer shields these differences to some extent, but compatibility issues with underlying templates still need attention when using non-mainstream models.

• Streaming Output: In actual products, token-by-token response (streaming) is almost standard, and the Model layer provides native support for this. Streaming output relies on HTTP Server-Sent Events (SSE) or WebSocket protocols underneath, and LangChain encapsulates the streaming API differences across vendors through a unified stream() method, allowing developers to handle streaming responses consistently without worrying about underlying protocol details.

• Parameter Control: Parameters like temperature and max_tokens determine output stability and length, requiring tuning based on specific scenarios. The temperature parameter controls output randomness (0 means deterministic output, above 1 tends toward creative divergence). In tool-calling scenarios requiring precise, reproducible output, it's usually recommended to set it to 0 or a low value near 0; while in creative writing scenarios, moderately raising temperature helps generate more diverse content.

Understanding the Model layer well is essential for building more complex application capabilities on top of it.

Agent: Teaching Models to "Take Action"

From Conversation to Action

If Model addresses "what a model can say," then Agent addresses "what a model can do." The core idea of Agent is: enabling large models to not only generate text but also autonomously decide which tools to call to complete tasks.

The core reasoning mechanism of modern LangChain Agents is mostly based on the ReAct (Reasoning + Acting) framework, formally proposed by Yao et al. in the 2022 paper "ReAct: Synergizing Reasoning and Acting in Language Models" and systematically validated with support from Google Research. ReAct's core idea is having the model perform explicit "Thought" before acting, then decide on an "Action" to take, observe the result (Observation) after execution, and enter the next round of thinking. Experiments show that compared to pure chain-of-thought reasoning or pure action execution, the ReAct framework improves success rates by 10%~30% on complex reasoning benchmarks like HotpotQA and FEVER. Its advantage lies in tightly coupling language reasoning with external information retrieval, effectively reducing model "hallucination" problems. This cycle forms the basic execution unit of an Agent. Unlike pure chain calls, the ReAct framework gives Agents dynamic decision-making capability—rather than mechanically executing a preset workflow, it flexibly adjusts subsequent action strategies based on observations at each step.

The new LangChain further abstracts this cycle into a directed graph structure through LangGraph, making complex multi-step, multi-branch Agent workflows visualizable and controllable. LangGraph is an independent sub-library launched by the LangChain team in 2024, specifically designed for building stateful, multi-step Agent workflows. It models the Agent's execution process as a directed graph (DAG, Directed Acyclic Graph), where each node represents a processing step (such as calling an LLM, executing a tool, human approval), edges represent data flow between nodes, and conditional edges support dynamic branching. Compared to traditional linear chain calls, LangGraph's biggest breakthrough is native support for "loop" structures—Agents can iterate repeatedly in the graph until termination conditions are met, which is exactly the execution model required by the ReAct framework. LangGraph also has built-in persistent state management (Persistence), allowing Agents to maintain context across multiple conversation turns, and even supports "Time Travel" functionality that lets developers revert to any historical state for re-execution, greatly facilitating debugging and laying the foundation for building Multi-Agent Systems.

In the architectural design of multi-Agent systems, LangGraph's graph model demonstrates unique advantages. A typical multi-Agent system might include: an "Orchestrator" Agent responsible for task decomposition, "Executor" Agents focused on specific domains (such as code execution Agent, data analysis Agent, web search Agent), and a "Critic" Agent responsible for quality control. These Agents pass messages and share state through LangGraph's edges, forming a division of labor similar to human team collaboration. Compared to a single Agent handling all tasks, multi-Agent architecture offers stronger robustness and scalability when processing complex, long-horizon tasks, and is an important frontier in current Agent system research.

Here's an example: when a user asks "What's the weather like in Beijing today?" a pure Model can only guess from training data or refuse to answer, while an Agent equipped with a weather query tool will autonomously determine that it needs to call a weather API, retrieve real-time data, and then compose a language response. This "perceive—decide—act" cycle is the essence of intelligent agents.

The Underlying Mechanism of Tool Calling

The underlying mechanism of Agent tool calling relies on the Function Calling capability of large models. This capability was officially launched by OpenAI in June 2023 with the GPT-3.5/GPT-4 API update, followed by major vendors like Anthropic (Claude 3's Tool Use) and Google (Gemini's Function Calling), gradually becoming a standard capability of Chat models. The core breakthrough of Function Calling is: it lets models output structured JSON rather than free text to express tool-calling intent, fundamentally solving the format instability problem of early prompt-based tool calling parsing—before Function Calling, developers needed complex regular expressions or prompt engineering to "coax" models into outputting in fixed formats, with extremely poor reliability.

The implementation of this capability relies on specialized reinforcement of structured output during the model's training phase. Developers describe tool parameter structures in JSON Schema format—JSON Schema is a meta-language standard for describing JSON data structures (based on IETF drafts) that can precisely define parameter types, formats, required fields, and value range constraints. During inference, the model matches these Schema descriptions with user intent, decides whether to trigger a tool call, and generates parameter JSON conforming to Schema constraints. In 2024, OpenAI further launched Structured Outputs, using Grammar-based Constrained Decoding to enforce JSON format validity at the decoding level, reducing tool call format error rates to near zero, marking Function Calling's evolution from "best effort" to "engineering-grade reliable." Function Calling has improved Agent reliability by an order of magnitude and is the key technical prerequisite for modern LangChain Agents to actually deploy in production environments.

The technical principle of Grammar-based Constrained Decoding deserves further explanation: during each decoding step of an autoregressive language model, the model computes a probability distribution over all tokens in the vocabulary, typically sampling from it or selecting the highest-probability token. Grammar-based constrained decoding introduces a "mask" mechanism on top of this—based on the currently generated JSON fragment and target Schema, it calculates in real-time which tokens are grammatically valid successors, forcing invalid token probabilities to zero. This guarantees output always conforms to the predetermined format without modifying model weights. This technique draws from Context-Free Grammar theory in compiler principles and represents an innovative application of formal language theory in large model engineering practice.

Developers define tools as functions with structured descriptions (including function name, parameter types, and functional description), and LangChain passes these descriptions to the model in JSON Schema format. During inference, if the model determines it needs to use a tool, it outputs a structured tool call request (rather than plain text), which the LangChain framework captures and then actually executes the corresponding Python function, returning results to the model for continued reasoning. For models that don't support native Function Calling, LangChain also provides a degraded solution based on prompt engineering, though with relatively weaker stability and not recommended for production environments.

The Relationship Between Model and Agent

This is where beginners get most confused. A simple analogy helps:

• Model is the brain: responsible for thinking, reasoning, and generating language;
• Agent is the combination of brain plus body: using Model as the core decision engine, equipped with tools (hands and feet), memory (recall), and execution logic (behavioral rules).

In other words, an Agent always contains a Model internally, but an Agent is far more than just a Model. Agent layers tool calling, multi-step decision-making, and state management capabilities on top of Model, evolving the entire system from a "Q&A chatbot" to a "task-capable intelligent assistant."

From a system architecture perspective, this layered relationship is also reflected in resource consumption: the Model layer's main costs are API call fees and inference latency; the Agent layer adds tool execution time costs (such as network requests, database queries), cumulative token consumption from multi-round iterations, and memory overhead for state management. When designing Agent systems, reasonably controlling maximum iteration steps (max_iterations) and tool call timeouts (timeout) are important engineering practices to prevent cost spiraling.

New Features: How Middleware Enhances Agents

The Value of Middleware

The Middleware mechanism introduced in the new LangChain version is a major highlight of this iteration. Middleware is essentially an "interceptor" layer that can insert custom logic at key nodes in the Agent's execution flow.

This mechanism borrows from mature middleware patterns in web development—similar to Express.js, Django middleware, or Java's Filter chain. Its core is the "Chain of Responsibility Pattern": each middleware component receives a request and can choose to handle it, modify it, or pass it directly to the next component. In LangChain's implementation, this mechanism is achieved through the Runnable interface's pipe operations and the Callbacks system. Developers can register subclasses of BaseCallbackHandler to insert custom logic at key lifecycle hooks like on_llm_start, on_tool_start, and on_agent_action, without modifying the Agent's core code. This "non-invasive" extension approach allows cross-cutting concerns like security auditing, logging, and performance monitoring to be cleanly separated from business logic—a concrete practice of Aspect-Oriented Programming (AOP) in AI application frameworks.

Typical use cases include:

• Input Preprocessing: Cleaning, desensitizing, or formatting user input before the model receives requests;
• Output Post-processing: Filtering, auditing, or structuring model responses;
• Permission and Security Control: Performing permission checks before tool calls to avoid high-risk operations;
• Logging and Monitoring: Recording execution details at each step for debugging and issue tracking.

Why Middleware Matters

In enterprise applications, an Agent's "controllability" is often more critical than its "intelligence." Unlike traditional software, LLM-based Agents have inherent uncertainty—the same input may produce different tool call sequences at different runtimes. This uncertainty is acceptable in consumer applications but must be constrained through engineering measures in high-risk industry scenarios like finance, healthcare, and law. The main strategies currently adopted in the industry include: implementing tool call whitelists through middleware, setting maximum iteration steps to prevent infinite loops, introducing Human-in-the-loop approval nodes for high-risk operations, and using observability platforms for full-trace monitoring of every Agent run.

The Human-in-the-loop mechanism is particularly critical in high-risk scenarios and deserves separate explanation. LangGraph natively supports setting "Interrupt" points at any node in the graph. When the Agent reaches that node, the system pauses and waits for human confirmation before continuing execution. This mechanism has various application forms in practice: it can be simple "yes/no" approval (such as confirming whether to send an email), human modification of the Agent's next action plan, or even complete takeover of control before handing back to the Agent. This flexible switching between "software automation" and "human judgment" is the core engineering pattern for "responsible deployment" of AI applications in high-risk scenarios today, and is also one of the basic compliance requirements that regulators impose on AI systems.

No matter how capable an intelligent agent is, if it cannot guarantee output safety and behavioral auditability, it's difficult to truly deploy in production. The middleware mechanism is designed precisely to address these engineering needs—it lets developers add guardrails and monitoring to Agents in a plugin-based, non-invasive manner, significantly improving the framework's production readiness.

Learning Path Recommendations

A Progressive Three-Step Approach

For learners starting from scratch, the following order is recommended:

1. Master Model first: Be able to call different models with a unified interface, understand message formats and parameter control;
2. Then understand Agent: Start with the simplest single-tool Agent, observing how it autonomously decides to call tools based on the ReAct framework;
3. Finally master Middleware: After the Agent runs stably, layer on production-grade capabilities like security and logging with middleware.

Hands-on Practice Beats Theory

LLM application development has a notable characteristic: many abstract concepts can only be truly internalized through hands-on implementation. Learners are strongly advised not to just read but to type code line by line following examples, understanding the purpose of each step. LangChain's official documentation is the most authoritative learning resource—consult the docs first when questions arise, rather than relying on second-hand materials.

The visualization tracing functionality provided by the LangSmith platform is also a powerful tool for debugging Agent behavior and is worth understanding its underlying design philosophy. LangSmith is the official LLM application observability platform launched by the LangChain team, born from the "black box" dilemma exposed when AI applications move from lab to production environments. Traditional software debugging tools (such as logs, breakpoints, profilers) fail severely when facing LLM applications—a single Agent run may involve dozens of LLM calls, tool executions, and state changes, making it nearly impossible to locate root causes with just print logs. LangSmith draws from mature distributed tracing concepts in distributed systems, generating complete Trace Trees for each Agent run, recording inputs/outputs, duration, token consumption, and error information for each node, making the previously "black box" reasoning process transparent and queryable. Additionally, LangSmith provides dataset management and automated Evaluation functionality, supporting developers in running regression tests on Prompt changes. It's currently one of the most mature tools in the LLMOps (Large Model Operations) field, with integration with open standards like OpenTelemetry continuously progressing.

LLMOps, as an extension of MLOps (Machine Learning Operations) in the large model era, is forming its own independent tool ecosystem and best practices. Unlike traditional MLOps which focuses on model training, version management, and inference services, the core challenges of LLMOps are: Prompt version management and A/B testing, LLM output quality evaluation (how to define a "good answer"), granular Token cost tracking and optimization, and Agent behavior explainability. LangSmith holds a relatively leading position in this ecosystem but also faces competition from Weights & Biases (W&B Weave), Arize AI, Helicone, and others. The entire LLMOps toolchain is still rapidly evolving. It's strongly recommended to develop the habit of using observability tools during the learning phase.

Conclusion

Model and Agent are the two cornerstones of LangChain and the entire LLM application development landscape. Model provides unified model invocation capabilities through the Dependency Inversion Principle, shielding differences across vendor APIs; Agent, built on top of this, grants applications the ability to "act autonomously" through the ReAct reasoning framework and Function Calling mechanism; and the new Middleware mechanism, borrowing from the mature Chain of Responsibility design pattern, further completes the critical puzzle for engineering deployment. These three correspond to three levels of AI application development: Capability Layer (model invocation), Intelligence Layer (autonomous decision-making), and Engineering Layer (controllable and observable)—all indispensable. Master the relationships and underlying principles of these three, and you're already standing at the threshold from "AI user" to "AI application developer."