Agentes de LangChain: guía técnica completa para 2026

Agentes de LangChainHover to explore

Un LLM que responde preguntas es útil. Un LLM que puede hacer cosas —consultar tu base de datos, enviar un mensaje a Slack, tramitar un reembolso y después contarte qué ha hecho— es un producto. Los agentes de LangChain son la forma estándar de montar ese bucle en 2026. Esta guía recorre todo el camino, del modelo mental al código de producción: el bucle del agente, cómo escribir herramientas, memoria y estado, salida estructurada, streaming, gestión de errores y qué funciona (y qué no) según r/LangChain, r/LocalLLaMA y la comunidad de X.

Esta guía se apoya en la documentación de agentes de LangChain v1, la documentación de LangGraph y en las discusiones recurrentes de r/LangChain y @LangChainAI en X.

1. El bucle del agente: qué ocurre realmente en ejecución

Todos los agentes de LangChain ejecutan el mismo bucle, sea cual sea el modelo:

1. Observar: el LLM recibe el historial de la conversación y la lista de herramientas disponibles (nombre, descripción y esquema JSON de los argumentos).
2. Razonar: el modelo decide si llama a una herramienta o devuelve la respuesta final. Los modelos actuales usan tool calling nativo en lugar de parsear JSON incrustado en texto libre.
3. Actuar: si pide una llamada, LangChain la ejecuta y añade el resultado a la conversación como ToolMessage.
4. Repetir: el bucle sigue hasta que el modelo devuelve una respuesta sin llamadas o se alcanza el límite de iteraciones configurado.

Eso es todo. La sofisticación está en qué herramientas ofreces y en cómo acotas el bucle, no en ninguna magia interna del framework.

2. Tu primer agente de LangChain en 15 líneas

Con create_agent de LangChain v1 apenas hay código repetitivo:

from langchain.agents import create_agent
from langchain.tools import tool

@tool
def search_orders(order_id: str) -> str:
    """Look up an order by ID and return its current status."""
    # Replace with your real DB call
    return f"Order {order_id}: Shipped, arriving 2026-06-23."

@tool
def issue_refund(order_id: str, reason: str) -> str:
    """Issue a full refund for an order given a reason."""
    return f"Refund issued for order {order_id}. Reason: {reason}."

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[search_orders, issue_refund],
    system_prompt=(
        "You are a helpful customer support agent. "
        "Always look up the order before issuing a refund."
    ),
)

result = agent.invoke({
    "messages": [{"role": "user", "content": "Refund order #4821 — it arrived broken."}]
})
print(result["messages"][-1].content)

Por debajo, el agente llama a search_orders("4821"), lee el resultado, llama a issue_refund("4821", "arrived broken") y devuelve la confirmación al usuario. Todo dentro de una sola llamada a invoke, sin orquestación manual.

3. Escribir buenas herramientas: donde fallan casi todos los agentes

Lo que más influye en la calidad de un agente es el diseño de las herramientas, no la elección del modelo. El modelo decide a cuál llamar basándose únicamente en el nombre de la función, el docstring y el esquema de argumentos. Si eso está mal planteado, no hay prompt que lo arregle.

Reglas que se cumplen en la práctica:

• Una acción por herramienta. search_and_refund() es una trampa: sepárala. El modelo debe poder invocar cada paso por separado.
• Escribe el docstring para el modelo, no para una persona. Indica cuándo se llama, qué devuelve y cualquier condición previa estricta («Llama a esto solo después de confirmar que el pedido existe»).
• Devuelve cadenas o JSON sencillo. El modelo lee el valor de retorno como texto. Un objeto muy anidado lo confunde; un resumen de una frase funciona mejor.
• Gestiona los errores dentro de la herramienta, no fuera. Devuelve "Error: order not found" en lugar de lanzar una excepción: así el agente puede reintentar o explicar el fallo en vez de romperse.

from langchain.tools import tool
from pydantic import BaseModel, Field

class SearchInput(BaseModel):
    order_id: str = Field(description="The numeric order ID, e.g. '4821'")
    include_history: bool = Field(
        default=False,
        description="Set True to include the full shipment history"
    )

@tool(args_schema=SearchInput)
def search_orders(order_id: str, include_history: bool = False) -> str:
    """
    Look up an order's current status by order ID.
    Call this FIRST before any action that modifies the order.
    Returns: status string, or an error message if not found.
    """
    try:
        order = db.get_order(order_id)
        if not order:
            return f"Error: order {order_id} not found."
        base = f"Order {order_id}: {order.status}, ETA {order.eta}."
        if include_history:
            base += f" History: {order.shipment_history}"
        return base
    except Exception as e:
        return f"Error fetching order: {str(e)}"

4. Memoria y estado persistente

Por defecto, cada llamada a agent.invoke() es sin estado: el agente olvida el turno anterior en cuanto termina. Para conversaciones de varios turnos hay que pasar el estado de forma explícita. LangChain ofrece dos patrones:

Patrón A: checkpointing por hilo con LangGraph (recomendado en producción)

from langchain.agents import create_agent
from langgraph.checkpoint.memory import MemorySaver

# MemorySaver keeps state in RAM; swap for PostgresSaver in production
checkpointer = MemorySaver()

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[search_orders, issue_refund],
    checkpointer=checkpointer,
)

# Same thread_id = same conversation memory
config = {"configurable": {"thread_id": "user-123-session-456"}}

# Turn 1
agent.invoke(
    {"messages": [{"role": "user", "content": "What is the status of order 4821?"}]},
    config=config,
)

# Turn 2 — agent remembers turn 1
agent.invoke(
    {"messages": [{"role": "user", "content": "Go ahead and refund it."}]},
    config=config,
)

Patrón B: resumen automático para contextos largos

Cuando un hilo supera la ventana de contexto del modelo, SummarizationMiddleware comprime los mensajes antiguos en un resumen acumulado antes de cada llamada. El agente pierde el histórico literal pero conserva el sentido, suficiente para la mayoría de casos de soporte o asistencia.

Con estado desde el primer díaHover to explore

5. Salida estructurada: recuperar datos tipados del agente

A menudo quieres que el agente recopile información y devuelva un objeto validado, no un resumen en texto libre. Pasa un modelo de Pydantic a response_format y el agente emitirá un objeto tipado dentro del mismo bucle, sin ningún paso extra de parseo:

from pydantic import BaseModel
from langchain.agents import create_agent

class SupportTicket(BaseModel):
    order_id: str
    issue_type: str          # "refund" | "late_delivery" | "wrong_item"
    recommended_action: str
    confidence: float        # 0.0 – 1.0

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[search_orders],
    response_format=SupportTicket,
    system_prompt=(
        "Classify the customer's issue and recommend an action. "
        "Always search the order before classifying."
    ),
)

result = agent.invoke({"messages": [
    {"role": "user", "content": "My order 4821 never arrived — it's been 3 weeks."}
]})

ticket: SupportTicket = result["structured_response"]
print(ticket.issue_type)           # "late_delivery"
print(ticket.recommended_action)   # "escalate to carrier"
print(ticket.confidence)           # 0.92

6. Streaming: que el agente se sienta rápido

El mayor problema de experiencia de usuario en un agente es la latencia: quien lo usa no ve nada hasta que termina el bucle completo. El streaming lo resuelve mostrando tokens y eventos de herramientas según se producen. LangChain admite dos modos:

# Mode 1 — stream final output tokens only
for chunk in agent.stream(
    {"messages": [{"role": "user", "content": "Status of order 4821?"}]},
    stream_mode="messages",
):
    if chunk[1].get("langgraph_node") == "agent":
        print(chunk[0].content, end="", flush=True)

# Mode 2 — stream every event (tool calls, results, tokens)
for event in agent.stream(
    {"messages": [{"role": "user", "content": "Status of order 4821?"}]},
    stream_mode="updates",
):
    kind = list(event.keys())[0]
    if kind == "tools":
        print(f"[tool] {event['tools']['messages'][0].name}")
    elif kind == "agent":
        for msg in event["agent"]["messages"]:
            print(msg.content, end="", flush=True)

En la práctica, usa stream_mode="updates" en cualquier interfaz con un panel de «pensando» en vivo: permite mostrar qué herramienta está llamando el agente sin esperar a la respuesta final.

7. Aprobación humana: la única barrera que no puedes saltarte

Cualquier agente capaz de gastar dinero, enviar un mensaje o escribir en una base de datos necesita una aprobación humana para las acciones irreversibles. LangChain v1 ofrece dos vías: middleware para los casos sencillos e interrupciones de LangGraph cuando necesitas control total.

# Simple approach — middleware
from langchain.agents.middleware import HumanInTheLoopMiddleware

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[search_orders, issue_refund, send_email],
    middleware=[
        HumanInTheLoopMiddleware(
            interrupt_on={"issue_refund": True, "send_email": True}
        )
    ],
)

# Advanced approach — LangGraph interrupt node
from langgraph.types import interrupt

def human_approval_node(state):
    last_tool_call = state["messages"][-1]
    # Pause execution and surface the tool call to your UI
    decision = interrupt({
        "tool": last_tool_call.name,
        "args": last_tool_call.tool_input,
        "prompt": "Approve this action?",
    })
    if decision["approved"]:
        return state  # continue
    # Inject a rejection message back into the graph
    return {"messages": [ToolMessage(content="Action rejected by user.", ...)]}

El middleware se implementa antes. La interrupción de LangGraph es más flexible: permite modificar los argumentos, no solo aprobar o rechazar. En proyectos con clientes casi siempre empezamos con middleware y solo pasamos a las interrupciones cuando hay que dejar que el usuario edite la llamada antes de ejecutarla.

8. ReAct frente a tool calling: cuál estás usando en realidad

Esta distinción confunde a mucha gente. En LangChain de 2022–2023, ReAct (Reason + Act) era el patrón principal: se pedía al modelo que escribiera un bloc de notas «Thought / Action / Observation» en texto plano, que LangChain parseaba para saber qué invocar. Funcionaba, pero era frágil: cualquier desviación del formato rompía el parser.

En 2026, create_agent usa tool calling nativo: el modelo emite la llamada estructurada en la respuesta de la API, no en texto libre. Es más fiable, más barato (no hay doble prompt) y está soportado por todos los grandes proveedores. ReAct queda como alternativa para modelos sin tool calling nativo, no como camino por defecto.

9. Checklist de producción antes de desplegar

1. Añade LangSmith desde el día cero. Define LANGSMITH_API_KEY y LANGSMITH_TRACING=true. Cada invoke, cada llamada a herramienta y cada token quedan trazados automáticamente. Lo agradecerás a las dos de la madrugada, cuando algo se rompa en producción.
2. Fija max_iterations. Un agente sin límite puede quedarse en bucle eterno por una herramienta mal descrita. Empieza en 10 y ajusta a la baja cuando conozcas tu profundidad habitual.
3. Protege con aprobación humana todas las herramientas destructivas. Sin excepciones. Un solo reembolso mal enviado en producción cuesta más que una semana de ingeniería.
4. Prueba las herramientas por separado primero. Haz tests unitarios de cada función con entradas simuladas. El comportamiento del agente es difícil de predecir; la corrección de una herramienta no lo es.
5. Escribe un conjunto de evaluación. Con LangSmith Datasets puedes registrar entradas reales y salidas esperadas, y lanzar evaluaciones de regresión en cada actualización de modelo. Sin eso, cada cambio de versión es a ciegas.
6. Usa un checkpointer duradero en producción. MemorySaver sirve para desarrollo local, pero cámbialo por PostgresSaver o RedisSaver antes de salir a producción: si no, un reinicio del servidor borra todo el estado conversacional.

10. Qué se dice en Reddit y X en 2026

Tras leer meses de hilos en r/LangChain, r/LocalLLaMA y los rincones de ingeniería de IA de X, la opinión de la comunidad se resume en estos temas recurrentes:

• «El diseño de herramientas es el 80 % del problema». Los posts de depuración más votados en r/LangChain casi siempre tratan de herramientas mal nombradas o docstrings vagos, no de fallos del framework. Cambias el nombre y empieza a funcionar.
• «Pasar de depurar con prints a LangSmith fue un antes y un después». Un comentario recurrente entre quienes han pasado de la demo al producto real. La vista de traza muestra exactamente qué llamada falló y por qué.
• «He sustituido LangChain por llamadas directas al SDK». Sigue siendo un tipo de post habitual, sobre todo en equipos que se especializan en un único proveedor o que persiguen latencias por debajo de 100 ms. En pipelines simples de 1 a 3 pasos, el coste del framework es real. No todos los casos lo necesitan.
• «La separación de paquetes (langchain / langchain-core / langgraph) sigue despistando a quien empieza». El propio equipo de LangChain lo reconoce. El modelo mental es más limpio en v1, pero la instalación sigue haciendo tropezar la primera vez.
• «Las llamadas en paralelo por fin hacen rápidas las consultas complejas». Quienes antes encadenaban llamadas secuenciales ven mejoras de latencia de 2 a 3 veces al dejar que el modelo lance a la vez las herramientas independientes.

11. Cuándo usar agentes de LangChain y cuándo no

Los agentes de LangChain son la opción correcta cuando necesitas al menos dos de estas cosas:

• Portabilidad entre proveedores (el mismo agente en Claude, GPT o Gemini cambiando una línea)
• Estado duradero de varios turnos con pausa y reanudación
• Aprobación humana para acciones destructivas
• Trazas y evaluación integradas sin montar tu propio logging
• Middleware reutilizable (anonimización de datos personales, resumen, reintentos)

Recurre al SDK del proveedor cuando:

• Trabajas con un solo proveedor y la latencia manda (bajar de <100ms es difícil con el coste del framework)
• Tu «agente» son en realidad 2 o 3 pasos lineales sin ramificaciones: un pipeline es más simple que un grafo
• El equipo tiene criterio propio sobre las abstracciones y prefiere controlar el bucle entero

Conclusión

Los agentes de LangChain en 2026 ya no son un juguete de tutorial. Con create_agent, tool calling nativo, estado con checkpoints, salida estructurada, streaming y middleware, el framework cubre toda la superficie de lo que necesita un agente en producción. La curva de aprendizaje existe —sobre todo en el diseño de herramientas y en el modelo de checkpoints de LangGraph—, pero a cambio obtienes un agente que puedes observar, pausar, ceder a una persona y migrar a otro modelo sin reescribir el código. Es una base sólida para cualquier MVP con IA.

Related Posts

LangChain v1 in 2026: The New Agent-Building Stack (What Reddit & X Are Saying)April 20, 2026

Orquestación de agentes con LangGraph: patrones, sorpresas en producción y qué se dice en Reddit y X (2026)16 de junio de 2026

Removing Expense Leakage Using Agentic Flow: The 2026 Founder's GuideApril 11, 2026