Getting Started with LangChain 1.3: Ecosystem Architecture & Agent Development Complete Guide

A practical guide to LangChain 1.3's ecosystem architecture and building your first Agent from scratch.
This guide breaks down LangChain 1.3's four-module ecosystem — LangChain (foundation components), LangGraph (stateful orchestration), DeepAgent (autonomous planning), and LangSmith (observability) — then walks through building a first Agent with tools, prompt templates, and short-term memory, emphasizing architectural understanding over API memorization.
Why You Should Understand LangChain from an Ecosystem Perspective
For many newcomers to AI application development, LangChain is often studied as a collection of isolated APIs, which leads to confusion. The tutorial author on Bilibili takes a fundamentally different approach — first get a Hello World-level Agent running, then go back and understand the entire ecosystem. This is particularly important in the era of large language models.
Here, an Agent refers to a core concept in AI application development — an AI system that can autonomously perceive its environment, formulate plans, and execute actions. Unlike simple Q&A-style LLM calls, an Agent has a "perceive-reason-act" loop: it can interpret user intent, decide whether external tools need to be invoked, execute those tools, and then reason about the next step based on the results until the task is complete. This design draws inspiration from the BDI (Belief-Desire-Intention) model in cognitive science. In engineering practice, the core challenge of Agents lies in how to reliably orchestrate these steps and handle exceptions and uncertainties at intermediate stages.
The author raises a thought-provoking point: in the traditional Java/SpringBoot era, mastering framework APIs was crucial. But in the LLM era, the actual API calling code can be entirely generated by AI. What developers really need to focus on is no longer memorizing specific APIs, but understanding the architectural design philosophy of the entire LangChain ecosystem — that is, when you want to build an application, how to holistically plan the implementation path and architecture.
This also explains why LangChain's frequent version changes (from 0.3 to 1.3) have become a pain point for developers: rapid API changes lead to constant code rewrites. But the underlying architectural thinking hasn't changed much. Once you grasp the core concepts, you can quickly adapt even when 2.x or 3.x versions arrive.

The Four Core Modules of the LangChain Ecosystem
The new LangChain ecosystem consists of four major modules. Understanding their division of labor is key to mastering the entire system.
LangChain: Foundation Component Library & Chain Structure
LangChain itself plays a dual role. First, it serves as the ecosystem's foundational component library, providing various basic capabilities for interacting with LLMs — how to call models, how to chat, how to use tools, etc. This is the "foundation" of the entire ecosystem; only with a solid foundation can upper-layer applications be stable. Second, it also provides a Chain-based approach for building complex applications, though this chain-style approach is used relatively less frequently now.
LangGraph: Stateful Process Orchestration Engine
Many people treat LangChain and LangGraph as two independent frameworks and struggle with "which one to learn." In reality, they converge toward the same goal and both belong to the same ecosystem. LangGraph builds on LangChain's foundational components to provide a stateful process orchestration engine (essentially a state graph) that combines basic components to handle complex business problems. It's inseparable from LangChain and cannot exist independently without those foundational components.
The "StateGraph" used by LangGraph is an engineering implementation of Finite State Machine (FSM) theory applied to AI applications. Each node represents a processing step (such as calling the LLM, executing a tool, formatting output, etc.), and edges represent state transition conditions. Compared to traditional stateless chain calls, state graphs naturally support loops, branches, backtracking, and other complex control flows. This is critical for business scenarios requiring multi-round tool calls, conditional logic, or even Human-in-the-loop intervention. Another major advantage of state graphs is persistence — the current state can be saved at any node, enabling checkpoint resumption and time-travel debugging.

DeepAgent: Autonomous Planning for Advanced Agents
DeepAgent is a new module added after LangChain 1.x, targeting modern advanced agent suites designed for deep task scenarios. It differs fundamentally from traditional approaches:
- LangChain/LangGraph mode: Developers pre-plan the business workflow and orchestrate processes for specific scenarios
- DeepAgent mode: Similar to products like Manus, Claude Code, and CodeX, it only provides basic capabilities like web access, local file reading, MCP/Skill integration, and the model autonomously plans and decides how to handle tasks
MCP (Model Context Protocol) mentioned here is an open standard proposed by Anthropic in late 2024, designed to establish a unified communication protocol between LLMs and external data sources/tools. Before MCP, every tool integration required custom adapter code, leading to severe ecosystem fragmentation. MCP uses standardized JSON-RPC communication to let LLMs connect to various external services in a "plug-and-play" fashion — database queries, API calls, file operations, etc. The Tools mechanism in the LangChain ecosystem is exactly this concept implemented at the framework level.
It's precisely because of this inclusive embrace of traditional chain thinking, stateful orchestration, and autonomous planning that LangChain has become one of the most mature client-side frameworks — it preserves framework convenience while also maximizing development freedom.
LangSmith: Engineering-Grade Observability Platform
LangSmith is a paid engineering platform that provides tracing, debugging, evaluation, and operations monitoring capabilities for LLM applications. This component is often underestimated: simple demos may not need it, but once you're building serious commercial products, these production-grade capabilities become essential.
Observability is an engineering concept borrowed from distributed systems into AI applications. The traditional three pillars of observability include Logs, Metrics, and Traces. In LLM application scenarios, observability faces unique challenges: since LLM outputs are non-deterministic, and Agents may go through complex chains of multi-round tool calls, simple logging is far from sufficient. LangSmith's tracing capability precisely records every LLM call's input prompt, output content, token consumption, latency, as well as tool call parameters and return values. This is crucial for diagnosing hallucinations, debugging tool call failures, and evaluating the effectiveness of different prompt strategies.
For example, you need tracing to locate issues, evaluation to assess model performance (whether it's a companion chatbot or a precise medical robot), monitoring to understand real-world production performance, and even capability tiering to offer different service levels. LangSmith's greatest advantage is that it's powerful yet incredibly simple to integrate — virtually zero code required.
Quickly Building Your First Agent
Environment and Dependency Installation
The tutorial recommends installing dependencies one by one during learning to build systematic understanding. The core packages are langchain and langgraph (requiring Python 3.8+; the demo uses 3.13). Additional packages needed:
langchain-openai: Extension package for OpenAI series modelslangchain-community: Community-maintained extension package, used when accessing Alibaba Cloud's Tongyi Qianwen
You can check current versions with conda list | grep langchain (tutorial version is 1.3.7).
Integrating LangSmith Monitoring
Integrating LangSmith monitoring requires no code — just set a few environment variables: the tracing switch, a custom project name, and the LangSmith API Key. The API Key needs to be created on the official website's Settings page. The author also demonstrates an engineering best practice — don't hardcode sensitive information in your code; instead, read it from a keys.json configuration file via a load_key method.
Unified Access to Major LLMs
LangChain provides init_chat_model as a unified entry point to access all major LLMs, with the key parameter being model_provider (which has built-in support for DeepSeek, Gemini, Anthropic, and other major providers). Since accessing OpenAI directly from China is inconvenient, the tutorial redirects via base_url to Alibaba Cloud's Bailian (DashScope) platform, which provides an OpenAI-compatible interface.
Alibaba Cloud's Bailian (DashScope) platform is Alibaba's LLM service platform hosting the Tongyi Qianwen series of models. A key feature is its OpenAI API-compatible endpoint, meaning any code written with the OpenAI SDK only needs to point the base_url to DashScope's compatible address (typically https://dashscope.aliyuncs.com/compatible-mode/v1) and replace the API Key to seamlessly switch to Tongyi Qianwen models. This compatibility strategy is very common in China's LLM ecosystem — DeepSeek, Zhipu AI, Moonshot, and others all provide similar OpenAI-compatible interfaces, greatly reducing migration costs for developers. This is also the technical foundation that enables LangChain to access multiple model providers through the unified init_chat_model entry point.
Switching models is extremely convenient: just change a few parameters to swap models. If your network allows OpenAI access, simply remove the base_url and use an OpenAI Key; for DeepSeek, just change the provider. There are also simpler wrapped components like ChatTongyi (community version), but note that community versions may have version compatibility issues (deprecation warnings have already appeared).

Tools, Agents & Memory: Deep Dive into Core Components
Tools: Extending LLM Capability Boundaries
LLMs can only answer based on their (outdated) training knowledge and cannot access real-time information. Take "What's today's date?" as an example — when you ask the model directly, the returned content is empty, but it will indicate in tool_calls that you "can call the get_current_date function."
In the LangChain system, defining tools is extremely simple — just write a regular function, add a description, and the @tool decorator. Functions decorated with @tool have their description information serialized into a function signature format (Function Calling format) that the LLM can understand, allowing it to determine when and how to invoke that tool. This mechanism is also the underlying foundation for advanced capabilities like MCP and Skill — regardless of how external capabilities are packaged, they ultimately convert into tool description formats recognizable by the LLM.
Agent: Automatically Orchestrating the Complete Call Flow
Manually handling the flow of "call LLM → identify tool call → execute function → return result → call LLM again" is tedious. create_agent encapsulates all of this: you just provide the LLM and tools, and the Agent handles planning and execution on its own.
The entire interaction involves different message types:
- HumanMessage: The question from the user
- AIMessage (with tool_calls): The LLM determines a tool needs to be called
- ToolMessage: The result of tool execution
- AIMessage (with content): The LLM synthesizes tool results to provide a final answer
This message flow mechanism reflects an important design principle: the LLM itself doesn't directly execute tools. Instead, it tells the framework through structured instructions "what tool I need to call and what parameters to pass," and the framework handles actual execution and feeds results back to the LLM as ToolMessages. This "LLM decides, framework executes" division of labor ensures both security (tool execution happens in a controlled environment) and full utilization of the LLM's reasoning capabilities.
Prompt Templates
ChatPromptTemplate is a frequently used component that templatizes prompts using curly-brace variables. For example, defining a translation context like "translate the content from English to {language}" — then you just pass in Chinese or French to generate different prompts. This lets the application accept just a few fixed business parameters externally, very similar to traditional application development.
The value of prompt templates goes far beyond simple string substitution. In production environments, Prompt Engineering is a key factor determining LLM application effectiveness. Through templating, teams can manage prompts as independent assets for version control, A/B testing, and effectiveness evaluation. LangChain's template system also supports composition of multiple message roles — System Message defines the AI's role and behavioral boundaries, Human Message carries user input, and AI Message provides few-shot examples. This structured composition approach is more reliable and maintainable than simple text concatenation.

Short-term Memory (Checkpoint) for Multi-turn Conversations
With the InMemorySaver component, an Agent can remember conversation history within the same session. For example, if you first ask "What's today's date?" and then ask "What about tomorrow?", the LLM can infer from context that you're asking about tomorrow's date. Developers don't need to manually consolidate chat history — just specify the checkpoint when building the Agent.
It's important to understand that LLMs are inherently stateless — every API call is independent, and the model doesn't "remember" previous conversations. To achieve multi-turn conversation coherence, the full conversation history must be sent with each request. This creates two engineering challenges: first, token consumption grows linearly with conversation turns and may exceed the model's context window limit (even though current mainstream models support 128K or longer contexts, high-frequency conversations can still hit the ceiling); second, how to efficiently manage this history across multiple users and sessions. InMemorySaver stores conversation history in memory, suitable for development and debugging; production environments typically need persistent storage (like Redis or PostgreSQL) for checkpoints. More advanced memory management strategies include conversation summary compression, sliding window truncation, and semantic retrieval-based memory, all aimed at maximizing information utilization within limited context windows.
Conclusion: Mastering Architectural Thinking Matters More Than Memorizing APIs
This tutorial uses a simple date-query Agent to connect several core foundational components of the LangChain ecosystem: Model (LLM), Tools, Prompt, and Checkpoint (short-term memory).
As an application framework, LangChain's value lies in its well-designed encapsulation of the complex interactions with LLMs, allowing developers to focus on application-building logic. The essence of building Agents in the future is taking these basic capabilities and assembling them into complete applications. Mastering the ecosystem's architectural thinking is far more important than memorizing specific APIs — and this is exactly the best strategy for keeping up with LangChain's frequent version iterations.
Related articles

DeepMind's SL2T Model: Real-Time Sign Language to Text, Enabling Deaf Users to Control Phones with Sign Language
DeepMind releases SL2T sign language to text model using multimodal recognition of hand, facial, and body movements to convert sign language to text in real time, with edge-cloud architecture for privacy.

Bias and Double Standards in AI Content Moderation: Technical Roots and Solutions
An in-depth analysis of bias and double standards in AI content moderation systems, exploring technical roots including training data flaws, annotation subjectivity, and rule design issues, with solutions for building fairer systems.

Altman Says AI Won't Bring a 4-Day Work Week — The Internet Fires Back
OpenAI CEO Sam Altman says AI won't bring a 4-day work week because people like being busy. Reddit erupts, arguing that enjoying busyness and being forced to work are fundamentally different things.