Deep In Langchain

July 28, 2026 · 科技 #high-tech

What Problem Does LangChain Actually Solve?

When choosing an Agent framework, you're not picking a feature list — you're betting on an ecosystem.

A few weeks ago, our team got into a discuss. The requirement was straightforward: build a Go-based agent that calls internal APIs, handles tool invocation, and supports multi-turn conversations. One camp argued for wrapping the OpenAI SDK directly — "why add framework overhead for something this simple?" The other camp pushed back: once you need RAG, multi-agent coordination, and prompt versioning, that thin wrapper inevitably grows into a poorly-designed, homegrown framework.

In the Python world, LangChain is the de facto standard. But in Go, there are two serious contenders: langchaingo (the community Go port) and ByteDance's Eino. This article won't give a "best" answer — but it'll lay out the architecture, code, and trade-offs so u can make your own call.

The LangChain Architecture: More Than an LLM Wrapper

Here's how I think about LangChain's layered structure:

Bottom Layer: Core Runtime

The core runtime handles the plumbing of LLM applications. Calling a model is the easy part — it's everything around the model that gets complicated.

Model I/O is the entry-point abstraction. LLMs, Chat Models, and Embeddings share a common interface, so switching providers is a one-line config change. The BaseChatModel abstraction isn't elegant because it's clever — it's valuable because it decouples your business logic from a specific provider. GPT-4o in production, Ollama locally.

Retrieval is where LangChain's integration depth shines. Document Loaders → Text Splitters → Embeddings → Vector Stores → Retrievers — the RAG pipeline is wired up out of the box. The real moat isn't the design, it's the sheer volume: 40+ vector databases, loaders for dozens of formats, all contributed by the community.

Chains have evolved. The old LLMChain patterns are giving way to LCEL (LangChain Expression Language), which uses the | operator to compose Runnables. It reads like a Unix pipeline: retriever | prompt | llm | output_parser. The framework handles parallelism and streaming internally, detecting which steps can run concurrently.

Agents turn LLMs from "you say something, it says something back" into "you state a goal, it figures out the steps." At the core is the ReAct loop (Reasoning + Acting): the model decides which tool to invoke, gets the result, then decides whether to call another tool or respond. LangChain provides factory methods like create_react_agent() and create_tool_calling_agent(). That said, the Agent abstraction has arguably too many layers — debugging a misbehaving agent can be painful, and this is one of the most common complaints about LangChain.

Callbacks are the cross-cutting layer. Hooks like on_llm_start, on_tool_end, and on_chain_error span the entire lifecycle. Logging, billing, and monitoring all hang off this system. Understanding Callbacks is a prerequisite for using LangSmith effectively.

Top Layer: The Platform Trio

LangChain isn't just a Python library — the platform layer above it is where the commercial focus lies. The three components serve different roles, but they stack cleanly.

LangSmith — Production-Grade Observability for Agents

LangSmith works by registering itself as a BaseCallbackHandler in LangChain's callback system. Every LLM call, chain step, and tool invocation is intercepted, serialized into a structured "Run" object, and pushed to the LangSmith backend over HTTP.

The clever part isn't the data collection — it's the data model. Each execution is modeled as a Trace Tree: the root node represents a user request (e.g., "analyze Q3 revenue"), and child nodes cascade down — the agent's reasoning steps, tool call inputs and outputs, LLM token consumption. Every node carries a run_type (llm, chain, tool, retriever), parent-child relationships, start/end timestamps, and input/output payloads. The payoff: when an agent takes 30 steps to answer a question, you can pinpoint exactly which step ate the most time, which tool returned an empty payload, and which LLM call burned tokens on irrelevant output.

Built on this trace infrastructure are two additional layers. The evaluation layer (Datasets + Evaluators) lets you extract input/output pairs from historical traces into curated datasets, then run automated regression tests every time you tweak a prompt. The automation layer (Rules + Webhooks) watches production trace streams in real time and triggers on conditions you define — "alert if tool failure rate exceeds 10%." This is effectively CI/CD and observability ported to the agent domain.

LangGraph — Agents as State Machines

Under the hood, LangGraph is a graph execution engine inspired by Google's Pregel model. You define a StateGraph where the state is a dictionary with reducer functions per key. For example, a messages key might use an append reducer — new messages accumulate in a list rather than overwriting. Each Node is a function with the signature (state) -> state_update. Nodes don't mutate global state directly; they return partial update dicts, and the framework merges them according to the reducers.

This design enables safe concurrency: within a single "superstep," multiple nodes can execute in parallel, each producing its own state update fragment, merged at the end. Conditional edges turn routing into pure functions — (state) -> next_node_name — making them trivially testable without mocking infrastructure.

What really separates LangGraph from chains is the Checkpointer. At the end of every superstep, LangGraph serializes the complete state (SQLite by default, Postgres in production) and writes a checkpoint. This means you can interrupt a 20-step agent mid-execution, tweak a prompt, and resume from step 15 — no restart from scratch needed. More importantly, it enables human-in-the-loop by design: set an interrupt point before a sensitive operation, and the agent pauses until a human approves. Compare this to traditional chains — a chain is a lit firecracker string; you just wait for the pops. LangGraph lets you snuff it out at any node, backtrack, and re-light. This is why I consider it the most valuable piece of the entire ecosystem: it solves not "how to call an LLM" but "how to manage LLM-driven business processes."

Deep Agents — Meta-Agents and Self-Correction

Deep Agents is a higher-level abstraction built on top of LangGraph, still under rapid iteration. The core idea is letting an agent act as its own project manager: given a vague goal, first plan subtasks, then execute them, then reflect on the results and replan if unsatisfied.

Concretely, this is a cyclic LangGraph: a Plan Node uses an LLM to decompose the goal into a step list → an Execute Node invokes tools or sub-agents sequentially → an Observe Node collects results → an Evaluate Node uses a different LLM to score the outcome and decide whether to continue, replan, or deliver the final answer. The two LLMs serve different roles — planning/execution uses the most capable model (e.g., GPT-4o), while evaluation can use a faster, cheaper model because judging "is this answer correct" is fundamentally easier than "how should I solve this problem."

In practice, the self-correction loop is still shaky. LLMs have a well-documented tendency toward overconfidence in their own output, which means the Evaluate Node often gives inflated scores. In my experience, adding a hard constraint — "you must identify at least one issue" — to the evaluation prompt pushes the miss rate down to acceptable levels. The direction is correct, but we're not yet at "set a goal and go to sleep" reliability.

Now let's look at actual code.

Two Languages, Two Paradigms

Python + LangChain: RAG as a Pipeline

Here's a minimal RAG QA setup — semantic search over documents, fed to GPT:

from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_chroma import Chroma

# 1. Set up vector store (in practice, do this once at init time)
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(docs, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# 2. Compose the RAG pipeline with LCEL
llm = ChatOpenAI(model="gpt-4o", temperature=0)
prompt = ChatPromptTemplate.from_template(
    "Answer the question based on the context below. "
    "If the answer isn't in the context, say you don't know.\n\n"
    "Context: {context}\n\nQuestion: {question}"
)

rag_chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
)

# 3. Fire
response = rag_chain.invoke("What are LangChain Callbacks used for?")
print(response.content)

What's interesting here isn't the brevity — it's the dictionary {"context": retriever, "question": RunnablePassthrough()}. LCEL inspects the values, runs the Runnable ones in parallel, and fills the results into the prompt template. You write zero concurrency code, the framework handles it.

Go + langchaingo: ReAct Agent

On the Go side, langchaingo gives you a more explicit API. You manage contexts, handle errors, and assemble components manually:

import (
    "context"
    "github.com/tmc/langchaingo/agents"
    "github.com/tmc/langchaingo/llms/openai"
    "github.com/tmc/langchaingo/tools"
)

func main() {
    ctx := context.Background()

    // 1. Initialize the LLM
    llm, err := openai.New(openai.WithModel("gpt-4o"))
    if err != nil {
        panic(err)
    }

    // 2. Define tools — static typing is a feature here
    searchTool := tools.NewGoogleSearch()
    calcTool := tools.NewCalculator()

    // 3. Build the agent
    agent := agents.NewOpenAIFunctionsAgent(
        llm,
        []tools.Tool{searchTool, calcTool},
        agents.WithMaxIterations(5),
    )

    // 4. Execute — the framework drives the ReAct loop
    executor := agents.NewExecutor(agent)
    result, err := executor.Call(ctx, map[string]any{
        "input": "What's the temperature in Tokyo today, in Fahrenheit?",
    })
    if err != nil {
        panic(err)
    }
    fmt.Println(result)
}

The contrast is instructive. Python's | operator makes the pipeline read like a declarative DSL. Go's version is explicit construction with error checking at every step — it reads like standard Go service code. Neither approach is "better." If your team lives in Python, LCEL's magic feels like leverage; if Go is home, langchaingo's explicitness feels like control.

Head to Head: LangChain vs. Eino

ByteDance's Eino is a Go-native LLM orchestration framework under the CloudWeGo umbrella. It borrows LangChain's modular design but makes distinctly Go-idiomatic choices. Here's the comparison:

Dimension LangChain (Python) langchaingo (Go) Eino (CloudWeGo)
Language Python native, largest community Go community port, API-aligned Go native, Go-idiomatic
Type Safety Runtime duck-typing, weaker IDE support Compile-time, some any interfaces Go generics, compile-time enforcement
Agent Model create_react_agent() / create_tool_calling_agent() NewOpenAIFunctionsAgent() factories ADK: ChatModelAgent + DeepAgent
Orchestration LCEL pipe + LangGraph state graph Chain + Agent Executor compose.NewGraph[I,O]() generic graphs
Streaming Per-component implementation Same as Python model Framework-managed auto-streaming
Multi-Agent Via LangGraph subgraphs Manual orchestration DeepAgent native sub-agent delegation
Interrupt/Resume LangGraph checkpointing Requires custom implementation Built-in, human-in-the-loop
Learning Curve Moderate, many concepts Moderate, mirrors Python concepts Moderate-low for Go developers
Production Readiness Highest, extensive enterprise usage Community-maintained ByteDance-internal, shorter public history
License MIT MIT Apache-2.0

My take on selection:

  • Pick LangChain (Python) if your team is Python-first. The ecosystem depth alone makes it the default choice.
  • Pick langchaingo if you're a Go shop that wants to leverage LangChain's conceptual familiarity — tutorials, blog posts, and community patterns largely transfer.
  • Pick Eino if you value compile-time type safety and Go's concurrency model. The generic graph orchestration catches type mismatches at build time, which matters in large codebases. The trade-off is a smaller community and fewer answers on Stack Overflow.

Here's the thing: your team's language trajectory over the next 2-3 years matters more than any feature comparison. If your infrastructure is all Go, bolting on a Python LangChain service might cost more in operational overhead than the framework saves in development time.

Beyond Frameworks: What Won't Go Out of Style

After all the architecture diagrams and code comparisons, one thing stands out: specific frameworks are temporary; the patterns they embody will stick around.

The ReAct pattern is the key to understanding agents. The Reasoning + Acting loop isn't LangChain's invention — it's from Yao et al., 2022. LangChain just packaged it as create_react_agent(). Even without any framework, you can write an agent with while True: thought = llm.think() → result = tool.act() → observe(). If you understand the pattern, the framework is a tool. If you don't, it's a black box.

LangGraph addresses the productionization gap. Real agent systems aren't linear pipelines — users change their minds mid-execution, tool calls fail and need retries, compliance requires human sign-off on certain operations. These are state machine problems, not LLM problems. Modeling agents as stateful directed graphs is the right call, and I'd bet on graph-based agents becoming the production standard in the next year or two.

LangSmith / Harness signals where the market is heading: a full "AgentOps" platform. Prompt versioning, dataset-driven evaluation, production tracing, automated issue detection and repair — for teams running dozens of agents in production, this is more critical than the framework itself.

Three things I'm watching:

  1. Orchestration standardization: Every framework has its own DSL now (LCEL, LangGraph, Eino Compose). MCP is already standardizing tool calling. Orchestration will follow.
  2. From copilot to agent swarms: Single-agent capability has a ceiling. The next frontier is multi-agent coordination that actually works in production. LangGraph's subgraph model and Eino's DeepAgent are both probing in this direction.
  3. Eval-driven agent development: Building agents is easy; knowing if they're any good is hard. Dataset-driven evaluation with automated regression testing might be the last mile between "demo" and "production."

Frameworks come and go. But ReAct loops, stateful graph orchestration, and tool-calling standards — these are becoming the basic vocabulary of LLM application development. Picking the right framework matters. Understanding why they're designed the way they are matters more.