LangChain + MCP in Practice: A Pitfall-Avoidance Guide to LLM Selection and Local Deployment

In the world of AI large model application development, the technology stack evolves at a dizzying pace. LangChain and LangGraph iterate continuously, the MCP protocol introduces new communication mechanisms, Alibaba's Qwen3 series launches as open source, and DeepSeek completes critical version upgrades. Based on systematic course content from veteran Bilibili instructor Lao Xiao, this article addresses the most fundamental yet error-prone aspect of agent development — LLM selection and local deployment.

Why Engineers Must Master Multiple LLMs

Many beginners share a common misconception: since DeepSeek is so popular in China — used by state-owned enterprises, government agencies, and hospitals alike — isn't it enough to just learn DeepSeek?

The answer is no. As an LLM engineer, what you need to master is how to use and fine-tune various mainstream AI models, not obsess over a single one. Technology selection is one of a developer's core responsibilities.

Consider this scenario: your technical lead asks, "Should we use DeepSeek V3, Qwen3, or the Claude series for this project? What are the pros and cons of each?" If you only know one model, you simply can't answer that question.

This is also why professional courses are rarely named after a specific model — you should be able to use DeepSeek, Qwen, OpenAI, Claude, and more. Building general-purpose development skills is the proper technical vision for an engineer.

Beyond API calls, it's worth understanding model fine-tuning and even pre-training, including the pre-training principles behind today's popular MoE and Dense architectures.

The Essential Difference Between MoE and Dense Architectures: The Dense architecture is the standard form of traditional Transformers: during each inference pass, all model parameters participate in computation. Represented by the Llama series, computational cost grows linearly with parameter count. The key insight is that every feed-forward network (FFN) layer in a Dense model is fully activated during each forward pass — at the hundreds-of-billions parameter scale, this results in extremely high memory usage and computational latency. Notably, the Transformer architecture itself, proposed by Google in 2017, has a core self-attention mechanism whose computational complexity grows quadratically with sequence length (O(n²) for a sequence of length n). This means ultra-large Dense models face a dual bottleneck during long-context inference: memory pressure from parameter count and time overhead from attention computation. This dual bottleneck directly drove the rapid development of sparse architectures like MoE from an engineering demand perspective — the industry urgently needed an architectural paradigm that could expand model capacity without proportionally increasing computation.

The MoE (Mixture of Experts) architecture introduces a sparse activation mechanism: the model consists of multiple "expert" sub-networks, and during each inference pass, only a few experts are dynamically selected for computation by a gating network (Router). This design was first proposed by Shazeer et al. in 2017 in the paper Outrageously Large Neural Networks, and later validated at scale by Google in the Switch Transformer (2021). Take Qwen3-235B MoE as an example: despite a total parameter count of 235 billion, only about 22B parameters are actually activated per inference pass, dramatically reducing inference costs and enabling even modestly configured servers to run ultra-large models.

The engineering challenge of MoE lies in expert load balancing — if certain experts are over-selected while others sit idle, it leads to training instability and reduced inference efficiency, a phenomenon known as "Expert Collapse." To address this, researchers introduced auxiliary loss functions to force diversified routing. Both DeepSeek and Qwen3 have made targeted optimizations to MoE routing strategies: DeepSeek employs fine-grained expert segmentation and shared expert isolation mechanisms, while Qwen3 improved expert grouping methods, further enhancing expert utilization and training stability. In real-world deployment, MoE architectures also face Expert Parallelism challenges in distributed settings — different experts are often distributed across multiple GPUs, and the cross-device communication overhead (All-to-All communication) triggered by routing decisions becomes a new bottleneck for inference latency, which remains a key engineering focus for all vendors.

Technical depth determines how far you can go.

Three Critical Pitfalls in DeepSeek Model Selection

Among domestic open-source LLMs, DeepSeek and Qwen are widely recognized as the top two contenders. While models from companies like ByteDance are capable, they are neither open-sourced nor have all their API interfaces publicly available, making them difficult to use directly in development.

DeepSeek has two model names in its API that are easily confused:

• deepseek-chat: corresponds to DeepSeek V3
• deepseek-reasoner: corresponds to DeepSeek R1 (reasoning model)

Pitfall 1: R1 Does Not Support Tool Calling or Structured Output by Default

This is the most common gotcha — the kind you only realize when you hit an error: according to official documentation, DeepSeek R1 (deepseek-reasoner) does not support Function Calling or JSON Output by default, nor does it support FIM completion.

For application development, Function Calling (tool invocation) and JSON Output (structured output) are precisely the two most critical capabilities for building agents and workflows. Using R1 directly for agent development will likely result in errors like "structured output not supported" or "Function Calling not supported."

The Technical Origins and Working Principles of Function Calling: Function Calling was first officially introduced by OpenAI in June 2023 for GPT-4 and GPT-3.5-turbo, marking a key milestone in making LLMs "actionable." The core mechanism works as follows: developers pre-define a set of functions (tools) with their names, descriptions, and parameter specifications (typically described in JSON Schema format) in the API request. During inference, the model autonomously decides whether to call a function, what parameters to pass, and returns the call instruction in structured JSON format — note that the model itself does not execute the function. Instead, the developer's code handles the actual execution, and the execution result is fed back to the model as a new message, forming a complete "perception-decision-action" loop.

This mechanism fundamentally changed how LLMs integrate with external systems, enabling standardized operations like querying databases, calling REST APIs, manipulating file systems, and triggering automation workflows. It is also the core infrastructure for the ReAct (Reasoning + Acting) agent paradigm. The ReAct framework, proposed by Yao et al. in 2022, has the model alternately output "Thought" steps and "Action" steps: the model first describes its current reasoning state in natural language, then decides which tool to call. After receiving the tool's returned "Observation," it continues to the next round of thinking — this interleaving of thinking and acting gives agents the ability to decompose complex tasks and dynamically adjust strategies, forming the theoretical foundation of modern agent frameworks like LangGraph. Architecturally, LangGraph's directed graph nodes are essentially graph-based representations of ReAct loops: each node corresponds to a "think-act" unit, directed edges between nodes describe state transition logic, and terminal nodes correspond to ReAct loop exit condition checks — understanding this correspondence helps you intuitively grasp why tool-calling stability is so critical to the entire graph execution flow.

Function Calling capability is not innate to models but needs to be trained during the supervised fine-tuning (SFT) stage with large volumes of high-quality tool-calling conversation data — including when to decide to call a tool, how to extract and construct parameters from natural language, and how to continue reasoning based on tool return values in complete dialogue chains. This also explains why different models vary significantly in tool-calling stability and parameter extraction accuracy. It's worth noting that JSON Schema, as the standard format for tool definitions, directly impacts the model's parameter extraction accuracy — clearer descriptions and more explicit constraints in the Schema tend to yield higher-quality call parameters from the model, a tuning detail often overlooked in engineering practice.

Pay attention to the word "default" here. Function Calling capability is essentially acquired through training — first proposed by OpenAI, any model can gain this capability as long as it's fed sufficient high-quality tool-calling data during pre-training or fine-tuning. The customized R1 versions deployed in government agencies and hospitals support tool calling precisely because they've been re-fine-tuned.

Pitfall 2: Infinite Loop Issue in V3 Versions

If you don't want to fine-tune the model yourself, the simplest solution is to switch to DeepSeek V3, but version selection matters:

• DeepSeek V3 before version 0324: Function Calling has an infinite loop issue; not recommended for agent development.
• DeepSeek V3 version 0324 and later: This issue has been fixed and can be used with confidence.

The "infinite loop" essentially means the model fails to correctly determine the exit condition when a task is complete during multi-turn tool calling, falling into a cycle of repeatedly calling the same tool. This is a typical problem caused by insufficient "termination decision" samples in tool-calling training data, and in practice leads to abnormal API cost consumption and response timeouts.

From a deeper perspective, this issue reveals a core challenge in LLM tool-calling capability: task completion state judgment. The model needs to learn to compare the current state with the task objective after receiving tool results and make a binary decision between "continue calling" and "terminate and summarize." This meta-cognition ability requires training data containing abundant positive examples of "task completed, stop calling" as well as contrastive negative examples of "incorrectly continuing to call," so the model can learn stable termination judgment boundaries.

Notably, this termination judgment failure has particularly severe consequences in graph-based workflow frameworks like LangGraph: since the graph execution engine faithfully triggers the next node according to the model's tool-calling instructions, the model's looping behavior directly maps to infinite loop execution of graph nodes. This not only consumes API quotas but may also trigger duplicate side effects from downstream tools (such as database writes or email sends). This is the fundamental reason why engineering best practice recommends setting a max_iterations hard limit at the LangGraph level — as an engineering-side safety net against unstable model-level behavior. This is also why even the most powerful closed-source models today occasionally exhibit unnecessary repeated calling behavior in complex multi-step tool-calling scenarios.

Pitfall 3: Overlooking R1's Important Minor Version Updates

DeepSeek released the R1-0528 minor version update, which officially supports Function Calling and JSON Output starting from this version. Real-world testing shows excellent performance, meaning R1 can finally be used directly for agent development.

Additionally, DeepSeek released a distilled model, DeepSeek-R1-0528-Qwen3-8B — a model obtained by distilling R1-0528 into the Qwen3-8B base.

The Principles of Model Distillation: Knowledge Distillation was formally proposed by Hinton, Vinyals, and Dean in 2015 in the paper Distilling the Knowledge in a Neural Network. The core idea is to transfer the "dark knowledge" learned by a large model (teacher model) into a smaller model (student model). Traditional distillation works by having the student model fit the teacher model's soft label (Soft Logits) output rather than hard labels, learning richer inter-class relationships — the soft labels contain the teacher model's confidence distribution across categories, and the correlation information from low-probability classes (i.e., "dark knowledge") significantly improves the student model's generalization ability. This phenomenon is amplified through "Temperature Scaling" in Hinton's original paper.

In the era of large language models, distillation methods have evolved: the mainstream approach uses high-quality reasoning chain data (Chain-of-Thought Traces) generated by the large model as training corpus, performing supervised fine-tuning (SFT) on the small model's base. This is called "black-box distillation" or "data distillation." DeepSeek-R1-0528-Qwen3-8B uses R1-0528 as the teacher model and Qwen3-8B as the student model base, trained through SFT on chain-of-thought dialogue data generated by R1. The advantage of this approach is its engineering simplicity — it requires no access to the teacher model's internal weights, only calling its inference API to batch-generate data.

It's worth noting that the distribution coverage of the teacher model's generated data directly determines the distilled model's capability boundaries. If the teacher model's batch-generated reasoning chain data primarily covers certain task types (e.g., code generation, mathematical reasoning), the student model will significantly outperform its base in those areas, but may underperform compared to natively trained models of the same parameter count in under-covered areas (e.g., multilingual understanding, creative writing). The trade-offs of distillation are equally clear: the student model's capability ceiling is constrained by its base architecture's parameter capacity, generalization ability is weaker on task distributions not covered by the teacher, and distilled models tend to be slightly less robust than natively trained models of equivalent parameter count. Therefore, distilled models are best suited for deployment in resource-constrained scenarios with relatively fixed task distributions.

Real-world testing suggests this distilled model is even better than the original Qwen3, supporting not only deep thinking and analysis but also Function Calling, with dedicated optimizations for MCP.

Qwen3: The Current Benchmark for Open-Source Agent Capabilities

Alibaba's open-source Qwen3 series features models in two architectures.

How to Distinguish MoE from Dense Architecture

• MoE architecture: The flagship 235B and the 30B model
• Dense architecture: 8B, 14B, 1.5B, and other models

Simple rule of thumb: within the Qwen3 lineup, 235B and 30B use MoE architecture; the rest are Dense. Under MoE architecture, while 235B has a massive total parameter count, only a small subset of expert networks is activated per inference pass, making actual inference costs far lower than a Dense model of equivalent parameter count. From a deployment perspective, Qwen3-235B-A22B (where A22B stands for "22B activated parameters") has inference memory consumption close to that of a 22B Dense model, making deployment feasible on consumer-grade multi-GPU servers. It's important to note that "activated parameters" determine the computational cost of inference, while "total parameters" determine the memory capacity needed for storage — deploying Qwen3-235B-A22B still requires approximately 140GB of memory to load all weights (calculated at BF16 precision), but the FLOPs per inference pass are equivalent to a 22B Dense model. Understanding this distinction is key to grasping MoE deployment costs.

This difference becomes even more significant in quantized deployment scenarios: through INT4 quantization, Qwen3-235B-A22B's weight-loading memory can be compressed to approximately 60-70GB, making a multi-card deployment scheme with four 24GB consumer GPUs (such as RTX 4090) feasible. Meanwhile, the activation memory overhead during inference remains equivalent to a 22B Dense model and doesn't scale proportionally with the total parameter count. This characteristic gives MoE architecture a unique cost advantage in edge computing and private deployment scenarios: users can achieve language understanding capabilities approaching hundred-billion-parameter models with relatively limited hardware investment.

Qwen3's Two Core Competitive Advantages

First, programmable thinking mode switching. Qwen3 allows developers to seamlessly switch between "non-thinking mode" and "deep thinking mode" via parameters: enable deep thinking for complex logical reasoning, disable it for simple Function Calling or MCP integration, balancing quality and efficiency.

Specifically, Qwen3 controls inference mode by setting the enable_thinking parameter in API requests (or using special markers in system prompts). When deep thinking is enabled, the model generates a complete reasoning process within <think> tags before providing the final answer; when disabled, it outputs results directly, reducing response latency by over 40%. This fine-grained reasoning overhead control is particularly important when building complex workflows — for tool-scheduling decisions that don't require deep reasoning, disabling thinking mode can significantly reduce costs and latency.

From a system design perspective, this programmable switching capability allows engineers to adopt differentiated reasoning strategies for different nodes within the same workflow: use non-thinking mode for routing decisions, parameter parsing, and other structured task nodes to pursue low latency; enable deep thinking for complex sub-task nodes requiring multi-step planning to ensure quality. This Hybrid Reasoning Strategy is especially practical in LangGraph's directed graph workflows, enabling fine-grained trade-offs between end-to-end response time and task completion quality — a system-level optimization difficult to achieve at the pure API wrapper level.

Extending further from a practical engineering perspective: this node-level reasoning control capability has spawned a new workflow design paradigm — Reasoning Budget-Aware Architecture. Engineers can annotate each node in LangGraph's StateGraph with "reasoning sensitivity" metadata, and a unified scheduling layer dynamically decides at runtime whether to enable deep thinking based on current task complexity and latency budget. This design transforms reasoning cost control from a "one-time decision during model selection" to "dynamic resource scheduling at runtime" — an architectural pattern worth serious attention when building production-grade agent systems.

By contrast, DeepSeek's thinking mode switching relies on a website UI button and cannot be flexibly controlled through programming — this programmatic control capability is what makes Qwen3 most engineer-friendly.

Second, significantly enhanced agent capabilities. Qwen3 precisely integrates with external tools in both thinking and non-thinking modes, has strengthened support for the MCP protocol, and has achieved leading performance among open-source models in complex agent-based tasks.

Overall assessment: At least in the open-source domain, when it comes to MCP, Function Calling, and agent support capabilities, Qwen3 is currently the best choice, bar none. Additionally, Qwen3 supports over 100 languages and dialects and has made multiple engineering optimizations to its MoE architecture.

MCP Protocol's New Mechanism and Tech Stack Updates

The MCP protocol has introduced a new Streamable communication mechanism, completely replacing the original SSE (Server-Sent Events).

SSE vs. Streamable HTTP Communication Mechanism Comparison: SSE (Server-Sent Events) is a unidirectional streaming push protocol based on HTTP/1.1, standardized by the W3C in 2009. It works by having the client initiate a single HTTP GET request, after which the server keeps the connection open and continuously pushes event data in text/event-stream format — the response never closes until the server actively terminates it or the connection drops. SSE's advantages include simple implementation and native support for automatic reconnection (via the Last-Event-ID request header), and since it's based on standard HTTP, it can traverse most enterprise network environments without special proxy or firewall configurations. The early MCP protocol adopted SSE as its remote transport layer to meet the streaming return needs of tool-calling results.

However, as agent task complexity increased, SSE's fundamental limitations became apparent: it's half-duplex communication — the client cannot send data to the server on the same connection. Every time the client needs to submit new information, a new HTTP connection must be established. This creates significant connection management overhead and state synchronization issues in scenarios involving multi-turn tool calling, mid-task cancellation of long-running operations, and real-time session state updates. Additionally, SSE performs poorly in load balancing scenarios across multiple service instances: since persistent connections must be maintained on the same service instance, horizontal scaling requires additional sticky session mechanisms, which conflicts with the design principles of modern cloud-native stateless architectures.

The newly introduced Streamable HTTP mechanism is built on standard HTTP POST. By designing the response body as a stream channel that can be written to multiple times, it enables multi-event push within a single request, while the client can carry session identifiers in subsequent requests to resume context. More importantly, this mechanism supports connection recovery — after a network interruption, the client can reconnect with the last event cursor, and the server continues pushing from the breakpoint, avoiding re-execution of long-running tasks. Since each interaction is an independent HTTP POST request, the server can achieve truly stateless deployment, natively compatible with elastic scaling in container orchestration environments like Kubernetes.

From a broader technology trends perspective, this migration represents the full alignment of AI tool-calling protocols with cloud-native design philosophy: stateless service units, horizontal elastic scaling, and breakpoint-resume fault tolerance. For teams planning to deploy MCP services in Kubernetes or Serverless environments, the introduction of Streamable HTTP eliminates the stateful long-connection management layer that was necessary in the SSE era, allowing MCP services to be integrated into standard API Gateways, Service Meshes, and traffic management toolchains just like ordinary REST APIs, dramatically reducing the operational complexity of production-grade deployments. This change has a breaking impact on all frameworks built on MCP (LangChain, LangGraph, etc.), requiring transport layer re-adaptation — and is one of the core reasons for the current round of course redesign.

Starting from version 0.2, LangChain and LangGraph continue to iterate. In hands-on development, MCP agents and servers will be taught in two language implementations:

• Java for developing MCP agents and servers
• Python for developing MCP agents and servers

Summary: Three Practical Principles for LLM Selection

For engineers looking to get started with AI LLM application development, the following principles offer direct practical value:

Principle 1: Don't lock yourself into a single model. The ability to use and select across multiple models is your core competitive advantage. DeepSeek, Qwen, Claude, and OpenAI should all be in your technical toolkit.

Principle 2: Understand DeepSeek R1's version boundaries. R1 does not support tool calling or structured output by default. When selecting a model, either use V3 version 0324 or later, or use R1-0528 or later.

Principle 3: Prioritize Qwen3 for open-source agent scenarios. Its programmable thinking mode switching and robust MCP support make it the top choice for agent development among current open-source LLMs.

Mastering these fundamental insights will help you avoid detours in subsequent LangGraph and MCP agent development.